5 ms·

This article represents the death of excellence and craftsmanship. Its the McDonald's-ization of software development. McDonald's does make the most consistent

This article represents the death of excellence and craftsmanship. Its the McDonald's-ization of software development. McDonald's does make the most consistent "food" in the world. But nobody would say it makes good food. No chef would ever want to work preparing food at McDonald's. The author pointed out many good ideas - the problem is the extremism - the author clearly hates software developers and the complexity of software development (a common trait among management), and wants to eliminate the complexity and variability inherent to dynamic human creation. Once you've taken all the creativity and joy out of it, and distilled it down to something any monkey or even ChatGPT can do, yes you've achieved such a system, and it's a quite dreadful place to work. A less extreme version of what the author proposes can enhance creativity and net velocity - but these systems need to be in balance, supporting and enabling the creative process, not eliminating it.

baldeagle 2y ago
This comment combined with a recent reflection on the ‘irony of automation’ makes me worried that the product I’m building to make life easier will instead lead to loss of craft, pride, and ingenuity. Honestly, still processing through it to make sure that all the people in my products and systems are seen.
- pell 2y ago
  It might sound redundant but I do think there can be an achievable balance. I worked at an organization that was allergic to documentation and safeguards of any kind and relied fully on certain talents to resolve issues. This was not just incredibly inefficient but also caused many problems when some of these people left the company. I think some safeguards and consistent documentation would have avoided the majority of this. And the talented individuals would also have had more time to work on other things, learn new skills and get even better at crafting in a more broad sense instead of only playing fire department. And finally, I can reassure you that there will always be room for “individuals” and “heroes” to do their craft and also save the day. Most systems don’t run like clockwork, there are always bugs, weird failures, strange oddities, most systems will need saving at some point. So, creativity and craft will generally have a place and value.
Enk1du 2y ago
The best advice I've seen on the issue is "Don't scar on the first cut", as in you shouldn't try to add a new rule every time you have an outage. That being said, I absolutely hate heroes. I've worked with a couple that get their thrills from the adrenaline buzz of swooping in and fixing the big problem ... and walking away. They don't put the work into documentation or making systems resilient because that's boring. I like boring. Boring means I can clock off at the regular time and not think about work until the next day.
- drewcoo 2y ago
  > I absolutely hate heroes I dislike the heroes' bosses. They're to blame for the situation. Managing a team of engineers is not like being a dungeon master.
- satisfice 2y ago
  You don’t know what heroism is. Read the literature of heroism before you decide you hate your fellow humans. Each one of us is capable of heroism.
  - Angostura 2y ago
    And a system that requires it if it’s employees to function is fundamentally abusive
  - Enk1du 2y ago
    Ah, now the Natural Born Heroes heroism and the virtue of Xenia (ξενία) I can get behind. It's the ego-inflating ""heroes" in scare quotes" that crave validation that I find so exasperating.
  - Jolter 2y ago
    The article is not about real heroism though. It’s about workplace “heroes” in the sense of diligent, creative, productive workers who have to take personal responsibility for the success of the business despite lacking support from said business.
solatic 2y ago
But the world has enough room for both McDonald's and the farm-to-table restaurant. They serve different markets and fulfill different needs. There is room for both Big Agriculture monocultures that have industrialized agriculture and the Polyface Farms intensive farmers who are both happier and more productive and profitable per-acre than the monocultures. But large enterprises, for all their cookie-cutter, cog-in-the-machine dehumanizing process, are great places for many folks: for the early career folks who are just getting started on the experience ladder learning professional development and get lots of benefit from all the guardrails, for mid-career professionals starting families who need to tread water in their career while they focus on their young children at home, for late-career elders who prioritize both stability and the late-career paycheck to help get them into a comfortable retirement. The macro goal though isn't to attempt to deny the benefits of process in large enterprises, it's to promote more productive small business. There are natural benefits to scale in large enterprises, but in software, many of those benefits to scale are not inevitable. Outfits like WhatsApp succeeded at building immense scale with very few engineers. It may be a bit of survivor bias, but small businesses can outmaneuver large enterprises when they have more productive talent that is not hemmed in by all the safeguards that larger enterprises are required to have. But this is still separate from the fact that each have their place.
- insensible 2y ago
  I’m a permaculture designer and have run a small vegetable farm. I have visited Polyface twice and spoken personally with Joel Salatin both times. I’ve read several of his books. I think that Polyface shows up in this discussion very much on the side of the systemic safeguards the article recommends. His farm is full of systems and safeguards a great many things by design. He plans for every risk he can think of and adapts his system in response. He got the farm from his father and has largely transferred it to his son, and they have built a business training both interns and the interested public in their methods. Safety measures ≠ world-dominating industrial scale.
  - solatic 2y ago
    Sorry, I wasn't trying to claim that small businesses don't need any safeguards. For example, small businesses also need backups, they need TLS certificates, lots of industry-standard stuff. What they don't necessarily need are everything required by the checklists that are thousands of items long where every box must be checked to pass SOC 2, ISO 27001, FedRAMP, etc.
