8 ms·

What's a senior engineer's job?

227 points by akshaykumar90 8y ago

venantius 8y ago
One thing that I consider to be a really important part of a senior engineer's job that's not enumerated here is: helping more junior engineers come up with estimates for difficulty and time on projects they're about to undertake. To a senior engineer, there are a large number of projects that are fairly easily scope-able, e.g. "add a new API endpoint"; "refactor this medium-large model" that a junior engineer may not have the necessary degree of confidence to estimate. While this can sometimes be the responsibility of an engineering manager, not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task.
- sdrothrock 8y ago
  That and a couple of other items on the list would fall (for me) under "mentoring/growing." I feel like a senior engineer should be working only on the really difficult stuff and also enabling other engineers to eventually be able to also work on the really difficult stuff. Enabling people to work to high standards, helping them when they're stuck, and helping with time estimates are all great parts of mentoring. It's a little shocking to me that "make sure folks are working well together" is tossed aside as "the manager's job." Part of being on a team, to me, is learning to communicate and work together effectively -- that's not a "manager's job," it's everyone's job. A senior engineer, by virtue of being senior, should also know and be able to teach effective communication strategies. It's just as important for an engineer to know how to communicate properly, whether it's within the team, with superiors, or with customers. This can reduce and lubricate many kinds of friction that ultimately cause needless work.
  - tinco 8y ago
    It might be shocking to you, but it is exactly the manager's main job. If people would magically communicate well and work together fluidly, we wouldn't need managers at all. It would just be team leads talking to product owners. You can try to hire around this, and sometimes this works, especially in small teams or early stage startups. But at some point this breaks down, humans simply can't be rational and social all of the time.
    - cimmanom 8y ago
      Yes, it’s the manager’s ultimate responsibility. But it’s not only the manager’s job. Every team member, and especially those with more experience, has a responsibility to ensure the team communicates and operates cooperatively and effectively. It’s the sort of thing that can’t be imposed by above by a manager if individuals aren’t taking responsibility for it in the first place.
    - sdrothrock 8y ago
      > but it is exactly the manager's main job I would disagree; a manager is not necessarily an engineer and thus cannot mentor a junior engineer as well as a senior engineer could. I'm not saying that a manager cannot or should not mentor, but that a senior engineer should ALSO be mentoring based on shared experience. There's no need for a mentor monopoly. :) This is a bit off topic, but to me, a good manager is basically an umbrella and a funnel for the team. The manager covers the team and protects them from crap to keep them productive, then funnels their communications and output to the correct places. Basically, the API for sales or execs or whatever to communicate with the team. That's where a manager differs from a senior dev for me -- the responsibilities are completely different. You can't have a good team driven from the top; everyone has to be working and pulling their weight. Now, I'm not saying that we should expect people to be rational and social all of the time, just that a large part of mentoring should include "soft" skills like how to deal with other people and yourself when you're not rational or social. This is definitely something that can be learned and eases workplace friction so, so much. Edit: If this sounds familiar, I think it might be because I tend to harp on this on HN whenever it comes up. I feel like the "soft" skills are under- or completely devalued here sometimes, but they can really make or break a team just as much as technical skills. I saw this comment on another thread that's sort of speaking to the same effect but from a practical perspective: https://news.ycombinator.com/item?id=18158042 https://news.ycombinator.com/item?id=18158042
      - pm90 8y ago
        Don't know why you are being downvoted, this is exactly how I see a manager as well. To add to protecting the team from external shitstorms, is also to be an advocate for team members so they don't have to constantly worry about raises and promotions.
- forkerenok 8y ago
  > not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task. That is a problem if you estimate time as opposed to (intrinsic) complexity of the task. If you choose to estimate complexity of tasks, then you estimate it without anticipating who would actually execute it and let the routine sprint capacity adjustments calibrate the rest for you.
  - UK-Al05 8y ago
    Story point style planning makes estimation a team problem rather specific engineers making estimates.
  - StupidOne 8y ago
    You still need time based planning. You can't go to client and say it will take 500 points to finish the project. You also can't bill story points. Yes, after some time velocity will enable you to easily convert points to time, but in real world when customer is de facto product owner and team size is in constant flux depending on each customer wishes, you need experience engineer to give you ballpark value how long something will take long before the coding even starts.
    - UK-Al05 8y ago
      Software development as an external agency is such a broken concept that I never apply for those jobs. The interests of both parties have serious misalignment.
