8 ms·

Something that I’ve noticed at my company and other companies friends work at is an increasing number of software engineers who do not write code at all. They j

Something that I’ve noticed at my company and other companies friends work at is an increasing number of software engineers who do not write code at all. They just write documents, comment on documents, go to meetings, and ask questions in emails. Lots of these types where I work and where my friends work (very well known companies). I do not think this is healthy for a company to have its mid and senior devs writing no code in the numbers I’m seeing.

3cats-in-a-coat 3y ago
Within the next 24 months that's what all engineers will transition to. Is it healthy or not, it's how it goes. Engineers move to abstract work like architecture, interfaces, and the implementation is handled by AIs, with humans just tweaking when it's not right.
- bqmjjx0kac 3y ago
  I'll take that bet.
- PartiallyTyped 3y ago
  I will take the other side of this bet. I don’t see this happening within the next 24 months.
  - 3cats-in-a-coat 3y ago
    We already have apps written by non coders in GPT. But sure let’s wait 24 months.
    - WJW 3y ago
      We also had apps written by "non coders" in excel. We had apps written by some hackthon participants who hadn't coded at all a week before the hackathon. Writing the code is not the hard part of software development, and never has been. The various LLMs do very poorly at generating and implementing high level designs, especially if they need to generate the specs themselves from a bunch a requirements and/or poorly formulated user feedback.
      - valval 3y ago
        You’re reiterating his argument almost perfectly. He initially said the code writing will be left to the AIs while high level designs will be left to the engineers. That’s exactly what they mention foreseeing in the next 24 months, which I also intuitively agree with.
    - PartiallyTyped 3y ago
      Woooooooooow, a greenfield project developed by a single or a couple of people! That for sure will scale on larger projects!
- xupybd 3y ago
  What are you basing this on? I've played with code generation from AIs it works sometimes but confidently produces bugs and doesn't scale at all. I think another giant leap is required to get to the point that humans are just tweaking. I'm saying we won't get there but what in the pipeline in the next 24 months that is going to get us there?
  - 3cats-in-a-coat 3y ago
    We all confidently write bugs and discover them in testing. The same process has been implemented for GPT, for example GPT Engineer, you can also instruct the Code Interpreter model for it in GPT Plus and it works. I see some people are not up to date here. What I base my guess on: the fact we already have GPT apps that write apps and clearly it works fine, and as we like to say "this is the worst it'll ever be". When people say "it's not very good right now, it produces garbage" I only see people who are not used with the speed of progress right now. Midjourney a year ago produced weird abstract doodles that only looked like images from distance. Now it produces photorealistic art that's taking jobs. One year. What we need: Bigger context, expert models in constellation and scale. You need nothing else. Of course some architectural modifications will emerge in the journey of achieving this, but that's a comparatively trivial constraint to solve, it's just normal software engineering as we've done for decades, but this time for models.
    - LtWorf 3y ago
      Just because you happen to do a trivial and menial job, it doesn't mean that every software developer does.
  - deleted 3y ago
    [deleted]
- coldtea 3y ago
  Don't drink too much of the AI kool-aid.
- analog31 3y ago
  Do the AI's need those things? I mean, they exist so that humans can understand their 10 million line code bases. Maybe something else will be needed, for AI's to understand their 10 billion line code bases. Something that we won't even be able to discern.
- formulathree 3y ago
  First: the AI isn't that accurate yet. It gets shit wrong. It's almost there but not yet. Maybe in 24 months... but a lot of people think we hit a wall. Second: implementation is harder then design. If AI can do implementation it can for sure do design. And it is demonstrably true that chatGPT can do design just as well if not better than implementation.
  - 3cats-in-a-coat 3y ago
    My observations are literally the opposite of what you said so YMMV. Design is where the needs of humans interface with the needs of a machine. Models are good at translating basic needs to code. Not so great knowing or figuring those needs in wider context. Yet. They’re interns.
