Maximizing Developer Effectiveness
martinfowler.com
Maximizing Developer Effectiveness
1–10 of 168 posts
Re: Maximizing Developer Effectiveness
#2How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.
Re: Maximizing Developer Effectiveness
#3How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.
send them this article
Re: Maximizing Developer Effectiveness
#4Patterns on the most effective teams I’ve worked on:
- high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas
- high degree of care for the craft. We hold each other accountable to quality
- ships, regularly, to real customers
- little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold arbitrary titles.
- the individuals are more than fairly compensated and the company shows their love for the team in big and small ways
- the team talks to their customer and has a lot of empathy for their problems. They want to be accountable to them
- the team has a lot of empathy for new team members and works hard to make on boarding easier
- some willingness to “get in trouble” with the broader org because you know what you’re doing is right ultimately for the customer
- high self starters: instead of complaining, people feel empowered to solve problems or prototype ideas without a permission structure
- not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers.
There’s a lot more emphasis on emotional intelligence and empathy in an effective team than on any specific process.
Re: Maximizing Developer Effectiveness
#5How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.
[deleted]
Re: Maximizing Developer Effectiveness
#6Patterns on the most effective teams I’ve worked on: - high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas - high degree of care for the craft. We hold each other accountable to quality - ships, regularly, to real customers - little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold ar…
Rot sets in when:
- teams no longer have a real customer, such as “big rewrites” that will ship in 3 years
- teams accept low quality and slack off. One PR isn’t called out and that gives a permission structure for lower quality
- a bad egg gets on the team the wrecks the feelings of emotional safety. The brilliant narcissist the company feels they need to let his/her abusiveness slide
- we throw new hires “into the deep end” because they have to “take their lumps” like we did
- people get territorial over code because they’re insecure and maybe not great developers.
- the customer is ignored to chase the latest cool new thing
- hiring standards are lowered and anybody with a pulse that walked by the tech section in the bookstore is hired
- good developers stop seeing peers, and realize they do all the work, so leave for a healthier team
- tech illiteracy outside the team trumps tech competency in the team. When the manager says “stop writing unit tests, just get the feature done”
- any rumor “hire cheaper labor” causes your best to flee and your least qualified to jockey for status
Re: Maximizing Developer Effectiveness
#7How do you convince management to focus on improving workflows? There's often a huge focus on shipping features with that being the primary criteria for promotions.
There might an infinite amount of things to fix, but you have to first come up with one specific improvement to the workflow that is straightforward to implement, that can be clearly measured to improve rate of shipping features. Then convince your manager of that idea, usually by getting him/her to think that they came up with the idea on their own. Then keep on repeating this, and people will be able to accept more and more process improvements that have less and less direct ties to shipping more features, because they've seen the results of all the improvements along the way. And then eventually your manager gets promoted for doing such a great job on improving productivity in their team, and because they like and trust you, you get promoted into their vacated position.
Re: Maximizing Developer Effectiveness
#8Patterns on the most effective teams I’ve worked on: - high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas - high degree of care for the craft. We hold each other accountable to quality - ships, regularly, to real customers - little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold ar…
Rot sets in when: - teams no longer have a real customer, such as “big rewrites” that will ship in 3 years - teams accept low quality and slack off. One PR isn’t called out and that gives a permission structure for lower quality - a bad egg gets on the team the wrecks the feelings of emotional safety. The brilliant narcissist the company feels they need to let his/her abusiveness slide - we throw new hires “into the…
What’s worse is when some of these make their way into a company that has barely gotten off the ground. Especially the narcissist.
Re: Maximizing Developer Effectiveness
#9> There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve.
I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don't exist. I say this as someone that's worked in large companies and saw how lengthy not only process feedback loops were (especially developer ↔ product team), but also engineering feedback loops (testing, deployment, dev environment setup, etc.)
And I also say this as someone that works on side-projects by myself. The tooling simply isn't there. Setting up fast engineering feedback loops (multi-tiered deployment, test, dev, local, prod, etc. environments, heck even hot reloading or debugging) is needlessly difficult, or janky, or simply impossible. This goes for just about any language/framework out there: from Java, to Javascript, to Go.
It's not surprising that FAANG often designs their own internal systems that handle this sort of thing (from DevOps, to automated testing, to A/B testing, to deployment). I'm a believer that this is also a space that's ripe for disruption. I want environments to just work. I want code to just compile. I want containers to just run. Without me having to start digging through documentation, looking at thirteen Stack Overflow threads, and cobbling a solution that will inevitably break 3 months from now.
Re: Maximizing Developer Effectiveness
#10> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach.
It's amazing this fad of microservices still hasn't subsided yet. It is the bane of every company that isn't a FAANG but has management who wants to pretend they might someday have FAANG-level scaling/development problems.