Clojurians Log v2

Thanks for all the tips. I can acknowledge seeing it as "the work itself', but was wondering if it had to be that way.

Regarding tips, it's important to manage your availability well. So you have long enough non-disturbed time slots for work as each interruption is costly. For example when I need to focus I silence notifications and enter "focus mode" untill I finish. I try to schedule meetings in a way that it's either start of my work or end or try to push all in one day. Sometimes I start earlier/later so that I make sure I have few hours of interrupted work when there is no one yet or people left already.

The dreaded Microsoft Teams has a "Viva Insights" feature that can automatically block out "focus time" on your calendar. I generally have it block 1-3 pm every day, but it auto-adjusts around other meetings on your calendar (and it auto-books time about a week in advance).

yup, sounds familiar

I believe this comes down to how people and processes work in a company. I.e. I get the same feeling of not getting anything done at least half of the week because I'm pairing with our juniors, explain aspects of the business domain and it's processes to new colleagues, ... But then I remember that this is actually part of my job and given that our juniors can do more and more work on their own i would say that I am getting stuff done. But yes I agree that there are sometimes a lot of unnecessary long meetings often because "that one person with a full calendar has to be at this meeting only to say that he/she doesn't care as long as they don't have to do the work". For me I found a good balance (most of the time) by starting early in the morning so I have about two hours before the daily when most other colleagues are still sleeping. Also we established to have time blocker when we are not available except for super urgent matters which also usually works well

My few tricks are: • saying no to more meetings (try doing this as much as possible) • limit reviews to 30mins end of day (instead of constant context switching), • have good tooling for all repetitive tasks, • be working on 1 clear task (written down in front of you works really well), • putting Slack in Focus mode (calls for emergencies), have clear 'office times' if necessary Depends on the type of company and role of course but in general, just like making time for things you gotta make space for focus.

Also as @seancorfield mentions making small incremental PRs minimises conflicts a lot. I like to merge multiple (maybe 1 - 5) PRs a day and rely on things like feature flippers to be able to merge partial features into main early. Haven't had many conflicts recently whilst at the same time working and collaborating on a lot of code. It does create a lot of branches, so I made a tool for myself that has eased the pain a lot over the past year. I'm actually polishing up the implementation and documentation at the moment, planning on making an official release soon (WIP nearly ready): https://www.prstack.dev/

If you build software alone it is quicker for you to build than building with more developers when you measure in how much code you write or how fast you ship. But long-term more will be built with bigger team (assuming similar level of skill of other teammates) and of higher quality and lower risk for the business when the one-man army leaves the company. Also the bigger company gets, the harder it is to be flexible for everyone. Company managment style always will be better for some and worse for other, so it balances out.

Having worked in small startups and several medium-to-large companies, I'm always impressed by how much small teams can get done -- but companies always seem to "scale" by adding more people and losing that small team dynamic. Productivity (of the team) does not scale linearly on the number of team members because of the increase in communication overhead and other bureaucracy. And, of course, scaling by adding more "small teams" still doesn't scale because then you have a different communication/orchestration overhead. It's a tough problem.

https://en.wikipedia.org/wiki/The_Mythical_Man-Month and https://en.wikipedia.org/wiki/Conway%27s_law?

It all depends on how you measure productivity. Arguably, apart from the very first item, everything from the list above could be counted towards "work".

I WFH, have almost no meetings, rarely have to answer anyone's Qs, code/PR reviews are minimal and fast, I follow Inbox Zero practices so dealing with email slots into Pomodoro segments, same with Slack, most of the companies I've been at aren't big enough to have the similar/affects problem (not even Macromedia, although Adobe was close but that was mostly due "enterprise" management thinking, IMO), merge conflicts are not a thing if your PRs are small and focused, escalations are rare because systems are stable and uptime is good 🙂 Maybe the problem isn't "work" per se but the company you're at and its culture? 😄 But, seriously, all those sound like process/management problems. None of them should be issues in a well-managed environment. But most companies are not well-managed 😞