20 Signs of a Bad Software Company for a Programmer

If you see more than a few of these things happening at your company, it is probably not the greatest place for a programmer to work for.

1. Everyone codes on Windows

2. No-one uses Emacs or Vim

3. Managers don’t understand why someone needs a big monitor

4. Hardware is outdated

5. If looking at code makes you want to vomit

6. You are paid for your presence not for your productivity

7. Multiple manual steps are required to build the software

8. Agile zealots roam freely

9. Company does not provide good benefits, because they actually cost money for the company

10. Innovation is almost impossible because of rigorous processes

11. The office is empty after 5 p.m.

12. People complain, if you play video games during the day, but not if you smoke cigarettes

13. Every team has to reinvent the wheel, because sharing code inside the company is very difficult

14. Estimates are not treated as estimates

15. Multiple meetings every week

16. Every class has a one or more patterns in its name

17. CEO has never programmed

18. You don’t have to write any code in the job interview

19. Using one tool for everything

20. Not realizing that people are the most important resource for the company

How many are true at your company?

0: You are one of the lucky ones
1-3: Not bad, you could be doing a lot worse
4-6: As long as they pay you enough, you can take it
7-9: Maybe you should start updating your resume
10-12: Life is too short to work there
13-16: You want scream your lungs out
17-20: Run and don’t look back!

  • Share/Bookmark

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

Master of Blocks

My last game written in Lua got accepted to App Store. Get it before Apple removes it :)

Destroy a mortal or try to survive the wrath of God as long as possible. Classic game turned into an awesome two player game.

Are you the Master of Blocks against AI opponent and your friends. See who can master the blocks.

When you play with a friend using Bluetooth, the other player plays God and the other one plays mortal.

Price: 1.59€/$1.99

View in App Store

  • 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