11 ms·

A Senior Engineer's Check-List (2019)

249 points by gautamsomani 3y ago

johnea 3y ago
#61: Shorten the checklist...
lr4444lr 3y ago
Wow, 60 items and I don't disagree with any of them.
quantum_state 3y ago
Great list … thanks for sharing
deleted 3y ago
[deleted]
jameshart 3y ago
Not really a 'checklist'. Can anyone honestly go down this list and mark any of the items affirmatively as 'complete'?
- dbalatero 3y ago
  No, but you could keep checking in on them and seeing how you're doing on a semi recurring basis.
- helpfulContrib 3y ago
  You can certainly use the form that way, as your own instance of a checklist, and it seems the site has the purpose of providing such mini 'applications' in a local-store friendly manner - see the Travel checklist on the same site, for example. Pretty nifty, if you think about it. Storage stays local, it looks like .. but I am not an expert. I just like the form of this. 3-digit slashdot ID's notwithstanding, I hope we see a revival of cute little cottage-/hobby sites like this, or a kind of perpetually simple cache of folks who just render their genius to static files, in cute ways, and leave it at that... over and over for a few years.
- donutshop 3y ago
  I agree with this. This is more of a list of reminders to keep in mind IMO.
playingalong 3y ago
I agree with the list and there is nothing wrong with it. Though, I would like to emphasize this is clearly an Individual Contributor kind of a perspective. There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow. Maybe a handful out of the 60 fall into this bucket. Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds).
- Aurornis 3y ago
  > There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow. Well the title is literally about being a “Senior Engineer”, not a manager. That said, there are numerous bullet points about mentoring others, leading by example, and setting work culture. Number 18 is “Be a mentor to a couple of junior engineers.” > Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds). While you’re not wrong, I don't think anyone should expect a checklist titled “Senior Engineer’s Checklist” to cater to management items. A manager’s checklist would subtract a lot of the IC items from this list. Management isn’t a superset of IC work. It’s a different job.
- jameshart 3y ago
  There's also some questionable stuff on here for ICs: > Keep your manager up-to-date on people you have difficulty working with If one of my directs came to a one on one and shared their updated enemy-list with me, I'd be pretty concerned.
  - cratermoon 3y ago
    If one of my directs didn't tell me about difficult-to-work-with people, I'd be concerned. I want to know if there are people everyone finds difficult work with, and the best way to know is to hear from all ICs.
  - alex_lav 3y ago
    The fact that you equate “difficulty working with” as an enemy list suggests to me you’re probably not equipped to be managing people. Respectfully.
karol 3y ago
Flip prio to high, the list shrinks to 11. Tick all and congratulate yourself.
- cratermoon 3y ago
  You mean Company impact? I see "effort" and two categories for impact - Career and Company. Also I notice that there's nothing in the "managers" category that has high company impact. Seems about right.
deleted 3y ago
[deleted]
karol 3y ago
It's the same as the problem of finding a good cleaner. If someone is responsible, thorough, turns up on time, has attention to detail, can handle delicate objects, is trustworthy around children and has good manners - then that person is already too good to be an ordinary cleaner and will get hired elsewhere, become a manager or a business owner.
- medstrom 3y ago
  I don't think the world permits so easy mobility. I have worked with cleaners who ticked all those boxes, they were still stuck in their job. Meanwhile not all managers tick those boxes.
- Horffupolde 3y ago
  It’s the eternal paradox of life.
cratermoon 3y ago
The only part of this I disagree with is "Couple of years of Relevant Practical Experience" is senior. Intermediate, sure. Senior should be at least five years AND at least two projects.
a_square_peg 3y ago
Assuming technical competency is given, I think senior engineer really needs to do two things well: 1. Be able to make a design decision - among multiple options and with incomplete data and uncertainties, a senior engineer needs to be able to make a decision and be accountable for it in order to move the project forward. I think a good interview question would be to ask about their difficult design decisions. 2. Be able to identify wrong solution (most of the time) - maybe this comes with technical competency but a lot of resource is wasted chasing solutions that with the benefit of experience, should have been evident early on.
- beebmam 3y ago
  Disagree. A senior engineer should make evidence based decisions, as should any engineer. If there's missing evidence for a conclusion, then a senior engineer should be able to design experiments which gather more evidence to derive a conclusion. Senior engineers should not be con-men.
  - CapitalistCartr 3y ago
    That sounds great, but hard decisions are hard because there isn't time, money, other resources to have all the facts, yet a decision must be made. There might not even be any way to know for sure without taking one path. Experience is all we have to guide us. Progress is full of such decisions, made in a gray fog. Fear of being wrong is paralyzing.
    - galaxyLogic 3y ago
      Exactly. My favorite metaphor for SW-development is playing chess. When you make a move, a decision, new choices, new decisions to make, open up and other ones may no longer be practical. What you decide and do now, affects what you can and must decide next. Except unlike in chess we don't really have the exact rules of the game anywhere. Still we must make choices which affect what moves can be chosen later. It is also like building a house, once you decide how to build the ground-floor and what it stands on, that greatly affects how the floors above that can be built (not too heavy, not too light etc.). It is often difficult to understand all the consequences of a design decision, what can be done and chosen after that, until you actually implement that design.
