Visit [1] for a full list (table view gives a lot of options. See "Controls"). Visit [2] for a summary. The source of the list is at [3]
1. https://littleblah.com/post/2019-09-01-senior-engineer-checklist/
2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-engineers-checklist-c8e9f9f6e3c2
3. https://github.com/littleblah/senior-engineer-checklist
Feedbacks/Pull requests solicited :)
Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then on Wednesday you can solve the architecture problem.
And that's pretty much this list summed up. It's nice on paper, and maybe it will make a difference if someone consults it when making tough decisions. Thanks for your effort.
I'm not part of the hiring process at our place but from what I've tried to contribute as a potential technical test, I get told it's too hard... It's really really not hard at all. But from what I can tell if you ask them to code, even in their own time or in the interview, that's unfair and stressful and you aren't seeing them at their best. So you ask questions instead of asking them to code, but then developers don't remember stuff they can just google nowadays. Again, you are being unfair and it's too hard for them!
We really seem to have allowed the infantalization of our industry, it's very depressing. Maybe the answer is just reject anyone under 35?
Once we become experts (relatively) at something it becomes very difficult to judge "easy" and "hard" things. I suspect we have rose tinted glasses about our prior selves and their ability. Plus, the people we are testing are not our prior selves and have a totally different set of experiences they draw from.
You're comment feel very much so "back in my day" which I am almost certain is a logical fallacy.
I think even a simple fizz-buzz can be a good litmus test. "I see here that you put JavaScript on your resume - good, we need that here. Let's open a console window in Chrome and do FizzBuzz". I've honestly gotten blank stares - developers who don't even know where to start.
[Edit: Spelling]
"Make everything as simple as possible but no simpler." All well and good if your requirements are written in formal logic or if there is only a single axis along which complexity can be measured.
"Hire only the best." What if the best only want to work with the best pay and the most interesting work? But "hire only the best of the very few who are willing to work on your projects for the kind of pay you're willing to offer, who will consider it a blessing that they were hired at 20% above your minimum starting salary with no other career avenues than management, and who are naive enough to think of options as valuable rather than lottery tickets" isn't quite as snappy or happy.
"Don't be evil." And since you have that slogan anything you do is by circular logic not evil. Handy.
Yes, this is the right question. I think the reason there is no generic definition is because it's subjective. The most generally applicable part of this is the differences in hiring practices at large-scale vs tiny-scale (there was an article on HN previously explaining this particular area):
The main points were google-scale can afford high salaries and can afford to cut out good candidates from the hiring process in the name of automation, so easy to automate and standardise empirical testing works for them, but not for small-scale, because you wont be able to afford the same candidate. Instead small-scale either hire for the people who fall through the cracks of large corporate structures or they hire for potential.
In answer to your question, this difference affects (or should affect) the qualities being measured... for large scale it's whatever the job requirements are, measured there and then; for small-scale it's the potential for whatever the job requirements are e.g enthusiasm, drive, domain specific interest. That's just one dimension of a company, there are all kinds of other aspects that will also affect qualitative measurement of a candidate.
But we also had some one who was even more of a GURU IBM used to ask him for advice on large Mainframe database problems.
I've certainly worked in places where they'd rather I didn't get involved in the hiring process. These kind of places often heavily relied on external recruitment, and would rather that I spend my time working on projects than potentially rejecting candidates that could do the job, but weren't up to my standard.
These aren't non-tech companies either - these are companies that deal in/sell tech as a project and/or service. Even in companies that live and die by their development team, non-technical management can run the show and dictate hiring.
PRevious place I worked had probably a hundred senior developers and none of them had any involvement in hiring.
IME the only developers that get involved in hiring is architect level and Lead Developers.
> Respect code and systems that came before you. There are reasons for every code and every guard that exists in production
Sometimes there's bad code in prod, or code that doesn't need to exist anymore. You should try to understand when something is there for a good reason versus a bad reason. Cut out the bad code, keep the good code.
I've seen a lot of cases where people assume that current code is untouchable or designed very intentionally, so they wrap it and then you end up with a tower of abstractions built on a poor base.
So, I think as a senior engineer you should try to understand the difference between code that should stay and code that should go.
Took over a system in Aug '18 with someone else. Previous 'senior engineer' had left after a year to go be a CTO someplace else. Everything seemed wrong - bad smells everywhere, spidey-sense a-tinging every day.
In October, we found that code put in place had been losing data since April - we had 6 months of pure data loss. Data that people assumed was 'working' because ... they hit a button and looked at the screen, and it was there. HOWEVER... after the midnight job run, the data was gone. No one ever looked the next day. Until October, and then it was way too late.
The whole "respect the existing code" has a HUGE assumption in it - that things are actually WORKING CORRECTLY in the first place. It also often assumes some of the original people who wrote the code you're dealing with are still on the team and and to answer questions.
THAT particular project above - my gut was "rebuild" - and we didn't. 16 months later, we are still finding code that is simply broken - data is lost, things are breaking, etc. But the whole "well, you're just someone coming in new - all devs just want to start from scratch and you shouldn't do that!" reared its head, and that idea was pushed aside.
I'd turn it around. Someone needs to be able to demonstrate - usually via automated tests I'd think - that things are, in fact, working as expected/assumed. If not, study/understand, then feel free to rebuild/throwaway.
I've taken part in another project with hundreds/thousands of tests, and while I hit code that looks/smells weird sometimes, some of the original people are on the team still, answer questions about 'why', and the tests pass. Even though it sometimes looks 'bad', it's functional and we can demonstrate its functional and working.
This is a HUGE difference, and that assumption about "it's working correctly right now" shouldn't be taken for granted.
I have seen people proclaiming a rewrite with a newer technology would be a good idea who didn't have the slightest clue about the system they were trying to replace (except that it was build with some outdated technology) and I am 85% sure, that their rewrite would have been worse. When I confronted them with my claims, they gave up quickly.
As a Senior Engineer, you should know what you are doing. If you see obviously bad code, thinking about a rewrite is no sin. Just try to understand what caused the current system to look like it does.
Let's say I'm a manager at said company. An engineer who just joined my project - which our previous senior engineer, who I trust (fairly or not), built - tells me it needs a complete rewrite. My default reaction is likely skepticism: the received wisdom is that rewrites are seldom justified; your assertion contradicts both this wisdom and my previous senior engineer. What do you expect my answer will be?
As the engineer making this recommendation, you'll need to do a bit of showing why. Part of this is technical: write some tests that show the problem, quantify the data loss, etc. Show that you've carefully balanced rewrite vs. other more incremental approaches to fixing the problem. Prototype part of a newer system quickly and show that it can be done.
The harder part to motivate - and often the more important part when it comes to "how do I get people to say yes?" - is non-technical. What's the business impact? What's the user impact? Is this an existential risk to the company if not fixed? How so? How do we assure our clients / users / etc. that time spent here is more important than time spent on features they want? Can you get someone with significant decision-making power to agree? How will you de-risk the rewrite and eventual migration, neither of which are trivial? How can you get just enough buy-in to secure the time needed to answer these questions, show quick progress, and reassure others that this won't be an even bigger catastrophe?
Don't just trash it, learn it, understand it, talk about why it could be improved - people write crap code for many different reasons.
Do replace it but do it with valid reasons and without being horrible.
People also tend to forget human and business impact. The code might look different if there is 1 week or 4 weeks given for implementation. Timelines, pressure from management/stakeholders to deliver faster has impact to made solutions and implementations.
That is when respect is needed - having empathy to understand why this part of software looks like it is now.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
I think that’s exactly what the rule is saying, I think almost everyone would agree. The problem is assuming that code is bad, or even actively looking for “bad”. If it’s in prod, that usually means it worked and was needed. Engineers in my experience do like to assume things are bad and actively look for reasons to re-engineer things without properly accounting for the number of ways things are going right. During my career, I’ve watched two separate large teams at two separate companies decide to rewrite a major codebase because they thought there was too much bad, and they thought there was a tower of abstraction. The result was they both dramatically underestimated the time needed to rewrite, and after having wasted literally tens of millions of dollars, ended up with roughly the same code quality as before and a couple of years of unnecessary down time. It’s more difficult to understand the code that came before and the reasons why it’s there, and it’s easier to judge it bad and decide to rewrite it without completely understanding it, that’s why the default should be to assume the code is there for a good reason, and try harder to understand the reasons.
That rule should, of course, be balanced with this rule, both are true:
> Simplify code, systems, and architectures relentlessly
I personally suspect that writing down and maintaining all the requirements and lifetimes for the codebase separately from the codebase, and having a regression test suite with complete coverage, is the way to safely deprecate features and continue to simply old large complicated codebases. But I’ve never seen that work in practice, yet...
> There are reasons for every code and every guard that exists in production.
Sometimes the reasons are not good ones. Maybe that's exactly what the author meant. The rule doesn't read like that to me, though.
And yeah, if you're rewriting something, don't rewrite the whole damn thing! Good code is modular and you should be able to pick it apart and replace components that are causing problems. If it's not causing a problem, don't rewrite it...
However if you're going to be adding features to a section of code (or otherwise working on it a lot), it's a good time to try to understand if you can do a bit of refactoring along the way to clean it up. By default, all code gains code smell over time and also becomes more robust. It's a tight rope to walk.
Replacing something simply because its not code you authorised or written isn't respectful. Replacing something because its not on a shiny platform, took too long to figure out, or simila, again isn't respectful.
replacing broken code, fixing bugs, changing architecture to adapt to another situation is fine.
How about ethics? company reputation? legal compliance? corporate responsibility?
...that's about it.
Delivery and ridesharing apps have algorithms that are almost indifferent from tip skimming. Many people working on those platforms live in financial hardship.
In an east asian country, people live under constant surveillance: physical (cameras, face detection), financial, and online activity. If you criticize the government you lose access to everything: payments, transport, credit, job, etc.
If you were paid a lot of money, would you implement those "solutions"?
That is the importance of ethics.
I worked at a company where the the work I was assigned was undermining my career to the point that if I didn't do something on the side, I wouldn't be able to pass an interview.
So while the business aspect is important, it is not the only thing that matters; it never is.
Balancing strategy and tactics is something you do as you become senior. Pumping tech debt is a tactic, good practices are a strategy.
The guidelines say that we should respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.
The following quote could easily be interpreted as viewing software engineering as a subcategory of engineering:
> most of the items on this list seem broadly applicable to different types of engineers
Given that interpretation, it seems more like they expected an article like this to be about software-specific concepts.
OP is just happy that this can be applied more generally.
In my opinion, engineer is just a term for people who solve practical problems. Which is a huge community of people these days.
I work with many kinds of engineers, every day, from electrical to mechanical, and I do not find their way of working any more advanced than what I have become used to from disciplines of Software Engineering.
I look at some of their math and think magic. They look at my code and think magic. However, anything else seems pretty much the same. We do iterative development, they do iterative development, although less sophisticated and with much longer feedback loops, so they have higher incentives to get designs right the first time - but that does not mean that they always do!
And it was, thus they were pleasantly surprised.
If you work for a small startup (where you'll be forced to be "senior engineer" if you like it or not), you'll have no "manager", "peers", "projects", "hiring", "mentoring", "networking", and so 95% of the list items immediately pop.
peers = peers
projects = you’d have at least one (and smaller additions to the product that could be projects in their own) hiring = you could be involved in the hiring process even though probably the CTO will handle it
mentoring = you can mentor others or get nentored by e.g the CTO
... etc
so where is that 95%?
Further to this point, networking is crucial too, but it's more networking outside the company. With other startups, with other technical folks -- your hiring pipeline is built on your personal network until you get to at least 20+.
• Question everything and ask “why” repetitively until you get to the root of problems and situations.
• Do not be adamant about your views. Listen to others and accept that there is more than one way to look at a problem statement, and multiple valid solutions to a problem.
• Have strong mentors to help you navigate and grow in the company.
• Read a few technical books every year.
• Actively seek feedback from your manager
The bullets above brings me to halfway through the list, and I feel that I was pretty selective in the ones that I chose. At this point for the remainder of the list nearly every item is one that I'd suggest for any experience level.
Always be ready to review any opinion you have in the face of new evidence. In fact, seek out information that will challenge your opinions. But until the burden of evidence favours another opinion over yours, be prepared to hold and defend your opinions stridently.
It might seem obvious, but this part is extremely important and can be very difficult to live by because it encourages (healthy) disagreement and conflict. "Strong opinions, weakly held" is explicitly _not_ about giving in to a majority opinion or because the opinion is coming from a position of higher authority. It's essentially the scientific method. It does not mean you should agree with other peoples' opinions just because they said it louder and/or more often than you did.
I've witnessed senior engineers and managers misunderstand this mantra and (mis)use it to punish ICs who disagreed with ideas of other more/tenured engineers but lacked evidence for being "better".
If you intend to use this framework as a value in your organisation, make sure you and everybody else understand what it means (_especially_ your engineering managers).
Sometimes that mentor is you. It's good to know if that is explicitly expected of you in your role, because you will need to budget time to do it properly. It is an extremely important role for any team, so take it seriously too.
For project managers/employers reading, it is paramount that you make mentorship be part of the senior developer's roles. As your company grows, you will be churning through employees as new hires and as people leave. It is very easy to not notice that you just lost all of your domain knowledge because you thought everyone was on the same page, but actually you had your senior developers too busy to effectively spread the tribal domain knowledge.
Documentation is great, but there is nuance and depth to complex software decisions that can't be captured in text in a reasonable amount of time. Not only that, but you probably have less documentation than you think you do, no matter how much you asked for it. People don't read it either. They will sooner google a problem, or ask a colleague.
Some developers absolutely do not like the role because of the regular interruptions, I get it, but some people are more than happy to help be a go-to. It remains the favorite part of my job. Make it a question in your interview process so that you can make sure you have someone who is going to be happy making sure your domain knowledge is shared throughout the company.
I would happy to do it if management acknowledges that managing people as a senior dev will take time away from doing actual coding work.
But somehow, they think you can manage to pull off doing deep coding work and managing people at the same time. This refusal to adjust expectations is just baffling to me.
Here's my thoughts on a few of the items themselves:
"Follow the principles of extreme ownership." -- Unless the term "extreme ownership" describes something specific (like "Extreme Programming"), it should be reworded to clarify. What are these principles or what is 'extreme ownership'? Is it clearer to say "make sure you take ownership"? Or "don't waste time working on things outside of your domain"? Or "don't limit your focus to just those items explicitly owned by you"? The latter is approaching XP's "collective code ownership" / "shared code."
"Be reachable to other engineers" -- is this like making sure you're available? Like "check into the company Slack channel frequently"? "Make sure you reply-all to that 11pm email so everyone knows you were checking your email then?" Sorry: that sounds a bit cynical but it's easy to misread this principle that way. Best reword this one IMO.
"Avoid stretching yourself too thin to be effective" - this is a great tip but is it specific enough to be useful? How will I know when I've done this? I think I know the answer but would a junior engineer reading this list know?
"When dealing with politics, avoid it, but have right folks vouch for your work" -- this one is not specific enough for me. "Avoid politics"? Who are the "right folks" -- how would I know whether I had asked the right folks to vouch for the work?
"If you are under-utilized, ask your manager for areas to explore" -- IMO this works better if you can specifically say "I want to work on X" and bonus points if "X" is an item that you know contributes directly to high level goals for the company.
It is very difficult to avoid politics unless you operate in a total isolation. Every time I need to talk, to get consensus, to request, politics is involve. It gets much more difficult when folks are not in agreement with what you want to do.
I will revisit this list in some time, and make changes based on feedback. If you can, feel free to contribute through the shared github link.
I have never had a job where my one on ones didn't devolve into status meetings and chitchat. What the hell am I supposed to talk about?
https://randsinrepose.com/archives/the-update-the-vent-and-t...
But i think the point of one-on-ones is to have some reserved time and space to discuss important things should you ever need to. If that need hasn't arisen yet, and you end up chitchatting and talking about the current project, that's great - that means you haven't had a crisis!
https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-...
Haven't tried it yet, but might help you to change your one-on-ones.
tl;dr: s/"Avoid politics, but have right folks vouch for your work"/"Become an adept politician".
I would say tactical negotiation and leveraging personal connect is healthy, but manipulation for personal gains at the cost of a larger good is what is my definition of "politics".
I have seen couple of managers in my career who, while were poor managers based on employee voice surveys in the company, ended up with large charters due to being good at politics/"rubbing backs". I want to say that end result was they screwed it up since their directs ended up leaving their team, but in reality, they thrived despite losing folks and not delivering projects, again due to politics. As an engineer, I failed to appreciate that.
Now, if you're a good politician with the best interests of the company at heart and the technical skills to deliver, the math is different, and the sky's the limit for you :)
I think that's an unhelpful definition; one should avoid conflating the activity with a particular goal. Politics is governance and decision-making, and how to convince people to support your position; whether that's performed for personal gain, or for the good of the company, or for the good of society (and the three are not mutually exclusive), is another thing.
This means developing empathy for other sides of the business, building up favours from other teams, forging alliances, listening, gathering intelligence and spotting trends.
at some point, you _will_ have to make hard decisions, your budget will be cut, project killed, etc, etc. If you are a skilled "work politician" you may be able to negate some, or all of the bad effects.
There is little description or context to this, so I'm not sure what I'm looking at here.
Apologies for being dense!
1. https://littleblah.com/post/2019-09-01-senior-engineer-check...
2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-e...
I have a couple questions with your notes about politics.
Could you expand on what you mean when you say "fall back to first principals"?
"If politics thrives due to team of company culture, switch" Could you expand on this if possible?
'Checklist' made me think of something a little more task-focused, e.g. checklist for reviewing code, checklist for designing systems, checklist for deployment etc.
So... I love the content, but I'd change the terminology.
This is my biggest pet peeve with junior developers. I find there's a total lack of ownership about making sure the feature is completely wrapped-up (not just the code, but the tests, the metrics, that it's shipped, that it's correctly marked as done and communicated, etc.)
I find they /expect/ that someone else at the company will review and make sure everything is done and safe, rather than be proactive about it.
It's why chefs-in-training at elite restaurants chop vegetables, mop floors and perform other menial task for an uncanny amount of time before proceeding to other things.
It's OK for junior folks to not see the big picture. I'd be FAR more concerned about heavily silo'd senior engineers only focusing on one thing.
Why json and not csv? Strictier parsing by javascript.
I would consider this list to be a little over-engineered
As above, visit [1] for the end-user version and [2] for the repository.
1. http://htmlpreview.github.io/?https://github.com/dpmm99/deve...
from link #3 thats coded has high effort, shouldn't that really be a medium or even low? It should be easy to figure out how projects impact the bottom line at the senior level. In fact, i would argue a senior engineer ought to be looking at some monthly sales figures every so often.
