Thoughts on “Being a Senior Engineer”

On Being a Senior Engineer made the rounds late last year. Before I finished reading it, I felt it was pointing me down a path I hadn’t realized was there but needed to go down. It’s the kind of “yes, this!” writing that I often end up ineptly giving people a link to without the ability to explain why they should care or how amazing it is.

I chewed on the original article for a few months, following the links, re-reading it. Basically, I’m trying to completely consume this idea of the responsibilities and abilities of a mature engineer. Below, a bunch of quotes that struck a chord with me and follow-up ideas.


I expect a “senior” engineer to be a mature engineer.

Mature engineers seek out constructive criticism of their designs.

Here’s an example of how I try to apply this: attempt to hold all the options (designs, causes, etc.) in your head. This is doubly important if you have identified a design or project plan as infeasible, but it appeals to those who don’t have the whole thing in their head. Empathy and understanding of other points of view is crucial.

Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you.

A thousand times yes! I have often felt that internet culture lionizes those who are quick and merciless in cutting down those that don’t agree or can’t code as prodigiously as the original poster. A senior/mature engineer is not soley defined by typing the most code per day.

Be the engineer that everyone wants to work with.

Please, if you ever see me not being that engineer, tell me!

…they have a responsibility to others to make themselves interpredictable. In general, mature engineers are comfortable with working within some nonzero amount of uncertainty and risk.

This is from a section on making estimates. It’s hard to make estimates, because they feel like binding contracts. If you’re working with the right people, it’s OK, they’re not a contract. Make a guess and help others you work with understand the level of entropy involved in your project reaching a milestone at a specific date.

This code looks good, I’m proud of myself. I’ve asked other people to review it, and I’ve taken their feedback. Now: how long will it last before it’s rewritten? Once it’s in production, how will its execution affect resource usage? How much so I expect CPU/memory/disk/network to increase or decrease? Will others be able to understand this code? Am I making it as easy as I can for others to extend or introspect this work?

  1. The only time is runtime, but a lot of developers focus on the static, build-time properties of their code.
  2. As a corollary, developers become the experts at the “hypothetical” of their code, and the ops team become the experts at the “practical” of their code. This isn’t a good division of labor.

Generosity of spirit is one of our core engineering values, but also a primary responsibility of our Staff Engineer position, a career-level position. These engineers spend the time to make sure that more junior or new engineers unfamiliar with the tech or processes we have not only understand what they are doing, but also why they are doing it.

I’ve found it challenging that I’m so far removed from the struggles of a junior developer that in some ways I don’t even comprehend them anymore. Trying to help those who have come up through Hungry Academy, even just a little, has paid dividends in understanding “junior” programmers and more experienced developers who don’t have my experiences.

They know that they work within a spectrum of ideal and non-ideal, and are OK with that. They are comfortable with it because they strive to make the ideal and non-ideal in a design explicit.

Again: hold all the things in your head, even though you take only one path. For now. It’s software you can and will change your mind.

Further: write software such that doing the right thing is easy, the wrong thing is hard, and amending the shortcomings is possible at a later time.

Being empathetic in this sense means having the ability to view the project from another person’s perspective and to take that into consideration into your own work.

Hold all the people, and their conflicting goals, in your head too. Isn’t engineering fun?

…never go to your boss with a complaint about anything without at least one (ideally more than one) suggestion for a solution. Even demonstrating that you’ve tried working the problem on your own and came up empty-handed is better than an empty complaint.

There will always be things that suck. Complaining about them feels good! Proposing, advocating, and working on solutions is better.

The issue with cognitive biases is that we can be blissfully unaware of when we are interpreting data with our own brains in ways that defy empirical data, and can have a surprising effect on how we get work done and work on teams.

For every time I wonder what cognitive bias I’m currently exhibiting, I’m sure there’s two more times when I have no idea. His list of biases is well worth reading into.

Ten Commandments of Egoless Programming. Yes.

How people feel about technologies, technical decisions, and technical directions is just as important (if not more) than the facts about the details.

People are irrational. Work with it. People have scars learnt from bad experiences. Deal with it. Everyone has succeeded in different ways and made the right and wrong inferences from it. Listen when people talk and speak to what they are excited and concerned about.

The double-tap

I use Alfred because I believe that my computer should be practically unusable to other people who try to use it. My goal is to put the things I use frequently close at hand. Conversely, the things I use rarely should be accessible without cluttering my most common workflows.

Last week, I came up with a way to bring the two or three applications I use all the time very close to hand. Ladies and gentlemen, I present to you the double tap:

Alfred Preferences

Since I use VIM inside a terminal several hours a day, I want really quick access to iTerm 2. My thumb just happens to sit near the command key all day. Ergo, assigning a key to quickly switch to the terminal makes a lot of sense.

