Don't Break Prod provides bite-sized pieces of career advice for software engineers.
One of the most important rules of programming is Hofstadter's Law : It always takes longer than you expect, even when you take into account Hofstadter's law. One mistake that smart junior engineers tend to make is under-estimating the amount of time that a project will take. It's not that more experienced engineers are sandbagging their estimates, but after gaining experience and seeing how…
One of my favorite quotes about growth comes from the cartoon Adventure Time: "Dude, sucking at something is the first step to being sorta good at something" - Jake the Dog A huge part of being a software engineer is trying and learning new things. Inevitably, you will be bad at many of these things the first time you try them. Maybe you botch a presentation to senior leadership, maybe the first…
This project is going to be perfect. You're not going to cut corners. You're going to finally do things the right way ™ even if that means working way harder or taking way longer . But how do you know what "perfect" is? If your feature isn't released yet, you don't really know how users are going to use it. You'll never know less about what your project needs than right now, so how can you know…
It can be easy to think that your job is to write code, but it isn't. Your job is to solve problems. Code is just a pretty good tool for many of the problems you're likely to work on. Unfortunately code is where bugs live. Every line of code you write is a place where something could go wrong. It's a little bit more complexity in your applications that people will need to understand. It's weight…
Well, you failed. Your project shipped late. Or it was really buggy when it did get shipped. Or maybe it just didn't work out and got scrapped entirely. That sucks. But don't waste the failure. Do something with that failure. Failure is a valuable piece of information. It can be used to figure out what assumptions were bad so that you can update your judgement for next time. It can be used to show…
It can be easy to be impressed by a particularly clever piece of code and assume that the effort required to understand it is a sign of skill in the person that built it. While this might be true for a good puzzle it is quite the opposite for a good solution. Ease of understanding is part of the functionality of a solution. Code is not static. Codebases will be read and modified by many people…
We've all gotten really excited about a new project; building something interesting, learning something new. Things go great until they don't. You get stuck in gumption traps , you get short on time, and the honeymoon phase of the project wears out. Motivation alone isn't enough to get through non-trivial things. You need to set good habits. Habits externalize your accountability for things that…
You've just been presented with a great opportunity. It will help you get visibility and could really accelerate things for you! You should get started today, right? Maybe? Remember, careers have speed AND direction. Going quickly toward something you don't want doesn't help you and can often be demoralizing. Think hard about what you want and seek out opportunities that will help you understand…
As engineers it can be tempting to think that our work should speak for itself. If you ship good code and solve good problems you will be recognized, right? Maybe. But doing the work without building relationships can put you at a serious disadvantage. Don't use the stereotype of the socially awkward programmer to justify working in isolation. Don't fall into the outdated trope of the surly…
You've just closed the last issue of a major project. It's shipped! Congrats. You start writing your internal blog post about how you "shipped X using Y technology", but why should people care that your project shipped? Why was it a good use of your time to solve that problem? When talking about your accomplishments (to your manager, in a public post, in a self evaluation, etc.) focus less on what…
When thinking about how a project can be completed you can look at 3 different dimensions: scope (how many things need to be done) timeline (when you can complete everything by) effort (how much work you and others can put in) If a new feature is added to a project (the scope is increased) then the project either ships later or more work is done in the same amount of time meaning more hours or…
Your job as a software engineer is not just picking up Jira tickets and completing them. Hopefully. You need to be on the lookout for good new problems to solve. It's good for your career to drive this type of work and ultimately this is how you'll both increase impact and increase your own satisfaction. But what makes a good problem? Richard Hamming wrote a great bit on choosing good problems in…
Positive feedback is pretty easy to hear. Keep up the good work! But critical feedback can be harder, particularly from a manager or someone with authority. When you receive critical feedback separate out the feedback you agree with and the feedback you don't agree with . Now you have two actionable buckets of information to work from. The feedback you agree with can provide clarity on areas to…
Especially when changing expectations. Communication is obviously a fundamental skill and that is never more apparent as when you are changing expectations. Often changing expectations means telling people that a feature will be shipped later than previously agreed upon or some desired functionality just won't be possible. Nobody wants to tell someone bad news and it can be hard to do. But it's…
A lot of recent posts have been about goals but it's important to call out that happiness is the fundamental goal you should be seeking. Why are you doing any of this if it doesn't ultimately make you happy. "Happiness" as a career goal doesn't necessarily mean that everything you do at work will be something you love. There will, of course, be unpleasant things (does anybody actually like being…
You've spent some time figuring out what you want and why , made a plan for how to reach these goals , and hopefully executed on that plan. Great! Hopefully you've learned something. Pay attention to how it feels to get closer to your goals. You now know more about yourself and more about what the realities of your goals. Use this information to make course corrections. Maybe you've been working…
Continuing on with making the most of mentorship , you've now figured out what your goals are so now it's time to achieve them, right? Slow down a bit. Take a minute to think about the best way to work towards your goals. Make sure that your approach is incremental, actionable, and accountable. Incremental steps are small. You can take them right away and see if they're working (and if they're…
The first step for making the most of mentorship really applies to pursing any serious career satisfaction. Know what you want. And why. In order to set goals and hope to be happy with accomplishing those goals you need to know yourself and what really motivates you. Start thinking about what you want to do. Maybe that's become a manager or start your own startup or be the most technical person in…
Having a mentor is great. You get personalized, one on one guidance for your personal growth, but you need to know enough about yourself to take advantage of that individualized support. It's your job to figure out where you want to go. It's your mentors job to help you get there. Here's a rough framework for thinking about that: Step 0: Know what your goals are and why. Step 1: Figure out how to…
It's not always what you know, but who you know. For any reasonably complex system it can be very hard to understand everything so it's good to know who in your organization can be a resource for the areas you don't know well. You can save yourself hours or days by knowing who can give you a quick overview of a new-to-you system or provide answers about an unfamiliar codebase. How do you find…
It's not enough to do good work, other people have to know how good you are. This can be a hard truth for many software engineers. Being visible is the very similar to selling yourself but in a more implicit way. If selling yourself is about explaining to others how valuable your work is, being visible is about helping others form their own ideas about how valuable you are. So how do you increase…
When you get the opportunity to choose the language or database for a new project it can be tempting to go with something new and exciting. You've just finished a really fun tutorial about it. Everybody online is talking about how cool it is. And you don't want your project to use some boring old technology, right? Wrong. Boring is awesome. Boring means it works as expected. Boring means a lot of…
Your direct manager has some of the biggest impact on your day to day happiness, often more so than the project you're working on or the company you work for. They should be acting as a source of expectations and feedback but if you don't understand their motivations they can become a source of frustration. A manager's motivations are likely a mix of two things; expectations passed down to them…
The earlier you can catch problems, the better. So why not try to catch them before they even happen. When talking through plans for a project, take some time to be pessimistic. Think about what can go wrong. Are there unknowns in the implementation that could prove to be big time sinks or high risk? Are there dependencies on other teams that could fall through? Is it likely that someone will make…
Do you know if your company is in wartime or peacetime? Peacetime is when there are no eminent existential threats to the business. You'll often see more freedom to explore new things, invest in longterm bets, and have more leeway to indulge in pet projects. During times of peace and prosperity it's often beneficial to be a little less focused and try a few higher risk ideas that may or may not…
"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Kernighan's Law So much about the practice of software engineering revolves around building software that we can read and understand. Unless you're just creating a quick script or throwaway tool, the readability of your code is important.…
There's a difference between being good and being useful. You can be good on your own, but to be useful you have to pay attention to what matters to the people around you. And organizations are always going to reward useful over good. If you want recognition, career advancement, job security, all those good things, it's important to really understand what your organization values. Sometimes this…
Your team is just coming off a major incident. In the postmortem you all come up with a number of ways to avoid having that problem happen ever again. Good. Now take a second look at that list and make sure that you're not just setting up guards to prevent the exact same problem. It's important to make sure you don't make the same mistake twice but you want to make sure that your solutions are…
Being good at learning is important. We work in an industry that is always evolving, so learning is a fundamental skill. Teaching, while obviously beneficial to those being taught, has the additional advantage of being a great way for the teacher to learn as well. When you teach, it forces you to clarify your own understanding of the subject matter. This helps you build better mental models for…
There's an old quote by Larry Tesler that goes, "AI is whatever hasn't been done yet." This reflects the thinking that the only things that are impressive are the things we can't do yet. It can be easy to fall into this trap when looking at your own skills. It's easy to forget what used to be hard. We normalize our current abilities and quickly assume that if we can do something it must be…
Sometimes an interesting opportunity presents itself, but your first instinct is to say "no". Resist that instinct. Maybe there's a chance to work on a project that seems really cool, but you're unsure if you have the technical chops to pull it off. Maybe there's an opportunity to speak at a conference but the idea of getting on stage in front of that many people is terrifying. If it really seems…
Let's say your team is having trouble with noisy alerts. Noticing this, you post a Slack message to your team channel saying "Hey, our alerts have been really noisy lately, we should clean those up!". You receive a lot of agreeing emojis and feel good that your team is with you. But still nothing is being done about the noisy alerts. A more active response to this problem could be picking an…
I first heard the term "gumption trap" in the book Zen and the Art of Motorcycle Maintenance (which is only superficially about motorcycle maintenance). The author talks about reassembling a bike only to realize that you've left a part out and how your energy is just drained knowing you'll have to redo everything. Gumption traps are those little demoralizing problems that stand in the way of your…
The concept of "tech debt" is all too familiar to most engineers. You make sub-optimal technical trade offs in order to get some other benefit. There are many situations where this makes sense; you skip addressing some edge cases to hit a tight deadline. But like financial debt, while it can be advantageous to take on, it does need to be paid back. "Process debt" is similar. It involves working in…
The best way to get useful stuff done is to not do other things. Particularly other things that aren't useful. 'No' is an important word for anyone trying to accomplish anything. At work (and in many other parts of life) there will be no end to the things you're asked to do. The only way to really move important things forward is to determine what isn't important and deprioritize it (note:…
Or agree with! Often when trying to come up with a plan for a complex problem groups can get stuck in the stage of tossing out ideas. It's great to spend time doing this, discussing the pros and cons of different approaches, but at some point you need an agreed upon plan and start executing. A good way to get to the point where you have an actionable plan is to just clearly state one as a starting…
When I think about the most impressive and impactful engineers I've worked with the most common trait they share is their ability to learn. It's not just that they have deep technical knowledge in useful areas, though they often do, it's that when presented with a problem in a new area they're able to approach it and gain enough understanding to come up with a good solution. So how do you get good…
Your job is to be impactful. Not produce code. Not close tickets. Not put in hours. To create impact on what ever is important in your organization. There is only so much any individual can do with their time to create impact. It helps to prioritize well, but you're only one person. At some point to best way to increase your impact is to make others better. This can be done in many ways. You can…
You should know a little bit about whats going on in the tech industry. You don't have to obsessively follow hundreds of blogs or know every nuance of drama in each programming language community, but at least have an awareness of the broad strokes. Know what industry trends people are thinking about (AI? Crypto? Whatever is happening now that makes those things look dated?). These things shape…
This is similar, but not quite the same as really being on vacation when you're on vacation . Being unavailable means that during your normal work week there are times when you won't be providing a quick response. And it's important to enforce this. Many have us have come to expect that when we want information or an answer we should be able to get it almost immediately. With email and Slack and…
It's not enough to be just be good. Other people need to know how good you are. Whether you like it or not, an important part of getting recognition for your work (and promotions!) is making sure other people know about what you've accomplished. You can't just rely on the quality of your work speaking for itself or expect others to just see how much you've done. This needs to be communicated both…
Production is down! All the alerts are going off! Everything is on fire! But at least it's not your fault, so you might as well just have a pint and wait for this to all blow over, right? You could. Or you could use this disaster as an opportunity to polish your incident handling skills. Figure out where the problem is being discussed. Understand the actions being taken to understand and solve it.…
Often as you are building or fixing something you'll find yourself doing things that are either repetitive or generalizable. A repetitive task might be something like updating a value on a few thousand records in your database or hitting and endpoint with very specific parameters over and over again. Something generalizable might a script that updates a specific customer's billing date, but if you…
This goes for being home sick, being on parental leave, or any other situation where you are officially "not at work". For many people it can be hard to fully disconnect when you are taking time off. With Slack and email and other things always there, it can be tempting to "check in" or answer a quick message. Often then comes from the well meaning motivation to be helpful to your coworkers. But…
Maybe you know someone who wields their code editor like a magic wand. Maybe their prowess with the terminal makes it seem like they speak directly to the computer. Maybe they have a mechanical keyboard that looks (and sounds) like it could never type a bug. Maybe this person is you. Choosing good tools and developing skill with them is absolutely useful, but don't lose site of what the tools are…
Given that you are a software engineer it might be easy to think that your job is to write code. No. Your job is to solve problems. Understanding software is one of the skills you use when solving problems. In a lot of situations, by the time a problem gets to you writing code might be the best way to solve a problem. A new feature needs to be built. A bug needs fixing. But sometimes if you take…
As you work on growing your career you will hopefully have many people helping you reach that next level, maybe a supportive manager or a mentor. But none of these people care about your career as much as you do. Nor should they. Helping employees advance is an important part of a manager's job, but it's not the only thing on their plate. If you really care about making progress you have to help…
Don't be afraid to speak up when something just seems... off. Maybe some metrics from a team dashboard look weird, maybe there's a change in a PR that you might not fully understand but feels like it might have bad consequences, maybe there's just some long standing code that looks like it can't possibly be right (but it must be if it's been in here for so long, right?). Often it's easy to assume…
As you progress in your career, becoming a stronger engineer and delivering more value you're going to build up trust and goodwill with the people you work with, both leadership and peers. This is your career capital. Now you need to figure out what to do with it. The more trusted you are, the more you are responsible for setting your own path. Shifting from the early career mindset of needing to…
When working on a feature or bug fix it can be tempting to make all your changes at once (this often means everything going out in a single pull request). This can be appealing as it lets you see the full end to end solution locally before you release anything, but it has it's disadvantages. First, it's much harder for others to review large changes. By breaking up your work into smaller, logical…