- mlthoughts2018 8y ago
  Speaking as a senior engineer myself, I disagree because time estimation in software is not a useful activity. The only thing it helps is political manipulation in a layer of management above you. Engineering work takes as long as it takes and often there are unknown blockers or surprise aspects of a problem that make it far more difficult than expected, so frequently that the initial estimate has no value to anyone, not even in a rough sense like, "will it take 2 hours or 30 hours." In my experience, a task estimated at 2 hours is equally as likely to take 30 hours as to actually take 2 hours, and there is no systematic way to know which case you're in. Regular check-ins to catch the blocking issues early is much more important, and so teams should not waste time making estimates or tracking velocity. It's pure junk. Instead, start working and meet often to detect blocking issues as you go.
  - KKKKkkkk1 8y ago
    Also, in an org that resorts to estimating and enforcing timelines, a task estimated at 30 hours will take 30 hours, even if it requires 2.
    - wallflower 8y ago
      At one of my previous companies, during a death march like project to get a 1.0 out, it was widely known that the offshore team was outright lying about completing their work in the estimated hours (scrum). They routinely worked overtime and sometimes weekends and yet the management pretended everything was hunky dory and on schedule. The non-offshore team looked bad unless we too worked long hours. A mess on both sides. We eventually shipped the release, 9 months late.
  - collyw 8y ago
    Agreed, the other thing that gets me is that estimates are often expected to be on the spot decisions. If you have done a task that is similar before then that's fair enough, but no one has ever told me to go off for a day or two and investigate the difficult / unknown parts to see hat the options are.
    - 8y ago
- wellpast 8y ago
  I’m really disappointed at the responses in this thread. I’m finding as I go into industry more and more that there’s this philistinism amongst programmers. “Quality code can’t be achieved because look...” “Accurately estimating software is impossible because look...” It’s so easy to claim these things. It’s way harder to earn the associated skill sets. We’re taking “programmers should be lazy” to a whole new level where laziness means not practicing, not growing, but instead using “hard to learn” as an excuse and equating “hard to learn” with “generally impossible”.
marmaduke 8y ago
I think there are some less concrete responsibilities. This post assumes all your colleagues give a shit, while some work might get delegated to a colleague who then waits for you to step them through it. How do you motivate people to take responsibility for their work (when firing or changing teams isn’t possible)? I think a senior engineer is also going to be one writing fundamental proofs of concept when time is tight (or at least I have been doing this)
fit2rule 8y ago
I have my own sort of loose rules about this. I long ago came up with it, and it works for me, but maybe there are a few holes worth poking. Basically it goes like this: There are no 'senior'/'middle'/'junior' level developers. There are _A, _B and _C. _A guys sit at the top. _B supports _A. _C support _A and _B, and .. other _C's. _A supports all _B's, all _C's, and of course.. all other _A's. The position is self-determined, i.e. up to the individual. Occasionally, when enough _A's, _B's and _C's serve together, they self-organise. Sometimes, you need to tweak a few things. For example, there is a kind of _A who doesn't want to work on things without a few multiples of _C around to clean up after him. This guy needs a _B. Then there are _B's who ignore _C's and just wanna work with _A's. This guy needs a better _A. And, also, a few _C's. And there are _C's who want to be _A's, while ignoring their duty to _B. This guy needs a few more _A's, and either becomes a _B, or an _A. (Or a _D, which is 'goes and does marketing stuff instead'.) Either way, there is another 'type' of developer, and this guy is an _X. He gets all the _A's and _B's and _C's happily playing together, executing on the plan. He can be an _A or a _B or a _C: he doesn't care, as long as things are executing.
- Aeolun 8y ago
  Why would you try to argue this point with A,Bs and Cs? Even if you called them monkeys, horses and lions it would have been more understandable. There’s a reason we don’t use these kind of variable names...