calderwoodra 3y ago
As long as they're also reviewing code, I think this is fine. They're scaling their knowledge and impact. Obviously there has to be a healthy ratio of senior:non-senior for this to work as well (maybe 1:4-5?).
zerodensity 3y ago
That sounds like good old Waterfall to me. Or in its current form SAFE. 90% communication 10% code. And something like that is basically what it takes when you have hundreds or thousands of people working on the same product. Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility. Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.
- wiz21c 3y ago
  yup, 100% true. If you have not worked in such a big company (say more than 500 people), you can't imagine how much politics/communication/organisation/standards/procedures are important both in term of, well, importance, and time you spend on it. In the company I worked, you had about 1 analyst for 2 devs and 1 PM for 10 persons. So more than one third of the team was never writing code. Add in the time spent in meetings, talks, testing, understanding and yeah, I'm sure about 50% of the time was spent not coding.
ravenstine 3y ago
Wow, I've never seen anything like this at the places I've worked. In my experiemce, we could use a role like that.
- hnick 3y ago
  Sounds like a Business Analyst and perhaps Technical Writer. Not something the developer should usually spend most of their time doing, but a bit is good.
- deathanatos 3y ago
  Eh, careful what you wish for. There's two extremes, and I've had the displeasure of seeing them both. The first is those who write only code, with no regards for the overall design or documentation of the system, and are completely unable to formulate answers about the high-level functioning of the system, often ask for things based on a low-level need with no regard for what could or should happen at a high level, because nobody has the high level picture. The other one is armchair architects who will draw system diagrams utterly disconnected from reality, with sub-systems doing things they cannot do, that we will never hire the engineering to do, etc. They'll mandate "common APIs" and "everything must be REST" (but where REST is their personal vision, which is inevitable not RESTful at all, and often is just a bespoke RPC/HTTP style API). There's a happy medium in the middle: engineers who understand the code, can be productive in the code, but also understand and are making conscious decisions about what the highlevel should be, making design docs, emailing about intentions, etc. Management has to offer the environment for that to flourish though: there has to be the time for documentation, the time for the design to emerge and for bugs to be worked out. But if everything is just a PM's pet ticket that is due "yesterday" and it must be done because management decrees it and once it is, repeat? Then that'll never happen, and those eng will quickly find greener pastures. Sometimes it's really petty stuff, too. I've lost the fight of "engineering needs a mailing list to discuss technical changes, TDDs they'd like a review on, etc. There needs to be an alias for engineers to do engineering" — and yeah, no TDDs have happened since!
  - jaylittle 3y ago
    Yeah so just wanted to chime in here. I 100% agree. I have worked at both extremes. My current gig is basically the first one. Nobody has the big picture. Nobody wants to discuss the big picture. They are only interested in checking off the boxes associated with the task they currently have assigned. Everything is due yesterday because there is no actual priority list and our priorities shift on a daily basis. It's utter chaos. We are writing an ERP system. It is slowly shaping up to be a complete disaster. I have spent the last eight months trying to change this approach and attempting to lead by example. It's not working. I will be moving on soon. TLDR: Just because somebody can afford to hire a software engineer, doesn't mean they should hire a software engineer.
jvans 3y ago
If you aren't writing the code you don't understand the problem and can't possibly write the documentation
- jbmsf 3y ago
  Thank you for not having the obvious and boring take. (I also agree.)
- LeonB 3y ago
  Someone reading the code should also be capable of understanding the problem that it solves and documenting the use of the code. If your code is fairly well written, I mean.
  - bruce511 3y ago
    Code, like say English poetry, can be subtle. Reading the code can easily answer the question "what does this do?", but it usually doesn't answer "why are we doing it?" Most importantly it doesn't tell us what we're not doing here, and why not. I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done. But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on. Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists. It I'd if you like the "search index" into the code.
- von_lohengramm 3y ago
  I think you misread the GP. These "mid and senior devs" are writing documents not documentation. They're not writing comments or wiki pages, they're writing designs docs for new systems, proposals for cross-cutting initiatives, etc. They're taking their knowledge of the domain, its issues, and general wisdom and applying it at a scale larger than a single developer's output. In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done. For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
leeoniya 3y ago
i'm starting to see this as well. it's frustrating because capacity planning expects that all engineers / ICs write code at least 75% of their time. the effect is that titles+headcount no longer accurately reflects what are and arent reasonable deliverables / deadlines for a team.
- starcraft2wol 3y ago
  > no longer accurately reflects what are and arent reasonable deliverables Have you ever seen an accurate prediction of this by any methodology?
