6 ms·

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 est

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”.

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”.