The best way to kill and bury your crusty old PHP system – replatforming a legacy system without your users noticing.
Hearing those words makes me feel like I’m tied mutely to a railway track, unable to scream for help as a train thunders towards me. We humans are walking sacks of blood, bile and bias, and estimating how long things will take brings out the worst in us.
A product manager recently asked me if one can get better at knowing whether things are easy or hard, and how long they will take. The good news is that with practice, you can help people estimate much better with your help than they would on their own.
Understand the problem you’re trying to solve.
If you don’t understand the problem well enough, you’re certainly blind to its potential complexities. Product managers are often in a *better* position than anyone else!
Understand what’s involved in the proposed solution(s).
This can be the trickiest part for non-engineers, because the details of the solution may sometimes be pretty arcane. Here’s what you can do:
- You can go a long way by asking good questions about how things work, and what’s involved in the solution. Listen carefully to the answers. If they don’t make sense, ask for a higher-level explanation, or from a different person. Explain it back – that will make sure you’ve got it right and help you internalise it. Take good notes. Over time, you’ll start to see how the pieces interconnect, and what problems are similar to one another, and this will get easier and easier.
- Don’t ask for an estimate for the whole solution. Break the solution down into pieces, estimate the size of each piece, and add them back together. In my experience, people can’t reliably estimate how long things will take beyond a few hours – so if the estimates are much bigger than this, break the pieces down into smaller and smaller chunks.
- Be the rubber duck!
- Offer to pair-program with a developer during the unit testing. You’ll get a really deep understanding of how the system works, and where the difficulties lie. Better still, if you write your tests before writing your code, your test suite provides a kind of score card for how close you are to a solution, and you’ll reduce time spent in QA.
Be aware and on the alert for pitfalls and cognitive biases that lead to poor estimations.
Human beings tend to be lazy about thinking through all the pieces for a complete solution (just focusing on the major parts, or the interesting parts, and ignoring the detail or the final 20% to make things perfect that takes all the time). They also tend to focus on the best case (if everything goes right) and ignore all the things that might go wrong. You never know what will go wrong, but if you have a sense of some possible pitfalls, you can factor them into your estimate. Possible approaches:
- Start by asking out loud ‘what are the hidden traps, complications, edge cases, difficulties or things that could go wrong. When we did similar things in the past, how long did it end up taking? Were there surprise pitfalls that made it harder than we anticipated?’ Or run a premortem. You’ll get much better estimates after this discussion.
- Use Planning Poker as an estimation approach. Each person makes an estimate in isolation – this forces them to think things through, and avoids estimates being dominated by what was said first or most loudly. The discussion afterwards creates an informed consensus view, and provides immediate feedback for people whose estimates are wildly off.
- As a last resort: make an optimistic estimate and double it.
Learn from feedback.
- Force yourself (or the project team) to make an estimate in advance, then during the project retrospective, compare the actual time taken to the estimated time. That would be the best way for everyone to learn from feedback! ‘We thought it was going to be X, but it turned out to be 2X’.
- If things take much longer than anticipated, ask how we could have predicted this in advance. That might help you avoid similar estimation mistakes in future.
- Notice if certain kinds of tasks tend to take longer than anticipated.
- Notice if certain people tend to be inaccurate, and give them feedback on this.
Abe Gong asked for good examples of ‘data sidekicks‘.
I still haven’t got the hang of distilling complex thoughts into 140 characters, and so I was worried my reply might have been compressed into cryptic nonsense.
Here’s what I was trying to say:
Let’s say you’re trying to do a difficult classification on a dataset that has had a lot of preprocessing/transformation, like fMRI brain data. There are a million reasons why things could be going wrong.
Things could be failing for meaningful reasons, e.g.:
- the brain doesn’t work the way you think, so you’re analysing the wrong brain regions or representing things in a different way
- there’s signal there but it’s represented at a finer-grained resolution than you can measure.
But the most likely explanation is that you screwed up your preprocessing (mis-imported the data, mis-aligned the labels, mixed up the X-Y-Z dimensions etc).
If you can’t classify someone staring at a blank screen vs a screen with something on it, it’s probably something like this, since visual input is pretty much the strongest and most wide-spread signal in the brain – your whole posterior cortex lights up in response to high-salience images (like faces and places).
In the time I spent writing this, Abe had already figured out what I meant :)
Have you ever had trouble deciding where to store a file on your hard disk? Or worse, had trouble finding it later?
When you store a file on your hard disk, you have to decide which folder to put it in. That folder can in turn live inside other folders. This results in a hierarchy, known in computer science as a *tree*.
The main problem with trees is that sometimes you want things to live in multiple places.
Tagging provides an alternate system. Tags are a lot like folders, except that things can belong to multiple tags. However, but the tags can’t themselves belong to anything. So you have just one level of organisation with no nesting.
The main problem with single-level tagging is that it’s too simple. We want to be able to use fine-grained categories (e.g. ‘lesser spotted greeb’) that themselves belong to higher-level categories (e.g. ‘greeb’, or even ‘bird’ or ‘animal’). But we said that tags can’t themselves belong to tags.
Described like this, perhaps the solution will seem obvious to you too. We want things to belong to multiple tags, and for those tags to sometimes belong to other tags.
I built this into Emacs Freex, my note-taking system.
For instance, I have tagged this blog post with ‘data structure’ and ‘blogme’. In turn ‘data structure’ is tagged with ‘computer science’ and ‘blogme’ is tagged with ‘writing’. So I can find this blog post later in various ways, including by intersecting ‘computer science’ and ‘writing’.
This gives you the best of both worlds: things belong to multiple categories, along with a hierarchy of categories.
When it comes to tools, I am a hedgehog rather than a fox. I like to have a small number of tools, and to know them well.
I recently resolved to start writing again. But I decided that I needed to sharpen my pencils first.
I have plans on how publishing and sharing should work. Grand plans. Too grand, perhaps.
So for now, I wrote something simple for myself. Now I can type away, press buttons… publish.
If you like Emacs, Python and WordPress, this might be interesting to you too. If not, it certainly won’t be.
Most of the work is being done by this great Python/Wordpress library. Thank you.
I wrote some simple Python scripts. One grabs all my existing blog posts. One looks through their titles, and checks them against the filename to see if this is a new post.
And then there’s a very simple Emacs function that calls them to save/publish the current text file.
I could add more things: deleting posts, or a proper workflow for moving from draft to published. Maybe later.
I wrote this post, then hit M-x wordpress-publish-this-file.
Someone asked me recently about getting their own domain name and setting up a website. I’m not very good at this stuff, but I have been through it once or twice, so I thought I’d at least offer this up in case it’s useful.
Let’s say you want to buy example.com, and set it up as a series of static informational pages about Example Business Inc, along with @example.com email addresses. There are (at least) 3 ways you can go:
1) the standard method
– Grab the domain from GoDaddy (or any other domain name registrar – they all do basically the same thing). It’ll cost you $10-20 for a year or two
– Then you need to find a place to host your site (e.g. Rackspace, Dreamhost). You’d spend c. $10/month to rent space on a server, point your new domain name to the server’s IP address, write and upload some html and images, and away you go.
– You then need to set up email addresses. If it’s GoDaddy, I think you’ll be able to set it up to forward your email to an existing account without too much trouble.
– This is what i had to do with Memrise because I wanted control over everything. Honestly, it was much much more complicated than i had anticipated to figure it all out.
option 2) use Google
– Use Google to register your domain name
– I think that’ll automatically set you up with Google Apps (custom Gmail, Calendar, Sites, Blogger, Docs etc.) for free.
– Then you can set up the design and content of the pages of your website with Google Sites.
– So then you’d all use a custom Gmail interface to check your @example.com address, and have access to blog.example.com, calendar.example.com etc. I’m a big fan of Google Apps.
option 3) Weebly (or some equivalent competitor)
– Besides Google, there are a variety of companies that help build a site. I’ve heard good things about Weebly, but haven’t closely investigated it for myself.
– Much like Google Sites, it looks like they’ll do most of what you’d want: help with design templates, deal with the hosting, potentially help with domain names, and a bunch of other stuff. Nice!
– As long as your needs are simple, I would consider the Google/Weebly approach, since I think it’ll be the most straightforward.
– Down the line, if you decide that you want to build something more complicated and interactive, you can always hire a programmer and switch from Google/Weebly to your own hosting set up.
– If you have someone to help who enjoys techie stuff or has set up their own site before, then setting things up with GoDaddy and your own hosting will probably go smoothly. But otherwise, a company like Google or Weebly that’ll do 90% of the work for you, so you can focus on building a great site :)
Reading the 5-page staged and glossy magazine interview in a hotel room with a famous actor has always filled me with a peculiar kind of existential dread. There’s something a little horrifying about an hour of conversation in cold type, bereft of the intonation, expression, context and rapport that make anything one says out loud bearable. And at the end of it all, to be distilled, distorted, interpreted and weighed by the pen of a stranger… Who could have the strength of character to read about but not become their own caricature?
In contrast, the last page of the Sunday Times magazine features ‘a life in the day of’ a happy array of personalities and professions. I like the concreteness of a single day as a window into someone else’s micro challenges and achievements. I realize that these days are probably fictionalized composites – but fiction makes for a sweet, concentrated and memorable pill. And at the end of it, there is no distillation, no weighing – just the reality of a daily rhythm.
When I am famous, I will decline interviews.
P.S. That said, I still remember being stopped in my tracks when a fashion photographer relative asked me sweetly ‘what did you today?’ in the midst of my PhD. My day had consisted of:
- 2 hours debugging a misplaced comma
- so that I could finish the 3-day long project of rearchitecting my non-parametric statistics to work across-subjects
- in order to get a better sense of whether results from the latest in a long line of experiments were actually better than chance
- so that we could tell whether reminding people and distracting them at the same time was causing them to forget
- to test our computational theory that half-remembering a memory actually weakens it
- which would have deep implications for our understanding how the brain learns and self-organizes
But really, I’d been comma-hunting, and it seemed hard to fit that into a the kind of response usually expected from ‘what did you do today?’.