What's a senior engineer's job?
jvns.ca
jvns.ca
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.
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.
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
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.
The interests of both parties have serious misalignment.
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.
But the problems that make estimation useless are problems that only surface after detailed digging that takes time and cross-team communication not realistically possible in time-boxed spike tickets, involving happening onto things that were not known and could not be known within a short spike timeframe.
Spike tickets are just an Agile bureaucracy thing to paper over the fact that estimation is intrinsically problematic to some fundamental aspects of one-size-fits-all methodologies like Agile.
Essentially for a spike ticket to be helpful in the common case, you need a spike ticket that just says, “actually go and complete the whole task you’re trying to estimate and then come back and tell us how long it really took.”
Software devs can become very good at estimation if you practice it.
Where 2 hours really is 2 hours—and even a week really is a week.
I know this from experience but it’s pretty basic to see that it’s true. A senior engineer (5+ years, say) is rarely encountering fundamentally novel problems. Most everything we do we’ve done before in some form.
To get good at estimation simply track how long things take. Over (short) time you will see that work is very predicatable and you can be very precise with your estimates.
If you buy this claim that ‘engineering work takes as long as it takes’ of course you won’t take the effort to get good at estimation and of course your lack of the skill will seem to reinforce your belief.
Don’t do that. Estimation is a highly valuable and acquirable skill. Acquire it!
Estimation is normally off because something unexpected happens. Staging environment down, build server is broken. An external dependency takes longer than expected. On a new unfamiliar legacy code base where our previous work estimates no longer apply. Those unexpected problems vary widely in how long they take to resolve.
Yeah, if you estimate on a familiar code base, when everything goes right it's easy. But very rarely is that the case.
In fact I might even _define_ “senior engineer” as someone who has been around long enough to know this and has come up with some way to pacify managers with meaningless estimates in a way that protects the team so it can actually still do work.
The only systems that do have high degrees of accuracy tend to throw out a big chunk of the work to get there (for instance some systems don’t estimate how long a proof of concept will take & only estimate post that).
I’d love to hear what your mechanism is for estimation that is repeatedly accurate & how to implement it at scale because otherwise it’s an open problem in the industry.
What references are you referring to?
I more or less gave the pattern — track your hours. I’ve been around the block...from large FANG companies to small startups across many varied tech stacks. Estimating an API design and impl in Java vs Python vs... Estimating impl a UI library in React vs some other server-side MVC framework... We are not inventing new bleeding edge academic paradigms — our work is estimatable.
If someone wants to pay me to teach the skill, sure...
But I can guarantee you you can estimate software efforts with accuracy.
https://www.computing.dcu.ie/~renaat/ca421/LWu1.html
The SEI recognizing the weaknesses of expert judgement estimates has layered on QUELCE which applies Monte Carlo simulations to the estimates:
https://www.sei.cmu.edu/research-capabilities/all-work/displ...
Note that QUELCE is an ongoing research methodology without a lot of data available about its effectiveness. But it says something that this is a very active research area in 2018. If it were a solved problem I’d not think Monte Carlo distributions would be valuable.
When it takes much longer, it's almost always due to design issues or political issues that create design issues. When the design is well-understood(and prototyping is hugely important to finishing design ASAP) the implementation goes smoothly. When stakeholders take turns stirring the pot to "make their mark", it goes haywire very quickly.
I agree that hunting bugs is very difficult to time-estimate correctly: it could be either a simple overflow bug that it only takes a dozen of lines to be fixed or it could be an architectural problem not spotted before that needs some serious evaluation before taking action.
But a development task should be predictable to estimate to some extent. An architectural analysis should reveal the parts of the system that need to be modified and it it takes more than 2 weeks, maybe the problem should be partitioned into smaller problems easier to estimate.
It’s so rare to have tasks without these blockers that estimation generally is unhelpful. Whereas measurement (beginning work and alerting people to blockers) is much more useful.
Anecdotally what happens when you do the breaking down into smaller tasks thing you are either just putting off giving the broader estimate (in systems that only estimate the currently workable tasks) or you are likely missing small tasks from your broader goal that will impact your estimate later leading to standard estimate overruns.
If a junior engineer gives some hand-wavy estimate of a project, I always ask them to sit down for 30 minutes and break the project down into bite-sized concrete tasks. "Bite-sized" means they need to estimate the tasks at some level. This usually uncovers some unexpected ambiguity or open questions which we can work to resolve. At that point we can also search for long poles, parallelizable work, unnecessary work, conceptual misunderstandings, etc., and it makes it easier for other engineers to swarm if the project starts slipping too much.
The other failure mode, where the team spends time discussing every ticket, wasting N people’s time when only 1 or 2 people have the expertise on that topic to debate the estimate, is way worse. It wastes more time, makes people act petty about who is doing more fictitious Fibonacci units of work, bikeshed over meaningless things like if a ticket is a 3 or a 5, and can make work scoping way more antagonistic than it needs to be.
That said, I've always been able to provide fairly good estimates for how long work will take, something that I got a reputation for doing well.
In my experience, that's not really true; I find value in time estimation to come from actually scoping the work again and probing for traps or pieces of complexity that weren't obvious in the first estimation passes. It's not true that software takes as long as it takes. Software projects expand to fill the amount of time allotted. Holding yourself to deadlines creates room for compromises and creativity.
In other words, when it turns out the estimate was too optimistic one can either:
- allocate more resources to the problem,
- make compromises about quality of work,
- miss deadline or
- adjust scope.
The first solution is rarely possible (or doesn't help because new hires take time to be productive), the second has unwanted side effects, so the last two are the best options... Pick your poison I guess.
- (2) Compromising does not always compromise quality of work. You can always cut scope as you mention in (4) and ship less features at a higher level of quality. Although what I was getting at was more that we have a tendency when given time to go about refactoring and rearchitecting things that don't necessarily need to be done, or introducing unnecessary / premature abstractions and optimizations. Deadlines tend to curb instinct to do that.
- (3) You can miss deadlines, but that's not a clean win either. It hurts morale, allows for feature-creep (oh you're not shipping next week, well boy do I have some extra things you could do with your newfound time) and hurts relationships with teams depending on what you're setting out to deliver all across the company.
- (4) Adjusting scope can make sense, so long as you're very good at figuring out what doesn't need to go out. Not every team is.
tl;dr: Shipping the right 70% of the feature set at 100% quality without premature / unnecessary optimizations and abstractions can be pushed along by aggressive timelines. This must always be balanced with sustainability.
It looks like a few people have reached somewhat similar conclusions and create frameworks around this idea (Agile, Extreme, TDD etc.) to formalize the processes. But it perhaps makes sense to realize that they are just that: processes and heuristics trying to make a hard problem (delivering software predictably on schedule) more manageable.
Anyone who can say this has the privilege of being fully insulated from revenue generation. But at some level of the company, resourcing decisions are made, and they depend on understanding the costs and benefits of various tasks. If you are deciding between having your engineering team build an Android app and adding an API integration, you need to understand how much revenue it will bring you and how much it will cost, and that’s where estimation comes into play.
Man months are very non mythical when it comes time to write paychecks.
You are incorrect. I work in a directly client-facing capacity and often have phone calls to help our actual clients and their product managers, and I have many internal stakeholders for my team’s work that are sales-facing and client-facing. Most of the quarterly planning meetings I am required to give input into are directly focused on revenue generation.
Because software velocity estimates do not have any correlation to the actual delivery timeline, yet they will be used for political bikeshedding by people who don’t know about the technival details, it is exactly in revenue critical situations that you want to get rid of the pretense of estimation and admit the truth that you have to simply measure by doing and frequently reporting blockers.
It can cause bang-simple engineering tasks to take weeks, during which time you never know how much longer you’ll need to wait, and depending on political capital of the entity blocking you, you may not even be allowed to publicly explain they are blocking you, and you are forced to absorb the negative externalities of their choice to block you.
Even though it would be incredibly useful to have, it is effectively impossible to give an accurate value other than for trivial or massively constrained problems.
Estimation is NOT commitment. Committing to estimates paves your road with good intentions (and leads to hell). Don't commit to estimates!!
Estimation is EXTREMELY valuable to help the business get a sense of engineering capacity. You can't tell the business, "we can't launch a Facebook competitor in a week of effort." No shit, Sherlock. So what can engineering work on next? What can the business ask engineering to prioritize, that's chopped up into a small enough piece that it can work it's way through development and into production in a more or less predictable manner, while still being large enough to have demonstrable business value?
Orgs that can't produce reliable software estimates suffer from one of the following: unreliable infrastructure (can't deliver new builds if your build system is down), insurmountable technical debt (can't reliably and quickly roll out requested changes if you don't have automated integration testing), bus factor 1 (look who decided would be a great week to be in a car accident! /sarcasm), lack of senior technical leadership involved in planning / chopping up tasks.
I hate to break it to people, but those are all pretty much fixable. You can have highly-available tooling. You can have competent technical leadership that balances technical debt and creates clear task work for engineers. You can have team leadership that prioritizes getting information out of team member heads and into source code or wiki (when appropriate), and cross-training. The fact that most organizations fail at best practice does not mean that best practice is inaccessible.
Also, with these types of estimates, they are basically misleading without some form of error bars, yet nobody ever incorporates that into it. Capacity is not some number, but a whole distribution of possible numbers, for which the mean might not be a relevant value (for example if it has several sharp modes that depend on discrete external events).
This is truly an amazing statement to make, especially from a senior engineer. Without a clear estimate and communicating that estimate to those who relies on your output, how can the others plan their activities, or how can you plan your activities without knowing how the others will take?
If other people makes plans based off of junk (read: any) estimates, it just amplifies the problems.
If you’re at least honest that the estimates are meaningless, everyone can acknowledge it and come up with different solutions, especially regarding speeding up the process to get started and make checking in about blockers more meaningful and consistent.
Only so long as you're developing your software in complete isolation from anyone else.
In terms of possibility, if you're not doing moonshot R&D then you should be able to give a reasonably bounded estimate (which occasionally will be wrong, but c'est la vie) of how long it will take to fix an issue or implement a feature. If you can't do that then IMO you aren't a senior engineer.
“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”.
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.
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.
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.
It is not necessarily that the architects don’t know how to code but more lack of opportunities to do so, as they increasingly become a human API between the engineering team and management and execs. Meetings all day, some of them of low value.
Right, that's not an "architect" then. That's a manager of some sort.
That's funny because I remember not too long ago about complaints regarding Senior Engineers at BigCorp that got too comfy and also couldn't code. It seems the walls are closing in.
It's a good anecdote that titles are bullshit in our particular field. It's also why I've opted to remove 'Senior' from my titles for external resumes to avoid people making judgments too soon.
I wouldn't go quite so far. The fact that titles don't mean much in sub-par outfits doesn't contradict the fact they can mean a lot in solid companies.
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.
So no, not every engineer should take care of the team's planning.
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.
"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.
With that renaming, the two lists in the post more accurately describe my recent positions as senior/staff engineer than anything else I've read, so I have to say I very much agree.
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.
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.
* 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.
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)
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.
same reason you don’t just throw a code review out to “everyone”. everyone = no one
And most people expect you to do such estimates on the spot.
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.