Aurornis 3y ago
I’ve had the good fortune to hire and work with a lot of ambitious engineers. One trap with lists like this is that it can be easy to lose sight of your core workload. On more than one occasion I’ve had to ask senior engineers to pump the brakes on all of their mentoring, leading, organizing, example-setting, and helping activities because their own work was not getting done. You only have so many hours in a work week. Get your priority work done first, then layer in additional activities selectively. Don’t think you need to be doing all of these things on the list all of the time.
- fifilura 3y ago
  Then maybe that person has implicitly become a manager. And to mentor and help others may very well be the best spent time for the company as a whole. But then his biggest tasks should be done by one of his more junior team-members.
  - Longhanks 3y ago
    If someone disregards his or her tasks without communication to his or her superior, and fails to get the tasks he or she was hired for done, a promotion is hardly the right answer in my opinion.
  - proc0 3y ago
    This is why most software companies tend to ship buggy messes that need to be constantly patched and updated. Software engineers never get to fully focus on optimizing software for the long term because as they gain experience within the org. they are moved away from engineering into management of other engineers. I think I get the motivation, an engineer managing a team of engineers can achieve "more" in less time. However I put "more" in quotes because a single expert engineer can build better, faster, and more reliable than an entire team, once they have mastered the systems and tools. That will never happen if they rarely touch code and instead attend meetings to talk about planning and scheduling.
    - za3faran 3y ago
      The promotion incentives at least in the bigger companies generally do not favor becoming a domain expert in the product. Everyone wants to become "staff+" and rake in the big bucks, and it's a race to build an empire at the cost of getting things done many times.
trav4225 3y ago
I always find advice like this a little confusing. A lot of these things seem (to me) to be none of the engineers' business. To me, engineers receive specs from management and implement solutions that meet those specs. And that's it. I suppose my personal experience must not be how things work elsewhere! Kind of fascinating, and it makes me wonder if people enjoy all this extra responsibility and how things go when engineers disagree with management.
- nuancebydefault 3y ago
  Sometimes (often) you feel like following the requirements is not the correct way, because they look fine at first sight but not so bright when doing a first analysis or design. Then you tend to get involved with the "none of my business" business.
- iteria 3y ago
  What you're talking about to me is mid-level work. Seniors deal with ambiguity and feasibility analysis. Non-technical people often don't understand the level of tech necessary. They'll say, "I want a bridge about this long" very nice, but but did you consider the about wind that whistles through this area ? Also, how many lanes? Yeah that many is too few because once this bridge goes up we're not gonna be reasonably able to close it even for maintenance. We need at least 4 lanes. Isn't there a cement shortage? Hm.. maybe we can use this material instead? No. I don't think building with wood for this length is a great idea. You get the picture. Yes lead developers exist, but they only have so much time to do little battles and they're busy making sure the big things are arguing correctly. Senior engineers should be able to talk to design about a redesign necessary because iOS just isn't capable of this it turns out or the cool effect you saw is only available on a version we don't use and can't update to right because complex reason. If you're just taking your requirements and working without having to negotiate with another person, you're probably not doing senior work. Some of it I the site I don't think is senior work really unless you're a tiny shop, but they're not weird since these are all skills a for senior adjacent roles that any senior might be called on to take randomly. It's not uncommon in many shops for leads to be a spontaneous and temporary role for some project that disappears on major release.
