Working has different goals from working out

The last time I spoke about swimming laps in relation to software development, it was to discuss Brooks' Law. I've had a couple more insights recently, though those are more about work in general.

See, I'd gotten a bit smug about how little effort it took me to swim from Point A to Point B. I was averaging one stroke for every three that others were doing, but travelling at the same speed, or better. Then I took a closer look at the metrics I was using.

Getting smug in the water.

That's when I knew I'd lost sight of the big picture, and allowed work philosophy to cloud my judgement. Here I was, patting myself on the back for becoming a more efficient swimmer when it was never even the goal.

Working

Larry Wall summed it up elegantly when he said that laziness was a virtue in programmers. He could have meant it as a joke, but philosophically, this cuts to the heart of the matter. Work for the sake of work is not admirable, at least not in the corporate context. You are not paid to work. You are paid to get work done. You are paid to add value through your work. If you think otherwise, you're basically a (admittedly very industrious, good on ya mate) buffalo in the shape of a human being.

Beast of burden.

Thus it stands to reason that at work, you want to produce the most output for the least amount of effort. Both current and future effort. Which is why software developers try to write good code - not because writing clean elegant code is a virtue unto itself, but because code that conforms to those standards minimizes the amount of effort needed to maintain it down the road.

Therefore because I was travelling through water at the same speed as others while putting in less effort, I thought I was nailing it. I forgot that I was working out, not working.

Working out

What are the metrics for working out? You want to put on more muscle. You want to lose weight. You want better cardio-vascular conditioning.

Unless being an athlete is literally your job, you're not cycling primarily because you want to be a better cyclist, or swimming because you want to be a more efficient swimmer. No, when you're working out, your goals are very different. Burn calories. Get your heart rate up. When working out, doing more work is precisely the goal.

Now, at my age, putting on more muscle isn't a goal. Decades of staring at my abs have made the prospect less than interesting. Losing weight isn't that big a deal; as long as I can see my toes when standing, I'm good.

Heart health.

But cardio-vascular conditioning? Oh, absolutely. That's what I was swimming for in the first place. And because I was going at the same speed I've been doing for years, without putting in much effort, my heart rate wasn't going up at all. Which effectively meant that while I was in the water congratulating myself for having become better at swimming, I was pretty much wasting my time.

Conclusion

Swimming faster was never the goal. Swimming more efficiently was never the goal. Putting in more physical effort was always the goal. Not only did I take my eyes off the prize, I forgot what it looked like.

Mission Swimpossible?
T___T

Three Great Virtues (Part 3/3)

Hubris is probably the most misunderstood of all the programmer virtues. But you're in luck - I'm Teochew, and if anyone understands arrogance, it's us.

The Virtue of the Great Programmer - Hubris

Developer ego is more commonplace than you'd expect. Any developer with some experience under his belt is going to be rather opinionated about how things should be done. Programming is about bending the will of a machine to our own, and making it churn out the results we want. It is about creating usable objects out of virtually nothing. It is about dealing in languages many people are too intimidated by to even attempt. And getting paid for it. Why wouldn't we be arrogant? Consider the quote below from Robert C Martin, in his book The Clean Coder.

"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance."

Robert C Martin seems to be a bit of an extremist in his views, and more than a little verbose. But in this case, he hit home for me right there.

But... but, but.

Why be modest when
you're that good?

In order for hubris to be a virtue, it has to work for you. It has to help you in your development. It has to drive you.

It has to spur you on to create products that people can only praise. Any code attributed to your name has to achieve great things. That arrogance manifests itself as pride in your work.

It has to inspire you to go boldly where no one has gone before. "A hundred programmers have failed? Well, I'll be the hundred and first." "Better men have tried and failed? Bitch, there ain't no better man." In fact, I believe that it is this same audacity to try something different, something unthinkable, that separates great programmers like Bill Gates (daring to succeed despite dropping out of university? The sheer gall.) and Linus "I'm always right" Torvalds from the rest.

How not to be Arrogant

Some forms of arrogance manifest as a belief that one has already learned all that is worth learning, and there is no need to keep exploring. That's arrogant, sure... it's also foolish. Dangerously so. Technology is constantly evolving. As I type this, a few million hackers around the world have figured out newer and more insidious ways to breach web security. New frameworks are threatening to render the ones you use obsolete. New features in your favorite programming language are causing older features to be deprecated. Going down this path is a sure route to ruin. There's a place for arrogance. Not so for complacency.

