One of the questions I try to ask myself is, if I joined a new team or company, what skills would I need to really help the team succeed quickly and effectively.
A lot of ya'll have been around the block a lot, and either been or worked with such folks. Your insights would be super appreciated
For example, the most productive person I've ever met, is a master of shell script, all the various shell tools (with obscure flags and usage modes), has deep knowledge in the use and application of makefiles, is a perl wizard and knows lots of tricks for virtualizing/replicating things in non-obvious ways.
When this person wants to automate a task, he can do it immediately, without having to think about 'how do I xxx'. It just flows from his fingertips because he knows all of these 'basic' things. Since so many things in SW are automatable, this gives him a non-linear advantage against nearly all his peers. He can dedicate 50% of his time building tools that act like a multiplier for the 50% of his production work and gets 500% done.
The only drawback is he documents very little, and as a consequence you have to be willing to dig through code to get the value out of his work.
A common mistake is to focus too much on the technical aspects and not enough on shipping. It’s easy to get lost in over-engineering the hypothetical perfect system that doesn’t ever shift to customers. You don’t want to be that person.
Instead, focus on simplifying implementations and shipping simple, trustworthy code as quickly as possible. A reputation for getting things done will go a long way.
Beyond that, focus on area under the curve. The more code you ship and the more tickets you work through, the more experience you’ll acquire. Cut through the time wasters and get coding as much as possible. Over a decade you can accumulate multiple times more experience than someone who moves slowly and puts in the bare minimum. This doesn’t mean kill yourself by working 50+ hour weeks, but it does mean you need to learn how to cut through the slack in a workday and eliminate procrastination and distraction. Learn how to get down to work and focus efficiency. It’s a learnable skill.
[1] https://blog.codinghorror.com/quantity-always-trumps-quality...
Quality versus quantity is a false dichotomy. You actually need both quality and quantity (or more accurately: speed of delivery). Don’t ship bad code for the sake of shipping code because this will damage your reputation.
The actual tradeoff most people are up against is speed versus complexity. If you find yourself in endless process meetings or talking about new architecture changes over and over again but it takes forever to actually write code, then you’re stuck on the complexity end of the spectrum. Complexity feels good in the moment because it feels like you’re doing the right thing and reducing risk, but the more complexity you add the less product you actually ship.
Learning how to simplify to the bare minimum, reduce process overhead, and ship quality, minimal code quickly is the art you want to learn.
But you are kind of past that point. There are a lot of different "archetypes" for being a really good staff engineer. You can become very skilled at a particular technology, or very knowledgeable about a particular product, or very politically effective within a particular organization. For different people, the best strategy here is different. It depends what you're good at, and what you really want to be good at.
For your question - if you joined a new team, what skills would you really need? The answer is, it depends on what the team needs.
I think you might be focusing on the wrong details. The first step in taking your career further is to find a team that is a good fit for you. That means two things.
1. The team's mission is big enough that it needs a staff engineer (or another staff engineer)
2. The skills needed for the role of staff engineer on this team are skills that you have or can acquire
On some teams it will just be impossible for you to become a staff engineer, because there just isn't enough opportunity or importance, as perceived by the management. On some teams it will be impossible for you to become a staff engineer, because it will require a skill that just isn't you. So go find the right team, and then it will be far more obvious what you need to do to become a ridiculously good backend staff engineer.
Feel free to email me if you'd like to chat more, I have been the engineering manager for a number of people who have gone through the senior -> staff period in their careers....
> Feel free to email me if you'd like to chat more
Appreciate this.
Let's say... an important piece of business functionality is divided between five backend services, each of which has its own engineering team. For the past couple years there have frequently been either performance problems or system-wide outages and nobody seems able to resolve it. Engineer X is on one of these five teams. They organize some processes, find some key people on each team to work with them, and convince the relevant managers to allocate resources to their project to improve reliability. The initial project is a success. For the next couple years, usage of these backend systems goes way up, since they are important to the business and now much more reliable. As usage grows, naturally reliability problems keep popping up, but Engineer X keeps their cross-team process operating and engineers participating in the process rapidly fix the reliability problems.
You could call these skills "political" but it might also feel just more like "being organized and communicating with the wide variety of stakeholders".
Obviously, green-field projects hold the promise of easy prominence. But you can learn to spot other opportunities that aren't as obviously sexy, yet get you name recognition.
Take time to share and listen. Teaching, mentoring, coaching, etc. others, especially those with less experience, is good, but is often done as a one-way transfer of information. Instead, find people who ask good questions (those with the least experience often ask the best ones) and be open to exploring those questions together. It's hard, because you will base your answers on your experience, which is by definition limited (it is for everyone), but it may not be the right answer in all situations.
> Instead, find people who ask good questions (those with the least experience often ask the best ones) and be open to exploring those questions together. It's hard
Great call out. Tangentially, if I'm being honest, not knowing answers to basic questions makes my insecurities surface, definitely a character flaw to work through.
On the contrary, your attitude of "I want to become ridiculously good at this" will carry you 50% of the way there. Good luck!
It's very easy for us to focus on the tech and think that more knowledge, more performance or whatnot is the next level. While we have some superheros (John Carmack, Dennis Ritchie, Dan Abramov) that are famous for incredibly focus and deep technical skills, for the rest of us, we are evaluated on getting stuff done, reliably and consistently.
There are, of course, situations in which "shipping" has to do with performance (I once had to rewrite and algo from python to rust to gain about 100x performance), but in those cases it's often explicitly defined as a business requirement, i.e. more revenue or lower expenses.
Another tool in my toolbox has been understanding better the "business" of coding, that is, how does software engineering work fits in the "supply chain" of a company, from idea to the sales guy making cold-calls. Two books come to mind, "The Unicorn Project" and "The Phoenix Project".
At any rate, the desire to keep improving yourself, growing and learning it laudable!
However, since this isn’t about listing trendy techs on your resume or l33tcoding, I don’t know if it will make you more in demand or not
2. do hard things. Solve problems other people are incapable or unwilling to solve.
3. practice. Rinse and repeat until you get it right. Be insanely persistent.
4. humility. There is no secret sauce. There is no magic toolset, framework, or assistant to do your job for you or cheer for you. Toil in silence and repeatedly fail until you get it correct. That pinnacle of success is the expectation not an achievement.
the author Will Larson https://lethain.com/ goes into detail about all types of staff engineers
also follow him on twitter
