Why Technical Track cannot compete with Management Track?

Most software companies that I know have a very limited technical track, but with management track there are a lot more ladders to climb. You can be 28 years old with 5 years of experience and at the top of the technical track in many companies. The only step upwards is to replace the CTO, because that is usually the next technical position after the lead programmer.

It is not very motivating that at the age of 28, your only option to get a “better” position, is to become a manager and do your work in PowerPoint and Excel. I am not saying that being in upper management is an easy job, but being the lead programmer is not an easy job either and people do get better and better in that job. Sometimes the best programmers become managers, because they cannot get further doing technical things.

In some companies being in a technical position is the same thing as being stuck with your career. Some people might think that you are not going anywhere with your career, because you are not getting any promotions. This is the typical MBA way of thinking, which has unfortunately taken over most of the western world. Being really good at what you do is not enough for the society, you have get promotions to be respected.

The funniest title is Director. In many companies Directors are just sales people. How can software companies that develop software, which actually needs technical skills to get done, have 90 per cent of their Directors doing something that has nothing to do with developing the software.

I can understand that sales people need fancy titles, because otherwise customers do not respect them, but at the same time they get bigger salaries and bonuses than programmers can ever get. It’s true that a good sales guy can keep the company running and should get his share of the money, but why does the programmer who also keeps the company running get only 10 per cent more than the programmer who does not do jack-shit.

I actually have the answer right here: Most software companies are run by MBAs and suits. It is as simple as that. The companies where you can actually have a long technical career are run or have been founded by technical people. It isn’t a surprise that the most coveted software companies where founded by technical people.

So programmers, next time you look for a company to work for, check the education for the upper management team. If there is more than two people with an MBA, you’d better find another company to work for.

  • Share/Bookmark

Just Do It

I hate it, when people say that they will put something on their backlog. If it just takes 15 minutes, why the hell can’t they do it during the same day? It’s very hard to work with teams that never do stuff. They will put the thing on their backlog and it’s always going to be in the next sprint. Things get either done immediately or when the team gets tired of being asked about it. I prefer immediately.

I know that they cannot concentrate on their own stuff, if they have to do favors for others all the time. But sometimes something needs to get done urgently and it might be a very small thing. Hell, if someone needs something simple from me, I will always do it during the same day. I don’t want to make other people’s work any harder than it already is. I can surf reddit 15 minutes less. People are genuinely surprised, when I do stuff for them immediately.

It is called common sense, and you can apply it even if you are following some fancy methodology. I am not an expert on Agile or Scrum or Whatever, but I would assume that there is a section, which allows the use of common sense.

I have a tremendous respect for people who can help me with something on the spot without rambling something about their backlog. As a programmer, big part of my job is to communicate with others and make sure that the whole system is running smoothly as possible. It does not make any sense to refer to the backlog every time someone needs something.

Like most programmers I hate interruptions, but I hate it even more, if someone else cannot do their work, because I can’t find 15 minutes to help them. When I am in the zone, I don’t want to get interrupted by anyone, but when that rarely happens, most people have gone home already for the day. I guess you could compare it to having kids. You get stuff done when they are sleeping, but your responsibility is to be there for them when they need you. Software developers are a bunch of preschoolers anyway.

This approach works for me. I do my stuff on time and help others, when they need it. It probably does not work for everyone, but they could still try to squeeze things into their daily schedule instead of the mythical backlog.

Let the flaming commence!

  • Share/Bookmark

How to Avoid Meetings

I just watched a video from Jason Fried talking why people cannot actually work at work. He explains how they try to avoid interruptions at their company, but most people cannot affect the way other people communicate in their office.

Meetings are the biggest interruptions for people without “Manager”, “Director”, or “VP” in their title. Most meetings are useless or take way too much time, still a lot people get dragged into meetings as experts, and they might not actually say anything during the whole meeting.

Try these tricks to avoid meetings.

1. Don’t go

If there are more than three people at the meeting, they probably won’t need you anyway. See, if anyone notices that you are not there. If they really need your opinion and input, they will come pick you up.

When you do this often, people will stop inviting you to meetings, because they know that you won’t show up, unless you are physically dragged to the meeting. You might get the reputation of someone who hates meetings, but don’t we all? You are just expressing your opinion better than others.

2. Ask for a clear agenda when you are invited

If there isn’t a clear agenda for the meeting, you are better of doing something else. Meetings without agenda get easily sidetracked and nothing gets decided.

The agenda should also say what is the actual goal of the meeting. If there is no goal, don’t go. You don’t need to waste your time listening to other people talking about their hopes and dreams.

3. Say you need to get some actual work done