But it gets even better! Alfred knows about double-taps of the control, alt, and command keys. So you can assign an application to each of those keys and really quickly switch back and forth between them. It’s pretty rad.

My experience is that this works exactly how I’d want it to 80% of the time. A couple times a day, I will start to chord a different key combo and mysteriously end up in iTerm. It’s not disruptive, just a little odd at first, and I keep going about my business.

If you use Alfred with the Powerpack and love your keyboard, you should definitely start using double-taps.

Computers do what we tell them to, except when we give up

We tell ourselves, “a computer only does what we tell it to.” But, when it comes down to it, if we aren’t getting the result we want out of the computer, we often give in and do whatever it is the computer wants us to do.

I’m fascinated by this phenomenon. Novices do it when they’re confused, even a little afraid they may have done something wrong. Experts do it when they’re frustrated and upset that the computer is preventing them from doing whatever it is they actually wanted to do.

What’s it say about our increasingly dependent relationship with computers? At what point do we give up on our own goal and do what the computer wants so we can make progress? Is it really computers we’re giving into, or the dysfunction of the relationship between the designer, developer and the user of a computer?

A maxim you could conduct your modern life by: beware technologists bearing a solution, lest it become another chore you have to tend to.

Don’t isolate yourself

As a remote developer, it’s tempting to create an environment where all you do is focus on churning out the code you’re paid to write. Minimal email distractions, no noise, meetings and chats only when you want it. Seems pretty ideal on paper!

I’ve found the exact opposite. Checking out of a team like that, even if I’m fulfilling all my duties, robs me of valuable context. It’s handy to know what other people are working on, when they’re succeeding, and how they’re learning from failures. It might not directly relate to my work, but it helps to stay aware of the environment into which your work fits.

I recently “turned on the floodgate” for the development organization around me. In our GitHub install, I picked one or two projects from each development team to follow. Since most teams use a pull-request workflow, I get a few dozen emails per day that give me the chance to peek into the cadence of a team’s work. This fills in context I miss in Campfire or your typical email broadcast.

My job as a developer isn’t to know all the things going on; I’m not suggesting you keep close tabs on every project. Instead, I’m trying to keep my finger on the pulse of colleagues on other teams. I find myself better prepared to help them out and make my own projects fit in with where the organization as a whole needs to go.

Semantics/Empathy

People argue about words all the time. In the past two weeks, I’ve participated and watched as nerds unproductively tried to convince each other that they are incorrectly using the words bijection, hypermedia, and dependency injection. Nerds easily fall into this trap because many of us are fascinated by knowledge, sharing that knowledge, and teaching that knowledge.

Arguing about words is fun. Arguing about words is practically useless.

Semantics are good

Words are a tricky business. An overused, overloaded, or ambiguous word isn’t particularly useful. “Synergize”, “web-scale”, or “rockstar” are mush words that don’t convey much meaning anymore. It’s tempting to think that encouraging others to be judicious in their use of words and mind the specific context and meaning of their statements could move the needle in making the world better.

On the other hand, human interaction is fidgety. We all have differing experiences, so the way we think and feel about things can vary wildly. You might say “we should pivot our business”, remembering the time you did so and took the company in a much better direction. I might hear you say “pivot” and think about all the abuses of the word in startup discourse or all the companies that have “pivoted” and still failed. Even though we are thinking of the same definition of “pivot”, we are thinking different things.

Semantics are good for getting two people in the same mental ballpark. I can say “web framework” and expect you to know I’m not talking about dogs, tacos, coffee, or compilers. You and I may differ on what a web framework is and what it does, but at least we’re both thinking of things that help developers build web-based applications. We may not be talking about the same thing, but we’re close.

This is why I think strong semantics are interesting, but not a silver bullet. Very rarely have I solved a problem by applying stronger semantics to the words used in the discussion of the problem. Never have I solved a problem by telling someone they are using the wrong semantics and that they should correct themselves.

We can argue about words all we want, but it’s not getting us any closer to solving the real problem. The problem we started talking about before we decided to have a side argument on the meaning of a word.

Empathy is better.

Empathy is a better tool. When someone misuses a word, I stop myself and think, “OK, let’s allow that one to slide. What are they really trying to say?” Rarely does someone misuse a word on purpose. It’s more likely they know it in a different context; discovering that context and matching it to your own is how the conversation moves forward.

If you say “we need to pivot our web commerce company to a web framework consultancy”, I may not know precisely what you mean by “pivot”, “web framework”, or “consultancy” but I can get on the same page with you. You think we need to change directions and that some services-oriented business based on helping people build web applications is the way to move forward. Armed with that, I can ask you questions about why we need to change directions, what that web framework looks like, or how we would change ourselves to a services-oriented company. It’s not as important that you get the words right; it’s important that we find a way to talk about the same thing.

