Softwarant

Why I have stopped programming since the last two years

The Affair

My love affair with programming started way back in the 10th grade. I was interested in developing interactive web applications and the best tool to accomplish that then was Adobe Flash. The sheer number of sites built entirely on Flash was astounding and all of them were exotic presentations enabled by motion graphics — things HTML developers could not even dream of. Then HTML5 happened. But that’s another story. Trying to figure out how to add interactivity to my animations had led me to reading Essential ActionScript 3.0 by Colin Moock. I’ll never forget it. That guy was my hero. This was the book that essentially introduced me to programming. It is literally where I learnt what boolean meant (a concept that took me quite a few days to grasp) and what OOPs was. It was beautiful. This book taught me to think in objects and systems and excited me to explore programming further. This lead me to VB and C++ and before I knew it I was just writing programs for fun. Gone were interactive websites. Just plain old data processing.

I was interested in designing systems and how its components would work in harmony. How the system evolved as a process over time simply fascinated me.

The image of a well designed and constructed factory or a well oiled machine remains affixed to my mind working continuously to do its job. And it was this fascination with processes and systems that finally got me interested in biology when I realised that living systems are the most sophisticated and complex of such processes. Software just wouldn’t cut it for me again.

Marriage

College was where I truly dived into the art of programming head first. I married it. C++ was instantly ugly and I broke up with it forever for the beautifully simple C. Just functions and some data structures. Java was so verbose and ugly that I have never even bothered to learn it and actively avoided programming in it. Again the focus was on developing algorithms and programs that solved problems. No one gave a shit about the UI since there was none. Probably a menu at most. I still cherish the time I spent thinking hard about writing a novel cows and bulls algorithm for people to compete against. I literally spent a month just thinking through the problem before writing a 900 line ugly ball of mess. But for me then it was a trophy of accomplishment — of having spent a month figuring out a solution to a complex problem.

Then something happened and I started moving out of command line C programs towards web systems in Rails because that’s what you needed to build products. Initially it was beautiful and fun. Ruby was much better than C and you could build web systems. Focus shifted entirely on building CRUD applications with UI. This went on for a few years and I didn’t know it then but I was slowly dying inside. I was writing the same CRUD code in a new language/framework and my skills were about grappling with the language/framework to make it do what I want.

I became a Rails developer. But if you think about it what does that even mean? We now have Hadoop/Rails/Node/etc developers. These are people who have mastered one technology stack or language. Isn’t that weird. People are spending years mastering a language or technology stack yet still making the same CRUD systems in very different ways with no majorly apparent tradeoff. More importantly the experience isn’t evolving and the fun is dying.

I also tried my hand at Ember.js and after having wasted 6 months grappling with the framework I gave it up in exchange for the simplicity of Rails. Rails is great as long as you’re doing what it does out of the box. Try and fight it and you’re fighting an uphill battle. But that’s true of all frameworks which is why I started hating “frameworks”. My exposure to the internals of the Rails codebase during GSoC also gave me an insight into the huge systems we have built and how incredibly complex they are. If you’re trying to read one of these you’ll blow out your brain by the sheer number of classes and methods going around. Why? Oh why can’t we build simpler systems using fewer components.

Espress

Espress was my first startup where we were trying to build a platform that connects writers, designers and marketers to come together and create a book. It was trying to solve the problem of helping self publishing authors find the right kind of people. Yet what I ended up developing over a period of 9 months was a CRUD app where you could create and write a book and a simple forum for your project where you could add people to discuss. Needless to say it was highly disappointing and unfulfilling. I realised I had no new insight about solving the problem of getting these people together. Just making tools — that too in this case very basic CRUD tools was never going to lead anywhere. I took a brave decision to let go of my intern (the poor chap) and shut down the company in one day. I was shattered and depressed for a better part of three months. I had dreamt and thought about Espress on and off for close to 5 odd years and yet I had missed the most crucial aspect of it. This was a classic case of an engineer’s naivety. To a hammer everything looks like a nail. The whole process had been about building the “web app”. The underlying architecture and the code structuring. It was still a CRUD app that solved zero problems.

What does an Engineer do?

An engineer solves problems. Right? So if you’re an engineer and therefore have studied engineering, I ask you this — what problems can you solve? No really. I need you to answer that.

What are most of us doing? Making the same applications that create, read, update and delete data with some validations and constraints. But pretty much just moving data in and out of a central database. It might seem like solving a problem the first time but when you’re writing the same code the fourth or fourteenth time you really start questioning why you’re even doing this in the first place.

The creativity inside me died. I was no longer solving domain problems but language and framework problems. How do you do this in language X and framework Y. I imagined a product and then kept fighting with the framework trying to make it do what I wanted. Domain problems were not even part of the equation. It was always about making UIs and UXs. The backend just processed data and persisted it.

This is not to say UI and UX problems don’t exist. Just that what got me really excited about programming was solving domain problems not artificial framework problems. Most languages and frameworks suck. Rails is still better once you gain enough familiarity. I have also been doing iOS development in Swift since a year now and it’s one of those things that kills me everytime I try it now. Swift is a horribly complex and verbose language and UIKit is incredibly powerful but also complex. You need to know a bunch of patterns and tons of classes to make them work in tandem and do things which you mistakenly had thought should have been simple.

Divorce

My stint at Disney was the last time I programmed a bit. The challenge was interesting but I was frustrated with the way we were solving these problems. It felt like labour. My colleagues Rahul and Saurabh are well aware of my rants and “kya bakwaas hai yaar” when confronted with how things were done in computer science. I gave up programming in mid 2015 and since then have been meditating, thinking about all this and learning hardware — the only source of little creativity and newness in my life. Hardware was interesting that way not because it can’t suffer from these chores. The problem with software development is that we’re dealing with code all the way down while hardware development has many varying components and layers that you need to solve problems at and deal with.

I was increasingly becoming aware of the fact that the basic tenets of programming were flawed and our concepts of variables, objects and processes were messed up.

2015 was a milestone year in my life as all my frustrations also culminated into solutions. 2015 was the year of serendipity for me. The cool thing is that I was right about my frustrations. While my colleagues happily code away in ignorance — grappling with misconceptions in the name of hipness, I have started walking on the path of truth. I’m back with the right mindset and the right tools to move forward. Now onwards I’ll only solve problems.

I know this post has no rhythm to it. But this article isn’t titled softwarhythm. It’s titled softwarant. It’s a rant. Get it?