Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: A Senior Engineer's CheckList
662 points by littleblah on Sept 9, 2019 | hide | past | favorite | 143 comments
Sharing something that I wrote for my use but I think can be useful to others (I am an engineer with the title of Senior Software Engineer)

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 :)




About this one:

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


The opposite can happen.

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 think respect does not imply assumption of correctness. It's more like: there's a reason why the code looks like it does. The reason could be time pressure, some crucial information missing at the time when it was being implemented, etc. By all means try to improve it but don't look down on a person who created it. It's easy to judge from perspective of 6 or more months.


"The reason" can also be lack of basic competence in previous workers. That can be extended to the rest of the team or management around the worker(s) for not providing a guidance/help.

"reason" can be "cause/effect" reason, but also "justifiable rationale". The files look like they do because someone typed keys and hit 'save' - cause/effect. But there's often no justification for how some code exists in its state that has to do with issues related to the business/logic itself. External factors - time (as you mentioned) or missing info (as you mentioned) - that missing info should have been documented somewhere.

I put out a lot of bad code in my early days. Seniors who came in afterwards ... yeah, the only or primary reason they could get from my code was "he wasn't very good at this". And they were correct. I got better, but primarily through trial and error (lots of them).

In thinking of some specific projects from 98/99 - I was demonstrably not good. I got stuff done, but it was generally very inefficient. But... it worked (to the level of understanding of everyone on the project). Even then, people weren't coming in after me to make basic stuff work, but they did help make it better.

If you're coming in to a project and there's no unit tests, no sample data, no repeatable build process, no documentation, no testing or verification process, and no previous team members to actually talk to to get questions answered, there's little reason to have any assumption of correctness. There may very well be 'reasons' for the lack of all of those factors above, but nothing makes me assume the code is correct. And... if I'm brought in to a project like that, "respecting" the code or the people before adds no benefit to the project, and may detract from getting stuff done.


> "The reason" can also be lack of basic competence in previous workers.

That type of wording belies a destructive approach to the problem. What I'm told is "lack of competence" is often someone not being trained properly, or leadership that decided to make a deadline no matter what, or a junior dev that got called a senior dev to fill a seat at a cheaper rate, or someone who knew they didn't have the skills but didn't want to admit it and lose their job.

The other thing I often find is that regular complaining about other people's code is usually projection. The less forgiving someone is the more likely that their code and architectural decisions suck even more than the people they're complaining about.

There's a senior dev at my job who openly craps on other dev teams as incompetent - to the point that he literally says, "those guys are fucking stupid and their code sucks". This guy never documents his own work, makes inflexible architectural decisions that don't take anyone else into account, and generally causes hours worth of workaround code for me every month.


Often, but not always. When people generalize, it's an equal error to conjecture that the premise for the generalization is always false in the other direction. Lack of skill/experience is just a nicer way of saying incompetence, and sometimes this is a proximate cause, and sometimes this is actually a root cause, in cases where the person was a genuine bad actor who fooled others into thinking they were qualified for the position.

Now of course there are many times where this is used as a crutch to blame system problems, but I've found a trend towards the idea that it's never due to lack of skill/experience on the part of an individual, and always due to some other root cause. That seems equally incorrect, and good judgement about the cause should be agnostic to how one feels about the idea of saying an individual failed at their jobs (which usually isn't a pleasant feeling for most.)

On the upside, one should actually expect people to fail at their jobs occasionally within certain boundaries, in order for them to grow. So failures to due to 'incompetence' (not negligence) should be often accepted and blameless, given they should be happening occasionally if you are pushing people past their limits. The best way to ensure someone doesn't make large categories of mistakes is to let them make one with a small blast radius, and having them take responsibility for addressing the failure and remediations. (This isn't at odds with blamelessness -- most ethical people will accept responsibility for their failures and correcting them, if they are able to fail in an open, respectful environment)


"often someone not being trained properly, or leadership that decided to make a deadline no matter what"

> That can be extended to the rest of the team or management around the worker(s) for not providing a guidance/help.