jonathanlydall 2y ago
I agree that the author’s proposal is too extreme, but some of their advice is good. I think any company wanting to scale to a significant size will need to learn to implement effective systems rather than rely too heavily on the efforts heroic individuals. However, what the author is proposing is the death of evolution in systems, they seem to think that an optimally efficient and effective system already exists and everyone should just be using it. This is not true because your competitors are probably always looking to change their own systems such that they can out manoeuvre you, unless you respond by adapting your systems, you will likely be out competed. My company’s approach is to progressively systematise everything reasonably possible, but it also has the philosophy that any existing system can be challenged for change or removal. We regularly have retrospectives primarily to try identify how we should change our systems. We never try to change too much at once, but over long periods of time our systems have tended to towards being highly effective. But understanding and identifying highly effective changes (beyond the low hanging fruit) requires exceptional individuals. We will always need heroes prepared to challenge existing thinking in case there is a better way.
jongjong 2y ago
Spot on. The comparison between a skilled software engineer and a skilled assembly line worker is a flawed one. The game of the assembly line worker is mass production; the impact of their skill is limited to a subset of all units and their contribution to each unit is also limited. A software engineer is more like a civil engineer or a surgeon. Their work affects the entirety of whatever they're working on at a foundational level. The value of the unit they work on is extremely high. Also, a software engineer doesn't assemble things; they plan and design things. Their impact outlasts their tenure by many years. Just like a surgeon's impact extends far beyond the operating table. Once the software engineer has quit the company, the code which they wrote is still crunching numbers and still earning income for their ex-employers while everybody sleeps. It's not just their code which lasts, it's the entire philosophy which they breathed into the product and their team which lasts as well.
- drewcoo 2y ago
  > The comparison between a skilled software engineer and a skilled assembly line worker is a flawed one. And the difference is that we engineers design and maintain the assembly lines, as opposed to being line workers.
bjornsing 2y ago
I agree wholeheartedly. I’ve seen this philosophy take over a software organization (Ericsson way back) and the results are dreadful. But it’s not only that the org turns into a dreadful place to work. You also lose in the market to competitors with a more creative culture. Ericsson could easily have been the AWS of the world and the creators of Android. Now it’s like… a shadow of its former self. (There are other reasons too of course, but I think this “process over people” philosophy was a major contributing factor.)
havkom 2y ago
Yes. Focus on building all your team members to heros instead. The other way around is possible, but you will end up with a team of 1000 people doing the same work as 10.
- havkom 2y ago
  BTW, I am currently working in an enterprise with a small team mixed with experienced developers (heros - but still always learning because of new complexities) and new developers (heros in becoming). Absolutely fantastic and we create wonders, but it requires management to acknowledge skill and exceptionalism.
voidr 2y ago
If creativity means allowing people to be creative with dangerous language features that they themselves probably don't fully understand and write code in a way that nobody else understands, then I would want none of it. Having working and maintainable software is a lot more important than having a team member showing off what they are able to do with eval, they can put that into a demo side project.
- layla5alive 2y ago
  That's not creativity, that's being amateur
deleted 2y ago
[deleted]

baldeagle 2y ago

This comment combined with a recent reflection on the ‘irony of automation’ makes me worried that the product I’m building to make life easier will instead lead to loss of craft, pride, and ingenuity. Honestly, still processing through it to make sure that all the people in my products and systems are seen.

pell 2y ago
It might sound redundant but I do think there can be an achievable balance. I worked at an organization that was allergic to documentation and safeguards of any kind and relied fully on certain talents to resolve issues. This was not just incredibly inefficient but also caused many problems when some of these people left the company. I think some safeguards and consistent documentation would have avoided the majority of this. And the talented individuals would also have had more time to work on other things, learn new skills and get even better at crafting in a more broad sense instead of only playing fire department. And finally, I can reassure you that there will always be room for “individuals” and “heroes” to do their craft and also save the day. Most systems don’t run like clockwork, there are always bugs, weird failures, strange oddities, most systems will need saving at some point. So, creativity and craft will generally have a place and value.

Enk1du 2y ago

The best advice I've seen on the issue is "Don't scar on the first cut", as in you shouldn't try to add a new rule every time you have an outage. That being said, I absolutely hate heroes. I've worked with a couple that get their thrills from the adrenaline buzz of swooping in and fixing the big problem ... and walking away. They don't put the work into documentation or making systems resilient because that's boring. I like boring. Boring means I can clock off at the regular time and not think about work until the next day.

drewcoo 2y ago
> I absolutely hate heroes I dislike the heroes' bosses. They're to blame for the situation. Managing a team of engineers is not like being a dungeon master.
satisfice 2y ago
You don’t know what heroism is. Read the literature of heroism before you decide you hate your fellow humans. Each one of us is capable of heroism.
- Angostura 2y ago
  And a system that requires it if it’s employees to function is fundamentally abusive
- Enk1du 2y ago
  Ah, now the Natural Born Heroes heroism and the virtue of Xenia (ξενία) I can get behind. It's the ego-inflating ""heroes" in scare quotes" that crave validation that I find so exasperating.
- Jolter 2y ago
  The article is not about real heroism though. It’s about workplace “heroes” in the sense of diligent, creative, productive workers who have to take personal responsibility for the success of the business despite lacking support from said business.

