Stay busy, be unproductive and follow the hype!

When I first started on Airstory, there was no pre-existing code so I decided to research different technical languages to figure out in what language I was going to develop. I was willing to learn a new language, so my options were pretty open.

I have been programming for quite some time, so I am not naive enough to believe there is a “best language” for what I wanted to do. All languages have their benefits and drawbacks but they do not vary enough to say “this wouldnt have been possible in any other language” or “this is the best language to achieve everything that I am trying to do”. I could have written Airstory in Java, C#, Python, PHP, Javascript, Golang, Ruby or any other popular language and still achieve the same functionality seen today.

However, the hype will have you believe there is substantial differences among languages. If you do not choose the right one (and by right, they mean the one they chose) then you are doomed to a special layer in hell reserved for programmers who are full of regret.

It is easy to get swept up in this hype. At first you may shrug it off. After a while, you will start to doubt yourself. Next thing you know, you regret not following “their” advice in the first place (even if it came out after you started your project) and will be looking into a complete rewrite.

Paying twice for the same ground

I don’t pay for the same ground twice

- General George Patton

As I was doing my research, I came across many blog articles covering topics such as “Moving from Python to Node” or “Moving from Node to Golang” or even “Moving from Python to Node to Golang and why I came back to Python”. I was amazed at how many people were continually rewriting the same functionality over and over again but in different languages!

How much time did that take? How much value does this add? And, the main thing, what else could you have built in that time to make your project that much better? I understand you will run into challenges while working with any technology. I argue that the solution is rarely to abandon it all together. Spend some time to really work with what you have; you may be suprised at how far you can get.

The state of Javascript.

As a programmer, you can always expect that technology will move fast. Right now, as far as languages are concerned, no other language is moving quite as fast as JavaScript. I came across this comic a while back that somebody used in an attempt to explain the current state of the JavaScript community.

Standards

It seems like every few months a new Javascript framework will come out. People will rave about how it will solve all the woes they have with their existing Javascript framework. You will start to see articles on how people are migrating over to this new framework. Then you will start to see posts on how the old framework is a failure and how they always knew it was going to be a failure. Finally, you will see comments from developers cutting each other down for having ever used the old framework at all. All this until an even newer framework comes out and the cycle repeats itself over again.

“What!? You are using still using framework X? You should be using my exact setup which I just started to play with! You fool!”

The thing is, this excitement over the newest JavaScript solution is hard to resist. You may be very happy with what you are currently using, but then you will start to see post after post on how great the next thing is and how crappy the old one is. Next thing you know, you are caught up in the hype.

I will sometimes go into r/javascript to see what is new, full of conviction on the technology stack that we are using. It doesn’t take long before that conviction starts to waiver. It’s like a Sirens Song happily luring you into the jagged rocks that is known as Javascript Fatigue.

Sometimes I can get to the point where I start considering a massive rewrite. Eventually, I somehow snap out of it and remember I have a lot of cool things I still want to build that I have never built before…do I really want to spend my time migrating to a new framework? Or would I rather build something great? My answer to that question is usually to close down Reddit and start digging into my next problem.

Grass is always greener

The grass is always greener…at least that is what it seems like from afar. The newest framework will solve all your existing framework’s issues. The language you are writing in is to blame for why your work is challenging. All you have to do is switch and you will be in developer bliss! I have read many stories over the years that follow along these lines. Usually, they are written while the author is still in his first few weeks of using a new technology. What I like to call the “honeymoon phase”. I have yet to see a follow up article from anybody a year later that says, “Yup, still bliss!”

The thing you should always be aware of is this: when you move to a new technology, you are signing up for a whole new set of challenges you haven’t even discovered yet. It may seem daunting at times, but it is better to tackle the challenge you know then to chase after an ideal that doesn’t really exist. Instead of chasing green grass, perhaps you should just water the grass you have.

Know when to hold ’em, know when to fold ‘em…

There can come a time when a switch is justified. For example, a faster framework can be a great move if your users are complaining about how slow your solution is and you have done everything you could possibly do to speed up your current framework. A faster framework is not justified just because “faster must be better.”

A move away from a library may be justified if it is no longer maintained and you need it to be supported (perhaps for security reasons).

A change in language may be justified if your company becomes so massive and the small negatives of an individual language can become unbearable at the scale you need it to work.

But please, keep in mind that Twitter was built on Ruby, Facebook was built on PHP and YouTube was built on Python. It took their current size and scale before these languages, as they are, were not good enough for them. Twitter started to move to Java, Facebook customized PHP with what eventually became the “Hack” programming language and Google invested heavily into speeding up Python and eventually developed Golang. If you are not working at this kind of scale, chances are, your existing language is just fine. And, just because YouTube needed Golang doesn’t mean your solution does as well.

Whatever the reason, it is important you make sure you are switching for the right reasons. Are you really at an impasse or did you just start to drink the Kool-Aid?