Lessons From My First Job

Ah, I finally found an interesting topic to write about – at least to me. I was going to write something about the best company I ever worked for (not google, unfortunately). However, upon further inspection of the themes I really wanted to talk about, I decided that it's really all about my first professional experience as an employee.

Everybody have different experiences on the first job. For some, it's the realization that money is REALLY hard to earn. For others, it's the realization that they can finally do their thing and stop worrying about irrelevant school works. And there are those unfortunate ones who will realize that this 'work' thing isn't so exciting after all – at least not much worth of all those years in school...

So I suppose I was lucky. I found a job that, just like the cliché being bandied about, I would probably pay others just so I can do it. Looking back now, I find that I appreciate it even more because it got me off the right foot as far as the business of software engineering goes. In fact, from what I hear around, some of the things I learned there are not even regular practices here in my country to this day – or maybe I just got to know some bad companies later. Here's the list...

Use version control software. One of the first things I had to learn during my first week is the venerable CVS. All projects in our small company gets enrolled there. Some of those who postpone enrolling their projects (mostly waiting until it is at least a running prototype) suffer through the consequences of lost sources (by being overwritten, or hard disk crashes). Before working there, I didn't really use any version control, floppy disk space are so precious back then. (The entry level hard drive with the largest capacity was 650MB – some blank CDs today have more than that!)

When I eventually moved to other jobs, I've been so used to having vcs around that I have a hard time forcing myself NOT to use one. I even use it for my personal projects. I really can't figure out why anyone would NOT use one. I've been in some companies doing enterprise size software without the benefit of vcs. All the developers' lives are hell – especially when some sources goes missing during project turnovers from departing employees (which are frequent).

Have a tool developer. In my experience, software shops tend to function a lot more efficiently if there is someone around who can make tools to automate repetitive, or rote processes. It's even better if everyone have this mindset because not only will everyone make tools for everyone else's use, they will also be on the lookout for things that CAN be converted into a tool. My first job is chock full of people who think this way, and it's infectious. Another side effect of the can-it-be-a-tool mentality is that it also drives people towards the real problems, the one that needs creative human solutions, and thus avoid expending precious efforts.

One good example of this is when we need to find a network packet problem (windows 95 was new then, DOS is still king, and so are packet drivers) that's causing malfunctions in one of our software. We needed something to intercept the packets and log them for later viewing so we can trace the exchanges. Since existing tools aren't available, we made one ourselves. We also enabled it to work across ethernet and arcnet so we wouldn't have to do fancy riggings to feed one onto another just for snooping purposes.

Another instance is when those Delphi (1.0-3.0) UI generic controls just weren't working for everyone. Since they're all generic controls, there's not much specialization provided. If you wanted, say, an edit box to enter quantity information, you pretty much have to check the input, AND range check the resulting string just to be sure. And this is only one specialization problem! So we decided to make tools and libraries to remove those troublesome issues. It's a lot of upfront work, but it paid off. All the other UI work from then on was simply a matter of dropping components and changing their properties.

Have coding and library standards. This maybe obvious, but there are still shops who ignore doing this. Maybe they fear reining in the programmers' creative juices? Or maybe some other nebulous reason exists, but what do we know? As far as I'm concerned, this is necessary to promote smooth operations all around. You don't want anyone to argue about placement of braces, or the capitalizations of variable names, or things of that nature. You also don't want programmer A to change programmer B's code to conform to his own coding style. A global coding standards will simply force both of them to format code the same way.

As for code libraries, this helps a lot in knowing what a fresh developer's machine needs. It's no good having only joe developer have the ftp libraries, and the know-how to install it, if you actually need it companywide. Just make it a standard and be done with it.

Create fixes not patches. Nowadays, patches are ubiquitous. Though I'm not saying that patches are bad, mind you. What I think have gone out of control is that it's better to find why something is not working and fix the source of the problem. Too often, problems are just worked around and tagged with some TODO for later investigation. The only problem is, later never comes and the problem gets laid at the foot of whoever the next maintainer is. One reason for the proliferation of this mindset is the way software folks are scheduled to work, which is the next lesson.

People DO have optimum work hours. Because we have been so used to working 9-5, we tend to ignore this one. Good thing my first job has a flexible schedule. We were just required to be around the office between 10am-2pm, and even that can be waived if you pulled an all-nighter the day before. The boss just recognizes the fact that there are hours where you're so focused you can plow through several days' worth of work – and this may not be within the 9-5 cycle at all.

In fact, let's admit to ignoring this optimum hours thing. For other tasks that we want to do, we 'know' when we're ready physically, mentally, or even psychologically. We sometimes put off reading that book because we're not in the proper mindset yet. We sometimes reschedule writing that blog because we just don't have the spirit at the moment. In fact, any non-time-sensitive activity (and maybe some of those that are) are simply moved to a more convenient time simply because we're just not ready for it, yet. Sometimes, when we see this in others, we automatically think they're just procrastinating, and yet we do it ourselves. But in the long run, this is just more efficient. Ever witnessed a team forced to do their thing at fixed hours? They tend to 'procrastinate' a lot more trying to find their groove before they can actually be productive.

The IT field moves too fast to be complacent. This is a biggie. In fact, there are several implications once you accept the truth in this statement. For one, you simply cannot stop learning. Some of the things you are using and/or doing can become obsolete even before you're done! And when I say obsolete, it's not always the same cause, nor the same effect. It might become moot because another product comes out doing exactly whe you set out to do. It might also become useless because the technology wasn't accepted (example: there was this POS standardization initiative from the company in Redmond, it was swept under a rug due to low acceptance from POS manufacturers). Whatever the reason, the people must at least be updated in order to react accordingly.

Another effect of this, which is lost on most HR types, is that it doesn't matter where you studied, or when you finished studying. What matters is your willingness to learn continuously, maybe even doing so on the fly. In order to have a productive, long-term career, you must be able to evolve all the time. At one of my previous job, I met this one guy who was hired because he's an expert in language X (specifying which language might pinpoint the actual person) and refused to evolve even when all the products end up being written in language Y. Would you want a teammate who will not adapt at all?

Flatter organizationas are more efficient. It's not that I have something againts large companies with multi-level hierarchies. It's just that I found that the flatter the organization is, the less bureaucracies there are, and the more personally invested the workers are at what they do. The fact that everyone knows who to report to, and that departments seldom have overlapping concerns are just icing on the cake. If you're one of the flat organizations, try to keep it that way. And avoid promoting technical people to management positions just to give them a career ladder of some sorts. Doing this over time will lead to ever increasing hierarchies – you'll have department heads, vice department heads, assistant department heads – and you'll no longer be as efficient a before. If technical people want career progression of sorts, there are other, more acceptable solutions. In my first job, we had a rather uncreative, but viable solution – we just get promoted to higher levels in the same position (i.e., engineer I, engineer II, engineer III...).

(Disclaimer: Note that I didn't say NOT to promote technical folks to management. I said to not do it for the sake of giving them a career ladder. Some technical people can be good management material and can be promoted as such. Just be certain that they want the promotion in the first place, and you can stand to lose one of your better technical resource to management)