Introduction - part 2/2

In the last post, I’ve described problems with teamwork and work organization. Let’s continue that subject for a bit more and then get to more technical matters. 

Work organization

Temporary solution is good enough as long as nobody complains.

In theory it shouldn’t happen. In practice, often happens that temporary workaround becomes final solution, especially when a deadline comes around. If there’s no other way, or you’re creating prototype or demo – sure, no problem. Temporary, quick solution is good enough but I dare you, mark it somehow (i.e. // TODO: temporary fix/solution) ! Do some forementioned code review after a while for heaven’s sake! It’s not uncommon that other programmer or even you will add a new functionality which will rely on temporary workaround, which won’t work in given case. That will cause creating a workaround to push forward that will raise the technological debt. So verily I say unto you, the sooner this temporary hack will be fixed the better.

You can read more about it here:

Resting on our laurels.

So you think you can code? Let’s assume – yes. People around you think of you as a team member, not only “the member”? OK. Do you respect you QA as thyself? Great! And you think that’s enough? Au contraire, my brother and sister. IT is rapidly growing – probably it’s the most dynamic business in the world. If something is rushing forward that much, you cannot stay in place. No other business may truly say, that If you’ll stop, you’ll definitely stay behind. And it’s going to hurt. Badly. So, when you do your bare minimum at work, it’s time to pull your socks up and start the real work – new solutions, new programming languages, design patterns, technologies, engines, frameworks, standards, etc. Every kind under the sun!

I’m not saying that from now till the day you die, you’ll have to work or study without any break. No, no, no – watch an episode of your favorite soap opera or 50+ images of cookies that look like cats on boredpanda. But let it be one episode and not half of the season! Change proportions of your time-wasting activities and guilty pleasure into something more mind-expanding. It may be a podcast, there is a ton of great lectures from IT conferences. Maybe you’ll find some inspiration or a solution of a mind-boggling problem?

You can read more about it in these posts:

Programming technique

I’ll optimise code from the start, because there will be no time for fixes later.

“Premature optimization is the root of all evil” – words said by Donald Knuth are still true nowadays. You will need to fix your code anyway. It’s just going to happen. There is no perfect code. Refraining from premature optimization does not mean you can be sloppy! It doesn’t mean that you cannot speed up in any way as well! If you’re not coding for yourself (which happens in most commercial products), code needs to stay clear, readable and flexible enough, to be developed later. That’s it.

You can read more about it here:

Code is unreadable? But it works? Leave it alone, then.

Rarely only one person works on given part of a code. That’s why variable names like a, b, a1, etc. which won’t say anything about their purpose, won’t help anybody. And when you’ll start working again with that code after some time.. without documentation… comments… well… Good luck. You don’t know how to write good, readable code? Take a look how current project is developed. If it’s a big company, it is likely to have coding guidelines. Those might turn out to be priceless or even mandatory to follow. Even if you do have your own coding style, it won’t hurt to analyse other people’s approach. It may actually be a good supplement in parts, where your solution is flawed.

You can read more about it in these articles:–net-8118

Comments in code are for lamers.

Of course, since we want to write code that doesn’t require comments a thisspecialflagtodosomethingawesome variable name is crystal clear and convenient to write. Especially when function has a couple of thousands of lines and is heavily nested. There is no possibility for you to make a mistake. Code commenting doesn’t hurt! You don’t have to describe every effective code line separately. In most cases a method will consist of code blocks, which have some responsibility. If it’s not big enough to be factored out, leave a comment, so that a person, which will work on that code later won’t have to wonder “what the hell author was thinking here !?” Tom Van Vleck (founder of MIT Computer Science and Artificial Intelligence Laboratory, computer security specialist), once said:

Don’t be like Tom…

You can read more about it in these articles:

KISS is just a band name.

Believe me, instead of one method of several thousands of lines; it’s better to have a couple of methods thousand lines each. And still it’s a bit too much. Keep It Simple, Stupid – the beauty lies in simplicity. Seriously, eliminating bugs with less granulated code is much easier in the long run.

If you’ve found big chunks of code with single responsibility factor it out into separate method. That single responsibility of a method or class should be your rule of thumb in code design. That allows you to give that portion of code a proper, compact name that doesn’t need much of a comment since it’s self-explanatory… You see where I’m getting with this, don’t you?

You can read more about it in these articles:

Those nested ifs in loops and methods are so picturesque…

Maybe they are pretty, but the moment you make mistake and remove wrong code block indicator (e.g. bracket in C++) you’ll be pulling your hair out during debugging. I’ve personally learned that nesting should be avoided as much as possible. Of course to reasonable extent.

For example – in the beginning of a method, instead of writing:

We can do it like that:

That will allow us to check all initial conditions for method to succeed.

In loops, for example, instead of:

We can do it like that:

Of course this approach isn’t right in all the cases. We should be extra careful here about creating appropriate conditions.

I won’t waste time on refactoring.

That sentence is actually equal to “I will waste my time to fix this whole mess after writing sloppy code.” If the methods are too long – extract the code. If you’re repeating yourself – adapt and make a common method to be used in different places. It’d be easier to debug later, to read through, to optimize. You’ve found a place to fix during wandering through the source files? Do it, if it won’t take you the whole day, of course. It’s really worth it!

Some time ago, I was working in a project, where around 40% of the code has been removed and it still worked! Not only doing it did not take a lot of time in comparison to the whole project, but the code was faster and much more readable. Aside from practical reasons, removing code is so much fun…

You can read more about it in these articles:

Memory leaks? Why bother? It’s just couple of bytes…

What is a memory leak? To put it in a simple way, it’s a state, where after creation of given object and working on it, you don’t delete it but you loose all references to that object, so it gets out of your control. If that object is referenced by other objects memory management mechanisms (e.g. Garbage Collector) won’t remove it. Even shorter: we clog our memory with objects we can’t control. Often operating system after closing entire application will have to cleanup after us.

This state is really harmful, because many mistakes of that kind may overflow operational memory and produce faulty or unexpected behavior. Currently many IDE’s have memory control tools to analyze code and detect possible memory leaks. What is more, in many of those cases we may be able to find an actual line in code which caused given problem. A simple solution to that problem is just cleaning up after yourself. In C++, for example, every pointer with new initialization should have its own delete. New standards, however, point out that it’s better to use std::unique_ptr which will deallocate the object pointed during leaving given scope (method, block or life of an object).

You can read more about it in these articles:

Code will be done, when I’ll be satisfied with it.

No, you won’t. If you’re satisfied with your code, you’re doing it wrong. The cornerstone is doing your task according to the spec and within a given time period. If you did, leave it. You can improve the code indefinitely but in most cases the time you can spend on given task is limited. Besides, the more time you’ll spend on testing, the better. Finding perfect balance between doing the actual coding and other stuff like testing, formatting, improvements, etc. needs some experience. That is why it’s better to set up your own deadline. You have to get the work done in a month? Try to do it in 2-3 weeks. Even if you mess up or change of specification will happen somewhere along the way, you’ll have 25% of extra time for damage control.

You can read more about it in these articles:


As you can see, a lot of bad things happened and if I went deeper, I could’ve find twice as much. The sooner you’ll find your own mistakes and eliminate them the better. Nothing probably will change overnight but at least try to get a hold of those bad habits and start to work on them. By doing that you’ll become better programmers, employees and colleagues. It’s better to learn on someone else’s mistakes than on your own. So: a bit of discipline, planning, empathy and cleaning after yourself will make your life easier. People around you shouldn’t complain either. I hope that seeing mistakes above you’ll be able to avoid them in the future.


Graphics used in this article are properties of their respective owners:–programming-humor-o-reilly.jpg

Leave a Reply

Your email address will not be published. Required fields are marked *