Life got very interesting one and a half months ago. I had a meeting with my employer where he sat me down and asked me if GridSpy was ready to survive without my salary. Essentially he asked me if I was ready to leave and take GridSpy full-time. Being an VC funded entrepreneur himself he knew how hard it is to make that initial leap into full-time start-up and gave me a gentle nudge “out of the nest.”

After that meeting my mind was racing. My wife and I agreed that taking GridSpy full-time was absolutely exciting but equally frightening. We’ve been tightening our belts for some time to get ready for bootstrapping but even we don’t know how soon GridSpy will transition from a ‘sure thing’ to a trading business. I assured her that I could land on my feet with a contracting job should the money run out.

So with much trepidation I decided that it indeed was the time to leave.

With a month’s notice given, I served out the notice period with tense anticipation, mostly worrying about the money. It turned out that the money problem soon solved itself. A friend of the family runs a stealth start-up which now had need of a contract programmer, and it was suggested to him that I would fill the role..

So the plan was to serve out my notice and start the contract after a well deserved full-time month on GridSpy. It soon came to be that my new client had an urgent need for my services – arguably more urgent than our own start-up for at least a couple of weeks. As a founder, it was a real heart wrenching experience. With complete control over my time I have decided that cash in the hand now to build initial stock is worth delaying our product just that little bit longer. I’ve also had a nice little splurge, for instance getting the required noise cancelling headphones.

It has been four weeks now since my last day as a salaried employee and I’ve had a great time. For the first time in ages overtime has been optional, working conditions are in my control, and opportunities are endless. However, the opportunities being endless thing has taken me away a little, well a lot, from GridSpy. These last four weeks have been great for my client but not so great for GridSpy. I have really enjoyed the programming challenges of the contract work, but I really haven’t spent any more time on GridSpy than I would have before. I seem to have exchanged one full-time job for another. Again I appear to be working for ‘the man.’

However, my working conditions now are much better. I’m working from home on my favourite sort of problems with my four screens. After a 5 step commute from the kitchen table to my office in the morning I work solid until lunchtime. The afternoon starts late after lunch and a play with the kids and is occasionally interrupted by one of my gorgeous children demanding a cuddle. Dinner is at 5pm and since that tends to work out as a 6.5 hour day I often work an odd evening too. Even though it seems like a short day I have found my output is huge. I am really able to totally concentrate and complete tasks in a way I enjoy. I’m much happier and I’m spending much more time with my wife and kids – that’s great!

Back when I was a Part time entrepreneur I constantly dreamed of the day that I went full-time. How much easier it would be when I could work on GridSpy and not have to stop. When looking at schedules of when the next feature would be ready I could wistfully say “well, it will take a long time but only because I can’t work on it full-time.” Although it was true, it was also a very convenient excuse.

Now I have exactly the opposite problem. With complete control of my time comes an equal amount of guilt when progress on GridSpy doesn’t suddenly take off. Since late last year I have been eternally thinking that we are only two months away from a product that is worth selling, and today I would make the same claim. What we do have today is a fantastic product and a handful of very happy clients. Today our Minimum Viable Product is pretty refined. It is focusing all my energies into those two months, or what it takes to get GridSpy out there, I am now struggling with. This has been a surprise for me.

Each week I can choose how much to work – somewhere on the slider from “Instant Cash Today” to “Successful business tomorrow.” It doesn’t help that I love my contracting job. I had better set the slider back to “Successful Business” before we run out of time. To do that requires the ability to say “No.” No to fun contracting tasks, No to quick cash, No to partnerships that require a lot of time on our part, and No to distracting marketing. But how do I break away from ‘the man’ when I actually really enjoy the work (and the cash too.)

Reflecting on what I have written I can see that I need to reduce the contracting work to the point where it pays some bills only, and spend as much time as possible putting GridSpy as a finished product into the marketplace. Well, after this particular contracting task is over that is.

Further reading:

• Part time entrepreneur, Fulltime Employee
• How our devices have evolved

See Also:

• Gridspy Homepage
• Live demo of GridSpy

Part Time Entrepreneur, Full-time Employee