I indicated this isn't always/necessarily one person's fault.

re: your senior dev. he might be correct that their code sucks, but he's also being an ass in his own right.

I've told this story a few times to folks where... in 2017, I was contacted by someone who said "the system stopped working". Turns out it was something I'd built in 2002/2003. It's eye-opening and humbling to go back and fix your own mistakes from 15 years earlier.

> The less forgiving someone is the more likely that their code and architectural decisions suck even more than the people they're complaining about.

I don't disagree. It's why I tell people to document as much as they can - document the meetings behind decisions, document the rationale for cutting corners. It will help YOU later on when you have to go back and can't remember why you did XYZ. (See above reference to 2017/2002).

I fully realize my stance comes across as offensive in some situations, and I do not always project this stance. I'm fully aware people are forced in to bad choices some times - I've done it myself (on both sides of the table).

However, I'm also often coming in to situations where I have nothing more than running code and a client wanting stuff done. My scenario above about no tests, no sample data, no testing process, no documentation and no previous dev to consult with... it's probably been more than 50% of the projects I've worked on in the past 20+ years. Clients/employers also read some of the same blog posts, and will sometimes throw out the "you shouldn't just rewrite stuff!" line (often while simultaneously telling me stuff is broken but "used to work 2 years ago"). These are sometimes 'dailywtf'-level projects, and if the primary goal is to make sure data and processing works as people need and expect today, large/wholesale overhauls are often necessary.

I've been on a short term project with a team the last few months and this is 100% different from many previous projects. There's 30+ tech folks, I'm on a team of 8, a mix of jr/sr folks, decent communication, a moderately large (and up to date and growing) test suite, test data, some documentation (could be improved), but generally all good people. I've seen some evidence of the "I'm the awesomest" dev work in the code repos, and those people are no longer around.

I'm not coming in to this project saying "everyone before me sucked ass and I'm a dev god". mostly because it's nowhere near true, but the process of getting stuff done is more team oriented - there's people to help, people to review, a good culture around the project, etc. There are problems but nothing like some of the other scenarios I listed above. So... this is the sort of scenario where it's a appropriate to respect the other folks, previous code, process, etc - it's all there and there's a defined way of working and getting better. Not all projects are like that.

FWIW, to the extent I find myself complaining about "other people's code", it's usually just a prelude to complaining about the processes which led to it. Why is someone being told to do XYZ without any context? Why are they excluded from decision making meetings, but given full responsibility for hitting a deadline they can't possibly meet? These aren't questions for the dev who wrote the code, but for the project management which led to that.

Example: Was brought in on a project with horrible code a few years back. Utter garbage - everything was NIH - they'd built everything from scratch. Digging a bit further, I find out that all dev and server boxes are limited from hitting the internet. No package managers work for anyone, so they build everything from scratch. Exceptions could be made - in writing - and within a few days or week or so, you might have someone pulldown and compile resources from a 'blessed' connection, then give you that code to run yourself. Things like encryption/decryption algorithms were being written by hand because it was the only way to hit deadlines in that working environment. Yes, it's literally insane to try to work that way, but I had a team of people who all did that, and felt trapped. It wasn't their fault entirely (excepting that they should have all just quit at once, or threatened to) but day by day things just got worse. Poor management was the root, not the devs - the bad code was just a symptom.


> document the meetings behind decisions, document the rationale for cutting corners

... document the API, document the project goals, document the company values, document checklists and routines, document processes and personal instructions. DOCUMENT THE GOD DAMN HISTORY OF FAILURES AND INCIDENTS!

And then rely in job on all those documents, not on talks and experience or memory of some key engineers. It hurts when you start, people tend to blame all those unnecessary staff, but it pays off in so high rates later. Often it's possible to say if a company will be successful on long run only by seeing its documentation.


It's not an assumption of correctness. It's an assumption of purpose. Chesterton's fence[1].

Let's say you inherit a large codebase, and it in fact does not have any tests, and is relatively complex and convoluted. Obviously that's not going to be very maintainable without testing, and it may make sense to do a rewrite...

