A: You know, I can’t deal with code that’s not correct.
B: But what is correct code? Isn’t the correctness of the code defined by the usage?
A: Yeah, that’s for sure, but you know, there’s still the ‘correctness’ in the code. I can’t leave a code behind that is not correct. Something that’s broken

Who hasn’t had this conversation? Of those who haven’t, who hasn’t heard it from other people?

There are more than two kinds of programmers in the world. Today, though, I’d like to pretend that there are the two kinds. Those who are happy with the code when it’s good enough, and those for whom enough is never enough.

And no – this is not going to be one of the fit-for-purpose arguments. The whole notion is self explanatory, and to be completely honest, I find it slightly condescending. As professionals in this field, it’s not like we don’t understand the concept of boundaries, parameters, conditions, constraints, and other things that inherently limits us and our code.

What I’m interested in, is where we derive this notion of ‘correct code’ from. There are many books written, many more guide lines set and countless hours of code reviews done, all for the search of the correct code. All this, without really ever having a satisfying explanation – not to mention the definition – of the correctness of the code.

In the beginning,

there was, or as it seems; there was, the correct code. Shown to us earthly beings by the higher powers, revealed through the dreams of the highest, righteous ones such as Ada and Dijkstra. They, our forefathers and priests, were the bridge builders between the world of us – the programmers, and the realms of pure logic and computation.

The computation was platonic. Numbers were integers. Computers were ideas.

‘How might we add numbers?’ Asked a money lender.

‘You enter one number here, and the other number here, and turn this handle.’ The righteous ones answered.

The money lender did his calculations. There was much rejoicing.

Then an astronomer came along, and entered the distance between the sun and the earth, then the distance between the earth and the moon, and turned the handle.

The great computing machine, at once, started steaming, then crashed and burned. This event marked the birth of something known as the ‘representation’. The computation had fallen from the realms of pure and accurate integers.  Unsavoury things such as precision, FLOATING precision, LOSS OF FUCKING precision, and others, came forth from the mouth of the ‘representation’ in a torrent of vomit.

The numbers we meant was, if you will, the will of the computation. The numbers we entered and the numbers that came out, were the representation. This idea, naturally, was met with much disgust. Many people tried to pretend that this was merely a passing idea, and that once we get finer cogs and smaller gears and stronger handles, representation will get closer and closer to the will, and all will be good, and we’ll be able to enter the Garden of Eden once more.

This day, alas, never came. In the meantime, though, the duality of the computation became the norm. The representation was not going away, and even though it was still vomiting forth the torrent of unsavouriness, people had grown to accept them.

The will, or the requirement, was correct. Representation that faithfully conveyed the will, was a correct program. Requirements were romantic.

Then came the War, and everything changed. It was almost like a back pedalling by the community, almost as if they were gripped by a nightmare. The will was not enough. It was not correct enough, they said, because it’s not done in UML.

What is UML? Asked a few. Most of those who asked were sent to the Camps. Those who escaped – the lucky ones – were captured soon and promptly burnt at stakes. Lucky bastards.

The tyranny of FORM and DIAGRAM and ARCHITECTURE and PATTERNS and CAPITAL LETTERS swept across the world, sometimes like the Black Death, and sometimes like the Pneumonic Plague. Sometimes, less often, it was like Cholera.

For those who remembered the days of the good will and not-so-bad representation, it was a sad time. This dark, dark period, was referred to as the Modern period, because that’s when they started chronicling the changes, and of course it was Modern back then.

The madness hailed all things strict and formal. Specification was the new correctness.

But as we approached the turn of the century for the second time in the history of the Code, there came to be a new school of thought – one that said, the specification might as well exist, but it really doesn’t matter if it’s not going to RUN.  If they didn’t run, said these Post Modernists, they aren’t codes at all. Do they even exist? How do we measure the correctness of something that exists, against something that doesn’t? Isn’t that like a cruel trial where you’re not even told what you’re being accused of?

So these reckless, shitless pimple-faced kids, who were now in their late-20s, started making up their own ‘correct answers’, or also known as ‘tests’. Of course they weren’t really correct, but they were steadfast. They said it didn’t matter whether those correct answers were really correct or not. The correctness, they argued, could only be found in the constant interplay between the code and the test.

The pure and platonic logos of the computation was pushed back to the back room. The line between the code and the correct test, between the correct code and the wrong test, and vice versa, blurred. The line between art and trash, promiscuity and chastity, vice and virtue, high-tech and low-tech, hipsters and yuppies, phone and computers and cameras and TVs and portable navigation devices, blurred.

