How I live and how I work

27 June 2013

I live differently to everybody else I know.

Other people go out to work. They earn money. They spend it. On houses, cars, children, gadgets, holidays. All kinds of things.

Sometimes they complain about work. Sometimes they complain about how expensive things are.

I don’t complain about either of those things.

I sit at home all day, creating software. I haven’t worked out how to make much money from it yet. But I’m getting there.

And yet, I seem to have plenty of money. Enough for me to live on for a few more months anyway, without having to worry just yet.

I haven’t won the lottery. I spent about six months last year doing some contract work, to earn of bit of money before coming back to doing my own thing again. But that contract wasn’t especially highly paid - pretty average, maybe a little on the low side when I compare it to other contracts that I’ve seen advertised, and the rates that other developers  I’ve spoken to have charged.

I suppose I lead quite a frugal lifestyle. If I look back 10 years, the lifestyle I had a student isn’t actually very much different to the kind of life I lead now. When I started working, I didn’t start spending.

Maybe it’s because when I started working, I had some student debts to pay off. Not the UK Student Loan - that’s paid off very gradually out of your pay packet - but some nice big credit card bills. I paid those off with a graduate loan from the bank, which then took me about three years to pay off.

So I was working but I couldn’t really afford to change my lifestyle, so I didn’t. Then when the debts were paid off, why change anything? I simply started saving.

Over time, those savings built up. I could have done quite a lot of things with the money. I could have put down a deposit to buy a house, sooner or later anyway. I could have bought a big shiny car. I could have saved a bit less, and developed a taste for expensive shirts or exotic foreign holidays. Or I could have started a family.

But I’m not interested in any of those things. Instead, the money allows me to buy the most valuable things in the world. Time and Freedom.

Some people save up for their retirement to start enjoying life. They put up with years of hardship, waiting for the light at the end of the tunnel.

I don’t believe in retirement. Not just because the economic situation at the moment means it’s likely that for many of us, even if we save up, retirement will be continually postponed until we are too old to really enjoy it. But more importantly, if you can set up your life so that you enjoy work, so that your work is your life, and your life is your work, then you never need to stop.

You can enjoy your life right now. You just need to spend less money on shit that you don’t need.

There are some great comments on this article at HackerNews

The secret of good documentation is empathy

26 June 2013

Writing documentation is hard, but that’s no reason to skimp on it if you want to run a successful software project. It’s certainly one of my least favourite activities, and usually one I put off right until the last minute, but the existence of good documentation is often the deciding factor whenever I’m assessing whether to use some software.

I have become accustomed to most documentation being pretty crappy though - so much so, that sometimes I forget to even look for it. I’ve been learning the JavaScript library Knockout this week, and I’d looked a few things up on Stack Overflow before realising that Knockout’s own documentation is excellent.

What I like about it is:

  • it's written to help me out, as a new user who knows nothing about Knockout
  • it explains why I would want to use it in the first place
  • it guides me through the key concepts, with examples
  • it doesn't shy away from the "advanced" stuff, but it flags it up appropriately - so if you're more of a JavaScript novice, you know which parts you can safely skip, but if you want to know more detail about what it's doing, all the info you need is there
  • there is a clear progression through the documentation - pages are relatively free of links, which keeps you on the right path, but if you want to jump in and look something up it's easy to do so

It’s just the right amount of detail - not too little, not too much, and you can read the whole thing in quite a short amount of time and feel like you have a good understanding of what Knockout is and how to use it.

While I think of it, the documentation for Bootstrap is another example which manages to get this kind of digestible tutorial-but-also-reference thing right.

As much as I love PhoneGap, I wish their documentation was as good as this. Frequently, it’s not kept up to date, which can lead to a lot of hair tearing even when trying to follow something as simple as the guides for setting up your first project. How many users have been put off using PhoneGap at all because of this?

I think all that’s needed is a little empathy. Remember that a new user doesn’t know anything about the software - and their first question is “why the hell should I bother using this in the first place?”

Answer that, and then think about what they’ll need to know next. Simple stuff really. But apparently, easy to forget. Why?

Nobody will tell you how badly you’re screwing up the experience of the first time user.

New users won’t give you feedback. They’ll move on elsewhere - maybe to some competing software, or maybe they’ll just give up on the whole idea of what they were trying to do anyway. They’ll think it’s their fault. They must have set up their computer wrong, or they’re too stupid to understand this, or this software isn’t really for them anyway.

I did experience some “road bumps” with Knockout even though its documentation is great. Fortunately, these only occurred after I was quite far through reading it, so I persisted instead of giving up. Did I just miss something by skimming over it? Maybe - after all, most people skim when reading on the internet, and I’m no exception. Maybe I’d just failed to grasp something which was never explicitly stated, and that functionality could have worked in a number of ways.

