Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maximizing Developer Effectiveness

martinfowler.com

Post reply on HN
Print view View original

21–30 of 168 posts

Re: Maximizing Developer Effectiveness

#21

Post by beandgaethje »

xyzelement wrote: post #19
29athrowaway wrote: post #14

A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if…

There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.

This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.

Re: Maximizing Developer Effectiveness

#22

Post by Mc91 »

> Day in the life in a low effective environment

> notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team.

This is not a low effective environment. A low effective environment does not have a large e2e test suite. It does not have a siloed QA team, and people write little to no unit tests, never mind integration tests.

If you are in a "low effective environment", a "siloed QA team" is a godsend. At least someone is responsible solely for quality, as opposed to everyone churning out features as fast as they can. Disposing of the siloed QA team in such environments rarely helps matters.

Re: Maximizing Developer Effectiveness

#23

Post by xyzelement »

bradlys wrote: post #12

Ooph, just reading the highly effective vs low effective environment bullet points was triggering. I can think of environments I entered where a good chunk of it was highly effective and my most recent startup was plagued with the low effective one (and even then - it will still IPO). Worst part is - they really had no interest in improving it. To improve would require an entirely different management chain - one tha…

>> I sometimes wonder who these articles are written for.

If you're a Leader (big L) in an org, this gives you a way to asses your organization. If you're a leader (small l) it may give you a way to concretize your thinking around problems so you can discuss them better.

>> Am I supposed to share this with the CTO to show them how poorly the organization is being run?

That would be the worst way?

Why don't you pick whichever problems on the list resonate the most, come up with a good case as to why it's a real impediment to your team, ideally quantify its impact, perhaps come up with some solutions, and then go have the conversation?

Ultimately, it's not important whether your org looks good or bad against some checklist, the "meat" is whether you have an opportunity to be more effective against your goals. If so, people generally want to have that conversation. Especially if you go in with a realistic understanding of why things are this way and the tradeoffs.

>> and even then - it will still IPO

Sounds like they know what they're doing then?

Re: Maximizing Developer Effectiveness

#24

Post by jiggawatts »

Productivity and efficiency of people is one of the topics that's always fascinated me, and I've both read a lot of material on the topic and have had the opportunity to observe hundreds(!) of organisations first hand thanks to being a consultant roaming from place to place.

From both scientific studies on the matter and anecdotal observation of the same, I can unequivocally state that the top three priorities are:

#1) The high-level goals of the organisation must be rapidly and clearly passed down the management hierarchy so that everyone can "row in the same direction". Ambiguity about goals, or uncertainty in whether one's work is even worthwhile is an astonishingly effective destroyer of productivity. Never treat employees on a "need to know" basis, feeding them the bare minimum that you think they need.

#2) There is no known method more effective at improving overall product quality than mandatory peer review of all code. Not only does this have the obvious direct benefit, but it also helps cross-train senior staff, bring junior staff up to speed, and helps improve consistency.

#3) There is no known method more effective than checklists at improving the quality of manual processes. Sure, if you plan to do something a hundred times, automate it. But you know what is really easy to turn into automation? A checklist. For non-automated processes, a checklist allows junior staff to confidently produce quality. Checklists are a training aid as much as they are a tool for quality improvement.

Of course, there's a very long tail of things one can do on top of those basics to improve productivity, especially of junior staff. Use an IDE. Use a code linter. Use automatic tests on checkin. Etc, etc... But none of those hold a candle to the above three in terms of raw effectiveness.

To put things in perspective: I'd rather have those three things and no source control than source control and none of those three things. You can meticulously track every version of a piece of garbage and it'll still be garbage...

Re: Maximizing Developer Effectiveness

#25

Post by 29athrowaway »

xyzelement wrote: post #19
29athrowaway wrote: post #14

A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if…

There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.

It takes more time and dedication to become effective at B). And at first, you may get things wrong, but the approach does pay off.

Someone that follows approach B learns more in a shorter amount of time. Because learning (advancing the frontier of your knowledge) happens when you encounter that limit, recognize it and try to move forward. Rather than dismissing it, which is what A) does.

B) always thinks: what is a better way of doing this? A) never does. Therefore, over time, B) becomes more effective than A).

In mind sports it's the same. You learn more in slow games when you take longer to think your moves. Every pro will recommend you to prefer slow games over fast games.

Re: Maximizing Developer Effectiveness

#26

Post by xyzelement »

beandgaethje wrote: post #21
xyzelement wrote: post #19

Earlier quoted context omitted.

There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.

This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.

I am less optimistic. A good developer documents the right parts because he has the understanding that this is helpful. An under-documenter doesn't get why that's helpful. An over-documenter doesn't get why it's helpful either, that's why he does it all over the place.

Re: Maximizing Developer Effectiveness

#27

Post by theptip »

Mc91 wrote: post #22

> Day in the life in a low effective environment > notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team. This is not a low effective environment. A low effective environment does not have a large e2e test suite. It does not have a siloed QA team, and people write little to no u…

It’s all relative.

Relative to the highly effective teams the article is describing, the points on the spectrum you discuss here are “low” and “lower”. Sure, low is better than lower. The article is making the case for “high” though.

Re: Maximizing Developer Effectiveness

#28

Post by droopyEyelids »

throwarayes wrote: post #6
throwarayes wrote: post #4

Patterns 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…

Can you expand on "any rumor hire cheaper labor"? Im too new to understand that one.

Re: Maximizing Developer Effectiveness

#29

Post by nmfisher »

marshmellman wrote: post #17
bradlys wrote: post #15

Earlier quoted context omitted.

They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever…

I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.

The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team.

Probably some truth to that.

Re: Maximizing Developer Effectiveness

#30

Post by xyzelement »

jiggawatts wrote: post #24

Productivity and efficiency of people is one of the topics that's always fascinated me, and I've both read a lot of material on the topic and have had the opportunity to observe hundreds(!) of organisations first hand thanks to being a consultant roaming from place to place. From both scientific studies on the matter and anecdotal observation of the same, I can unequivocally state that the top three priorities are: #…

I agree with #1 and #2 and will add the following:

#1 - on the flip side, you need employees who give a shit about your company mission and your clients. Just like a good organization is eager to share these goals, a good employee is eager to receive them. Whenever someone doesn't care, it's a big indicator to write them off.

#2 - Likewise, people have to give a shit and be critical. I used to run code reviews on my team like this - person A reviews person B's code (together, in person) and I sit behind them, not to judge B's code but to judge A's review. It's shocking to me how people want to give code "the benefit of the doubt" and don't flag things unless they are truly egregious. It doesn't help anyone when people hold back like this.

Post reply on HN