Articles from March 2010

Communications 101 for programmers

For some reason communications isn’t in the curriculum for most people studying computer science. There might be a general course about communications, but nothing about communications to prepare students for the work that lies ahead in the software industry.

Of course, universities also leave a lot of other things out of the curriculum that are needed in work places, but communication is one of the most important skills for programmers. Most people have worked with a programmer with less than good communication skills, which might reinforce the stereotype that programmers are geeks without social skills. Those programmers who possess enough social skills are often promoted to managers, which makes the rest of the programmers look even worse communicators.

Programming intrigues introverted people, because they have to only communicate with the computer, but once they get a real job, they suddenly have to communicate with people that do not have the same technical capabilities as they do. This creates a problem, because they were hired for their programming skills, but suddenly good social skills are needed to do the job properly. No one told them that programming job would require them to speak to multiple different people in the organization, sometimes even customers. They have the technical skills to do the job, and programming is the one thing they are good at and want to do for a living.

However, it’s not their fault that they were hired to do something that they are good at. Unfortunately, it’s the skills which are not taught in university and cannot be learned from programming books that are crucial to their success in software companies as programmers.

How many programmers brag about their social skills in their résumé?

How many recruiters know how to find programmers with good social skills?

However, all hope is not lost for programmers. They can learn to become better communicators. It’s a skill that can be improved. They have mastered programming languages, so learning a couple of social skills shouldn’t be too difficult. They have to come out of their comfort zone to do this. Some people cannot do that, but most people can do it with small steps and before they realize, they are the best communicators among their peers.

Couple of advice for programmers to push them self out of the comfort zone to become even better programmers as a result of their improved social skills. These simples things can make you a better programmer and enjoy your work more. Communication should not be seen as the necessary evil by programmers, but as the opportunity to get to know and work with different people from different parts of the organization.

1. Demonstrate your work to other people

Talk about your work and show people what you have achieved. It might sound scary, but once you are on a roll, you don’t even realize that you might be giving a presentation, because you are talking about the stuff you have done. It will boost your confidence, when people appreciate your work and ask questions about it.

2. Teach kids something you like to do (in a public place)

It might sound like that this has nothing to do with working in a software company, but you couldn’t be more wrong. Small kids are the most honest people you will find. They don’t talk shit about you behind your back, they will say it to your face. If you can handle that, going to any meeting to talk about anything is child’s play.

I was a basketball coach for 15 years. When I started coaching I was afraid of telling kids what to do. It didn’t take me very long before I was able to yell at the kids in front of their parents :)

3. Learn to talk about technology without sounding like a total geek

Try to explain your non-technical friends (assuming you have them, if not, your WoW buddies) about your work without using any fancy technical terms. When you can do that, then explaining things to marketing and sales people is a lot easier. They might actually understand what you are saying, because you are not throwing computer lingo at them. There will be less miscommunication, if you speak the same language with all the people in your organization.

4. Try to have some fun at work

This might mean different things for different people, but when you are having fun at work, you are connecting with people on a personal level instead of a professional level. It’s a good way to get to know people better, which will make communicating with them about work issues a lot easier. You probably don’t want to be the office clown, but try to find people who share your sense of humor or have same kind of interests outside work.

5. Open your mouth

Unless you are a ventriloquist, you have to open your mouth to say something. Unfortunately, many programmers prefer to keep their mouths shut, when they should share the information they possess. A lot of times things that should have been said, were not, and because of that, projects fail.

Open your mouth, if you don’t like other people’s decisions or suggestions. You might know more to suggest a better solution yourself, but keeping your mouth shut will guarantee that no one will ever see things from your point of view.

People won’t judge you, if you can defend your views. They will actually start to ask you for your opinions, because they know that when you open your mouth, you have something important to say.

  • Share/Bookmark

How to Manage Programmers

This is my view on how programmers (or obnoxious programmers like me) should be managed. Almost all of these things are based on my personal experience, especially learning from the mistakes made by management.

Everybody knows that programmers are probably the hardest people to manage, because the way they work is so different from the norm. The things that are important to them are not usually important to business people and vice versa. Programmers are also delicate little creatures that remember every single mistake managers make.

