Random Newbie Stuff

This post is strictly for people who have just entered into the software profession. I have jotted down some random things that I have faced myself or seen other people do wrong here. The solutions may seem to be pure common sense or banal, but I take that risk of being obvious because I know a lot of people who lack common-sense.

When I was coding in Fortran and C just to get something working, first days as a programmer, I never bothered about anything. I just wanted to get something done, by hook or by crook. Then, after joining a formal course on Computers, I had this notion of a good programmer being someone who spews out code which works on the first go. No errors, compiler or otherwise. Just works. Now, when I recollect what I used to think in those days, I almost feel its so lame that I shouldn't admit to it. But then, you learn soon after shooting yourself in the foot enough number of times that its just not worth it. You have to start coding and face the problems as they come. What I have found out over the years is that it is not only insane to try to write error-free code without actually coding, but also totally unproductive! I agree that human brain is a marvelous thing, but why waste it on stuff which a computer is kick-ass in doing. Don't sweat a lot about syntax and stuff. You anyway have Google, if nothing else. I suggest you, of course, learn the syntax and stuff, but there is no need to memorize it, like a lot of people I know try to do. You will remember stuff if they are important enough. Others, you can always look them up.

A lot of people like to talk about high level, abstract, potential "solution" to a lot of problems. They think and analyze for a long time and fear getting their hands wet. I know I used to do it and I know people who still do. All I can say is that its sheer "balls". You cannot just talk about problems. You have to get down to code at sometime and actually solve them.

Something I have found out is people don't learn the right things at the right time. If you are learning Java, there are reasons why you should, I would suggest you start from the command line and go through the Java classpath hell before you start doing stuff in an IDE like Eclipse or IntelliJ. You need to know how things work under the covers, irrespective of what it is that you are learning.

Something that boggles people down is the size of a code base, either when they join a project middle way or when they have to understand how something works. One thing you need to understand is that it is written in a language, I assume, that you understand. Just think of it as a novel or a text book that you need to read. The chances are you cant digest everything that is there in a day or even in a week. Just like reading a book, you need to start from the beginning, logical i.e., and then move deep into the code base. You will surely finish it, sooner or later! Just like a book, some code appeals to you and some don't. Its up to to you if you really want to work with some code or not. You can always do this. Or bail out.

A few things that I can think of which are done blatantly wrong and which can be fixed easily, with some mental effort.

Redesign the World

As a professional programmer, one of the things I constantly crib about is the fact that NOTHING fits my current requirements. No single tool, no open source library, no neat application, no nothing. I just get frustrated. Something that I want is automation. I don't want to be bothered with repeating something more than twice. I get all pissed because I have to do it. If its repetitive a computer got to do it. Why in the hell would I want to waste my time and effort??

Sometime back we were using Antlr as a Parser on our project. Given the simplicity of our grammar, we thought Antlr would be a perfect fit. But turns out, it was not! It was so painful that we replaced it with a hand written parser in about a day. With complete test coverage.

Given this attitude of "Redesign the one tends to redo a whole lot of things. The most important thing to keep in mind when you want to replace something that already exists and is very irritating is that it solves the problem. Doesn't matter if its not done well, if its slow etc etc. Because the chances are, by the time you reach where that tool/library is, you would have inadvertently ended up making some compromises or hacks every now and then yourself. Unless of course, there is a very strong reason such as the project productivity/velocity is getting screwed etc. to replace the tool.

What's more important is to be wary of what I call the "Quick-Win" syndrome. When you want to replace, lets say, Cruise Control or Selenium RC, its easy to get carried away thinking, "Its just a freaking while loop" and start off. The chances are you will get the basics quiet right, in fact may be better. But there are so many corner cases and issues that something like CC takes care of which were shielded from you that you just wont be able to "hack it" away to glory in a weekend. You will get a quick win in the sense that it works perfectly well in the happy path and feels Oh-so-close-now to the solution that you wont be prepared to give up until the contrived corner cases start biting you. But its just normal that you think its just one of those things or lets just hack this one away quickly which ends up in something "enterprise" like Selenium RC.

All I am saying is, when you want to replace something once and for all, don't think of it as a weekend hackday thing. Especially if its something big. So, take your time and make some wise decisions before starting off.