amriksohata 8y ago
Totally disagree with the section "What’s not part of the job" Part of any job is stepping up and deputising for your manager, sure if you don't want career progression or want to go into the technical side you could argue they would try and do some of that instead, but if you want to be a senior you have to be a rounded individual that can mentor new starters, help with sprint planning when your boss is not around. Thats part of being a senior, otherwise you are just a good Mid.
- UK-Al05 8y ago
  I find help with sprint planning something every engineer should do. Sprints are owned by the team not the product owner
  - mosselman 8y ago
    People should do what lies within their realm of capabilities. I know enough people who are fine programmers but who lack the overview or sense of connectedness between certain task or the ability to think about the business value of certain tasks in order to make decisions when things start to take too long or become too complex. Those people should not take care of handling the sprint when the person who normally does that is away. So no, not every engineer should take care of the team's planning.
    - UK-Al05 8y ago
      Well in my team sprint planning is a team job. Everybody gets together and plans the next stories. Usually different people have knowledge/interests on different stories, so nearly everyone gets some input. Heck in the scrum guide this is the way it's meant to be. If your engineers can't factor in business value, or work dependencies its usually because people are hoarding knowledge so they dont have the ability to factor that in.
      - mosselman 8y ago
        I didn't say the team as a whole wouldn't be able to contribute. I was saying that not all people are able to take over day to day planning individually. "its usually because people are hoarding knowledge so they dont have the ability to factor that in." That is like saying that everybody who isn't smart, must be good with their hands. Some people are just not good at certain things, no matter how much they are enabled to do those things. Which is completely fine.
fogetti 8y ago
I think what the author described is mostly any engineer's job. You don't need a title for this.
yitchelle 8y ago
In the section where she explicitly mentioned what is not part of her job, I bring two of her points which I disagree with. * Make sure work is allocated in a fair way * Make sure folks are working well together While she is not directly responsible for these two items, she and everyone else on the team should be responsible for alarming their manager/team leader when either of these items are not working. With more eyes and ears monitoring the team, it helps to reduced the risk of bad behaviour disrupting the team's cohesion.
mzanchi 8y ago
It's interesting the author mentioned estimating but said they are not very good at it yet. I have read somewhere else that what distinguishes a senior engineer from a junior engineer is exactly the skill in estimating work.
- coldcode 8y ago
  No one can estimate worth a damn. With experience you realize how terrible all estimates are — unless you are estimating something you have exactly done before, which is more likely with more experience. Everything I have done in my career was mostly unrelated to anything done previously, so estimating would be as effective as using dice.
- collyw 8y ago
  As I said in another reply, it really depends. If its a task that I have done before and new code, then I can give a fairly good estimate. If its something new, I have no idea. If it's on a monstrous old codebase, then there are a lot of unknowns to add into that. And most people expect you to do such estimates on the spot.
- Aeolun 8y ago
  More like senior engineers have learned from experience and just triple any estimate.
srazzaque 8y ago
Good read, I like JE's posts. But I definitely feel like this falls into the trap that a lot of similar posts fall into - attempting to "bullet-point" a role description inevitably will result in people criticising the inclusion or exclusion of individual points. Which is a shame because it detracts from the overall spirit of what's being said. Struggling to find the link now, but I read another post on the subject of seniority, and it basically summarised the crux of it for me. This unravelled everything. Seniority is measured contextually by asking: "to what degree can I leave stuff with this person and expect it to get it done with high quality? Further, to what degree can I NOT leave stuff with this person and _still_ expect that to get done." From this, one can derive their own context-appropriate "check list". In an environment such as finance, where an engineer is absolutely not the expert, can I trust that this person can work with the experts to get to an appropriate solution? In an environment where you have many intermingled teams, will s/he be able to propose solutions and get buy-in across the org? In a consulting/client scenario, can this person represent our company? What might they need help in? In a bootstrapping startup scenario, can I entrust them with the entire build of (some major component)? In different contexts, the above set of questions would unroll a different set of measurements for seniority, and may require a different mix of soft/technical skills. But that's fine, there's no one-size-fits-all seniority ladder.
- jkmcf 8y ago
  I’d love to read that link. I usually summarize the role as doing what’s necessary to get the job done reasonably, but your point about knowing what to entrust others with is spot on.
mabbo 8y ago
> I put “write code” first because I find it surprisingly easy to accidentally let that take a back seat As a first-year-out-of-school developer, I shadowed an interview once from a "Principle Engineer" at another company. By the end of the interview, we understood two things: 1: He did not code in his job and hadn't in a while. 2: He could not code anymore. This role was for a senior engineer position, where he would need to mentor people on writing software. It was a pretty hard 'no' by the time we did our group follow-up with the other interviewers.
- BerislavLopac 8y ago
  He probably spent all of his time on developing principles...
