Peter Nixey

I'm Peter, a Rails developer and entrepreneur. I'm an ex-computer vision researcher, the former CEO of Clickpass and a YC alum. I have built and sold a lot of different software and am now the CTO of - which lets you quickly create stunning sales pitches

How to be a great software developer

Disclaimer: This is a very long piece, much longer than I would normally write on any subject. I have edited it back but on sending it to friends to read they agreed that there was no one bit that should be cut. I hope that you feel the same.

If there’s one thing that software developers care about, it’s becoming even better software developers. Where do you start though? Should you accumulate the bells and whistles: deepen your knowledge of Node and no-sequel? Should you rote-learn the answers to the profession’s gateway questions and be able to produce bubble sort or link shortener algorithms on demand? Or are there perhaps more fundamental roots that you can put down?

I believe that your seniority and value as a programmer is measured not in what you know, it’s measured in what you put out. The two are related but definitely not the same. Your value is in how you move your project forward and how you empower your team to do the same. In fifteen years of programming I’ve never had to implement a bubble sort or a link shortener. However I have had to spend thousands and thousands of hours writing and refactoring account management tools, editing suites, caching logic, mailing interfaces, test suites, deployment scripts, javascript layers, analytics architecture and documentation. These were the things that mattered, the completion of these were what moved us forward.

Those humble components are the bricks and mortar of projects and take hundreds or thousands of hours of hard work to assemble. And even though they combine to form complex systems, they themselves should not be complicated. You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”.

Simplicity and excellence are most reliably attained by starting with something, anything, that gets the job done and reworking back from that point. We know this is true of companies and the concept of the MVP is burned deep into our consciousness. So too with software. Start with something ugly but functional and then apply and reapply yourself to that ugly and misshapen solution and refactor it back into its simplest form. Simplicity comes far more reliably from work than from brilliance. It comes more predictably from code written, than from thought expended. It comes from effort.

It is all too easy for smart lazy people to flash spikes of brilliance and wow their contemporaries but companies are not built on those people and product does not sit well on spikes. Companies are built on people and teams who day in, day out, commit good code that enables others do the same. Great product is built by work horses, not dressage horses.

Years after Joel coined the term “Rockstar Programmer”, it lives on along with the misapprehension that companies need such geeky micro-celebrities in order to do anything. While those characters do exist there aren’t many of them. When you do find them they’re often erratically brilliant - astonishing at the things that interest them but hopeless at working consistently or smoothly with their team.

Not only is their output erratic but their superiority is aspirational and infectious. Their arrogance bleeds toxically into the rest of the team. It signals loud and clear that if you’re smart enough you choose when you work and what you work on. You become a “Developer in Residence”. And you not only soak up a salary but you distort the values of those who work around you.

So the reality is that in all likelihood you and your team will depend, should depend not on those who think they are “Rockstars” or “Ninjas” but on reliable people who work in reliable ways.

Great developers are not people who can produce bubble sorts or link shorteners on demand. They are the people who when you harness them up to a project, never stop moving and inspire everyone around them to do the same. Fuck Rockstars. Hire workhorses. Here’s some ways to become one:

Name your functions and variables well (write Ronseal Code)

Such an incredibly simple place to start and yet I think it is one of THE most important skills in programming. Function naming is the manifestation of problem definition which is frankly the hardest part of programming.

Names are the boundary conditions on your code. Names are what you should be solving for.

If you name correctly and then solve for that boundary conditions that that name creates you will almost inevitably be left with highly functional code.

Consider the function:

It tells someone almost nothing abo

ut what it’s going to do or how it’s been implemented in the code. However:

tells someone exactly what’s going to happen. It’s also a good indicator as to what’s not going to happen. It tells you both what you can expect the method to do but also how far you can overload that method.

A developer might happily refactor “process_text” to not only convert text to HTML but to auto-embed videos. However that may be resolutely not what was expected in some of the places that function was used. Change it and you’ve created bugs. A good clear name is a commitment to not just what a function does but also what it won’t do.

A good function promises what it will deliver and then delivers it. Good function and variable naming makes code more readable and tightens the thousands of contracts which criss-cross your codebase. Sloppy naming means sloppy contracts, bugs, and even sloppier contracts built on top of them.

It’s not just functions that you can leverage to describe your code. Your variable names should also be strong. Sometimes it can even be worth creating a variable simply in order document the logic itself.

Consider the line:

It’s pretty hard to figure out what the hell is happening there and even once you have done so, it’s not 100% clear what the original author was trying to achieve with it. The variable names are horrible and tell you nothing.

The “and not” statement is always confusing to read (please never write “and not” clauses which end with a noun) and if your job was to refactor this code you’d have to do some acrobatics to guess exactly what the original intent was.

However, if we change the variables names into something more meaningful then things immediately start to become clearer:

We can go further still and forcibly document the intent of each part of the if statement by separating and naming the components:

It takes some courage to write a line like “user_is_recently_created” because it’s such fuzzy logic but we all do it at times and owning up to that helps inform the reader about the assumptions you’ve made.

Notice also how much stronger this approach is than using comments. If you change the logic there is immediate pressure on you to change the variable names. Not so with comments. I agree with DHH, comments are dangerous and tend to rot - much better to write self-documenting code.

The better code describes itself, the more likely someone will implement it the way it was intended and the better their code will be. Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors.

Go deep before you go wide - learn your chosen stack inside out

Very few programming problems are genuinely new. Very few companies are doing technical work that hasn’t already been done by 50 teams before them. Very few problems attract Stack Overflow eyeballs that haven’t already seen them somewhere else before.

For that exact reason, the majority of the things you are trying to do have already been solved by the very stack you’re already using. I once refactored 60 lines of someone else’s Rails code to a one line using the delightfully simple and powerful methods that Rails ships with.

Not only do they waste time but they create verbosity and errors. Their code requires new documentation to describe it, new tests to monitor it and it makes the page noisier and harder to read. Like any new code, it’s also buggy. War-tested (and actually-tested) stack code is very seldom buggy.

