Writing great software isn’t all about the software you write

This is a guest post from Adam Leventhal. Enjoy.

Dear new developer,

I love software engineering. Even as excited as I was to start my first job, I didn’t imagine the deep and enduring joy it would bring. In my career, I’ve oscillated closer and farther from writing code, and while management and entrepreneurship are wonderful, there’s nothing like the pure joy of building software.

Building great products takes a team. Code is a critical piece, but that doesn’t mean you need to stick to your narrow lane. Yes, developers write code, product managers write specs, doc writers write docs, marketing writes slides, sales sells, support supports, etc. Focus is important, but it’s a myth that doing your job well requires focus at the expense of understanding the holistic view of how products are built. Understanding the full product lifecycle–from conception, to purchase, install, and support–will make you better at your job and lead to better products.

One of the first things I worked on professionally was a product called DTrace. It’s a tracing tool to help understand how systems operate. It’s used to find bugs, chase down performance problems, or explore how a code base operates. I was drawn to the project early on because of the extremely precise and creative engineering required to safely instrument running programs and kernels. It was all very cool, very satisfying. An extremely formative moment in my career came when I was demonstrating an early DTrace prototype to a customer. We used this new lens into their software to understand behaviors that had always been mysterious to them. Their ideas came one on top of the next as we exposed all kinds of crazy behaviors and pathologies on the fly. I had seen the power and utility of what I had built in my own use, and my team’s use. Seeing a customer–and engineers quite different from me–get so fired up was eye opening. I still wanted to build cool stuff and write hard code, but understanding the problems it solved and the people who used it informed my work from then on.

There were three engineers working on DTrace. We were our own product management. We built features we needed to solve urgent problems for ourselves and customers. We were our own marketing, giving talks and writing blog posts. We were our own doc writers, churning out a hefty users guide. Those activities weren’t downstream of development, they were an integral part of it. When building a feature, we talked about how to explain it to sales people, to users, to support engineers. Sometimes that meant changing what we had planned to build: if you can’t write the documentation for a feature you’re probably building the wrong feature.

Almost a decade later I joined a new team that could not have been more different. The development team was comfortable in their ignorance of the broader product. They didn’t just stick to the code, they were narrowly focused on just their own subsection of the code. In the Solaris Kernel team where we built DTrace, we would follow bugs up and down the stack, through multiple, enormous code bases, to determine the root cause of problems. Here, developers were content to chase a problem to the edge of the module they owned, and then reassign the bug to the developer who owned the next module. The team barely had a shared understanding of what they were building, much less of that true north of customer need. That gap was evident in the end product: modules were poorly integrated and features fell short of solving customer problems.

Whatever you’re working on, understand not just what’s needed, but why. Listen in on a sales call, talk to a customer, or do a ride-along with a support engineer working on an escalation. Some companies have great programs to involve engineers in the broader product lifecycle. If yours doesn’t it’s probably (hopefully!) because no one has asked. Empathy is an engineer’s greatest asset: empathy for the customer to understand their problems and priorities; empathy for the doc writer trying to explain a complex feature; empathy for the next engineer to pick up your code and make sense of it. Empathy starts from a curiosity to understand what and why.

Find true north for the products you work on. It will make your work better and bring you more satisfaction.

Adam H. Leventhal is an engineer at Oxide Computer Company building a new, modern computer. Previously he was a software engineer at Sun Microsystems, CTO at Delphix, and co-founder, CEO at Transposit. He’s sheltering in place in San Francisco with his wife, teen, toddler, and two dogs. Find more of his writing here, here and here.

Start the conversation

This is a guest post from Tae Kim. Enjoy.

Heyo!

So you’ve entered the world of… development? Software engineering? Programming? Coding? So many words for the same thing! I usually stick with “Software Engineering” for the resume because that sounds the fanciest, and fancy === money. But when my friends or family ask, I say that I do “computer stuff”. That usually works.

You’re probably thinking, “wow… what lame advice”. But you’ll see. You’ll see…

So about me! I’m Tae. At the time of writing this letter to my fantastic reader (YOU!), I’ve been developing for about 6 and a half years. I work at Airbnb in Silicon Valley. (If you haven’t seen the show yet (Silicon Valley on HBO), I highly recommend it. First season was the best, but you gotta watch ‘em all.) I primarily work in the Frontend realm, typing my 1’s and 0’s in Javascript and React. If you are still playing with jQuery… stop that and learn React. Trust.

But enough about me-self! Today I’m going to give you my one piece of advice. The one thing that I do that makes me successful at my job. It’s not coding really really fast. Nor is it knowing how to implement Quick Sort in O(n log n) time. It could be that my JIRA velocity is off the charts – but it’s not. No no no. It’s something far more crazy. Something far more insaneeee! It’s this…

When I’m at a good stopping point from my work, I step away from my desk, walk over to a random teammate (sometimes a random person), and ask, “Heyo, whatcha working on?”. Bat shit crazy right?!?

Well, the responses vary from person to person.

You sometimes get a short answer like “Oh, just fixing this bug. *turns back to monitor and puts on headphones*”. That’s totally OK, they are probably in the zone and you should slowly walk away. Try not to judge them too hard. *whispers asshole under breathe*

Other times, they have something super rad to show off like “Yo! I just fixed this crazy bug in IE. Check it out!”. These responses are awesome because you can dig in and learn something new. That same bug will show up in your work, it’s just a matter of time.

