Ian On The Red Dot

Work has become a strange affair. I’m extending my notice period so that I can be around when the project (that has consumed my life for the better part of the last 10 months) goes live. It didn’t make sense to leave my company and our clients at the last hurdle. It feels wrong. I’m not sure whether it’s because I’ve been conditioned by the Singapore education system to be a good worker that I feel this obligation.

I don’t expect anything to go wrong but as they say, production is the last testing environment.

Yet while I’m physically at work, my mind isn’t there. My mind is busy making plans, being terrified and excited with what is to come.

Bad habits have started being entrenched. In truth, I was learning them early last year after the first project went live. They had been creeping in along with the growing dissatisfaction about the state of affairs with my employment situation. My learning of bad habits did get some respite when I was able to occupy myself with other matters like setting up a continuous integration environment (using Hudson) for the second project.

Now, I find it hard to muster any sort of pride when trying to complete the remaining tasks before I officially handover my duties and my system. The tasks just seem too mundane and serve as a reminder of why I chose to leave. I’m just waiting for time to pass, the days to run down, until I leave.

Bad habits, are, bad. (You probably read that and went, ‘No Shit Sherlock’)

I know the bad habits will come back to haunt me once I focus on ship building full time. It is hard to get an engine going when it has been left idle for too long. I don’t need another reminder of the pain I felt when I entered university after my National Service .

And so, I’m writing this post to remind myself that work, while done under a situation I have grown slightly dissatisfied with, is still work that must be done well, even if I’m going to, borrowing a NS phrase, fuck off after two more months. And if I have to test the waters, I’m going to do it.

Take the Powerpoint presentation I prepared as part of the training for the operations staff. The template I was originally bequeathed was the usual boring, stodgy corporate affair, the kind where you had multiple nested bullet points on 1 slide. The embarrassing sibling of presentations found at Note & Point. The first time I prepared the training material last year, I conformed to the template. This year, I tried to push the boundaries, searching for Creative Commons licensed photos from Flickr to pepper throughout the presentation when trying to emphasize some point. I hope it worked.

I did enjoy the reaction of the trainees when they saw something different on the screen.

Just because it has always been that way doesn’t mean it needs to continue that way.

And so, with the two months left, I’m going to do two things the client didn’t ask and didn’t pay for because that’s what need to be done:

1. Proper way to track database migrations.
2. Easy way to prepare release notes.

In Search Of A Better Model For IT Companies In Singapore.

Up Or Out:

Bring lots of new employees in, team them up with mentors, provide real work to do, and give them a choice: either get lots of great experience and get out, or work hard for a higher-up position. Whenever you hear someone aspire to “make partner”, he’s undoubtedly working at a firm that’s adopted this model.

The benefits don’t stop there. A company with a culture of quitting does not have ex-employees; they have alumni. This is far more than a semantic distinction. An alumni relationship is positive; something that people can take pride in; and one that keeps the door open for further opportunities on both ends. Let’s face it; we’re already curious about our former workplaces and try to keep up through former coworkers. It’d be that much easier if the company facilitated this in some manner.

The alumni relationship also helps with the flow of new personnel. While ex-employees are be hesitant to recommend the company they “broke up” with, alumni will champion it to colleagues in need of similar experience. Furthermore, there’s no sense of defeat when an alumni returns – armed with experiences from other organizations – for another tenure.

The ‘Cravath System‘:

The belief was that someone who had worked anywhere else had learned bad habits already.

My first job after graduation was at a MNC based in India with an office in Singapore. The Indian programmers I worked with were incredibly intelligent people. They were also very cheap compared to their abilities and the value they were contributing to the company (*).

(*) This isn’t a subjective statement. There is a methodology to determine the costs of projects, both for the company and the clients.

Because they were cheap, whenever there were projects, the solution was to throw X number of programmers to build the cathedral. From scratch. Again. The only way a project benefited from previous projects was through the experience and knowledge of the programmers who had worked on other projects.