- dunpeal 8y ago
  > As a first-year-out-of-school developer, I shadowed an interview once from a "Principle Engineer" at another company. A lot of people don't realize how easy it is to get impressive titles at very small or low-quality outfits. If it's just you and the CEO running the place, you would be a "CTO" even if you couldn't pass a phone screen for any decent entry-level engineer position. We constantly get resumes from "senior engineers" working for no-name tiny companies and startups. They are often our worst candidates, especially when it comes to hard skills like coding. Reality is that these skills are rare, and no-name outfits will be competing for the rare candidates who can code against all the better employers out there. The results are what you'd expect.
  - UK-Al05 8y ago
    Even at large companies this can happen. Architects and high level engineers can simply go out of touch with current engineering practices simply because it's not their job anymore.
    - dunpeal 8y ago
      You know, I heard this claim about "architects" and "high level engineers" before, but I've never seen much evidence for it in real life. How many of these detached astronaut "architects" actually exist? The only real-life example I ever became personally familiar with: academics who were parachuted to some quasi engineering leadership positions thanks to their impressive publication credentials. I wouldn't call these folks "engineers" of any level. They are scientists who head teams that employ engineers.
vkjv 8y ago
> "...review design docs" In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team. But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information. Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.
- jiveturkey 8y ago
  what ive found works is to /always/ pair a jr with a sr engineer to write any ddoc. 2nd, always assign a specific sr reviewer. only after that review, release the hounds. others that have interest or particular insight can reflect on deficiencies (or, rarely, strengths) without the dread feeling of having to deeply understand the context or underlying dependencies. same reason you don’t just throw a code review out to “everyone”. everyone = no one
rlaanemets 8y ago
I think that setting explicit job boundaries is a good thing to do. Otherwise you end up with role creep and potential burnout. This happened to me. There is a considerable pressure to pick up as many activities at the job as you can as hiring more developers is hard or impossible at some locations as the demand for developers has skyrocketed. This demand buries you even deeper under tasks once your colleagues leave elsewhere for better offers.
deleted 8y ago
[deleted]
visviva 8y ago
What's a senior *software engineer's job?
deleted 8y ago
[deleted]
nojvek 8y ago
Jvns does it again. We need more women like her in the industry. Such an awesome engineer and educator.

227 points by akshaykumar90 8y ago

One thing that I consider to be a really important part of a senior engineer's job that's not enumerated here is: helping more junior engineers come up with estimates for difficulty and time on projects they're about to undertake. To a senior engineer, there are a large number of projects that are fairly easily scope-able, e.g. "add a new API endpoint"; "refactor this medium-large model" that a junior engineer may not have the necessary degree of confidence to estimate. While this can sometimes be the responsibility of an engineering manager, not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task.

sdrothrock 8y ago
That and a couple of other items on the list would fall (for me) under "mentoring/growing." I feel like a senior engineer should be working only on the really difficult stuff and also enabling other engineers to eventually be able to also work on the really difficult stuff. Enabling people to work to high standards, helping them when they're stuck, and helping with time estimates are all great parts of mentoring. It's a little shocking to me that "make sure folks are working well together" is tossed aside as "the manager's job." Part of being on a team, to me, is learning to communicate and work together effectively -- that's not a "manager's job," it's everyone's job. A senior engineer, by virtue of being senior, should also know and be able to teach effective communication strategies. It's just as important for an engineer to know how to communicate properly, whether it's within the team, with superiors, or with customers. This can reduce and lubricate many kinds of friction that ultimately cause needless work.
- tinco 8y ago
  It might be shocking to you, but it is exactly the manager's main job. If people would magically communicate well and work together fluidly, we wouldn't need managers at all. It would just be team leads talking to product owners. You can try to hire around this, and sometimes this works, especially in small teams or early stage startups. But at some point this breaks down, humans simply can't be rational and social all of the time.
  - cimmanom 8y ago
    Yes, it’s the manager’s ultimate responsibility. But it’s not only the manager’s job. Every team member, and especially those with more experience, has a responsibility to ensure the team communicates and operates cooperatively and effectively. It’s the sort of thing that can’t be imposed by above by a manager if individuals aren’t taking responsibility for it in the first place.
  - sdrothrock 8y ago
    > but it is exactly the manager's main job I would disagree; a manager is not necessarily an engineer and thus cannot mentor a junior engineer as well as a senior engineer could. I'm not saying that a manager cannot or should not mentor, but that a senior engineer should ALSO be mentoring based on shared experience. There's no need for a mentor monopoly. :) This is a bit off topic, but to me, a good manager is basically an umbrella and a funnel for the team. The manager covers the team and protects them from crap to keep them productive, then funnels their communications and output to the correct places. Basically, the API for sales or execs or whatever to communicate with the team. That's where a manager differs from a senior dev for me -- the responsibilities are completely different. You can't have a good team driven from the top; everyone has to be working and pulling their weight. Now, I'm not saying that we should expect people to be rational and social all of the time, just that a large part of mentoring should include "soft" skills like how to deal with other people and yourself when you're not rational or social. This is definitely something that can be learned and eases workplace friction so, so much. Edit: If this sounds familiar, I think it might be because I tend to harp on this on HN whenever it comes up. I feel like the "soft" skills are under- or completely devalued here sometimes, but they can really make or break a team just as much as technical skills. I saw this comment on another thread that's sort of speaking to the same effect but from a practical perspective: https://news.ycombinator.com/item?id=18158042 https://news.ycombinator.com/item?id=18158042
    - pm90 8y ago
      Don't know why you are being downvoted, this is exactly how I see a manager as well. To add to protecting the team from external shitstorms, is also to be an advocate for team members so they don't have to constantly worry about raises and promotions.