nuancebydefault 3y ago
Zooming in on check 4, ask 'why' until you find the root. For some reason I tend to do this almost naturally, with mixed results though. Especially when reviewing code, you often see how things can be done more simply, and asking "why" to the reviewee can sometimes backfire because of touching a sore point. Thinking about it, not only when reviewing code. Also, when you question the used processes you often bump into "we found out from experience this works best" or "why change a working process". So always using the "why" tactic can be frustrating at times.
- kwhitefoot 3y ago
  Asking why has to be done much earlier in processes than that. You need to interrogate the person or department that is asking for something to get to the thing that they actually need instead of merely what they think is the easiest thing for you to deliver. I was often able to reduce the scope and cost of parts of projects by pestering the domain experts who wanted something to explain why they wanted it. I often discovered that they believed that what they really wanted was impossible or too difficult so they had pre-emptively asked for the second best. Once I understood what they really needed I could tell give them a proper estimate of the cost of solving the actual problem. In some cases I was able to automate away the job that they had asked me to merely provide a better user interface for for and do that with less effort and cost.
  - nuancebydefault 3y ago
    This is very interestering, would you care to elaborate with a concrete example of what happened?
    - kwhitefoot 3y ago
      It was mostly a long time ago so the details are a bit hazy now. Generally it went something like this: The domain expert (our internal customer) has a badly specified procedure for picking the correct configuration for some sub-assembly. It depends on a number of different parameters some of which are continuous variables and some are discrete. Which continuous variables are relevant depends on which combination of the discrete values are chosen; for instance choosing nominally equivalent parts from different suppliers can mean having to express the specification in different terms. So the customer asks for a user interface that will make it easier for the end user (not the domain expert, a less qualified person) to explore the database and a few simple tools to do some calculations so that they can decide which parts to order. While writing up my proposed solution I realize that a lot of what the domain expert has expressed as matters of fine professional judgement look suspiciously like they are in fact rule bound from the point of view of the actual end user. When I quiz the domain expert about this they tell me that they though that the task was too complicated to automate. When I finally extract from them the actual rules I see that the actual end user has no real freedom of choice, that the rules change about once a decade, and that all that is requires is a small form to gather the two pieces of information that are not already in the system and a fairly small set of database queries. All the rules can be encoded easily in a couple of small database tables that the domain expert can update when the conditions change. I point out that this is actually less work, can be delivered sooner, and is most likely more reliable. The domain expert agrees and we are both happy. Over the decades that I spent writing applications I frequently found that customers failed to ask for what they really wanted because of mistaken beliefs about the relative difficulty of various kinds of computing tasks. Instead of asking for what they needed they asked for what they thought we could provide. This frequently caused more delay than if they had simply asked for the best solution from their point of view. Often the customer asks for what they want rather than what they need. Very often what they want is rooted in solutions or partial solutions that they have seen or implemented themselves. They think that they simply need a better version of their own home grown tool when in fact their tool is the way it is simply because of the limitations of the tools they had to hand, usually Excel programmed by someone doing it instead of the engineering that they are actually competent in. Using the appropriate solution, often an SQL database and a very simple front end, simplifies the task dramatically and makes the tool both easier to use and much simpler to maintain.
ChrisMarshallNY 3y ago
> Resist the urge to refactor major systems to achieve simplification, because there's a risk you will end up with a similarly complex system after some time Word
TensorTinkerer 3y ago
Really digging the list, especially the emphasis on simplicity in systems. Reminds me of that age-old principle: "What is the simplest thing that could possibly work?" I've been on teams where we battled convoluted systems. Sometimes a refactor, even a daunting one, clears so much technical debt and revitalizes the team. The 'ask "why"' bit? Gold. It's not just about coding but understanding the bigger picture. Feedback loops in software? Amazing. Feedback in career growth? Equally crucial. It's a solid reminder that our game isn't just code; it's the soft skills too. They can seriously make or break your trajectory. But as always, while guides are great, everyone's path in tech is unique. It's like code; it evolves, iterates, and adapts.
shikshake 3y ago
“Strive for deep technical expertise in technologies used” In general, how would someone go about this? Is it just something that should happen over time or is there a method/goal to strive for?
- kbutler 3y ago
  Continuing study and investigation after achieving functional competence. Learn more apis, dig in to implementation, read other people's code, ... There's a big difference between engineers who consistently, proactively study and learn vs those who just leverage previous knowledge. And I've experienced both sides of that in myself.
- renegade-otter 3y ago
  It's possible if you keep things simple, but it's a rather naive goal in most places which have already grown in size and complexity. Just knowing what's happening with the other teams and how your work fits into it is already a full-time job. I've spent DAYS on Slack without getting anything done - I had to get up early in the morning. I wrote about something related recently. "I am not your Cloud person": https://renegadeotter.com/2023/07/26/i-am-not-your-cloud-person.html https://renegadeotter.com/2023/07/26/i-am-not-your-cloud-per...