But first, write tests. Test your assumptions. Read the commit history and see how the code base evolved over time. Maybe the reasons it was built the way it was are dumb ("I like naming my variables after my favorite flavors of pie!") or maybe it was done for really good reasons ("The database library breaks with odd numbers of connections, so the pool always has to be an even number."). The issue is that you simply don't know and risk repeating your ancestors mistakes unless you do some investigation.

[1] - https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


> Read the commit history

You're assuming there's always 'commit history' to review :)

I completely agree you need to do investigation, and document what you can about the system. Some of that documentation will take the form of tests. Without a doubt.

The 'assumption' I refer to is either clients or other devs assuming something is correct. I've lost track of the number of times I've heard "it was working fine until 2 days ago", when, in fact, it was never actually working, just not throwing a visible error until 2 days ago.

I will look at the fence - have seen reference to it before.

"until the reasoning behind the existing state of affairs is understood." - you may also need to realize the original rationale may never quite be understood. I've hit this a few times, and we've ended up just scrapping a particular set of functionality because no one could actually tell why it was there any more - everyone involved who may have used it or wanted/needed it is gone, and it's useless (or is now a blocker for other progress).


I think you are making some great points here. I have seen code commits are mostly right click in Eclipse and commit all modified files irrespective of if they are local config changes or preferences.

The senior devs in projects I worked have made 10 level deep 'strategy patterns' for future enhancements which still had hardcoded values underneath and absolutely non-extensible.

So in my books senior developers knew what they were doing comes with huge assumption. I have noticed many sr engineers simply had delusions of grandeur far beyond their programing skills.


Exactly.

> So in my books senior developers knew what they were doing comes with huge assumption.

This is another big assumption, and... especially given that we know in our industry that 'title inflation' is a real thing... "sr" just doesn't seem to mean much. I'm seeing lots of job postings today that call for "sr foo engineer", calling for 3+ years of experience. My definition and expectations of 'sr' are far different.

Interestingly, I've only been in a couple of places that even defined what they actually meant by that title - what was expected was written down. It was still open to interpretation, but a baseline to judge you against, and to give jr folks something to shoot for.

> which still had hardcoded values underneath and absolutely non-extensible.

Don't even get me started on people that just learned the 'final' keyword and abuse the hell out of it. :)


That's why I think code that seems "weird" should always be accompanied by a comment explaining why it is the way it is and why a seemingly more obvious approach wasn't taken.


At the very least.

Better might be a comment linking to a ticket or wiki page or internal README with far more explanation. What's the technical reasoning, and what was the business impetus for requiring this done this way at this time?

Again, I've been on both sides of this fence, but the "never rebuild" mantra has a lot of assumptions built in, chief being that things are actually working correctly. If they are, and there's no tests around it, memorialize the existing state with your own tests at the very start. It's what we did on the August project referenced above, and it took weeks (months, really) to have a modicum of basic tests ensuring some base level of understanding for our team (just 2 of us).


I think you are missing the point. Respecting systems doesn't mean 'not touching' or 'working around' existing systems. It just means 'understand it, before you change/rewrite it'. Otherwise, your rewrite might be even worse.

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.


Fair point: sometimes things are, in fact, bad enough that a rewrite is warranted. IMHO, this is where the "senior engineer" mantle becomes less about engineering and more about interpersonal / organization-navigational skills.

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?


"respect the existing code" <-- for me, this means respect the people who wrote it especially if they are still about.

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.


if they're still around, you can ask questions, and get a much better handle on why it's the way it is, and perhaps avoid earlier mistakes, and come up with a better strategy. maybe even just actually document the 'whys' and leave it as is.


It's very situation dependent. I try to advocate for the old code when I can, but I've had similar experiences. The most recent example was a multithreaded app started by a person who understood neither mutexes nor pure functions. Doing a ctrl+f for "sleep" for quickly showed that code was doomed to always be breaking in inexplicable ways. Give code the benefit of the doubt as much as possible, but there is a point where old code deserves more suspicion than respect.


