Live data from Hacker News

Maximizing Developer Effectiveness

martinfowler.com

41–50 of 168 posts

Re: Maximizing Developer Effectiveness

#41
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 t…

> 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.

I can't really get behind this sentiment, since in my experience the worst of those ten things is frequently not only ineffective (which would be bad enough since switching costs are very real), but actively harmful compared to whatever you're doing. Chances are you didn't arrive at your current processes entirely in a vacuum, and it's already a mishmash of ideas from the zeitgeist, filtered to not being the worst on all dimensions by the fact that you're still around to observe it.

You really need to be able to pick out the good ideas from the bad ideas, and that doesn't come readily to everyone.

Re: Maximizing Developer Effectiveness

#42

Earlier quoted context omitted.

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.

Good on them for puttin in the effort, at least. Some of us just show up for the paycheque

Re: Maximizing Developer Effectiveness

#43

Earlier quoted context omitted.

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

> 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. I can't really get behind this sentiment, since in my experience the worst of those ten things is frequently not only ineffective (which would be bad enough since switching costs are very real), but actively harmful compared to whatev…

Well, my assumption is that if you're seeking help (a) what you have isnt currently working, and that (b) you're seeking help at a place that usually provides decent info such as HN or Stack Overflow.

Or maybe I've become experienced enough to distinguish between the good and the bad ideas without realizing it and don't really remember the earlier days when I had mentors who would help me navigate those decisions.

Re: Maximizing Developer Effectiveness

#44

Earlier quoted context omitted.

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

I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.

Re: Maximizing Developer Effectiveness

#45

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

Mythical Man Month by Freddie Brooks is pretty good but is not a quick read.

Re: Maximizing Developer Effectiveness

#46
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 defa…

Azure product teams could do with a bit more customer obsession IMHO. And not just the existing customers you’ve had for 20 years with stale IT departments

Re: Maximizing Developer Effectiveness

#47
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 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.

Because we are always shifting frameworks and approaches, there are few consistent targets for tools like that. What you might call the "Developer Experience" tooling ecosystem, is woefully immature for this fact.

I would way rather use old approaches with mature developer experience tooling than new approaches with constantly breaking environments and pipelines. But we constantly start all over again with new approaches, and never quite make it to the mature tooling phase...

Re: Maximizing Developer Effectiveness

#48

Earlier quoted context omitted.

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

I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from import…

It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline.

In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).

Re: Maximizing Developer Effectiveness

#49

Earlier quoted context omitted.

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.

I've come around to commenting as if I was Statler and Waldorf.

Re: Maximizing Developer Effectiveness

#50
post #47
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 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. Because we are always shifting frameworks and approaches, there are few consistent targets for tools like that. What you might call the "Developer Exper…

I'd agree with you, but people were saying this exact thing about automating deployments and then Heroku came along and changed the whole game.

Terraform is trying to solve this but it's still a far cry from "Heroku for infra."

Post reply on HN