Ignore nifty distractions and work on the important things

10x/rockstar/ninja developers are real and how to be one

The new year is just around the corner. With it comes the social obligation to consider how one will try (and most likely fail) to make next just a bit better than this year.

I want to be more productive and here is my take on productivity. Forget 10x. Let me suggest that there are only 1x developers and 1/10x developers. The 1x-ers spend 100% of their time and effort on what matters. The 1/10x-ers waste 90% on being busy doing the wrong thing.

To demonstrate, here is a list of 10 things you can do as a developer:

1. Solve a problem with code
2. Create a problem with code
3. Write nifty code that solves no one’s problem
4. Have a meeting about the wrong problem
5. Have a meeting about … I really don’t know
6. Watch a YouTube video about someone else’s nifty problem
7. Have a meeting about deploying your code
8. Have a meeting about deploying someone else’s code
9. Give an update about your code to someone who doesn’t care
10. Give a status update on the outcome of the meeting about deploying someone else’s code that created a problem.

As you can see, being a “rockstar” is not inherently about doing more, but rather doing less. By choosing to ignore 9 out of 10 things on the list above, you are free to get 10 times as much of the right stuff done. #RealMath

Maybe you have worked with that guy who churns out bad code at furious pace. Had he literally done NOTHING all day, the company would have likely been better off. “Working” long hours just gave him more time to waste yours. Don’t be that guy.

Here are a few pointers on the best ways that I can think of to ignore the nifty distractions and work on the important things.

Know the fundamentals

Understand the problem

Elon Musk has made Aristotle’s First Principle thinking sexy again. As he (Musk) explains it “You boil things down to the most fundamental truths … and then reason up from there.” To over-simplify the origins of SpaceX, Musk observed two fundamental principles: 1) rockets are expensive but 2) raw materials are relatively cheap. The logical conclusion was to design and build his own rockets.

As an example within the software industry, you may observe the fundamental principles that 1) at lunch it takes everyone a while to find a place to eat, but 2) only a few people have strong opinions about where to go. In this case, the logical conclusion is to develop an algorithm that quickly recommends something based on a few weighted preferences. All of the resulting conversation and code should be about HOW to make that happen. Anything else is a waste of time! Don’t build a food-oriented social network. Don’t build your own cross-platform mobile UI framework. Don’t build a custom suite of tools for your deployment pipeline.

Don’t get me wrong, food consumers are social and your app UI needs to be high quality and deployed cheaply, but don’t waste brain cycles on those solutions if your fundamental problem is “instant weighted recommendations.” The best over-the-counter tools will be more than good enough. Remember, customers don’t buy nifty code that solves YOUR problem, they buy nifty solutions to THEIR problem.

Rockstar developers understand the problem and why it must be solved.

Understand the solution

Don’t write code when more code is not the solution. Not every solution comes in the form of in-house development. Is there an off-the-shelf tool that does 80% of what you need? Done. Even though you might admire the problem and think you could do better, don’t be tempted to solve it yourself. Sometimes the solution is as simple as a spreadsheet or regular phone call. While patently unsexy, Excel is often a fantastic 80% solution that lets you focus on your secret sauce.

Bad solutions are also known as problems. Roughly 75% of a project’s cost comes from maintenance after it is initially shipped. This means that if you decide to finish and deploy the wrong solution to justify its sunk cost, you will end up paying that amount 3 MORE TIMES rather than being able to invest time and effort in the correct solution. It is often tempting to jump into a project by writing code rather than identifying the correct solution. Immediately building the first solution that comes to mind before the correct one is identified leads to expensive rework. As a coworker of mine says:

“Months of coding saves a week of planning.”

Lastly, ensure you can actually “hit the high notes.” Of everything in this article, this is the only one that has anything to do with the hard skills of a developer. While much of productivity has to do with “not doing those bad things,” you still have to be able to do the right things with excellence.

Joel Spolsky refers to this as “hitting the high notes.” In his own words:

“Mediocre talent just never hits the high notes that the top talent hits all the time. The number of divas who can hit the f6 in Mozart’s Queen of the Night is vanishingly small, and you just can’t perform The Queen of the Night without that famous f6.”

If your company sells software (as opposed to, say, a bank that has an IT department), then its success or failure is predicated on the quality not the quantity your work. Invest the time to get really good at the skill sets needed to solve your core problem. Even if your problem domain struggles to hold your interest, that’s still good data. If all of the interesting problems seem to be elsewhere, go to where they are rather than importing a shiny albeit incorrect solution.

Rockstar developers avoid even the niftiest solutions to what is NOT the problem.

Solve, then automate

Human developers are good at creativity but bad at repetition. Machines, on the other hand, are horrible at creativity but awesome at repetition. Exploit this! Don’t limit your investment to just the creative process of solving problems. Take time to automate the resulting solutions. Problem solving without automation makes you a victim of your own success.

If you spend a few days learning how to deploy your project to the cloud, don’t stop until you have automated the process. NOT doing so guarantees that you are going to be stuck with that task for the foreseeable future. This will consume time that is much more wisely spent on solving your fundamental problem (which is likely not sitting through deployment meetings and following checklists).

Granted, be aware of how much time automation will save and thus how long it will take for you to see a return on your investment. Consider the following:

https://xkcd.com/1205/

Rockstar developers don’t waste time on repetitive tasks.

Scale out, not up

Humans scale poorly. (Although, at this time of year I usually tend to scale out … heh heh.) Everyone has only 24 hours a day and thus can only get so much done whether that be coding or communicating. Dan Abramov, an author of Redux, wrote a fantastic article related to this because, in his own words: “I am a human and don’t scale.” The majority of his post is a strategy for the community to leverage his work without taking a direct dependency on him.

This is the first part of scaling well: don’t be the the sole repository of your own knowledge. Dump your knowledge as publicly as possibly and then point others there. Invest time building a community around your area of expertise. Train others, write good documentation, blog, contribute to open source projects, speak at meetups, become famous, you know … find ways to communicate to a many people as possible as efficiently as possible.

The second part of scaling is learning to communicate asynchronously. A verbal, face-to-face conversation means that all parties must find time to meet at the exact same time. Steve’s first law of meetings states that the probability of scheduling a meeting quickly is inversely proportionate to the number of participants. When the system you built goes down at midnight, the on-call team needs your knowledge NOW, not at 10am the next morning. Communicating asynchronously means documenting and training when all systems are green so that you don’t have to be around when stuff goes sideways.

Rockstar developers communicate well so that others can be rockstars too.

So, you ask, do I consider myself a 10x Rockstar? Going back to first principles, I have a mortgage payment to make, and our customers have money. Therefore, the most logical conclusion is to get stuff done, ship an awesome product that our customers love, and then swim in the piles of cash that they throw at us. If that’s what a Rockstar is, then bring it on!