I think the main thrust is respect the code and understand why it was there. Don't start with the possible initial feeling that a particular piece of code or guard is not needed. If you do find that it's not needed, remove it or fix it.


I'll second manojlds's comment. If there is bad code/design decision on production - it not necessary means it was bad all the time. Software grows, requirements changes and it is very likely there is a reason why the code is as it is now. Even if it does not solve the problem efficiently today.

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.


It's essentially the Chesterton's Fence principle.


This is very similar to Joel Spolsky's advice that you should never just chuck code out and and start from scratch.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...


Yup. That was my inspiration, and sadly, I have been on the side as well where things started from scratch, and ended up blowing up couple of months later.


AKA, Chesterson's Fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


> you should try to understand the difference between code that should stay and code that should go.

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


I don't think the OP meant "don't touch old code", but this sentence, to me, implies that "reasons" means good reasons:

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


It is true, sometimes the reasons are not good ones. But, if it is in production, one should assume the reasons are good ones, there's already some evidence. The point is mainly that the burden of proof is on the reader to demonstrate the reasons are not good before modifying it... especially because you're right: code smell is the default product of time. We have to be careful about assuming that code smell indicates something is wrong. My couple of decades of experience is that people assuming reasons aren't good and jumping into modifications is a bigger acute problem than being more conservative than necessary. Accumulating the tower of abstractions is no doubt a problem, but it happens more slowly and is caused by a multitude of bad practices, it rarely breaks production or causes downtime, unlike refactoring too eagerly because of smell or opinion rather than demonstrated necessity. It is indeed a fine line, I completely agree!


respect doesn't mean revere.

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.


Here is a clickable list of what the OP posted, for the lazy:

1. https://littleblah.com/post/2019-09-01-senior-engineer-check...

2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-e...

3. https://github.com/littleblah/senior-engineer-checklist


Thanks. Somehow I failed to create clickable links :(


Not your fault. It's impossible to do in the post description.


'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.'

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.


Especially nowadays when Developers don't seem to have to be required to actually be able to code.

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?


I find that things I think would be easy and often incredibly difficult for people who are not as experienced as I am. That certainly played out while I was writing exams for undergraduates.

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’m seeing the opposite in DC. Our recent “junior” candidates have been very impressive. I can see the affects of competition being played out. And, especially the female candidates - just outstanding.


I'm sure it depends on your organization, and with large orgs maybe even your particular subdivision. That said, I can sympathize. I'm involved in the interviewing process of my niche in the org and try my best to hire quality candidates, but I can say that a non-trivial amount of devs are hired into the org without demonstrating any ability to code.

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]


So you want to implement an age measure of qualification, since you cannot get hiring to implement a good technical interview process? Do you also write code the same way?


Are you having problems with the junior developers that are getting hired?