- alex_lav 3y ago
  Don’t stop learning at the end of your use-case for a piece of tech. If your team uses a tool, understand approaches you didn’t take, trade offs and ultimately why you chose the path you chose. Understand even other pieces of tech and their approaches. Also, deeply understand failure scenarios and how to mitigate them. Basically just dig in beyond “it works”. You’d be surprised how many devs never read a tool’s docs if they don’t absolutely have to.
- Agingcoder 3y ago
  Read books, on a variety of topics, including the ones you don’t know about. A book will give you a much broader and deeper understanding of most topics than random blog posts on the internet. Make sure you read one or two a year, and think about how you’d apply what you’re learning at work. Even better, find an actual application at work. I’ve found that solving tricky problems ( horrible network related issue, performance bugs, strange behaviour of program/framework/os, someone you know deciding to use new tech you don’t know about etc ) is usually a good way of finding a topic to explore. Find someone who’s interested in actively learning things, it makes things a lot more pleasant, and it’s easier to remain motivated. You don’t have to learn the same things - just share the fun stuff you’re learning. Finally, and most importantly : it’s ok if you’re not learning as quickly as when you were at university. It’s not a competition. You have a full time job, don’t have a lot of time, so just make sure that you enjoy learning, so that you keep doing it !
dang 3y ago
Discussed at the time: Show HN: A Senior Engineer's CheckList - https://news.ycombinator.com/item?id=20914236 https://news.ycombinator.com/item?id=20914236 - Sept 2019 (143 comments) (that shouldn't have been a Show HN! too late now)
deleted 3y ago
[deleted]
crtified 3y ago
Point 1 ("Understand the business aspect of your work, and what makes money. Eventually, only that matters.") is depressing to me.
sacnoradhq 3y ago
> 8. Do not be adamant about your views. I worked at a MAANG where this was not the case. The pecking order of "seniority" was who was the most "right" and who could poke the most holes in everyone else's ideas while denying others' contributions while bragging about how essential and important their work was in a semi-agro manner that discouraged dissent and curiosity. In my view, marks of intelligence include lacking strong biases, comfort with ambiguity, be willing to propose hypotheses, experiment, gather data, and be proven wrong.
29athrowaway 3y ago
There is nothing about engineering in that list.
danwee 3y ago
> Strive for deep technical expertise in technologies used And that alone occupies most of my (working/free) time. Not sure how I'm supposed to keep up with the rest of the list. To know technologies is one thing, to have deep tech expertise in many technologies is a completely different one.
GreedClarifies 3y ago
A lot of Amazon in that list, that's not a bad thing, one of Amazon's greatest strengths is its principles. Did the author spend time at Amazon?
tennisflyi 3y ago
Glad number one was explicit. It might not be what you consider but for most others it is.
donutshop 3y ago
Relevant discussion from the past https://news.ycombinator.com/item?id=16367997 https://news.ycombinator.com/item?id=16367997
mellosouls 3y ago
"Understand the business aspect of your work, and what makes money. Eventually, only that matters." Applies only to commercial organisations (and no, even with those money is not the be-all and end-all) so not impressive as a number one, at least with that wording. Understanding business is clearly key though. TBH that and the rather self-satisfied "it is useful to any software engineer, it is especially useful to senior engineers." on a rather enigmatic website lacking in other interesting writing put me off considering it further.
zer8k 3y ago
[flagged]
- deleted 3y ago
  [deleted]
- lolinder 3y ago
  > Be amazing at bullshitting. Small project? Make the mole hill into mount everest. Big project? Act like you just saved the company. Study people. Your manager and their manager have exploitable weaknesses. ... Fuck people who think honesty is how you get ahead. ... Exploit every weakness. Don't be an asshole of course. That won't get you ahead. Following the advice in this paragraph—bullshitting and exploiting people to get ahead—makes you into an asshole. There's no way around it. For myself, I'd rather not "get ahead" if "getting ahead" requires turning myself into that which I despise. I've had to work with people like this, and I will not bring that hell on anyone else.
- mannyv 3y ago
  Sounds like the former staff from Twitter!
arkoinad 3y ago
Some of the points are very company/team specific dependent. And also dependent on culture of the company.
vkaku 3y ago
This theoretical expectation of such engineers is deeply flawed. - Every level balances between execution and communication. - Many companies fail due to not scoping and not collaborating enough. - Any engineer should follow good practices but prioritize creativity over processes whenever they want to thrive. - Tech is a creative industry. Scrum and other overhead processes have not led to a productivity increase. Become a Senior Engineer. Just not only in theory.