Then there are times when they say, “Yo… I have to fix this bug but have no idea what to do :sadface:”. That’s a great time to sit down and pair on a hard problem. Maybe you don’t know the answer, but you can be there for both support and as a Rubber Ducky (google: rubber ducky programming). Don’t be afraid to pull in other people around you and have a group brain sesh too, those are the best! #teamwork

These types of responses aren’t actually why I give this advice though. Learning and helping is great, don’t get me wrong! But this action is more than that.

You are being a teammate. You are building relationships. You are creating culture.

I know I know. How can a single question create culture? That’s nonsense!!! And I agree. But it’s a great start. It’s the doorway if you will. Once you enter, you then gotta walk the hall, turn into the dining room, sit down, and start eating. No really, grab a meal with your teammates too.

Sorry if that didn’t make any sense. I do that sometimes.

What I’m trying to say is that if you are genuinely interested in your teammates, they’ll recognize this. They will appreciate this. It’ll lead to way more than a simple IE bug fix. Hell, it might even lead to a new best friend!

I don’t think we join a company to sit at our desks alone, heads down, without wanting to speak to anyone. I think we’re just not comfortable making the first move.

But if someone begins the conversation, we’re very willing to reciprocate.

So start the conversation! Get people interacting! That’s what culture is. That’s what a fun work environment is. Ping pong tables? Those aren’t culture. Those are doorways to get culture (I know, the damn doorway metaphor again).

Airbnb has a slogan of “Belong Anywhere”. At first, I thought it was some cheesy line that our CEO preached. But I get it now. Especially in the world of developers, where it’s so easy to get sucked into your computer. It’s very easy to become siloed.

Nobody wants to go home thinking “Man, I don’t really have friends at work” or “Aw shucks, nobody said hi to me today”. That would suck.

Instead, what if they went home thinking “Oh man, I’m really glad I got to work with <insert your name here> today” or “Wow, I really love my team”. That would rock.

So be that spark. Create that culture. Because you are fucking awesome.

Tae

P.S. Say “Good morning” and “Good night” when you come in and leave. It’s better that way. Trust.

Tae Kim does computer things at AirBNB.

The Art To And Power Of Saying No

Dear new developer,

There’s an art to saying no. And there’s power in doing so.

I worked on a project that was creating a Yahoo clone early in my career. The lead developer got sick. I said “yes, I can help.” I jumped in and helped out, a lot. I ended up working 96 hours in a single week. The site launched. I was thanked by my company with … a t-shirt and six-pack of beer.

I have learned since then how to say no.

The art is in saying no without being a jerk, and to making sure that everyone realizes that they are all on the same team. My best advice for that is to flip things around and say “yes, but.” “Yes, I’m happy to shift to working on task B, but should I finish task A first.” “Yes, I can help you with the release, but Jane is waiting on this feature.” This makes it clear that you are happy to help, but have other obligations as well.

After you describe the two options, ask for prioritization. Especially as a new developer, you simply don’t have the bigger picture. Maybe task B is blocking three other developers from making forward progress. Maybe that release is really important because of a bug fix that needs to go out before the launch of a new product. I have never once been dinged when I asked for prioritization. It shows that you care about working on important things, are aware that there is a bigger picture, and are flexible.

However, be aware that as soon as you juxtapose two tasks that both need to get done, you will be asked to estimate those tasks. Practice that, as it is a skill you’ll need as a software developer.

The power of saying no is in protecting your time. You only have one life to live (#yolo). When you have a salaried job, there’s very little downside to your company in trying to take more hours. Even if they are really nice people, you are the person responsible for establishing and protecting your boundaries. If you say yes all the time, you may end up working a lot of hours.

The other issue is that it feels good to work, especially as a new developer. “Look, I’m getting stuff done.” “I’m building cool stuff.” But the point of life is to live, not just to work. As I look back over my career, I’m proud of what I’ve built, but a lot of what I’ve built is gone. Don’t let a company suck you in and not learn to live a life.

Learn to say no.

Sincerely,

Dan

Show gratitude

Dear new developer,

I have found gratitude to be an invaluable part of my software development career.

First, being grateful makes me happier. It works for others too. When I get frustrated with someone at work, or some technology that is poorly documented or doesn’t do just want I want, taking a step back and being thankful for my position is just the antidote. It gives me perspective that software development is an awesome job compared to just about any others. Here’s a short list of how software development is awesome:

  • it is lucrative
  • there is a low barrier to entry
  • there are varied challenges
  • it is a broad industry
  • many jobs provide autonomy
  • remote work is a reality for many
  • there is an opportunity for continuous learning
  • developers are in high demand
  • workers are treated well (I know how health care workers, some with master’s degrees, are treated)

When I think about that, it makes the normal frustrations a bit easier to handle.

Showing gratitude to other team members also reminds me that everything is a team effort. It also has the side effect of making a job more fun, and making it easier to communicate in the future. Every team member has something to teach you.

Finally, being grateful makes me more fun to be around. Given roughly equal skills, who would you rather work with? A grumpy co-worker who is sullen and unhappy, or one who regularly shows appreciation for other team members? Who do you think will be remembered more fondly years later?

There is no need to be obsequious. You don’t need to over-thank anyone who helps you or buy people gifts. A simple “thank you” or mentioning your gratitude for the assistance to another team member in passing, done every day or two, will work wonders over the long haul. More tips about gratitude:

  • be professional. Make it short and sweet.
  • be specific: “thanks for the help with the XYZ component yesterday” is far better than “thanks for being you”
  • spread it around, including peers and people in other departments.

Remember, it’s good for you too, not just your career.

Sincerely,

Dan