A typical month work load

Climber by Bettina Ritter
[image by Bettina Ritter]

I don’t really have a typical work day. It doesn’t mean I have an exciting job. It just means I can’t tell you what I’ll be doing the next day, because I don’t know for sure what I’ll be doing. What I can tell you is what I do in a typical month, generally speaking. There’s a point to all this, and I’ll start with…

From 8:30 am till 6 pm

Those are my work hours. Except Friday. On Fridays, I get to go off at 5:30 pm. My current job title is IT Analyst, changed from Systems Analyst. And if you think that’s vague, you’re right. My job scope is quite varied. Basically, my contractual terms require me to “do whatever the boss tells you to do”.

The current company I’m working for isn’t a software company. I just work in the IT department. What it means is, programming isn’t as highly regarded as I want, as what I read about in those programming blogs and sites. It kinda sucks, but it keeps me fed.

Let me tell you about the tools I use at work. I’m the “online guy”, which means any user interface related development comes to me. I use Visual Studio 2003 (C# and VB.NET) for all the web applications, console programs and a few software tools I create to help me. I also use Visual Studio 2005 for one particular application, with a graphical user interface. It’s too tedious to explain why I use both versions. It’s enough to know that I do.

I also use PowerBuilder for some Windows applications. It’s really, really painful to work with PowerBuilder code. I tell myself it’s the previous programmer’s skill that’s to blame, not the language, but I frequently fail. Tracing and debugging PowerBuilder code takes a lot of work for me. I really hate PowerBuilder… I think this calls for a separate rant article.

I’ve been asked to investigate C and C++ code on Unix machines too. So yes, I understand make files, shell scripts and cron jobs. I even know how to use the vi editor! I used to telnet to the Unix machines with TerraTerm, which is now abandoned for a more secure client application. Can’t remember the name because I rarely use it, because I rarely need to telnet.

Database admin, server admin and LAN admin

Despite the fact that I’m completely ignorant of SQL and databases in my formal education, I’m thrust full force into it at work. I’ve worked with the Oracle, SQL Server and Sybase databases, know most of the nuances between them on SQL syntax, and understand how to use stored procedures. I handle them all.

I am also completely in charge of a few Windows servers and the SQL Server databases running on them. Server maintenance, backup schedule and tapes, security patches, SSL certificates, IIS configuration, server performance.

Then I’ve got to know about the opening of ports for security purposes, who to notify when there are application or server changes. I need to know ping and tracert and ipconfig and other network related stuff.

All of that maintenance and administration is on top of my development work.

I don’t need to connect to Oracle databases now, but I used to do so with TOAD. There’s a limit to the number of licenses, so I wrote my own database connector program. It only does retrieval of data, basically the select statement, but it’s enough for current tasks. The Oracle databases belong to another team, and they’ve only needed me to help out rarely.

I use the Enterprise Manager and Query Analyzer for the SQL Servers. They’re great tools, and they come with the database installation, which is cool. There’s also another tool that has saved me many times. It’s the DTS, Data Transformation Services. I’ve used it to transfer data interchangeably between Oracle, SQL Server, Sybase and get this, Excel. Users take to Excel much better, so I need to use their form of “database”.

Designers, comparers and reflectors

I’m also a web designer. I suck at it, but I’ve been lucky enough to muddle through, and my users and their customers think my user interface looks awesome. I use Paint.NET (and sometimes the inbuilt Windows Paint program) for my image editing tasks. Plus I’ve got some colour tricks up my sleeve.

Some time ago, I had to verify some old code by another programmer. He can’t remember what he changed, and I obviously don’t know what could possibly be changed. I needed help! Fortunately, I found CSDiff. It allows you to compare two files (or even folders) and lists down differences between them. Much better than checking line after line of code by inspection.

And if you do .NET work, you must get the Reflector by Lutz Roeder, which had been taken over by Red Gate Software. It allows you to get back code from compiled .NET DLLs and programs. The result might not be the prettiest code, but with sufficient talent and patience, you can get something out of it.

I’ve used it on my own code and other team members’ code to check for disparity. Sometimes, you forget which version you’ve compiled that code into… Sometimes, it’s for self study, to understand what others have done.

The phone calls. Oh the phone calls.

My phone rings a lot. There are over 10 people in my immediate vicinity. I can tell you that, if you add up all the phone calls all of them ever receive in a month, it would still be less than what I alone receive in that same month.

Remember I told you I’m the “online guy”? That means a lot of users know me, and I don’t know all of them. Since they usually interact with the application interface, any problem is routed to me. Whether it’s data inconsistency, business logic query, application error or failure, all of them come to me. I’m a one-man helpdesk I tell ya.

It was so bad that sometimes, I’ve had to solve and handle user queries for entire days on end. Due to the nature of my work, the start and end of the month are particularly busy for my team. The number of times my phone rings goes through the roof. Maintaining decent phone etiquette starts to be a strain…

Wait, there’s something missing…

Where’s the source control software I’m supposed to be using? Well, I’m the source control. My team is very small in size. Company directives dictate we send work to our offshore colleagues. I think those (typically recent graduate) colleagues have some problems of their own, let alone set up a source control system that works across geographic boundaries.

I’ve not been with development teams at other IT departments, but I think we would totally fail at the Joel Test. Totally.

Despite these circumstances, I still manage to do development work, sometimes with surprising and outstanding results. I believe good task management is crucial to my balancing act. Which brings me to…

Holistic approach to programming

If you’re working at a software company, or on something focused on software and programming, I envy you. I really do. You’d probably get to talk with other programmers on interesting topics. Your work is really appreciated, because it goes to the bottom line.

I might not be programming exclusively, but I get to see the bigger picture. I get to liaise with people from sales, marketing and customer service. I get to talk with upper management and even the actual customers. I get to see the kinds of products and services offered, and how it’s implemented and supported by software.

Programming is kind of … an elite thing. When I was studying C programming in university, I was surprised that many of my fellow students struggled with it. I took to it like a fish in water. After a while, I realised that most people cannot grasp the thinking required in programming, even if they opted to study it themselves.

So I’m going to state this. Many people are not going to understand how great that piece of code you’ve written. Many people think software can make their lives easier, but fail to realise that not everyone can write good software.

This is where all your other skills come in. You have to sell what you’re doing to other people. Convince them that it’s useful, that it’s awesome, that it’s relevant, that what you do and what you propose is important.

Sell your ideas. Market your ideas. Your software is more useful if you see it from a bigger-picture point of view, from other people’s point of view. That requires you to understand other concepts. Concepts that aren’t related to programming at all. And you synthesise them together to make your code better.

And that, is my point.

Well-rounded coding education

Michael Barnathan asked, on my 2008 introductory article, for my thoughts on

I’m [Michael] drawing up plans for a new type of university with a multidisciplinary curriculum that takes advantage of the fusion of principles from different disciplines.

His project’s web site is at http://www.projectpolymath.org/, aiming

to simultaneously acquire breadth and depth of knowledge in time comparable to that required to obtain a traditional single-subject university degree

I think his toughest challenge is actually convincing other people that his university degree offerings are on par with, and even better than, other conventional university degrees.

That said, my eye was caught by

Rather than studying individual majors, students focus on problems and concentrate on their primary approaches to these problems.

It’s problem-centric, so other skills come into play.

Say you’re an artist and you want to paint something. Just being a brilliant creative person isn’t enough. Do you want to use a particular type of brush? Do you know how to mix colours together to get that special hue and tone? Do you care about the quality of your painting canvas?

Joel Spolsky says there should be a degree program where it would

consist of a practical studio requirement developing significant works of software on teams with very experienced teachers, with a sprinkling of liberal arts classes for balance.

where

You might be able to major in Game Development and work on a significant game title, for example, and that’s how you spend most of your time, just like a film student spends a lot of time actually making films and the dance students spend most of their time dancing.

It’s similar to Michael’s idea of education. The other areas of your education enhance your primary focus. Just browse through some game development sites such as GameDev and MadMonkey. You’ll find many articles on game development that have little to do with coding itself, ranging from application of artificial intelligence to the physics in cloth simulation. And here you thought game developers were all about coding skills…

Then there’s Clayton Shier who wrote about the importance of math in computer science courses, of knowing a subject outside of programming.

And Bryan Hughes said that

Coding is actually a small part of the real software engineering package.

on a forum post discussing recognisable traits of a good programmer (look for Nova Dragoon near the end of the post).

Not convinced yet? Jeff Atwood talks about how we should teach computer science, with subjects such as project deployment and source control. Topics that have little to do with coding itself, yet make you a better programmer. There’s something important he mentioned too:

Today’s computer science students should develop software under conditions as close as possible to the real world, or the best available approximation thereof.

It’s something that on hindsight, I should have paid more attention to. In the academic environment,

  • I worked mostly alone (no people skills training for working in teams)
  • Collaboration was frowned upon (they think of it as copying or cheating)
  • Source control was non-existent (still is in my present employment…)
  • Deployment was non-existent (instructor/professor simply compiled your code and ran it)
  • Mostly theoretical or well-defined problems were given (real world problems are much more complicated, usually people-based)

The usual problems fall into topics like finding shortest path with Dijkstra, drawing the Sierpinski Triangle, or manipulating huge matrices for LU decomposition or QR decomposition (killed lots of brain cells too because of the math involved…).

During my university education, there was only 1 semester where I attended a specific course on programming, with C. Half my time was on math. The other half was on solving scientific problems with programming, using the knowledge I had on that one course in that one semester.

When I started working as a programmer, there were lots of programming stuff I needed to do and learn. Like SQL, VB.NET and Javascript. There were also a lot of non-programming stuff. Like writing documentation, talking with users and working with other team members.

Being a good programmer is more than just coding.

And that’s the point. That’s the whole point of this blog. Now, isn’t it time for you to get a well-rounded coding education?

Empty your bladder before watching movie

Toilet sign What does emptying your bladder before watching movies have anything to do with software development? Read on to find out… Before that, I want to tell you a story… and no, it doesn’t start with “Once upon a time”…

The movie afternoon

It was a beautiful Saturday afternoon. I had just taken my lunch and on a whim, decided to watch a movie. Glancing through the available movies, I thought “Bee Movie” seemed interesting. So I got my tickets and went in punctually.

Well, I don’t know how movies are aired in other countries, but in Singapore, there’s a 10 minute segment where commercials and movie trailers are aired before the actual movie is shown. There’s a comfortable seat waiting for me and there’s air conditioning (believe me, in Singapore, low temperatures are a premium), so I usually just go in to the movie theatre early and rest up. Besides, I get to view new movie trailers and sometimes, the commercials are funny or inventive or creative.

Anyway, I was already comfortably slumped in my seat and this lady and her maid towing two children came along. They were sitting in my row, so I shifted slightly to let them pass and they sat down. Since it’s still within that 10 minute segment, the lady asked one of her children that he go to the toilet now. Then she promptly dragged that boy out. Unsurprisingly, I’ve got to move again to let them out.

After a few minutes, they came back, just in time for the movie, and again, I’ve got to move to let them in.

This situation is actually very common. Parents do that. And couples. And large groups of teenagers. Anytime there’s more than one person in the movie watching group, this situation potentially comes up.

These people come in, sit down, and after like 1 minute, decide that they need to go to the toilet, or buy a hot dog, or get a drink. Wouldn’t they have thought of those errands before they come in to the theatre?

There’s only one answer: laziness.

Movie watching is a fairly common activity. You probably did it quite a few times. Is it very difficult to foresee that you want to go to the toilet or buy that hot dog and drink beforehand?

They just had to come in and check that they still have time before the actual movie starts. Then they run out like there’s no tomorrow and do whatever they need to do, and feel like oh, they’ve gotten one thing down pat.

This is not about getting things done. It’s not even a productivity issue. It’s an issue of poor planning. Do you really think coming all the way in to the theatre, sit down and then running out again to do mini errands is efficient?

The software development parallel

Just like there are tasks you can foresee for movie watching, there are tasks you can foresee for software development. Design, thinking, business logic understanding. Preparation. All before writing a single line of code.

You don’t rush in to write a fantastic code base, and then find out that “oh, maybe I should’ve thought of that…” and then rewrite your entire code base to incorporate a business logic that should have already been thought out.

You don’t rush in to write code for web pages, and then find out that “oh, if I generalise this part, it can be used as a template for other web pages as well”.

Design first. Think first. Prepare first. It doesn’t take a lot of time, and you know you should do it. So why don’t you? Laziness. It’s much easier to fall into the trap of coding to feel productive. I’ve sometimes fallen for this trap too, and it’s usually undone a lot of my work.

Just as some movies aren’t bladder friendly, some software projects aren’t design friendly either. These projects are either too complex or too simple. Complexity intimidates your mind, and you feel it’s too much work to think things through. Simplicity fools your mind, and you feel anything more than “I just code this, and code that, and everything’s done” is too much thinking.

Even a short period of designing and planning can do wonders for a software project. It’s saved my skin at least once, because of the short deadline given.

So how do you start your software development projects?

5 reasons why you need polymath programmers on your team

A polymath is someone who is knowledgeable in a wide variety of subjects or fields. And polymath programmers are people whose interests and knowledge cover programming and related subjects. In this age of information overload, let me tell you the 5 reasons why you absolutely must have at least one polymath programmer on your software development team.

1. They are fast learners
Their natural curiosity compels them to find out more about anything that interests them. Fueled by unwavering discipline, they quickly master the basics of a topic, and attain above average to advanced proficiency. Technology moves fast, and your team will benefit if at least one of you can keep up.

2. They are embracers of the unknown
You can only innovate if you are willing to step out of your comfort zone. To stand out means trying something no one’s done before. To create simple software solutions means seeing what cannot be seen. New ideas are born out of the darkness of the unknown. And polymaths are skilled at bringing them to light.

3. They are idea connectors
Their breadth of knowledge enables them to link seemingly disparate ideas and create new ideas. Sir Isaac Newton discovered the law of gravity from a falling apple. Archimedes found a way to calculate the volume of an irregular object when he was bathing in a bathtub. Fresh perspectives are a premium. The answer to your problem can be sitting just a few cubicles away.

4. They are role contortionists
They’re flexible. Polymath programmers know how to program in C. And C#. Probably Javascript too. Some Unix commands. ASP.NET. Connect to a database. Network stuff. Why a float or double is a very bad choice for storing monetary values. Write technical documents. Liaise with users. Answer technical questions from customers.

And when your star database administrator goes on leave, your polymath programmer can smoothly take on the duties. Your genius web developer has a cold and takes the day off? Let your polymath programmer handle that small but business critical graphic change.

This may sound degrading, but it’s true. Polymath programmers act like plug and play components. They can become whatever role you need them to be, whenever you need them to be.

5. They are autonomous agents
Set them an interesting and challenging task, and watch them work at it with little intervention from you. Amassing knowledge from different sources require self discipline and organisational skills. Let them know what you need, and stop bugging them. Your job as a manager is to stop other people from bugging them.

Conclusion
There you have it, the 5 reasons why having polymath programmers on your team can help with your bottom line. So how do you find them? That, my friend, is another story…

Applying squeeze theorem to software project management

It was a sleepy morning. I was tired and hungry, and in the lecture room, listening to the professor on freshman calculus. He was going on and on, and I was struggling to pay attention, and he mentions the squeeze theorem. Also known as the sandwich theorem. That perked my ears. I was just a tad disappointed when there’s no food involved…

One of the uses of the theorem is to prove that something is equal to something else, say x is equal to 5. If you happen to know that A is less than or equal to x, and that x is less than or equal to B, then you have this

What if A is equal to 5, and B is also equal to 5? You get this

When A squeezes upwards, and B squeezes downwards, by the squeeze theorem, x must necessarily be equal to 5!

Ok, the explanation is a little simple compared to the actual theorem. What I want to point out is that this happens when I’m doing a development project. You see, this is what happens

The customer rarely need everything that they state as a requirement. And the project manager rarely know enough about the software development involved to fulfill what is really required. Three scenarios arise out of this.

They never meet

What happens is I will have to do some serious creative thinking to fill up the gap in the understanding between the two. The customer might want a feature that is hard to implement, but an easier alternative can be done to solve their real concern. The user requirement given to me might have ignored certain software limitations or restrictions, and more effort is actually required. So not only do I have to program a listed feature, I have to make it satisfy both parties when they have different views on the feature.

They overlap

This one is tough to handle, because both parties have their own views on how to do it. My challenge is to prise them apart and convince them that my way will be the best solution. And I have to coerce them in a way that it looks like they are the ones who came up with the solution.

They shake hands

This is the situation I strive for. I have enough specifics to plan the coding, yet have some room for creativity, so as to pleasantly surprise both parties. I have the best chance of success when I am actively involved in the project discussion, or that I can provide preliminary analytical input to one or both parties. Thus will I be able to influence the final requirement.

Sometimes, I have little control over the direction of the software project. Sometimes, I can influence the people involved so that goals are met and everybody is happy with the output. Regardless of the result, I’m going to be squeezed.

We should call them improvement reports

My career as a software developer has always been fraught with danger. I’ve been involved in several software projects now, and they all come with their challenges. The development cycle would involve the gathering of user requirement, planning, development and testing. The testing here refers to my testing. Where I work now, they have a whole department just to test the resulting applications of developers.

The gathering of user requirement is fairly simple. A couple of meetings, a few phone calls and some emails usually do the trick. Smiling helps. The simplicity of planning will vary, depending on deadlines (users will always say “as soon as possible”. Smile some more.), complexity of tasks involved and available manpower. For me, development is usually a breeze. I’ve shook my hand in the air (and mentally swore words that cannot be repeated here) whenever I do work with PowerBuilder, but that’s a different story. The internal tests are also easy. Enter a few values, make sure they are calculated and stored in the database correctly, and check that the reports are designed according to the user’s requirement.

The tests done by the dedicated testing department are, well, nerve-wrecking. I’ve had to duplicate the production environment onto the test environment. I’ve had to upload data, download data, change data and massage data from text to Excel and vice versa. I’ve got to refer to the finalised user requirement document to confirm (and defend) the veracity of my code.

There’ll be phone calls and emails to and fro, to confirm this, to help set up that, to ask why that number is supposed to be that number. I’ll probably be working on another project while smiling on the phone and scribbling notes on my already messy desk.

And I haven’t even gotten to the fun part.

At the end of the test period, I will be sent *drum roll*, defect reports. These evil documents contain what the testers had deemed unforgivable deviations from the righteousness of the user requirement document. They would identify the defect in my program, point their righteous fingers at me, and cackle “You made mistake. *dance around* Your program doesn’t work. *dance around some more* It’s all your fault”.

The thing about defect reports is that, well, they contain defects. When I pointed out that testers only focus on generating defect reports, I was faced with blank stares, with the implicit “Of course they look out for defects. That’s what they are supposed to do!”.

What you focus on, expands.

When the appraisal of a tester is determined in part by the number of defect reports the tester produces, what happens? That tester will produce tons of defect reports, on whatever bug or however slight the program misbehaviour was. This skews the perception of the accuracy of the program. Then when the defect report came to me, I would do whatever it took to downplay the report, to deny the existence of the purported defect, uh I mean inconsequential oversight, where I try to skew the perception back into balance.

This sparring of responsibility is damaging to the project, unhelpful to the user, and definitely a waste of the company’s resources. “Are you telling me you spent two hours typing that report about why there should be an ‘s’ for plural, when you could have been giving suggestions on how to improve the user experience?”. “Are you telling me you spent two hours going through every display message in the program code to make sure the ‘s’ was appended correctly, when you could have been implementing better features?”

Instead of keeping track of defects, we should be focusing on improvements. Yes, there are bugs. And yes, I will eliminate them. I also appreciate being told about them. I’m just a programmer. If you are a tester, you’ll be closer to being a user than I’ll ever be. Other than complaining about how lousy my program is, can you add anything to improve the user experience?