Most startups seem to embrace 60-80 hour weeks, you keep reading about them and begin to believe that this is normal. After 12 hour marathon coding sessions ‘typical entrepreneurs’ walk 10 metres from desk to bed and collapse in their shared accommodations. Living in such lean conditions makes those crucial first months of business far cheaper. This work ethic and minimial living costs maximises the runway before the seed money runs out.

Paul Graham is one of my favourite bloggers, and his essay entitled The Other Road Ahead he paints a clear picture of how lean a start-up can be, stating “You can literally launch your product as three guys sitting in the living room of an apartment, and a server collocated at an ISP. We did.”

No matter how much I’d love to take the lean ramen noodle approach it’s simply not practical for me. I’m a father of two, a husband of one, and an employee. I’ve got a beautiful family with young children, a modest house with a mortgage, and a full-time job to pay the bills. In short, I have a standard existence that I imagine many of my readers share. Living off noodles in a cheap apartment with my co-founders is not the only way that start-ups are built. I’ve taken an alternative route that involves just as much hard graft (harder maybe?) and allows me to remain employed full-time. The food sure is better!

I simply have to fit Gridspy into the gaps between the hours at work outside of the home and the start-up and the time put into fatherhood and being an available partner. It is a compromise position that I have had to maintain for the last year until Gridspy was ready. Along with the mandatory overtime, maintaining a full-time job limits my flexibility. I cannot travel to meet potential clients as easily or pick up the phone to talk to them. It markedly slows down progress. However, without the job there would possibly be no Gridspy, or less so than there is now, as there would be no base to develop from.

Despite my full-time commitments I still consistently work on Gridspy. As I mentioned in Selling the Dream I spend four evenings a week working on Gridspy (3-4 hours each one) plus all of Sunday and manage to make a lot of progress. Sometimes I spend my four hours on a blog entry, sometimes on some firmware or a little bit of Django code. Lately I have been creating the setup process for new users. There is a ton of documentation to do on our website – it all takes so much time.

Since my baseline existence is ‘family-man’ and a full-time job, I have had to pace myself with Gridspy. If I am not careful I will burn myself or my loved ones out (and trust me, we’ve been close at times) so I have to be the tortoise rather than the hare. At least doing a small chunk every night gives me a lot of time to think through technology decisions and plan my development.

Of course Gridspy is all that I want to work on and all that I can think about. This creates constant tension/wishful thinking in wanting to jump in both feet first and get everything up and running now, yesterday! It doesn’t help that this fully dedicated full-time start-up founder is also a widely published expectation.

But there are no savings to live off, and even though the almost three year old in my life would like to live on noodles for a bit, I don’t think I could for long. Being employed isn’t as simple as just turning up to my ‘day job’ and punching keys so I can pay the bills. I want, need, to be a ‘good employee.’ It takes conscious effort to honour my commitment to my employer. I remind myself everyday to focus on the work I do for them and to leave Gridspy at home. I’m sure you can see how after a long day at the office and after the chaos of the early evening with the kids, it can take a while to get down to the business of Gridspy. Sometimes all I want to do is grab a beer and turn on the TV.

I like my job, it has loads of benefits. Not least that I can afford to buy beer and have nice dinners and provide my wife and children with all the comforts of home. I have been given some great introductions to potential business partners through my well connected colleagues. I’ve had a group of fellow engineers to discuss my ideas with and sound out my features. Plus I’ve had lots of free coffee and idle banter around the water cooler to enjoy. The benefits of a stable routine and a reliable injection of cash into our bank account each month are not to be frittered away lightly.

But when it comes to developing my own gig, it is a chicken and egg problem. The sooner I take the leap and go fulltime with Gridspy, the sooner we can complete the features that are preventing us from doing a large scale release. But the moment I take that leap, the clock (and the bank account) starts ticking down. I have an extremely short runway and I worry that I could scuttle this opportunity before it has had a chance to take off.

Reading entrepreneurial blogs such as Paul Graham’s can make you think that you have to go fulltime or give up. I am taking an alternative route. By creating Gridspy part-time I have been able to give it the time and breathing room required to succeed. I’m starting to think that this path is the most courageous since it requires serious commitment to devote all your free time to your startup. In the end, I am sure that my compromises will pay off.

Further reading:

• Selling the Dream, putting Sales before Software
• Introducing the Nexus

I’d love to hear more about what you are all doing in your valuable free time and how it is going.