I have seen numerous cases of mismanagement that it really raises the question whose fault is it? I would say that the finger can almost always be pointed at the upper management and in some organizations at the HR. It’s their job to pick the best managers to manage programmers.

If you are making management decisions in a software company, you have to know your personnel. Many companies are managed by sales and business people, and they have no idea how to manage programmers, because they don’t know what it’s like to be a programmer.

Usually the best companies, for programmers to work in, were founded by programmers and most of the upper management are former programmers themselves. If your upper management consists of business people, I will bet that they will drive most of the programmer crazy with their stupid decisions.

I do realize that the most important goal of every single company is to make money, but at what cost? One buzzword in today’s economical situations is cost cutting. Companies try to save a little money here and there, but they might not realize that cost cutting can actually do more harm than good. Make enough stupid cost cutting decisions, and your best programmers will go work for a company that does not make stupid decisions to save a few cents here and there.

If you are any kind of manager in a software company, follow these simple instructions and you will earn programmers’ respect.

Read Peopleware, again, and again

There shouldn’t be any managers in software companies that haven’t read Peopleware. The basic principles how to manage programmers are timeless. I don’t have a lot respect for managers, if they haven’t read this book. Instead of spending thousands of dollars in so called management training, every single company should buy a copy of this book for every single employee in the company. You simply shouldn’t be allowed to be a manager, unless you have read this book.

Don’t treat programmers like second-class citizens

Example : One company had this big gala to reward all the best sales people and support people. There was free food and drinks, and stupid awards. Pretty much everyone including the managers of programmers were invited, except the programmers themselves. Programmers do not care that much about awards, but I have never seen a programmer turn down free food and drinks.

Don’t treat programmers like they are all the same

There is a huge variance in productivity between programmers, but not necessarily in their salaries. The best sales people make the most money, because it is easy to measure their sales, but companies are reluctant to pay the most productive programmers what they are actually worth.

Of course, measuring programmers’ productivity is really hard, but when someone is a lot more productive than others, it is actually pretty obvious. In what kind of system the most productive programmer, who is clearly at least two times more productive than the other programmers, gets a pay check, which is at most 20 percent bigger?

Don’t try to impress them with your business bullshit

Most programmers don’t care how you run the company, as long as it doesn’t affect their work too much. If you try to push your business lingo down their throat, they will laugh at you. Probably not out loud, but once the programmers get back to their caves, they will rip you apart. Things like this makes you lose all credibility in the eyes of the programmers.

Don’t waste their time

There are so many ways to waste programmers’ time. Basically anything that does not involve development related tasks makes programmers feel like they are wasting their time. Programmers want to spend their days programming, if you don’t let them do this, they will find another job, where they can actually program.

Meetings are the worst time wasters of them all. You should carefully think before inviting programmers to meetings. Is the meeting really worth of disrupting the programmer’s work flow for multiple hours or possibly the whole day? Most programmers should only take part in design meetings and those are not really meetings in the traditional sense; they are more like interactive design sessions.

You, as a manager, should shield programmers from every useless company event that will disrupt their ability to do their job. Programmers will respect the manager who goes the extra mile to let them do their jobs.

Don’t make their work any harder

Their work is already pretty hard. It doesn’t help, if they have to go through bureaucratic loops and holes to be able to do their job. It does not make any sense that they might not have the access to some integral parts of their job, e.g., source code.

If bureaucratic things and environment restrictions prevent programmers from doing their job properly, their productivity will drop, because they are wasting their time doing stuff they don’t want to do.

Don’t treat them like numbers in a spreadsheet

Programmers are not numbers in a spreadsheet. I have seen too many cases of management by Excel. People are moved around in a spreadsheet to match resources and work load. It just doesn’t work like that. Another mandatory book for managers is The Mythical Man-Month.

First of all, programmers cannot be moved to other projects to make the project finish faster, if the project has been going on for a while already. The bigger problem is that programmers usually don’t like to be moved around like pieces in a chess game. I have seen situations, where management have tried to force moving programmers around without asking them, and the results have been less than flattering for the management.