You might be surprised that this actually works. When you say this to people they might actually realize that they shouldn’t just randomly invite people to meetings. If they keep arguing that the meeting is really important, then ask why is it more important than the work you are doing. If they can answer this question, then you might be out of luck.

4. Don’t obey your managers like in the army

Stand up to your manager, and explain how going into a meeting will interrupt you from getting your work done. Most managers should shield their employees from meetings, but if they don’t, you need to voice your opinion. Most people act like whatever the boss says is the law. Wake up! It’s not the army, unless you are, of course, working for the army. Show some backbone and stop acting like a lamb.

5. Make a mockery of meetings

This tactic will not win you any reputation points, but at least it should get you out of boring meetings. Question the usefulness of the meeting in the meeting. Show that you are actually angry that you were invited to waste your time. When someone gets sidetracked, ask if you can leave, because your time is being wasted. This, of course, requires some balls, but balls will get you out of meetings.

You can also bring your laptop with you, and not pay any attention to the actual meeting. When you show people that you have better things to do, e.g., harvest your Facebook farm, you won’t get that many invitations to meetings anymore.

6. Switch your job

This is the last choice, because some companies are so obsessed with meetings that there might be no way to avoid them. Life is too short and precious to spend it in meetings. Find another job from a company that has a better understanding of the true value of meetings. You should ask in the job interview what is the company policy and opinion about meetings.

I don’t think people want to tell their grandchildren that they spent most of the their work-time in meetings. People want to get things done. They feel good about themselves after a work day, when they actually accomplished something. Nobody feels good after a day of meetings.

  • Share/Bookmark

Apple May Have Lost the Mobile Game Business

Apple has admitted that it does not make money with App Store. They make money with the number of devices sold. So the whole purpose of App Store is to sell as many iPhones, iPod Touches, and iPads as possible.

It’s in Apple’s best interest that there are as many good games as possible in the App Store. The mobile gaming industry is still growing strong. Apple has the chance to become the biggest player in the market with App Store, but they need game developers’ support.

Writing games only in C, C++ or Objective-C is, of course, doable, but without the possibility to use scripting languages, it’s not the most convenient way to develop games. Scripting languages are the heart and soul of games these days. The speed of development increases, when the game can be scripted. Frameworks, like Unity3D, are a big reason why there are so many games available in App Store.

Games don’t need support for multitasking from the OS. Games don’t run in the background. Games are always multi-platform; they don’t rely on native UI components. Most game code is game logic, or graphics.

All the reasons that people have given for Apple’s decision to limit programming languages do not affect games. Apple just made developing games a lot harder for iPhone. With the limitations, game developers have to decide, if they want to write games exclusively for App Store. It’s, of course, possible to use the same code base, written for example in C, with other platforms, but it will be a lot harder to develop games that way.

Apple was in a good position to challenge Nintendo as the leader in mobile gaming business, but now that might not happen with Apple’s decision to piss of game developers. We just have to hope that Nokia doesn’t make another pathetic attempt to enter mobile games like it did with the Nokia N-Gage. It will also be interesting to see, if Android starts to gather some momentum in mobile games.

  • Share/Bookmark

RIP Lua Programming on iPhone

It’s over. Steve killed you. We had a good run, but it came to an end sooner than I expected. I was always worried that something like this might happen, but it was still a surprise.

We knew each other only for a couple of months. Those months were the best time of my life. I will always remember the fun we had. I can still remember asking you to create a complete table including the data model with just one line of Lua code. You did all the hard work for me. I never knew what was happening behind the scenes. I bet your autopsy will reveal thousands of lines of ugly Objective-C code, but I don’t care. I will always remember you and your clean and nice Lua interface.

I remember when we did the multi-player code. You just said that I should give you the function that will be called on the other iPhone. It worked beautifully. I could just run code over the network as I did locally. I suspected that you did something against the rules, but I was ignorant and trusted you. The autopsy will probably show me the nasty details how you implemented this.

We also had fun, when we tried to hide you from Steve. We obfuscated the Lua scripts and put them inside the binary. Now, even that wouldn’t do the trick anymore, because running strings command on the binary, reveals that Lua library is inside the binary. I don’t know, if Steve’s minions would actually do this, but I am not going to risk it.

You showed me your true powers with closures and metatables. I was amazed, how you could do so many amazing things, when you seemed so simple. I felt that I was cheating, because programming with you was too easy. Most people think that programming for mobile devices is supposed to be hard, but you proved them wrong in your short visit on this planet.

We had our problems also. Remember, when I tried to use timers that were released. I would use pointers after you thought no one was using them, and cause you a lot problems. We talked about fixing this problem in your next version, but we didn’t even get to start working on that; your end was so sudden.