Thanks Eben for the chance to share this blog entry.

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.

I’m now a few years older, and a few years wiser; and I’ve found myself in a far off country trying to organise developments in a country 26 hours by plane away.

So, I thought I’d share some of the tips I’ve picked up from the experience so far. And for the sake of lazyness, I’ll write it as an “all time top 5″ list, a-la High Fidelity.

5) It helps if the two ends are culturally similar. I don’t mean culturally similar with regards to race, relgion etc… rather it helps when the two organisations are similar in ethos. Do you both have a similar level of commitment to clients? Do you both work similar hours? Have similar expectations of what constitutes an acceptable level of testing/documentation/speed of development?

4) Try and get the ability to allow both sides to access source. This gives you the ability to check progress… fix bugs and give suggestions that you wouldn’t otherwise be able to early on in the development cycle.

3) You need to clearly define the responsabilities at each end.. which country is responsible for tracking the project state? code deficiencies? documentation etc… Preferably there needs to be one designated person at either end ultimately responsible for deliverables. Without such a person, deliverables have a habit of languishing in the bowels of the development shop without progress.

2) Personal relationships are a key factor to making things work. Having met the other person at the other end of the phone can make up for a lot of process deficiencies. Put some people on a plane to meet the folks at the other end… if you haven’t met the side, your business is likely to suffer. Try and foster relationships not just with the senior members of the other side,  as the developers will likely be more open to going the extra yard for you if they have a face to put the work to.

1) Communicate. Daily if possible. Emails good, IM is better, Phone calls are the best. Make sure each side is aware of what’s going on…

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

Today a rather strange thing happened to me, I typed one another dev’s DAS Keyboard so my mind switched into full on touch typing mode, this lasted about 20 seconds before I started typing DVORAK instead of QWERTY (I can touch type both layouts – ironically I’m typing this on QWERTY). I’ve also been trying since around 1999 or 2000 to switch to the DVORAK layout but I almost without fail revert to QWERTY after a few weeks. I don’t revert because DVORAK is simply too hard or too slow because I’ve actually managed to build up my DVORAK touch typing speed to something that is almost useable. 

There are certain trends in the IT industry that just bugs me (and believe me that’s an understatement, ask anybody who’s had a similar conversation with me!) for instance the worst possible technology will be the industry standard! There are many examples of this, I’ll leave this as an “exercise” for you “the reader” to research. Back to the topic at hand, QWERT vs DVORAK is an excellent example – now I realise that some of you will claim that my statement is false and there is no scientific proof blah blah blah, I’m drawing on personal experience and in MY OPINION QWERTY sucks! Personally I like the way DVORAK feels while typing and that is why I believe that the worst layout is the standard. If you’ve read this far you might think that this is going to be another lecture on why you have to switch to DVORAK, let me assure you it is not!

So why am I mad as hell? There is a force that keeps me from my favorite keyboard layout and I wish I could eliminate it, unfortunately I do not think I’ll be able to. What’s my current options to get onto the DVORAK layout? I can use a soft switch by changing my keyboard layout on the OS layer, this might be fine for your average user that lives on a single machine or at worst case have a machine at home and a machine at work. In my case my home machine is also my work machine so theoretically I should have my cake and eat it? Another alternative is to buy a hardwired DVORAK keyboard, not only are these hard to find, some of them are just plain silly looking, tacky or very expensive . If there’s another one I’ve missed let me know in the comments I’d like to investigate it!

Interestingly neither of these actually solve my problem. I’m a laptop user, I’ve got a MacBook Pro to be exact, I’m also a Microsoft developer which means I spend a lot of my time using VMWare to run windows, not only that I work on many server environments via remote desktop and I even remote to some of my other Mac’s. The servers I use are shared machines which other developers use too and they are not DVORAK users either. So the first problem is that when I switch my Mac to the DVORAK layout it’s all fun and games until I move to windows VMWare will treat my keyoard as QWERTY regardless of what the Mac thinks it’s using, and right fully so the hardware is wired for QWERTY so it makes perfect sense, it’s virtualised and not dependent on any Mac settings. My real issue starts with the remote desktop connections, if Windows is set to use DVORAK remote desktop will blatantly ignore this and treat my keyboard as QWERTY – this does not make sense since it’s NOT virtualised and I’m merely sending the remote machine keystrokes! Suddenly I have to switch every machine I connect to to DVORAK when I only want my own machine to be switched and send the keystrokes as DVORAK instead of QWERTY to the machines I connect to. This works well when I’m using a terminal and ssh into a remote machine, why does this not work for other remote connections?