If you are a Ruby developer take time to learn Ruby, especially the incredible range of array methods. If you are a Node developer take time to understand the architecture, the methods and the mindset of Node, if you are an Angular developer go right up to the rock-face and understand the logic behind of the incredible architecture the core team is forging there right now. Ask before you invent. You are walking in the shadows of giants. Take time to find their tracks and then marvel at how beautifully they have been built. Because if you don’t, you simply punt the problem downstream and someone will just have to figure out why the hell you chose the sub-standard path you did.

Learn to detect the smell of bad code

Something I’ve noticed in programmers who are good but who have plateaued is that they simply don’t realise that their code could be better. That is one of the worst things that can happen to your personal development. You need to know what has to improve before you can figure out how to improve it. Learn both what good code looks like and what bad code looks like. It is said that grand chessmasters spend proportionally much more time studying previous other good chess player’s games than the average players. I’m quite certain that the same is true for top developers.

An important part of your improvement arsenal is your ability to detect bad code - even when it’s only slightly bad or perhaps “a bit smelly”. Smelly code is code which, while you can’t quite articulate why, just doesn’t feel right.

It may be that you’ve used 60 lines of code for something which feels fundamentally simpler, it might be something which feels like it should be handled by the language but has been manually implemented instead, it might just be code that is as complicated as hell to read. These are your code smells.

It’s not an easy thing to do but over the years you should learn what bad code smells like and also what beautiful code looks like. You should develop an aesthetic appreciation for code. Physicists and mathematicians understand this. They feel very uneasy about an ugly theory based on its ugliness. Simplicity is beautiful and simplicity is what we want.

The truth is that the truth is sometimes ugly but you should always strive for beauty and when ugly is the only way, know how to present it well. If you can’t create beautiful code, at least create Shrek code but before you do either you need to develop your sense of smell. If you don’t know what good code looks like and know what bad code smells like then why would you ever improve it?

Write code to be read

I once heard Joel Spolsky say that Stack Exchange optimises not for the person asking questions but for the person reading the answers. Why? Because there are far more of them than the single person who asks the question - utility is maximised by optimising for readers, not questioners.

I think you can view code in a similar way. It will be written just once by you and you alone. However it will be read and edited many many times, by many others. Your code has two functions: the first is its immediate job. The second is to get out of the way of everyone who comes after you and it should therefore always be optimised for readability and resilience.

What assumptions have you made, what do your methods actually return, what on earth does that quadruple nested if / else / and not / unless, statement actually select for? Sometimes you’ll need more than just good variable naming and you should ring fence it with tests but do what it takes (and only just what it takes) to make it durable. Great code is code that does its job and that continues to do its job even when git blame returns a who’s who of your company payroll.

Write every line to be read through the eyes of a disinterested and time-pressured team mate needing to extend it in a year’s time. Remember that that disinterested and pressured team mate may be you.

Weigh features on their lifetime cost, not their implementation cost

New developers want to explore and to play. They love the latest shiniest things and whether they’re no-sequel databases or high concurrency mobile servers and they want to unwrap all the toys as fast as possible, run out of the room to play with them and leave the mess for the next dev to clear up.

Features and architecture choices have maintenance costs that affect everything you ever build on top of them. Abstractions leak and the deeper you bury badly insulated abstractions the more things will get stained or poisoned when they leak through.

Experimental architecture and shiny features should be embarked on very carefully and only for very good reasons. Build the features you need before the features you want and be VERY careful about architecture. Save toys for side projects. Every component you invent, every piece of bleeding edge, fast changing software you incorporate will bleed and break directly into your project. If you don’t want to spend the latter stages of the project doing nothing but mopping up blood then don’t use it in the first place.

Or, as a friend once tweeted

Understand the liability AND the leverage of Technical Debt

Technical debt is the code you write which, while sub-optimal, gets you to where you need to go. It’s the errors which, while annoying, are still sub-critical. It’s the complexity of a single-app architecture when you know that the future lies in service-orientation, it’s the twenty-minute cron job which could be refactored to twenty seconds.

The cost of these these not only adds up but it compounds. Einstein once said that “there is no force so powerful in the universe as compound interest”. Equally there is no force more destructive in a large software project as compounding technical debt. Most of us have seen (or built) these projects. Codebases where even the smallest change takes months of time. Codebases where people have lost the will to write good code and hope only to get in and get back out without bringing the site down.

Technical debt is an awful burden on a project.

Except when it’s not.

Not only that but technical debt is the best type of debt in the world because you don’t always have to pay it back. When you build out a feature that turns out to be wrong, when you build out a product which turns out not to work, you will drop it and move on. You will also drop every optimisation, every test and every refactoring you ever you wrote for that feature. So if you don’t absolutely need them; don’t write them. This is the time to maximise your leverage, leave gaps, ignore errors, test only what you need to test.

In the early stages of a product or a feature, the likelihood is that what you are building is wrong. You are in an exploratory phase. You will pivot both on product and on technical implementation. This is the time to borrow heavily on technical debt. This is not the time to fix those sporadic errors or to do massive refactorings. This is the time to run through with guns blazing and keep firing till you burst out the other side.

When that happens though; when you’re sure that you’re in the right place and out the other side then it’s time to tidy up and to strengthen your position. Get things in good enough shape to keep on rolling, repay enough of the debt to get you on to the next stage.

Technical debt is like so many other things in a startup, a game of leapfrog. Your initial code is scouting code. It should move you forward fast, illuminate the problem and the solution and give you just enough space to build camp. The longer you stay, the more of the system that camp has to support the bigger and stronger you build it. If you’re only ever staying for a week though, don’t burn time laying down infrastructure to support a decade.

Check and re-check your code. Your problems are yours to fix

Engineers who “throw code over the fence” are awful engineers. You should make sure your code works. It’s not the testers’ job and it’s not your team-mates’ job. It’s your job. Lazily written code slows you down, increases cycle times, releases bugs and pisses everyone off.

