When it comes to programming, there is the notorious myth of the 10x developer.  It is said that a 10x developer accomplishes roughly 10 times as much as the other programmers on the team.  It’s quite a controversial topic and there are people on both sides of the issue.

Some people propose the myth of the 10x developer is absolutely ludicrous and others say that the variation from a standard to rockstar programmer is more like 100x or 1000x more productive.

Whether you choose to believe the idea of the 10x developer or think it’s utterly ludicrous, here are 29 behaviors that all uber-productive developers share. We think #29 is the most important one of them all.

1. Use Google very aggressively.

As a developer, you need to know how to phrase search queries, review what other people have discussed about the topic you’re researching, and apply what you learn to the project at hand.

When faced with a problem, unstoppable programmers know how to take a moment to research and understand the problem at hand.

As a programmer in 2016, it’s essential to know how to properly research tools using the technologies available on the web, It’s why such a simple trick you can learn in 10 minutes can radically change how you approach the programming problems you encounter.

2. Maintain an obnoxious amount of stick-to-itiveness.

Technology evolves so quickly that you need to constantly be learning new technologies as they come out. As such, you’ll need to feel comfortable looking at things with a fresh perspective when you have zero experience.

The best developers embrace the experience of being a beginner with new technologies and master the process of teaching themselves to be self-sufficient developers as quickly as possible.

Every expert was a beginner at some point in time.  And there are so many technologies out there that even an expert at one technology is a clueless noob in another.

3.  Acknowledge that micro-decisions matter.

When writing programs, it can often feel like there are a billion decisions you need to make, even when you’re just adding a small feature. You need to think about things like naming variables, calling functions, naming CSS properties, using a hash vs. using an array, naming things, and much more.

Coming up with good names for things is a big part of programming. It isn’t easy. But it’s important.

Developers also joke that there are two hard problems in computer science: cache invalidation, naming things, and off by one errors.

New programmers often don’t pay enough attention to variables and function naming. Average programmers spend more time thinking it through. And unstoppable programmers have already learned (usually the hard way, through bugs and problems). They’ve developed patterns that help them name variables, and they don’t even need to think about it since they always name things the same way.

4.  Acknowledge that most major decisions don’t matter that much.

In the process of building out applications, you’ll make major decisions that will impact how you write most of your code. For example, you’ll generally want to use a Test-Driven-Development approach. There are a few different tools that you can use to test your code.

In ruby, for example, you might have to weigh the differences between MiniTest vs. RSpec.  People have really strong opinions about these types of decisions. But unstoppable developers think differently and tend to not care too much. They value the habit of writing tests, and they understand that the specific tooling that you use to do so isn’t as important.

Unstoppable programmers do not participate in the flamewars that other developers often find themselves in. Instead, they roll with the punches. Unstoppable programmers are quite zen-like.

¯\_(ツ)_/¯

5. Always use the right tool for the job.

In programming, there are so many different open source libraries, tools, and frameworks at your disposal. Unstoppable programmers constantly evaluate the tools that they’re using and figure out how to pick the right tool for the job. Since they are self-sufficient developers, they’re willing to stomach the pain of learning something new if it will ultimately allow them to be more productive.

These developers research differently than most other people. Most developers review the documentation, read blog posts comparing the tools, and pick a single tool.

But the best developers narrow their research to 2 or 3 options and quickly apply the tool to their project immediately to understand how it will work out in their environment. These developers have no problem writing code that ultimately gets scrapped.

This leads us to our next point.

6. Understand that “code is cheap.”

A top-performing developer will have no problem scrapping hundreds of lines of their 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.

Super productive developers can produce so much more output because they don’t get tricked by the sunk cost fallacy, which causes people to act irrationally, especially when writing code…

In coding, the sunk cost fallacy involves factoring in time you’ve spent working on solving a problem in a certain way.

For example, consider a scenario in which someone started writing code one way for a project and expected it to take about a week. They made decisions based on that expectation, and after working on the project for a full week they realized that it will actually take a month. Most developers will continue the path they’ve already started down, justifying their decision by saying things like, “I’ve already made a week of progress”.

