Runners experience a euphoria known as runners high. Programming creates similar feelings. There are multiple types of highs developers have. Each high can be enjoyed alone or mixed together to get really trashed. Everyone loves a rush of delicious endorphins.

Finding A Problem

Solving a problem in a programmatic way is pretty amazing. The seed of learning to develop begins in many developers from entertainment. They start off learning to code because of video games. At some point though, developers learn more about programming and they want to solve more challenging problems.

As I grew older and learned more about programming, I realized there was a vast landscape of challenges out there, and the opportunities for fun and learning was by no means limited to visual effects and interactive games. I discovered that writing a script parser in a high-level language or implementing a routing algorithm can be just as much fun as pipeline-optimizing rendering loops in assembly or programming an animation engine.

Finding challenging problems and knowing they can be solved with programming is the first endorphin release.

Finding The Right Language

Great developers don’t limit themselves to one tool.

Many times people forget that programming language is just a tool to solve problems. In the end it boils down to problem and a right solution. A problem can be solved in any language, but certain problems can be best solved by using certain languages while others are best suited for other problems. It depends upon using right programming language for solving a particular problem.

It’s lame when developers limit themselves to a single language and argue how awesome it is. Developers who limit themselves to one tool are not educated people.

A person who is a mile wide and an inch deep is not an educated person. But a person who is a mile deep and an inch wide is not an educated person either.

Languages and frameworks are being produced at an incredible rate. This growth will eventually plateu but we should keep partying like we don’t know the great depression is around the corner. The current language trend is for the language to have a very specific use. Rather than being a generalized language, able to solve lots of problems, there is a single set of problems the language is trying to solve.

After finding a problem knowing there is a language specifically suited to solving it is the second endorphin release.

Sharing the Solution With Others

Developers love when people use their products.

At this point the developer has struggled during the development of the solution. They have written the first version of the product. They have found a few bugs and they’ve been fixed. Now is the time the code is shared with others. Depending on what the product is for, this can be done multiple ways.

Productizing the solution is the most common. Another method, which is more common to developer tools and frameworks, is to release the product as an open source project. Regardless of how the tool is released, the developer is still tasked to raise awareness around the solution. Hopefully, one that has viral growth.

Once the code is released, the developer waits, hoping someone will use their solution. Someone has the same problem. A search or two later and they find the developers solution. People have begun to use the developers solution. Release feel-good endorphins.

If they pay for it, even more endorphins!

Getting Complimented

Developers want to work on things that are being used. There is a rush that comes from knowing that the code you are developing will be used by others. However, when someone compliments something that you do another high is reached.

Everyone loves getting complimented. It makes us feel important.

When a product is being used only a few of the users will evangelize the product. When this level of adoption and appreciation happen the developer starts getting high on his own supply.

As a side note, negative feedback can be damaging. Startup advisors teach people to use negative feedback in order to iterate the product. We have to be told and retold not to let it affect our psychology.

Having Others Contribute

Ultimate euphoria. When another developer comes along and decides to contribute to your solution an overwhelming feeling comes over you. Recruiting others to contribute to your code base is a necessity if you are building anything that is widely used.

Contribution comes in two forms: Paid and non-paid.

You may think paid contribution doesn’t make developers high. You would be wrong. Having the means to hire another to work on your solution is pretty sweet. If you are hiring correctly it’s an amazing feeling. You have convinced someone else about your vision. They are contributing to the code base, not only for money, but because they believe in what you’re doing.

Non-paid contribution happens with open source projects. If another developer finds what your doing to be helpful they will offer patches to your solution. These patches could be fixing bugs your code base has or adding features which they required in order to use the solution.

Elegance

Like artists developers love being Elegant.

I’m still hunting for this programming “high”, but nowadays it’s less about making the computer simply do something, but getting it done in a beautiful, elegant, eternal way. That’s what keeps bringing me back to writing code.

Elegance can be so powerful that it is the only driving factor to why you develop.

blog comments powered by Disqus