249 points by gautamsomani 3y ago

johnea 3y ago

#61: Shorten the checklist...

lr4444lr 3y ago

Wow, 60 items and I don't disagree with any of them.

quantum_state 3y ago

Great list … thanks for sharing

deleted 3y ago

[deleted]

jameshart 3y ago

Not really a 'checklist'. Can anyone honestly go down this list and mark any of the items affirmatively as 'complete'?

dbalatero 3y ago
No, but you could keep checking in on them and seeing how you're doing on a semi recurring basis.
helpfulContrib 3y ago
You can certainly use the form that way, as your own instance of a checklist, and it seems the site has the purpose of providing such mini 'applications' in a local-store friendly manner - see the Travel checklist on the same site, for example. Pretty nifty, if you think about it. Storage stays local, it looks like .. but I am not an expert. I just like the form of this. 3-digit slashdot ID's notwithstanding, I hope we see a revival of cute little cottage-/hobby sites like this, or a kind of perpetually simple cache of folks who just render their genius to static files, in cute ways, and leave it at that... over and over for a few years.
donutshop 3y ago
I agree with this. This is more of a list of reminders to keep in mind IMO.

playingalong 3y ago

I agree with the list and there is nothing wrong with it. Though, I would like to emphasize this is clearly an Individual Contributor kind of a perspective. There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow. Maybe a handful out of the 60 fall into this bucket. Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds).

Aurornis 3y ago
> There are hardly any bullet points encouraging building and maintaining work culture, growing other people, serving as an example to follow. Well the title is literally about being a “Senior Engineer”, not a manager. That said, there are numerous bullet points about mentoring others, leading by example, and setting work culture. Number 18 is “Be a mentor to a couple of junior engineers.” > Thus don't consider this list anywhere near complete if your career path envisions being a manager (of different kinds). While you’re not wrong, I don't think anyone should expect a checklist titled “Senior Engineer’s Checklist” to cater to management items. A manager’s checklist would subtract a lot of the IC items from this list. Management isn’t a superset of IC work. It’s a different job.
jameshart 3y ago
There's also some questionable stuff on here for ICs: > Keep your manager up-to-date on people you have difficulty working with If one of my directs came to a one on one and shared their updated enemy-list with me, I'd be pretty concerned.
- cratermoon 3y ago
  If one of my directs didn't tell me about difficult-to-work-with people, I'd be concerned. I want to know if there are people everyone finds difficult work with, and the best way to know is to hear from all ICs.
- alex_lav 3y ago
  The fact that you equate “difficulty working with” as an enemy list suggests to me you’re probably not equipped to be managing people. Respectfully.

karol 3y ago

Flip prio to high, the list shrinks to 11. Tick all and congratulate yourself.

cratermoon 3y ago
You mean Company impact? I see "effort" and two categories for impact - Career and Company. Also I notice that there's nothing in the "managers" category that has high company impact. Seems about right.

deleted 3y ago

[deleted]

karol 3y ago

It's the same as the problem of finding a good cleaner. If someone is responsible, thorough, turns up on time, has attention to detail, can handle delicate objects, is trustworthy around children and has good manners - then that person is already too good to be an ordinary cleaner and will get hired elsewhere, become a manager or a business owner.

medstrom 3y ago
I don't think the world permits so easy mobility. I have worked with cleaners who ticked all those boxes, they were still stuck in their job. Meanwhile not all managers tick those boxes.
Horffupolde 3y ago
It’s the eternal paradox of life.

cratermoon 3y ago

The only part of this I disagree with is "Couple of years of Relevant Practical Experience" is senior. Intermediate, sure. Senior should be at least five years AND at least two projects.

a_square_peg 3y ago

Assuming technical competency is given, I think senior engineer really needs to do two things well: 1. Be able to make a design decision - among multiple options and with incomplete data and uncertainties, a senior engineer needs to be able to make a decision and be accountable for it in order to move the project forward. I think a good interview question would be to ask about their difficult design decisions. 2. Be able to identify wrong solution (most of the time) - maybe this comes with technical competency but a lot of resource is wasted chasing solutions that with the benefit of experience, should have been evident early on.

