web developer & system programmer

coder . cl

ramblings and thoughts on programming...


programming traps and pitfalls

published: 16-10-2011 / updated: 16-10-2011
posted in: development, programming, rants, tips
by Daniel Molina Wegener

Programming is a hard activity, it requires concentration, and certain programming paradigms, like functional programming and well done object oriented programming, requires a good knowledge and basis in other areas, like theoretical computing. You cannot do well structured object oriented programming or functional programming without a good basis on algorithms. There is no such technology that allows you to create great programs without that knowledge, and you cannot be good creating software design without that knowledge.

Certainly, one of the worst enemies of programmers is getting stuck on a programming problem. But there are other well known enemies, like bad specifications and badly taken requirements, all of them can make a programmer to work twice, mainly once the programmer thinks that the problem is solved. Any of those errors are very de-motivational on any circumstances.

Personally, to boost my productivity as programmer, I do a previous analysis before I start my programming tasks for my workday. You can distinguish two types of tasks, those where you know exactly how to solve some problem, and those tasks where you don’t know how to solve the problem. There are also two subgroups, those tasks that are easy to complete once you know how to solve them, and those tasks that are not easy to complete, even if you know the solution or not.

Problem Levels

Problem Levels

To get things done, I use a very simple schedule. I treat all problems that are on the group B (known-hard) first, then I solve all problems that are on the group C (unkonwn-easy), both tasks in the morning. Then I solve all problems on the group B (known-easy) after the lunch, and finally I do not solve those problems on the group D (unknown-hard), instead I do the required research to complete those tasks the next day, very early with a fresh mind, so they become group B (known-hard) or A (known-easy) problems.

Problem Schedule

Problem Schedule

So, all unknown-hard problems, will become known-hard the next day. Leaving the last hours of the workday to do research and doing theoretical solutions instead of coding, will bring you a more relaxed day ending, allowing you to progressively leave the coding activity. I think that is bad to be the complete day programming, you must do other activities, like reading. Organising problems according to its complexity brings me more productivity than doing problems sequentially.

If you are able to organize your schedule with the proper sequence, probably you will reach your better performance, because you will be using the proper energy to solve those problems, rather than doing tasks in sequential order, you will assign the priority according to its difficulty and the hour of the day to meet the best concentration regarding the problem to solve.


No coments yet.

post a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>