Don’t kid yourself that you’re anything less than a burden and get it fixed.

Do actual work for at least (only) four hours every day For all the talk about self optimisation, focus and life hacking that goes on amongst developers, the simple truth is that you don’t need to do that much work to be effective. What really matters is that you do it consistently. Do proper work for at least four solid hours each day, every day and you will be one the best contributing members of your team.

However, doing four hours of work every day is harder than it seems.

Proper work is work that includes no email, no hacker news, no meetings, no dicking around. It means staying focussed for at least 45 minutes at a time. Four hours of work a day means that one day lost in meetings or on long lunches and foosball breaks means you have do eight hours the next one. Believe you me, eight hours of solid work is almost impossible. Four hours a day on average also means you should be aiming for five or six in order to prep for the day when you only get four.

However it also means you can be a huge contributor to your team while having a fully rounded life. It means that you don’t need to post that self-indulgent “I’m burning out, please help me” post on HN. It means that simply by being consistent you can be valued and respected.

Software teams don’t slow down because people work four pure hours a day rather than seven (which is insanely hard to do consistently by the way). They slow down because people spend weeks with no direction, or because the louder and emptier vessels dedicate their paid time to discussing Google v. Facebook’s acquisition strategies over endless extended coffee breaks.

Just work. Doesn’t matter how incremental or banal your progress seems…

Write up the things you’ve done and share them with the team

However you document things, whether it’s through a mailing list like Copyin, a wiki or even just inline documentation in the code, you should take the time to explain your architectural approach and learnings to the rest of the team.

Have a tough time getting a fresh install of Postgres or ImageMagik to work? If you found it hard, the rest of your team will probably also find it hard so take a moment to throw down a few paragraphs telling them what you did and saving them the time next time.

One of the worst parts of programming is losing whole days to battling bugs or installation issues. If you take the time to document and distribute the way you found through that you could buy five times your wasted time back by forearming your colleagues.

Understand and appreciate the exquisite balance between too much testing and too little

Testing is a powerful tool. It allows you to set a baseline for the reliability of your releases and makes you less fearful to make them. The less fearful you are to release, the more you do so and the faster you improve.

However it’s also an overhead. Tests take time to write, time to run and even more time to maintain.

You become too heavy to move, too encumbered to flex your limbs, immobile. Too little of it and the first skid across a concrete floor is going to cut you open and leave you bleeding.

There is no intuitive answer to what the right amount of testing is. Some projects require more testing than others and testing is a whole new piece of expertise you need to learn in itself.

Take the time to understand what really needs tests and how to write good tests. Take the time to see when tests add value and what the least you need from them really is. Don’t be afraid to test but don’t be afraid not to test either. The right point is a balance; take time to explore where the equilibrium lies.

Make your team better

This is different to the other points in that it’s not something you can action so much as an indicator of whether your other actions are working.

Does your presence make your team better or worse? Does the quality of your code, your documentation and your technical skills help and improve those around you? Do you inspire and encourage your team-mates to become better developers? Or are you the one that causes the bugs, argues during stand-ups and who wastes hours of time discussing irrelevant architectural nuances because it helps cover the fact that you’ve done no actual work?

You should make your team better. There should always be at least one or two ways in which you make those people around you better and through which the osmosis of your quality helps strengthen them. However, be aware that being “smart” alone is probably the least valuable and arguably most destructive dimension you can choose. In fact, if your chosen dimension doesn’t actually make you tired it’s probably not a valid one.

It’s not who you are on the inside that defines you

There is one humbly brilliant, line in Batman Begins which has always stayed with me. At some point in the film where he’s fooling around and acting up as a billionaire playboy, Christian Bale implores Katie Holmes to believe that he’s still a great guy on the inside. She answers simply: “it’s not who you are underneath, it’s what you do that defines you”.

Your contribution as a developer is defined not by the abstraction of how smart you are or how much you know. It’s not defined by the technology acronyms on your resume, the companies you’ve worked at or which college you went to. They hint at what you’re capable of but who you are is defined by what you do and how that changes the project and the people around you.

If you want to be good, apply yourself.

Comments on Hacker News

Amazon, the time has come to give you a key

We’ve been beating about the bush here for years, Amazon but let’s be honest, it’s time for you to have a key. At first it was lunchtime dates at mine. We’d both be excited and both be there early. It was forward of me to invite you over so soon but what the hell, I was in the honeymoon haze!

Then of course my job got more demanding and it was harder to sync our timings. So you very thoughtfully tried finding a spot in between us to meet, somewhere where you could make it easily and which I didn’t have any problem collecting from.

The problem was though it wasn’t always easy to get your gear home from those lockers and so even they didn’t work out that great. There was just too much stuff that I wanted to avoid hulking home and the locker just didn’t really help.

Then finally we go to the late night booty calls. They weren’t ever really going to last. They were convenient, sure but hardly civilised.

Now it’s got a bit weird with you telling me you’re going to send stuff to me by drone. I mean it’s a sweet gesture and everything and it’ll be cool to get stuff quickly but it feels a bit unnecessary. I know you love gadgets but there’s honestly an easier way.

Let’s get down to it, it’s time for you to have your own key.

I’ve let complete strangers in to stay in my house and yet you, with whom I have had a relationship for the past 15 years I still won’t even let past the front door. So I think it’s time for us to move to the next stage. I want to give you a key and I want you to come and go as you please.

It’ll make life so much easier. I’ll be able to order the things that I want to get but which aren’t currently worth the hassle - 12 bottles of Pellegrino, milk, orange juice - hell I’ll probably end up getting most of my groceries from you. I promise too that I’ll experiment with more stuff. I’m already hooked up to your Prime gig so if you’re willing to send it, I’m willing to try it.