And we find ourselves in this blurry time. Are we any closer to finding out what the correct code is? Probably not.

Not all is lost, however – I take a great relief in thinking that the era of the Black Death, UML and other horrors is now over. The era of bad music, bland building and startlingly ugly furniture is finally over.

The quest of finding out what the correctness of code is, is probably a bit more arduous than the quest of writing the correct code. But only because it’s hard, it does not mean that we get to give up. The best we can do is to question. Keep questioning, whether the code we’re writing is correct, and whether how we judge the correctness of the code is correct.

And by the end of our times, or by next Tuesday, we might catch a glimpse of the next mighty ones.

About three years ago, I was working for this company ‘A’. I had been working for this company for more than 4 years by then, which was also my first full-time employer.

At first, I really enjoyed it. Colleagues were good, the boss was really good, the work was interesting, and I got recognition for the work I did. Also, the money was good. I really had very little to complain about.

Then slowly but surely, I got sick of maintaining the same software month after month. Who wouldn’t? So I asked the boss-man that I be given something new to work on. He was most accommodating, and I was given a new product to develop and a whole new team (which I quickly populated with my close friends) to build something completely new, from scratch. I was ecstatic. It was tremendous amount of fun, while it lasted.

After a while, though, things started to go sour in the company ‘A’. We had a new CEO, whom I felt really didn’t fit into the company culture. We also relocated, and the new working environment did not allow my ‘team’ to work effectively as we did previously. The upper management (the new CEO and the boss-man) felt that we were not delivering our product on time, we had marketing woes, and so on.

The new product lacked a clear direction, either technical or otherwise. No one in the company exactly knew what it did and whom we intended to sell it. The management changed direction whenever there was a potential customer. It went like this:

A potential customer would require a customised demo, but the suggested sample would cause some performance issues on our pre-alpha version. So we were told to improve the performance across the board, and we made some strange technical decisions to make it go fast. Then the next week, another potential customer would come along and tell us that they’d like to run it on .NET rather than Java, so we spent a week porting all of our code, like maniacs.

At this stage, it was impossible to keep the development team focused. We got frustrated. None of the customised demos were spectacular. We didn’t win any of those contracts, and the upper management got frustrated as well.

Feeling that our team was not performing, they ordered a feature-freeze on our product. The team was effectively disbanded, save about one and a half FTE (full time equivalent) for the maintenance and even more demo-building. I was taken off the product team, and put to something else.

That position is what I recall as the least fun time I had in the industry. I was not able to touch any of the code for our core products, I was on maintenance of a side project, and I spent my days answering calls from our clients. I felt that I was in tech-support.

Frustrations piled up, and so did the personal friction between various colleagues. My ex-team members left  the company almost all at the same time – within a window of a couple of months. I really couldn’t get along with the CEO. Although at the time I attributed all my problems to other people, now it’s clear to me that I was the morose bastard who was being difficult.

Then I got into a discussion with a friend, who also has been in the I.T. industry for a few years. She told me that she intended to leave the industry for once and for all, because it wasn’t right for her. She was going to pursue a whole new career, starting over. Encouraged by her actions, I decided to leave the industry as well. I didn’t set any concrete targets. I thought may be about three months before I started looking for a new job.

I went travelling. After about a month of not working, I stopped thinking about work completely. I stopped touching computers at ALL. I read books, climbed, cooked, ate, drank, played with friends, and so on. My perception of time became.. strangely real. I started counting time with the passage of the moon and the length of the day, instead of working weeks.

This state of mind lasted, more or less, for about eight months. I say again: for the eight months, I did not sit in front of a computer for more than an hour at a time. In a typical month, my computer-time would be around 30 minutes a week.

I stopped thinking in terms of problem solving, modelling, structuring, simulating, all the mental tools that I used for ‘work’ went out the door. I got to the point where, when I was making a cup of tea, I was able to concentrate all my effort in making that one cup of tea, and drinking it.

I became single-minded. If I wished to do something, I did it with a complete focus. Mind you, I was not managing difficult problems. I was trying to get things done such as ‘eat something’ and ‘drive to the next village, where I can eat something’. Occasionally I had to convert longitude-latitude into map grids, but that was a simple task with a calculator.