Don’t ignore their opinions

When programmers open their mouth, they usually have something important to say. Bullshitting is something that is more common to sales people than it is to programmers. Programmers are usually quite smart and ignoring their opinions is a recipe for failure. They know what they are talking about. You, as a manager, have to listen to them and let them know that you will value their opinions and show that their opinions truly matter.

If programmers are not listened to, they will not share their opinions anymore and that is not good for anyone. It’s their job to know the ins and outs of technical issues, and ignoring their knowledge is just stupid management. Most programmers don’t want to work for employees that do not value their opinions.

Don’t ignore their efforts

The difference in productivity between programmers can be huge. Even the same programmer can have huge variance in productivity, if his efforts are ignored for too long. Why should anyone bust their ass off and write more quality software than anyone else, if his efforts are completely ignored? He will get the same salary and perks, even if he only works at 25 percent effort, because he’s still getting more stuff done than the rest of the programmers.

Ignore programmers’ efforts long enough, and you will not have any productive programmers to manage. If your company aims at being mediocre, then it’s fine to ignore their efforts, but if your company actually wants to make a difference, do something to acknowledge the achievements of your programmers.

Don’t ignore their requests

Programmers don’t need many things to do their job. A computer with a monitor or two, a proper keyboard, and a mouse are usually enough. If a programmer wants another monitor, give it to him. If he wants a solid-state drive, you better find a way to fit it into the budget. If he wants a couple of books, you should be happy that your programmer wants to learn new things and every company should support that.

Saving money on the things that are essential for the programmer to do his job is brain dead. Programmers don’t spend a lot company’s money and the last place you want to save is on programmers’ tools. Don’t do it, unless you want to alienate your programmers and watch them go to work for someone with proper budget for hardware and software.

Don’t ever lie to them

Be honest. If you make a mistake, admit it. Programmers respect managers, who will admit their mistakes. They have no respect for managers who make bad decisions and then try to put the blame on the programmers. If you are honest, you will show that you are also a human and programmers can relate to you better, otherwise they think you are drinking some vampire blood in your ivory tower.

If you lie to them and they find it out, they will never respect you or listen to you anymore. You lied to them once, why should they believe you ever again? There is no turning back. Be a man and give your position to someone who actually tells the truth to his employees.

Don’t try to fool them with your limited technical knowledge

Most managers are not as technically gifted as the programmers, ergo they are managers. If you belong to this group, do not try to impress the programmers with your technical skills. Good programmers will smell a fake from miles away. Admit that your technical skills are not on the same level, and let them make the decisions about technical issues. You can give your input, but often it is best to keep your mouth shut, unless you are certain that you are the export on the subject.

  • Share/Bookmark

Ten levels of productivity

These ten things help me to get the most productivity out of myself as a programmer, and I would bet that most of these things also apply to almost every single programmer.

If you are my boss, colleague, head of R&D, CTO, head of HR, CEO, or anyone who is working with me or want me to work for you, these 10 things should be in order to maximize my productivity.

I like to think that my productivity decays exponentially every time when one of these things cannot be fulfilled. When three or more of these things are not true, my productivity drops to the level of an average programmer ;)

These are not in any particular order, because they are all really important and productivity cannot be accurately measured.

1. New or interesting technology

Every time I get a chance to work with new or interesting technology, I want to learn as much as possible about the technology as quickly as possible. Like many other developers, learning new things really motivates me. When working with a really interesting technology, programming does not feel like work at all. Simply put, I am really productive, when I don’t feel like that I am working.

Example : Once upon a time I got a chance to port a software for Sony PSP. There was nothing special in the software that was being ported, but the whole concept of making software for Sony PSP was so awesome that my productivity went through the roof.

2. Something to prove

I usually get some extra motivation, if I feel like I have something to prove. This might happen, when someone has underestimated me or I have heard that someone doesn’t think that our team has the necessary skills to get something done. I want to prove people wrong, and rub it in their face, and that gives me a huge boost in productivity.

Example : I wanted to prove that I actually know something about algorithms, so I made it to the TopCoder Open 2008 finals and placed 2nd in the competition.