forkerenok 8y ago
> not all EMs are sufficiently technical to know how long it'll take a _junior_ engineer to take on an otherwise easily-scoped task. That is a problem if you estimate time as opposed to (intrinsic) complexity of the task. If you choose to estimate complexity of tasks, then you estimate it without anticipating who would actually execute it and let the routine sprint capacity adjustments calibrate the rest for you.
- UK-Al05 8y ago
  Story point style planning makes estimation a team problem rather specific engineers making estimates.
- StupidOne 8y ago
  You still need time based planning. You can't go to client and say it will take 500 points to finish the project. You also can't bill story points. Yes, after some time velocity will enable you to easily convert points to time, but in real world when customer is de facto product owner and team size is in constant flux depending on each customer wishes, you need experience engineer to give you ballpark value how long something will take long before the coding even starts.
  - UK-Al05 8y ago
    Software development as an external agency is such a broken concept that I never apply for those jobs. The interests of both parties have serious misalignment.
mlthoughts2018 8y ago
Speaking as a senior engineer myself, I disagree because time estimation in software is not a useful activity. The only thing it helps is political manipulation in a layer of management above you. Engineering work takes as long as it takes and often there are unknown blockers or surprise aspects of a problem that make it far more difficult than expected, so frequently that the initial estimate has no value to anyone, not even in a rough sense like, "will it take 2 hours or 30 hours." In my experience, a task estimated at 2 hours is equally as likely to take 30 hours as to actually take 2 hours, and there is no systematic way to know which case you're in. Regular check-ins to catch the blocking issues early is much more important, and so teams should not waste time making estimates or tracking velocity. It's pure junk. Instead, start working and meet often to detect blocking issues as you go.
- KKKKkkkk1 8y ago
  Also, in an org that resorts to estimating and enforcing timelines, a task estimated at 30 hours will take 30 hours, even if it requires 2.
  - wallflower 8y ago
    At one of my previous companies, during a death march like project to get a 1.0 out, it was widely known that the offshore team was outright lying about completing their work in the estimated hours (scrum). They routinely worked overtime and sometimes weekends and yet the management pretended everything was hunky dory and on schedule. The non-offshore team looked bad unless we too worked long hours. A mess on both sides. We eventually shipped the release, 9 months late.
- collyw 8y ago
  Agreed, the other thing that gets me is that estimates are often expected to be on the spot decisions. If you have done a task that is similar before then that's fair enough, but no one has ever told me to go off for a day or two and investigate the difficult / unknown parts to see hat the options are.
  - 8y ago
wellpast 8y ago
I’m really disappointed at the responses in this thread. I’m finding as I go into industry more and more that there’s this philistinism amongst programmers. “Quality code can’t be achieved because look...” “Accurately estimating software is impossible because look...” It’s so easy to claim these things. It’s way harder to earn the associated skill sets. We’re taking “programmers should be lazy” to a whole new level where laziness means not practicing, not growing, but instead using “hard to learn” as an excuse and equating “hard to learn” with “generally impossible”.

marmaduke 8y ago