But an unstoppable developer will zoom out and think differently:

“There was a different approach that I thought would only take a week and a half. That means if I take that approach it will be done likely twice as fast as if I keep the following path.”

On top of that, the unstoppable developer will have no hard feelings to the work that ultimately was ditched.  Many people would look at scrapping code in favor of something else as a waste of time. But the experience gained from writing the code was actually the “output” vs. producing shippable code. It was simply part of the process that ultimately led to the result.

7. Evaluate technologies based on all their merits.

It’s not uncommon to evaluate technologies and omit a giant elephant in the room about the particular technology (and just not even acknowledge it). For example, I’ve been very vocal that I’m bullish on the Elixir programming language. It has wonderful syntax, an amazing community, great thought leadership and a bright future.

But the technology is so new that if you want to actually build complex features, you’ll probably have a harder time finding open source technology that will make your life easy than building the same application in Ruby.  

We’ve built the Firehose platform with Ruby on Rails because it’s the most practical decision for the problem. We used technology that makes it easiest to make it happen in 2016. In 2017, 2018, 2020, the technology may be different and we will adapt as needed.

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. As an unstoppable programmer, you understand that your self-worth isn’t tied to a few facts you’ve memorized. The “stuff” doesn’t matter.

What makes you valuable isn’t what you know, but rather your adherence to these behaviors.  The unstoppable programmer knows that the details often matter very little. Beginners often find it difficult to get ahead of the curve on technology.

Unstoppable developers realize that every technology they know (programming language, framework, library, etc.) could no longer be a viable option tomorrow.  They think about programming and problem-solving at a higher level.

9. Always analyze the clues found in error messages

Traditional education has taught us that failure is bad. And when learning to code error messages are often associated with failure. Unstoppable programmers know that the path the right solution is usually paved with a lot of steps in the right direction that aren’t perfect.

Learning how to troubleshoot and debug error messages is an important skill.  And the “error message” generally consists of two parts:

The first part is the actual message of the error, which is a plain-text sentence describing the problem that exists in the code. However, the error message on its own usually isn’t enough to solve the problem. The Call Stack is more important.

A Call Stack is a term developers use to describe “how they got to a particular line of code.” It is generally formatted to show you the following information:

• The exact line of code that contains the error
• The reason why that line of code is being executed.

By tying in the initial error message of “a plaintext description of the problem,” it also hints to why the line of code is incorrect and how to fix it.

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.

10.  Know the difference between a premature optimization and a show-stopping optimization that NEEDS to happen.

Code often has trade-offs. A benefit of one approach might have an unwanted side-effect.  This is particularly true with speed, especially taking into consideration the size of the collection that you’re working with.

Typically, there are at least two different ways you can write your code:

• Way #1: Done in the Most Straight-Forward Way Possible
• Way #2: Done in a More Confusing Way to Be Faster

In most cases, writing confusing code to go faster doesn’t matter. For example, if you have a web application with around 1,000 users, looping through each of the users can probably be done in a couple of milliseconds (basically what feels like instantly).

However, if you’re dealing with sites at the scale of Facebook, which has billions of users, looping through each of them isn’t feasible in most situations.

Most use cases fall in somewhere in the middle. Knowing the right time to write code that’s a bit more confusing, but will be faster, is a valuable skill to develop.

Since people want applications to be fast, you need to consider how long it will take your code to execute. However, it’s even worse to take code that is already fast enough and turn it into something that confuses other developers (and ultimately slow them down and cause bugs).

Unstoppable programmers generally opt for simpler solutions that are slower, without indications that it’s too slow. You can gauge this from the program’s running speed, benchmarking tools, or profiling tools like NewRelic.

11.  Take responsibility for your mistakes.

Mistakes will happen.  Especially when working on a team. Most problems that result from working on a team are not related to code, and they involve miscommunication between members. Typically, there are multiple parties at fault in these situations.

