10 ms·

Show HN: A Senior Engineer's CheckList

662 points by littleblah 7y ago

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

probablypat 7y ago
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?
- digitalsushi 7y ago
  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.
- deleted 7y ago
  [deleted]
- littleblah 7y ago
  Thanks. "fall back to first principals" is inspired by this post: https://jamesclear.com/first-principles https://jamesclear.com/first-principles
visviva 7y ago
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.
- j05huaNathaniel 7y ago
  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.
  - ben_jones 7y ago
    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.
    - imafish 7y ago
      So a mechanical engineer with < 1 year experience should also be called a junior mechanical developer.. or am I missing the point here?
      - richardwhiuk 7y ago
        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/0672326191 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.
        7y ago
tmh88j 7y ago
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.
- ehnto 7y ago
  > 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.
  - arvinsim 7y ago
deleted 7y ago
[deleted]
timdorr 7y ago
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!
- mychael 7y ago
  It's not your fault. The post has zero context.
  - deleted 7y ago
    [deleted]
  - littleblah 7y ago
    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.
- SeyelentEco 7y ago
  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.
29athrowaway 7y ago
> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?
- siquick 7y ago
  None of that matters if employees aren't getting paid.
  - icebraining 7y ago
    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.
- pavanlimo 7y ago
  OP has shared the github repo where these pointers are maintained and has encouraged pull requests to improve on the list.
- LaGrange 7y ago
  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.
  - 29athrowaway 7y ago
    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.
rukuu001 7y ago
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.
- deleted 7y ago
  [deleted]
- littleblah 7y ago
  Thanks!
wyldfire 7y ago
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.
- deleted 7y ago
  [deleted]
- littleblah 7y ago
  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.
- yitchelle 7y ago
  >> "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.
mychael 7y ago
This is not a checklist. Items in a checklist are either checked or unchecked. This is more of a values matrix.
- dvasdekis 7y ago
  You can click on items to check or uncheck them
  - mychael 7y ago
    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.
cuongnt3010 7y ago
(y)
rsashwin 7y ago
I like the css and theme of your website. Did you design it yourself or is there a theme of sorts which you adopted?
- littleblah 7y ago
  Thanks. Its "even" theme on hugo. https://themes.gohugo.io/hugo-theme-even/ https://themes.gohugo.io/hugo-theme-even/
  - rsashwin 7y ago
    Thanks for sharing! Really appreciate it.
notTyler 7y ago
'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.
- PopeDotNinja 7y ago
  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).
  - l0b0 7y ago
    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.
    - dagw 7y ago
      "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.
avip 7y ago
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.
- jefozabuss 7y ago
  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%?
- arcticbull 7y ago
  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+.
  - littleblah 7y ago
    To add to this, I found these resources great: 1. https://blog.samaltman.com/how-to-hire https://blog.samaltman.com/how-to-hire 2. https://startupclass.samaltman.com/courses/lec02/ https://startupclass.samaltman.com/courses/lec02/
  - SMFloris 7y ago
    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.
- littleblah 7y ago
rusteh1 7y ago
Great list! Did you/do you work at Amazon at some point? I feel like the Amazon LPs might have influenced some of these?
StreamBright 7y ago
Sounds like the person who wrote worked for Amazon or similar company. Almost all of this was official Amazon guideline for engineers.
- littleblah 7y ago
  Is it? I did not know, sorry.
  - StreamBright 7y ago
    I wrote it as a praise. :) I agree with it 100%.