Then all of a sudden, when I was driving to the next village so I could eat something, in the expanse of the Mongolian desert, I had an epiphany. A part of my brain that was turned off eight months ago, spontaneously rebooted. Wherever I saw, I saw patterns. They arranged themselves into problems, which I’d try and solve. Mole-rat holes on the ground would become 8-Queens. Longitudes and latitudes were prime numbers – or were they?

And I liked it. It was like finding an old friend. Even though I loved the simple, clear thought process devoid of any background threads analysing everything, I realised, in the end, that I did those things for living because I Liked It. I went to a university to study it because I Liked It.

From there, returning to the industry was a brain-dead decision. I may have lost a year or so in my career, but I regained something that so few people in this industry seem to retain, especially when they become worldly and wise after a few years out of the university – the knowledge that I do what I do for no other reason than that I Like It.

Log[...] things that you [...] care about[...].

I couldn’t agree more.

I’ve come across this guy, who wrote in this book that we should all stop commenting. Instead, if you needed to comment, log!

What an interesting idea, I thought, so I started doing it for a little project. Of course, comments on classes and methods remained, but all in-line comments were converted into log messages.

A few things became very apparent very quickly:

1. Logging messages were littered with obscenities.
2. The normal operation of the program generated a LOT of logging messages. This was OK, since the code was actually doing some complicated thing that I wasn’t fully used to.
3. All the ‘easy’ part, that we don’t normally comment on, don’t get logged at all. This caused a few problems. Without those messages, though, the logging messages didn’t ‘flow’. That is, it would jump from one difficult part, without giving me any closure on what was happening, to another difficult part.
4. If you include the working variables into your logging statements, you practically have effectively compiler-checked comments.

After a while, though, it became evident that this approach had its limitations and I relented, and my boss complained about the massive giganto logging file, but that’s a whole another story.

.J

… or ‘OO is hurting the industry because encapsulation’

The ability to abstract is a powerful one. I have seen my share of uni-freshers. There are a million different kinds of students and they all have their different ways of understanding. Obviously, some are better than others, and some are worse.

The worse kind of students are those who cannot abstract. Of course all human beings can abstract to some degree or other, otherwise no one would be able to drive a modern motor vehicle, or eat a pie. But some students insist on ‘knowing all the details’ because ‘that’s how they understand things’.

To those students, the concept of an API is difficult to explain.

‘You call this method, and fun things happen.’
‘But how does it happen?’
‘You shouldn’t care.’
‘But I need to know!’

And there are sighs. They most likely won’t pass 101, or if they do get through, they’ll be miserable for the rest of the course, unless you’re a hot chick and have a full set of 14 geeky Asian guys to help you out with the assignments.

There are a couple of explanations that can be offered for this. Most people, even some experienced developers, tend to side with one explanation: they are bad at abstraction. Without it, you won’t get far.

I beg to differ.

The reason why they won’t do well is that they are asking clearly the wrong person. They should not be asking lab demonstrators, who in all their infinite (well, 2 extra years’ worth of) wisdom, have no clue about how that API works. They should be asking the professors, the writers of that API, internet forums, or read the documentation, whatever. The information is available, but not from the lab demonstrators who get paid 13 dollars an hour including tax.

Their weakness is lack of confidence that stops them from asking difficult questions to the proper authority, and laziness in their quest for information.

Look at the top students on the other hand. The chances are, they fully well know how their favourite APIs work underneath the covers. They probably know how the chips are manufactured, how gates are made, circuits are designed, machine code is executed, assembly code is written, compilers are architected, and so on, and so forth. All the way up, all the way down.

My point is this: abstraction is a powerful tool, but it’s only a tool and it’s only one of the tools.

To pretend that the students ’shouldn’t care’ about how an API works is at best ignorant and at worst, well, just ignorant. Of course they should fucking care, you know? Like Knuth or Dijkstra or someone rather really important once said in one of their immortal essays, although what we produce is computer code, we should never forget that what we’re really crafting is the behaviour of the machine. The runtime matters. It’s the thing that we’re trying to get the computer to do.

How else, other than finding out what your function call does, are you going to determine what the computer will do? Reading documentation is fine and dandy, but that guarantees neither the completeness nor the correctness.

You will never learn how to fix a car by reading the owner’s manual, or even the repair manual, or even the blueprints of the car straight from the manufacturer. You have to open it up. Take the wheels off. Lift the car from its axle. Pry open the diff. Feel how broken that bearing is. Shake it and see what sound it makes. That is how you learn how to fix something. That is how you learn _anything.