solatic 2y ago

But the world has enough room for both McDonald's and the farm-to-table restaurant. They serve different markets and fulfill different needs. There is room for both Big Agriculture monocultures that have industrialized agriculture and the Polyface Farms intensive farmers who are both happier and more productive and profitable per-acre than the monocultures. But large enterprises, for all their cookie-cutter, cog-in-the-machine dehumanizing process, are great places for many folks: for the early career folks who are just getting started on the experience ladder learning professional development and get lots of benefit from all the guardrails, for mid-career professionals starting families who need to tread water in their career while they focus on their young children at home, for late-career elders who prioritize both stability and the late-career paycheck to help get them into a comfortable retirement. The macro goal though isn't to attempt to deny the benefits of process in large enterprises, it's to promote more productive small business. There are natural benefits to scale in large enterprises, but in software, many of those benefits to scale are not inevitable. Outfits like WhatsApp succeeded at building immense scale with very few engineers. It may be a bit of survivor bias, but small businesses can outmaneuver large enterprises when they have more productive talent that is not hemmed in by all the safeguards that larger enterprises are required to have. But this is still separate from the fact that each have their place.

insensible 2y ago
I’m a permaculture designer and have run a small vegetable farm. I have visited Polyface twice and spoken personally with Joel Salatin both times. I’ve read several of his books. I think that Polyface shows up in this discussion very much on the side of the systemic safeguards the article recommends. His farm is full of systems and safeguards a great many things by design. He plans for every risk he can think of and adapts his system in response. He got the farm from his father and has largely transferred it to his son, and they have built a business training both interns and the interested public in their methods. Safety measures ≠ world-dominating industrial scale.
- solatic 2y ago
  Sorry, I wasn't trying to claim that small businesses don't need any safeguards. For example, small businesses also need backups, they need TLS certificates, lots of industry-standard stuff. What they don't necessarily need are everything required by the checklists that are thousands of items long where every box must be checked to pass SOC 2, ISO 27001, FedRAMP, etc.

jonathanlydall 2y ago

I agree that the author’s proposal is too extreme, but some of their advice is good. I think any company wanting to scale to a significant size will need to learn to implement effective systems rather than rely too heavily on the efforts heroic individuals. However, what the author is proposing is the death of evolution in systems, they seem to think that an optimally efficient and effective system already exists and everyone should just be using it. This is not true because your competitors are probably always looking to change their own systems such that they can out manoeuvre you, unless you respond by adapting your systems, you will likely be out competed. My company’s approach is to progressively systematise everything reasonably possible, but it also has the philosophy that any existing system can be challenged for change or removal. We regularly have retrospectives primarily to try identify how we should change our systems. We never try to change too much at once, but over long periods of time our systems have tended to towards being highly effective. But understanding and identifying highly effective changes (beyond the low hanging fruit) requires exceptional individuals. We will always need heroes prepared to challenge existing thinking in case there is a better way.

jongjong 2y ago

Spot on. The comparison between a skilled software engineer and a skilled assembly line worker is a flawed one. The game of the assembly line worker is mass production; the impact of their skill is limited to a subset of all units and their contribution to each unit is also limited. A software engineer is more like a civil engineer or a surgeon. Their work affects the entirety of whatever they're working on at a foundational level. The value of the unit they work on is extremely high. Also, a software engineer doesn't assemble things; they plan and design things. Their impact outlasts their tenure by many years. Just like a surgeon's impact extends far beyond the operating table. Once the software engineer has quit the company, the code which they wrote is still crunching numbers and still earning income for their ex-employers while everybody sleeps. It's not just their code which lasts, it's the entire philosophy which they breathed into the product and their team which lasts as well.

drewcoo 2y ago
> The comparison between a skilled software engineer and a skilled assembly line worker is a flawed one. And the difference is that we engineers design and maintain the assembly lines, as opposed to being line workers.

bjornsing 2y ago

I agree wholeheartedly. I’ve seen this philosophy take over a software organization (Ericsson way back) and the results are dreadful. But it’s not only that the org turns into a dreadful place to work. You also lose in the market to competitors with a more creative culture. Ericsson could easily have been the AWS of the world and the creators of Android. Now it’s like… a shadow of its former self. (There are other reasons too of course, but I think this “process over people” philosophy was a major contributing factor.)

havkom 2y ago

Yes. Focus on building all your team members to heros instead. The other way around is possible, but you will end up with a team of 1000 people doing the same work as 10.

havkom 2y ago
BTW, I am currently working in an enterprise with a small team mixed with experienced developers (heros - but still always learning because of new complexities) and new developers (heros in becoming). Absolutely fantastic and we create wonders, but it requires management to acknowledge skill and exceptionalism.

voidr 2y ago

If creativity means allowing people to be creative with dangerous language features that they themselves probably don't fully understand and write code in a way that nobody else understands, then I would want none of it. Having working and maintainable software is a lot more important than having a team member showing off what they are able to do with eval, they can put that into a demo side project.

layla5alive 2y ago
That's not creativity, that's being amateur

deleted 2y ago

[deleted]