3. Enough sleep

This is really important, because my brain does not work at full capacity, if I haven’t slept enough. I usually need to sleep at least eight hours to operate at full speed. If I have to get up early and go to some stupid meeting, I know the rest of the day will be a waste, because no matter how many energy drinks I consume, my productivity will not be at a high level.

4. No interruptions

Most people have heard of the flow, but not very many software companies enable programmers to get into the flow. I strongly believe that every programmer should have a room with a door. Most companies are not run by programmers and they have no idea what kind of negative effect noisy working environment has on productivity.

Before any agile zealots start bashing me that there must be constant communication inside the team, I agree that communication is crucial to the success of software projects, but good communication does not mean noisy offices and constant interruptions. There is a way to communicate and still get into the flow.

When I need to get things done, I usually hang around at the office after all the 9 to 5 geezers have gone home. It’s kind of sad that in most companies you have to work different hours to actually be productive.

5. No context switches

Even if the context switch is small, getting back into the flow might be impossible. In many companies most things are urgent and need someone’s immediate attention. This creates a situation where context switches are accepted and even expected, but this destroys the programmer’s productivity.

If you need to get things done, you cannot work on multiple completely different things at the same time and maximize your productivity. Organizations should understand that programming is not a clerical activity and it cannot be continued immediately with the same pace as it had before the context switch.

Meetings are the biggest productivity killers for programmers. One meeting in the morning and one in the afternoon, and I guarantee that most programmers get nothing done on those days. Most meetings, not all, are already a huge waste of time. Too many people get together without a clear agenda and no moderation, and usually nothing good comes out, in addition to killing the productivity.

6. No estimations

This is a bit controversial issue, but I am speaking from my own experience, and I have noticed that most programmers are more productive when there are no estimations for their tasks. This might not apply to everyone, but there is something common in programmers’ mind that slows them down when their tasks have estimates.

One obvious thing is that, when the task takes less time than the estimate, programmer might polish it until the estimated time has been reached. The programmer might also think that he has done something wrong, if he finishes early, and might refactor the code with all kinds of design patterns to make it look more professional.

I am not saying that no one should ever estimate anything, but estimation is always a guessing game at best, and programmers do not move from task to task at full speed when estimates are followed like bible.

7. Free reign

If I have the last word on all the design matters, I will be more productive, because I can’t spend my time complaining and whining about decisions made by others. I have to believe in the decisions I have made, and show that the design supports implementing features at a rapid pace.

This does not mean that I am dictator and never listen to anyone. It only means that I don’t want anyone to step over me and force me to do things I don’t like. If that happens, my productivity might take a dip, because I cannot work at full speed at something I don’t believe in.

It might sound like that I am a little princess and cannot work with other people, but that’s not true. I like to work with other people, as you will learn. All I am saying is that, if I am involved in making design decisions, I will be more productive as a coder.

8. Good available libraries

This is something that some programmers don’t like to do; they like to write everything from scratch themselves. I, on the other hand, like to leverage as much existing technology as possible. However, I don’t spend my days trying to find pieces of code that would do the work for me. Only in situations where it absolutely makes the most sense to use an existing library, I will use it.

I like to have good building blocks available, so I can build my software on top of those. If I have to implement most of the building blocks myself, my productivity won’t be as good, because it will take longer to get the job done.

In some situations the only reasonable way to get the job done, is to write everything from scratch. Fortunately, those situations are not that common anymore, because there is so much good software out there.

My personal favorite at the moment : Lua

9. No unnecessary bureaucracy

Bureaucratic things can get in the way of achieving maximum productivity. Organizations might be in such a bad shape that programmers cannot do their jobs properly, because they have to waste a lot of their time doing things that must be done before they can actually write any code.

Bureaucracy is also a motivation killer, which will easily drop the productivity to zero. If an organization makes programmers jump through loops and holes, they are not going to be very productive.

10. Brilliant coworkers