Another problem with the DVORAK layout is that short cut keys are usually chosen for their location on they keyboard or due to their relation to each other, undo, cut, copy and paste for example. DVORAK scatters these keys all over the keyboard so it makes no sense using them anymore and you loose all the benefits of using DVORAK instantly. There’s a partial solution to this with DVORAK layouts that switch to QWERTY when you hit the command key on the apple (I’ve not been able to find the windows equivalent yet, but it does not matter since windows produces too many other headaches besides this one). Don’t even get me started on trying to use EMACS or Vim (I use both I’m not religious!) on DVORAK keyboard, things go bad VERY quickly!

So my solution to this, and this is a theoretical solution I highly doubt I’d be able to find a practical implementation of it anywhere:

Change my laptop keyboard layout on a firmware (possibly even hardware, but I don’t believe it’s required) level, but I don’t want a standard DVORAK layout because of the short cut keys issue. Come to think of it if windows copied more of Mac OS X you might actually be able to globally remap all short cut keys to DVORAK equivalents. This might only get you part way there since there’s other issues on Mac OS X that will prevent you from doing this since Cocoa provides this magic and Carbon apps will give you the proverbial finger! The only way this solution will actually function properly will be when implemented on a lower level than the OS and even then it will be far from perfect.

So in conclusion DVORAK will ultimately be an EPIC fail, this sucks and gets my blood boiling, I really do like the DVORAK layout and in a perfect world there would be no QWERTY short cut keys would have been designed around DVORAK so all the counter arguments would also go away. Personally I feel DVORAK is better because on a subconscious level I automatically switch to it even though I spend 99.9% of my time typing on QWERTY. So if you’re thinking about switching to DVORAK I can honestly not recommend it unless you’re living on an isolated computer (which might be fine for most people).

DVORAK FAIL </ Rant>

P.S. Please prove me wrong! I’d like nothing more!

P.P.S. You might have noticed that I did not mention Linux in this post, I’ve given up on Linux many years ago due to the amount of pain associated with it (I did try DVORAK on it though and it sucked back then), my linux pain argument could fill a book so I refuse to go into it!

… 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

A little background first, this post has been in draft for almost a month now, I keep putting it off which is a little ironic, but the great thing about GTD is that you just need to renegotiate with yourself and it’s all good! The other strange thing about me blogging about GTD is that I’m probably the least organised person you’ll meet for a long time! Hopefully my post will inspire others like me to get a little bit more organised, it’s worth it!

Having said all of that I’m still terrible at practicing GTD and I really do wish I was better at it, but enough about that here’s the grunt:

Why a post on GTD?

That’s easy to answer (and yes I know every man and his dog blogs about GTD), it’s great, it works, and it has saved my skin many times already.

Why use GTD?

I’m not going to try and convince you that GTD is the best thing since sliced bread since it took me quite a while to really take to it, and even now I’m not “black belt” but I’m getting better. Once upon a time I used to work for a boss, life was great all I had to do was show up at work, do some stuff and I get paid, sometimes I didn’t do stuff and I still got paid. Now that I’m running my own software outfit life is a little different, if I don’t do stuff I don’t get paid! This of course creates a need to Get Things Done…

I’ll explain why it took me such a long time to really take to the concept first. When I was working at my last employer I started to read “Getting Things Done” because I was bored and had no work to do (again the irony is not lost on me). So naturally I got all excited about the prospect of actually getting things done, so I set my trusted system up did the whole go around the house and find everything that needs doing (if you read the book you’ll know). So that was step one done, I collected all my “empty loops”.

Then came the processing bit, now suddenly I had a whole lot of boring stuff around the house to do and some stuff at work to do. I never got round to doing most of the boring house stuff – some of it is still on my list (other things I’ve conveniently dropped off). The work stuff got done though, but there was a problem.