Any chance you could pick up returns as you drop stuff off too? That would be AMAZING. I would finally even start buying clothes from you then. Let me tell you, I live in a city and it takes me half an hour to get to the post office and that’s if it’s even open. Earning the money to buy gifts from you keeps me pretty busy and the Post Office and I have pretty separate shifts. I also don’t have a car so I’m not going to be buying anything big. I love the fact that you do returns but frankly if there’s even the faintest chance that anything needs returning then I’m going to avoid buying it.

So, let’s move this relationship to the next level. I’ll cut you a key, you promise to look after it and we’ll take this up a notch. I’m game if you are?

p.s. I realise you’re not going to carry around a bunch of keys large enough to make an Alcatraz jailer blanche. However I also have faith that you can figure out a neat lockbox or similar that I can install for our mutual convenience. Ta.

Comments on Hacker News

Like Climate Change, the Privacy battle begins as a marketing problem

There are bad things happening with regard to our personal privacy right now. Many people don’t see anything wrong with them and many people feel no discomfort about them. Twenty years ago, the same was true of climate change. It took a long time to disseminate the dangers of climate change. It will also take a long time to disseminate the dangers of our privacy erosions.

We are taking part in an unavoidable and tragic pincer movement between the technology industry and our governments. We assume that privacy doesn’t matter because we implicitly assume we always have the choice to switch off, leave our phones behind and be private. Be private and offline or be online and observed.

Someday within our lifetimes, the technology industry will, with the best of intent, take that choice away. Someday soon, the proliferation of internet-enabled devices will flip the paradigm. We will be observed at all times, online at all times. We will have no privacy unless we pro-actively seek it out and we may lose the ability even to do that. At the very least we will be conspicuous by our absence.

Among those of us who see the problem looming there is a belief that we can reason and debate our way to making this issue go away. However we need to do far more than that. We have to change things such that people who don’t care and aren’t aware want it to go away too. We have to make them feel the danger. We have to market fear.

Try convincing someone that climate warming was real and that a gas-guzzling V12 engine was bad 20 years ago - good luck to you. Good luck trying to convince anyone to pay a premium for a battery powered car. It would never have happened.

It took 20 years of education, celebrity endorsements, films like “An Inconvenient Truth” and acres of data for people to finally develop an awareness (albeit generally a slightly retarded awareness) of what was happening with global warming. It wasn’t the data that made people want to change though - it was fear for what may come and desire for the now chic options which might avoid it - the Prius’, Teslas and carbon-neutral flying.

We face exactly the same problem with privacy. The NSA knows the implications and a subsection of the public knows the implications but that subsection is tiny. The vast majority of people don’t understand the implications but more importantly they don’t feel there’s a problem. Even if we convince them there are implications they won’t do anything until they *feel* them. That is something different.

No government is going to change anything until they feel that there is something wrong. Every sale starts with emotion and only ends with logic. we’re trying to tackle this problem the wrong way around - by starting with logic. We need to make politicians and the public feel the fear, feel the discomfort and only then offer them the logic to rationalise that fear and solve the problem.

If Google and Yahoo and Facebook are really serious about wanting to protect our privacy they could do so by marketing the implications of what happens when it goes away. They could to fund films, documentaries and even advertising. For years our governments have shamelessly marketed themselves into power using fear. Now we need to market our rights using the same tools back.

When the politicians and the public start feeling the consequences they will start wanting to act. They may never understand fully why they do that, the important thing is just that they do. You can’t always tell a child that something is dangerous, you have to show them it’s dangerous. You have to scare them.

How Dropbox could beat Apple in Photos

After my last post on photo management it became obvious that I was far from alone in my concerns about iOS photo management. The article hit a nerve and thousands of people retweeted it and even John Gruber and MG Siegler linked to it.

The problem clearly affects a lot of people. The question is what to do about it. Photos have been updated in iOS7 but few of the real problems seem to have been addressed.

The problems with iOS photo management today

1. No ability to organise photos across devices
iOS still extremely ineffective tool for organising images across devices. While iOS7 has introduced “moments” which seem to cluster photos by geography and time, there’s still no way to edit either the naming of the moments or even the clustering of them. Not only that but the moments are (so far) still tied to each individual device.

2. No ability to access photos cross-devices
Without doing a three-way sync with a Mac (which you may not even own) it’s more or less impossible to get a clear set of organised and curated photos natively synced across devices. Photostreams are unfortunately a mess and so no native way to settle back with your iPad and put together an album which you might later access from your Mac or iPhone. This is a tremendous waste.

3. Not enough value to make it worth paying for backup
iOS does offer a background backup service for your photos. This is helpful and the entry-level pricing of $20/year is much more manageable than Dropbox’s $120/year. However, while an investment in Dropbox gives you sync-space for everything, Apple’s is far more limited and basically won’t be used for anything more than photos. Dropbox offers you far more flexibility with the storage you purchase.

Dropbox should solve the problem
This space is hot. Photo backup is almost certainly the key to getting consumers to pay for backup and that is a very large market. After my original post, many representatives from startups and some very large companies got in touch to suggest I try their photo products. A number were good but after trying many of them I realised that Dropbox is the company I want to solve this.

I want this because at its core, the problem fundamentally boils down to syncing files across my computers. That’s going to cost me money and bandwidth and will cost my computer processor time and memory. I already pay Dropbox to do this and I don’t want to add the complexity of another service running in parallel.

Dropbox is also in a great strategic position to do this. Many people are loyal to iOS or Android but many more (perhaps the majority) are not. Android’s catching up with iOS fast and against Apple, Dropbox is in a strong position to nail this space because it’s one of the few companies with a strong foothold across both platforms. If you’re not 100% sure that you’re sticking with iOS you definitely won’t want to commit to Apple for long-term backup.

Unfortunately though, while Dropbox has the sync part down, it offers almost nothing else. Here’s what I think it needs to start doing in order to tackle this:

1. Provide a cross-platform Photo Management API
Cross-platform today means much more than it did ten years back. However, to deliver on photo management, Dropbox needs a photo management tool and that means they need one on every platform. I think the complexity of the project means that the key to success is probably not focussing on interface but instead focussing on building a superb-quality, cross-platform API and datastore.