beebmam 3y ago
Disagree. A senior engineer should make evidence based decisions, as should any engineer. If there's missing evidence for a conclusion, then a senior engineer should be able to design experiments which gather more evidence to derive a conclusion. Senior engineers should not be con-men.
- CapitalistCartr 3y ago
  That sounds great, but hard decisions are hard because there isn't time, money, other resources to have all the facts, yet a decision must be made. There might not even be any way to know for sure without taking one path. Experience is all we have to guide us. Progress is full of such decisions, made in a gray fog. Fear of being wrong is paralyzing.
  - galaxyLogic 3y ago
    Exactly. My favorite metaphor for SW-development is playing chess. When you make a move, a decision, new choices, new decisions to make, open up and other ones may no longer be practical. What you decide and do now, affects what you can and must decide next. Except unlike in chess we don't really have the exact rules of the game anywhere. Still we must make choices which affect what moves can be chosen later. It is also like building a house, once you decide how to build the ground-floor and what it stands on, that greatly affects how the floors above that can be built (not too heavy, not too light etc.). It is often difficult to understand all the consequences of a design decision, what can be done and chosen after that, until you actually implement that design.

Aurornis 3y ago

I’ve had the good fortune to hire and work with a lot of ambitious engineers. One trap with lists like this is that it can be easy to lose sight of your core workload. On more than one occasion I’ve had to ask senior engineers to pump the brakes on all of their mentoring, leading, organizing, example-setting, and helping activities because their own work was not getting done. You only have so many hours in a work week. Get your priority work done first, then layer in additional activities selectively. Don’t think you need to be doing all of these things on the list all of the time.

fifilura 3y ago
Then maybe that person has implicitly become a manager. And to mentor and help others may very well be the best spent time for the company as a whole. But then his biggest tasks should be done by one of his more junior team-members.
- Longhanks 3y ago
  If someone disregards his or her tasks without communication to his or her superior, and fails to get the tasks he or she was hired for done, a promotion is hardly the right answer in my opinion.
- proc0 3y ago
  This is why most software companies tend to ship buggy messes that need to be constantly patched and updated. Software engineers never get to fully focus on optimizing software for the long term because as they gain experience within the org. they are moved away from engineering into management of other engineers. I think I get the motivation, an engineer managing a team of engineers can achieve "more" in less time. However I put "more" in quotes because a single expert engineer can build better, faster, and more reliable than an entire team, once they have mastered the systems and tools. That will never happen if they rarely touch code and instead attend meetings to talk about planning and scheduling.
  - za3faran 3y ago
    The promotion incentives at least in the bigger companies generally do not favor becoming a domain expert in the product. Everyone wants to become "staff+" and rake in the big bucks, and it's a race to build an empire at the cost of getting things done many times.

trav4225 3y ago

I always find advice like this a little confusing. A lot of these things seem (to me) to be none of the engineers' business. To me, engineers receive specs from management and implement solutions that meet those specs. And that's it. I suppose my personal experience must not be how things work elsewhere! Kind of fascinating, and it makes me wonder if people enjoy all this extra responsibility and how things go when engineers disagree with management.

nuancebydefault 3y ago
Sometimes (often) you feel like following the requirements is not the correct way, because they look fine at first sight but not so bright when doing a first analysis or design. Then you tend to get involved with the "none of my business" business.
iteria 3y ago
What you're talking about to me is mid-level work. Seniors deal with ambiguity and feasibility analysis. Non-technical people often don't understand the level of tech necessary. They'll say, "I want a bridge about this long" very nice, but but did you consider the about wind that whistles through this area ? Also, how many lanes? Yeah that many is too few because once this bridge goes up we're not gonna be reasonably able to close it even for maintenance. We need at least 4 lanes. Isn't there a cement shortage? Hm.. maybe we can use this material instead? No. I don't think building with wood for this length is a great idea. You get the picture. Yes lead developers exist, but they only have so much time to do little battles and they're busy making sure the big things are arguing correctly. Senior engineers should be able to talk to design about a redesign necessary because iOS just isn't capable of this it turns out or the cool effect you saw is only available on a version we don't use and can't update to right because complex reason. If you're just taking your requirements and working without having to negotiate with another person, you're probably not doing senior work. Some of it I the site I don't think is senior work really unless you're a tiny shop, but they're not weird since these are all skills a for senior adjacent roles that any senior might be called on to take randomly. It's not uncommon in many shops for leads to be a spontaneous and temporary role for some project that disappears on major release.

nuancebydefault 3y ago

Zooming in on check 4, ask 'why' until you find the root. For some reason I tend to do this almost naturally, with mixed results though. Especially when reviewing code, you often see how things can be done more simply, and asking "why" to the reviewee can sometimes backfire because of touching a sore point. Thinking about it, not only when reviewing code. Also, when you question the used processes you often bump into "we found out from experience this works best" or "why change a working process". So always using the "why" tactic can be frustrating at times.