The "high" in high bar is not a particular useful measurement. What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word. What you can say is "we need someone who knows the internals of tool X, and we measure it via Y". Basically, avoid using adjectives to measure things (e.g. say 1 liter glass, don't say big glass).


The only "problem" with that approach is that it invalidates most hand-wavy advice:

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


"Hire only the best." What if the best only want to work with the best pay and the most interesting work?

That's the interesting question. The hard choice, that I rarely see discussed, is what to do when "the best" won't work for you. Do you hire the "perfectly adequate" or do you not hire and not do that thing you want "the best" person to work on.


one idea is to put your candidate out of their comfort zone and ask them to get their arms around something new. Try to figure out if they have a process for teaching and improving themself. Maybe if you can't hire the best you can find someone with the potential to be one of the best.


I think the short answer if higher the best you can, commit to getting better, and hoping that is enough!


> What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word.

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.


What defines a high bar, at BT our team had a DBA whose first boss was Dijkstra (yes that one) we was the unofficial database GURU for the entire engineering centre.

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 wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.


This is probably far more common than we'd like to admit.

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.


I've been a "senior" engineer for years, in that time I've read through a few dozen CVs, sat in on 2 interviews, and had final say in hiring of exactly zero people. I suspect the same is true for at least half the senior people here, unless they also happen to managers.


I'm not trying to sound accusatory, I'm just interested. Aren't you interested in choosing the people the people you're going to have to work with every day? Are managers doing interviews where they're asking technical questions?


I remember myself and every other senior engineer on a team once rejecting a candidate and being overruled by management. The guy was hired and... turned out to be as useless as we thought he'd be.


Well, the person might not have been the most skilled guy around, but how hard did the team worked at integrating this person?

I mean, starting with a negative reputation in a team that felt betrayed by your arrival doesn't seem to be the best condition to give the best out of yourself.


There is infinite opportunity to screw over a new hire. Just getting setup in the dev environment on any team is usually 50% undocumented and you need help from coworkers.... it's one of my least-favorite things to do on a new job.

Also undocumented in large companies: how to get ANYTHING done outside the team.

Then when it comes to reviews, especially in large companies, you are utterly beholden to whether or not your manager likes you. I've only ever seen one person the manager disliked get a glowing review, and the manager did it as a joke since they were quitting.


This happened at a company I worked at as well - except the rejected candidate became our manager!


I certainly have sat in on interviews and think it's valuable experience for a senior, especially when you're looking to fill a particular gap on the team. I was more pointing out that this is a very generic comment around a very complex problem.


Why most developers never have any HR/IR training or do this in their day to day Job.


I'm a senior developer and have almsot zero involvement in 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.


At my current company we ask even juniors to get involved. Interviews are in pairs, with at least one senior person in that pair, so we can make sure each interview is as fair as possible. IMO everyone can have a valid view, and since we could well be looking for their next team mate I'd prefer to know that it's not just my opinion that gets heard. It's been working pretty well so far, and given people more experience in hiring that I hope helps them later in their careers.


Maybe the idea is that the senior engineer here should collaborate on what that bar is.


Thanks for the list. There are a lot of great suggestions here, but I think the scope is much wider than just senior engineers for a majority of the items. Here are a few that I think are especially important for junior level engineers.

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


Second bullet point: recommend using “strong opinions weakly held” (https://medium.com/@ameet/strong-opinions-weakly-held-a-fram...).

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.


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


> It's essentially the scientific method.

I had never considered this before and it is right and true.

Thank you for enlightening me.


> Have strong mentors to help you navigate and grow in the company.

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.


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

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.


Thanks for sharing. I would instead describe this list as "principles" instead of a checklist. A checklist is often used for a much more specific scope with very specific items. These are not applicable to any specific time or scenario and have activities that are not very specific.

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.


Extreme ownership probably refers to the book Extreme Ownership: How U.S. Navy SEALs Lead and Win.


yes!


>> "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?

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.


Thanks.

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.


It's a (thoughtful) list for the "senior engineer in 500+ heads company".

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.


Manager = CTO/CEO

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%?


While I agree to certain extent, you still have these things in different shapes and sizes. Startup teams are a tight knit community in my experience, but as it scales, these aspects start to show their heads.


I worked at a five person startup, and I had all of those.


If you're at a startup you better be hiring! That's your #1 job! You better keep that bar high because the next round of folks will be hired by them. Further, at a small startup you can't get away from a bad hire, they're literally adjacent to you for 50+ hours a week.

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


To add to this, I found these resources great:

1. https://blog.samaltman.com/how-to-hire

2. https://startupclass.samaltman.com/courses/lec02/


As the CTO of a small-ish startup, this rings so true. All our employees were hired from our network. Its only now that we'll look for other sources to benefit or hiring pipeline.


> [Reminder] One-on-one usually is not a status meeting

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?


1) Feedback (going both ways). 2) Anything that is blocking/bothering you. 3) How you feel about any recent developments in the team/company. 4) Long-term career stuff. What interests you, in what direction you want to be going. 5) Stupid organizational stuff you need assistance with (e.g. reimbursements). 6) Random smalltalk, personal stuff.


It needn't devolve into status. I like how Rands thinks about nerd herding.

https://randsinrepose.com/archives/the-update-the-vent-and-t...


Same here.

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!