If you have someone really smart to bounce ideas with, you will come up with solutions that are better and take less time to implement. In the best situation, there is a little bit of competition, and it will push the productivity to higher levels, because not many people want to be to be outperformed by others. There is also a risk, if the competition takes over, the quality might suffer, because the software was done too quickly. Coworkers should actually push each others to write high quality code.

The opposite will result in a loss of productivity. If you have no one to share ideas with or you have to baby-sit other programmers, there is no way that productivity will reach its full potential. The best situation is when there is always someone a bit smarter and more experienced than you, so that you can always learn new things and push yourself to your limits.

  • Share/Bookmark

Why do I use Emacs

About a year ago, when we were having knowledge transfer about one interesting Java component, the dude, who was showing me what the code was doing, suggested that I should use Eclipse instead of Emacs, because it is so much better editor. I can argue with people who claim that Vim is better than Emacs, but I just kept mouth shut this time.

My first contact with Emacs was in University, but I didn’t immediately see the power of Emacs. I got a job as a Windows programmer, and I started using Visual Studio like every Windows programmer. However, I was surrounded by these UNIX gurus, and watching them do their work in Emacs and in a shell, I realized that I could be much more productive, if I learned to use those same tools.

Visual Studio wasn’t that bad. I liked intellisense, but simple text manipulation was not on the same level as it was in Emacs for those gurus. Other Windows developers where also moving towards Emacs and I decided that I will also do that. The first year was though. First I tried to make my Emacs a full-blown IDE with all different views, but at some point I ended up having two editor frames side by side without any extra stuff.

Slowly, but steadily, I started to learn new things about Emacs and then I realized that I will never stop learning new things about it. At the same time I was reading Pragmatic Programmer, which is one of the best books ever. In Pragmatic Programmer there is one advice called : “Use a Single Editor Well”. I decided I will try to learn Emacs as well as possible and forget all the other editors and IDEs, because life is too short to learn two editors well.

I started to pick up really cool stuff for my Emacs. iswitchb-mode was one of my early favorites. It makes switching between open buffers a breeze. I always get a warm feeling, when I see people using their editors or IDEs to switch between open files. A lot of mouse movement or typing is required to get the job done. I do the same thing in Emacs with only a few key presses.

I was kind of missing “go to declaration” from Visual Studio, but when I discovered tags or especially xgtags, my worries were gone and I could easily jump to definitions and declarations without having to move my hand from the keyboard.

I knew about keyboard macros and thought they were really cool, but when I realized what rectangle operations could do, I was blown away. Manipulating text on multiple lines is a feature that should be in every single editor. Most editors nowadays have it, but I never see anyone else using the feature, but then again, I am surrounded by Visual Studio, Eclipse and Vim guys.

I loved iswitchb-mode, but I needed something similar to open new files. Currently I am using file-cache to do this and it’s brilliant. Just like with iswitchb-mode, I can type any part of the file name and open the correct file with only a few key presses. I know that anything.el could do the job of both iswitchb-mode and file-cache, but when I tried it just didn’t seem as smooth as the tools I was already familiar with.

Unfortunately I have to do some C++ coding, and when I discovered flymake, I almost crapped my pants. Now I would never have to fix compiler errors after trying to compile the code. I would fix them on the fly while writing the code. I am, of course, writing this using Emacs and have turned on flyspell-mode, which does the same thing for English language. This feature is, of course, in all the modern word processors and browsers, but not in many editors.

One last feature I would like to mention is yank-pop. When you learn to use, you can pretty much cut any piece of code or text, without having to worry about overwriting the clipboard with something else. This is a really powerful feature and I don’t understand, why it is not everywhere.

Most of these features are available in other editors also, but like I said, Emacs was the editor I decided to learn and I am sticking with it. You can use whatever editor you want, but don’t tell me that editor X is better than Emacs, because it probably isn’t.

I always try to be more productive and the editor plays a big role in this. Fortunately, Emacs allows me to this as good as any other editor or probably even better. Learning to use Emacs is a life long project, but I knew that it was the right choice for me when I made the decision. You might not want to spend so much time with your editor, but when I have my own company, I don’t have to hire you either.

  • Share/Bookmark

My Beef with C++

