I have been a programmer for over 9 years. I continue to be a programmer – although the way I go about programming has changed drastically over the past 6 months or so. First let me start off with my previous incarnation.
When I joined IIIT, I knew nothing about computers. I hated programming (I still hate some programming languages) mainly because the very foundation of programming languages is not upto mark. Spoken languages, albeit have a lot of ambiguity, tend to be places where we can play around with words. Programming languages base their concepts in mathematical formulations or close to metal abstractions. In a simple sense programming languages are not for people to communication between one each other. They are for communication with a logic machine. This is the beginning of all problems in Computer Sciences courses. You know that something is wrong when so many books are written on how to squeeze your thinking into a programming language’s paradigm (OOPS, AOP, Structural languages etc;). You know something is wrong when processes are designed around how to “reduce” bugs.
I started off with the language C and honestly it is one of the most ridiculous looking language. Didn’t like it. Not one bit till I played a game called Comanche Gold – a helicopter sim. I wanted to change somethings in the game but did not know how. So I went to my professor back then – Dr Govindarajulu. He was the one who gave me the right reason to start programming. I attribute all of my programming skills to him. After that, I’ve swallowed C and then C++, as a bitter medicine. Still, I always used to write down what I was thinking before writing the first line of code. It just felt right.
Then I joined professional stream. By golly I never imagined that I had to write so much documentation for a measly single line of code. It was ridiculous amount of overhead. I know why that was the case – writing large systems is like the layers of onion. If you slice it open all you end up with are tears. It was also because of the fundamental flaw with the assumption that no matter what you do, you will always have bugs.
That one statement somehow has been mutated into a resignation. Apparently programmers now are entitled to having bugs in their code. They rely on testers to discover their issues. That is “outsourcing” (read: disowning) responsibility. I cannot stand that.
Now let us return to what’s happening on the “fixing” the above case – creating processes. I am sick and tired of processes that tend to get invented to fix this situation by adding peer reviews. Understand that writing code is easier than reading someone’s code. Peer reviews are a manager’s way of “fixing” the problem by picking the easiest and the laziest possible solution. I have never seen it work. Yes I am sure someone will say – you are doing reviews wrong. Read the lines again – reading code is hard. End it there.
Here’s how I started changing things on my team. First writing code has to be an enjoyable process. I do this by making sure that I do not hire idiots. Second I ensure that people own significant and complete pieces of code. Third all code that needs to be shared has to have interfaces. Fourth write code right the first time you write it. If there are bugs, scrap it and write it again – no change in timelines. Fifth my testers (currently) are for compliance and large scale integration – they are only to check if people have made the right assumptions with the usecases. Sixth I automate test cases as much as possible. Seventh documentation is not an after thought. At the same time I do not see it as something that needs to fill reams of paper. Eighth I need people to explain to me in plain English what is it that they are trying to achieve. Ninth I always tell my programmers what I want from them and not how I want it from them. Tenth I put them next to artists – I want people who create not who engineer. Eleventh I do not accept a single way to do things. Only when I see multiple discreet approaches do I know that someone has actually thought through the whole process. Twelfth I always think how does this change or add the core problem definition – This helps me make decisions around priority. Thirteenth I love iteration – I first give a solution and then IF and when required I speed it up. Fourteenth I hate guessing when it comes to optimisation. If the profiler does not say a piece of code is slow, it is not slow.
Above everything else, my approach to technology has changed completely. Earlier I believed that technology is what changes lives. That is not true. Technology that makes a difference (to people, processes, humanity??) is the only thing that matters. Today I only ask myself this – do I even need to write this line of code? Is it relevant to the big picture?
Infact I have now started insisting that people TALK before they write. Everything we are doing needs to be devoid of jargon (WTF XML). The problem definition gets one sentence and the solution gets one sentence. If I do not hear that I know that the developer is … outsourcing creativity and responsibility.
Outsourcing: Making sure that Clark Kent can buy a pair of spectacles and Superman can buy his cape at a shop. Outsourcing is not taking Superman’s job in saving the world. So please stop bastardising the word outsourcing. We’ve been doing it for a long time now (I outsource entertainment to Valve Software for TF2).