There was rarely, actually never, a common pool of source code (i.e. libraries) that was created by one project, subsequently refined, and used in future projects. There wasn’t even a process to ensure that this was done.

If source code was ever shared between projects, it was because a programmer on the current project had done something similar in a previous project, and copied the code over. Ctrl C, Ctrl V.

Now, from a company’s perspective, if the programmers weren’t paid cheaply, the company wouldn’t want the programmers to keep rewriting similar code. The companies would institute a policy to ensure that after each project, a review was done to see what code could be reused for future projects, extract that code, refine it, and create libraries that can be shared. These libraries of code would subsequently be refined as they were used by other projects.

Like my boss would say – more bang for the buck.

Fool me once, shame on you; fool me twice, shame on me.

When an employee first joins a company, I would like to believe he or she would make the best effort to do his or her best. I’ve seen that in my current company. People really give their all with the best attitude.

Then they wait and see. What will management do. What sort of bonuses are given. What sort of pay increment is given. What sort of promotions are awarded. Are promises kept?

After the first year, people start asking the questions:
1. Does the company value me?
2. Do I really want to stay in this company?
3. Where can I get a pay that is equal to my value?

If promises are not kept, expectations not met, then these questions start getting asked by more people in increasing intensity. Sometimes people give the company a grace period. One year is too short a time to judge. Maybe this year was an aberration due to the economic crisis. Let’s wait one more year.

Once they get fooled or disappointed for the second year, you can bet a lot of people will start planning to jump ship. So here is the impact of constantly leading your employees on that you will take care of them.

1. Lots of time is wasted on them planning to jump ship instead of working for the company.
2. Negative energy is generated. People become less productive.
3. People also become less creative. Meaning – they aren’t going to be generating long term intellectual capital for the company if they know they are going to jump ship soon. They just do their job and go home. Nothing more. Nothing less.
4. New recruits look at the old birds leaving and go, fine, it seems the company doesn’t take care of its own. Maybe they weren’t good enough. I am. I’ll give the company a grace period. But on the safe side, I won’t invest 110% into this company. Just do my work. Do it well. And try to stand out with my excellent work. But I won’t build intellectual capital. I won’t give the company something they can use when I’m not around.

The truth is this. Treat people like monkeys. Or give them the impression they are going to be treated like monkeys, and you’re never get your company to grow well sustainably. There is only that much you can scale by adding disposable manpower.

Giving employees reason(s) to build that intellectual capital for you and the confidence that you will share the profits of a well-performing company are the best ways to increase your company’s staff’s productivity.

Some other notes
1. Talk about cognitive dissonance. There was a friend whose boss announced to the staff during a company meeting that there was no pay increment because business was bad. At the end of the meeting, he invited all the staff for a party on his new yacht.

2. I hate it when companies try to extract maximum value from employees NOW promising to reward them in the future.

The AWS (i.e. Annual Wage Supplement) was a way to add a variable component to the employee’s wage. It is actually quite brilliant. The company reduces monthly fixed cost. The company gets the benefits NOW. without really being forced to pay LATER. They only promise to pay later. The bad companies find a thousand reasons not to give AWS. Wait. My opinion is most non-government related and non-MNCs do find at least 1 reason not to give AWS (or if they do give, a miserable amount).

I work to create systems for people who look down on the very people (my colleagues and me) who create the systems that allow them to make more money faster just by moving money here and there because they have more money than us.

WTF.

It is like making boots for people to stamp on our faces.

Who cares about productivity?

Bosses aren’t saying – raise your productivity and we will pay you more. They are saying, raise your productivity, if not, we will hire someone cheaper or someone who can do more for the same pay.

Minister Lim Swee Say:

“Job is the best welfare, full employment is the best protection for workers and productivity gain is the best driver for wage increase in the future…”

The statistics show that Singapore’s GDP has grown.
The statistics also show that Singapore’s income inequality has also grown.

