> How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it
This list should also include: How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.
As a junior engineer I found that I respected senior engineers more when they asked me to teach them something they didn't know.
As a senior engineer I feel like I get a lot more respect from the junior engineers when I just admit, "I don't know that can you teach me more or point me at some good resources?". For that matter, I get a lot more respect from other senior engineers when I give them exactly the same response.
That's a great one. An observation that I've made over the years is that junior engineers tend to shy away from asking too many questions, afraid of appearing incompetent, whereas the most senior engineers asked the most questions. At a certain point asking questions becomes less about informing yourself, and more about informing the team (through context shared in meetings, chat). It can even take the form of the Socratic method, using questions to bring others to conclusions that may already appear obvious to you. Much better approach than pushing an idea directly onto others, and leaves plenty of room to change course as a result of the conversation.
Yeah, I’ve also gotten a lot of mileage in the last few years using the emotional version of this. Instead of listening to a proposal and saying “well that obviously won’t perform fast enough” I’ve started saying things like “I love this but I feel nervous that it might be slow once you have it working”. The difference is subtle but important, because I’m being clear I want them to help me dissolve my fear about the performance issues. We’re on the same team in a way we aren’t if I make it confrontational.
I think about it like you have a volume dial that you need to turn up or down depending on the room you're speaking in.
If you're pretty junior, or you work with a lot of loudmouths, you might need to turn the volume up higher to make sure you're listened to. If you're senior, or talking to a group of people more junior than you, you can get away with being a lot softer with your words. (And you often should, to avoid intimidating the juniors). And its not really about volume. Its about your word choice.
Low volume: "Hm, that sounds ok but I'm worried about performance."
High volume: "This will be unworkable because of performance problems. We need preliminary benchmarks, or a plan for solving those problems before we can move ahead."
Maybe.
At the same time I think most senior developers have been through the hype cycle a few times.
Junior to intermediate level devs seem to jump on the latest "silver bullet" trend quite a lot not realising that this happens all the time and probably isn't anywhere near as good as the hype.
I miss working with adults who know not to take the first version personally. To me the difference is not so subtle, the first version is an engineering conversation, the second one is somebody who is clearly pandering.
When I started my career in software testing 20 years ago, the Socratic method was my best friend. It's a great way to lead a developer to a bug. Instead of getting defensive, they're extremely motivated to fix it.
> How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.
(For reference: I've been paying my bills with code for a good 20 years now.)
I've learned 80% of what I know about Javascript, Typescript and React from one dude on my team who was freshly out of university. The dude was (and still is) a damn genius at that stuff.
If he doesn't burn out by overreaching, he'll be a legend by 2025 =)
Same. I’ve been at it for 20 years and just never was in a job that used React or Typescript. In my current job I was paired with a boot camp grad probably ~15 years my junior who has been an amazing mentor as I learned React + Redux + Typescript.
That was me, though perhaps less proficient, until I realized that all the work was basically worthless trash and there's little point in putting my employer before my own interests. Now I can't figure how to do that again!
I have decades of experience, but there’s often stuff I can learn.
Here’s an example: I have developed an SDK, with heavy documentation, but I have found that written docs aren’t actually very useful, as no one reads stuff anymore.
So a new engineer on my project showed me Postman. Before, I’ve used far humbler REST explorers. In turn, I showed him Charles Proxy.
I’ve actually gone way beyond what he needed with it, because it’s a great tool.
It is not a 100% replacement for my docs, but it will help a lot.
I can develop an architecture that is way beyond anything he can do, but it’s worthless, if he can’t write stuff that uses it.
> I can develop an architecture that is way beyond anything he can do, but it’s worthless, if he can’t write stuff that uses it.
A line from another article posted to HN today I remembered is:
"An API without a reference implementation and command-line client is called a gray box."
I totally agree with that. If your API/SDK has an easy way for me to copy/paste some code or command line examples to "play" with it, I'm about 1000% more likely to take it seriously.
In my experience being humble, I most frequently get
“Whaaaaaaaaaat you never heard of that, its so popular, everyone’s into this”
I just wait patiently and stare, maybe an occasional “ah, mmm”
and then eventually say “so can you tell me about it”
and really the answer is no, most people can’t articulate themselves and provide filler instead
it’s usually in relation to anything someone is passionate about, or an assumption they have that supports their passion. such as a social norm or ideal, not just engineering
Anecdote (which serves as a reverse example i.e. senior asking a question):
We were having a regular status call and since the meeting finished early there was a general chit-chat happening.
That is when we started talking about "iphone" and our boss innocently asked "what is iphone" (it had been on the market for a year since its first launch)
We started looking at each other in disbelief. But we knew this about her. She used to openly ask in a meeting without shame on things she did not know. But once she understood something she use to process that info very well.
The team really adored her because she was so good in other managerial things (like defending team, good rapport with individuals, planning, etc).
Back story was that all her time was spent with her 2-3 kids leaving no time for other things.
Key takeaway: stay humble. In my career, I have been antiquated in the past (Flash developer), so I have learned that going to someone and asking what they know is usually a better path. I also call out good contributions from other teammates, because that is what being alive is about.
In the cases where I've been welcoming new individuals into teams it has always been made clear to them by me that there are no stupid questions, everything can be challenged if the argument for it can be made and that I don't know everything and wont/can't come up with all the ideas (ie they could very likely come up with a good idea to a hard problem).
In my experience this has really made it a pleasant experience to introduce new developers (fresh from uni or new to the code base/domain) to the product and team.
Just for context, in the country I reside in there isn't this emphasis on titles in the software space, and as such I am not a formal senior dev at my company. I believe I would have that title if living in a country where such distinction were normal.
But there s also the tendency we all had as juniors to try to push new things we're closer to, rather than try and accept the "old" technology often working just as well while being much simpler.
Not always the case, but when you see people pushing heavy, runtime-script languages full of ambiguity to modernize an old simple compiled code base, it's hard to do the wait and see and show 2 years later to the juniors: "see your lombok spring thing is now absolutely unmaintanable when all it does is 3 multiplications"
It s often a balance since nobody likes change, junior like senior, and often both sides have their crap.
I’m pretty sure this extends into all roads of life. Being able to admit you don’t know something instead of acting like you is a good trait. At the very least people won’t look at you and assume you’re completely full of shit.
The best example of this is pair programming with someone for any length of time. No one has a proper subset of knowledge it is is immediately apparent and both sides value the exchanges.
And often the interactions themselves are the teachers. My mind was blown when a particularly bright child asked me what's the difference between a dream and reality. The best I could come up with is that this 'reality' has a larger continuity and is the one that people in this large continuation agree to call 'real'. I don't know what I could have said if he mentioned a recurring dream with a continuing state. I did say that boils down to a label assignment in case it that should ever come up.
My favourite definition of reality is the stuff that doesn't go away when you stop believing in it.
This makes reality a social phenomenon, beyond just physics. For example, institutions are a reality because many people believe in them; the police don't go away when criminals stop believing in the law.
If you get enough people to believe in your dream, it can become real, self-sustaining. Neil Gaiman wrote a nice short story, taking the idea literally - A Dream of a Thousand Cats.
I don't understand this comment. Is "the implication" from my comment or the parent comment? Is it the dreams I talked about, or the dreams that the parent comment's child interlocutor was talking about? By never involving any of "these things", are you talking about institutions?
To be more verbose, by "institution" I mean stable, recurring patterns of behaviour (much like https://en.wikipedia.org/wiki/Institution), which isn't that far off of the continuity point made by the parent.
> How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.
Definitely! This is something I do a lot and love to do. I’m excited when i realise “oh, rather than reading and reading in this topic - I can ask (a person who happens to be junior) if they’re not too busy”.
The actual problem in that case (when you need a closed door for something like this) is that you are part of a team without trust and you senior staff has not yet learned how to make themselves vulnerable.
It depends on what you're asking about. I remember an older engineer asking me what the term "amortized analysis" meant and that made me write him off as someone who doesn't know basic CS concepts (he was still a great product engineer, but I never once went to him for technical help afterwards).
In hindsight, I guess it's sort of forgivable given his age. The topic probably wasn't even invented yet so he couldn't have learned about it in school.
I'd never heard that term, so I looked it up. I was definitely familiar with the concept, but never heard that term for it before.
Not everyone learns the same terms for the same concepts. Maybe you should be a little more accepting that not everyone had the same education you did.
I am curious, what other name does it go by? I had a strong response because this came up while arguing about the cost of appending to a vector in loop. He had no idea what I meant when I said it was "constant time amortized" and didn't seem to know how resizable array work. This is always the first data structure you learn in CS 101 so I am surprised people are disagreeing that it is basic CS knowledge.
Knowing the generally used names of things isn't the same as knowing the things.
"All science is either physics or stamp collecting." -- Ernest Rutherford.
I suspect there are many people who understand the Big-O, Omega, Theta, and Little-O implications (the physics) but might not have heard the term "constant time amortized" (the stamp collecting).
(Not that knowing accepted names is bad, it's much much easier to communicate when everyone shares a set of terms that they agree on the meaning of...)
I'm old enough to remember that Microsoft got this wrong back in the early 90s. In early versions of Microsoft Foundation Classes, which Windows C++ programmers were using before the STL took over and std::string became the thing, repeatedly appending a character to a string (I think it was CString) was quadratic, because they didn't increase array size by a multiplicative factor, but by a linear amount, so you'd get a ton of reallocation and copying. I used to use versions of this as an interview question.
However, language for concepts evolves with time, and younger programmers shouldn't assume that older programmers don't know a concept because they learned it by a different name. (Though they might not know the concept).
In early versions of Microsoft Foundation Classes … repeatedly appending a character to a string (I think it was CString) was quadratic, because they didn't increase array size by a multiplicative factor, but by a linear amount, so you'd get a ton of reallocation and copying.
I remember seeing production code slow to a crawl once because of that one. It wasn’t long after I’d left university, where I’d studied CS but the lectures on complexity theory had seemed quite theoretical at the time. Suddenly, here was a vivid example of how it could cause a problem in practice, in a situation as everyday as putting some text in a UI. The solution — using a string builder — then led me to several other principles about choosing an efficient internal representation for data and it being OK not to convert that data into its “true” form until you’re ready to use it. I suppose I should thank whoever made the original mistake, because despite causing a frustrating afternoon with a profiler, it also created several lightbulb moments early in my career.
It reminds me a bit more of talking about p50 vs p99 latency times but where we’re not measuring production data, more like what we’re guessing production loads will look like.
Just a data point: I could guess what you meant by “constant time amortized” but I’ve never heard of “amortized analysis”. I’ve learned the same concepts under “big O notation” or just “complexity”.
I suggest that you consider whether it’s possible that other people know the same concept under a different name and don’t write them off as quickly if they don’t know your favorite term.
Amortize is what you do with the loan on your home; never heard that particular word in this context.
I am surprised at how blithely you assume the terminology you learned at your particular college is universal, and how parochially you seem to look down on people just because they don't share that particular terminology.
Replace "amortized" with "on average" and you'll have the basic concept.
A constant time operation has bounded runtime for every input, but an amortized constant time operation can allow for much longer runtimes so long as they happen sufficiently rarely. Concretely, doing an amortized constant time operation N times should be O(N).
It sounds like "amortized" is close to mathematically meaningless in that case.
Why not use actual statistics jargon at that point?
Sometimes we need to realize that the reactions of people inside of the software community are almost purely due to their own personal (usually social) insecurities and are not worth addressing.
We have an entire thread giving credibility to someone who absolutely idiotically dismissed another person for not knowing the meaning of a single word.
The person who was temporarily ignorant of the meaning of that word is not the one I am thinking needs to be ignored here.
To expand on @hansvm answer, an example would be a hash table.
Insertion is O(1) (constant time), most of the time.
But once in a while the collection will need to increase the size of the underlying array, which causes the entire table to be reorganized. That specific insertion will then be O(N) (where N is the size of table). The good news is that this reorganization happens only once every N insertions.
So amortized insertion is O(1), even if in the worst case it can be O(N). Depending on your use case you can hand wave the worst case away with "amortized it's constant time", or you can choose a tree instead, for a more predictable O(log N), or you could use some other mitigating tactic, like initializing your hash table with enough storage _for all use cases_ so you can guarantee O(1).
One of the most substantial, frequent mistakes I see from junior developers is writing off the skills of their colleagues because of perceived gaps in knowledge.
Everyone has blind spots. I have a PhD in computer science. I wouldn't think any lesser of someone's technical chops if they weren't familiar with the term, so long as they quickly understood it when explained.
Don't conflate knowing the term with (really) knowing the concept. Some people might know what you're talking about even without having ever heard the term.
Counter-point: I had never heard the term "amortized analysis" before (I am self-taught) but when I looked it up, I realized "oh I've done this kind of thing before" and immediately understood what it was.. I just didn't know this kind of aggregated profiling had it's own name...
So my advice would be don't be too quick to judge people based on assumptions you make about them.
A fantastic list. I find #11 to be especially critical to one's career growth:
> How to give up your baby, that project that you built into something great, so you can do something else
This is the only way to really scale oneself, while growing others in the process. Hanging on to a project indefinitely can rob you of an opportunity to tackle bigger, more challenging problems. It's so easy to get stuck on a comfortable track, feeling like (and probably being) an indispensable subject matter expert, while the bigger fish get away, often without being aware of them or having the necessary bandwidth to even consider their existence. This, in my mind, is one of the big differences between a senior and a staff engineer (where such distinctions exist).
Agree completely. I failed greatly at #11 at my last job. And payed for years. And absolutely second your endorsement of The Managers Path. If anyone here has ever read a “management” book and been baffled by how stupid it was, know that this book is very much a different breed.
This also seems to be one of the biggest things I've seen small but great open source projects mishandle. As the userbase becomes larger they need to hire more devs but that means not having as much control and others doing things that you did before. Learning to delegate (#3, #8, #9, #10, #12, #18, #20, #22) is a really difficult task (because it takes all those points). It is the transitioning from an mostly an engineer and partly a manager to mostly manager and maybe engineering that many engineers find difficult.
I'm very much afraid of that one on my current project. I'm a solo developer on the front-end part of an application, I've been asking for people to help me out, and even suggested raising money and opening up a can of consultants (I used to work as one, I know some good ones that can give this project a boost). But on the other hand, I've been working on this for a year and a half now. Objectively it's not that much code yet, I guess (in the 10K LOC region), but I'm just afraid all of my technical choices will be overridden.
Mind you, I also try to use ADRs (architecture decision records), which basically force me and others to think about and defend a decision - something I've always missed in any project I've been in.
#11 is probably true in the general case, but for me I am the only engineer in the company on a revenue-based bonus scheme due to my ownership of a pet project. It also doesn't stop me from working on other things. Obviously, if the company have the impression that 100% of your time needs to be on X then that's bad and they're probably getting that impression from you yourself.
You'll really understand this business once you get to the point where you can't wait to give up the "grown up baby" to some junior who will be stuck with it for some time to come. Of course only internally, showing such attitude makes getting rid of an overexploited project harder.
This reads like something from Robert A. Heinlein's Lazarus Long character.
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
This is a quote I stumbled more than 10 years ago and that stuck with me since. Then I read Adam Smith's Wealth of Nations, where he unequivocally explains how skill/job specialization is simply a product of demography. I still agree with the sentiment of Heinlein as a personal ethic, but I have made my peace with specialization.
In the last few centuries, we have reached a critical mass of scientific and technical knowledge where any further advances require a tremendous amount of specialization. There's no way or point in fighting tthat.
As someone pointed out on a podcast I listed yesterday, wheels get reinvented all the time, as not every whell fits all travel purposes equally well. :)
Look, in most corps you can shelter for a really long time at the lowest non up-or-out position. In fact to some degree that's the safest level to stay at, though the worst paid one. It's totally fine with everyone.
This whole damn list can be boiled down to "how to communicate effectively" and isn't very actionable at all by the reader. Which isn't too much of a surprise to me because that's the exact way I felt reading Manager's Path. It's even a bit insulting that it's targeted at engineers, furthering the narrative that engineers are bad communicators.
Much better books in this space are "The Making of a Manager" by Julie Zhuo and "Elegant Puzzle" by Will Larson. Both very insightful and actionable. The latter is a bit dense though.
I hate these lists because I don’t think a senior engineer is a one size fits all skill set. You can be a mediocre coder but amazing at social aspects and mentorship. You can be an anxious wreck in social situations but have amazing engineering abilities.
There's nothing "wrong" if someone is an anxious wreck socially while being an amazing engineer. It just means that the company also needs to hire a good manager to take care of this brilliant individual. VS if they could hire someone who's maybe not as brilliant, but still sufficiently good to execute the engineering tasks that the company requires, but doesn't need a manager or anyone to tell them what to do, just does it and makes everything run smoothly. In fact, maybe even communicating with other teams and helping them run even smoother than before.
Then you can see where in the first scenario you had to hire two people and only one in the second case, and in the second case you're getting even more additional value with your senior engineer doing partial manager-y things. So now the second individual is maybe 2x as valuable to the company as the first, and you can see it's a no-brainer for the company which to go with.
Both of these are true but I don't think either one could be a very good senior engineer (passable, maybe) and probably not even a passable principal/staff engineer.
In most cases there becomes a point of diminishing returns in terms of pure engineering skill. At that point it is far more efficient to be able to improve over all output, not just your own. That's where these skills come in.
Think of these as things which become critical after the engineer has mastered the skill of solving a hard problem.
> At that point it is far more efficient to be able to improve over all output, not just your own.
There's only so much you can improve if the output is low. After all, if all your seniors spend their days managing, who does the actual coding? Juniors. And what happens with them after they've "mastered the skill of solving a hard problem"? They become seniors, stop coding and start teaching the next batch of juniors.
This seems like purposefully limiting the quality of the work, and increasing the time it takes.
> there becomes a point of diminishing returns in terms of pure engineering skill
It's quite surprising, if we think about it - software engineering is about as close as you can get to pure productivity multiplier. It shouldn't have diminishing returns, not so soon. It should have exponential returns. After all, the same skills that can be applied to a problem, can be also applied to a meta-problem of solving the problem faster.
As I have learned in offshoring projects, that is a matter of scale, you just need to scale the amount of juniors carring stones, the quality is overrated as long as the product line (completly unrelated to software) keeps working.
Yes but someone who can't effectively determine what problems need to be solved doesn't scale, not does this engineer scale to problems big/hard enough that they require more than one person
One can also take one skill out of the list as goal to achieve.
I don't think an engineer is able to be perfect in all skilset. This kind of list should be seen as an inspiration and challenge you in the skill we are lacking from.
The Mendoza Line is an expression in baseball deriving from the name of shortstop Mario Mendoza, whose poor batting average is taken to define the threshold of incompetent hitting. The cutoff point is most often said to be .200[1] (Mendoza's career average was slightly better than that, at .215)[2] and, when a position player's batting average falls below that level, the player is said to be "below the Mendoza Line".
I was not familiar with the term, but useful concept. Reminds me of something I read recently about the “Goat”, the West Point cadet finishing at the bottom of his class.
Junior level developers at companies I've worked at are often taught to run meetings as part of helping them grow. If a couple junior developers work on a project then having them take turns facilitating the meeting was common. My team's meetings at my last company we also had everyone take turns facilitating it. There were some pre-meeting tasks that the facilitator was also responsible for like organizing some documentation related to last week on-call alerts + commenting on any product metrics for the main product we worked on (most of the time it was looks normal).
A lot of growth I've seen is about having people get opportunities to do things more commonly done by people at higher levels. While most design documents are written by seniors or above sometimes mid level/junior engineers get an opportunity to write one and all design documents get a lot of feedback anyway.
That doesn't make sense, leading meetings is a basic skill. Unless you mean something else then what I think you mean by meetings. This is stuff we've been doing through high school and college doing stuff like group project meetings. Personally I've lead meetings at all levels in my career so far
I think the author means "senior" as a concept (For varying levels of seniority, from senior, to staff, and beyond.) and not just a point on a progression path.
#1 Running meeting and knowing how they work is a really good skill for every one to have
> You can be a mediocre coder but amazing at social aspects and mentorship.
I don't think you can. You can be good developer and amazing and mentorship or social aspect. But if you are mediocre one, you can teach others what you dont know.
When I was a university student we had teacher assistants, who were more senior students. In most cases the best teacher assistants were not the brilliant students but rather the more mediocre students. The cause is that these mediocre students had really struggled to understand the material and therefore could really understand our problems in learning it. Many brilliant people are really lousy teachers.
Is there a difference between a "senior engineer" and a "highly productive engineer with a long rap sheet of experience, that constantly feels like it's never enough"?
Senior/Principle/Staff/etc titles are typically less about raw competence or tenure and more about leadership. A senior will typically spend most of their time working on high level design and overall strategy for a project, with execution left to more junior engineers.
Seniors should be technical enough to jump in if necessary and they should guide junior engineers as needed but execution is not the main focus of the role.
I think "senior engineer" is just a role with responsibilities that include the stuff in the posted article. There's no realistic expectation that someone can be successful at all of this all of the time, but the role requires making a credible effort. The work needs to get done and there are no candidates with perfect skills waiting in the wings.
Exactly. I've been kicking around for about 20 years or so. This list captures many things I've found set great developers apart from the pack. With few exceptions [0], people who only bring amazing engineering skills will be held back without some ability in these areas. That said, this isn't the sort of thing people should see as a checklist. Rather they're skills you should keep in mind and always seek to improve upon regardless of where you're at.
[0] The exceptions are generally people with deep expertise in domains where that's a rare attribute
You could also see it as a Peter Principle checklist. If you do all of those things all the time, someone is going to think that you're so great that they might promote you right out of software development and into management. So if you want to stay a developer, maybe try to leave a few boxes unchecked :-)
Feel it if you must but even this list is woefully incomplete if we are to strike the cynic's position! Not everyone is going to encounter all these in one role. Not even in a whole career.
A lot of these are super redundant in my opinion.
If you boil them down I bet a lot of these would be mirrored in one living ones life in general. Some of them can be taught but so much more is earned by grit and experience.
I am not pooping on this site at all ... just remember everything in the modern world is made by a human hand. Frail and limited and built on billions of failed attempts. Life is iterative and unpredictable. It is a journey after all. Cruel and wide, with beauty written large everywhere in plain site.
There is definitely a mix of product owner tasks in this list. I would say the following are either mixed responsibly or in some cases entirely on a PO:
> How to influence another team to use your solution instead of writing their own
> How to give up your baby, that project that you built into something great, so you can do something else
> How to communicate project status to stakeholders
> How to convince management that they need to invest in a non-trivial technical project
> How to craft a project proposal, socialize it, and get buy-in to execute it
> How to get information about what’s really happening (how to gossip, how to network)
There is also PM work in there but that I would say hits a little closer to the senior engineer.
I think those refer to technical projects initiated by an engineer. In many cases I've also initiated product ideas that I then discuss around the company to get feedback and momentum with so that the PO will accept it into planning.
Yeah and that’s why I added the caveat that these aren’t exclusive to a PO. And I’m sure there are differences at every org. I’m a senior at a small org and _before_ we had a PO I did do all that stuff. Now that we have a PO I only do that sort of thing internally with our team when we are planning and prioritizing our work for other groups. The farthest up I ever sell have to sell an idea is my own Director and I love it.
1. I think that it is very important to distinguish between seniority (formal, role- and capability-based) and leadership.
2. While the original post offers a nice list, my mental model on the topic is pretty simple: the higher the seniority, the more capable a person should be in strategic thinking (both technical and business), ability to successfully apply it to correspondingly larger scopes and impact (tasks -> features -> problems -> teams -> organization -> company -> industry -> economy), and soft skills.
I agree seniority is about scope, but also think that there’s some isomorphic relationship in there.
When you broaden the scope enough, leadership takes over as a crucial tool. Not necessarily leadership in terms of management, but at least in terms of leading by example, thought leadership etc.
It’s near impossible to have company-wide (say of >200 people) impact without any kind of leadership.
I wholeheartedly agree. There is certainly a correlation between seniority / scope and leadership. And, as you allude to, it is a positive one. My point in #1 was that they are separate entities with their own unique characteristics and I just wanted to emphasize that (despite the fact that the author of the original post has included some relevant leadership expectations in the list).
Realistically speaking, anyone who has all these skills can get a director level position with 150 reports. A realistic description of a senior engineer is an experienced coding monkey with passable social skills.
"senior" can mean the level 3 years after college hire, all the way up to SVP-level Fellow, despite one of those levels having the specific name of "Senior Engineer" at many companies (often not the same level at different companies!)
No way. There are 3 distinct groups of corp employees: workers or individual contributors (junior, middle, senior), managers (line manager, middle manager, director) and the "money managers" (vp, svp, c-suite). A senior engineer and an svp have nothing in common except the title prefix.
>How to influence another team to use your solution instead of writing their own
Yeah I'd love to figure out how you do that. 99.9% of the time that is a cultural and political problem that you aren't going to solve by being some incredibly persuasive engineer. Oh and management won't care enough to intervene.
I think one of the things that a lot of these articles lack is something along the lines "Be clear about what you can acheive and what you can't". It doesn't matter how good your solution is, if the guy writing the replacement isn't receptive to advice that's fine, you've got better things to do.
The ingredients to doing that, in my opinion, are:
- Actually be right -- it really is to the other team's advantage to use your solution.
- Find people on the other team receptive to the idea and talk to them. Informally, privately, in small meetings, and in large ones -- different settings will be appropriate in different social contexts.
- Have a lot of social capital already. In this context, what this means is have a reputation for getting the other team recognition and making them successful, working with them when they want to do things their way, and going out of your way to help individuals with their own (unrelated) projects.
- Put in all the work to make the advantage of your solution easy to see. Do the integration work for them, if you can. Set up a demo, if you can. Do the legwork, make the slides, do the research, solve their problems. Install it for them, if they'll let you!
- Shut up about your part in their subsequent success. All you ever wanted was for them to succeed, and they made a smart call, and that's the important thing.
At least that's the way I do it. :)
I once saw an extreme master of the technique use it to convince an entire team of 50+ people including engineers and two layers of management to change an existing piece of infrastructure (our change control system) to something better. He did it by meeting privately with every individual touched by the process, explaining the advantages and the costs, getting individual buy-in from each one. He then put together a presentation outlining the change and held a big meeting to review the proposal -- with all the people he'd already talked to, who privately were behind the idea but thought nobody had the power to change it. Once everyone saw that everyone was in, it was a done deal. And that's how you solve impossible political problems. :)
> Yeah I'd love to figure out how you do that. 99.9% of the time that is a cultural and political problem that you aren't going to solve by being some incredibly persuasive engineer.
You answered your own question: Get better in the social/political/psychological sphere. Handling/tackling cultural and political problems is sort of a prerequisite to being a senior engineer. :-) This is sort of "standard career advice".
If you think going "political" is a betrayal of your values, then your thought process is part of the problem.
To be fair, no one would hire you over superman. These lists are all great for employers - please provide as much value for as little expense as possible.
As far as personal development goes, don't let anyone else dictate what's important for you.
Nobody knows what you're capable of when you're being hired (unless you're well known - in which case you command a premium anyway), and once you're in the system it's highly unlikely you'll get paid more just for being a better employee. At the very least, you have to demand it.
Your employer is usually perfectly happy getting more for less.
Who is the target audience of TFA? Most likely, people who want to 'level up' in their career and still naively believe that skill (versus hustling or nepotism) is the main driver of such things. [0]
Entire frameworks have been built just to afford the creators a career in consulting so they can 'level up'. Perhaps the less the average engineer thinks about such things, the better...
I should put in a caveat since this is hacker news - being actually good rather than having the appearance of being good is better for your career in startups, but the opposite is true for BigCos like FAANG.
1. Realize technology is the easy part, people are the hard part. E.g., that's managing leadership egos, and/or the egos of peers and subordinates.
2. In the context, communication is essential. Technology problems are solved with people and commms. Full stop.
3. Communication is not simply broadcasting, it includes listeningas as well. That said, sometimes (sadly?) "the whole truth" is better replaced with less than whole, or even silence.
4. Similarly, learn to "read the room." That could be the culture, the team, the project, the meeting, the individual, and so on.
This is a good list, and I'd add Nietzsche's classic aphorism to it, as these are also vital:
Ein Mensch mit Genie ist unausstehlich, wenn er nicht mindestens noch zweierlei dazu besitzt: Dankbarkeit und Reinlichkeit. (A man of genius is unbearable, unless he possess at least two things besides: gratitude and cleanliness.)
And when you learn that basic accounting, a couple of things. Cost accounting and financial accounting are related, but different. For financial accounting, there are often a number of different ways you could account for something. The right answer may well not be something you can figure out from first principles. You do it the way FASB says to do it. This took me a bit to appreciate.
While personally one should probably know what those mean, in the context of a Senior Engineer, I've never been in a position where I would have to know what those mean or have ever worked in a place where any engineer, let alone a Senior, needed to know what those mean.
We call those cost centers, which is another useful term to know for when you’re derisively called one. Also COGS/OCOGS and such, which is basically accountingspeak for “annoying overhead we wish we didn’t have to spend but nonetheless must,” and which occasionally shows up in department names to serve as a handy reminder of your corporate value.
Without knowing how accounting works you’d sit there wondering “what the hell is that acronym in my department name in Outlook, anyway?” whereas once enlightened you understand how your team is evaluated at a higher level. It’s not just accounting, honestly, knowing how business works is advantageous for anyone.
“What do you do here?” “Oh, I’m just a cost center.” is a pretty fun tack to take with leadership, often true, and likely to confuse the hell out of them in its simultaneous honesty and correctness.
My problem with this list is that a lot of these things are not really “skills” but rather seem to be a prelude to some new responsibility outside the job of engineering. Which is fine if you’re going to be compensated as such, but IMO the bump of 10-20% more salary for all this extra work and stress is not worth the hassle.
#22 is one I'm struggling with at the moment with a colleague: How to tell someone they’re wrong without making them feel ashamed. I'm very tactful except when it comes to asking other people to be tactful. Any suggestions would be really appreciated here and make for an unexpected Sunday.
I would approach this by bringing up (one on one) concrete examples of where this person displayed a lack of tact (without calling it as such). If the other party reacted strongly, analyze that and get this person to understand cause-and-effect, along with explaining that there are other ways of accomplishing their goals. Come with concrete ways of how you would have done it. If the other party reacted privately to you, instead talk about how you would feel, perhaps even ask them to imagine how they would feel if someone talked to them in a similar way. Don't make it personal at any point, your goal is to help them see that there are better ways of accomplishing their own goals. I find most folks are open to that kind of feedback. If the person is an incorrigible asshole, you may need to escalate.
This is something I test candidates on during interviews, I make a small mistake, or disagree with an opinion to play devils advocate, just to see how they will tell me. Are they going to be nice about it, or become nasty, and how will they resolve the situation of a disagreement.
Me personally, I sometimes just ask to double check "are you sure?" even though I know a person is wrong, and say something like "I am very sure of this, let's double check" instead of saying "no, you are wrong".
Yeah, I know someone who is otherwise pretty empathetic who has a tendency to lead with "No..." when there are better ways.
This is one thing where not being in person often hurts--although even pre-pandemic that was often the case with me. If a reasonable well-aware person is reading a not to large room, they'll probably respond if someone suddenly gives a "Did I just hear what I thought I heard look?"
Ask questions. Like, How does this work in that scenario? What if it fails on high traffic? If their idea is flawed they themselves will understand it. Then we can propose our approach. Encourage them to ask questions. This will help to find gaps in our approach. Who knows, sometimes we were wrong in the first place.
1.) We are industry in which you often become senior engineer after 2 years of experience, because basically you are confident a lot and can code.
2.) We are also industry that writes about senior engineers as if we were perfect zen masters, with no ego but great confidence and security, with infinite patience combined with effective asertivity, knew exactly what to say when socially and politically. And yet also willing to sacrifice self whenever self interest and project interest are in opposition.
And also having perfect technical skills, both abstract thinking and attention to detail, and know all algorithms and also all optimizations and all technologies and generally being perfects perfections.
3.) Although the previous two points sounds to be contradictory, maybe it goes back to confidence and absurd expectations.
Well, you'd want both. You want someone dedicated to that role of business analyst, and then you also want your senior engineers to be able to do it, but just not focus their time on it. The understanding is key to improving their execution (unless you think BAs will provide you a 100% perfect and complete spec?) and helps with the turnaround time, so that not literally every ask to the business owner has to go through your BA. And maybe even most of the questions you'll be able to juts answer on your own, and then the turnaround time is literally zero.
Senior engineers seem to need a lot more social skills than regular engineers. So much of that seems like managerial stuff that at least as a more junior developer I come nowhere close to touching.
As much as people laud 10x engineers, the reality is that if you can make the people around you 2-3x more effective you’re likely adding the value of a 15-20x engineer without writing a line of code.
I've never thought of 10x engineers as someone who can crank out 10x amount of code. Influencing others to accomplish larger goals is the best way to scale yourself reliably. And then there are the rare unicorns who can do both, e.g. John Carmack (having indirectly observed his leadership style at Facebook).
Yeah, the 10x debate always seems to be just a disagreement of terms. Are we talking about junior engineers shoving lines of code through the JIRA backlog with no negotiation over what the most effective things to be working on are? Probably not 10x variance, and if there is, maybe they're cutting corners on process.
Are there people who say "I propose we subtly adjust the product in this way which saves us 7 person-months of development effort and 2 months in time to market while delivering 90% of the original proposal's value?" Yeah, there are, and I don't understand why we pretend that can't be a thing.
Don't worry, a lot of that is experience, though at a certain point you have to get intentional about your growth, as not everything comes naturally to most people. And senior engineers are regular engineers too. Well, most of them :) Senior engineers should be partners to managers and yes, there are overlapping skills for sure. That happens because building product is a lot less about raw coding as a less experienced engineer would expect. It's about people and teams and communication to a very degree, in fact. This too you will learn with time.
I consider myself a sociable person and that can have negatives if you're too pally with juniors. They may not take you seriously if they've seen you drunk on the thursday night work drinks. The more senior you go the more of a barrier there should be.
As people become more senior, the distinction in skills and responsibilities between managers and engineers starts to blur a lot. In fact, the best folks in both tracks have spend some time in the other track
This is a good list, and I'd also recommend the author's book "The Manager's Path". One of the few books in that genre that I felt contained genuinely useful advice.
In over 5 years of dev, I've never been convinced in the value of design docs. I've bootstrapped several large components, I probably only kept up to date a document maybe once out of all those times, and I've never had any regret or paid a price for not having it. You can think up front, draw + share diagrams, get feedback, and have well documented source code without needing to introduce duplication and "englishification" of a system.
I'd love to be convinced otherwise though! Always looking to learn! Anyone care to pitch them to me?
Edit:
After reading the rest of the points, I'm actually pretty convinced this is more of a "how to be <role that provides technical interface with leadership>" rather than "how to be a senior dev". It sounds to me like they're mixing roles/responsibilities here - there are certainly plenty of senior devs without these responsibilities/expectations.
Design docs are a heavy-weight way to accomplish 3 major things, roughly in the order of importance:
1) Get feedback from your peers and other teams who need to interface with your design. Your design, or the problem you think you are tackling, could change based on their feedback.
2) Future readers can get a lot of context. Specifically, the design doc documents the trade-offs you considered and chose; this helps future engineers fully understand the problem space before second-guessing major decisions.
3) Leave some trace that you initiated/drove an effort of some design, for career/promotion purposes. You can demonstate how many stake holders/teams your work had to touch, and how difficult the problem & solution are based on various metrics in the design doc (# of ppl that participated in the review, # of services/components your design had to touch, etc).
Personally this is my least favourite reason to write a design doc, mostly because I find people write heavy-weight design docs when it serves no other purpose than for perf, and design docs are often.. embelished when they dont need to be.
Instead of a design doc, you can just file a bug, or shoot an email to a wider team, to accomplish the 3 things above. However, it becomes increasing inefficient to solely rely on bugs/email as the # of peers/stake holders increases, the scope/complexity of your project increase, or the communication overhead in your company increases.
I think it really depends on how mature, how complex, how isolated, and how big your project/working group is.
Where does your work fall, and what kind of process do you personally use to accomplish 1,2 & 3?
So i see the usefulness of design docs to be threefold:
1) Writing it all down in one place. You've got tons of whiteboard meetings, random discussions by the water cooler, random slack threads, ideas you think up in the middle of the night, different asks and different reqs coming in from different teams. It's useful to formally write it all down. And then once you see it all in one place, you can more easily see which parts of conversations you forgot, which decisions that you thought you all agreed on in the meeting but people actually thought you agreed on a different outcome. You can see if there are any contradictory points -- does one decision you agreed on in one discussion actually make it impossible to follow the decision you agreed on in another discussion. You've now got the big picture and see things now you're all zoomed out, that you couldn't see when each discussion was just drilled down into a single component or aspect.
2) Coordinate for review. So now it's all written down, and everyone can go through and see if there's anything that they missed. Are there actually any blockers in here? You can now send it out to all the concerned parties and they can make sure that you didn't miss anything, that all concerns and asks are being properly covered. Are all the original requirement actually being handled by this design? How long is this actually going to take now for all the involved teams and people to do. Much easier to do when you've got a complete list of everything you need to do.
3) Documents your original intent. So now you're off and implementing it all, and of course you end up building something completely different from the design doc. But it's still important to go back to it and be able to see, what were all of these original concerns and blockers and worries that we had? The design doc says we made this decision because of this showstopper, we ended up doing it a different way, but did we properly account for that in our final implementation. Why did we even want to design it this way in the first place, does that constraint still hold today, and will our end result fail because we ignored it.
Did you receive many components bootstrapped by someone else?
I’ve picked several projects along the way and just having one or two ADRs helped me so much. Sometimes a piece was not working so well, but without knowing why it was made that way made it really risky to just decide on a change.
Like code comments and any documentation in general, design docs aren’t best for telling what something is/does but why it exists, why alternatives were discarded, why apparently suboptimal behavior was chosen and so on.
I write design docs frequently. They can be anything from two to about ten pages, outside of formal systems like aircraft. They need to be short to be readable.
The point of a design doc is to get feedback on the design and to keep a record of decisions made and why they were made. That’s it. It isn’t supposed to stay up to date forever - your code should document that instead.
Once you get feedback on the design, the doc has served its purpose - archive it and move on.
I have been reading the "The Manager's Path" by the author of this post and for someone transitioning from a pure technical role to a semi-technical role I found it really insightful.
For me, the human aspect of building tech solutions was always overshadowed by my passion for engineering. It seems that dealing with humans is indeed far more challenging and also far more rewarding. I recommend every engineer to dive into literature along these lines to get a fresh perspective. Seems like the most essential component for building successful tech teams.
Any strategic or tactical advice is particular to each company. This is not a skill. The other skills include mentoring, so this seems a little redundant.
It's different from mentoring. It's being good at making sure management is aware of your coworker's accomplishments. It's a managing up skill instead of managing down skill.
For example, when you as a senior engineer are in a meeting with management and without the junior engineers, it's important to call out "Jr. Eng X did this part of the project and did a great job".
Yeah, a lot of this is providing visibility to low visibility high impact work or Anchoring[1] work so people's impact is correctly reflected as a part of whatever review process an organization does.
Missing item: How to say no. Sometimes this is necessary because management literally wants the impossible (e.g. to solve the halting problem); other times it's necessary because management isn't aware of the tradeoffs (e.g. we could release this game next week, but people will probably get annoyed when it crashes once a day; or we could add the feature you're asking for but it would take years of additional engineering time).
Understanding of the business. Software development is always a tradeoff, without a deeper understanding of the business it's hard to make the right tradeoffs.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
4. How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
Skill learned : be able to not pay attention to a senior manager who wants to talk about technical stuff that they don’t really understand AND tells you that technical stuff is easy compared to management.
It’s weirdly saddening that these are the things ppl need to create a whole list for and keep being reminded of. Yet, it is very often is the case. The vast majority of engineers don’t even consider these to be of big importance. I wonder if this is something specific to our profession or people personalities that follow it.
In the past, for me, the word should was the blocker to improving on some of these. e.g. Senior manager X should know how this works. Programmer Y should be promoted. Technical debt Z should be paid down. I used to get stuck on this dismissive stance. It was the idealist in me saying we shouldn't have to waste energy on this stuff because it should be common sense. I was seriously lacking compassion for some situations. I think learning to synergise my empathetic side and my logical side has allowed me to step away from what 'should' be and what 'can' be.
In my case growing up infront of the computer “helped” me avoiding all social situations.
This made me a programmer, but oblivious to all sorts of things about how the world really works.
I needed years of conscious effort to bring myself up to a basic level, which everyone around me seems to have mastered yeeears ago.
But it’s well worth it, you just need self awareness, then realizing and admitting I’m not good at X, but will learn is the life long ultimate meta-skill.
This is great content, and much of it applies to other roles as well!
I've been trying to summarize for my partner (a UX designer) what helps in doing a senior role well and gradually growing into leadership, and this says much of it better than I could have myself.
some points on this list are somewhat disputable, for example
>How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
maybe not how, but when. I was on a project as a consultant that was basically ruined by management being technical but on very old or non-related technologies and they were indulged in spending hours of meetings some days to pontificate and worry about details that did not apply. Obviously this was not the only problem but I swear some times it would have been good to eye roll or otherwise shut down the questions rather than let them continue.
> How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
> How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it
Aren't these a bit condescending? Sure they're directed up, but it sounds "be nice when you're looking down on them".
But worse, what if, as an engineer, you've just got a blindspot? What if the manager (or any person for that matter) has a brilliant idea that _you_ don't understand and therefore think it's stupid?
My experiences with senior engineers is that they often need to learn to keep their biases in check.
> Aren't these a bit condescending? Sure they're directed up, but it sounds "be nice when you're looking down on them".
No, that's the point. It's how not to come across as condescending.
> But worse, what if, as an engineer, you've just got a blindspot? What if the manager (or any person for that matter) has a brilliant idea that _you_ don't understand and therefore think it's stupid?
I think that is covered here: "How to listen to other engineers’ ideas without feeling threatened". Just insert "manager" for "engineer".
> My experiences with senior engineers is that they often need to learn to keep their biases in check.
I'm sure there is context missing here but everyone has biases and this sounds a lot like someone feeling "threatened"...in which case, see the prior bullet point.
This is an excellent list. I can think of so many experiences where I’d have fared better knowing/following this advice instead of my wrong instincts at the time.
Most senior engineers I know are key men. The have the corporation by the short curlies and, uhhh, dealing with the key men egos is something everyone has to put up with.
Words like "senior" and "principle" engineer reflect more on company being hostage to coding expertise than reflect competence beyond coding. I'm trying to think of senior or principle engineer who gave two whits about "beyond coding". Coming up blank here.
In large corporations pay is tied to title and often times titles are handed out simply to pay someone not to look elsewhere and it has nothing to do with anything else.
> How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
This I sometimes struggle with. It doesn't help that my recent efforts in this area have been with someone who also displays every bit of Dunning Kruger and beliefs in magic thinking like "the internet doesn't have problems and retries should never have to happen so we must have a bug!" or "everything can be solved with DNS (because they don't know how DNS works, what is is or how it can be used)".
24. How to write uncontroversial Medium articles filled with information people who have been in the industry more than a few years know and can kind of agree with in order to make yourself seem like some sort of guru.
I scrolled to the bottom and sure enough:
Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online!
Don't even bother with this list if you live in Europe. Even a waiting staff with zero education makes more money in Europe than a software developer. So if you lose your job, you will be glad making more money and have more fun contacting other people than sitting all day long at a desk for a penny.
FAANGs/multinationals have offices in Europe. Even more rarely they have them in Asia/Oceania.
Outside that, the happy developers I know are self employed as consultants or own app businesses.
There’s also video game studios around the world in many places other software companies don’t exist. I think this is a very interesting trend but not sure if it pays well.
Game development mostly pays quite poorly in comparison to other software eng, especially when considering the stress level of typical expected unpaid overtime. It’s a buyer’s market: companies have their pick because so many people are passionate about the field.
(You could be a gaming millionaire by e.g. being a very early employee at a studio with a casual mobile gaming hit ten years ago, but those are definitely exceptions.)
Yea no, can we stop putting ALL of the weight on the technical people that already are MASSIVELY skilled on their field and are chronically overworked? The soft people skills responsibilities fall on the soft skills people i.e. management. That is THEIR job, not mine. They can't do shit else so they better do at least that.
This is the fundamental problem with our profession, we are goal oriented and try to make things work at all cost, and we get taken advantage all the time even when we are holding all the cards (high demand for us, low supply).
Stop making their work easy by making yours hard, you are not a fcking lap boy, you are an engineer, you solve the technical sht. Make the "management and meetings" people earn their over inflated checks or simply move to the next job for an even better pay, simple as that.
All my PM, TL, RRHH, QA, and the rest of the spreed sheet crowd have always been the same: Lest waste an hour every day in a pointless meeting to show them who is boss and pretend that we do something useful, then lets spend the rest of the day in Facebook and social media while I pest the nerds on chat every few hours asking "how is that going? do you have an estimate?". That is not working, that is been a parasite. Force them to earn their living.
Yes. And no. Generic "you" follows (I am NOT trying to pick on OP).
If you are a senior engineer in a team of engineers, do you need your manager around to facilitate every meeting that discusses "next engineering steps"? If so, are you really senior?
If you, as a senior engineer, can't get a new starter up to speed on your code base (without creating a hostile environment), are you really senior?
I mean, I am not saying these things should fill 90% of your work-day, but maybe 5%? And when you do them, you should at least be passable at it. A complete lack of soft skills is not really excusable in a senior engineer. But, it is also the case that a senior engineer job is about more than soft skills.
Not sure why you're downvoted on this. Far too many managers try to also push their management work on the engineers themselves. I've seen this many times and it makes my blood boil. No random PM drone, it's not my job as an IC to do your sprint planning work for you.
Seems like a misunderstanding to me. Those tasks are on everyone's plate to varying extents, but I too have definitely witnessed the useless PM whose role seemed to be to force subordinates to effectively take on the executive portion of their role. Then everyone wonders why morale is so low.
I’m confused by this thread because a PM is not a manager. Their job is more like a cheerleader, where they don’t have any power and you don’t have to listen to them (unless your actual manager delegates to them).
For some of them this does turn into just asking why you’re not done yet.
so is this person going to become another gayle mcdowell with a book that will be mandatory reading for engineers in a few years? the top skills engineers need to master is saying “no” and negotiating your compensation
funny how people vote this down - this illustrates the problem in our industry - engineers do not band together to counter more demands and expectations of a profession that is already extremely demanding compared to other roles in corporations
The title says 'senior' so one would think Google Senior (L5), Amazon Senior SDE3, Microsoft 64 etc, but the sub-title indicates it is for 'all levels of seniority'.
Well duh, ok, I would expect a Google Principal (L8) or Microsoft Partner (69) to be able to perform most of this list.
The list for the exact Senior would look more like this:
1,2,3,4,5,11,15,16,21 -- L5+ senior engineer
6,8,12,13,14,19 -- manager (M1+) or L6+ engineer.
7,9,10,17,18,20,22,23 -- common "skills" that everyone executes up to their ability, but in general you would expect a corellation between the eng level and the ability in these.
This list should also include: How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.
As a junior engineer I found that I respected senior engineers more when they asked me to teach them something they didn't know.
As a senior engineer I feel like I get a lot more respect from the junior engineers when I just admit, "I don't know that can you teach me more or point me at some good resources?". For that matter, I get a lot more respect from other senior engineers when I give them exactly the same response.