Furthering my point, I make this claim: Currently, the ‘abstraction’ is severely overrated, especially in OO- and component-oriented programming circles.

What they write is this: the blue button makes it go. The red one makes it go faster. Do not press them at the same time. That’s the extent of the 90% of the API documentation there are.

And they expect us to work with it. What if you want to make it go slower? The trick is to press the two buttons at the same time, except for in the next minor version update, pressing the both buttons at the same time makes it blow up, and you’re punished for using an undocumented feature.

‘We told you not to’, says the smug author. And we agree with him. All the OO people agree that this is the way it should happen. Don’t do things that you’re not told to.

But hang on a minute. Don’t you think that’s even slightly weird? Why such change in behaviour? Why did it make it go slower in the first version? What deficiency in the original design prompted the authors to make such changes? Wouldn’t you want to know? Wouldn’t you be curious?

Most of all, wouldn’t you be pissed off if it broke your app?

But no. We’re told it’s just like a contract between two entities. You keep to the words, and don’t do things that are not specified it in the contract, or there be consequences.

Bullshit, I say: in the real world, if pressing those two buttons made things go slower for more than 12 months, it would be in the de-facto go-slow-mode contract, which would be enforceable. The wordings of the contract itself be damned.

The proper way to make things would be to let people know why and how the things work. Abstract it, document it, that’s all fine, but do not hide how and why things happen. Craft every bit, every level of the application correctly, thoughtfully. Then let people see it. Let people see your fucking craftsmanship. If you ain’t got one, this is a very good time to get one.

This brings around me to the final point: although I started off this article by talking about abstraction, it’s not about abstraction as such. It’s about hiding behind it and thinking that kludge is OK as long as you stick to the contract, the API, the interface, whatever.

People don’t think in terms of contracts. They think in terms of behaviours, hows and whys. When you ring up your ISP, you don’t have the service contract in your mind. You want the internet to work, and you want them to keep quiet about your midget-porn download usage. Fuck the contract. Who gives a shit? Who even reads them? If they didn’t have the explicit midget-porn-secrecy clause in their contract, and if they spill the beans, you’d be furious, wouldn’t you?

So there. Be honest, write good code, let people see what’s going on. Do not hide behind the encapsulation. If you do, you’re a midget-porn lover.

.J

I enjoy it, although it’s bitter and often hot, sometime sour and more often that not, just foul.

For me, there exists a cup of ‘platonic’ espresso, in which everything is good, no bitterness, no scalding heat, no aftertaste of chlorine, no burnt beans, no old beans, just … you know, coffee.

It is my firm belief that any realisation of this platonic coffee can only take away from the perfect, ideal, platonic version of itself. Brewing a cup of coffee is a process in which you try your very best not to deviate too far away from the logos of coffee.

But recently, as my coffee brewing skills improve, I started enjoying coffee a bit more. May be even a bit too much. I solemnly confess that there were a couple of cups of espresso last week that I even found to be wholly enjoyable. No, no, this won’t do.

Much like the platonic and real coffee, digitised images suffer from a similar problem. That is, there is the ‘perfect image’, which is, obviously, the scene which was photographed by God, then there are ‘realisations’ of the image, which are taken by real cameras. At the very moment we take the picture, there are imperfections. Dynamic ranges are lost, colours and definitions are inaccurate, and so on.

This is entirely excusable. We do not want to blame the coffee farmers for not having the God’s One Coffee Tree. Camera manufacturer are good people, making a lot of money, having an interesting, satisfying job.

However, there is one chronic and inexcusable place in which to introduce further imperfections; and that is the rendering time – i.e., when the digitised image is displayed on the screen. It is akin to going through the trouble of getting the beans all the way from Java (where, as we all know, where God once planted his One Coffee Tree), then not having hot enough to water to brew the coffee.

I mean, imagine: A perfect moment happens somewhere in the universe. This moment is unique in space-time, nothing EVER, ANYWHERE will be exactly the same. It happens once.

Then there is the perfect photographer, who, using his powers of divination, predicted this event, and set up his camera.

When the moment came, he pressed the shutter. The clockwork of metal and plastic and copper and nylon, electrons and spring completes its circle within one one-hundred-and-twentieth of a second. Oh, no, Nikon engineers made a mistake, got past the QA person, it was more like one one-hundred-and-nineteenth of a second. Zeiss engineers, also, made an imperfection on the lens, which smudges lower right hand corner of the image, very slightly, almost unnoticeable. There was one speck of dust on the front element.