I think there are some less concrete responsibilities. This post assumes all your colleagues give a shit, while some work might get delegated to a colleague who then waits for you to step them through it. How do you motivate people to take responsibility for their work (when firing or changing teams isn’t possible)? I think a senior engineer is also going to be one writing fundamental proofs of concept when time is tight (or at least I have been doing this)

fit2rule 8y ago

I have my own sort of loose rules about this. I long ago came up with it, and it works for me, but maybe there are a few holes worth poking. Basically it goes like this: There are no 'senior'/'middle'/'junior' level developers. There are _A, _B and _C. _A guys sit at the top. _B supports _A. _C support _A and _B, and .. other _C's. _A supports all _B's, all _C's, and of course.. all other _A's. The position is self-determined, i.e. up to the individual. Occasionally, when enough _A's, _B's and _C's serve together, they self-organise. Sometimes, you need to tweak a few things. For example, there is a kind of _A who doesn't want to work on things without a few multiples of _C around to clean up after him. This guy needs a _B. Then there are _B's who ignore _C's and just wanna work with _A's. This guy needs a better _A. And, also, a few _C's. And there are _C's who want to be _A's, while ignoring their duty to _B. This guy needs a few more _A's, and either becomes a _B, or an _A. (Or a _D, which is 'goes and does marketing stuff instead'.) Either way, there is another 'type' of developer, and this guy is an _X. He gets all the _A's and _B's and _C's happily playing together, executing on the plan. He can be an _A or a _B or a _C: he doesn't care, as long as things are executing.

Aeolun 8y ago
Why would you try to argue this point with A,Bs and Cs? Even if you called them monkeys, horses and lions it would have been more understandable. There’s a reason we don’t use these kind of variable names...

amriksohata 8y ago

Totally disagree with the section "What’s not part of the job" Part of any job is stepping up and deputising for your manager, sure if you don't want career progression or want to go into the technical side you could argue they would try and do some of that instead, but if you want to be a senior you have to be a rounded individual that can mentor new starters, help with sprint planning when your boss is not around. Thats part of being a senior, otherwise you are just a good Mid.

UK-Al05 8y ago
I find help with sprint planning something every engineer should do. Sprints are owned by the team not the product owner
- mosselman 8y ago
  People should do what lies within their realm of capabilities. I know enough people who are fine programmers but who lack the overview or sense of connectedness between certain task or the ability to think about the business value of certain tasks in order to make decisions when things start to take too long or become too complex. Those people should not take care of handling the sprint when the person who normally does that is away. So no, not every engineer should take care of the team's planning.
  - UK-Al05 8y ago
    Well in my team sprint planning is a team job. Everybody gets together and plans the next stories. Usually different people have knowledge/interests on different stories, so nearly everyone gets some input. Heck in the scrum guide this is the way it's meant to be. If your engineers can't factor in business value, or work dependencies its usually because people are hoarding knowledge so they dont have the ability to factor that in.
    - mosselman 8y ago
      I didn't say the team as a whole wouldn't be able to contribute. I was saying that not all people are able to take over day to day planning individually. "its usually because people are hoarding knowledge so they dont have the ability to factor that in." That is like saying that everybody who isn't smart, must be good with their hands. Some people are just not good at certain things, no matter how much they are enabled to do those things. Which is completely fine.

fogetti 8y ago

I think what the author described is mostly any engineer's job. You don't need a title for this.

yitchelle 8y ago

In the section where she explicitly mentioned what is not part of her job, I bring two of her points which I disagree with. * Make sure work is allocated in a fair way * Make sure folks are working well together While she is not directly responsible for these two items, she and everyone else on the team should be responsible for alarming their manager/team leader when either of these items are not working. With more eyes and ears monitoring the team, it helps to reduced the risk of bad behaviour disrupting the team's cohesion.

mzanchi 8y ago

It's interesting the author mentioned estimating but said they are not very good at it yet. I have read somewhere else that what distinguishes a senior engineer from a junior engineer is exactly the skill in estimating work.

coldcode 8y ago
No one can estimate worth a damn. With experience you realize how terrible all estimates are — unless you are estimating something you have exactly done before, which is more likely with more experience. Everything I have done in my career was mostly unrelated to anything done previously, so estimating would be as effective as using dice.
collyw 8y ago
As I said in another reply, it really depends. If its a task that I have done before and new code, then I can give a fairly good estimate. If its something new, I have no idea. If it's on a monstrous old codebase, then there are a lot of unknowns to add into that. And most people expect you to do such estimates on the spot.
Aeolun 8y ago
More like senior engineers have learned from experience and just triple any estimate.