Unstoppable developers treat their life like they’re in the driver’s seat.  100% of the problems they face are a result of their behaviors, even if the only option is to find a different job. They don’t spend time trying to pass the blame off on other developers, processes, or environment.

Rather than fidgeting around worrying about what other people think, unstoppable developers focus on what they do have control over: code.

12. Become a power-user of your development tools

Unstoppable developers are power-users of tools within their development environment.  As a programmer, understanding the programs you use to write programs and becoming a power-user is important. The tools you’re using likely support advanced tricks, plugins, and shortcuts for common tasks.

It doesn’t matter what makes up your toolkit, and if you use Sublime Text, Atom.io, Emacs, Vim or Visual Studio. If you spend a good percentage of your time coding in a specific environment, you should know exactly how to control it.

That said, tools like Sublime and Atom are easy to pick up.

Tools like vim and emacs are notoriously difficult to learn, but their skill-cap is quite high.  This means that people who are great at these tools run circles around people who are great with conventional text editors.

For inspiration watch the one minute demo of Destroy All Software, this video (skip to the middle), or the, or this video of hacking go in vim.

Unstoppable developers generally start out by mastering easy tools, like Sublime Text or Atom. But unstoppable developers also want to improve, so they eventually graduate to Emacs or Vim (or use spacemacs and use both!)

Plus you can probably learn it in a week if you take the right approach.

But it’s probably wise to make the switch after your second or third job as a developer to tackle learning a command-line text editor.  If you’re a rookie programmer you should just use the easiest tools to get the hang of.  

13. Know how to use Vim (at least a little bit)

All unstoppable developers know Vim. At least a little bit. They might not very good, and many would never write code on their own machine using it, but they are capable of slowly muddling their way forward using that text editor.

This isn’t a stance on the Emac vs. Vim flamewar. Instead, it’s just that most linux servers will come pre-installed with Vim, and it’s handy to be able to quickly edit a file on a headless server. Most serious developers can edit files on a server that doesn’t grant them install permissions for other programs.

It’s actually more than likely that your systems administrator won’t let you install emacs on the server…if only to troll you.

Your only other option is to learn nano. So… yeah. Just learn vim.

14. Never accept freelance work in an unfamiliar technology

Unstoppable developers are curious. They’re naturally interested in emerging technologies. After working on a side project or two, freelance projects start to come along and it can be tempting to experiment with a new technology.

The best developers’ treat their full-time job as a place where they get paid to learn. And when freelance work comes along it can be tempting to get paid to learn new technology. But unstoppable developers know to avoid this temptation. Here’ why:

A big part of freelancing is estimating and projecting how long things will take. If you’re working with an unfamiliar technology, you will have no idea how to estimate time. Some tasks might take you much less time than you anticipate. However…

More than likely there will be one or two things that will take a massive amount of time to figure out in a new programming language or framework. Unstoppable programmers know to never put themselves in this awkward spot where they have to rush to figure things out on the fly. Instead, they only agree to freelance work with technologies that they know.

15. Don’t count the number of hours

Unstoppable developers spend all their energy focusing on the technical aspects of the code they’re working on.

They understand that there are two types of work you can do in a day:

• Deep Work: Cognitively demanding tasks that require you to focus without distraction and apply hard to replicate skills.
• Shallow Work: Logistical style tasks that do not require intense focus or the application of hard to replicate skills.

Unstoppable programmers spend time doing deep work. This is the stuff that challenges you intellectually and requires you to be sharp (this is coding). Shallow work like responding to emails, etc. will generally only be an interruption to what really matters.

There’s generally a limit to the amount of deep work you can do before getting mentally fatigued. For many developers, it amounts to about 6-8 hours a day. Once you work past the point where you’re tired, you make silly mistakes that actually take away from the progress that you made previously.

Unstoppable developers know that the number of hours doesn’t matter. They don’t push themselves too hard because they know that working in a mentally exhausted state is counterproductive.

Don’t kill yourself. Tomorrow is another day.

16. Absorb massive criticism with ease

