7 ms·

I hate that this has become the norm. Sometimes, even most of the time, tight clean code and proper data structures and clean smart queries are vital for both

I hate that this has become the norm. Sometimes, even most of the time, tight clean code and proper data structures and clean smart queries are vital for both cost and performance reasons. That smart(experienced) people think up how to approach a problem and throw it over the wall to the juniors makes me sad, even if it has become somewhat commonplace. I was actually offered a position doing exactly that for a rather successful, nonFAANG valley company. Literally 'decide how to solve the problem, then hand it off and never think about it again.' It sounded awful for everyone involved. I'd just write in abstracts and never code, and the coder just codes without thinking a ton. Sounds terrible for both party's growth.

madeofpalk 4y ago
This was not how I interpreted parent's comment. I thought they said that the hard part of coding is figuring out what to code. Actually writing it is the quick and easy part.
philjohn 4y ago
I work in a FAANG at this level - but one of the expectations is "you lift the others up around you" rather than just handing out tasks, and the other is "you write the hardest parts of the system". For me this can be something algo heavy with tight perf requirements, or setting up initial abstractions and architecture - it's a mix. But I'm only coding about 30% of the time.
Railsify 4y ago
Extreme division of labor, did it work as far as pushing the product forward?
deleted 4y ago
[deleted]
dkarl 4y ago
> I was actually offered a position doing exactly that for a rather successful, nonFAANG valley company. Literally 'decide how to solve the problem, then hand it off and never think about it again.' It sounded awful for everyone involved. I did that for a while, and it was exactly as awful as you would think. The implementers resented the implication that they couldn't do research and make interesting decisions, and I hated spending my time describing designs instead of implementing them. The design documents I wrote were DOA, since the implementers neglected to update them when they deviated from them. And of course all the normal dynamics of software development (shifting priorities, changing product requirements) were happening at the same time that I was handing off "finished" designs. It was a farce, and I quickly left for a role where I could be hands-on again. The right way to support juniors is much more fluid, because different people need support in different areas, and you have to give them chances to stretch themselves as well as preventing them from coming under too much pressure.
lifeisstillgood 4y ago
Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped" We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indicates to me some problem with job title inflation - like there are not enough manager slots so the management layer is moving down a rung to senior engineer. Edit: of course Linus Torvalds wrote more emails than code. Which tends to indicate something.
- urthor 4y ago
  Moving senior engineers into management is the smart thing sadly. My experience with F500 companies, doing anything causes an incredible amount of grief. The most productive thing for seniors IS stopping coding. Going to meetings is the only way to deploy ANY code to production. The problem isn't even software. The problem is "new software" represents change.
  - ozim 4y ago
    Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.
    - marcosdumay 4y ago
      You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional. That's not a good reason, although it may be the only thing you can do.
dspillett 4y ago
This is why I've always avoided moving into managing things. I'm a tinkerer, not a leader. I enjoy that and wouldn't enjoy the other. I may have done myself out of a bit of salary over the years, but I'm doing more than well enough as I am and my skills/attetudes/other seem generally respected.
zelos 4y ago
"Senior Engineer" isn't a single job definition, is it? There's senior in the technical sense and senior in the quasi-management sense.
substation13 4y ago
This is also not how to solve problems - at least in my experience. I must write some code, usually completely scrapped, to understand how things will fit together. PoC code is the next stage after white-boarding for me.
hammock 4y ago
What’s the better way, Assuming the goal is for the junior to do most of the work?

madeofpalk 4y ago

This was not how I interpreted parent's comment. I thought they said that the hard part of coding is figuring out what to code. Actually writing it is the quick and easy part.

philjohn 4y ago

I work in a FAANG at this level - but one of the expectations is "you lift the others up around you" rather than just handing out tasks, and the other is "you write the hardest parts of the system". For me this can be something algo heavy with tight perf requirements, or setting up initial abstractions and architecture - it's a mix. But I'm only coding about 30% of the time.

Railsify 4y ago

Extreme division of labor, did it work as far as pushing the product forward?

deleted 4y ago

[deleted]

dkarl 4y ago

> I was actually offered a position doing exactly that for a rather successful, nonFAANG valley company. Literally 'decide how to solve the problem, then hand it off and never think about it again.' It sounded awful for everyone involved. I did that for a while, and it was exactly as awful as you would think. The implementers resented the implication that they couldn't do research and make interesting decisions, and I hated spending my time describing designs instead of implementing them. The design documents I wrote were DOA, since the implementers neglected to update them when they deviated from them. And of course all the normal dynamics of software development (shifting priorities, changing product requirements) were happening at the same time that I was handing off "finished" designs. It was a farce, and I quickly left for a role where I could be hands-on again. The right way to support juniors is much more fluid, because different people need support in different areas, and you have to give them chances to stretch themselves as well as preventing them from coming under too much pressure.

lifeisstillgood 4y ago

Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped" We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indicates to me some problem with job title inflation - like there are not enough manager slots so the management layer is moving down a rung to senior engineer. Edit: of course Linus Torvalds wrote more emails than code. Which tends to indicate something.

urthor 4y ago
Moving senior engineers into management is the smart thing sadly. My experience with F500 companies, doing anything causes an incredible amount of grief. The most productive thing for seniors IS stopping coding. Going to meetings is the only way to deploy ANY code to production. The problem isn't even software. The problem is "new software" represents change.
- ozim 4y ago
  Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.
  - marcosdumay 4y ago
    You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional. That's not a good reason, although it may be the only thing you can do.

dspillett 4y ago

This is why I've always avoided moving into managing things. I'm a tinkerer, not a leader. I enjoy that and wouldn't enjoy the other. I may have done myself out of a bit of salary over the years, but I'm doing more than well enough as I am and my skills/attetudes/other seem generally respected.

zelos 4y ago

"Senior Engineer" isn't a single job definition, is it? There's senior in the technical sense and senior in the quasi-management sense.

substation13 4y ago

This is also not how to solve problems - at least in my experience. I must write some code, usually completely scrapped, to understand how things will fit together. PoC code is the next stage after white-boarding for me.

hammock 4y ago

What’s the better way, Assuming the goal is for the junior to do most of the work?