Programmer’s dilemma – Making tough choices

July 20, 2007 By

I’m lucky to be given relatively free reign in my design and coding decisions. Unfortunately, that often means I have to choose between what is right, and what is easy. Here’s a few of them:

Usability – If it’s optional, then don’t make it mandatory
When given the choice of optional fields, a user can and will take the path of least resistance, which is to leave all optional fields as is. I recently developed a web page that retrieves records from a database. All fields are optional. Consequently, everything from the database is retrieved. Which crashed my web server.

Since I was giving a presentation to a customer when this happened, I was just a tad embarrassed. After the presentation, I went back, made a few fields mandatory, with corresponding error messages to avoid Raymond’s feedback form experience. Sometimes, I have to be a user too.

Result oriented – Programmers Don’t Like to Code
I used to tell people I love programming. I’m not so sure now. Then I realised what I really love is solving problems, and that I can express my solution in a program. Even though solving that CSS display bug or optimising that loop gives me joy, it means little to the result-oriented user. So I have to choose practicality sometimes.

CSS Design – Suckerfish Dropdowns
There is this web application I’m maintaining that displays a menu for navigation. The code is unwieldy and makes use of some Javascript copied and pasted without much thought. Hideous to look at and horrendously tedious if I have add a new page. Luckily I found a more elegant dropdown menu solution. It means I have to redesign the navigation element, but it’s worth the effort.

The one you never want to meet – The Brillant [sic] Paula Bean
I have seen my fair share of obnoxious idiots of programmers, and chose patience and understanding instead of exclaiming their ineptitude. But Paula, the experienced Java programmer, raises stupidity to an art. Brillant!

Socialise or be ostracised – In Programming, One Is The Loneliest Number
Not only is programming by yourself lonely, but it’s dangerous to your code, health and social life. It was tough when I first started interacting with people I don’t know but were on my office floor. Don’t have any programmer colleagues? Get help by persuading your manager to hire another competent programmer.

Filed Under: Curiosita Tagged With: , , , ,

Texture maps and the soul of programmers

July 19, 2007 By

Texture mapping is a technique which adds detail to 3 dimensional models. You’ll see it in graphically rendered movies like Toy Story or Shrek, and in games such as Doom and Final Fantasy XII.

Suppose we have two 3D models, a sphere and a fractal-generated terrain.
3D models of sphere and terrain
When we map a texture (which is just an image) such as
Sunset onto the 3D models, we get
3D models with sunset texture

If we change the texture to
Quiet campus and map that onto the 3D models, we get
3D models with quiet campus texture

Fundamentally, the 3D model is the same. The output changes because the texture is changed. It’s the same with programming. Two programmers will produce two different sets of program code, yet produce the same required logic.

The unique coding fingerprint of the programmer becomes the texture that maps onto the required logic (a 3D model). It’s the way the programmer thinks up a solution. It’s the way the programmer writes and organises code. It’s the personal touch that programmer has imparted onto the resulting program. And a skilled programmer can even alter the logic, such as adding checks not specified in requirements, to create a more useful resulting program.

When you’ve done enough programming of your own, reading other programmers’ code gives you insight into their minds. Understand why a piece of code is written the way it is written. There are many web sites providing programming help with sample code, most of them with further explanation of the code. So read through the entire solution, explanation, code and all.

Yes, you really really just need the code to solve your problem. When you’ve solved your problem, read through the code and try viewing the problem as the original programmer would have. You’ll learn even more because you’ll have gained some fraction of wisdom, and be better at creating solutions. You’ll have developed your unique texture, and the distinctive soul of a programmer.

Filed Under: Programming Tagged With: , , , ,

Fractal nature of computer programming

July 18, 2007 By

Have you ever felt like you are doing the same things over and over and over again? Your daily commute, your workday schedule or your programming pattern?

Fractional capacity dimension
MandelbrotFractals possess the distinctive property of self similarity. They look the same when you zoom in and when you zoom out. Take a small part of a fractal, and it looks similar to another part of the fractal.

So how does programming come into the picture?