I hear there’s a new kid in town called Android. From what I understood, he doesn’t kill stuff like Steve. I hope I can resurrect you with Android. It might be dangerous, but I have to try it. I grew so fond of you that I cannot see myself coding in Objective-C or Java. They are just too verbose. You were so simple and elegant, but I guess Steve didn’t like the competition advantage you provided for people like me.

I will always remember you and keep a copy of you in my version control close to my heart. I will leave everything the way it is now. If I try to resurrect you with a new device, I promise I will use Git this time. I will let you have your peace in SVN.

  • Share/Bookmark

12 Problems with Software Estimation

Software estimation is hard, really hard, but still many software companies rely heavily on software estimations. I will present twelve big problems that come with software estimation. The list could easily have 20 or 30 problems, but I limited the list to only twelve problems.

I will not suggest any solutions to these problems yet; that is the topic of another post.

1. It is impossible to estimate the unknown

Every software is unique, and it is impossible to estimate a software accurately, when it’s being done for the first time. Even if the requirements are given, it is really hard to estimate a complex system that is going to be built with the given requirements.

Software can be programmed in so many different ways, and usually design decisions, which are not known during the time of estimation, have a huge impact on the duration of the project.

There are, of course, different kind models and methods to make the estimates more accurate, but even with the perfect method, the estimates are still only guesses, because of all the things that are unknown when the estimates are needed, which is usually before the development starts.

2. Estimates are usually optimistic

Most programmers make optimistic estimations. They either think they are more productive than they actually are, or they do not understand the complexity of the software.

This usually leads to padding. The person who receives estimates from the programmers might multiply the estimates with a magic number just to make the estimates less optimistic. This is also very bad, because everyone doesn’t make optimistic estimations.

3. Estimated time is always used

Most programmers also tend to spend the allocated time on a task. If something is estimated to take two days, the programmer makes sure that it takes two days. Even if he finishes early, he will tune and polish his solution, or just slack off, until the allocated time is spent.

This creates a situation, where nothing gets done faster than the estimates, but some things will take longer than the estimates.

4. Business relies on estimations too heavily

Product launches are scheduled based on estimates. Trade shows are booked based on estimates. In some companies the whole sales and marketing departments rely so heavily on estimations that any kind of delay will cause major problems for the company.

5. A lot of time is spent on things that are not estimated

Even if the estimates are perfect, a lot of time must be spent on things that are not estimated. Programmers need to do some maintenance for older versions, someone gets sick, and new tasks come up during the project.

Many companies add another padding for these things, but it does not make the art of estimation any better. If estimates are based on adding padding, and padding on top of guesses, it does not sound something that can be relied on very much.

6. Estimates are not treated as estimates

People do not understand the meaning of the word estimate. It should be taken literally, but the true meaning of the word is not understood nor is it respected. There shouldn’t be too many plans that rely on the estimates. If things that have estimates depend on other estimated things, it creates a chain reaction of delays, when an estimate cannot be reached.

7. Estimates do not consider productivity variations between programmers

This adds another level of difficulty for estimations. In traditional industry, you know the speed of the average bridge builder, but programmers differ so much in productivity that it is impossible to estimate accurately something when you have two unknown variables: the speed of development, and the required amount of work.

The situation is not that bad when programmers estimate their own work, because they might have a good guess on their own productivity, but when someone else does the estimation for the programmers, they could get equally believable numbers with a Stetson-Harrison method.

8. Changes in requirements do not reflect on estimations

Most projects have changes in requirements through out the project, but the estimations for the whole project are not changed. Every single feature added to project must have an effect on the estimates, otherwise the whole process of estimating things is a complete joke.

9. Truth is told when it’s too late

When programmers make their own estimations, they blindly believe that the estimates can be reached and the software will be finished on time. They won’t accept that their estimates were optimistic, until very late in the project, when telling the truth is already too late.

10. Estimates are not updated when they cannot be reached

When estimates are not reached, other estimates should also be corrected, because missing estimates is usually a sign of optimistic estimation. However, in these situations programmers blindly believe that they can do the rest of the tasks faster to make up for the lost time, when the opposite is usually true.

11. Programmers are blamed when estimates cannot be reached

When the whole success of the company depends on estimates, someone must be blamed when the estimates cannot be reached. Usually the finger is pointed to the people, who could not keep up with the estimates: the programmers. This will create a very unhealthy work environment, and programmers will pad the estimates just to keep their jobs safe.

12. Wrong people do the estimates

Estimates should be made by the programmers themselves. Sometimes team leads can do the estimates for them, but the game is lost, if someone with an MBA does the estimates. Run and don’t look back, if this is happening in your company.

  • Share/Bookmark

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