Programmers: far more than typists

typing

I recently read a post by Jeff Atwood where he states that programmers are typists first and programmers second. This is something that I could never agree with.

I am a Software Developer. I should be part of the whole development cycle. That means, among other things, I design, write, test and maintain my own and other people’s code. The initial coding is possibly not more than 20% of the full cycle. In fact, according to this post by Peter Hallam, it is no more than 5%! How then can we possibly be typists first and programmers second?

A programmer is not a cog in the machine; he invents the cogs and arranges them in the machine. He is not a factory element; he is the one building the factory. Sure, there are different roles and requirements, but this is what developing software is all about.

Yes, I agree that typing is one of the fundamental requirements for programming, but a programmer is so much more.

To agree with Jeff, if you do not know how to type, it is not really that hard to learn. Get yourself a typing tutor and invest some time in practicing. However, the day programmers become nothing more than mere typists is the day I leave IT.

Who’s the Boss?

[Article related not just to the IT industry, but most companies in general]

The Big Boss

In some companies there seem to be continual strive between employees, managers, and even clients.  Everyone has got their own opinion.  To a certain degree they are all right, but only one can have the last say.

If your company makes the client your boss, then you will always be trailing behind in the wake of complaints, non-important things and sometimes other badly thought out ideas.

You want to lead to market!

Note that I am not saying that the client should be ignored.  He is after all responsible for the cash flow.  A policy stating that “the client is always right” is absolutely required, but always in context.  Value the client’s opinion.  Treat them as if they are the be all and end all.  Just do not forget who the real “big boss” is behind the scenes.

Strive for excellence

The purpose of any respectable company is to make the life of the client better and easier, even if that means changing the way the client does things.

Usually this type of change will not be welcomed by management, due to time, money and other restraints, but if the product your company has to offer really is that great then it is worth at least trying to pursue an ideal.  Now if something is not broken, do not fix it, but a lot of times the reason for keeping things the same is because that is the way it has been done for so many years and everybody is just too lazy to touch the topic.

A lot of times people only care about what they gain today.  They do not always have the foresight to realise that a bit of effort will in fact make life more efficient, meaning more time and money in their pockets over the long run.

IF NOT

If you compromise on quality, eventually things are going to break.  The client is going to blame the product.  The company could try to defend itself with words like “but you asked for it to be like this”, but that will just anger the client.  Whatever comes from this, the company is getting bad publicity.  Since the company has to continue the “client is always right” mentality they now have to promise a fix which will just end up as a bad “hack” and make matters worse for future upgrades.

Example

Client: “Do it like this.”
Certain employees striving for excellence: “This is not a good idea because…”
Manager: “Be quiet.  You are not paid to think about this, just make it work!”

YOU ARE CHOPPING OFF THEIR HANDS!!!

So stop blaming or laying down the employees if things go bad in the future.  You can throw all your fancy management processes out of the window.

You brought it upon yourself.

Why developers cannot be managed.

[Article related to the IT industry]

Certain IT companies have policies where they require the employees to log their work time, sometimes even on an hourly basis. Why is it that almost every developer I have ever met is utterly frustrated by this? Regardless of these strict processes, why is it that most IT deadlines are still late?

These and similar questions have been bothering me for a while, and I could never quite place my finger on it, until recently. I am going to attempt to give you a very stereotypical view of what I believe the typical developer/architect/engineer is like. I would just like to mention that this article is not purely from introspection, I used external sources as guidelines.

Your (stereo)typical developer

1. Value their own opinion over that of others.

At first this might sound like a weakness, but with regard to their work and self-critical nature, it can in fact be their strength. This also result in them not being so much impressed by authority, rather by that which is useful.

2. What works over what is right.

They don’t care that much about political correctness. Here is an example. The company has a policy that every alien USB device must be scanned before it can be inserted into a computer. It is, however, Saturday morning, and the logistics team is not around. Since the work needs to get done, the developer is not going to think twice about inserting it.

This might sound rather negative at first, but as it is the developers who will eventually be responsible for creating a better wheel for tomorrow, there are times when they need to break away and follow their own minds and instincts.

3. Abstract, not concrete

This abstract manner might be to blame for the late deadlines. They are so much focused on new possibilities that the existing ones are not always turned into reality. They often leap between ideas and possibilities.

Your typical manager (those not from a programming background) are usually far more concrete and structured. They love making lists and follow it to the dot. In their minds it not only makes perfect sense to log work records on an hourly basis, it also give them a sense of fulfilment. They believe in the evidence of the facts of here and now rather than wasting their time on new ideas and endless possibilities.

As you can see it is clear why managers became managers and developers became developers. Sadly, a lot of times the managers want to force their ways down onto those around them, but just because it works for them does not mean it is going to work for everyone else.

Note that I am not saying that developers are not goal driven. Some are more and some are less, and usually it is a good idea to combine them accordingly to make up for each other’s weaknesses.

Solution