cadbox1 7y ago
Did you use a tool to create the JSON or did you type it by hand?
- littleblah 7y ago
  `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.
dbmikus 7y ago
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.
- manojlds 7y ago
  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.
  - Pawka 7y ago
    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.
  - IanPBann 7y ago
    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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
    - 7y ago
arcticbull 7y ago
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".
- littleblah 7y ago
  > 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.
  - arcticbull 7y ago
    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 :)
  - icebraining 7y ago
    > 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.
mansoor_ 7y ago
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!
grumpy8 7y ago
>> 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.
- crispyambulance 7y ago
  "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.
DePro 7y ago
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/developer-knowledge/blob/master/FIPBYBSDS.html http://htmlpreview.github.io/?https://github.com/dpmm99/deve... 2. https://github.com/dpmm99/developer-knowledge/ https://github.com/dpmm99/developer-knowledge/
wry_discontent 7y ago
> [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?
- imglorp 7y ago
  It needn't devolve into status. I like how Rands thinks about nerd herding. https://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/ https://randsinrepose.com/archives/the-update-the-vent-and-t...
- sbarzowski 7y ago
  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.
- twic 7y ago
  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!
- arendtio 7y ago
  Recently, I came across this list: https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-1-on-1s/ 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.
chasd00 7y ago
"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.
ddgflorida 7y ago
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.
socratees 7y ago
Developer Tune-Up by Neil on Software is a similar categorization of skills and growth areas. it's worth giving a try.
Mc_Big_G 7y ago
I would add "Demonstrate discipline in following processes and take ownership in changing them when they don't make sense"
chickenfries 7y ago
> Avoid over-engineering I would consider this list to be a little over-engineered
Flimm 7y ago
Here is a clickable list of what the OP posted, for the lazy: 1. https://littleblah.com/post/2019-09-01-senior-engineer-checklist/ https://littleblah.com/post/2019-09-01-senior-engineer-check... 2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-engineers-checklist-c8e9f9f6e3c2 https://medium.com/@littleblah/my-top-25-items-in-a-senior-e... 3. https://github.com/littleblah/senior-engineer-checklist https://github.com/littleblah/senior-engineer-checklist
- littleblah 7y ago
  Thanks. Somehow I failed to create clickable links :(
  - Flimm 7y ago
    Not your fault. It's impossible to do in the post description.
POHUY 7y ago
Yes
Urazali2719 7y ago
### Keybase proof I hereby claim: * I am urazali2719 on github. * I am urazali2719 (https://keybase.io/urazali2719) on keybase. * I have a public key ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo To claim this, I am signing this object: ```json { "body": { "key": { "eldest_kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "host": "keybase.io", "kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "uid": "a7384b781017a51bd2850438b486e419", "username": "urazali2719" }, "merkle_root": { "ctime": 1568063008, "hash": "55e2a1aca29a97218ab28315d1079e1336b99b3aed46b60181b88198d0fad93587538e062da852f70b10e9b333add4f3ef9e5cd0c85b6633951ed0917725bf6b", "hash_meta": "f57d9437e56e0706bcd46bb32c2515003b1df484ae7940a087e12d2f919c2ccc", "seqno": 6255300 }, "service": { "entropy": "pQ1KgMrybqclACOooqMs605+", "name": "github", "username": "urazali2719" }, "type": "web_service_binding", "version": 2 }, "client": { "name": "keybase.io go client", "version": "4.4.0" }, "ctime": 1568063014, "expire_in": 504576000, "prev": "dcbca968d387888c4ab3f37e1d7d6f078287b7b24ee018c5b908da217b211454", "seqno": 16, "tag": "signature" } ``` with the key [ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo](https://keybase.io/urazali2719 https://keybase.io/urazali2719), yielding the signature: ``` hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgAwvAYRbVy51CAF03NmVmpQ7eyI7CkWFCum3BGzWTTd8Kp3BheWxvYWTESpcCEMQg3LypaNOHiIxKs/N+HX1vB4KHt7JO4BjFuQjaIXshFFTEIOLvq0969sHy7qFboEd6fzJ3WvqppZhidrhBsa3cr/jFAgHCo3NpZ8RAo2qBHI7Uq5VzjyxJlJPafMcPx0Fhpe42vS7zIPV+hSCzuUTXcTntC+p6mLm0d+sBEOHvWX0fR9MLaomu65OuCKhzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIOcZ1awz/uX7SpgEXR1NQxYUJ/3T35vm+UTgrF9wE68Eo3RhZ80CAqd2ZXJzaW9uAQ== ``` And finally, I am proving ownership of the github account by posting this as a gist. ### My publicly-auditable identity: https://keybase.io/urazali2719 https://keybase.io/urazali2719 ### From the command line: Consider the [keybase command line program](https://keybase.io/download https://keybase.io/download). ```bash # look me up keybase id urazali2719 ```
jablue 7y ago
Cool sounds great .
vadikkiev 7y ago
Thanks