I’d build a common, core-database and API and then completely separate the challenge of building applications for iOS, Mac, Android and Windows. Running a cross-platform interface project would be a nightmare whereas starting with an agreed-on database, file-structure and editing API could at least decouple the interface programmes. It would also let developers build and sell management apps for the platform themselves.

Minimum functionality for such a synced API would be
- delete photos
- organise photos into albums
- leave scope for smarter auto-album-organisation in the future
- simple editing (red-eye / crop / auto-enhance / filters)
- store edits with original file and only ever present one copy to the user to organise

Building a set of native clients is no small task and if I were running that project I’d want to know how much overlap there was with applications which are already on the market. Companies like Loom are surging ahead with great functionality and if you could buy them and retrofit their interfaces to a common set of standards then you could shortcut a lot of dev time.

2. To endeavour to become the native Camera Client for the user
The more frequently the user interacts with their photo library, the more time they will invest in it, the better it will be and the more they will value it.

One way to increase interaction frequency is to be the native camera app. This doesn’t need any fancy functionality but should offer at least parity with the existing native app. On iOS you you unfortunately can’t rely on being *the* native camera app because fastest way to access the camera is through the lock-screen and only Apple has access to that.

3. Remove the confusion around multiple copies of photos
This seems small but is fundamentally a huge problem. People need to stop having multiple copies of photos. If you have multiple copies it means you don’t know which one to delete or which one to edit. Creating copies of photos in a photostream which are then edited or deleted separately from the original photo is incredibly confusing. All of this is a mess and a pain.

Dropbox needs to figure out one way or another how to make sure that users only have one copy of each photo in Dropbox and no others in the photostream or on the camera roll.

4. To make their pricing more accessible
Dropbox’s cheapest plan is $10/month which is a lot to ask from someone who’s never paid for storage before. However, and at least on iOS, Apple has kindly provided a forcing function to make users consider paying.

Dropbox’s biggest friend right now is the “Your iOS storage is almost full” notification. Users get this when they run out of their initial 5Gb on iOS and then have to pay to upgrade or start deleting photos. Left to their own devices most users will never pay for things and many people will just delete photos until the warning goes away. If Dropbox could do some jujitsu to figure out when a user hits their limit then they could message the user at the same point and undercut Apple.

Offer dual-tier storage
Data’s not cheap to store so undercutting Apple wouldn’t be easy but one way that Dropbox could do compete is by leveraging cold storage. Dropbox can offer to backup high-resolution photos securely but without immediate retrieval (i.e. by using Amazon Glacier or similar). That way they could offer peace of mind while charging a fifth of the price. Users could buy peace of mind cheaply and then pay for access later on. This could also be a way to segment the market and offer plans which are nominally high-storage without cannibalising existing higher plan subscribers.

Trade storage for credit card details
One of Dropbox’s biggest problems must be getting people over the penny-barrier and convincing them to open a new line of expenditure (storage). Making the ramp more shallow would help and giving them something for just entering credit card details (1Gb storage?) would make it much easier to get involved. Paying for backup is a big thing for a lot of people and making that easier should be a big priority.

Young people are taking a lot of photos but aren’t inclined to pay for things (especially since many of them don’t have jobs) but within only a few years those people will become mothers and fathers with children and photos of those children that they don’t want to lose. The more Dropbox can get them over the hurdle of credit-card input and crossing the-penny-barrier before that time comes, the more likely they are to start paying to save their family memories.

5. To be fast, transparent and reliable
I use Dropbox to backup my photos and it currently has 5 photo (or video?) files which it refuses to sync successfully. I don’t know what they are, I don’t know why they won’t sync and I don’t know how to get them to sync. Because they haven’t completed I don’t trust that any of the library has completed and I’m not ready to delete the old ones on the camera roll. Every time I open the Dropbox app it takes over a minute for the photos section to load and it not infrequently crashes.

Dropbox also splices all photos stored anywhere in the Dropbox folder into the photos view of the application. This is both unexpected and undesirable. I don’t want drinking trips spliced in with family photos. If photos from a stag trips on a Saturday night are going to appear next to photos from a baby shower the next day then I’m never going to show people those baby photos because I won’t want them scrolling through the stag photos. The whole thing is club-handed and badly thought through.

Dropbox can’t afford this sort of confusion. The company succeeded with files because it did everything quickly, reliably and responsibly. Doing this right is no small challenge but a company which does will be treasured by its users. Dropbox needs to constantly go the extra mile in UX to show what’s happening and to give users the agency to fix problems themselves.

Why is this a problem worth solving?
The battle to win the world’s photo management market is a huge one. It’s a huge amount of work but it comes with huge spoils. The number of photos people are taking is growing exponentially. The devices on which that is happening are increasingly connected to the internet and Dropbox is already part of the file system on most of those devices. People want photos to be private by default and they want something then can rely on. Dropbox has already proved itself to be reliable and unlike Google Plus, Facebook and Flickr, it’s private by default. Dropbox is the heir apparent.

The cost of storage continues to fall while the number of photos and videos recorded continues to rise. The arbitrage opportunities are almost as good as they will ever be. In many ways I wish that Apple would solve this but that doesn’t look like it’s happening and for all of its lethargy in getting going, Dropbox is the next best bet.

Apple’s fingerprint sensor may be the biggest leap forward in payments since the Amazon Account

During today’s keynote, Tim Cook mentioned, almost in passing, that you could log into the iTunes store using the fingerprint sensor.

This statement may turn out to have way more significance than its low-key delivery would suggest. It took me a moment to realise it but the fingerprint sensor is almost certainly not about securing your device. The fingerprint sensor is about securing your account. The fingerprint sensor is about payments, initially to Apple and then maybe subsequently elsewhere. The fingerprint sensor may be Apple’s mobile answer to Amazon’s web-bound One-Click.