Bjarne Stroustrup is giving two speeches in Finland this week. Stroustrup’s topic is the trends and future of C++. I have been seriously contemplating protesting his speeches. I have thinking about what kind of signs should I make for the event. (These are all jokes, of course, I am not actually going to do this)

“Thanks Bjarne, for ruining the lives of millions of coders”

“Because of you, Bjarne, I hate my job”

“I hope C++ dies as soon as possible”

“You look almost as ugly as C++”

“What where you using, when C++ was designed?”

“Seriously, was that [C++] the best you could come up with?”

Anyway, I have a serious beef with C++. The more I have to use the more I despise it. Biggest problem is that everyone has their own idea of what C++ should be. So basically one code base could be using 15 different programming languages, except they are all called C++.

Don’t try to sell me the crap that you can write bad code in any language. That is true, but no other language, which I know of, allows you to write so complex stuff in so many different ways that it requires multiple PhDs to understand what is happening. Bad programmers will write bad code in any language, but at least I might understand it. I have been coding C++ (or C with classes) for too long and I am still baffled every time I see templates mixed with operator overloading.

Why do people have the need to do complex things, when a simple solution would do the job? Are they trying to prove their superiority as C++ coders? Maybe they are making themselves irreplaceable, because no one else will understand their code. “He must be good coder, because no else will understand his code”. I think that is bullshit. Good coder is someone who writes code that others can follow easily. I don’t respect people who write so complicated code that my head starts to hurt when I see the code.

There are way too many features in C++. You can get a decent language out of it, if you keep most of the features away. I assume Google is doing a pretty good job with this. They have a pretty clear style guide that dictates what features are allowed and what are not. However, unfortunately everybody has their own idea of what features should be used and what shouldn’t be used.

The hell breaks loose when there is no common agreement what features in C++ are allowed. The result is a complete mess, and this is where my beef with C++ is. It’s like talking the same language, but not understanding what the other guy is saying. The language provides so many different ways of doing things that nobody could ever learn them all. This is C++’s fault and companies’ fault. If there is no agreed way of writing C++, people will write it as they like, and everybody likes to do it a bit differently. No other language makes this possible. C++ is basically a language with as many sub-languages as there are programmers.

  • Share/Bookmark

Master of Blocks Preview

I am getting ready to publish my second application that uses the Lua framework I have created for iPhone. You can check out the Lua source code for the game : here.

The game is a 2 player Tetris clone inspired by the awesome Tetris God video.

I hope to get game finished and submitted to App Store later this week. After that, I will work on the framework to get it open sourced.

  • Share/Bookmark

The Next Big Language will have to wait

Steve Yegge talks about The Next Big Language in his classic blog. The blog is already three years old, and there has not been that many changes in the world of programming languages in recent years.

According to TIOBE, the ten most popular programming languages have stayed the same in the last four years, and no language in the top ten has moved more than two positions in either direction.

In the last 12 moths, Objective-C has jumped from 32. to 12. on the list. There is an obvious reason for this; any software submitted to Apple’s App Store must be written in Objective-C. The popularity of iPhone and iPod touch has made Objective-C main stream language in a year, but it is still not even close to being a big language.

Another site that collects information about the programming language popularity, is lang.pop. Their results are collected from different web sites, and are very similar to TIOBE’s findings.

In his blog, Steve says that the NBL should arrive in 18-24 months. It has already been 37 months and nothing significant has happened. Instead, almost every one of the top 10 programming languages have found their niche and solidified their position in their respective areas. Let’s take a look.

  • Java : Dominating enterprise server business
  • C : Dominating low-level and embedded software
  • C++ : Strong in many different fields, especially games
  • PHP : Unfortunately still really popular on the web
  • Visual Basic and C# : Strong in Windows software
  • Python and Perl : Most popular scripting languages and doing well on the web
  • Javascript : The language for web applications

If we consider C, C++ and Java to be the biggest languages, I don’t see any language currently in the top 20 taking their place. C++ might be the one that could lose the most popularity in the near future, because it is not really strong in any particular area, except maybe gaming, but I don’t see a single language taking its place. Most probably, different languages get some parts of its popularity in different areas.

