11 ms·

The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely h

The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Not to mention onboarding newer devs who haven’t learned the technologies yet.

AtNightWeCode 4y ago
Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer. The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will enable quick decisions and shorter time to production. Scrum for instance also emphasis the need for protecting the developers from the outside. But in this agile post apocalypse it seems like the result have become the opposite.
- chrisweekly 4y ago
  Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.
taylodl 4y ago
Yep. Coding is a team sport. When hiring, think more along the lines like you're drafting for an NFL team. How does the potential hire's talents complement the team's? Will the personalities and the way they work fit with the team's? You ignore team culture at your own peril and that's been true now for decades.
temac 4y ago
It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact. Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone. And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.
fdgsdfogijq 4y ago
This is corporate software engineering in poorly designed systems. Its not software engineering and is a completely separate job. The fact that its so prevalent doesn't negate that fact.
ipaddr 4y ago
That's not a senior engineer's job.. that's a job that has scope creeped into many roles: project management, lead developer, project owner and a trainer. Are you doing QA and managing the production servers as well?
- matwood 4y ago
  Blurring the lines is a senior engineer's job (though at a larger company, this may not happen until the next level up). It's how they grow the scope of what they deliver to the company. I would be upset if a senior engineer told me that anything in the path of delivering the final product was not their job. Defining 'job' here as understanding something and communicating/helping address/fix with the appropriate team.
- corobo 4y ago
  Not OP but > Are you doing QA and managing the production servers as well haha... yes I am
- ZephyrBlu 4y ago
  Those are roles that Senior engineers are expected to be able to play, at least at my company. And yes, devs do QA because we have no QA staff and Production Engineers manage the servers.
- bombela 4y ago
  Wait.. you are supposed to only code?
  - puchatek 4y ago
    You're supposed to deliver value. But your org structure is dysfunctional I'd say you're also supposed to say boundaries and flag when you're spending too much time on things outside your core role
- didibus 4y ago
  That's what I thought at first as well, but I eventually realized that's not the case. The senior engineer is mandatory to be consulted and involved quite actively for all those other roles to function correctly.
MattGaiser 4y ago
I would have thought that job would be a higher level than senior. Team lead perhaps.
- Scarblac 4y ago
  I'm like him, senior developer at a small company (~80 people total, 15 in software dev) and also do all those things. Sometimes I am team lead or tech lead for a while, then purely dev for a while, depending on what projects we have and how we are divided into teams at the time. It's not considered "higher", just a role that the seniors sometimes have. The only job title above "senior x" in the company is Director.
  - mytailorisrich 4y ago
    That's perhaps because it is a very small team but it's highly unusual in larger organisations. In general "senior engineer" is actually a rather junior level in the overall organigram. 5 years experience doing pure dev. and your title is bumped to "senior engineer" but you're still a 'only' a dev.
- astrange 4y ago
  I’d expect team lead to be about senior level. A staff engineer should be doing more than that.
jseban 4y ago
> The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Yeah the hard part about software engineering is being the henchman of your corrupt manager.
- rocqua 4y ago
  I think the hard part would be equally split between: solving the right problem, ensuring the right flexibility, and making sure the customer actually will be happy.
silisili 4y ago
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.
watwut 4y ago
> The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. This sounds more like one person doing it all rather then "being developer".
punnerud 4y ago
I have switched on that, and figured out that there is more benefits of coding early than later: - Users can give feedback ( theoretical exercises is hard for users that’s not technical) - Get ownership over the product -Easier to learn “what you don’t know that you don’t know” when you can iterate -You have do so more development up front, but I believe you save it in the long run Took me almost 10years to have enough examples that coding vs no-code activities should not be 20/80 but 80/20.

AtNightWeCode 4y ago

Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer. The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will enable quick decisions and shorter time to production. Scrum for instance also emphasis the need for protecting the developers from the outside. But in this agile post apocalypse it seems like the result have become the opposite.

chrisweekly 4y ago
Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.

taylodl 4y ago

Yep. Coding is a team sport. When hiring, think more along the lines like you're drafting for an NFL team. How does the potential hire's talents complement the team's? Will the personalities and the way they work fit with the team's? You ignore team culture at your own peril and that's been true now for decades.

temac 4y ago

It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact. Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone. And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.

fdgsdfogijq 4y ago

This is corporate software engineering in poorly designed systems. Its not software engineering and is a completely separate job. The fact that its so prevalent doesn't negate that fact.

ipaddr 4y ago

That's not a senior engineer's job.. that's a job that has scope creeped into many roles: project management, lead developer, project owner and a trainer. Are you doing QA and managing the production servers as well?

matwood 4y ago
Blurring the lines is a senior engineer's job (though at a larger company, this may not happen until the next level up). It's how they grow the scope of what they deliver to the company. I would be upset if a senior engineer told me that anything in the path of delivering the final product was not their job. Defining 'job' here as understanding something and communicating/helping address/fix with the appropriate team.
corobo 4y ago
Not OP but > Are you doing QA and managing the production servers as well haha... yes I am
ZephyrBlu 4y ago
Those are roles that Senior engineers are expected to be able to play, at least at my company. And yes, devs do QA because we have no QA staff and Production Engineers manage the servers.
bombela 4y ago
Wait.. you are supposed to only code?
- puchatek 4y ago
  You're supposed to deliver value. But your org structure is dysfunctional I'd say you're also supposed to say boundaries and flag when you're spending too much time on things outside your core role
didibus 4y ago
That's what I thought at first as well, but I eventually realized that's not the case. The senior engineer is mandatory to be consulted and involved quite actively for all those other roles to function correctly.

MattGaiser 4y ago

I would have thought that job would be a higher level than senior. Team lead perhaps.

Scarblac 4y ago
I'm like him, senior developer at a small company (~80 people total, 15 in software dev) and also do all those things. Sometimes I am team lead or tech lead for a while, then purely dev for a while, depending on what projects we have and how we are divided into teams at the time. It's not considered "higher", just a role that the seniors sometimes have. The only job title above "senior x" in the company is Director.
- mytailorisrich 4y ago
  That's perhaps because it is a very small team but it's highly unusual in larger organisations. In general "senior engineer" is actually a rather junior level in the overall organigram. 5 years experience doing pure dev. and your title is bumped to "senior engineer" but you're still a 'only' a dev.
astrange 4y ago
I’d expect team lead to be about senior level. A staff engineer should be doing more than that.

jseban 4y ago

> The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Yeah the hard part about software engineering is being the henchman of your corrupt manager.

rocqua 4y ago
I think the hard part would be equally split between: solving the right problem, ensuring the right flexibility, and making sure the customer actually will be happy.

silisili 4y ago

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.

watwut 4y ago

> The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. This sounds more like one person doing it all rather then "being developer".

punnerud 4y ago

I have switched on that, and figured out that there is more benefits of coding early than later: - Users can give feedback ( theoretical exercises is hard for users that’s not technical) - Get ownership over the product -Easier to learn “what you don’t know that you don’t know” when you can iterate -You have do so more development up front, but I believe you save it in the long run Took me almost 10years to have enough examples that coding vs no-code activities should not be 20/80 but 80/20.