Recently, I came across this list:

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.


What is this a checklist of exactly? A list of things to do to become a senior engineer, or things to do once you are a senior engineer?

There is little description or context to this, so I'm not sure what I'm looking at here.

Apologies for being dense!


It's not your fault. The post has zero context.


Sorry about that. Thanks for pointing out the gaps. 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.


To me, those are the same things. Things you do to become a senior engineer /are/ the things you do when you're a senior engineer. You don't become a senior engineer without exhibiting some of the traits shown and you don't stay a senior engineer without doing most of those things.


This is a very good set of principles to operate by.

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


Thanks!


>> extreme ownership

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.


"Extreme ownership" is something that takes time to develop.

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.


These are excellent, except for one, which is to avoid politics. Politics is the art of making other people want the things that you want. If you can't do that, you're not a senior engineer. Politics is critical for your success, and honestly, a large number of these sixty points fall under, IMO, politics.

tl;dr: s/"Avoid politics, but have right folks vouch for your work"/"Become an adept politician".


> Politics is the art of making other people want the things that you want.

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.


Sure, that's totally fair, but let's step back for a second. Let's say there's you, who's got the company's best interests at heart and a great technical/product direction. Then there's Steve. Steve is rubbing backs, in it for himself, but in the pocket of everyone who matters. Who's gonna win? Sadly, it's Steve. Not playing politics is a great way to lose at politics because you're going to get beaten by the first person who is.

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 :)


> manipulation for personal gains at the cost of a larger good is what is my definition of "politics".

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.


fair enough


indeed, You need to be an adept politician.

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.


> Avoid over-engineering

I would consider this list to be a little over-engineered


> "Understand the business aspect of your work, and what makes money. Eventually, only that matters."

How about ethics? company reputation? legal compliance? corporate responsibility?


Caring about ethics is too old fashioned for software "engineering," reputation is maintained by someone else, software developers tend to think the law happens to other people and HAHAHAHAHA.

...that's about it.


Engineers at a known european auto maker created a solution to defeat car emissions tests. As a result, there were cars on the streets that polluted hundreds of times more than a regular car.

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.


You are trying to convince me that ethics are important. I already believe that. You perhaps might try to convince me that companies care about that, but you started off with a bunch of counter examples.


In addition to the ethical aspects of the product, I would add, that I always ask myself, "if I was laid off today, can I use my current job to get another job."

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.


OP has shared the github repo where these pointers are maintained and has encouraged pull requests to improve on the list.


Definitely. Thanks for pointing out the gaps. 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.


None of that matters if employees aren't getting paid.


Being a prerequisite is not the same as being the only thing that matters. Also, the company making money does not mean the employees will get paid.


Your post comes off as if the author is purposely avoiding these topics. No doubt they’re important, but while many software people will look at a company’s reputation or take ethics for granted (in the sense that of course it’s important), many software people, especially juniors, don’t stop to think about the business value of spending X on Y. Everything has a cost - for example, spending the extra time optimizing your code has a cost. Value is what you want to produce at the end of the day, not a grand architecture or extremely optimized code. Those may or may not be a means to an end. That’s not to say you should ignore ethical or legal consequences. I don’t think people generally want to break the law.


People generally don't want the company to lose money either. Many ethical and even law violations happen for the same reason you gave: they don’t stop to think about it. Ethical and legal consequences are not always obvious.


You are conflating software engineering good practices with ethics. They slightly overlap but are not the same.

Balancing strategy and tactics is something you do as you become senior. Pumping tech debt is a tactic, good practices are a strategy.


Sounds like the person who wrote worked for Amazon or similar company. Almost all of this was official Amazon guideline for engineers.


Is it? I did not know, sorry.


I wrote it as a praise. :) I agree with it 100%.


This is not a checklist. Items in a checklist are either checked or unchecked. This is more of a values matrix.


You can click on items to check or uncheck them


Thats not true. You can click an item to highlight it. I've never used a checklist that used highlighting to indicate it's state.


