The nature of programming and Frankenstein programming

date: Sep 4th, 2011

A programmer feels like an inventor, programmers are kind of architects, we love being self directors and get motivated by results rather than the process itself. Every time we are coding any piece of program, algorithm, procedure, function, this contains part of ourselves; we are kind of leaving our soul on it, our spirit on it, regardless how good/bad it was done. Later on when we look at all these things we did, we feel like that belongs to us even when we don't feel proud of them.

So because we know all these consequences (the weight of feeling what was done by us) we always try to do things better and better, and better means more efficient, smarter, reusable and mainly maintainable. This is when the experience comes over, before hand, the things we do normally satisfy all the possible execution scenarios (somehow we know them), that's what we love, have fully control of the fluid course, being masters of our own bubbles.

Over a decade dealing with programmers I haven't met anyone mediocre. We always try to do things well done and the thing we hate the most is when it is not actually possible. The main big problem comes when there are changes that need to be done in our programs for satisfying requirements that were not thought once everything has began; sometimes our programs fail after changes and it is in those moments where we ask ourselves. Are we not good developers because our programs are not flexible enough? Sorry, this question was made wrong; Are we bad developers because our vision is not good enough to predict the future?

So many times we have to forget about the things that we have invented, just throw them away, these things were made for satisfying requirements completely different of how the final requirements look like at the end. This normally happens when the prototyping process and final development are mixed in one single step. Unfortunately sometimes it is really hard for us say no. The word "no" is a synonymous of "incompetence" for some developers and what they still haven't learned is that this is a straight path to something everybody hates a lot, frustration. Even money does not compensate how it does feel; at the end of the day what we are wasting is our soul, aren't we?

There is something very weird when programmers are coding, it is all about feelings and doing their job professionally, we all know these two things shouldn't be mixed but unfortunately most of the times they are, why? Cleary because we are not gluing bricks, we are inventors. Regardless which kind of language we are using; there are very strong reasons to explain why our code sometimes looks "beautiful", or sometimes it looks very messy, or simply very academic which some people can follow and feel indentified with.

It looks beautiful when "uniqueness" and performance, both together reach the limit after satisfying all what it was meant to be for, there is nothing more rewarding than that, it is a shame we rarely have the chance of sharing this emotion with someone else, it is a shame we normally later on realize it is not as unique as we thought because of people's feedback or simply because it was already invented by someone else but, still it is the charm of the whole thing I guess. Academic code is always following predefined patterns in order to be compatible with someone else, sometimes we have to code all together in the same style, following always a common convention, especially when we are coding in co-op mode (within a bunch of programmers). But hey, is it not really frustrating when we lose control of our source code? It is sad; it is frustrating when all comments in our code don't match with what the code does in execution after changes, changes and changes. It is crazy when we need to debug something and we can't even have access to the output log of our program because it looks extremely messy with no sense. Funny thing, many people always end up doing things like Log.fatal("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa "+myvar);

I think that the only way to avoid all this happen is identifying beforehand if what we're doing is prototyping or coding a final development, separate these two things is normally very tricky, especially if we don't know how to say no, normally people can't visualize how complex things are (they don't have to) but at some point we need to say no otherwise what we will be always doing is, prototyping.

Remember, it is as important as the whole development process itself, allocating proper time for tidying up, for commenting, for packaging... a program is done not when it has been delivered with no bugs but when it is fully commented and ready to be reused. I know it is a boring task but it is extremely necessary if you want to keep your mood always up, your brain healthily.

date: 14 Dec 2012 - 00:27:24, published by Dimitar
Keep on coding dude. Just wanted to say hi and admirations from Bulgaria. And also nice paper here.