srazzaque 8y ago

Good read, I like JE's posts. But I definitely feel like this falls into the trap that a lot of similar posts fall into - attempting to "bullet-point" a role description inevitably will result in people criticising the inclusion or exclusion of individual points. Which is a shame because it detracts from the overall spirit of what's being said. Struggling to find the link now, but I read another post on the subject of seniority, and it basically summarised the crux of it for me. This unravelled everything. Seniority is measured contextually by asking: "to what degree can I leave stuff with this person and expect it to get it done with high quality? Further, to what degree can I NOT leave stuff with this person and _still_ expect that to get done." From this, one can derive their own context-appropriate "check list". In an environment such as finance, where an engineer is absolutely not the expert, can I trust that this person can work with the experts to get to an appropriate solution? In an environment where you have many intermingled teams, will s/he be able to propose solutions and get buy-in across the org? In a consulting/client scenario, can this person represent our company? What might they need help in? In a bootstrapping startup scenario, can I entrust them with the entire build of (some major component)? In different contexts, the above set of questions would unroll a different set of measurements for seniority, and may require a different mix of soft/technical skills. But that's fine, there's no one-size-fits-all seniority ladder.

jkmcf 8y ago
I’d love to read that link. I usually summarize the role as doing what’s necessary to get the job done reasonably, but your point about knowing what to entrust others with is spot on.

mabbo 8y ago

> I put “write code” first because I find it surprisingly easy to accidentally let that take a back seat As a first-year-out-of-school developer, I shadowed an interview once from a "Principle Engineer" at another company. By the end of the interview, we understood two things: 1: He did not code in his job and hadn't in a while. 2: He could not code anymore. This role was for a senior engineer position, where he would need to mentor people on writing software. It was a pretty hard 'no' by the time we did our group follow-up with the other interviewers.

BerislavLopac 8y ago
He probably spent all of his time on developing principles...
dunpeal 8y ago
> As a first-year-out-of-school developer, I shadowed an interview once from a "Principle Engineer" at another company. A lot of people don't realize how easy it is to get impressive titles at very small or low-quality outfits. If it's just you and the CEO running the place, you would be a "CTO" even if you couldn't pass a phone screen for any decent entry-level engineer position. We constantly get resumes from "senior engineers" working for no-name tiny companies and startups. They are often our worst candidates, especially when it comes to hard skills like coding. Reality is that these skills are rare, and no-name outfits will be competing for the rare candidates who can code against all the better employers out there. The results are what you'd expect.
- UK-Al05 8y ago
  Even at large companies this can happen. Architects and high level engineers can simply go out of touch with current engineering practices simply because it's not their job anymore.
  - dunpeal 8y ago
    You know, I heard this claim about "architects" and "high level engineers" before, but I've never seen much evidence for it in real life. How many of these detached astronaut "architects" actually exist? The only real-life example I ever became personally familiar with: academics who were parachuted to some quasi engineering leadership positions thanks to their impressive publication credentials. I wouldn't call these folks "engineers" of any level. They are scientists who head teams that employ engineers.

vkjv 8y ago

> "...review design docs" In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team. But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information. Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.

jiveturkey 8y ago
what ive found works is to /always/ pair a jr with a sr engineer to write any ddoc. 2nd, always assign a specific sr reviewer. only after that review, release the hounds. others that have interest or particular insight can reflect on deficiencies (or, rarely, strengths) without the dread feeling of having to deeply understand the context or underlying dependencies. same reason you don’t just throw a code review out to “everyone”. everyone = no one

rlaanemets 8y ago

I think that setting explicit job boundaries is a good thing to do. Otherwise you end up with role creep and potential burnout. This happened to me. There is a considerable pressure to pick up as many activities at the job as you can as hiring more developers is hard or impossible at some locations as the demand for developers has skyrocketed. This demand buries you even deeper under tasks once your colleagues leave elsewhere for better offers.

deleted 8y ago

[deleted]

visviva 8y ago

What's a senior *software engineer's job?

deleted 8y ago

[deleted]

nojvek 8y ago

Jvns does it again. We need more women like her in the industry. Such an awesome engineer and educator.