kwhitefoot 3y ago
Asking why has to be done much earlier in processes than that. You need to interrogate the person or department that is asking for something to get to the thing that they actually need instead of merely what they think is the easiest thing for you to deliver. I was often able to reduce the scope and cost of parts of projects by pestering the domain experts who wanted something to explain why they wanted it. I often discovered that they believed that what they really wanted was impossible or too difficult so they had pre-emptively asked for the second best. Once I understood what they really needed I could tell give them a proper estimate of the cost of solving the actual problem. In some cases I was able to automate away the job that they had asked me to merely provide a better user interface for for and do that with less effort and cost.
- nuancebydefault 3y ago
  This is very interestering, would you care to elaborate with a concrete example of what happened?
  - kwhitefoot 3y ago
    It was mostly a long time ago so the details are a bit hazy now. Generally it went something like this: The domain expert (our internal customer) has a badly specified procedure for picking the correct configuration for some sub-assembly. It depends on a number of different parameters some of which are continuous variables and some are discrete. Which continuous variables are relevant depends on which combination of the discrete values are chosen; for instance choosing nominally equivalent parts from different suppliers can mean having to express the specification in different terms. So the customer asks for a user interface that will make it easier for the end user (not the domain expert, a less qualified person) to explore the database and a few simple tools to do some calculations so that they can decide which parts to order. While writing up my proposed solution I realize that a lot of what the domain expert has expressed as matters of fine professional judgement look suspiciously like they are in fact rule bound from the point of view of the actual end user. When I quiz the domain expert about this they tell me that they though that the task was too complicated to automate. When I finally extract from them the actual rules I see that the actual end user has no real freedom of choice, that the rules change about once a decade, and that all that is requires is a small form to gather the two pieces of information that are not already in the system and a fairly small set of database queries. All the rules can be encoded easily in a couple of small database tables that the domain expert can update when the conditions change. I point out that this is actually less work, can be delivered sooner, and is most likely more reliable. The domain expert agrees and we are both happy. Over the decades that I spent writing applications I frequently found that customers failed to ask for what they really wanted because of mistaken beliefs about the relative difficulty of various kinds of computing tasks. Instead of asking for what they needed they asked for what they thought we could provide. This frequently caused more delay than if they had simply asked for the best solution from their point of view. Often the customer asks for what they want rather than what they need. Very often what they want is rooted in solutions or partial solutions that they have seen or implemented themselves. They think that they simply need a better version of their own home grown tool when in fact their tool is the way it is simply because of the limitations of the tools they had to hand, usually Excel programmed by someone doing it instead of the engineering that they are actually competent in. Using the appropriate solution, often an SQL database and a very simple front end, simplifies the task dramatically and makes the tool both easier to use and much simpler to maintain.

ChrisMarshallNY 3y ago

> Resist the urge to refactor major systems to achieve simplification, because there's a risk you will end up with a similarly complex system after some time Word

TensorTinkerer 3y ago

Really digging the list, especially the emphasis on simplicity in systems. Reminds me of that age-old principle: "What is the simplest thing that could possibly work?" I've been on teams where we battled convoluted systems. Sometimes a refactor, even a daunting one, clears so much technical debt and revitalizes the team. The 'ask "why"' bit? Gold. It's not just about coding but understanding the bigger picture. Feedback loops in software? Amazing. Feedback in career growth? Equally crucial. It's a solid reminder that our game isn't just code; it's the soft skills too. They can seriously make or break your trajectory. But as always, while guides are great, everyone's path in tech is unique. It's like code; it evolves, iterates, and adapts.

shikshake 3y ago

“Strive for deep technical expertise in technologies used” In general, how would someone go about this? Is it just something that should happen over time or is there a method/goal to strive for?