They need freedom and room to operate. Do not tie them down with needless administrative processes; leave it for the people who are good at it. As a result you will notice that overtime will no longer be a problem. This is because the important thing to these types of people is long uninterrupted sessions of quality work. Most of them even have an insatiable hunger to accomplish the goals they set their minds to.

Of course, you need to make sure that they are passionate and faced with enough challenges. A lot of them have got short attention spans and are thus easily distracted once bored. As I also mentioned in a previous article, it is very important to recognise the gems from the shiny stones, otherwise the above suggestion will instead become an easily exploitable loophole.

Your company’s most value resource

[Article related to the IT industry]

What is an IT company’s most valuable resource?

There are a few vitally important resources to the world of Information Technology (IT). One of the major runner-ups is marketing. What people see when they work with a computer program is usually only the tip of the iceberg, so they need big-mouthed talkers to make people realise that this specific product is going to fulfil all their needs.

In my opinion, the most valuable resource is, in fact, the developers. Not just the product the company is selling, not just the code these developers are writing, but the actual people doing the job. The reason why I say these human resources are more important than anything else, even the product, is because these human resources makes the product what it is, whether that means designing a wonderful system, or destroying it into an unmanageable pile of rubbish.

Yes, with enough resources you could make almost anything “work”, but unless you have some smart thinkers involved it will not leave much for efficient future business. I have personally seen what terrible state a product can become if left in the hands of the wrong people.

Managers, please listen to the opinion of your well-prised developers!

You might argue that I am only making this point because I am myself a developer in the IT industry, but I am saying this because I have seen the efficiency of well thought out products, but also the huge amount of time and other resources (including money) wasted on products that were just done to make it work, without the least bit of though on what the future might hold. This is why good managers are also critical, a topic which I will touch in a moment.

So, how does it work?

Here is a very simple example to compare against. When constructing a house, one would make use of architects, builders and inspectors. The architects, having the most experience, set forth a detailed design on what the building should look like. The next step is to gather the builders, who are the dumb manual labourers usually contracted out to a manager/director. There are a lot of builders, but only a few architects. Inspectors should be involved with both of these.

In the world of IT things are a little different. The people responsible for the design are usually also responsible for writing the code for their designs. More advanced developers get assigned to more advanced problems, but even the less experienced ones are required to at least think about what they do before they do it. Rephrasing, developers are almost always in charge of getting their own development done.

This is, once again, why good managers are needed. They need to differentiate between real diamonds and shiny stones. Unfortunately, it would seem like 80% of the developers are simply vocational; they only care about doing just enough to get things to work so that they can go home and enjoy the weekend. (I am not motivating working overtime, I am just pointing out how little care and pride a lot of people take in their jobs).

With this I am not saying that one should avoid these people, but a manager should be aware of this when assigning projects and responsibilities, and also realise when to quit defending and demand better. Sometimes it is even possible that these people’s true talent really lies somewhere else altogether. Here it usually helps to have at least one project manager with some actual coding experience.

What about the inspectors?

At this point most would think that the QC (or QA; test) team fulfil the inspector’s job, but I beg to differ! Due to the almost hidden nature of development I do not think it is even possible to properly inspect all the elements of a program. The job of QC is to run tests on the products, both functional and performance driven, in order to find possible problems.

To me this process is like running over a mountain with a hand drill trying to find underground caves. More advanced tests use bigger drills. With well written programs you have a better idea where to start drilling. The point is that people forget that product testing only show the presence of bugs, not their absence.

Another reason why the product testing phase falls short is that usually the less experienced people are dumped in the test team, and since deadlines are usually late, the amount of time used for testing is far less than actually required.

Leverage

The basic principle of leverage is to use 5% of a hundred people’s effort rather than 100% of one person’s effort. It sounds very idyllic, but the problem is that you first need to judge the state of the target market.

It might be partially applied, but in the world of IT I cannot see this principle working as much as intended. Like they say, one chef makes a feast, but two makes a mess. (I forgot the exact wording). Due to the nature of computer software, every developer of a specific product needs to follow a proper set of guidelines to prevent every one heading off in their own direction with their own little ideas. As a part these ideas might be good, but as whole it has the potential of disrupting the harmony of a lot of other things.

Personally, I would rather be surrounded by a small group of experts than an army of fools.

One final remark on managers

Even though I currently think developers are more important than managers, as a smart group of developers can function without a manager, I do hope I did not give the impression that managers are less important than what they truly are.

Although they do not create or design the product, they have the authority to make things happen, combined with the “eagle’s eye” view to evaluate current situations while still keeping the past and future in mind. They use this to steer the group in the right direction, assuming their ideas does not get overruled by a higher authority. A lot of times it is also their job to recruit new or lay down existing developers, or to give counter offers and kill fires when things get out of hands.

It is so easy to get tangled up into all the problems and drawbacks of the moment. Good managers should be able place themselves above the situation, sit back, relax, and think.