I was paid a whole heap of money each month to do some work, it turns out I didn’t actually do that much work, using GTD I got all my work done for the week in 4 hours (whoops!!), it turns out that you can bulk your time easily by surfing the web (then once the admins block your favorite sites, you can easily eat up 40 hours a week by playing nethack – no-one even knew!). This left me with a moral dilemma, do I use GTD and realise how little work I do, or do I go back to my old ways and pretend that I didn’t know (a little note about this though, being fairly efficient at writing code and knowing when to generate code and when not too does help a lot with the amount of work you get done – I still out produced the other developers in the company).

So naturally I started spending a lot of time playing with all the different GTD tools available to me for free to try and find the perfect one (I spent more time playing with tools than doing any actual work!). I also ended up dropping GTD due to a guilty conscience! Eventually the lack of doing any real work got to me and I quit my job, started contracting and I’ve not looked back yet!

Here’s a list of systems I’ve tried:

• lo tech – paper based (this was too much effort for me!)
• Monkey GTD and other GTD systems based on tiddeleywiki
• Thinking Rock (this one is quite nice actually – very functional)
• Things (It was great to start with but I reached it’s limits very quickly, never tried it with the iPhone app though!)
• iGTD 2
• Midnight Inbox (it was only in beta though to be fair!)
• PyGTD (Not sure if you can still find this, it’s a python script that operates on text files – good fun but again too much effort)
• OmniFocus (My personal favorite)

So how did I get back to GTD? Well as I progressed in my life as a consultant I ended up roping in a few of my good old buddies to help me out with the work load and I somehow ended up having to manage people and tasks and I started context switching like it’s going out of fashion. Naturally I figured GTD would help with the problem I’m having, again I started looking at tools and I kind of used it. It was still a struggle though and I only actually used GTD when I really needed it, this usually meant that I’m about to drown if I don’t do something about it and quickly too. So in a way I did learn something from reading the book but obviously I did not get the main point behind it, GTD is meant to be stress free. I only practiced it when the stress levels were so high that I’d have a mental breakdown unless I used GTD.

So why is it so difficult to get into GTD? For me the answer is simple I move around a lot and I’m not always at my computer where I keep my trusted system. This means the system only works some of the time and the time I’m “off line” it breaks down – the mental set back from this is actually a lot worse than I realised!

I finally bit the bullet and bought OmniFocus (both for the Mac and for the iPhone). OmniFocus is by far the best GTD tool I’ve ever used, and I don’t even use it the way it’s intended to I’m still not really using contexts the way they are supposed to be used. OmniFocus for the iPhone is a different beast and I would not use it on it’s own (even though a lot of people do this). The iPhone counter part is not that easy to use and will put you off GTD if that’s your primary GTD system. Using OmniFocus for the Mac in conjunction with the iPhone is as close to perfect as I can find at this time. It’s great I can take my system with me where ever I go and I usually do most of my task entering on the Mac, synchronization over wifi seals the deal! Now when I’m out and about and I need to capture something quickly I shove it in my inbox (which practically lives in my pocket) and I process it later when I get to the Mac and sync! All of this means I can tick my tasks off as I go on my iPhone and really keep on top of things.

So thanks to OmniFocus for the Mac and iPhone I can actually say that I’m practicing GTD (and I say practicing because I’m still really bad at it, but at least things are moving forward). If you’re a Mac head like me, you own all the hardware and you’re keen on GTD but you are struggling – I suggest you buy the software and start getting more productive!

So when I say that I’m suck at GTD it’s not because I don’t use my digital system, it’s because my system is virtually non-existent in meat-space. I’ve got an inbox, and a filing cabinet but it gets used only when it absolutely needs to be used – this is of course bad. The only thing saving my bacon in meat-space is the digital reminders of pressing issues in meat-space.

I do realise that each person has their own preference for GTD software, this is my preference. I do not suggest you drop your system, if it works for you then stick to it! You can take away from this post what ever you wish – read it with a grain of salt since I’m naturally Biased towards anything Mac and iPhone and I do not expect others to be that way too (then again if you’ve talked to me in person I’ve probably already tried to convince you to buy a Mac and some of you probably already have!). I just wanted to share a little bit of my experience using GTD with you and I hope you found it interesting if not useful.

Please leave comments if something is unclear or I just missed the whole point! 

Thanks for reading!