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

31–40 of 168 posts

Re: Maximizing Developer Effectiveness

#31

Post by jiggawatts »

dvt wrote: post #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 loo…

I'm going through this right now. I'm helping a customer deploy Azure App Service (similar to AWS Elastic Beanstalk).

Jesus wept. It's sooo fiddly to set up everything. The prod and non-prod environments need dozens of parameters that are all slightly different. Some of these are exposed as resource properties, making them obvious, some are environment variables that are nearly undocumented. Everything is off by default and has to be turned on. Logging. Monitoring. High availability. Secure parameter storage. Staging. On and on....

Oh, you want high availability? Sure, if you pay an extra $3K per month and switch to internal only networking, build Azure DevOps "agent" VMs in a zone-redundant set, and register a bunch of private DNS zones. Good luck automating this. There are template samples available, but they've been broken for years.

Regional disaster recovery? Just duplicate everything! Okay, but not like that! Slightly differently because replication is asymmetric and you may not want active-active. Then you have to layer stuff on top to actually fail over. But not one thing at a time! That's a performance disaster. All or nothing, but that's not an Azure feature, so good luck with that...

This is what I thought the public cloud provides: Some place to upload a ZIP file of code that "just runs" without me having to baby-site the infrastructure.

What's actually provided is a bunch of infrastructure parts that the public cloud vendor will patch for you. Everything else is your problem.

Re: Maximizing Developer Effectiveness

#32

Post by bradlys »

xyzelement wrote: post #23
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 w…

Rocketships don’t need to know what they’re doing to succeed.

Re: Maximizing Developer Effectiveness

#33

Post by aserafini »

yeswecatan wrote: post #20
marshmellman wrote: post #17

Earlier quoted context omitted.

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.

Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as op…

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices).

But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.

Re: Maximizing Developer Effectiveness

#34

Post by addicted »

dvt wrote: post #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 loo…

In my experience for any particular aspect of software development, if you ask for advice, you will find 100 people saying about 10 different things.

It sounds confusing and contradictory. And it's likely that 1 of those ten things is much better than the others.

However, the gap between what you are doing right now and the worst of those ten things is almost certainly much greater than the gap between the worst of the ten things and the best.

IOW, just go ahead and implement one of the potentially contradictory improvements that people on HN, for example, have suggested. You will already be way better off than before.

And once you start doing this often enough you will get to the point where you're able to identify the best 2 or 3 of the 10 options presented almost immediately. And the gap then between #3 and #1 is small enough to possibly not even matter.

Re: Maximizing Developer Effectiveness

#35

Post by xyzelement »

29athrowaway wrote: post #25
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.

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…

This doesn't really match my experience with people. You can be dogmatic about, for example, code comments - and dogmatics are not thinkers.

I used to work with a guy who was representative of this dogma. He'd give people a hard time if they didn't comment every line of code, and his own comments would be shit like:

  if (country == "Japan)     // If the country is Japan
    total_cost = price       // set total_cost equal to 
  price
  else
    total_cost = price + tax // Otherwise, set total_cost to price+tax
He thought this was great, and was upset when I'd tell him this is completely useless (comments don't provide any information over the code) and it's missing the one thing that would be good to actually document: why is Japan different?

People like this heard somewhere that comments are good, and thus good people write comments, and if I am a good person then by gosh I am writing comments. They don't think about utility at all.

Re: Maximizing Developer Effectiveness

#36

Post by jdfellow »

droopyEyelids wrote: post #28
throwarayes wrote: post #6

Earlier quoted context omitted.

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.

Likely rumors that the company will be hiring or contracting overseas.

Re: Maximizing Developer Effectiveness

#37

Post by logicalmind »

I am on the precipice of starting a new project at an organization and it is a much larger and more diverse project than I have worked on before. This article provides some good food for thought, but is anyone fond of particular books or articles they've found particularly helpful?

I have worked in small teams of highly-effective teams generally. But I am about to embark on a much larger team consisting of a large range of skill levels. It would be nice to lay some effective groundwork from the start that isn't overly cumbersome.

Re: Maximizing Developer Effectiveness

#38

Post by xyzelement »

bradlys wrote: post #32
xyzelement wrote: post #23

Earlier quoted context omitted.

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

Rocketships don’t need to know what they’re doing to succeed.

Is that so obvious?

I bet there are way more failed businesses that had followed meticulous software practices than there are 'rocketships' that took off despite(?) what may appear to be bad practices.

Re: Maximizing Developer Effectiveness

#39

Post by 29athrowaway »

xyzelement wrote: post #35
29athrowaway wrote: post #25

Earlier quoted context omitted.

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…

This doesn't really match my experience with people. You can be dogmatic about, for example, code comments - and dogmatics are not thinkers. I used to work with a guy who was representative of this dogma. He'd give people a hard time if they didn't comment every line of code, and his own comments would be shit like: if (country == "Japan) // If the country is Japan total_cost = price // set total_cost equal to price…

Your code example doesn't represent approach B). You are conflating verbosity with readability.

A better example of B) in this context would be understanding that IEEE 754 floating point numbers cannot be used for currency, and perhaps adding a comment about that.

Meaning, really understanding what you are doing all the way, and understanding when it works and when it doesn't.

Re: Maximizing Developer Effectiveness

#40

Post by seer »

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: #…

Very good points and eloquently put. I want to add something though regarding #2 - having a code review process is not enough. You need to train people how to do good reviews.

I’ve seen countless times people treat reviews “an approval” by both author and reviewer and for various reasons. People don’t consider it worthwhile, or they don’t want to offend, or they feel offended.

There is countless amounts of advice out there on how to write good code. But there is precious little on how to review code, and even less on how to write “reviewable” code, which is also a thing.

But if people understand the PR review process as more of a conversation, meant to align people on one direction, PRs are incredibly awesome.

Post reply on HN