Archive for the ‘Uncategorized’ Category
I’ve been happy here at wordpress.com, but it’s time to move to a new home:
- Adverts? On my blog? No thanks. Wait, how many dollars per year to get rid of them?
- Having one name for the blog and another for the domain is just wrong.
So today I am moving to http://yieldthought.com. You’ll have to resubscribe to the new RSS feed, which I’m sorry about, but the good news is you can now *also* follow me on twitter. Hurray for social media!
Feel free to check out the new place and leave a comment or a tweet to welcome me to my new home!
People giving advice on how to make a million dollars often say things like “be a machine”. It’s just an expression, right? They’re trying to say that you should stay focused and work long, hard hours to the exclusion of all else. Aren’t they?
No, I don’t think so.
I think they’re trying to express what discipline feels like. Discipline is doing what we decided to do and not what we feel like doing. It’s amazing that more people don’t talk about discipline, because it’s such an incredible force multiplier:
Even if we’re somewhat more productive during the hours we want to get things done, it’s still difficult to ignore the difference between what we do and what we could do.
But this afternoon I just can’t concentrate hard enough to refactor the payment system. I’m not in the zone!
— The collective whine of developers worldwide
Discipline isn’t single-mindedness – it doesn’t mean forcing ourselves to sit there, banging our heads against the keyboard until something breaks. It’s about taking the easy option off the table: yes, I want to give up and read Reddit. Just for a minute or two. Just to relax and recharge, then I’ll be able to focus so much better…
No. Recognize these desires? Pleasant, tempting, but useless. They don’t bringing us any closer to achieving our goal, so screw them. Once the easy, useless options are gone, what can we do to make some kind of progress? There are lots of different ways to make progress even when we feel all concentrated-out. Sketch out an understanding of the system on a piece of paper, away from the screen. Take the classic short walk; something that actually clears the head and refreshes as opposed to just being a pleasant distraction from the guilt of not working. There are many ways to keep on pushing forward.
Paul Graham Loves Discipline
This discipline is the relentless resourcefulness that Paul Graham praises so often: the dedication to pursuing our goal, regardless of how many detours we have to make to get there. When you’re running a startup, sometimes failure is the easy option. Last year the online bagel business seemed so exciting, but now it’s dragging, conversion rates are down, Amazon have entered the space and suddenly you desperately want to be doing something else.
Discipline helps us focus. It takes the easy option of giving up – or daydreaming about it – off the table and looks at other ways to keep on making progress, like diversifying into the custom toppings sub-sector.
The easiest way to build discipline is to stop pampering every little emotional whim. Don’t feel like working? Suddenly curious about what people are saying on twitter? These aren’t deep-seated emotional needs, they’re pathetic passing fancies that we can do without. This is when it helps to think of ourselves as the machine, ploughing relentlessly, unstoppably onwards. The machine doesn’t get bored or distracted or lazy. The machine does what it’s told, and we’re doing the telling.
But, but, burn-out! Overwork! How can he be suggesting this?!
I can hear the cries already, but they’re all wrong. Sometimes it’s ok to treat ourselves as machines. Nobody’s going down the coal mines. It’s not going to do any lasting psychological damage to go without a Dilbert hit for the next two hours. Also, overwork isn’t a sign of too much discipline, it’s another sign of too little. It’s giving in to the less common addiction of always working, even when we know it would be good for us to stop and spend the weekend with our family and friends.
At the end of the day we’re going to look back at how we spent it. Discipline is the strength to do the things that will make our future selves proud, instead of vaguely ashamed. It’s doing the things we’re going to wish we’d already done.
The great thing about discipline is that it gets easier the more we do it. There’s not some finite amount of self-control to get through each day that’s recharged by browsing the xkcd archives. Our in-built sense of when we need a break has been destroyed by years of ADHD-like alt-tab, ctrl-t and resetting it actually feels good and liberating.
Ten Things That Actually Help
Most productivity tips around are variations on “be more disciplined”, but they don’t talk about the discipline explicitly. This makes them attractive, because who want to be hard on themselves? It also makes them less useful, because they don’t tell us how to become more disciplined.
Take the pomodoro technique (45 minutes work, 15 minutes slacking off for being a good boy) – what they’re really trying to say is “be disciplined for just 45 minutes – you can manage that, can’t you?” That’s a lot like Joel’s advice to “be funny” when we write – it sounds great but leaves out the important bit, like: what can we actually do when we start getting distracted? So I’ve put together a bunch of real things that help. Well, they help me, anyway:
- Treat yourself like a machine that exists to carry out your will. Ignore any feelings of reluctance or distraction and force yourself to start the task. Don’t be afraid, it won’t hurt. It’s good.
- Ask yourself: is browsing reddit going to make me a million dollars? Does the person I want to become spend their day reading comics? Hint: no and no.
- Do something to take the temptation away. When you find yourself heading to Penny Arcade just close it, stand up, go look out of the window. Think about everything else you could do that will still bring you closer to your goal while giving you a break from the direct task.
- Avoid the trap of “rewarding yourself” by spending the rest of the afternoon catching up on all the reddit articles you’ve missed. Take a lunch break, but do something actually relaxing in it. Sitting in front of the screen reading more text won’t make it easier to concentrate later on, so don’t.
- Be proud of your discipline. Reading Hacker News is so tempting because it gives us a little kick of endorphins, but so does feeling good about yourself every time you override this impulse. When you start being disciplined just to prove you can, you’ve already won.
- Subscribe to Hacker Monthly – the beautiful magazine format gives you a reason to avoid reading too many articles in advance and takes away the fear of missing something important.
- Alternatively, get Instapaper. Instead of reading articles online, just use the bookmarklet to save them all for reading on your phone next time you’re travelling or caught waiting without net access. This works pretty well, but not as well as ignoring them altogether.
- Your email can wait and so can twitter. If it’s really urgent someone will call you.
- Recognize that doing things to avoid thinking about something else is a waste of time. Doing things we enjoy is great, but if we’re being honest most of the time we waste we’re not really enjoying ourselves, we’re just passing the time.
- Decide in advance when to stop for a break. If you don’t, after a while your thoughts start circling: “Shall I stop now? How about now? Maybe now?” It’s the mental equivalent of “Are we nearly theeeere yeeeeet?” and it’s very distracting. If you pick a time or a clear milestone and stop when you reach one it’ll be a lot easier to keep your focus.
Stop Messing Around And Get Started Already
Seriously, this is great. Give it a go for a couple of days. When you want to get something done, be a machine. Say no to your distractive impulses and see what happens!
Ok, I’m done. You can start now.
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
I used to think removing special cases – the extra if statement that handles the unusual file format that doesn’t quite fit – was the best way to improve my programming. Every time I had to add a special case to a function it meant I wasn’t solving the problem generally enough.
In a way, which I’ll come to in a moment, this was ok. In a much more important way, it was really-and-I-mean-shoot-yourself-in-the-foot-and-throw-the-remains-into-a-vat-of-industrial-strength-paint-stripper stupidly wrong.
What made it right was my innocence – back when I knew nothing about programming (i.e. when I thought I knew everything) longer-lived programs started accruing odd if-statements and shoe-horned additional functionality all over the place until they were an ugly, barnacled mess of additions and changes that I didn’t understand and couldn’t work with any more. Every time I promised myself that next time I’d resist the temptation to add just one little exception and instead refactor to a more general level right away and everything would be clean and smooth and regular and easy to work with forever.
I guess lots of people have reached the same conclusion, because I notice examples of the unsaid assumption that Special Cases Are Harmful a lot. Today, I’m taking a stand: adding special cases – making exceptions – is the single most important thing we can do.
It’s All Fun And Games Until Someone Loses An AbstractEyeMonsterFactoryFactory Class
I wrote lots of little games when I was learning to program and I’m guessing you did, too. I made them because I wanted to play them, and that meant I tried to generate levels and enemies randomly in the hope that my own game could surprise me. I didn’t want to add special code for boss monsters or for each level – that would defeat the point. Every level had to run the same code, just with different data. No special cases, remember?
Well, all of my games sucked. Sometimes the mechanics were fun enough, but after a couple of levels the game just got boring. Algorithmically-generated enemies and levels simply weren’t interesting, because after a while the patterns became obvious and then there was no reason to keep exploring deeper into the game; one level was much the same as any other.
I’m sure this is stupidly clear to anyone who actually designs games for a living or works in the industry, but it was a revelation to me that the most interesting and valuable parts of a game are the parts that show a human touch, where I could feel the presence of a real person who put some thought into the experience. While ‘special cases’ looked like cruft at the level of an individual algorithm, they turn out to be the essential, core content and personality at the user-facing level. I’d been systematically stripping my work of any personal, human touch whatsoever.
In real applications, whether games or business sites, special cases add a massively disproportionate amount of value.
Posterous know this – they’re laboriously and painstakingly adding beautiful import functionality from each of the other major blogging platforms. Each one is a special case, they didn’t restrict themselves to one common ‘import blog’ feature that scans a page and does its best to rip the text, formatting and images – no, they give users from each of the major platforms special, individual treatment.
Google were the first to do this in a big way in search: how cool is it when Google converts a currency right there are the top of the page? Or shows the weather forecast? Or the cinema listings? Each of these are laboriously hand-coded special cases. I once met a guy at Google whose full-time job was working on showing sports results at the top of mobile search queries. That’s dedication to the special case.
There’s a couple of reasons why looking at special cases are often better than adhering doggedly to an increasingly complex general case:
- Special cases are solvable. We can be very, very clever when we’re only handling a small, discrete part of a problem. The general ‘show the most relevant information to a search query in an immediately readable and usable way’ is so hard it’s still unsolved despite decades of attempts. Just look at Wolfram Alpha. In comparison, pulling up the current forecast for queries containing a local word for ‘weather’ is almost trivial.
- The results are better. The general ‘import blog’ problem is hard to get exactly right, but we can write code to import just wordpress blogs perfectly because the problem domain is both smaller and better defined.
- Whatever we think about solving the general case is almost certainly wrong until we’ve solved a few special cases first. The real world is not a well-defined problem; special cases help us explore the problem space.
I’m tired of hearing that ‘if you solve a problem right, you only have to solve it once’. Yes, this is fine in theory, but is completely bonkers when applied to the changable, unpredictable real world. If we try then most of the time we:
- Never find a perfect ‘general’ solution for all cases, or
- Find one but spend so much time and effort on it that we neglect a million other important things, or
- Get ‘close enough’ and just stop, which means a solution that’s imperfect in most cases, and by ‘imperfect in most cases’ I mean ‘that makes most people slightly unhappy’.
Look After The Pennies And The Pounds Will Look After Themselves
You know what? When we try so hard to make each special case just right, general cases will start to fall out naturally. This is the right way around. The other way, hypothesizing a general case and enforcing it onto everyone, that is the wrong way.
Look after the special cases and the general case will look after itself (well, unless you’re unusually incompetent)
— Mark, Make Exceptions
Adding super-slick handling for a few common cases is such ridiculously low-hanging fruit that I can’t believe so many companies miss the opportunity. I think it’s this pattern of reasoning we learn when we begin programming – this desire to avoid messy details and refactor to a more general level that handles all those cases implicitly. It turns out that this simply doesn’t apply well to product design and, if we want anyone to use the programs we’re writing, we should always be thinking about product design.
So yes: we can make exceptions for people and go out of our way to make them smile. People are trying to accomplish real tasks with our applications, our websites, our businesses. We have to keep looking out for next special case we can handle that makes just one of those tasks improbably and awesomely simple. Software’s not about ticking the most feature boxes with the fewest function calls, it’s about making someone’s day.
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
… that there are those among us who have never heard Code Monkey – if you think I’m talking to you, then may I humbly suggest taking steps to rectify the situation at once 😉
Every now and again I see glimpses of myself in ‘younger’ programmers as they struggle with the same concepts I did, fall into the same mental traps and generally make similar mistakes. Writing the 4 wrong ways post made me wonder how common these phases really are and whether we could categorize them.
You too? Well wonder no longer, for I have completed this herculean task! I’ve found myself in each of these traps at least once – some of them several times – and have seen them in others too. Are there more out there?
The Enthusiastic Newbie
The newbie is full of passion and excitement for her one and only language, which is undoubtedly VB, PHP or actionscript. Having finally got to grips with the syntax of said language she feels she’s completely mastered it in all its forms. The newbie writes astonishingly quickly, but everything ends up in one big file full of global variables. This is a very productive stage, if little worm games and random utilities / replacement shells are what you want produced.
Distinguishing code features: Each program is exactly one file, containing a hundred global variables, none of which has more than four letters in the name.
Mistaken belief: Programming’s pretty easy, really.
Most endearing quality: Her little shiver of excitement every time she opens her IDE and gazes at a blank project, full of potential.
Reads: Firefly fanfics.
Most likely to say: “Come and look at this cool flash game I just finished!”
The Budding Genius
Having programmed for a few years and learnt a second language, the budding genius is firmly convinced that he is the Messiah of the programming world. He reinforces this world view with his conviction that anything he doesn’t understand (i.e. almost everything) is pointless, old-fashioned and a waste of time.
Distinguishing code features: Uses his own vector class implementation. Always starts class names with his own initial.
Mistaken belief: The programming world has more to learn from him than he does from it.
Most endearing quality: How easy it is to make him defensive and huffy by mentioning anything outside his cabbage patch of experience.
Reads: His own blog.
Most likely to say: “Huh, yeah well everyone knows functional languages are no use for *real* programming *anyhow*”
The Abstraction Freak
After a while all new programmers being to realize they start each new flash game by copying 90% of the old one. Suddenly it occurs to them that they could write one ‘super’ game engine to make writing a new game as simple as finding the sprites and writing a config file containing the rules! Flushed with this success, the wannabe abstraction freak begins to believe all programs should be generalized, generalized, generalized… unfortunately, holding on to this belief too long turns them into the Abstraction Freak.
Distinguishing code features: Adds five new classes every time he implements a new feature, all of which are named after design patterns and give no clue whatsoever as to the feature they’re supposed to implement. Any actual business logic is hidden in an xml-based config file somewhere else in the repository.
Mistaken belief: Writing a program to interpret a set of config files containing an awkwardly-phrased, buggy description of the program he wants to write is better than writing the program he wants to write.
Most endearing quality: The expression of painful concentration on his face while battling his analysis paralysis before starting to reimplement the login feature for the fourth time that month.
Reads: Design Patterns, cover to cover, during his lunch break every day.
Most likely to say: “So I think we should start the new time scheduling project by writing a generic application framework…”
Any programmer exposed to the bitter realities of working in a soulless commercial software company, shuffling bits on a hard disk for the same salary every month eventually develops a certain protective shell. Neither speed nor genius are rewarded, so often a professional developer begin to develop a very careful, measured style that ensures he’s never caught out by either bugs or management, which he considers to be pretty much the same thing.
Distinguishing code features: The first ten lines of any function, even an accessor, are all assert statements. All the error conditions for each function are dutifully checked and handled and comments are liberally scattered throughout.
Mistaken belief: Doing things ‘properly’ is the same as getting things done, but better.
Most endearing quality: His aura of measured, unflappable calm that makes it clear that even the direst emergency won’t make him work any faster, leaving one with the impression he might be better suited to a career in the bonsai industry.
Reads: joelonsoftware.com (yes, even though Joel’s stopped posting)
Most likely to say: “Well, I won’t be able to say until doing a proper estimate next week, but it’s going to be at least *sucks air in through pursed lips* at least four man-months to add a print preview, plus testing and documentation of course.”
After a decade or so of bouncing from one stereotype to the next, our newbie is all grown up, yet she feels like a hollow shell of the enthusiast she once was. One morning, she wakes up and realizes that the unwieldy crust of unit tests, assertions, error-checking and class-design that have built up around her programming style are just crutches, crutches that are dragging her down and that she no longer needs! She casts them off and begins writing the simplest, barest code she can think of to do what she needs! Free the features! Free the code! Freedom!
Distinguishing code features: Only writes in dynamically-typed languages with a strong functional component. At first glance her code looks remarkably similar to the newbie’s, except there’s less of it and the variable names make sense.
Mistaken belief: That her enlightenment makes her a guru without the quotation marks.
Most endearing quality: Her little shiver of excitement every time she sees an interesting problem she could solve with ‘just half a dozen lines’ of code.
Most likely to say: “You know, polymorphic inheritance is really just a poor-man’s substitute for first-class functions and dynamic typing…”
So there you have it, my career as a programmer laid bare. I’m curious; does everyone go through these phases?
If I’ve missed any great ones, add your own in the comments and I’ll either update the article or collect them for a Part II…
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!