PHP is a mess, Visual Basic and C# are too Windows oriented, Python is too slow, Perl is Perl, Javascript is stuck to its niche, Ruby is slow as hell. Honestly from a technical point of view, Go could be the next big language. It would require some serious brainwashing from Google. If Google starts shipping computers and mobile phones to people all over the world, and the only language you can use to develop software for those platforms is Go, then it might become the Next Big Language.

Usually when a new programming language had gained some popularity, it’s because there was a new opportunity and a big company behind it. The current market is taken. At the moment, I don’t see any holes where a new language could go and overtake the segment, because the other languages could not fill the hole.

It will require new type of hardware or a completely new need for software before the Next Big Language will have a chance to appear from nowhere. There must be huge financial support for the language, because companies will not want to waste their money experimenting with new and unproven programming languages.

The Next Big Language must be advanced, but I don’t think that it is the deciding factor. I would like that the Next Big Language would do everything that Steve has listed, but I think we will have to settle for less. There will be languages that will fulfill all Steve’s requirements for NBL, but the actual NBL won’t probably be chosen on technical merits.

People talk a lot about high-level languages like Haskell, Erlang, and OCaml, but not very many people actually get to write code for living in those languages. Young people need to decide what languages they need to learn to get a job in programming, and unfortunately, they start learning Java and PHP to get a job. I can’t blame them that most programming positions require Java, PHP, C# or Visual Basic skills.

I hope that before I retire I could see a new language rise and take over most of the programming world. Currently there are too many programming languages that I don’t want to write for living. I would like to see C++, Java, PHP, and Visual Basic disappear from this planet and be replaced by something awesome, but I don’t know, if that will happen in the next 30 years. Let’s hope Steve is right, and the Next Big Language is right around the corner.

  • Share/Bookmark

Better looking code has fewer bugs in it

The most important thing for me about code is its looks. I might sound crazy, but bad looking code makes me cringe. Whitespace is the single biggest factor defining the looks for the code. Variable naming is also important, but as long as it is consistent, it doesn’t matter nearly as much as whitespace usage.

There is actually a reason why I rave about the importance of looks in code. Better looking code has fewer bugs. Let me say it again with all caps: BETTER LOOKING CODE HAS FEWER BUGS.

There are many reasons for it and I will try to prove it to the best of my abilities.

Whitespace should be used to separate things. By writing


it takes a while to see what is actually happening in the code. If the whole thing is written without any whitespace, it is hard to know where a variable begins or ends. By writing

    variable_x + variable_y - variable_z * variable_y

it is immediately clear what is happening. It takes less time for the brain to visually gather all the needed information from the line above. All of this was achieved by pressing the biggest key on the keyboard six times. The space key is so huge that I don’t understand, why many programmers have hard time finding it.

Because the second example is more clear, the bugs in it are more obvious. Let’s say that instead of using a ‘-’, there should be a ‘+’. This might go unnoticed in the first example, but the operators are more visible in the second one, and the problem can be caught more easily.

Whitespace doesn’t only limit to space characters; newlines are also really important. Code should be structured by modules, functions and blocks of code inside the function. If the function is one big block of code without any newlines, it is impossible to quickly get a clear picture of what is happening in the function. The return key is also quite big, but still many programmers are able to avoid touching it for long periods of time. Some programmers claim that if code has too many empty lines, enough information cannot fit one screen. I have one advice for you: Buy a bigger monitor. If you still want more lines, turn it 90 degrees. Now you have so many lines visible that even the most verbose Java code with plenty of empty lines manages to provide a lot information in your Eclipse.

Example 1:

    //comment hidden here so you won't see it

Example 2:

    another_line_of_longer_coder = xyz;

    for (i = 0; i < 12; i++)

    long_calculation = 1262 + 3222 - 3423 ^ 32424 >> 1233 ? 1 : 0;

    // comment not hidden anymore

Who can honestly say that the first example is better than the second one in any aspect?