Normally, this is where I'd chide the OP for using "Engineer" in the title when they really mean "Software Engineer", but (refreshingly) most of the items on this list seem broadly applicable to different types of engineers, so it's not really warranted.


Your comment seems pretty elitist. It's clearly implying that Software Engineers aren't real engineers. I'll admit, not every software developer designs and builds engines (see definition of engine) but many Software Engineers, in fact, do. The principles of engineering are simply applied sciences. Many software engineers have degrees in Computer Science and they are applying the science. I also know plenty of Software Engineers that have Engineering degrees as well. So I guess I'm just wondering why exactly you feel the need to "normally" correct OP? Real question, not trolling. I just want to to understand.


> Your comment seems pretty elitist. It's clearly implying that Software Engineers aren't real engineers.

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.


This isn't as inflammatory as you think it is, software engineering is just a subset of engineering... just like all other engineering fields.

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 think you misunderstood him, as others have noted, however I do agree that Software Engineers tend to diminish their own skillset as not "engineery" enough. And I have a very hard time understanding why.

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!


I didn't understand it that way, they expected the list to be software engineering specific (touching topics like Git, CI/CD, etc), but the title gave off the impression that it would be helpful for engineers across all disciplines.

And it was, thus they were pleasantly surprised.


Not sure that I agree. I think said comment is more of an observation that software engineers have a larger representation here than other engineering disciplines, but this list isn't exclusively beneficial to software engineering principles.


But you can't deny there is a pervasive overuse of the label 'engineer' to cover everything from junior web developers with < 1 year experience all the way to senior roles at major companies. The label has an important meaning to non-technical readers and should be used more sparingly.


So a mechanical engineer with < 1 year experience should also be called a junior mechanical developer.. or am I missing the point here?


A mechanical engineer with < 1 year of experience likely has a degree in Engineering, which has been certified by a professional body. In some countries that's a requirement for using the term "Engineer".

A junior web developer, with less than 1 years experience might have spent two days reading https://www.amazon.co.uk/Sams-Teach-Yourself-PHP-Hours/dp/06... (if that).

Let's not pretend those are the same.

Software Engineering has a history of trashing any benefits of formal education, and refusing to believe that any of it has any worth.


> In some countries that's a requirement for using the term "Engineer".

This is more or less the case where I am from, so I assumed that to be generally applicable, but no? In that case, I agree.


I was recently trying to make something like this checklist, but categorized a little differently, with multiple levels of detail, and... extensive.

As above, visit [1] for the end-user version and [2] for the repository.

1. http://htmlpreview.github.io/?https://github.com/dpmm99/deve...

2. https://github.com/dpmm99/developer-knowledge/


Being a sceptical ct, I would say that all of these items in the first list are shaky at best. "All that matters is profit" is how we end up with melting ice caps!


"Understand the business aspect of your work, and what makes money. Eventually, only that matters"

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.


Great list! Did you/do you work at Amazon at some point? I feel like the Amazon LPs might have influenced some of these?


This is great! Thank you for sharing your experience.

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?


If you cannot disrupt a perverted culture by introducing a new culture, the politics of the perverted culture will work against you until you break, align, or leave. It is not unwise to leave before you break and it is easier to leave before you align.


Thanks. "fall back to first principals" is inspired by this post:

https://jamesclear.com/first-principles


Did you use a tool to create the JSON or did you type it by hand?


`jq` is great. Initially, I started with excel, which I exported as csv, which using `jq` I converted to JSON.

Why json and not csv? Strictier parsing by javascript.


I would add "Demonstrate discipline in following processes and take ownership in changing them when they don't make sense"


You have a bug in your CSV export. The header has 5 fields and you export 6. You are missing "#" as the first header field.


Developer Tune-Up by Neil on Software is a similar categorization of skills and growth areas. it's worth giving a try.


I like the css and theme of your website. Did you design it yourself or is there a theme of sorts which you adopted?


Thanks. Its "even" theme on hugo.

https://themes.gohugo.io/hugo-theme-even/


Thanks for sharing! Really appreciate it.


(y)


Cool sounds great .




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: