My fallacies as a programmer

Its been 10 years I am calling myself as programmer. Through out this journey I had came across many good programmers. This has been exciting so far. Recently I was reading many articles on web about programming and programmers experiences, each have their unique experiences and there is lot to learn from them. Many of those experiences are similar to what I had. So this motivated me share my (common to others as well) experiences.

No forethought 

One of the biggest mistakes I made as programmers is I never planned before I started coding. I start coding right away without thinking much and researching. But I don't blame too much myself, when I initially started coding I worked on very small scale application where we don't have to plan much, but soon this has become habit and now today with 10 years of experience I still tend to do this mistake. But it's never late than never. What I learned is writing a quality program has a flow:

Imagine and Think. Do some research. Create a draft on paper. Get views from stakeholders. Code. Test. Review and Refactor.

But to be precise, it doesn't come easily. You need to get yourself habitual of following these activities. Programming is not just about writing code, it is a logical creativity that needs nourishment.

Too much forethought

Too much of water might poison you, similarly planning to much is a waste of time. There is no such thing called “perfect plan”. Look for good enough plan that can get you started. But yes, plan do changes, but at least you will have something concrete which will give more clarity to your code. 

Plan very carefully because too little planning and too much planning can both hurt the quality of your code. Planning for all features at once will be outlawed (waterfall model), where it requires a lot of planning and future vision. Now a days waterfall model is absolute for most of the software. So be agile.

Forethought for unknown

As my experience grew I started thinking of what-if scenarios. I started thinking of case which will never exist or may be not required. This could be a good thing while writing tests but not good when you are writing code for basic requirements of your application. What-ifs cases are often good for edge cases but not for edge features. So, write the code which is needed today to implement only the solution.

Using the first solution I got.

We often gets issues and we start looking for solutions. As soon as I get the solution I run away with it, without thinking of complexity it will add to existing code and potential failures. 

A problem can have multiple solutions, we should analyse and question each solution to find the best among it. Being a programmer, our job is to find the simple and robust solution which maintains the integrity of existing code.

Not quitting on solution.

This is one of the most regular mistakes I did throughout my career. “Sticking to the solution I found, even I identify that, it might not be the best solution”. This happens because of ego involved or “That's my solution and I will go with it” attitude. But programming is not about this attitude, no matter how much hard work you did to find a particular solution, the moment you realize the solution you provided can fail, just throw it away. It's better to fail early and fail often.

Obvious things doesn't need commenting

I used to put comment wherever I think I should write, just to get some attention and make my code look meaningful and bulky :P 

But we can avoid unnecessary comments if the function and variables have a meaningful name. If function and variable name reveals themselves what they do and why they exist we can avoid writing unnecessary comments.

But sometimes we do need to specify comments in that case we should only write about why a particular piece of code is written rather than writing what code is doing.

Considering, if thing is working, it's right.

The common mistake many programmers do. (Specially in service based company). Programmers usually consider if application is working fine, then everything is fine and they don't have to play with it as it may hamper production environment, but this leads to the bigger problem for future. There should be a track of potential bug points and if we know some module which is not well written but working fine for now. Doing this will save you from bigger problems.

No regular code reviews.

Unfortunately when I initially started programming I worked with a team which had never taken code reviews seriously. Soon I have developed a bad attitude towards code review. But, as my experience grown I realised that code review is an opportunity to learn and we should be thankful to the reviewer. Coding is a forever learning process and code review will teach you something which you don't know. There might be situation were your code reviewer is wrong and it will be your turn to teach them something. So this is a collective learning process which all team members do for each other to make better product and a better programmer.

Reluctant towards errors.

If you see a red coloured beautiful message and you dislike it, then you need to change your attitude towards errors. Errors are blessing. One should not be afraid of it. Error indicates progress. Look them as helpers, deal with them and leverage them to make progress. Remembers only ameture programmers are afraid of errors, pro love them.

Obsessed with best practices.

I always see programmers following and teaching best practices, but best practices are bull shit to me. There is no such thing. There can probably be good practices but saying best practices is like its the end of the world, no further good can happen.

Invest time in finding better practices which is more suitable for your case. Don't follow something because it is quoted somewhere, or someone else does the same thing or some one said its a best practice. Question everything, see beyond theories.

Programmers have life too. Have a glass of beer whenever you can :P

Working continuously for hours is a sign of stressed and newbie programmer. Human need rest and this is something we should not compromise on. Many times in our career we are is that zone where we have to do lot for work, but this should not stop you from taking small breaks, if it stops, don't get yourself involved in such projects.

Get off you chair, roam around, watch birds ;) and come back with fresh mind and relaxed eyes.

Happy Coding.