Assuming technical competency is given, I think senior engineer really needs to do two things well:
1. Be able to make a design decision - among multiple options and with incomplete data and uncertainties, a senior engineer needs to be able to make a decision and be accountable for it in order to move the project forward. I think a good interview question would be to ask about their difficult design decisions.
2. Be able to identify wrong solution (most of the time) - maybe this comes with technical competency but a lot of resource is wasted chasing solutions that with the benefit of experience, should have been evident early on.
Disagree. A senior engineer should make evidence based decisions, as should any engineer. If there's missing evidence for a conclusion, then a senior engineer should be able to design experiments which gather more evidence to derive a conclusion.
That sounds great, but hard decisions are hard because there isn't time, money, other resources to have all the facts, yet a decision must be made. There might not even be any way to know for sure without taking one path. Experience is all we have to guide us. Progress is full of such decisions, made in a gray fog. Fear of being wrong is paralyzing.
Exactly. My favorite metaphor for SW-development is playing chess. When you make a move, a decision, new choices, new decisions to make, open up and other ones may no longer be practical.
What you decide and do now, affects what you can and must decide next.
Except unlike in chess we don't really have the exact rules of the game anywhere. Still we must make choices which affect what moves can be chosen later.
It is also like building a house, once you decide how to build the ground-floor and what it stands on, that greatly affects how the floors above that can be built (not too heavy, not too light etc.).
It is often difficult to understand all the consequences of a design decision, what can be done and chosen after that, until you actually implement that design.
It happens all the time of course. But I wonder if it is a bit of a trivial concept. Of course what was done before will affect what is the optimal choice now.
But I agree it is good to keep it in mind -- when you are making the current decisions. If I decide this way now, what is the cost of my available options in the future? Pretty much the way chess-players evaluate their possible moves.
> That sounds great, but hard decisions are hard because there isn't time, money, other resources to have all the facts, yet a decision must be made.
While I am sympathetic to the concept of reasoning under uncertainty, the way you've framed it is hardly engineering anymore.
Design projects come with a spectrum of data requirements, and each has its own cost function for improved accuracy. For example, knowing exactly how long the bridge you need to build matters greatly, and the cost of surveying should be pretty low. In contrast, measuring the soil at the site you build on top of has a variety[1] of options with varying costs. You can't ever be 100 percent certain that your sampling was good enough, but the samples more you have the more confident you can be. Depending on the project and design, you may not need the most expensive and most accurate option, but you probably don't want to just rely on priors built through "experience."
Translating this to the world of software, we have a variety of data collection strategies. A/B tests, canaries, software instrumentation, tracing, offsite monitoring, f-scores, beta tests, market surveys, and more. The best thing you can do as an engineer making an uninformed choice is to design the system to collect the data you are missing and to make it easy to change your design later. Amazon calls these "two way doors" versus "one way doors"; if your decision was wrong you can go back and make a different choice. As an example, if you are designing a caching system, spending a bit of time to generalize the API will allow you to swap between policies as you collect data about cache hit rates. If you don't, the cost of changing your mind goes up as more things depend on the nuances of your API.
Rather valorize making uninformed decisions, I'd prefer to valorize flexibility and continuous data collection. Seen this way, the old adage "There's never enough time to do it right, but always plenty of time to do it over" is a coherent philosophy.
If you have to make decision, and lack information, time and money to even try something to understand the best decision, you are having problems bigger than technical ones; and even the best engineer in the world will probably not do better than a dice
> A senior engineer should make evidence based decisions, as should any engineer.
... sooo there is no distinction between a senior engineer and a non-senior engineer? you've really said nothing in this comment.
senior engineers have seen enough things to know what the right solution is in many cases, without having to take a bunch of time to collect evidence. that's what makes them senior, not just 'good'.
> seen enough things to know what the right solution is in many cases
When dealing with uncertainty (nearly always) it's generally easier to identify and rule out what 'wrong' solutions are. There are often multiple obviously 'wrong' options (no, we should not keep a user's password in plaintext, even if the goal is to make it easy to recover a lost password), but picking a 'right' one... from a whittled down list, it may often come down to familiarity or convention rather than an arbitrary "this is the only 100% correct solution".
1. Identify every project dimension with risks. The big one: project -> use -> user -> reward -> costumer fit? (Where user and customer may, or may not be the same.)
Price cost economics? Technical complexity? Technical experience shortfalls? Project resource availability? Solution resource efficiency? Safety? Third party dependencies?
2. Identify each significant risk in each risk dimension.
3. Identify the simplest question (or two) whose answer will reduce or eliminate each risk.
4. If a risk can’t be mitigated by answering a single question (or two), maybe it is really a combination of risks, or risk dimensions. If so break them out, repeat.
4. Craft the simplest research task to resolve each risk question.
—
This sequence is a special case of focusing energy on upstream tasks, before investing in downstream tasks.
Or as I like to say: move slow to move fast.
—
A meta risk is loops in risk/work dependencies.
Classic example: Stakeholder wants to see something working before you resolve risks of getting something working.
Identify the simplest, sparsest form of a loop is one way forward.
Alternatively, break the loop. Identify alternate ways to satisfy the stakeholder. Find a way to remove dependency on the stake holder (constructively).
I can kind of agree with your sentiment. We should run experiments, regardless of our skill level. We should, in fact, regard anything we do as an experiment. Very few decisions in the real world are irreversible. Doing experiments doesn't mean there's no skill to it. The Senior engineer will know what hypothesis is most likely to prove true, and will start with a system design that will work out well assuming that hypothesis to be true.
This is what the previous commenter referred to as "making a decision without all the evidence". If the senior engineer turns out to be right, and the hypothesis proves true, the experiment becomes the system. If the hypothesis turns out false, the system might still be workable, otherwise it's refactored into some new experiment.
The senior engineer is better at making that initial guess as the correctness of a hypothesis. Just like a senior scientist.
There’s always going to be missing evidence. Almost all business decisions can be made without 100% certainty. Make your conclusion with what you have available and find out if that’s good enough. Don’t dawdle trying to get more info that’s probably not needed.
Philosophically I agree, but in my experience the company isn't willing to pay for experiments except in Production due to scaling issues and quality of synthetic data.
So you need to instead have a series of features that are architecturally solid, have KPIs to measure success, and be willing to throw out working production code that doesn't move metrics enough to warrant their complexity.
From what I can tell, that is the only good predictor we have. See Tversky's work with the IDF or the available CTA methods for studying expertise, e.g. CDM.
Compared to what? Leetcode questions? I'd say an in depth discussion about past projects is the only way to know if someone will be a valuable future member of any team.
Compared to just having a conversation and being a good reader of people. Not everybody can do that, as not everybody is a good programmer, or designer or whatever. No silver bullet, also for recruiters.
It's the same as the problem of finding a good cleaner. If someone is responsible, thorough, turns up on time, has attention to detail, can handle delicate objects, is trustworthy around children and has good manners - then that person is already too good to be an ordinary cleaner and will get hired elsewhere, become a manager or a business owner.
I don't think the world permits so easy mobility. I have worked with cleaners who ticked all those boxes, they were still stuck in their job. Meanwhile not all managers tick those boxes.
I’ve had the good fortune to hire and work with a lot of ambitious engineers.
One trap with lists like this is that it can be easy to lose sight of your core workload. On more than one occasion I’ve had to ask senior engineers to pump the brakes on all of their mentoring, leading, organizing, example-setting, and helping activities because their own work was not getting done.
You only have so many hours in a work week. Get your priority work done first, then layer in additional activities selectively. Don’t think you need to be doing all of these things on the list all of the time.
Then maybe that person has implicitly become a manager.
And to mentor and help others may very well be the best spent time for the company as a whole. But then his biggest tasks should be done by one of his more junior team-members.
This is why most software companies tend to ship buggy messes that need to be constantly patched and updated. Software engineers never get to fully focus on optimizing software for the long term because as they gain experience within the org. they are moved away from engineering into management of other engineers.
I think I get the motivation, an engineer managing a team of engineers can achieve "more" in less time. However I put "more" in quotes because a single expert engineer can build better, faster, and more reliable than an entire team, once they have mastered the systems and tools. That will never happen if they rarely touch code and instead attend meetings to talk about planning and scheduling.
The promotion incentives at least in the bigger companies generally do not favor becoming a domain expert in the product. Everyone wants to become "staff+" and rake in the big bucks, and it's a race to build an empire at the cost of getting things done many times.
Right, it's better for business if people can multiply their productivity... which is arguably the reason computers were invented. If only someone could dedicate themselves to unlocking this power, maybe by studying how it works... but seriously, software engineers can in theory automate anything software related. It just doesn't happen because of how things are structured in an organization, where non-technical tasks are often valued more than technical tasks. Also "growth" seems to imply more people, which I can see how this would incentivize solving problems by adding more people rather than more software.
If someone disregards his or her tasks without communication to his or her superior, and fails to get the tasks he or she was hired for done, a promotion is hardly the right answer in my opinion.
Really digging the list, especially the emphasis on simplicity in systems. Reminds me of that age-old principle: "What is the simplest thing that could possibly work?" I've been on teams where we battled convoluted systems. Sometimes a refactor, even a daunting one, clears so much technical debt and revitalizes the team.
The 'ask "why"' bit? Gold. It's not just about coding but understanding the bigger picture. Feedback loops in software? Amazing. Feedback in career growth? Equally crucial.
It's a solid reminder that our game isn't just code; it's the soft skills too. They can seriously make or break your trajectory. But as always, while guides are great, everyone's path in tech is unique. It's like code; it evolves, iterates, and adapts.
I agree with the list and there is nothing wrong with it.
Though, I would like to emphasize this is clearly an Individual Contributor kind of a perspective. There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow. Maybe a handful out of the 60 fall into this bucket.
Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds).
> There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow.
Well the title is literally about being a “Senior Engineer”, not a manager. That said, there are numerous bullet points about mentoring others, leading by example, and setting work culture. Number 18 is “Be a mentor to a couple of junior engineers.”
> Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds).
While you’re not wrong, I don't think anyone should expect a checklist titled “Senior Engineer’s Checklist” to cater to management items. A manager’s checklist would subtract a lot of the IC items from this list.
Management isn’t a superset of IC work. It’s a different job.
I... what do you you see as your job as a manager? Your entire job as a manager is to manage your direct reports. Knowing who they're working with, and who they're having difficulty working with (and then to smooth it over so they can continue to work together, or move people around so they don't have to) is core to the job of managing y'know, people.
If one of my directs didn't tell me about difficult-to-work-with people, I'd be concerned. I want to know if there are people everyone finds difficult work with, and the best way to know is to hear from all ICs.
There's a difference between having some awareness of interpersonal challenges my team have, versus one of them having, among the list of 61 principles by which they govern themselves, 'keeping me up to date on who they are having difficulty working with'. I mean, I note that there isn't a corresponding advice to 'keep your manager up to date on people you enjoy working with'.
Overall, it just sounds like they plan on making problems and then bringing them to me to resolve. Which, sure, would require 'managing'.
You're clearly a very serious person. It might help you to be aware that some other people take things, in general, a little lightly.
Out of context guidance consisting of little faux-wise aphorisms like that of the OP is just kind of inherently amusing, especially when offered earnestly, precisely because it is open to misinterpretation - and my suggestion that it could be interpreted as advice to keep your manager apprised of who's currently on your enemies list was meant to illustrate that risk.
As putative advice to senior engineers for how to conduct themselves, it struck me as something which some toxic engineers might take as endorsing their superior attitude. That makes it bad advice, and that's why I'm mocking it.
But how I react to the idea of this sort of thing being offered as career advice, respectfully, tells you absolutely nothing about how I conduct myself in my professional role.
> and my suggestion that it could be interpreted as advice to keep your manager apprised of who's currently on your enemies list was meant to illustrate that risk.
Yeah....again....not an enemies list.
> As putative advice to senior engineers for how to conduct themselves, it struck me as something which some toxic engineers might take as endorsing their superior attitude. That makes it bad advice, and that's why I'm mocking it.
Yeah...again...this perception is a toxic _manager_ trait.
> But how I react to the idea of this sort of thing being offered as career advice, respectfully, tells you absolutely nothing about how I conduct myself in my professional role.
We can disagree, that's fine. Thankfully you don't work in my organization, so your opinion is of 0 value to me. I had (obviously incorrectly) hoped some sane feedback might make you reevaluate your behavior, but alas stubbornness prevails. Hopefully your reports can manage working with you effectively.
You can certainly use the form that way, as your own instance of a checklist, and it seems the site has the purpose of providing such mini 'applications' in a local-store friendly manner - see the Travel checklist on the same site, for example.
Pretty nifty, if you think about it. Storage stays local, it looks like .. but I am not an expert. I just like the form of this.
3-digit slashdot ID's notwithstanding, I hope we see a revival of cute little cottage-/hobby sites like this, or a kind of perpetually simple cache of folks who just render their genius to static files, in cute ways, and leave it at that... over and over for a few years.
> Resist the urge to refactor major systems to achieve simplification, because there's a risk you will end up with a similarly complex system after some time
It's possible if you keep things simple, but it's a rather naive goal in most places which have already grown in size and complexity. Just knowing what's happening with the other teams and how your work fits into it is already a full-time job. I've spent DAYS on Slack without getting anything done - I had to get up early in the morning.
Read books, on a variety of topics, including the ones you don’t know about. A book will give you a much broader and deeper understanding of most topics than random blog posts on the internet. Make sure you read one or two a year, and think about how you’d apply what you’re learning at work. Even better, find an actual application at work.
I’ve found that solving tricky problems ( horrible network related issue, performance bugs, strange behaviour of program/framework/os, someone you know deciding to use new tech you don’t know about etc ) is usually a good way of finding a topic to explore.
Find someone who’s interested in actively learning things, it makes things a lot more pleasant, and it’s easier to remain motivated. You don’t have to learn the same things - just share the fun stuff you’re learning.
Finally, and most importantly : it’s ok if you’re not learning as quickly as when you were at university. It’s not a competition. You have a full time job, don’t have a lot of time, so just make sure that you enjoy learning, so that you keep doing it !
Don’t stop learning at the end of your use-case for a piece of tech. If your team uses a tool, understand approaches you didn’t take, trade offs and ultimately why you chose the path you chose. Understand even other pieces of tech and their approaches. Also, deeply understand failure scenarios and how to mitigate them.
Basically just dig in beyond “it works”. You’d be surprised how many devs never read a tool’s docs if they don’t absolutely have to.
I always find advice like this a little confusing. A lot of these things seem (to me) to be none of the engineers' business.
To me, engineers receive specs from management and implement solutions that meet those specs. And that's it.
I suppose my personal experience must not be how things work elsewhere! Kind of fascinating, and it makes me wonder if people enjoy all this extra responsibility and how things go when engineers disagree with management.
What you're talking about to me is mid-level work. Seniors deal with ambiguity and feasibility analysis. Non-technical people often don't understand the level of tech necessary. They'll say, "I want a bridge about this long" very nice, but but did you consider the about wind that whistles through this area ? Also, how many lanes? Yeah that many is too few because once this bridge goes up we're not gonna be reasonably able to close it even for maintenance. We need at least 4 lanes. Isn't there a cement shortage? Hm.. maybe we can use this material instead? No. I don't think building with wood for this length is a great idea.
You get the picture. Yes lead developers exist, but they only have so much time to do little battles and they're busy making sure the big things are arguing correctly. Senior engineers should be able to talk to design about a redesign necessary because iOS just isn't capable of this it turns out or the cool effect you saw is only available on a version we don't use and can't update to right because complex reason.
If you're just taking your requirements and working without having to negotiate with another person, you're probably not doing senior work.
Some of it I the site I don't think is senior work really unless you're a tiny shop, but they're not weird since these are all skills a for senior adjacent roles that any senior might be called on to take randomly. It's not uncommon in many shops for leads to be a spontaneous and temporary role for some project that disappears on major release.
I'm not even sure that a mid-level engineer would be just taking specs and implementing them. Maybe early-mid, the sort who are moving up from building easy things to building bigger things, but even at mid level an engineer should be able to take ownership of some small set of related features for a system.
It's definitely interesting how people with the same title can have such different experiences. I'll try to give the other perspective, but please understand that it's a huge topic and this is a simplification.
My experience has been an issue is raised - usually by management or "the business", but sometimes by engineering. "Our website is too slow!". Now someone has to step up and clarify things. Like:
* what does "fast" even mean for our website? It would be great to have an objective metric.
* Is there such a thing as "fast enough"?
* How much time / effort / money is a given improvement worth?
* How do we prioritize this vs. everything else we could be working on?
A project spec comes out of those discussions, but the discussions themselves have significant technical and business inputs.
I don't view taking part in these discussions as "extra" responsibility, I view it as a core part of the job. I've also seen what happens when specs are written without technical input: it makes implementing them a lot less pleasant.
> A project spec comes out of those discussions, but the discussions themselves have significant technical and business inputs.
Then managers should learn whatever it takes to be able to make these types of decisions. There seems to be a double standard where engineers have to do all of these non-engineering tasks, meanwhile non-engineers never have to learn the systems in depth.
I think programming is a hard enough job that warrants 90% of focus, at least to be able to reap the benefits of computer science. At the dawn of generative AI, we can clearly see software has no limits, yet limits are implicitly imposed by re-prioritizing an engineer's time with "soft skill" tasks and having them spend a huge amount of time thinking about things that have little to do with computer science.
If a business needs that specific intersection of skillset, perhaps it should be a new role, instead of stretching the role of engineering and missing the opportunity to innovate at the software level, which in the end would help the business anyway.
One engineer on their own can only write so much code. As soon as you have two, you have a team, and the team needs to share information. Fundamentally that's what all those meetings are for (and it's a large part of the job of leadership to facilitate that sharing of information as effectively as possible)
> One engineer on their own can only write so much code.
My first internship, a long time ago, was making HTML websites manually. At the time JS was still young and was not widespread, but I still wrote a custom content management system that would write HTML for me... when I presented this to the people in charge, there was no interest. They didn't care I could do the work faster. They had clients, which payed them by job and not by time. This is just one example of many I experienced of how businesses are blind to how much programmers could add value to their company by simply optimizing their expertise of software engineering. Software engineers are boxed into roles where they are unable to focus on engineering only, and as a result they never achieve the technical level that will allow for domain specific innovations.
So no, engineers don't really have a limit on productivity (granted there is a cost), given that you can write code to write code. There really is no limit, we just have to look at AI.
Sometimes (often) you feel like following the requirements is not the correct way, because they look fine at first sight but not so bright when doing a first analysis or design. Then you tend to get involved with the "none of my business" business.
> Strive for deep technical expertise in technologies used
And that alone occupies most of my (working/free) time. Not sure how I'm supposed to keep up with the rest of the list. To know technologies is one thing, to have deep tech expertise in many technologies is a completely different one.
Zooming in on check 4, ask 'why' until you find the root. For some reason I tend to do this almost naturally, with mixed results though.
Especially when reviewing code, you often see how things can be done more simply, and asking "why" to the reviewee can sometimes backfire because of touching a sore point.
Thinking about it, not only when reviewing code. Also, when you question the used processes you often bump into "we found out from experience this works best" or "why change a working process". So always using the "why" tactic can be frustrating at times.
Asking why has to be done much earlier in processes than that. You need to interrogate the person or department that is asking for something to get to the thing that they actually need instead of merely what they think is the easiest thing for you to deliver.
I was often able to reduce the scope and cost of parts of projects by pestering the domain experts who wanted something to explain why they wanted it. I often discovered that they believed that what they really wanted was impossible or too difficult so they had pre-emptively asked for the second best. Once I understood what they really needed I could tell give them a proper estimate of the cost of solving the actual problem.
In some cases I was able to automate away the job that they had asked me to merely provide a better user interface for for and do that with less effort and cost.
It was mostly a long time ago so the details are a bit hazy now. Generally it went something like this:
The domain expert (our internal customer) has a badly specified procedure for picking the correct configuration for some sub-assembly. It depends on a number of different parameters some of which are continuous variables and some are discrete. Which continuous variables are relevant depends on which combination of the discrete values are chosen; for instance choosing nominally equivalent parts from different suppliers can mean having to express the specification in different terms. So the customer asks for a user interface that will make it easier for the end user (not the domain expert, a less qualified person) to explore the database and a few simple tools to do some calculations so that they can decide which parts to order.
While writing up my proposed solution I realize that a lot of what the domain expert has expressed as matters of fine professional judgement look suspiciously like they are in fact rule bound from the point of view of the actual end user. When I quiz the domain expert about this they tell me that they though that the task was too complicated to automate. When I finally extract from them the actual rules I see that the actual end user has no real freedom of choice, that the rules change about once a decade, and that all that is requires is a small form to gather the two pieces of information that are not already in the system and a fairly small set of database queries. All the rules can be encoded easily in a couple of small database tables that the domain expert can update when the conditions change.
I point out that this is actually less work, can be delivered sooner, and is most likely more reliable. The domain expert agrees and we are both happy.
Over the decades that I spent writing applications I frequently found that customers failed to ask for what they really wanted because of mistaken beliefs about the relative difficulty of various kinds of computing tasks. Instead of asking for what they needed they asked for what they thought we could provide. This frequently caused more delay than if they had simply asked for the best solution from their point of view.
Often the customer asks for what they want rather than what they need. Very often what they want is rooted in solutions or partial solutions that they have seen or implemented themselves. They think that they simply need a better version of their own home grown tool when in fact their tool is the way it is simply because of the limitations of the tools they had to hand, usually Excel programmed by someone doing it instead of the engineering that they are actually competent in. Using the appropriate solution, often an SQL database and a very simple front end, simplifies the task dramatically and makes the tool both easier to use and much simpler to maintain.
I worked at a MAANG where this was not the case. The pecking order of "seniority" was who was the most "right" and who could poke the most holes in everyone else's ideas while denying others' contributions while bragging about how essential and important their work was in a semi-agro manner that discouraged dissent and curiosity.
In my view, marks of intelligence include lacking strong biases, comfort with ambiguity, be willing to propose hypotheses, experiment, gather data, and be proven wrong.
"Understand the business aspect of your work, and what makes money. Eventually, only that matters."
Applies only to commercial organisations (and no, even with those money is not the be-all and end-all) so not impressive as a number one, at least with that wording. Understanding business is clearly key though.
TBH that and the rather self-satisfied "it is useful to any software engineer, it is especially useful to senior engineers." on a rather enigmatic website lacking in other interesting writing put me off considering it further.
You mean Company impact? I see "effort" and two categories for impact - Career and Company. Also I notice that there's nothing in the "managers" category that has high company impact. Seems about right.
The only part of this I disagree with is "Couple of years of Relevant Practical Experience" is senior. Intermediate, sure. Senior should be at least five years AND at least two projects.
> Be amazing at bullshitting. Small project? Make the mole hill into mount everest. Big project? Act like you just saved the company. Study people. Your manager and their manager have exploitable weaknesses. ... Fuck people who think honesty is how you get ahead. ... Exploit every weakness. Don't be an asshole of course. That won't get you ahead.
Following the advice in this paragraph—bullshitting and exploiting people to get ahead—makes you into an asshole. There's no way around it.
For myself, I'd rather not "get ahead" if "getting ahead" requires turning myself into that which I despise. I've had to work with people like this, and I will not bring that hell on anyone else.
1. Be able to make a design decision - among multiple options and with incomplete data and uncertainties, a senior engineer needs to be able to make a decision and be accountable for it in order to move the project forward. I think a good interview question would be to ask about their difficult design decisions.
2. Be able to identify wrong solution (most of the time) - maybe this comes with technical competency but a lot of resource is wasted chasing solutions that with the benefit of experience, should have been evident early on.