Refusal to listen to feedback is another dangerous manifestation of arrogance. Sure, not all feedback is created equal. If, for example, you haven't written a line of code your entire misbegotten life and have the audacity to comment on my professionalism, be prepared to be very firmly put in your place. On the other hand, working too close to the product can lead to blind spots, and sometimes - just sometimes - fresh perspectives are helpful even if they are from laypeople. There's also a tendency for a developer's ego to lead to defensiveness - such as refusing to concede an argument or admit that someone else knows more than you do. That is insecurity. If you're confident enough in your own abilities and value, you don't ever need to travel that rocky road.

Then there's the Not Invented Here syndrome. The pragmatic developer understands that there is no shame in collaboration or leveraging off someone else's work. "Real devs code from scratch"? What kind of egoistical rubbish is that? No matter what you do, you're leveraging off the work of Ada Lovelace, mother of the modern computer. Want to be a "real dev"? Go re-invent algorithms!

So...

Are you an adequate, good or great programmer?

This is, as you may have suspected, just my opinion. There are many ways to interpret the words of Larry Wall. In fact, I have no real business telling anyone how to achieve greatness in programming - after all, I'm just about adequate myself, on some days anyway. Like many people, I have my moments. Some days I feel like I'm Neo from the Matrix, and some days I wonder why I'm even employed.

But in general, yes, most developers fall around the "adequate - good" axis, with only the top echelons making it into the "great" category. Still, "adequate" is a good goal, and "good" is a respectable one.

Be virtuous!

Too impatient to sign off properly, too lazy to care.
T___T

Three Great Virtues (Part 1/3)

Larry Wall, creator of Perl, is also the author of Programming Perl. In it, he said something that has inspired me profoundly as a web developer.

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."

Now, there have been numerous interpretations of these virtues. But we're not going to bother with those; I'll be providing my own take on this. (What? Last time I checked, this is my blog.)

So the burning question - why are these virtues? In most other contexts, they would be considered sins. However, not just any lazy, impatient and arrogant SOB can be considered a great programmer. In fact, it takes a special kind of lazy, impatient and arrogant SOB to be a programmer at all. And I humbly submit that these three virtues are stated in that order for a good reason - they separate the adequate from the good, and the good from the great.

The Virtue of the Adequate Programmer - Laziness

If you remember nothing else about programming, remember this: minimum input, maximum output. All programming is about solving problems and automating tasks. Whatever fancy new gimmicks and technological advances the next twenty years throws at you, philosophically, programming does not change. This has been, is, and will always be; the one truth about programming. Whatever languages you use, whatever platform you swear undying loyalty to, it all goes back to this in the end - minimum input, maximum output.

The ultimate aim of any program is to make life easier. Because the awful alternative is more work. Not just more work - more boring and repetitive work which would be better done by machines.

Make the slaves do the work.

Programmers are always looking for the shortest, most direct route from Point A to Point B. They are always looking for a way to reduce that repetitive, monotonous task into a series of processes and outsourcing them for a dumb machine to execute. In other words, programmers are the taskmasters, and computers are the slaves. If that's not lazy, I don't know what is. The question is invariably "can this be automated?" followed by "how much can this be automated?".

Human beings get distracted. They get bored. They get frustrated. Machines don't. And therefore machines are the perfect candidates as slaves to carry out all that mindless work and in the process make life easier for the programmer. Notice how I said "make life easier" twice?

This is virtue numero uno for a good reason - not all programmers have the other two virtues (and therefore not all programmers are good, or great). But all programmers (and their cousins, the web developers) have to embrace this virtue at their core.

How not to be Lazy

Laziness comes in various forms. Not every form of laziness is admirable. If that laziness leads to more work down the road, it's counter-productive.

Copy-pasting code blindly without checking for relevance and room for improvement - that certainly qualifies. It's something I actively avoid.

If the code is going to be reused in the foreseeable future, invest a bit of time abstracting it into methods and subroutines so that it's easy to reuse and maintain. The Don't Repeat Yourself (DRY) principle is applicable here.

Sloppy code, lax security measures, incomplete test cases are all good examples, cases where the programmer couldn't be arsed to close that last loophole. Guilty as charged. Sometimes reality demands that I have to cut corners. It's not an excuse, but sometimes people have to choose between being a bad programmer who delivers, and being a great programmer who's out of a job.

In an age where many great programmers have paved the way for us by writing systems that automate even programming tasks, it's very easy to be lazy in the wrong way. Plenty of developers I know don't bother with the basics because that newfangled framework takes care of it for them. I'm guilty of this too. For instance, garbage collection and memory management is not exactly something I like to concern myself with - though in my defence, as a web developer, my priorities lie elsewhere.

Next

We examine Impatience.