Having solved my issue, nobody is ever going to get to hear about what it was, or how I solved it. Other users may have the same problem, and will have to figure it out themselves too. The maintainer of the documentation will never know - there is no channel for me to say “I didn’t understand A, until I realised B”. There will be no bug report for an issue which may be unique to me and my brain.

IFComp 2013 announced

25 June 2013

The IFComp 2013 has been officially announced!

This is the biggest text adventure competition there is - now in its 18th year. Entries can be written for any interactive fiction platform, and it usually gets some good coverage out there in the wider world. Many authors wait for the competition to release the game that they’ve been working on all year.

This year, I’m planning to be one of those authors myself, with my first work of interactive fiction - eeek!

There are prizes to be won too. As it’s only just been announced, no prizes have been donated yet, but you can get an idea of the kind of thing by looking at last year’s prizes.

If you’re planning to enter, take a good look through the rules. Note that all entries must be previously unreleased - this means if you’re working on a game now that you want to enter into the competition, make sure you don’t release the game publicly beforehand. This doesn’t stop you from having a few beta testers though - and in fact, getting your game tested by a few people is something I’d strongly encourage!

You have until 1 September to declare your intent to enter and until 28 September to upload your game. Games are made available a couple of days later, and the results are out on 15 November.

Good luck everybody!

Preventing your software from descending into an abyss of complexity

25 June 2013

Nice article by Kris Gale on the hidden costs of complexity in software:

Among the most dangerously unconsidered costs is what I've been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer.

I used to work on a huge financial software product, written in VB6. Legend had it that this was the largest VB6 program ever built - hundreds of different components. And it was painfully slow to work on. The whole application desperately needed refactoring, yet despite there being a team of 20 developers working on it, development had basically completely ground to a halt. We were all busy, of course - plenty of bug fixes and minor feature requests - but it never felt that the application was noticeably getting better.

There had been an attempt to move the application into the world of .NET, but all that had achieved was creating a hybrid VB6 and C# application that added yet more layers of code. Nothing was ever removed, or stripped back, or simplified - just more and more code added to the pile.

It meant that it took a long time to add any new functionality, as you had to dig through all of the layers, and inevitably changing anything would cause something to break, often in a subtle way in a completely different part of the application.

I used to enjoy coming home from work and hacking on Quest for a few hours, because it felt like I had suddenly become 1000x more productive, and could add new features and fix bugs almost scarily quickly.

Now that Quest is (for the moment) my full-time job, and with its codebase having grown quite considerably over the years, I have to be careful not to bring the same problems upon myself. All software tends to stagnate over time - I’m reasonably happy with how my own architecture is holding up, but even then I often find I’m slowed down by having to ensure that it always remains compatible with games created for older versions, and that any changes I make to how it works apply across both the desktop and web editions.

In some ways, it would be nice to strip things back a bit - perhaps making it a web-only product, instead of there being a Windows desktop version too. The existence of the desktop version seems a bit “legacy” now, but there still a genuine need for it - schools don’t yet always have reliable or fast internet connections for example.

The challenge, then, is to ensure that any complexity that exists is there for a good reason, and to keep an eye open for where things can be simplified. It’s very easy to ask “how can this software do more?” - perhaps we should also sometimes ask “how can this software do less?”

Try throwing away some stuff

24 June 2013

Alex Kristofcak has an interesting idea:

To fight the plague of accumulating crap I came up with a business idea: after you sign up, you get an empty box in the mail with a paid return label every month. You fill it up with stuff you don’t need and send it back. You then get a $10 check.

We’ve been decluttering our house for the past few months. We’ve got rid of a whole load books and useless old gadgets. Novelty lamps. A blender. Vases. Cameras. Suitcases we never used. We’ve got rid of furniture.

We’ve gone through our cupboards. I had old computers from the 1980s in there that I was never realistically going to get out again. There were old DVD players and VHS recorders.

Every little thing. Even a teapot we didn’t need. We already had another one - who needs two teapots?

Rachel even got rid of most of her CD collection. I’m still too sentimental to get rid of mine - even though I rarely listen to CDs these days. Maybe one day.

The extra space has meant we can get by living in our fairly small house for a long time. That’s a huge money saving. It’s also good for the mind - freeing ourselves of the guilt of not using all our stuff is hugely liberating. We can get on living our lives as they are, without sharing our home with past versions of ourselves, or indeed, the fantasy versions of ourselves who in our imaginations would one day actually use all these things.

All Posts