As a Senior Software Engineer here at Uber, I often spend time helping to mentor newer software engineers. One of the questions I get asked most often from my mentees is “How do I become a Senior Engineer?”
This is a complex question. Any true answer will contain caveats and nuances. However, in my opinion there is one broad answer that cuts to the core of the question. The distinction between a Junior Engineer and a Senior can be boiled down to a one word difference:
Junior engineers build on the rails, Seniors build the rails.
What I mean by this is that Junior Engineers are going to be building on the work already done by Senior Engineers. Senior Engineers essentially multiply the work they do by creating technologies/architectures that enable other engineers to write better code.
Let's look at an example. Back when I was at Facebook on the messenger team we had a problem: implementing new message types required changes across our entire stack. Changes needed to happen across multiple layers of abstractions on both clients and the backend. It was a huge pain in the ass¹.
Together with the help of several other engineers, I helped build a technology called XMAs (extensible message attachments). The result of building XMAs was that adding a new message type became as simple as making single, small change on the backend and a corresponding single, small change on each client.
New types of messages that would've taken months to develop using a team of engineers could now be built in a week or two with a handful of engineers. The work my team and I did enabled easy development of new features, increasing developer productivity. We built out new rails.
It's worth noting that we based our XMA technology off of another technology at Facebook, Story Attachments. The engineer who had built that was, in my opinion, working at higher level than a Senior Engineer. They had enabled engineers to enable even more engineers, further multiplying their effect.
Think about some of the most esteemed engineers you know. The Kent Becks, the Dennis Ritches, the Grace Hoppers. What's the one thing they all have in common? They've enabled thousands of engineers to write better software.
That's really what growing as an engineer is, enabling larger and larger amounts of engineers to do more work. So if you find yourself wondering how you can improve your abilities as an engineer, try asking yourself a different question: how can I enable other engineers to be better?
Kurtis Nusbaum is a Mobile and Backend Developer at Uber. He's an avid long distance runner and diversity advocate. Here's his mailing list. Here's his Twitter, and LinkedIn. Here's his github. If Kurtis seems like the kind of guy with whom you'd like to work, shoot him an e-mail at kcommiter@gmail.com.
¹ As a general rule of thumb, if something is a huge pain in the ass for you, two facts can be assumed: it's a pain in the ass for others, and creating a solution is highly leveraged work. Problems like these are ripe for the fixing and will most likely enable other engineers.
Top comments (17)
Limiting "senior" to just technical aspect of tools or code is way too narrow to capture it's meaning. My all times favorite on the subject is this kitchensoap.com/2012/10/25/on-bein...
Also (my personal pet peeve) "senior" also thinks about why and for what purpose system is built. E.g. people working at Uber who not concerned about it's despicable business practices also show signs of immaturity.
That said this is not only about code.
You misspelled Ritchie. That aside, while what you said is true, it's necessary, but not sufficient. Senior engineers have to have a deeper understanding of how stuff works under the hood. I interview "senior" engineers who have no clue how string literals in C work; or what structure alignment and padding are, or why they're necessary; and lots of other nuts-and-bolts-type stuff. Even if you use higher-level abstractions, you have to understand what they're doing under the hood in order to make informed performance trade-off decisions.
I'd wager that in 90+% of the programming jobs out there you have literally zero need for information on how string literals in C work, or what structure alignment and padding are. Unless you work with C, or do some extremely performance sensitive low level work it really doesn't matter.
What matters in most jobs is getting stuff done, and that can be done by focusing on the actually important bits. Most of the software architecture today can solve the performance, availability and scalability issues etc. on a much higher level so that they don't have to care about the C-level details.
One sign of a senior engineer is knowing when to ignore the low level details and micro-optimizations and focus on the higher level architecture.
And witness code bloat and poor performance rampant both on-line and in apps. Getting poor code done just for the sake of getting it done might help you get to market, but not to remain there.
And you have to know the low level details in order to know when they can be safely ignored.
This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.
I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.
In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.
No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.
For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.
Nobody is putting a gun to your head either to read it or reply. If it's that annoying to you, stop.
And I quite specifically said you have to know a breadth of things to know which bits are the important bits.
You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.
That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.
A senior engineer also should know about effective time use. When should they spend time on something, and what issues and details they should ignore. What problems should be solved on the higher level architectural level, and what requires the low level optimization.
Quite a lot of junior engineers spend too much of their time worrying about the little details, e.g. which of the 3 potential ways to solve a simple problem (such as doing a substring match) is theoretically "the best". Sure you might consider them a bit to make sure you don't make huge mistakes that will completely kill the performance for your application, but in the end it's almost always more important to get things done than to get them done "perfectly".
Especially in the modern world where quite a lot of development is done for the web, it's more important to consider the overall architecture than the little details. The architecture is what makes your system scale and perform under load, not the micro-optimizations of substring matching.
I like this. Concise and definite. I also thought it might be interesting to point out that being a senior software engineer is not always about the code. Sometimes, it's about the little advice and notes, the recommendations (do this because "xyz", don't do this because "abc"). It'll be dismissive to ignore the fact that senior engineers generally influence how younger engineers think or view a lot of computing concepts or problems. Explaining the philosophy behind why a number of things are the way they are [plus the kind of reasoning process that led to them] and challenging newer software engineers to make life all much more easier for all of us is one of the other things senior engineers should consider engaging junior engineers with. All in all, I am considering actively mentoring this year, concept?[Mentoring helps us all in the end] Lovely article nonetheless. :) [P.S: It's 2:32 am over here and I just shared this link with a mentee]
Like all professions, it's a range of experience that separates junior from senior level positions. In my article about being a programmer I indicate there are several skills that define a programmer beyond just coding.
I'd expect a junior programmer to be versed in only a few skills and need a lot of assistance in producing a project. I'd expect a senior programmer to be able to manage, on their own, their relationships with all development staff and be able to effectiely prioritize their work, along with mentoring the junior programmers.
You lost me at "Uber"
A great high level explanation of the concerns a high level engineer should be thinking about. I think some other concerns that should be very important to a senior engineer is being a people leader, and guiding mentees and peers -- and even leaders higher up the chain -- to making better technical and non-technical decisions.
This may be too soon, but.. speaking of helping lead: A senior engineer and/or leader would be working hard to find and stop any of the harassment issues being talked about on Blind for the last two weeks.
Absolutely. I'm actively involved with our lady eng ERG at Uber. Over the past few weeks I've been listening to a lot of stories and helping out where I can. I've also been working for better representation of diversity in the tech industry at large for several years now.
Great article Kurtis! I wrote today also about my vision on what a senior dev really is..I really agree on your example that junior devs build on the rails and senior build the rails, they make the software architecture so that the junior cannot make mistakes, they build the framework. In my article I also talk about different disciplines or 'hats' that senior people must have worked in..such us testing, bugfixing, etc. Let me know your opinion linkedin.com/pulse/what-really-mak...
Very insightful article. What amount of your time as a Senior Engineer do you have to devote to management related activities?
I'm not a manager, so I don't think I have any real management activities (like helping people grow their careers). I do spend about 50% of my time mentoring though.