Guy with the money.

Typical perception of the customer is “The guy with the money”.

Most businesses run with this as the central theme of their model.

Lets change one thing..

Customer = “Guy with a problem”

Try it.. Does it change anything for you?

You need to code

As a senior member of the team, its very easy to get into a comfort level and literally stop coding. Have seen many people do that.

Especially, in the kind of software industry we work in.. you’re encouraged to leave coding and get to the so-called ‘Next Level’. That means a raise in salary. That means a higher position. And yes.. that means people work for you.

There used to be a sugar mill in my village. Incidentally, it closed down few years back. It had a similar tradition. Your importance was measured by the number of people working under you. You were the boss to 10 people under you meant that you’ve achieved the greatest feat the village folks have ever achieved. I’ve seen tears in family’s eyes once their son was promoted to that level.

It kind of made sense there. Not completely, but some sense. The kind of work performed did not really need a great deal of creativity or thinking. It was a mundane job. Loading/Unloading a sugarcane truck. Moving the load to the machinery. and so on.. So if a person was very good, he’d be twice as productive as the regular guy. Frankly, it didn’t mean much. Twice as good.

But, you’re in a software industry. A good software engineer is many more times productive than a mediocre one. So if he’s not coding.. its a team’s loss.

One of the reason given is.. you need to get other people to work and help them get to speed.

Frankly, I’ve been long enough in this field to know that it just doesn’t work. You can’t really replace a good software engineer with 5 mediocre ones. The output will only be mediocre. Add the fact that, leading a team is not something that comes naturally to software guys. In fact, on the contrary, good software folks aren’t really preachy types. They prefer showing the stuff in practice.

The speed with which the world is moving, most of the technologies get outdated pretty soon. So there is no real fun in holding on to Dracula and angels. In few years you’d find yourself struggling to keep your job competing with young guns equipped with modern artillery.

One way out of it is office politics. No one loves it. But they don’t have a way out.

And of course, management in no way compares to the fun and excitement that programming brings to everyday life. Isn’t it.

So let go of the status quo. Get back to programming. Show them how its done.


Revisiting is the key.

Thats the difference between good stuff and great ones. The second look. Revisiting your work.

Its the time when I started my career.. and a certain gentleman named Asokan, who was helping us getting started with Programming said:

“Your programs are supposed to function. They need to provide the right output. But, your work as a programmer doesn’t stop with that.”

There’s always a tendency to stop improving things once they’ve started to work. I’ve experienced this on many occasions where we released software as soon as it just started working. Then there is this over-celebrated QA team, that does some quality check and boom.. the customer has it in his hands. And it breaks (well, not always.. practically only 99% of the times) . We find ourselves spending pretty much the same time as we took to write the code, fixing it. Well.. we don’t learn. We follow the same cycle as above. It just has to work. isn’t it?

Well.. the truth is that stuff breaks. In software, it sure breaks like hell. So the wise decision is to be ready for it. Now, its not that we do it on purpose. Sometimes we’re not well informed, not experienced enough, are bounded by self-imposed time constraints. Most of the times.. we just don’t care.

So what can we do?

Give the code a second look.. (once its started working). Its not a crime to write ugly code to get stuff working. Its advised not to get into the habit of clean stuff.. and forget the actual solution. So get it working first. Then pause. Stop for a while. Its working now. Lets improve it a bit.

Clean stuff up.

Proper names. Rethink names of methods and variables.

Write tests if you’ve not written them yet.

Refactor.. Refactor.. Refactor.

Release it.

I know there is an urge to release stuff as soon as they’re ready.  The stuff above doesn’t take that long anyway. And saves lot of time and money later. Try following this cycle.

Next time you estimate a work, dedicate a little time for revisiting your code too..

Hope it helps.