Dontbreakprod

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

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. Inevit

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, yo

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

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 o

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 solut

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. Motiva

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

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. Do

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