But the moment is captured. It has 14-bits per channel. There are three channels. There are more mega-pixels than there are brain cells in the average photoshop user.

The pain begins. Like every other aspect of photography (and coffee) the process is continuous subtraction from the perfection. The art of subtraction leading to its own, less Godly and more human perfection. As the roasting of the beans is the subtraction of the freshness, the cropping subtracts part of the perfection, leads to a more concentrated whole, and so on, and so forth.

And after hours, days, months of hard work and pain and blood and sweat, the product is ready…. and it’s a fucking jpeg.

It can display 256 levels of red.

Jesus Fucking Wept.

What’s funnier? The modern LCDs. You’re lucky if your panel can display more than 100 shades of pure red.

Ok, here’s the technical part of this blog:

1. Invent a file format that contains arbitrary bits per channel of colour (TIFF does that? good. I don’t know).

2. Given that the current generation of graphics can do only 8 bits per channel, but it can do 60 frames per second quite happily, we map the x-bit per channel into 8-bit, but randomise it over time. So when the average is taken over a second, it reproduces the original colour.

3. Add extra room for oscillation to cater for the shitty displays. The net effect will be a still photograph that looks like having motion-picture film-grain.

4. Not sure whether this will actually lead to a better looking image.

.J

And for those who didn’t enjoy it: I still think that you might be decent human beings, but by God, what’s wrong with you?

But now that’s out of they way, what I want to write about today is about the ’standardisation process’. If you do not like the topic (like I don’t) or believe it irrelevant, you may stop reading now.

Plato, when asked the question of ‘Who will watch the watchmen’, he said that they themselves will, because they will believe that they are better than the other people. Through this egotism and alpha-male altruism, Plato believed, that the society could have a safeguard against failure.

What an idiot.

Government-sanctioned technical committee are a bit like that. They are entrusted (and that’s where the word comes from) by the people to produce something useful, and what they produce will have large legal, technical and financial implications.

If the enforcement is the person wielding a hammer, and the law is something that gives him the right to use it, the committee decides what the hammer is made of.

And the answer is not always as straightforward as you might imagine. What is the manufacturer of Egyptian cotton doing in this committee?

The year was 2005, and I found myself at the round table of a HISO committee. I was to write the draft standard for what would dictate how various health-IT organisations in New Zealand would exchange electronic data.

I was a software developer with four years under my belt - which is like fucking forever, right? - and for the first time in my life, had a ‘team’. (I was cocky enough to call myself a ’senior software developer’ or a ‘technical lead’)

I was bulletproof.

I made jokes about the committee and others around me laughed with me, but I believed firmly that I was in the committee because I was better, I knew better, and I could lead all of them to a better place.

And by God, how quickly the power corrupts. And by God, what an idiot I was.

The first thing I did was to grab the requirement specification document of the product that we were busy implementing, deleted all the trademarked words, and submitted it as the draft standards document.

It had holes in it, it had some strange decisions that were not fully justified (or justifiable), it was still in pre-alpha stage of development, and it was all around propriety, ignored all existing related W3C standards. But it works, ok? Isn’t that what’s required of the committee?

My ulterior motive was to get my document accepted; that would mean I wouldn’t need to implement a standard; my programme would be the standard. Everyone would want to buy a copy of my software; it will be the only one available; and you’ll be required by law to purchase a ’standardised’ software.

Looking back now, I see that pushing an ulterior motive through a committee is impossible. On the other hand, blocking other people’s motives is dead simple: stall.

There are four all-day meetings a year. And by ‘all-day’, we mean about 4 hours long. first hour will be spent on recapping, the middle two on lunch, and the last hour on organising the next meeting. There is very little stalling to do.

They stalled me, I stalled them. All along the watchtower, watchmen were busy stalling themselves.

I’ll save you the details. It’s not interesting. What I want to say is this:

Do not attend a committee with an ulterior motive, because you won’t get it through, and you’ll make everyone else’s life a little bit more pointless. It does not matter whether you think it’s clever (it’s not) and it’ll work (it won’t) and other people on the committee are idiots (so are you).

If you have an ulterior motive, go with a little bit more direct approach. And yes, I’m fully condoning the use of violence and blackmailing.

[...] they are SLOW.

I couldn’t agree more.

In all seriousness, however, I should point out that from my limited experience, Wordpress just deleted my post, that there are differences between a bespoke development project and a generalised solution/product development.