So, what makes the minister think that if a worker increases his or her productivity, the company will pay the worker more? What makes the minister think that those with wealth will be more willing to share the wealth in the future?

There seems to be too conflicting messages here:

1. Raise productivity or lose your job because we can replace you with a foreigner.
2. Raise productivity so your value increases and the company will pay you more.

We know companies are doing 1. We also know they are NOT doing 2.

So telling workers to increase productivity is of no consequence in helping them if companies aren’t willing to share more of the pie. It is also of no consequence if foreign workers who are willing to increase ‘productivity’ (do more for less, do more for same by putting in more hours or taking less pay) are also allowed to be employed.

Bosses’ idea of productivity = Amount Of Work / Pay
Worker’s idea of productivity = Amount Of Work / Time

Different formulas. Think about this for a moment.

The problem is that the ministers are asking workers to bite the bullet first. Prove your worth and trust us (companies, government) to take care of you.

The correct way would be to get companies to pay more. Once you have to pay more for a worker, you as the owner of a company have many more incentives to put more systems and processes in place to get more from the worker. Or you could just overwork him in terms of hours. So the government would need to manage that abuse of overworking.

And it is not just about the company being forced to get their workers to be more productivity, for SME’s, for the want of a better word, it buys a lot more loyalty.

And what does loyalty get you?

More on that tomorrow.

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(
name=”planetype”,
discriminatorType=DiscriminatorType.STRING
)
@DiscriminatorValue(”Plane”)
public class Plane { … }

@Entity
@DiscriminatorValue(”A320″)
public class A320 extends Plane { … }

is different from

@MappedSuperclass
public class BaseEntity {
@Basic
@Temporal(TemporalType.TIMESTAMP)
public Date getLastUpdate() { … }
public String getLastUpdater() { … }
…
}

@Entity class Order extends BaseEntity {
@Id public Integer getId() { … }
…
}

This has no meaning.

Being a monkey doing manual work just because that’s the way it has always been. Because the company, despite being around for so long has not bitten the bullet and dedicated resources to building the tools it needs to use so regularly.

Because labor is elastic, the tools are not focused on. Quote aggressively for projects and throw more and cheap labor onto the problem.

It feels like we are becoming like the Indian company I used to work for.

This is soulless.

Of course, we (i.e. the staff) could dedicate our own time outside of office hours to create the tools we need.

But why should we?

You learn a lot just by studying the work they do and asking questions.

&

Some quick thoughts – there is a difference between:

1. Go and work on something and let me see.
2. Go and work on something and let’s discuss how we can make things better.
3. Go and work on something and then I’ll contribute by saying whatever you do is shit AND then I’ll finally give my ideas.

I hate ‘blue-dress-red-dress’ working relationships. You know, the kind you get with some girlfriends. She will hold up a red dress and a blue dress and ask you which one she should wear. Either she has a clue or doesn’t. If she does, your opinion doesn’t matter. If she doesn’t, she will only make up her mind after you give your answer, and she will always choose the other dress.

If you are stuck in a team like that, time to stick a gun in your mouth. And maybe pull the trigger.

I understand the principle behind the separation of the development and testing teams – every programmer suffers from momentary lapses of judgement brought on by the ‘it is my baby’ feeling towards their code which makes them perform less rigorous testing.

It would not be presumptuous to assume a testing team incentivized to find bugs in an application will perform more rigorous testing and act as a perfect foil to the development team.

In theory.

In practice, if the testing team does not have the knowledge of the business requirements and application, if the team does not have the skill-set to track what’s going on with an application, if they have to rely on the development team to interpret results then the whole point of separation is lost.

The testing team needs to be able to operate independently from the development team when determining why a test case fails.

It is also not sufficient for the testing team to say a test case has failed. The testing team needs to be able to ascertain the point in the business process where the error occurred which is possible with logging and information from the database.

If they can never understand the ‘why’ then the chances of false positives and false negatives increase.

And seriously, Google is your friend. In case you forgot how to use Google, click this link.