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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.