A simple programming structure
When you write a program, there are typically 3 sections to it:

  • Declare variables
  • Perform logic
  • Obtain a result

In the program, you might write functions to help break up the program into smaller pieces. And in the function code, you

  • Declare variables
  • Perform logic
  • Obtain a result

See any pattern yet? How about programs calling other programs? The caller program declares some variables, calls another program to perform logic, and obtain a result from that callee program.

Self referential
There’s a special type of function whose programming logic involves calling itself again. They are called recursive functions. An example is the function for calculating factorials. The factorial of 6 is the product of all positive integers less than or equal to 6. Or 1*2*3*4*5*6 = 720. The recursive function will be f(n) = n * f(n-1), where f(1) = 1. In code, it looks like

public int Factorial(int x)
{
if (x == 1) return 1;
else return x * Factorial(x - 1);
}

It is programmatically inefficient, but it is concise. (Math is like that sometimes…)

Iterative process of software development
The very cycle of software development is itself self similar. You develop, test, debug, roll out and get feedback from your users. Then based on the feedback, you develop again, test again, debug again, roll out the next version and get more feedback.

Sometimes, it’s even shorter. You write some code for a small part, test it until you’re satisfied with it. Then you write some code for another part and test that until you’re satisfied.

Can you give more programming examples with fractal properties?

Filed Under: Programming Tagged With: , , , ,

5 simple tips to meet project deadlines

July 17, 2007 By

Jared was halfway through developing that unbelievably cool application. The specifications were complete, the customer was pleased with the prototype of his user interface and everyone was doing what they did best. There was just this teensy little problem. Sometime ago, Jared had to go help out that fellow colleague with a programming task. Then there’s the time when his users seemed to conspire against him, and decided to take turns calling him with technical queries throughout the day.

Whatever the reason, Jared made a brief calculation and discovered that he’s starting to run out of time. Then he remembered some tips he read from an incredible web site.

1. Shut down your email
Outlook can be detrimental to your productivity. Having to constantly glance at the bottom right of your monitor to check if a new email came in will sap the focus out of you. Ignore people who call you up and say they’ve sent an email 5 minutes ago, and demands that you explain why you haven’t responded. Try checking once in the morning, once after lunch and one last time an hour before you leave work.

2. Go to the toilet often
It matters little if you have a strong bladder. Just go. Walk slower than usual on the way. Have a good look around the office. Take your time while washing up. Your goal is to get away from the computer, away from the task. Your body gets a little exercise and your mind experiences different sensations. All good impetus for igniting your creativity.

If you really want a good reason to go, just follow the next tip.

3. Drink more water
Your brain is already working at hyperspeed. Your body is aching from holding your special fast and furious typing stance. Drink more water. Eat proper foods. Cooling your brain and taking care of your body is important, because you can think better when you can physically keep up with your mental processes.

4. Wear a scowl
Monarch butterflies advertise their distastefulness with contrasting bright colours. Soldiers deter intruders with barbed wire fences. You can achieve the same effect with people who absolutely must bother you with some insignificant detail. Put on the meanest, angriest and most unforgiving scowl you can muster, and note the dropping number of unwanted guests.

5. Leave on time
This may seem counter-intuitive, but leaving work on time forces you to make the best use of your time while you are in the office. You are a responsible programmer, and so you will make sure that the project is still delivered to the best of your abilities. What you want is maximise your throughput instead of increasing the amount of time spent.

Conclusion
After Jared followed those simple tips, he was able to crank out tons of flawlessly elegant code. And lunch with his colleagues. And leave work on time. And manage to catch up with the latest tech news and blogs of his favourite authors.

As Jared was leaving work on the eve of the project delivery, he saw the unfortunate programmers a few cubicles away, mindlessly and desultorily going about their work, having forgone their lunch and now working overtime. Jared laughed (silently of course, as a form of respect for the others), shook his head and left with jaunty steps.

Filed Under: Work Stuff Tagged With: , ,

5 reasons why you need polymath programmers on your team

July 16, 2007 By

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…

Filed Under: Work Stuff Tagged With: , , ,
« Older Posts
Newer Posts »