There is an underlying assumption here that you might get one or two high performers but they’re going to leave and managing software development is more like managing a McDonald’s where you turn over fungible workers regularly.
Imagine starting from the other side with a skilled group of programmers and removing causes of them leaving (largely bad managers and management, and bureaucratic toil). Then this calculus starts looking very different.
Even then, your heroic programmer could get hit by a bus.
But, how does one start with a skilled group of programmers? You mean to start a business, and go compete in the marketplace? That does happen, but programming skill and business skill (and motivation) don’t coincide or even align as often as we’d like. Moreover, in highly consolidated markets the incumbent giants are hard to compete with. The golden exit strategy for most startups still remains being swallowed by a giant, which puts one back in the area of this underlying assumption that you dislike.
how does one start with a skilled group of programmers
Start with an uncommon language, Clojure, Haskell, Common Lisp, Elixir or such (is Uiua up to it?). You’ll probably have a good friend group of highly competent developers by spending time in a hipster language, but you’ll also get overqualified people applying who just want to work with that language!
The best way to manage system complexity is sufficiently skilled developers who have a coherent model of the system in their mind as they maintain it.
No amount of LLM use will cause this to happen. No amount of tooling or static analysis will cause this to happen. No amount of process will cause this to happen. In short, you cannot legislate this into existence. You can and should set up guard rails like the post talks about. But this only ensures you don’t make known mistakes. It can’t check for a beautiful or even a decent design.
Programming skill continues to matter, perhaps more so in enterprise software, as it is long-lived. If that fact is inconvenient to management/capital, that’s their problem with reality, not ours.
If you have strong enough rules, you don’t need to worry about the skills of the programmers.
Ok, let’s just write perfect rules and then use an LLM to code the whole system! /s
This quote is from a different post, but I think it sums up the limitations of this way of thinking:
The more barriers you have for bad code, the better your code quality.
To paraphrase Rich Hickie, every bug in production has something in common: they all passed the type checker.
Setting up good barriers in the first place requires skill. Knowing when to stop appeasing the linter and just put a eslint-ignore comment requires skill. Knowing how to design a cohesive system that elides the most likely classes of bugs is a skill. You can’t lint for that. You can write absolutely horrendous code that passes every check, and without some kind of guiding philosophy or vision, it will go on to confuse people, and those people will write even more confusing bugs.
In my opinion, this was a clear case of a programmer resisting the system approach because he wanted to spend time fixing the same problems over and over and pretend to be working hard.
This passage really bothered me. Your meta process seems to have failed you here, and this actually seems like the perfect time to defer to a skilled team lead or manager to defuse the conflict, presumably after hearing the dissenting opinion and considering the alternatives. Yet your conclusion is to blame and shame this person who voices a disagreement, which you uncharitably attribute to incompetence and dishonesty, citing no evidence.
I find it hard to believe that trying to enforce this mechanistic way of thinking didn’t harm the social dynamic of the team in some way.
I don’t fundamentally disagree that focusing on process, rather than putting skilled people on a pedestal, is a better way to build teams that work well together. But this article seems to fundamentally miss the point: process is about accountability to a shared understanding, not attaining some objective measurement of code quality. In short, it’s a social strategy, not a technical one.
Is this a rejection, at least in part, of the agile manifesto? I know we’re all disillusioned with formal Agile methodologies, and for good reasons, but it can’t be true that returning to the regimented rigidity of old corporate America is the answer. Maybe I misunderstand.
Trying to capture the good practices in systems instead of relying on heroes is very sound advice.
The article goes further and says “If you have strong enough rules, you don’t need to worry about the skills of the programmers.”
I don’t think that is at all accurate, and I don’t think the article provides any support for it. An example they provide is this: “One of the solutions was to introduce a rule to memoize everything returned by hooks, to automatically prevent future problems with memoization.”
I can easily believe that most of the things returned by hooks should be memoized. I am skeptical of the claim that ALL things returned by hooks should be memoized. So a library or tool which automatically memoized the results with a way to annotate that some should be omitted might be a great idea. Hiring unskilled developers because the memoization is automatic is NOT a good idea in my experience.
I’m curious to hear how the author would introduce innovation into a team/system. Which role is capable of making the rules? Who is capable of changing them, and even are they ever incentivized to do so? How does this not lead to perpetual stagnation?
There is an underlying assumption here that you might get one or two high performers but they’re going to leave and managing software development is more like managing a McDonald’s where you turn over fungible workers regularly.
Imagine starting from the other side with a skilled group of programmers and removing causes of them leaving (largely bad managers and management, and bureaucratic toil). Then this calculus starts looking very different.
Even then, your heroic programmer could get hit by a bus.
But, how does one start with a skilled group of programmers? You mean to start a business, and go compete in the marketplace? That does happen, but programming skill and business skill (and motivation) don’t coincide or even align as often as we’d like. Moreover, in highly consolidated markets the incumbent giants are hard to compete with. The golden exit strategy for most startups still remains being swallowed by a giant, which puts one back in the area of this underlying assumption that you dislike.
Start with an uncommon language, Clojure, Haskell, Common Lisp, Elixir or such (is Uiua up to it?). You’ll probably have a good friend group of highly competent developers by spending time in a hipster language, but you’ll also get overqualified people applying who just want to work with that language!
The best way to manage system complexity is sufficiently skilled developers who have a coherent model of the system in their mind as they maintain it.
No amount of LLM use will cause this to happen. No amount of tooling or static analysis will cause this to happen. No amount of process will cause this to happen. In short, you cannot legislate this into existence. You can and should set up guard rails like the post talks about. But this only ensures you don’t make known mistakes. It can’t check for a beautiful or even a decent design.
Programming skill continues to matter, perhaps more so in enterprise software, as it is long-lived. If that fact is inconvenient to management/capital, that’s their problem with reality, not ours.
Ok, let’s just write perfect rules and then use an LLM to code the whole system! /s
This quote is from a different post, but I think it sums up the limitations of this way of thinking:
To paraphrase Rich Hickie, every bug in production has something in common: they all passed the type checker.
Setting up good barriers in the first place requires skill. Knowing when to stop appeasing the linter and just put a
eslint-ignorecomment requires skill. Knowing how to design a cohesive system that elides the most likely classes of bugs is a skill. You can’t lint for that. You can write absolutely horrendous code that passes every check, and without some kind of guiding philosophy or vision, it will go on to confuse people, and those people will write even more confusing bugs.This passage really bothered me. Your meta process seems to have failed you here, and this actually seems like the perfect time to defer to a skilled team lead or manager to defuse the conflict, presumably after hearing the dissenting opinion and considering the alternatives. Yet your conclusion is to blame and shame this person who voices a disagreement, which you uncharitably attribute to incompetence and dishonesty, citing no evidence.
I find it hard to believe that trying to enforce this mechanistic way of thinking didn’t harm the social dynamic of the team in some way.
I don’t fundamentally disagree that focusing on process, rather than putting skilled people on a pedestal, is a better way to build teams that work well together. But this article seems to fundamentally miss the point: process is about accountability to a shared understanding, not attaining some objective measurement of code quality. In short, it’s a social strategy, not a technical one.
I see this and I weep a little:
Is this a rejection, at least in part, of the agile manifesto? I know we’re all disillusioned with formal Agile methodologies, and for good reasons, but it can’t be true that returning to the regimented rigidity of old corporate America is the answer. Maybe I misunderstand.
I believe the author is the (likely unwitting) avatar of the zeitgeist voicing how ‘people’ think engineering should work.
Trying to capture the good practices in systems instead of relying on heroes is very sound advice.
The article goes further and says “If you have strong enough rules, you don’t need to worry about the skills of the programmers.”
I don’t think that is at all accurate, and I don’t think the article provides any support for it. An example they provide is this: “One of the solutions was to introduce a rule to memoize everything returned by hooks, to automatically prevent future problems with memoization.”
I can easily believe that most of the things returned by hooks should be memoized. I am skeptical of the claim that ALL things returned by hooks should be memoized. So a library or tool which automatically memoized the results with a way to annotate that some should be omitted might be a great idea. Hiring unskilled developers because the memoization is automatic is NOT a good idea in my experience.
I’m curious to hear how the author would introduce innovation into a team/system. Which role is capable of making the rules? Who is capable of changing them, and even are they ever incentivized to do so? How does this not lead to perpetual stagnation?
It depends on implementation. The point is make system that will work to prevent a problems, rather than hope people will not make problems.
But you’re correct that it is important to make system mobile and ready for changes.