Yield Thought Has Moved
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?
- I really need to be able to use javascript here. Gists, analytics, everything worth having uses javascript.
- 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!
Discipline: Be The Machine
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!
Make Exceptions
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.
But, seriously
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!
Criminal Overengineering
As programmers we’re continually accused of doing a sloppy job. There are countless programs in the wild, crashing, locking up and accidentally writing “I am a fish” a million times over someone’s mid-term essay. The effect? Something like this:
This damn computer and excel r fuckin my life up! Hatin life right now
— MissAlauren (and everyone else at one time or another)
It’s experiences like this that cause people to rant about Microsoft and curse the anonymous programmers who suddenly (yet inevitably) betrayed them. We all know this; it’s burned into our very souls by countless hours of tech support provided to family and friends. Time after time we see that programmers who do quick, sloppy work make other people suffer. And so we try, we try so damn hard not to be like that. We try to be the good programmer who checks every return value and handles every exception.
If we stopped at competent error handling and sufficient testing, all would be well. In truth, we actually go too far and, it has to be said, largely in the wrong direction.
A vast proportion of software at work today is horribly over-engineered for its task. And I’m not talking about the interfaces, about having too many controls or options for the users. These are, indeed, terrible sins but they are the visible ones. The worst of the overengineering goes on under the surface, in the code itself.
You’re Doing It Wrong
Have you ever seen someone using the strategy pattern when they should’ve used a 5 line switch statement? There are a million ways to turn something like this:
switch(operation)
{
case OP_ADD: return a + b;
case OP_SUBTRACT: return a - b;
case OP_MULTIPLY: return a * b;
default: throw new UnknownOperationException(operation, a, b);
}
… into a hideous, malformed mutant beast like this one, which I haven’t inlined because it’s far too long.
The most insidious cause of overengineering is over-generalizing. We will over-generalize anything given half a chance. Writing code to work with a list of students? Well, we might want to work with teachers and the general public someday, better add a base People class and subclass Student from that. Or Person and then EducationPerson and then Student. Yes, that’s better, right?
Only, now we have three classes to maintain each with their own virtual methods and interfaces and probably split across three different files plus the one we were working in when a one-line dictionary would have been fine.
Perhaps we do it because it’s relaxing to rattle off three classes worth of code without needing to pause and think. It feels productive. It looks solid, bulletproof, professional. We look back on it with a comforting little glow of self-satisfaction – we’re a good programmer, no messy hacks in our code.
Except, this doesn’t make us good programmers. Overengineering like this isn’t making anyone’s lives better; it’s just making our code longer, more difficult to read and work with and more likely to contain or develop bugs. We just made the world a slightly worse place. It lies somewhere between tossing an empty drinks bottle on the street and grand theft auto.
The extra effort caused by our overengineering carries a hefty opportunity cost:
- Less time spent refining the user experience
- Less time spent thinking about the meaningful implications of the feature we’re working on
- Less time available to look for bugs and – with harder-to-read code – more time spent debugging them
Yes, by overengineering the Student class you indirectly ruined MissAlauren’s day.
We have to stop championing each ridiculous feat of overengineering and call it what it is. It’s not ‘future-proof’, because we can’t see the future. It’s not robust, it’s hard to read. Applying a generic solution to a single case isn’t good programming, it’s criminal overengineering because like it or not somebody, somewhere will pay for it.
Don’t Worry, Be Happy
I suspect all the best programmers have already realized this, but they’re not shouting about it loudly enough for everyone else to hear. Paul Graham is completely right when he suggests that succinctness is valuable:
Use the length of the program as an approximation for how much work it is to write. Not the length in characters, of course, but the length in distinct syntactic elements– basically, the size of the parse tree. It may not be quite true that the shortest program is the least work to write, but it’s close enough… look at a program and ask, is there any way to write this that’s shorter?
— Paul Graham, The Hundred Year Language
He’s actually talking about language design here; indeed, in Succinctness is Power he’s careful to note that it’s clearly possible to write a program that’s too succinct. This is because, these days, Paul Graham is more a language designer than a working programmer. Otherwise he might have said:
If you’re about to take a hundred lines to write what you could in ten, stop and ask yourself this: what the fuck?
— Mark, Criminal Overengineering
When I feel tempted to over-generalize or over-engineer a bit of code, it’s often because of fear. Fear that someone will find a really good reason I shouldn’t have done it the easy way. Fear that I’ll have to rewrite the code again. Fear of finding myself on the wrong side of an argument about the merits of the visitor pattern. But fear does not naturally lead us to the most elegant solutions.
Next time you feel the compulsion to write a nice, general solution to a simple case, stop and ask yourself what’s stopping you just writing it the simple, specific, succinct way:
- Am I worried I’ll have to rewrite it?
- Am I worried someone will criticize it or that I’ll look bad?
- Am I worried that it’s not professional enough?
Are any of these true? Then relax. Don’t worry. You worry, you call me, I make you happy.
Just write the code the simple, specific way and then add a short comment, something like: Replace with the Strategy pattern if this gets any bigger.
This is the perfect solution. It’s a great reminder to you next time you come here about what you wanted to do. It shows other programmers on your team that you considered the ‘correct’ way to do it and have a good reason not to do it just yet. It’s very hard to argue with a comment like that, because you’re not arguing about the strategy pattern vs the switch statement, you’re arguing about whether to use the strategy pattern after 3 cases or after 4 cases – not a discussion that can reflect badly on you, in any case.
A few months later you can go back and look at how many of your comments eventually turn into more complicated, engineering code. I’ll bet you it’s not very many. That’s how much time and effort you’ve saved, right there. That’s setting yourself free to pursue the solution and that’s making the world a slightly better place.
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
Is That All?
Note: This post isn’t about the iPad. It’s about me and you, our bosses and most of all it’s about normal people. It just starts with a story about the iPad, because that’s the way it happened.
What did Yahoo’s bosses say when they saw Google’s homepage for the first time? Why are 37signals so militant about saying ‘no’ to extra features? What did the Apple engineers think when Jobs told then to make a phone with one button?
Last weekend I spent twenty minutes playing with an iPad on a stand in an airport. I opened Safari and read xkcd, Penny Arcade and Hacker News. I flicked through the pictures of some sunkissed holiday by the sea. I played a couple of not very good games. I wrote a short document. I watched a video. At the end of twenty minutes I wandered away feeling slightly uneasy, thinking:
Is that all?
— Me
As a programmer, I’m comforted by screens full of settings. When playing a new game the first thing I do is find the options and tweak the hell out of it before I’ve even played a single level. The iPad left me feeling somehow uncomfortable, as if I was missing some core element. Had I really seen all it could do?
That was when I saw it: in a handful of minutes on completely unfamiliar hardware and software (no, I don’t have an iPhone), with an unusual multitouch interface I’d just ‘done’ things without having to think about them, without having to learn anything, without having to struggle. The gap between wanting to do something and doing it was so short that, for twenty minutes, it ceased to exist.
Don’t worry, we’re almost at the end of the iPad bit.
I was asking myself what the iPad could do. The iPad wasn’t doing anything – it was letting me do what I wanted. It had been designed by people who loved me more than their product (as Gandhi says you should). Was that all? Yes, because playing around for twenty minutes was all I wanted to do.
The user interface should be like a soundtrack barely noticed by the user
— Steve Capps
Everything we create should aspire to this, should leave us – as programmers – wondering if that’s all and if we shouldn’t perhaps add a bit more. Scott Berkun (a genius and a craftsman) said all of this more than ten years ago and I’ve known about it for at least half that time, but it hasn’t really changed the way I write software because it’s too hard to just know when something’s simple enough.
The feeling of ‘is that all?’, however, the uncomfortable suspicion that I can’t really ship a product with just one button, that all the important companies have login screens – this feeling proves we are on the right track. It is an excellent guide. Our world is full of self-indulgent interfaces clamoring for our attention. Why should we keep making this worse? We have to be brutal with our interfaces. Strip everything out. Consider every single piece of text as being a waste of the user’s time reading it, every control an unnecessary, unpleasant intrusion.
The user’s attention is a limited resource and we should heavily optimize to minimize our impact upon it. We must always, always remember that nobody wants to use our software – they want to finish their work and go play outside.
It’s hard. It’s risky. It’s easy to defend a new dialog as full of buttons as the old one. Our colleagues and managers live in bizarro world, believing our software has value independent of the things it helps people to achieve. They don’t want the new startup screen to have just 10% of the controls of the old one.
That’s not progress! Progress means more! Deleting things isn’t doing work! It’s anti-work!
— A stupid person near you (or, possibly, you yourself)
I’ve felt this, even if I haven’t said it. There’s this massive tension between writing something to humbly serve people you’ve never met and may never meet, and writing something your boss and colleagues will approve of. Yet we have to try, because the way software has been written for the last twenty years is making people unhappy.
Our calling, our duty, is to write software that will make our colleagues, bosses and competitors scoff and say “Is that all?” while making the lives and work of real people simpler, easier and less stressful. Our customers will love us for it – we just need the courage cut and hack and tear down everything that’s not necessary to get their work done and to put it out there for them to use.
Postscript: What am I doing about this? My startup, CodeChart, is making profiling very simple and very beautiful; the old generation of tools are so ridiculously overcomplicated that most people never use them. It’s in closed beta at the moment, but have a look at our getting started guide to see how it works and feel free to sign up for the beta if you’ve got some .NET code you want to look at. I know, I know, other languages – including my beloved python – are coming later!
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
A Song Is Worth 1093 Words
Natural programmer. Ended up a rock star. Pity.
If someone had sent me this earlier in the week I could’ve saved us all 1093 words. Much love to Craig Lyons and some random youtuber for the developer anthem of the week.
Don’t stop listening until you’ve heard my personal message around 1:44 😉 In fact, it keeps on getting better!
If anyone makes a nice cut summarizing the software development sections (or just a loop ending at 1:16) send me a link!
Anyone know of any more songs secretly about programming and startups out there?
Start In The Middle
I start in the middle of a sentence and move both directions at once.
— John Coltrane
Newspaper reporters are taught to write fractal articles: summarize the entire article in the title. Elaborate a little in the first sentence, then fill out the most important details in the first paragraph. A reader should be able to stop at any point without having missed any important details. We should approach programming projects in the same way.
As a child – after some experimentation and a lot of thought – I decided the best way to eat cornflakes was as follows:
Cornflakes, by Mike Haufe
- Pour the cool milk over the golden roasted flakes
- Sprinkle the one allowed teaspoon of sugar over the top
- Start eating around the edges, saving the sugary middle section for one last big spoonful of joy at the end
I stand by that decision. In fact, I’ve noticed I do similar things in other areas of my life. I’m sure a psychologist would talk for hours on the subject. Luckily for you I’m not a psychologist, I’m a programmer. And it turns out that this is an awful way to work on software projects.
Has this ever happened to you? You wake up one day with a great new idea for applying bayesian filtering to twitter streams to filter out the pictures of Joel’s new puppy spam. You’re totally convinced it’s what the world needs. It’s the startup that’s finally going to help you to break out of your day job maintaining PHP payroll software stock supermarket shelf stockers. So what do you do? You do this:
- Fire up your IDE and start a new website project
- Whip up a login page and get the user account basics set up
- Decide OpenID’s really where it’s at these days and hit stackoverflow for a good OpenID provider plugin
- Run into problems getting it to accept Google accounts and spend half the night debugging it
Wait, what? How did this happen? Getting OpenID working isn’t fun. It’s almost the definition of not fun.
I didn’t want to do all this, I just wanted to make an awesome bayesian twitter filter, but somehow there’s all this stuff I have to get through first.
— Me (swear words redacted)
My hard disk is littered with projects that I started, got half way through setting up without ever really getting to the good bit, then abandoned. I suspect yours is, too.
The right way to start a bayesian twitter filter is to apply a bayesian filter to content from a twitter stream. I know. It looks like this:
- Google for some bayesian filter code
- Dump whatever’s in your twitter client logs to a file and write three lines of python to parse it into a form the bayesian filter can work with
- Train the filter and see what happens
Compared to the original approach it looks awesome, right? So what stops us approaching all projects like this? Well, there’s something beguiling about wanting to get the framework right from the start this time. It’s more comfortable starting with something we already know how to solve. Sometimes we have a clear vision of how it should end up in our heads and simply start to create that vision from the beginning through to the end.
Start in the middle
— Paul Graham (lightly paraphrased)
Lean startups and the Minimum Viable Product are all about starting in the middle. Paul Graham’s advice for startups can be summed up as ‘first solve the interesting part of the problem, then build the business around it’, but the process is also fractal – starting in the middle applies right down to the level of writing a new class, or a single function. First write some code that solves the problem even if it’s imperfect or partial, then expand it out with your favourite blend of accessors, inheritance and polymorphism (Note: don’t even bother with that bit unless you hate yourself).
I’ve seen four key benefits to starting in the middle:
Benefit 1: Ideas that turn out to be impossible or just plain bad are discovered early. This is classic lean startup advice: fail early.
Benefit 2: Spend most of your the time solving interesting problems and not fine-tuning framework skills. Which would you rather get better at?
Benefit 3: Discover interesting things while your project is still young and flexible enough to adapt to them.
Benefit 4: Once you’ve solved a problem, you’re so motivated to use it that you finish up the surrounding areas in no time. You add extra users because you want to show it to your friends; you add keyboard shortcuts because you’re getting tired of using the mouse all the time. This is programming the right way around – first the need, the desire, and then the solution.
I’ve recently seen all of these benefits while working on my own side-project-turned-startup. Ages ago I had this great little idea for making profiling so simple that it just told you which line of code was slowest in a nice little report and I whipped up some C# code to do just that. The results weren’t making much sense, so I tried plotting the data to a canvas to see what was going on. Pretty soon I was looking at a poor man’s sketch of this:
Visualizing a program's execution
Instantly I knew I’d been working on the wrong thing; seeing the execution of a program laid out before me in all its glory was so rich and so interesting; something I had no hope of summarizing in a small table of figures. I just had to explore it – I added function names, colour, a breakdown of time spent in each and over time it grew into such a valuable part of my toolkit that I’ve started sharing it with the rest of the world.
Would I have changed direction if I had already created a website, a login system, a messaging layer, a database schema all geared around the original idea? No. I’d have reached the interesting part of the problem with a half-finished framework and close to zero energy and enthusiasm. The discouragement at seeing the futility of my cherished profiling-via-pdf idea would’ve seen me put the whole thing back on the shelf and go play Altitude to forget about it.
So start in the middle, start with the interesting, challenging, core of the problem you’re trying to solve. Cut down everything else to ridiculous minima and see what happens; you may create something fascinating.
Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!
Chicken Little and 3.3.1’s Great Big Loophole
I thought someone else would say this, but either they haven’t or they didn’t say it loud enough and now I can’t take the waiting any more, so here goes:
Oh noes, my pythons iz banned!
On April 8th, Apple added some onerous conditions to section 3.3.1 of their iPhone Developer Agreement, explicitly prohibiting interpreters, translation layers and cross-platform toolkits from the Apple Store. It set off a wave of discussion that still echoes around to this day, and it pretty much killed Flash dead.
Much as I hate Flash, that’s not what I want to talk about. I want to talk about the reaction from most of the programming community:
The sky is falling, the sky is falling!
— Pretty much everyone
Some bloggers even complained that kids wouldn’t be able to grow up learning how to program in Apple’s Brave New World. What?
You can write in any language you want so long as it compiles to Javascript and runs in the browser, or runs on a server somewhere online
— The oddly-overlooked truth
Local applications are already dead. Whether they’re on the desktop or on the phone, their days are numbered. The resurgence in phone apps for the iPhone / iPad is a temporary blip. The future is in the cloud, in the browser and on servers.
Where will kids learn to program in Apple’s new world? On programming sites, interpreting their code in the browser, pulling in web services they way you and I learned to pull in local APIs. You don’t like Javascript? Don’t worry – You have options and they’re only going to keep getting better. Suddenly Bespin doesn’t look so dumb any more, does it? Mix in Github and free online hosting services like Google App Engine and you can see the parts are already assembling.
In fact, with 3.3.1 Apple has shot itself in the foot by ensuring that all the best developers are going to work extra hard to get their applications running in the browser; a bit of a home goal for iAd and a gift to Google – and the rest of us. After all, web apps are fundamentally easier to develop and support.
So here’s to Apple’s 3.3.1 clause and all its consequences: Thanks, Steve!
Looking for Beta Testers
My startup – codechart – has recently started looking for beta testers.
I haven’t said much about the startup here, but our thinking is as follows: developers deserve just as much love as everyone else, yet typical development tools are awful, or at best bearable once you’ve learned how to use them. We want to change that, starting with a profiler that actually makes sense. We’re prioritizing .NET first, with other platforms (such as my beloved python) to follow.
So if you work or play in .NET and want to help us find out how we can love you and not our code then go sign up and we’ll set you up with an account and explain what it’s all about in the next week or so!
yield thought 
You must be logged in to post a comment.