4 ms·
1. Keep teams small. Down to the smallest you can. E.g. 2 devs on a project, one is more front-end-y, the other is more db-y, but both can fix code top to botto
by keyle 3y ago
1. Keep teams small. Down to the smallest you can. E.g. 2 devs on a project, one is more front-end-y, the other is more db-y, but both can fix code top to bottom. If a lot of sync up are necessary with stakeholders, add a third person for that, a doco guru.
I've had this period where I worked with another contractor and we just blended in like one. We spoke twice a week and we got so much done because we both knew what needed to be done and got the ability to do it.
The key is that *the sum of the people should be worth more than the individual output of each*. The larger the team, the harder this is to achieve.
2. This classic from xkcd really makes a difference https://xkcd.com/1205/ https://xkcd.com/1205/ - Automate, eliminate, speed up. The sum adds up to massive savings.
3. Minimise cross-teams interruption. No sync up between teams, or having repeat meetings about the same thing; have clear meeting agendas. Divide the work in asynchronous output. For this you need good documentation and standards. Don't let other teams set your standards.
4. Have clear priorities. I've seen teams waste huge amount of time because priorities weren't clear. Flat-orgs are a thing, sure, but you better be able to justify how you spend your time. Consider every hour as a billable, not as a lifestyle.
5. Let people do their job. Because they're quiet doesn't mean they're not working. You might not be busy but they might be. Treat silence as deep work, not stillness.
Many personal hours are wasted because we're waiting on other people. Many team hours are wasted because priorities aren't clear or not well allocated. Finally, we're all slaves to slow systems, builds, deploys: be ruthless about those.
These are the main culprit of waste (imho!).
- xwowsersx 3y agoThese are great, thanks. Not what I had in mind with my question, but actually more foundational and important than what I was asking about.
- keyle 3y agoAh yes, you mentioned "Developer Experience". This is what makes a difference for me in the last 20+ years... 1. Know your tools inside out. If you're a Vim user or not (I'm not), make sure you do most things with shortcuts as much you can. Take notice of every time you use the mouse and consider whether that could be keyboard driven. You'll first save seconds, which turn into minutes, then hours. 1b. Same for the terminal tools. My 'profile' is shock full of aliases and functions that make my life easier to talk to containers, other tools, etc. It almost becomes a library of power tools. 2. Effective navigation through code, forward, backwards, definitions, declarations. These should become second nature and effortless to save a ton of time! 3. Use every power tools available, whether it's static analysis tools like Rust Clippy, or language servers (LSP) in VSCode, Neovim or elsewhere; or chatGPT, make sure you make technology work for you, as much as possible. 4. Hook up to Dash or DevDocs to reduce your time clicking about Google trying to solve a problem. Knowing everything is impossible, knowing where to find the information quickly is a life saver. 5. Sometimes you'll find a really hairy bug, document it for your future self. Whether you blog it up at night or simply keep it in your (searchable) notes, it can save you 20 mins down the line, it's worth it. Sometimes it's a recipe list of "how do I do that with X" systems that can't be automated. If you can go home and forget everything, you're doing it right. 6. Turn off notifications etc. as much as possible. This is well known... It's perfectly fine to browse HN in my mind as it's a net addition to my life, but be conscious about time spent on socials and more importantly knowing when to turn them off.
- pawelduda 3y agoRe 2, sometimes I waste more time than I save automating but then the task becomes more pleasant, friction is reduced so anything that helps stay in the flow is also a win for me. And some automations have similar steps so you can borrow from these you already have
- marcosdumay 3y agoAlso, almost every time I manage to seamlessly automate something, it turned out that doing the task 10 times more often brought some value too. So yeah, the "how many times you do the task" counter is a very bad metric of how worthwhile it is to automate. And on the other dimension, of "how long it is to write a program", well, it's a simple matter of precisely predicting the effort for a development task. We all know developers are great on this. Overall, this is a fun comic, but people shouldn't read anything else from it.