Developers who produce more code than others need to get used to getting their code torn apart. You need to develop the ability to react rationally and logically when that occurs.

A co-worker who critiques your code doesn’t think you’re stupid. They’re just demonstrating that they think a different approach could be better. As an unstoppable developer, you need to be able to react to this feedback logically.

If you agree to the criticism, which is generally something you will probably do, simply update your code to use the new approach.

If you disagree with the criticism, which happens sometimes too, you need to learn to stand-up for the approach you took and talk about it’s strengths, weaknesses, trade-offs and merits.

Generally, feedback on your code will result in one of two reactions from you.  Either:

“Silly me.  I can’t believe I missed something so obvious.”

Or:

“You’re absolutely correct, however in order to make this certain situation work, this is the only viable option.”

There’s nothing wrong with updating your code based on feedback from other developers.  In fact, getting frequent code reviews prior to code being accepted to the project is one of the best ways to level up as a developer, especially if the person giving the code review is a stickler.

17. Pair program with people with more experience

Pair programming is when two people work on the same code at the same time. One person is the driver (one who types the code), and the other is the passenger (one who guides the discussion of code). There’s no faster way to learn to code.

18. Always code review your own work first

This is a simple rule, but it falls a little outside the norm. There are so many developers who propose a change to an application but don’t take the time to look at their own code.

Before you issue a pull request on GitHub, review the code and pick it apart in the same way you would if it was someone else’s code.  You can avoid a lot of negative feedback on your code by doing this one simple thing.

19. Recognize that the hard part of freelancing isn’t writing the code. It’s everything else.

The reason that many freelance developers have seemingly outrageously huge billing rates (it’s not uncommon to bill for hundreds of dollars per hours) isn’t because writing code is hard.  It’s because everything else about managing freelance coding work is hard.

Unstoppable developers understand that while writing code is a critical role in building the products, it’s just part of the equation. Sales, marketing, customer support, quality assurance, and product management are all hard too.

20. Identify and resolve bigger issues

Many different types of people are responsible for building complex software. There’s a sales team to generate revenue, marketing teams to lead growth, and customer support representatives to make customers happy.

Product managers are an integral role and act as the middleman between different teams. They assign priority to the various stakeholders’ work for the development team, and they balance the immediate needs with the long-term vision for the product.

The biggest problems that developers fact typically are not related to code. Instead, it’s managing your relationships with:

• other developers on your team
• your manager
• your product manager
• (and everyone else in the company)

You run into problems like:

• Working on the weekends to stay on schedule.
• Constantly having bugs in your code and having to ship hotfixes.
• Production site goes down multiple times.
• Initiatives start but before there is adequate time to finish it there are new higher priority initiatives

Normal developers think about the implications as they pertain to the specific situation and code that is required to resolve the immediate issue at hand.

But often, the problems aren’t normal and are the result of a team or individuals doing things to prevent the dev team’s rhythm. Unstoppable programmers understand this and know to deal problems in a way that leads to more long-term solutions.

21. Dive into large open source projects to bring your features to life

There are times when things like web frameworks (or other open source projects) won’t allow the support functionality you’re looking to build natively. Most developers would say that this makes the task at hand is impossible to pull off.

But an unstoppable developer will dive into the framework’s source and try to figure out how to monkey patch a solution. Monkey patching features in open source projects is another term for a temporary work-around (aka horrible hack) that adds the functionality to this open source project.

In order to implement this, developers need to gain a good understanding of the code of the framework related to that feature.

Most developers are afraid to even start. Unstoppable developers can’t stop themselves from diving right into the fray.

22. Skip a lot of meetings

If you work at a big company, there’s no bigger waste of time than meetings to talk about future goals and work that’s currently being done. It’s not uncommon to spend more time talking about work that’s happening than actually doing it.

It’s common for developers to complain about the crazy abundance of meetings they need to attend.

People won’t give you flak for not showing up.  Your company pays you to write code.  Not to talk about writing code.  While most developers complain about meetings, some secretly like them because it’s really shallow work that’s easy to do.