octodog 3y ago
I literally had a "senior cloud architect" tell me that he didn't understand how one of his team's apps works because "he only draws the boxes" and then laughed it off.
- gonzo41 3y ago
  Don't worry, he knows what you're thinking. It's probably a paralysing deep sadness for him.
  - MattPalmer1086 3y ago
    I think there can some some truth to that. As I progressed into more architectural work, you have to leave the deep technical details behind, and you do miss it. But you can't do everything.
- valvar 3y ago
  This is why self-deprecating humour can be dangerous. Some people won't get it and will just think you're an idiot.
magic_hamster 3y ago
As my career progresses I find myself reviewing code, mentoring, deciding on architecture and running around helping way more people. I still do hands on coding but my workday had completely changed since when I first started out.
dumpster_fire 3y ago
To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap. Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.
- bombolo 3y ago
  [flagged]
  - MattPalmer1086 3y ago
    Then you have quite limited experience (or you're just going for some snark). Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects. Out of interest, just who do you think should be doing the high level architecture?
    - bombolo 3y ago
      > Out of interest, just who do you think should be doing the high level architecture? People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
      - MattPalmer1086 3y ago
        I often see the argument that people who write the code should do the architecture as well. Maybe on a small development effort it can give better alignment. When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen. However, this does not mean that the architects are idiots, although that is of course possible!
doalldrugs 3y ago
This would be normal for any other engineering discipline.
floydian10 3y ago
I have seen this more and more as well. In my experience, it tends to be developers who are aiming to switch to project management at some point in their careers.
rqtwteye 3y ago
Reminds me a little of a lot of interns who all want to "lead". Doing the work is lower class. There is more money in talking about work.
- watwut 3y ago
  Yeah, but also these interterns are the ones who gets rewarded. The people who do the work do not get visibility and gets rewarded less.
zero_shift 3y ago
It's a consequence of scale. Beyond a critical mass of complexity, it becomes more work to envision the moving parts and orchestrate changes among them, than writing the code itself. Personally, I think most software systems could accept fewer moving parts if we allowed certain tradeoffs, and the benefit would be much more empowered engineers.
ozim 3y ago
Seems like you put too much value on writing code. As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable. Code is liability. To propose solutions I still need to know the code for the system so it is not like suddenly I lost ability to write or understand code. But coding - is only one of many tools for creating a system.
- blitzar 3y ago
  Your company is one consultant away from deciding that your role, as you dont write much code, could be better done by someone who is a full time manager who has an MBA fresh out of university and no coding skills.
  - jvanderbot 3y ago
    I've actually seen these kinds of very-valuable positions replace by the mythical "TPM", who (unless they are very good) has zero hands-on knowledge and wants none. They are worse than unhelpful. A good prin engineer gives all the same schedule updates and cross-functional requirements-wrangling that a mediocre TPM would, but also produces useful code examples, coaching, and PR reviews.
  - perlgeek 3y ago
    By the same token, somebody actively writing code could be said to be one consultant away from being replaced be an offshoring firm. In the end, knowledge of the business details (including their technical implementation) are something that cannot be easily replaced.
- TeMPOraL 3y ago
  > As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable. Except, this could be done better and cheaper by a literal rock with letters spelling "NO" written on it with a sharpie. If a software company doesn't write any code, what exactly is it doing? And speaking of bad decisions, surely some have been made already, since everyone is doing the job they're the least qualified for.
renegade-otter 3y ago
It's the culture of over-communication. In the last 8 year or so, I have noticed my ability to actually write code had dropped through the floor. Everything has to be discussed to death, reviewed, approved, and go through a release process and red tape that would make the US State Department blush. And the end result is still slow and inefficient. There is just no time to make it better as you move on to discuss something else to death, while drowning in a sea of Slack messages. At one level I understand it. Gone are the days of us hacking away as an island, playing around, experimenting. Software engineering is more mature, boring, and corporate.
Cthulhu_ 3y ago
I dunno, it depends entirely on the industry etc; code is, after all, but the final product, the implementation detail of your company. So many (too many?) developers focus too much on code, on output in lines of code, instead of building the right thing. This is why in a lot of companies, internal tools (like issue trackers, performance monitoring, logging, orchestration, testing, etc) are written and rewritten over and over again. The idea that building your own is better than using off the shelf software. But it's self-gratification, it's avoiding the company's own / real problems and products. Writing code without a plan or purpose is wasteful.

3cats-in-a-coat 3y ago

Within the next 24 months that's what all engineers will transition to. Is it healthy or not, it's how it goes. Engineers move to abstract work like architecture, interfaces, and the implementation is handled by AIs, with humans just tweaking when it's not right.

bqmjjx0kac 3y ago
I'll take that bet.
PartiallyTyped 3y ago
I will take the other side of this bet. I don’t see this happening within the next 24 months.
- 3cats-in-a-coat 3y ago
  We already have apps written by non coders in GPT. But sure let’s wait 24 months.
  - WJW 3y ago
    We also had apps written by "non coders" in excel. We had apps written by some hackthon participants who hadn't coded at all a week before the hackathon. Writing the code is not the hard part of software development, and never has been. The various LLMs do very poorly at generating and implementing high level designs, especially if they need to generate the specs themselves from a bunch a requirements and/or poorly formulated user feedback.
    - valval 3y ago
      You’re reiterating his argument almost perfectly. He initially said the code writing will be left to the AIs while high level designs will be left to the engineers. That’s exactly what they mention foreseeing in the next 24 months, which I also intuitively agree with.
  - PartiallyTyped 3y ago
    Woooooooooow, a greenfield project developed by a single or a couple of people! That for sure will scale on larger projects!
xupybd 3y ago
What are you basing this on? I've played with code generation from AIs it works sometimes but confidently produces bugs and doesn't scale at all. I think another giant leap is required to get to the point that humans are just tweaking. I'm saying we won't get there but what in the pipeline in the next 24 months that is going to get us there?
- 3cats-in-a-coat 3y ago
  We all confidently write bugs and discover them in testing. The same process has been implemented for GPT, for example GPT Engineer, you can also instruct the Code Interpreter model for it in GPT Plus and it works. I see some people are not up to date here. What I base my guess on: the fact we already have GPT apps that write apps and clearly it works fine, and as we like to say "this is the worst it'll ever be". When people say "it's not very good right now, it produces garbage" I only see people who are not used with the speed of progress right now. Midjourney a year ago produced weird abstract doodles that only looked like images from distance. Now it produces photorealistic art that's taking jobs. One year. What we need: Bigger context, expert models in constellation and scale. You need nothing else. Of course some architectural modifications will emerge in the journey of achieving this, but that's a comparatively trivial constraint to solve, it's just normal software engineering as we've done for decades, but this time for models.
  - LtWorf 3y ago
    Just because you happen to do a trivial and menial job, it doesn't mean that every software developer does.
- deleted 3y ago
  [deleted]
coldtea 3y ago
Don't drink too much of the AI kool-aid.
analog31 3y ago
Do the AI's need those things? I mean, they exist so that humans can understand their 10 million line code bases. Maybe something else will be needed, for AI's to understand their 10 billion line code bases. Something that we won't even be able to discern.
formulathree 3y ago
First: the AI isn't that accurate yet. It gets shit wrong. It's almost there but not yet. Maybe in 24 months... but a lot of people think we hit a wall. Second: implementation is harder then design. If AI can do implementation it can for sure do design. And it is demonstrably true that chatGPT can do design just as well if not better than implementation.
- 3cats-in-a-coat 3y ago
  My observations are literally the opposite of what you said so YMMV. Design is where the needs of humans interface with the needs of a machine. Models are good at translating basic needs to code. Not so great knowing or figuring those needs in wider context. Yet. They’re interns.

calderwoodra 3y ago

As long as they're also reviewing code, I think this is fine. They're scaling their knowledge and impact. Obviously there has to be a healthy ratio of senior:non-senior for this to work as well (maybe 1:4-5?).

zerodensity 3y ago

That sounds like good old Waterfall to me. Or in its current form SAFE. 90% communication 10% code. And something like that is basically what it takes when you have hundreds or thousands of people working on the same product. Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility. Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.

wiz21c 3y ago
yup, 100% true. If you have not worked in such a big company (say more than 500 people), you can't imagine how much politics/communication/organisation/standards/procedures are important both in term of, well, importance, and time you spend on it. In the company I worked, you had about 1 analyst for 2 devs and 1 PM for 10 persons. So more than one third of the team was never writing code. Add in the time spent in meetings, talks, testing, understanding and yeah, I'm sure about 50% of the time was spent not coding.

ravenstine 3y ago

Wow, I've never seen anything like this at the places I've worked. In my experiemce, we could use a role like that.

hnick 3y ago
Sounds like a Business Analyst and perhaps Technical Writer. Not something the developer should usually spend most of their time doing, but a bit is good.
deathanatos 3y ago
Eh, careful what you wish for. There's two extremes, and I've had the displeasure of seeing them both. The first is those who write only code, with no regards for the overall design or documentation of the system, and are completely unable to formulate answers about the high-level functioning of the system, often ask for things based on a low-level need with no regard for what could or should happen at a high level, because nobody has the high level picture. The other one is armchair architects who will draw system diagrams utterly disconnected from reality, with sub-systems doing things they cannot do, that we will never hire the engineering to do, etc. They'll mandate "common APIs" and "everything must be REST" (but where REST is their personal vision, which is inevitable not RESTful at all, and often is just a bespoke RPC/HTTP style API). There's a happy medium in the middle: engineers who understand the code, can be productive in the code, but also understand and are making conscious decisions about what the highlevel should be, making design docs, emailing about intentions, etc. Management has to offer the environment for that to flourish though: there has to be the time for documentation, the time for the design to emerge and for bugs to be worked out. But if everything is just a PM's pet ticket that is due "yesterday" and it must be done because management decrees it and once it is, repeat? Then that'll never happen, and those eng will quickly find greener pastures. Sometimes it's really petty stuff, too. I've lost the fight of "engineering needs a mailing list to discuss technical changes, TDDs they'd like a review on, etc. There needs to be an alias for engineers to do engineering" — and yeah, no TDDs have happened since!
- jaylittle 3y ago
  Yeah so just wanted to chime in here. I 100% agree. I have worked at both extremes. My current gig is basically the first one. Nobody has the big picture. Nobody wants to discuss the big picture. They are only interested in checking off the boxes associated with the task they currently have assigned. Everything is due yesterday because there is no actual priority list and our priorities shift on a daily basis. It's utter chaos. We are writing an ERP system. It is slowly shaping up to be a complete disaster. I have spent the last eight months trying to change this approach and attempting to lead by example. It's not working. I will be moving on soon. TLDR: Just because somebody can afford to hire a software engineer, doesn't mean they should hire a software engineer.

jvans 3y ago

If you aren't writing the code you don't understand the problem and can't possibly write the documentation

jbmsf 3y ago
Thank you for not having the obvious and boring take. (I also agree.)
LeonB 3y ago
Someone reading the code should also be capable of understanding the problem that it solves and documenting the use of the code. If your code is fairly well written, I mean.
- bruce511 3y ago
  Code, like say English poetry, can be subtle. Reading the code can easily answer the question "what does this do?", but it usually doesn't answer "why are we doing it?" Most importantly it doesn't tell us what we're not doing here, and why not. I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done. But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on. Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists. It I'd if you like the "search index" into the code.
von_lohengramm 3y ago
I think you misread the GP. These "mid and senior devs" are writing documents not documentation. They're not writing comments or wiki pages, they're writing designs docs for new systems, proposals for cross-cutting initiatives, etc. They're taking their knowledge of the domain, its issues, and general wisdom and applying it at a scale larger than a single developer's output. In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done. For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.

leeoniya 3y ago

i'm starting to see this as well. it's frustrating because capacity planning expects that all engineers / ICs write code at least 75% of their time. the effect is that titles+headcount no longer accurately reflects what are and arent reasonable deliverables / deadlines for a team.

starcraft2wol 3y ago
> no longer accurately reflects what are and arent reasonable deliverables Have you ever seen an accurate prediction of this by any methodology?

octodog 3y ago

I literally had a "senior cloud architect" tell me that he didn't understand how one of his team's apps works because "he only draws the boxes" and then laughed it off.

gonzo41 3y ago
Don't worry, he knows what you're thinking. It's probably a paralysing deep sadness for him.
- MattPalmer1086 3y ago
  I think there can some some truth to that. As I progressed into more architectural work, you have to leave the deep technical details behind, and you do miss it. But you can't do everything.
valvar 3y ago
This is why self-deprecating humour can be dangerous. Some people won't get it and will just think you're an idiot.

magic_hamster 3y ago

As my career progresses I find myself reviewing code, mentoring, deciding on architecture and running around helping way more people. I still do hands on coding but my workday had completely changed since when I first started out.

dumpster_fire 3y ago

To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap. Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.

bombolo 3y ago
[flagged]
- MattPalmer1086 3y ago
  Then you have quite limited experience (or you're just going for some snark). Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects. Out of interest, just who do you think should be doing the high level architecture?
  - bombolo 3y ago
    > Out of interest, just who do you think should be doing the high level architecture? People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
    - MattPalmer1086 3y ago
      I often see the argument that people who write the code should do the architecture as well. Maybe on a small development effort it can give better alignment. When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen. However, this does not mean that the architects are idiots, although that is of course possible!

doalldrugs 3y ago

This would be normal for any other engineering discipline.

floydian10 3y ago

I have seen this more and more as well. In my experience, it tends to be developers who are aiming to switch to project management at some point in their careers.

rqtwteye 3y ago

Reminds me a little of a lot of interns who all want to "lead". Doing the work is lower class. There is more money in talking about work.

watwut 3y ago
Yeah, but also these interterns are the ones who gets rewarded. The people who do the work do not get visibility and gets rewarded less.

zero_shift 3y ago

It's a consequence of scale. Beyond a critical mass of complexity, it becomes more work to envision the moving parts and orchestrate changes among them, than writing the code itself. Personally, I think most software systems could accept fewer moving parts if we allowed certain tradeoffs, and the benefit would be much more empowered engineers.

ozim 3y ago

Seems like you put too much value on writing code. As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable. Code is liability. To propose solutions I still need to know the code for the system so it is not like suddenly I lost ability to write or understand code. But coding - is only one of many tools for creating a system.

blitzar 3y ago
Your company is one consultant away from deciding that your role, as you dont write much code, could be better done by someone who is a full time manager who has an MBA fresh out of university and no coding skills.
- jvanderbot 3y ago
  I've actually seen these kinds of very-valuable positions replace by the mythical "TPM", who (unless they are very good) has zero hands-on knowledge and wants none. They are worse than unhelpful. A good prin engineer gives all the same schedule updates and cross-functional requirements-wrangling that a mediocre TPM would, but also produces useful code examples, coaching, and PR reviews.
- perlgeek 3y ago
  By the same token, somebody actively writing code could be said to be one consultant away from being replaced be an offshoring firm. In the end, knowledge of the business details (including their technical implementation) are something that cannot be easily replaced.
TeMPOraL 3y ago
> As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable. Except, this could be done better and cheaper by a literal rock with letters spelling "NO" written on it with a sharpie. If a software company doesn't write any code, what exactly is it doing? And speaking of bad decisions, surely some have been made already, since everyone is doing the job they're the least qualified for.

renegade-otter 3y ago

It's the culture of over-communication. In the last 8 year or so, I have noticed my ability to actually write code had dropped through the floor. Everything has to be discussed to death, reviewed, approved, and go through a release process and red tape that would make the US State Department blush. And the end result is still slow and inefficient. There is just no time to make it better as you move on to discuss something else to death, while drowning in a sea of Slack messages. At one level I understand it. Gone are the days of us hacking away as an island, playing around, experimenting. Software engineering is more mature, boring, and corporate.

Cthulhu_ 3y ago

I dunno, it depends entirely on the industry etc; code is, after all, but the final product, the implementation detail of your company. So many (too many?) developers focus too much on code, on output in lines of code, instead of building the right thing. This is why in a lot of companies, internal tools (like issue trackers, performance monitoring, logging, orchestration, testing, etc) are written and rewritten over and over again. The idea that building your own is better than using off the shelf software. But it's self-gratification, it's avoiding the company's own / real problems and products. Writing code without a plan or purpose is wasteful.