4 ms·

Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the compute

Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it. See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project. The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.

vkou 2y ago
Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
ryandrake 2y ago
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding. I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
- intelVISA 2y ago
  > Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity. Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
throw49sjwo1 2y ago
That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.
- jimmaswell 2y ago
  I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point. And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
  - throw49sjwo1 2y ago
    It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code. A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence. A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
  - Izkata 2y ago
    > And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal) I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week. On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with. Basically there's just no consistency day-to-day.
MarkMarine 2y ago
You’re on hackernews, not an MBA roundtable. Lot of people here have been at Apple (like me), Google (at its peak in your opinion or now) and let me queue you in on something… the leaders at Google, Apple, etc that you’re lionizing spoke about their developers the way I am. Maybe that is the gap between the typical org and the great ones
dns_snek 2y ago
> In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; That's not a job, that's a tool, and it's called a transpiler. A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler. > Their social skills are very often lacking, and they are prone to arrogance Unlike your own comment which displays these exact qualities?
dragonwriter 2y ago
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer “Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be. The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.
ebiester 2y ago
Maybe, just maybe, you're mixing cause and effect. If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience. If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product. An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.
- dns_snek 2y ago
  Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc. I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers. Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
  - Izkata 2y ago
    Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine. Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.
deleted 2y ago
[deleted]

vkou 2y ago

Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.

ryandrake 2y ago

> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding. I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.

intelVISA 2y ago
> Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity. Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.

throw49sjwo1 2y ago

That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.

jimmaswell 2y ago
I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point. And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
- throw49sjwo1 2y ago
  It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code. A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence. A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
- Izkata 2y ago
  > And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal) I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week. On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with. Basically there's just no consistency day-to-day.

MarkMarine 2y ago

You’re on hackernews, not an MBA roundtable. Lot of people here have been at Apple (like me), Google (at its peak in your opinion or now) and let me queue you in on something… the leaders at Google, Apple, etc that you’re lionizing spoke about their developers the way I am. Maybe that is the gap between the typical org and the great ones

dns_snek 2y ago

> In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; That's not a job, that's a tool, and it's called a transpiler. A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler. > Their social skills are very often lacking, and they are prone to arrogance Unlike your own comment which displays these exact qualities?

dragonwriter 2y ago

> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer “Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be. The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.

ebiester 2y ago

Maybe, just maybe, you're mixing cause and effect. If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience. If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product. An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.

dns_snek 2y ago
Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc. I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers. Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
- Izkata 2y ago
  Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine. Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.

deleted 2y ago

[deleted]