6. Understand that code is cheap.
You need to be ok with scrapping hundreds of lines of code to do things in a different way. Often, the only way to learn that a certain approach will not pan out is to give it a solid attempt.
Many people look at scrapping code in favor of something else as a waste of time. But the experience gained from writing the code should actually be considered an “output,” just like shippable code. It’s simply part of the process that led to the result.
7. Evaluate technologies based on all their merits.
Often, average developers will evaluate technologies while omitting the giant elephant in the room. For example, I’ve been bullish on Elixir. It has wonderful syntax, an amazing community, and a bright future. But it’s so new that if you want to actually build complex features, you’ll have a harder time finding open source technology to make your life easy. You need to take all of these factors into account.
8. Say “I don’t know.”
There’s no quicker way to waste your time as a developer than to refuse to acknowledge what you don’t know. Unstoppable programmers understand that your self-worth isn’t tied to a few facts that you’ve memorized. The “stuff” doesn’t really matter.
What makes you valuable isn’t what you know, but rather your adherence to these behaviors. Unstoppable programmers know that every technology (programming language, framework, library, etc…) could no longer be a viable option tomorrow. They think about programming on a higher level.
9. Always analyze the clues found in error messages.
Traditional education has taught us that failure is bad. Error messages are often associated with failure. However, good programmers know that these messages are actually clues that lead you down the path to the right solution. And they know that they consist of two key parts:
- The actual message, which is a plain-text sentence describing the problem that exists in the code.
- The Call Stack (the more important part), which helps you understand the exact line of code that contains the error and the reason why that line of code is being executed.
It’s also worth noting that developers are likely to encounter similar error messages time-and-time again. You should focus on learning how to fix the problems and why you need to fix them. Doing so will allow you to fix similar errors at a faster rate in the future.
For example, ruby developers have seen the error message: “No Method Error on nil:NilClass” probably more times than someone starting out has seen any error message.