662 points by littleblah 7y ago

probablypat 7y ago

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?

digitalsushi 7y ago
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.
deleted 7y ago
[deleted]
littleblah 7y ago
Thanks. "fall back to first principals" is inspired by this post: https://jamesclear.com/first-principles https://jamesclear.com/first-principles

visviva 7y ago

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.

j05huaNathaniel 7y ago
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.
- ben_jones 7y ago
  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.
  - imafish 7y ago
    So a mechanical engineer with < 1 year experience should also be called a junior mechanical developer.. or am I missing the point here?
    - richardwhiuk 7y ago
      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/0672326191 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.
      - 7y ago

tmh88j 7y ago

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.

ehnto 7y ago
> 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.
- arvinsim 7y ago

deleted 7y ago

[deleted]

timdorr 7y ago

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!

mychael 7y ago
It's not your fault. The post has zero context.
- deleted 7y ago
  [deleted]
- littleblah 7y ago
  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.
SeyelentEco 7y ago
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.

29athrowaway 7y ago

> "Understand the business aspect of your work, and what makes money. Eventually, only that matters." How about ethics? company reputation? legal compliance? corporate responsibility?

siquick 7y ago
None of that matters if employees aren't getting paid.
- icebraining 7y ago
  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.
pavanlimo 7y ago
OP has shared the github repo where these pointers are maintained and has encouraged pull requests to improve on the list.
LaGrange 7y ago
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.
- 29athrowaway 7y ago
  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.

rukuu001 7y ago

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.

deleted 7y ago
[deleted]
littleblah 7y ago
Thanks!

wyldfire 7y ago

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.

deleted 7y ago
[deleted]
littleblah 7y ago
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.
yitchelle 7y ago
>> "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.

mychael 7y ago

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

dvasdekis 7y ago
You can click on items to check or uncheck them
- mychael 7y ago
  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.

cuongnt3010 7y ago

(y)

rsashwin 7y ago

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

littleblah 7y ago
Thanks. Its "even" theme on hugo. https://themes.gohugo.io/hugo-theme-even/ https://themes.gohugo.io/hugo-theme-even/
- rsashwin 7y ago
  Thanks for sharing! Really appreciate it.

notTyler 7y ago

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

PopeDotNinja 7y ago
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).
- l0b0 7y ago
  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.
  - dagw 7y ago
    "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.

avip 7y ago

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.

jefozabuss 7y ago
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%?
arcticbull 7y ago
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+.
- littleblah 7y ago
  To add to this, I found these resources great: 1. https://blog.samaltman.com/how-to-hire https://blog.samaltman.com/how-to-hire 2. https://startupclass.samaltman.com/courses/lec02/ https://startupclass.samaltman.com/courses/lec02/
- SMFloris 7y ago
  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.
littleblah 7y ago

rusteh1 7y ago

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

StreamBright 7y ago

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

littleblah 7y ago
Is it? I did not know, sorry.
- StreamBright 7y ago
  I wrote it as a praise. :) I agree with it 100%.

cadbox1 7y ago

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