For every app, music and in-app purchase made through an iOS device there is at least one other that wasn’t made because someone couldn’t be bothered to type in their password, got it wrong or just didn’t know it. Amazon once measured a discernible difference in checkout rates from page loading increases of only 1/100th of a second. Apple has to request a password. That password has to secure the phone against chargebacks due to theft, purchases made by small children or just a trouble-making friend pinching your phone and playing with it. The only answer to those chargebacks today is to demand users to continually re-enter their passwords.

Perhaps even more problematic for Apple is the proportion of their customer base who don’t even know their passwords. A significant proportion of iOS users won’t be able to tell you their password and may not even have a credit card associated with it. Apple must have swathes of older, tech-challenged or simply disinterested customers who never buy any video, music or apps. Those customers are lost revenue for the iTunes store in the short term and are far more vulnerable to churning over to Android in the long term.

Because it’s not the just the revenue from apps that passwords cost Apple. Apps are what make the platform useful, apps are what tie you to your OS and many of the best ones need to be purchased. If you don’t buy apps the platform is significantly less useful to you, you’re far less loyal and you’re far more likely to be swayed by Android. Apps are Apple’s platform lock-in.

I’m guessing that this new scanner won’t just be a piece of hardware Apple ships and forgets about. I’m guessing that Apple will integrate their efforts around the fingerprint and will encourage you to setup your fingerprint and enter your credit card in the Apple store when you buy a new device. I would. They will do everything they can to encourage you to associate your fingerprint with your credit card and free you to one-scan purchase. I’m also guessing that despite its more homebound nature we’ll see that fingerprint sensor very quickly on the iPad too. The iPad is a perfect shopping tool and one-scan shopping would make that even more true.

The fingerprint sensor is way too much technology just to make it easier for you to get past your lock screen. As Tim Cook said, many people don’t even setup a PIN. I think the fingerprint sensor promises to be a far more strategic tool than simply a souped-up login. What the fingerprint sensor may actually deliver is the biggest improvement in frictionless payments since the Amazon account.

Apple has to make big bets to move the dial now and payments is one of those that many people have spoken about. Many people were waiting for Apple to announce NFC and jump into the payments space but I think they may be even cleverer than that. Payments would be a huge new revenue stream for them but easy authentication and chargeback avoidance must have been a large barrier to offering that. If the fingerprint recognition works a well as advertised, that barrier may just have fallen away.

Comments on Hacker News >

Things I’ve Learned About How to Build Good Product

These are the slides from the talk Taavet Hinkrikus and I gave yesterday at the O2 for Campus week and Wayra.

The talk is about how to build good quality product quickly in highly uncertain situations. It’s about building product in a pre-product-market-fit startup and I like to think that there’s something for everyone (over the age of 29) in there.

If you, like me, lament the fact that Craig David and XKCD sex scenes have have never before met in a presentation about product then you’re going to LOVE slides #90-99 (also I hope you at least remember Craig David unlike most of the blank-faced audience I was talking to).