kbutler 3y ago
Continuing study and investigation after achieving functional competence. Learn more apis, dig in to implementation, read other people's code, ... There's a big difference between engineers who consistently, proactively study and learn vs those who just leverage previous knowledge. And I've experienced both sides of that in myself.
renegade-otter 3y ago
It's possible if you keep things simple, but it's a rather naive goal in most places which have already grown in size and complexity. Just knowing what's happening with the other teams and how your work fits into it is already a full-time job. I've spent DAYS on Slack without getting anything done - I had to get up early in the morning. I wrote about something related recently. "I am not your Cloud person": https://renegadeotter.com/2023/07/26/i-am-not-your-cloud-person.html https://renegadeotter.com/2023/07/26/i-am-not-your-cloud-per...
alex_lav 3y ago
Don’t stop learning at the end of your use-case for a piece of tech. If your team uses a tool, understand approaches you didn’t take, trade offs and ultimately why you chose the path you chose. Understand even other pieces of tech and their approaches. Also, deeply understand failure scenarios and how to mitigate them. Basically just dig in beyond “it works”. You’d be surprised how many devs never read a tool’s docs if they don’t absolutely have to.
Agingcoder 3y ago
Read books, on a variety of topics, including the ones you don’t know about. A book will give you a much broader and deeper understanding of most topics than random blog posts on the internet. Make sure you read one or two a year, and think about how you’d apply what you’re learning at work. Even better, find an actual application at work. I’ve found that solving tricky problems ( horrible network related issue, performance bugs, strange behaviour of program/framework/os, someone you know deciding to use new tech you don’t know about etc ) is usually a good way of finding a topic to explore. Find someone who’s interested in actively learning things, it makes things a lot more pleasant, and it’s easier to remain motivated. You don’t have to learn the same things - just share the fun stuff you’re learning. Finally, and most importantly : it’s ok if you’re not learning as quickly as when you were at university. It’s not a competition. You have a full time job, don’t have a lot of time, so just make sure that you enjoy learning, so that you keep doing it !

dang 3y ago

Discussed at the time: Show HN: A Senior Engineer's CheckList - https://news.ycombinator.com/item?id=20914236 https://news.ycombinator.com/item?id=20914236 - Sept 2019 (143 comments) (that shouldn't have been a Show HN! too late now)

deleted 3y ago

[deleted]

crtified 3y ago

Point 1 ("Understand the business aspect of your work, and what makes money. Eventually, only that matters.") is depressing to me.

sacnoradhq 3y ago

> 8. Do not be adamant about your views. I worked at a MAANG where this was not the case. The pecking order of "seniority" was who was the most "right" and who could poke the most holes in everyone else's ideas while denying others' contributions while bragging about how essential and important their work was in a semi-agro manner that discouraged dissent and curiosity. In my view, marks of intelligence include lacking strong biases, comfort with ambiguity, be willing to propose hypotheses, experiment, gather data, and be proven wrong.

29athrowaway 3y ago

There is nothing about engineering in that list.

danwee 3y ago

> Strive for deep technical expertise in technologies used And that alone occupies most of my (working/free) time. Not sure how I'm supposed to keep up with the rest of the list. To know technologies is one thing, to have deep tech expertise in many technologies is a completely different one.

GreedClarifies 3y ago

A lot of Amazon in that list, that's not a bad thing, one of Amazon's greatest strengths is its principles. Did the author spend time at Amazon?

tennisflyi 3y ago

Glad number one was explicit. It might not be what you consider but for most others it is.

donutshop 3y ago

Relevant discussion from the past https://news.ycombinator.com/item?id=16367997 https://news.ycombinator.com/item?id=16367997

mellosouls 3y ago

"Understand the business aspect of your work, and what makes money. Eventually, only that matters." Applies only to commercial organisations (and no, even with those money is not the be-all and end-all) so not impressive as a number one, at least with that wording. Understanding business is clearly key though. TBH that and the rather self-satisfied "it is useful to any software engineer, it is especially useful to senior engineers." on a rather enigmatic website lacking in other interesting writing put me off considering it further.

zer8k 3y ago

[flagged]

deleted 3y ago
[deleted]
lolinder 3y ago
> Be amazing at bullshitting. Small project? Make the mole hill into mount everest. Big project? Act like you just saved the company. Study people. Your manager and their manager have exploitable weaknesses. ... Fuck people who think honesty is how you get ahead. ... Exploit every weakness. Don't be an asshole of course. That won't get you ahead. Following the advice in this paragraph—bullshitting and exploiting people to get ahead—makes you into an asshole. There's no way around it. For myself, I'd rather not "get ahead" if "getting ahead" requires turning myself into that which I despise. I've had to work with people like this, and I will not bring that hell on anyone else.
mannyv 3y ago
Sounds like the former staff from Twitter!

arkoinad 3y ago

Some of the points are very company/team specific dependent. And also dependent on culture of the company.

vkaku 3y ago

This theoretical expectation of such engineers is deeply flawed. - Every level balances between execution and communication. - Many companies fail due to not scoping and not collaborating enough. - Any engineer should follow good practices but prioritize creativity over processes whenever they want to thrive. - Tech is a creative industry. Scrum and other overhead processes have not led to a productivity increase. Become a Senior Engineer. Just not only in theory.