littleblah 7y ago
`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.

dbmikus 7y ago

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.

manojlds 7y ago
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.
- Pawka 7y ago
  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.
- IanPBann 7y ago
  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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - 7y ago

arcticbull 7y ago

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

littleblah 7y ago
> 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.
- arcticbull 7y ago
  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 :)
- icebraining 7y ago
  > 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.

mansoor_ 7y ago

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!

grumpy8 7y ago

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

crispyambulance 7y ago
"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.

DePro 7y ago

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/developer-knowledge/blob/master/FIPBYBSDS.html http://htmlpreview.github.io/?https://github.com/dpmm99/deve... 2. https://github.com/dpmm99/developer-knowledge/ https://github.com/dpmm99/developer-knowledge/

wry_discontent 7y ago

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

imglorp 7y ago
It needn't devolve into status. I like how Rands thinks about nerd herding. https://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/ https://randsinrepose.com/archives/the-update-the-vent-and-t...
sbarzowski 7y ago
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.
twic 7y ago
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!
arendtio 7y ago
Recently, I came across this list: https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-1-on-1s/ 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.

chasd00 7y ago

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

ddgflorida 7y ago

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.

socratees 7y ago

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

Mc_Big_G 7y ago

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

chickenfries 7y ago

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

Flimm 7y ago

Here is a clickable list of what the OP posted, for the lazy: 1. https://littleblah.com/post/2019-09-01-senior-engineer-checklist/ https://littleblah.com/post/2019-09-01-senior-engineer-check... 2. https://medium.com/@littleblah/my-top-25-items-in-a-senior-engineers-checklist-c8e9f9f6e3c2 https://medium.com/@littleblah/my-top-25-items-in-a-senior-e... 3. https://github.com/littleblah/senior-engineer-checklist https://github.com/littleblah/senior-engineer-checklist

littleblah 7y ago
Thanks. Somehow I failed to create clickable links :(
- Flimm 7y ago
  Not your fault. It's impossible to do in the post description.

POHUY 7y ago

Yes

Urazali2719 7y ago

### Keybase proof I hereby claim: * I am urazali2719 on github. * I am urazali2719 (https://keybase.io/urazali2719) on keybase. * I have a public key ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo To claim this, I am signing this object: ```json { "body": { "key": { "eldest_kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "host": "keybase.io", "kid": "0120030bc06116d5cb9d42005d37366566a50edec88ec2916142ba6dc11b35934ddf0a", "uid": "a7384b781017a51bd2850438b486e419", "username": "urazali2719" }, "merkle_root": { "ctime": 1568063008, "hash": "55e2a1aca29a97218ab28315d1079e1336b99b3aed46b60181b88198d0fad93587538e062da852f70b10e9b333add4f3ef9e5cd0c85b6633951ed0917725bf6b", "hash_meta": "f57d9437e56e0706bcd46bb32c2515003b1df484ae7940a087e12d2f919c2ccc", "seqno": 6255300 }, "service": { "entropy": "pQ1KgMrybqclACOooqMs605+", "name": "github", "username": "urazali2719" }, "type": "web_service_binding", "version": 2 }, "client": { "name": "keybase.io go client", "version": "4.4.0" }, "ctime": 1568063014, "expire_in": 504576000, "prev": "dcbca968d387888c4ab3f37e1d7d6f078287b7b24ee018c5b908da217b211454", "seqno": 16, "tag": "signature" } ``` with the key [ASADC8BhFtXLnUIAXTc2ZWalDt7IjsKRYUK6bcEbNZNN3wo](https://keybase.io/urazali2719 https://keybase.io/urazali2719), yielding the signature: ``` hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgAwvAYRbVy51CAF03NmVmpQ7eyI7CkWFCum3BGzWTTd8Kp3BheWxvYWTESpcCEMQg3LypaNOHiIxKs/N+HX1vB4KHt7JO4BjFuQjaIXshFFTEIOLvq0969sHy7qFboEd6fzJ3WvqppZhidrhBsa3cr/jFAgHCo3NpZ8RAo2qBHI7Uq5VzjyxJlJPafMcPx0Fhpe42vS7zIPV+hSCzuUTXcTntC+p6mLm0d+sBEOHvWX0fR9MLaomu65OuCKhzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIOcZ1awz/uX7SpgEXR1NQxYUJ/3T35vm+UTgrF9wE68Eo3RhZ80CAqd2ZXJzaW9uAQ== ``` And finally, I am proving ownership of the github account by posting this as a gist. ### My publicly-auditable identity: https://keybase.io/urazali2719 https://keybase.io/urazali2719 ### From the command line: Consider the [keybase command line program](https://keybase.io/download https://keybase.io/download). ```bash # look me up keybase id urazali2719 ```

jablue 7y ago

Cool sounds great .

vadikkiev 7y ago

Thanks