Not only does elegant code make the bugs more visible when looking at the code, but bugs are also more visible when looking somewhere else. There have been many situations where I have found bugs in code, when doing something completely else. Beautiful code leaves an imprint in my mind, and sometimes I know exactly where the bug is. I cannot do that with ugly code. I cannot bend my mind around ugly code and walk through it with my eyes closed.

Too long lines and too long functions also prevent me from seeing the code in my head. If the function is short enough, you know everything that is happening in the function and in what order, but if the function is too long, you get lost and don’t know what is happening in the function without looking at it. Long lines, which I already complained in another blog, also hide bugs and prevent me from visualizing the code in my head.

There is never a good reason to write bad looking code or deviate from coding standards. It takes only about 2% more time to write proper code, but most the time should already be spent on thinking. If the 2% is too big for you, maybe you should switch your editor to a proper one or get a new profession, because I don’t want to work with people, who cannot follow simple agreements.

  • Share/Bookmark

Office Space Out 2

Don’t feel like working. Feel like spacing out? What to surf the web or sleep without interruptions at the office?

Never has slacking off been so easy and fun at the same time!

The new and improved version of Office Space Out, will enable you to configure your program to play keyboard and mouse sounds, like you were actually using them for real. Your boss will never know the truth and he will probably think that you are the hardest working person in the company.

There are three prerecorded types of keyboard sounds available. If none of them match your keyboard, you can record your own.

You can configure how much fast typing, slow typing, mouse usage, and silence should be in one loop. You can configure the sounds to match your work task.

Price: 0.79€/$0.99

View in App Store

Lua source code

Office Space Out 2

  • Share/Bookmark

What happened in Vegas '08

I am sorry to disappoint you, dear reader, but nothing that you might expect, happened. I was there to attend a programming competition. The venue was the Mirage Hotel and I was there to take part in TopCoder Open ’08 Marathon Match finals. But first, let’s see how I actually got there.

I started participating in TopCoder competitions in the summer of 2007. The first two competitions were a learning experience for me, but in the third competition I was doing pretty well, but my final submission had a bug in it, which dropped me from sixth place to 79. I was really pissed, and started testing my solutions more thoroughly after that.

2008 TopCoder Open started in February and had three qualification rounds, before the 12 best competitors would meet in Las Vegas for the final round. 617 competitors participated in round 1. 300 best made it to the second round, and I actually had the best solution in the first round. 100 best from the second round made it to the third round, and I placed 20. in the second. Third round was probably the most grueling two weeks of my life. My usual day looked like this: 8 hours or work, 2 hours of basketball practice and 8 hours of coding at home. I didn’t sleep much, but in the end, I placed 5. in the third round and made it to Las Vegas.

TopCoder paid for my trip to Las Vegas, and they also paid the five nights I stayed at the Mirage. My competition was on the first day. It started at 9 am and lasted for 8 hours. In the beginning, I was struggling a bit, but after lunch I started rolling and went to the top of the leader board. However, I didn’t stay there for very long, because Psyho overtook me by a clear margin, and I kind of new that I had given everything that I had. Fortunately nobody else scored more points that I did, so I placed second in the competition.

The prize money for second place was $5000, which was kind of nice considering that I got a completely free trip to Las Vegas to do some coding. It was a really nice reward for months of hard work in the qualification rounds.

I spent the rest of the week mostly at the hotel watching NBA playoffs, because I got a fever and a cold. It was bit disappointing to go all the way to Las Vegas and become ill, but at least I saved some money that I probably would have spent at the famous Las Vegas activities.

Last year I didn’t quite make it to Las Vegas; I was 21. in the final qualification round and 10 best made it to Las Vegas, but this year I will go for it again. I haven’t participated in that many TopCoder competitions anymore, because they are really time-consuming, especially when working normal hours.

I am currently ranked #3 in the Marathon Match competitions, but there are some competitors that are not currently ranked, because they have not participated in any competitions for a while. I bet that all the top competitors will come out from hiding for TopCoder Open 2010, and the final qualification round will drain everything out of everyone, who tries to make it to Las Vegas.

Source code for my solution

Problem description (Must be a TopCoder member to see the description)

  • Share/Bookmark