For a bespoke development, I couldn’t agree more that we simply don’t write that much difficult code that is worth testing.

In a generalised product that is supposed to work out of the box, configure itself in a foreign and what must be considered harmful environment, facing endless molestation and little games of feeding ‘funny’ shaped input, unit tests are extremely valuable.

I must add, though, that even in this case I believe that ‘a Java class as a unit’ is a ludicrous notion. I’m talking about at least a package/assembly, or a whole component that could be made up of several of those. I know by now I’m no longer talking about unit tests, but hear me out:

I once wrote a system that takes XML and generates Java code, that compiles against a Java library (also written by me) and supposed to do something. There were tests written about really really anal behaviours, such as ‘what if the user adds 59 minutes to 2AM just before daylight saving’ and so on.

Some time later, we had to port our system across to C++, and of course we didn’t have a requirement specification. The C++ guru we specially brought on board went “what the f?”

But when I explained that we had test cases and all he had to do was to write the program so it passes the tests, he went “ok”. And lo and behold, it was so.

I guess in the end, this anecdote really had nothing to do with unit testing.

Secondly, the title of today’s blog is a lie: My cat did not bring anything last night, and I do not have a cat.

Which leads to my third point:

Technology is a lie, just like my cat.

I really should clarify: current generation of business computing technology is a lie, just the same way my title was.

There is no ‘technology’ going on. We have run around in a giant circle past ten years, relying on hardware manufacturers to accommodate for our ever bloating layers of layers of abstractions upon abstractions. We still rely on HTTP, and AJAX is a (very shallowly) glorified <iframe width=0 height=0>. Development of the languages that we use day-in day-out has been making something that looks like C behave more like LISP.

Technology. Give me a fucking break.

Technology is defined as ‘the application of scientific knowledge for practical purposes, especially in industry’. What part of what we doing can be described as ‘Technology’? If any among you want to cry out ‘it has adopted a new meaning because languages change’ just fucking shoot me in the eye now.

There is no ‘Computing’ going on, either. Current generation of computing has as much to do with computers as the current driving has to do with horses.

If you take a long drive down the lane all the way to the wops, you might hit one.

We write a few eXtensible Markup Language Documents, that is to be read by some program being run on an interpreter running in a virtual machine running in a virtualised environment. Sometimes I do wonder whether it’s virtual machines all the way down.

But anyhow, the fact that computers don’t do any real computation shouldn’t come as a surprise to anyone by now.

Then there is Business; Business is the last thing we are worried about in any given day. How often do you gloss over a bug, a feature, an unimplemented button, saying to yourself or to a colleague or a manager or a client saying ‘that’s a business problem.’?

How effing often, do you really worry, care, think about, talk in terms of, the business, the final product that we are supposed to be delivering? How often do you brush this thought aside for someone who knows better, deep down fully well knowing that there is NO ONE who understands it better?

Business, whether you, a J2EE developer, an ASP.NET developer, SQL junky, Javascript monkey, whatever you might be, like it or not, is what differentiates you from John F Carmack…. and also the fact that he’s good enough to have made it and owns Ferraris which is also his middle name by now, but that’s beside the point.

Let me start the paragraph above all over again.

Business is what differentiates us from other sufferers of the modern computing technologies. Whether we like it or not, as long as we are in this field, and pretend that it’s an application of science and that it’s going somewhere and the world is not made of turtles all the way down, we bloody well should care what we are applying it to.

Every line of code of Java or .NET that you write, wishing that you were writing a new breakthrough algorithm that will  turn the world into a giant bathtub filled with supermodels and peanut butter jelly sandwiches in Ruby, is killing baby Jesus.

If you are going to do the job and get paid for it, start caring. Start firstly from the first word. Start from Business. Then care about computers, then worry about applying science. If you don’t know any science, like I don’t, stick to the first two. Please to cease and desist to pretending, or start to learning, if you will, why not.

Please become an expert in your domain. If you are in insurance business, please understand how a broker works, what an underwriter does, who processes a claim. If you are in health IT, learn about ICD codes, learn how hospitals operate. If you’re in banking or accounting, please know what Basel-II and IFRS are (if you still have a job, that is).

Because then you’ll write better software, and your work will be more focused. You’ll ask fewer stupid questions. You’ll become far more valuable. I’ll curse a little less when I use the software you wrote.

That is all I wanted to say.

And of course, I’m saying all that to myself.