An occasional meeting isn’t bad since it can break up the day. But when the calendar starts filling up with 3-4 hours of meetings per day (and it happens), unstoppable programmers start skipping them. People will appreciate your time more if you start doing this.

23. Know when it’s time to give back

At the start of your career, you have to focus on honing your craft. You spend a lot of time working with other developers who have more experience than you, and by doing so you learn tricks of the trade.

As an unstoppable programmer, there’s no more effective way for you to code than to churn out a ton of quality code with your headphones on. But if you want to become an unstoppable programmer, there comes a time when you need to start giving back to junior developers, just like your mentors did with you. For all you know, that junior developer is well on their way to becoming an unstoppable programmer too.

24. Be capable of writing bad code

Unstoppable developers are capable of writing bad code. Sometimes. Not all the time. But sometimes, when it’s the right call. The so-called Duct Tape Programmer knows this:

The real world is messy. As someone young and idealistic it can be tempting to live in absolutes and extremes. But given the realities of deadlines, expectations, and the benefits of certain features, not everything is possible.

It’s sometimes the right call to work with a temporary workaround (aka a horrible hack). Since code is cheap, and unstoppable developers have no problem if their code is later replaced, responsible laziness is helpful.

It’s worth noting that most people live in extremes on this category and are either:

• Absolutely reckless and write terrible code.
• Over-engineer complex solutions to simple problems.

The best developers know when it’s acceptable to take a shortcut and when it is absolutely needed. This is one of the most difficult skills to learn.

25. Let Other People Know That You’re Working Late Without Being a Jerk

If you’re the last one in the office and working late, the last thing you should do for the day is send an email to someone with a quick update.  People will generally notice the timestamp, especially if it’s really late and even if they don’t acknowledge it, they’ll know you’re working hard.

26. Act as a leader, not a boss

Unstoppable programmers are leaders. They are not bosses. There’s an important difference.

• Bosses are people who have people work for them.
• Leaders are the people who other people follow.

Unstoppable programmers are the leaders of their team. They may not have a title. But they’re the people who the entire dev team looks to for their judgment.

On development teams, there is one key difference between leaders and managers. Leaders live in the trenches and do the work (and often the most work) of the team. Managers might be able to tell you the correct answer in theory, but the leader has enough context to have an opinion that is highly respected.

27. Go play foosball. That’s often more important than coding.

Or ping pong.  Or something.  The feature that everyone is talking about today will soon be old news and everyone will be talking about some other feature that’s in the works.  Features might be broken into x-week chunks that are called sprints, but unstoppable developers are running the marathon.  Endless working absolutely as hard as physically possible will make you miserable.

Invest in yourself for the long haul. So mess around here and there if you’re overworking yourself.

Your team will be around forever. Building relationships with other developers (and even people on different teams or roles), will ultimately be more important than getting a feature shipped a little sooner.

28. Learn under pressure.

Most unstoppable developers have been in a situation where a system has gone down or something was broke, and they are responsible for getting it back up. Often, they won’t know exactly how to solve the problem.

Truly unstoppable developers are capable of excelling in high-pressure situations like these, and they have the ability to learn new things like:

• Performance tuning
• Server configuration
• Data migration from different systems

Learning new things while in a high-stress environment is one of the hardest skills to master, but also one of the most important.  

But to truly be an unstoppable programmer you need to implement one behavior above all others.

29. Move Fast and Break Things

Don’t let perfect be the enemy of good.  Mistakes are often the best learning opportunities. So don’t treat mistakes as failures. Instead, treat them as learnable moments, where you take a step back and evaluate how to prevent the situation the next time.

The key to growing is understanding how to make the same mistake only once.

Programming, like many things in life, is more about the work you put in than your actual know-how. That’s why so many of the behaviors that will help turn you into an unstoppable programmer can also help make you unstoppable in everyday life.

Now, what are you doing on this blog post? Close this and start programming. You can start by jumping into our free Software Engineer Intro Course here.