Words are fun, but what’s useful is to figure out what the other person is thinking or feeling and talk to that. Setting aside the tension of telling someone they’re wrong, it’s not productive. I’d rather talk about how we can make better programs or better understand our world than foible over the meanings of a few words.

Words are a lossy representation, they can’t possibly ever connote the full meaning and nuance of any idea of interesting size. Don’t get caught up in skirmishes about the marginally important details of semantics. Use words to show others what you’re thinking and guide them towards your understanding of the problem and a proposed solution.

A decentralized web is hard

The Web We Lost, on the web of ad-hoc, bottom-up social networks before the pendulum swung fully towards centralized networks like MySpace, then Friendster, and now Facebook, Twitter, and friends. I’m glad Anil Dash is pointing out that great things were happening before social networks were massively financed operations and the delightful things that were different when people ran the system from the bottom up.

Owning and operating your data is obviously better than letting someone trade on it. But, there are missing pieces for users:

  • Where do I host my corner of the social network? Putting content on the web without someone else to run it is still strictly nerd stuff.
  • How do I find my friends? The advantage of a centralized network is its easy to make global observations, like analyzing social graphs for recommended links.
  • What are the checks against bad actors? Comments and trackbacks were fantastic for weblogs, until spammers figured out how to turn them into toys for boosting pagerank.

I don’t think any of these are insurmountable. But, decentralization is hard! Can we pull it off? I’d love to see it happen.

Focus-mode considered harmful

I have, at times, been a practitioner of turning off notifications, superfluous applications, and other distracting computer softwares so I could “get things done”. Sometimes it works! However, I have come to suspect that perhaps it is obscuring a greater problem.

I’m just not focused.

Maybe my task is tedious, my project is poorly-defined, or I don’t have a thread to pull on in order to get started. Whichever it is, the world’s greatest distraction-free, focus-enhancing software isn’t going to fix it.

What I really need is something imminent. A show-and-tell with my team, a milestone to deliver, an item to cross off a list, something to publish for the world. I need a goal and it really helps if I need to achieve it in the next few hours.

Yesterday, I worked for a couple hours towards a show-and-tell with my team. I had Twitter, Campfire, and Rdio open. One or more of these are a possible distraction. But, I knew none of them was going to make my demo better, and so even though I flicked over to them occassionally, I flicked back immediately and got back to work.

No one wants a deadline, but a date and an expectation can prove more useful than I had previously thought.

Ideas for living and creating differently

Try thinking about living and creating a little differently today. Advice for beginners: push through the shortcomings of your early work until your ability catches up with your taste. Slow down, lead life at a slower pace every now and then, it’s good for you. Stop telling us how much everything sucks; not everyone makes the same decisions and trade-offs you would when they create something.

Gimme clarity

Wise pal Brain Bailey, along the way to writing about Woody Allen, perfectly articulates my challenge in thinking about how a team should work:

The combination of clarity and freedom is what makes work a joy; one without the other is where you find frustration. When you have great freedom, but an incomplete understanding of the goal, you’re likely to invest hours of effort in a futile attempt to hit a target you can’t see. You know this is the case when you see revisions requested again and again, or products that are perpetually delayed.

On the other hand, a clear goal with little freedom in how to achieve it produces uninspired work by dispirited people. The lack of freedom is experienced as a lack of trust and confidence. People in these environments will eventually seek out new places to work.

Personally, I oscillate between attributing failed projects to too much freedom or not enough freedom. It’s not about that at all. It’s about the balance of that freedom and clarity. If I’m given freedom without clarity, I run off and invent something interesting but impractical. If I’m given over-constrained clarity, I get discouraged.

(Freedom is a funny thing on teams and projects. I have a lot more freedom than I usually think, but I’m still very conservative in acting on that freedom.)

I recently asked my team lead to give the team I’m on a stronger direction in which to go. We already had most of the freedom we needed. We talked over how we could proceed as a team and came up with a direction that was useful for the other teams around us and not so far afield from our current momentum as to discourage us. My morale immediately doubled and I think our team did some good excellent work once we had that strong direction.

Whether you’re managing yourself, managing a team, or managing your manager, asking for clarity is a thing I you should do!

The feel of a commented program

Opening a nicely documented source file is like opening a well-designed, nicely printed book. The main text is obvious, but the side-notes are there to help you when you aren’t quite catching where the author goes or when the author wants you to go read up on something else for context.

Opening a file that needs few comments is like opening a notebook. It’s the raw form of an idea. A few people can pull this off, distilling a program down to its essence.

Both are charming in their own way. The challenge is to know when you’re producing a book and when you’re writing in your notebook. Write for yourself first, then edit it up or down for the reader.