If you’re wondering what the relevance of the Ariel Atom and a kitted-up Peugeot 206 (#106-110) is it’s this. One looks like a piece of scaffolding that fell on a go-cart but goes like s**t of a shovel while the other looks, well… crap but it’s owner clearly spend a lot of time on “design” while paying no attention to the fact that there’s not a lot of point in it as a car. This is a metaphor.

Enjoy, debate and if you chose to upvote this at Hacker News, well then let me tip my hat to you as you’re a gent sir (or mademoiselle). Gracias.

Comments on Hacker News >

How to build product campus week from Peter Nixey

Using Sidekiq and OpenRedis on Heroku

I recently switched from using DelayedJob to Sidekiq for processing my background tasks. Sidekiq’s super-powerful for jobs that have a lot of latency (like external API calls) since it parallelises them in threads and runs 25 (by default) at a time. This can literally divide the number of boxes you need to run things by ten.

However it took me a little while to debug some stuff in order to get it running well on Heroku. I hadn’t been using Redis before and so I had a few moving parts to sort out. I kept getting the error:

sidekiq Redis::CannotConnectError (Error connecting to Redis on localhost)

The problem was that I hadn’t told Sidekiq how to connect to Redis. In case you’re having the same issue, this is how I fixed things.

1. Setup a Sidekiq initializer file

As per you should add a Sidekiq initializer file which will look something like this:


# /config/initializers/sidekiq.rb

redis_url = Rails.env.development? ? ‘redis://localhost:6379/0’ : ENV[‘REDIS_PROVIDER’]

Sidekiq.configure_server do |config|
config.redis = { :url => redis_url, :namespace => ‘twistilled’ }

Sidekiq.configure_client do |config|
config.redis = { :url => redis_url, :namespace => ‘twistilled’ }

NB I haven’t figured out and can’t bring myself to figure out how to format code correctly in tumblr so if you copy and paste my ocde you’ll need to make sure that single-quotes and double quotes come through with the correct characters on your machine.

2. Add your OpenRedis URL to Heroku as an env variable:

heroku config:set REDIS_PROVIDER=your_redis_url_from_open_redis

3. Check things are working via the Sidekiq console

You can monitor the status of the system by mounting the very pretty Sidekiq console in your routes file (NB you should password protect this):

# routes.rb
require ‘sidekiq/web’
mount Sidekiq::Web, at: ‘/sidekiq’
view this from


This may not all be necessary. See this conversation on Twitter with Mike Perham. Unfortunately (possibly due to something I set incorrectly) I couldn’t get this technique to work but you may do:

Our very real liability as Twitter app developers

Last week Carl Icahn sent out a tweet that raised the market cap of Apple by $17Bn. Carl was under no illusions as to the significance of his disclosure, and filed with the SEC before doing so to state that he may use Twitter to release information he considered to be material.

The ability of high-profile Twitter accounts to move markets is now very real and doing so nefariously is not unprecedented. In April of this year crackers got hold of the Associated Press Twitter account and wiped an estimated $135Bn off the S&P 500 Index by tweeting that explosions at the White House had injured president Obama.

Being implicated in such events this has huge consequences. A friend’s company recently suffered a data leak and afterwards he told me that it was one of the worst weeks of his life with an office full of lawyers and FBI agents. He said “I hope you never have to go through this”. That happened as a result of leaking their own (encrypted) passwords. If you were a developer implicated in the compromise of a high-profile Twitter account which broadcast market-moving material then I can only assume things would be many times worse. Such an eventuality may be closer at hand than you imagine.

If you ask for write-permission for Twitter accounts then you have access to those accounts. And if someone gets access to your server or database then they may do too.

In order to get hold of your users’ accounts a cracker needs four things:
- your users’ oauth tokens and secrets
- your application’s consumer token and secret.

The first two aren’t of any use on their own as any API call still needs your application’s consumer token and secret. If, however, the hacker has access to your users’ tokens and your consumer tokens then they’ve got the keys to the kingdom.

You should be absolutely 100% certain that the four of these things are never available to a cracker. The most significant and protectable of these is your application’s consumer secret, however you should also think carefully about how and where someone might get hold of the other three. Best practices for protecting these will vary depending which platform you’re on.

We’re going to see a rise in Twitter attacks over the coming years. It’s now such an influential news source that getting into users’ accounts is only going to become more attractive. The prospect of honeypot apps or developers paid by financiers to move markets becomes ever more likely. Finance aside, the power of Twitter to incite civil action or even violence is very real and would undoubtedly have huge implications for a developer who inadvertently enabled such activity.

As developers we should think carefully about the liability we take on when we request write-permissions for an account on Twitter.

However I think that Twitter also has a responsibility to educate and protect its users more than it currently does. Users with large followings should be warned about the ways their account can be mis-used by connected apps. They should also be encouraged to switch their account to a “secure” mode where it can only connect to apps which have been whitelisted or even perhaps a super-secure mode which would disallow app-connections altogether. Most people have very little idea of the implications of connecting to a Twitter application. Even if did though and they they knew they could trust it, they can’t possibly anticipate how securely the application’s been coded.

Over time we will undoubtedly see more clarity in the law and in how liability will be allocated across such a chain of events. Unfortunately it’s going to be a precedential case and a scapegoat developer which will forge this. When this does happen we will discover how much responsibility will fall at the app-developer’s doorstep for not properly securing themselves and at Twitter’s for not properly informing their users of the risks.

As more and more influential people join Twitter, such attacks will inevitably become more frequent. In the meantime, as application developers, we should be careful with what liability we chose to take on and how we protect ourselves and our users from it.

Comments on Hacker News

"Instead of cures for cancer we got Angry Birds"

“The Valley’s brightest minds once invented things of immense significance like the first PC. But then came the internet and the pursuit of big ideas was eclipsed by a scramble for quick profits. The money pumped into hard technological problems plunged while interest in iPhone apps soared. The result? Instead of cures for cancer we got Angry Birds”.

So concluded a recent article in the Sunday Times. “Does it really matter”, “you could working things that could save lives, why worry about dry cleaning?”. Casual observers love to glance through the office windows of entrepreneurs and wonder “if there’s so much money to be made in entrepreneurship, why don’t these folks do something that really matters”.

I can perhaps understand where they’re coming from. One of my brightest friends is looking to start a new idea in advertising or property. I know that he’ll do very well in whatever he choses but it makes my heart sink to think of his talents being used to optimise advertising. I don’t expect him to stop the spread of malaria but he’s a source of creative energy in the world and it would be nice to see him use it for something that I might at least use.

Asking him or any other entrepreneur why they solved one problem and not another is like asking a river why it doesn’t splash out and irrigate the fields above it. “Since you’ve got so much water, why not wet my crops rather than just deepening the plunge pool under the waterfall?”. The question is moot. Water flows downhill: down a potential gradient. Like water, entrepreneurship also follows a potential gradient. Water depends on a height gradient, entrepreneurship on a value gradient. The greater the gradient, the faster they move and asking why things might be different is as pointless as arguing with water.

Entrepreneurs follow those gradients for good reasons too. While the Sunday Times may photograph Brian Chesky hanging out in AirBnB-central they don’t photograph the entrepreneur who had to give up his company and leave penniless to look after his dying sister’s family. They don’t photograph the hundreds of young hackers holed up for years in Palo Alto with nothing to show for it. They don’t photograph the founders who watched their company fall apart as they stood locked in a legal Mexican standoff. If they did their question might change from “why do you not cure cancer” to: “why do you do this stuff at all?”. Entrepreneurs follow potential gradients because their business is a risky business.

I think the “does it really matter” philosophy comes from two misapprehensions. The first is the assumption that markets are fungible and the second is a lack of ability to distinguish small probabilities.

When you assume markets are fungible - that one can be tackled as easily as the next - you inevitably ask whether “disrupting the dry-cleaning market” really matters when the alternative is “feeding Africa”. These aren’t adjacent problems though, they’re literally and figuratively continents apart. There are already entrepreneurs tackling both problems but they are entrepreneurs with very different knowledge sets. Getting frustrated with software entrepreneurs failing to feed Africa is like getting cross with Norman Borlaug for not doing a dwarf wheat iPhone app. These are different entrepreneurs with different skills and different available markets.

When you have no way to distinguish small probabilities then all long-shots look the same. Two “seemingly impossible” ideas may still be magnitudes apart in probability. As incredibly small as it is, the chance of successfully building a new car manufacturer is still millions of times higher than that of curing cancer. To the average person both ideas may seem vanishingly small but good entrepreneurs work with a microscope. They can magnify their field up so large that they know every nook of it. What looked like two small specks to the untrained eye looks completely different to the entrepreneur. They see one as a cell with all of its mitochondrial energy-producing goodness while the other, a million times smaller still, remains as mysterious as it was without the microscope.

Finally, it’s worth pointing out that entrepreneurship isn’t a salaried job-rotation or an credit-option on an MBA. You don’t chose the option you fancy most and then roll on to a different one three months later. Being an entrepreneur is a nail-biting, ration-sapping, wind-bitten, many-year, unsupported journey into the unknown. Asking an entrepreneur why they took one route and not another is like tweeting to a climber on K2 to ask them why they didn’t take the harder route. Ask away but if you think it should be climbed then you should buckle up and climb it.

Comments on HN

Five techniques that measurably improved our customer development

When we first started building Copyin we had a problem. We found it incredibly useful but our early users felt differently. We loved that it created a knowledgebase out of our email. The problem was that we couldn’t communicate that benefit to our customers. People were receptive to the problem but (at that stage) not the product.

So we found ourselves in a quandary. We had a product which was valuable to us but not to the people we’d so far shown it to. So did we have a product or a market problem? We didn’t have enough data to know. After all, it wasn’t like we were the only product in our space those people didn’t use - almost none of them used Salesforce or Yammer and they were both successful nonetheless. Was our sample size too small or our product off-mark?

In order to answer this we needed to speak to more people. We knew we could get them from a public launch but we didn’t yet know who we were launching to. We felt it would be a waste to launch while still so far off product-market fit. However we still needed to speak to more people and to different people and we needed to do so quickly.

1. We created an inbound customer development pipeline using our blogs

The first thing we needed was more people. For that we turned to our blogs. Both Rob and I had already had a fair amount of success blogging so we decided to experiment with recruiting people directly from blog posts. We built a small signup form, cached it to withstand traffic and embedded it in the bottom of each post.

This is the form:

(Please do sign up - it won’t take you off the page :)

To our delight, the form worked. About 1% of people who saw it signed up and we immediately increased both the reach and diversity of people we were interviewing. We had enquiries from everyone from CTOs of publicly listed technology companies to administrators of NBA teams and mountain rescue societies. We did all of this without even altering what we blogged about. If we’d written about Copyin or its problem space specifically I’m sure we’d have converted even higher.

2. We immediately followed up on new registrations to arrange interviews

Our goal was to get interviews not signups so once people had signed up we immediately sent them an email thanking them for their registration and inviting them to speak to us.

At first we worded this invitation email in a very softly, softly, manner:

Hi, it’s Peter from Copyin. If you have a moment we’d love to chat to you. We can speak to you when it’s convenient, please do get in touch.

Nobody responded to these though so we changed the text to be much more exclusive with limited availability:

We’re prioritising customers with real pains in this area. If this is you then please get in touch and we’ll book you in as soon as we get an opening. If it’s not then please accept our apologies but we’ll get to you when we can

The latter converted very effectively and about 10% of registrations emailed us back to tell us more about their particular needs. Almost everyone who emailed us was happy to do a phone conversation and we’d spend anywhere from ten minutes to an hour speaking to them about how they were currently solving the problems that Copyin addressed.

3. We stopped pitching and started listening

When we first started customer development we made a massive mistake. Instead of listening to a customer’s problems we would instead pitch them our solution What we should have been doing was asking people what their issues were and listening to how we might solve them. What we actually did was wax lyrical about the product and debate with them on whether it really could solve their problems (at the time it couldn’t).

Customer development is a very different process to sales though. Sales is about helping your customer to understand the product. Customer development is about helping the product to understand your customer. Don’t try and sell during the initial exploration.

4. We made sure that the whole team was a part of it

After each interview we’d sent both the transcript and the summary to the the rest of the team using Copyin. Disseminating the research is tremendously important. The temptation as CEO is to yank the product tiller after each and every interview. This leaves the team feeling bewildered as to why the thing they were working so hard on is now so unimportant. Their natural reaction is to stop caring so much in case what they’re passionately working on suddenly gets binned.

Obsessively sharing customer research has three huge benefits. The first is that when you do need to move the tiller everyone already understands why. The second is that it encourages you to discuss product as a team and gives everyone a vested interest. The last one is that you have a written record of what actually happened.

If you don’t give the team access to customers it’s easy to dismiss their opinions as being uninformed. This can cause decisions to be over-volatile and is bad for morale. If they do have the data then they can not only offer valuable opinion but also become a powerful protection against CEO tiller-yanking and over-correction.

5. We used our embedded signup form to test new hypotheses

As you do your customer development you will start to form new hypotheses about what the customers actually want and what their problems actually are. It’s incredibly useful to test these and to see whether they’re correct or just a result of your last interview.

We were able to do this by incorporating three very simple benefits from Copyin back into the original enquiry form and cycled through various features that tested our hypotheses:

- turbo charged mailing lists to better connect your team
- Search-assist to make sure you never answer the same question twice
- Tag, file and edit the email threads actually worth keeping


- Connect to the expertise in your team
- Capture your team’s knowledge
- Know what’s happening

By seeing which phrases people responded to we began to see which things they cared about (and which ones they were prepared to pay for). These phrases also helped drive what they put in the last (most helpful) box which asked them what they would use Copyin for:

We got a variety of answers to this. Early on they were vague and sent by people who (upon interviewing) often turned out to have no budget. Over time and as we improved our positioning we were able to select better and better for people with real budget and more tangible problems.

What people answered to “What would you use Copyin for?”

We’ve got a vastly growing team, with a huge email load. Streamlining this process would be amazing.

Need to track conversations multiple people are having on multiple topics over multiple channels

Populating Knowledge base with relevant content about processes and services.

More Cow Bell


The data was statistically insignificant but it was nonetheless very helpful in understanding which terms appealed to which people (and to which budgets).


It’s very easy for customer development to fall by the wayside and to think that it will “just happen”. It’s not easy to do though and involves being humbly wrong many times in succession. It requires all the pro-active outreach and rejection of sales without any of the highs from actually selling anything.

Done properly though it is incredibly powerful and painful only because it compresses a year of head-in-the-sand learnings into a few short weeks. That much medicine is never easy to swallow.

We found that with the funnel in place the rest followed very naturally. For us, heavy investment in customer development let us go from a product which nobody really understood to one which people now get in a single sentence (create your company knowledgebase from your everyday email) and really want to use.

Discussion on Hacker News >