Peter Nixey

Rails/Angular developer, Entrepreneur & YC alum. Previously built and sold Now O(only)TO at and part time partner at Entrepreneur First.

This is the dream non-technical startup job

I am a founder advisor to a company called RotaGeek. RotaGeek schedules staff for companies like O2 i.e. it makes sure the right people are in the right retail outlets at the right time of day.

The company launched four months ago and with only three employees, already has £150,000 in annual recurring revenue. Based on the current inbound leads alone it looks like it’s going to have £1M in recurring revenue by the end of next year.

This is the real deal. I’ve been doing startups for ten years and never seen anything like this.

Chris, the founder, is a badass but totally run off his feet right now and needs someone very capable and bright to complement the work he’s doing. She or he needs to be Chris’ “right hand person” and will end up holding a very significant position in the company and doing many things. The company is a different place every week and this role will be very different in five months time.

We are looking for someone who is very smart, has a track record of doing hard things that demonstrate their ability to consistently work and achieve and who is able to write and present extremely well. The role will involve everything from working through UX and analytics in improving the signup flow to going out to present RotaGeek at pitch events to handholding multinationals through their onboarding process.

If you’re smart, hard working and have ever approached a startup suggesting that you might be good for “biz-dev or marketing” then this may be for you. However you need to apply soon: we want to appoint this person yesterday.

If you are that person or you know that person, please tell them to get in touch with Chris directly: chris at rotageek dot com.

Your application should include evidence showing us how you’re smart and evidence that you’ve done hard things (whatever those hard things may be). Also include any public profiles - LinkedIn, Twitter, Blog etc.

Mail us.
- Peter

Brojures can now be embedded

Which while completely orthogonal to anything else I write about is kind of cool :)

A counterpoint to Jessica Livingston’s advice: Why Startups Should Use Marketing as Sonar

Jessica Livingstone recently wrote a very good article for the WSJ on Why Startups Need to Focus on Sales not Marketing. Her point was that early companies do much better by making their products work really well for a defined audience than by distracting themselves with high-scale but low-fit marketing.

Only a few days earlier I had been enthusiastically advocating exactly the opposite advice to the team at Entrepreneur First. I feel that startups should pay extremely close attention to marketing and do so as an ongoing discipline. I think that one of the biggest dangers to early stage startups is getting into a local market-minima and that marketing is an essential tool to help avoid that.

One of the team, Alex, wrote to me to ask whether the two points were at odds with each other and if not why I would stand by my original statement. I don’t and I do. Here is why.

It is very important to focus on making a product work really well for clearly identified customers. It’s painful and takes longer than you expect. But it also forces you to make software that is genuinely useful. As Jessica points out, marketing is painless and shields you from the cold reality (and insight) of rejection. A depth-first approach also tends to correlate with successful products. Or as Paul Buchheit says, “it’s better to make a few people really happy than to make a lot of people semi-happy”. Worth noting that this isn’t the same thing as causation but for those of us who value building beautiful product, encouraging nonetheless.

However in the product-focussed, early-stage (pre YC) teams that I see, the real risk is not that they waste time or money on marketing. The real risk is that they end up optimising for the few users who are most easily accessible to them. Instead of exploring the wider market, these teams relentlessly iterate their product for a small number of friends, family and customers who don’t necessarily even want their product. They just happen to be accessible users.

Marketing is traditionally a tool to help companies scale sales. It allows them to reach out to a lot of people and either sell them directly or soften the ground for a purchase later on.

That scalable outreach is super important to startups too; not as a sales tool but as an exploration tool. Marketing is a way for startups to quickly gauge demand for their product across one or more marketplaces. It’s a way for startups to explore the territory and find their beach heads. In more mature companies, marketers complement the sales team. In early startups they should be cartographers, and complement the product team. Before you can make something work perfectly for an individual customer you need to find the individual customer to perfect it for.

"Startup marketing" does not mean thousands of dollars spent on adwords budgets or expensive trade show stands either. Startups are inherently interesting and should get involved in the communities they’re designed to service. If you’re a developer and your community is Hacker News then you have it easy. Companies like Stripe and absolutely nailed their HN marketing. If your target market is Mums then get stuck into Mumsnet, if it’s teaching then get stuck into the teaching community. Some of these communities are in forums, some are on Twitter some are probably just physical. Any which way though your primary marketing is simply Getting Involved. It won’t get you all the way but the relative ROI is huge.

One of the companies I advise, Rotageek, provides excellent scheduling software for organising staff schedules. The team spent years honing the product and making it right for the NHS here in the UK. One of the founders, Chris, worked in emergency medicine and saw the pain and cost of manually organising staff. Being an entrepreneurial sort, he teamed up with a friend to create a piece of software to address that. He knew the problem intimately and worked hand in glove with the NHS, evolving the product and optimising it for their needs until one day he realised they just weren’t going to pay for it. They would happily string him along and may eventually, possibly have bought but that point would have been long after the company finally ran out of runway.

However the moment that Rotageek switched from optimising the product for the NHS to casting their net out wider, they started to find companies who really were hungry for the software and more than willing to pay. The team is now scaling for a huge rollout and all because they started marketing the product widely enough to find people who really wanted it. Even now they still only have a relatively small market sampling. While retailers are extremely receptive to Rotageek, they may not end up being the best market for the company either. Without reaching out to new markets and without casting their nets wider, the company will never discover that.

One of the hardest and also the most useful things I’ve ever done was door-to-door book sales in West Virginia. I did it with a friend as a summer job at University. We learned a huge amount about selling and how to sell. The sales scripts and the sales school were both brilliantly designed but despite all the technique, the scripts and the schooling, one simple lesson was hammered home again and again: “The quickest way to convert a disinterested customer into an interested one is knock on five new doors”. The point was that finding the people who really want to buy from you is more lucrative than obsessing over those who don’t. To find that customer, the one that’s really hungry for you, you need to first of all knock on a lot of doors.


You should absolutely go deep and optimise for your target market be careful not to optimise prematurely. There is someone for everyone on the internet. You can find people who are willing to eat you and even people who are willing to be eaten. When you find those customers who really want to you (hopefully not for dinner) then follow Jessica’s advice: go deep and deliver exactly what they want. Until then though, remember Annie Lennox’s advice and that “everybody’s looking for something”… “Hold your head up, keep your head up, movin’ on”.

Comments on Hacker News

Introducing Objectives, Goals and Strategies

As with my previous post this is taken from an email I sent round to our team today

I’ve spoken about this with all of you individually now but I’d like to get it down and into Copyin too.

Up until recently we’ve been using “2-week plans” to give us each a longer horizon on the work we’re doing. Those have been combined with weekly “Plans, Progress and Problems" reports to give us a way to plot and chart our progress.

As an early startup, we operate on such a tactical, day-to-day basis that the two week plans were originally a useful way to help orient ourselves with where we each wanted to go in the “longer” term. However once we introduced weekly PPPs they started to feel redundant. The two week plan was turning into just twice a PPP and not adding any value to us.

The PPPs do an excellent job of making sure we’re moving forward they don’t really do a lot to check that we’re going in the right direction. Which is where Objectives, Goals and Strategies come in.

Objectives goals and strategies are a way of determining the exact value-add that we want to commit to (objective), how we plan to deliver the value add (strategy) and whether we succeeded in doing so (goal).


The qualitative outcome we want to achieve e.g.

  • make sure that people stay active on Brojure
  • increase the number of people being exposed to Brojure
  • make the editor easier to use


These are the hard numbers that determine whether we have actually met our objectives. They’re a way of making our objectives achievable and failable.

(examples of goals that relate to the above objectives)

  • increase the proportion of new users who create a 3rd Brojure from 1% to 20%
  • increase traffic to the site from 500 uniques a week to 5,000 uniques per week
  • reduce the time it takes to create a Brojure (with known content) from 15 minutes to 5 minutes

NOTE - these should be achievable (not ridiculous) and also failable (you should be able to tell whether you actually achieved them. e.g. “make editor better” is not failable)


These are the ways in which we are going to delivery our goals.

Note that the strategies are the ways in which we achieve our goals. They are not the goal itself. Failing to recognise this distinction is why many people and companies remain busy without really achieving anything. They assume that the work is the goal. Working is not the goal, it is merely a means to achieving the goal.

Let’s look at possible strategies for achieving the goals we set above:

Possible strategies for increasing # users who create 3rd Brojure from 1% to 20%

  • after each Brojure send them an email with a trick they can use for a new Brojure and a prompt to start the next one
  • pick a vertical and funnel users through 3 particular uses of Brojure for them e.g. for a restauranteur encourage them to produce: 1 Brojure for their menu, 1 Brojure for Private Events, 1 Brojure for the restaurant’s history (sounds like a crappy strategy to me but it is at least an example of one!)
  • add a “to do list” in the editor encouraging users to “complete their to-dos” one of which is making 3 Brojures
  • allow people to copy Brojures and tweak them for someone new

Possible strategies for increasing traffic to site

  • guest blog on other people’s publications
  • buy google adwords (needs further constraints to ensure that the strategy is economically viable)
  • make identifiable improvements to SEO
  • get guerrilla and go into communities to spread the word

Possible strategies for decreasing time it takes to make Brojures

  • fix image upload bug
  • allow people to copy an existing Brojure to create a new Brojure
  • pre-load Brojures with content
  • allow people to save content snippets that can be injected into new Brojures
  • add more Javascript interaction to the editor to literally increase editing speed

What Objectives, Goals and Strategies actually do for us

The idea is that each month we will decide on our actual objectives. This is one of the most important parts of the process. It’s very easy to just churn through work without moving forward and so before we decide what we’re going to do we first decide what we want to achieve. Product is one place that can benefit hugely from this part of the process. It’s incredibly easy to queue up lots of features without any of them actually impacting us and end up with a set of features for the sake of features.

Once we’ve done that we then get honest with ourselves and ask what will tell us whether we achieved that outcome. We set our goals.

Finally we look at the strategies we’re going to use for achieving those goals. How will we execute?

OGSs will be set at the start of each month

The Objectives will become something that will require solid teamwork from us. If we take an objective like “increase Brojure completion rate” then it may require Dash to create an email strategy, Peter to implement changes in the editor and Tomas to design them. Similarly “Increase the number of people engaging” may mean Ollie has to do do more phone calls but that Dash needs to create a new sign-up email type and that Tomas needs to tweak the landing page design.

This is nice in that it begets collaboration which is fun. However it could also go badly wrong. If we choose goals badly they will be dependent on multiple people and we could fail on all OGSs simply because a critical member of the chain was not able to give their support to all of the strategies they were required for. If Dash is on the hook to do an email component for every other person’s strategy then he could end up over-committed. If he’s overcommitted then he won’t succeed and everyone fails. Whose fault was this though? Who can correct it when it becomes clear that it’s starting to happen? Not Dash’s because he was over-committed, not everyone else’s because it was Dash who failed to deliver. This is NOT a situation we want to find ourself in (or put Dash in).

Goals should hold individual people (or teams but at our scale it will mostly be people) responsible for delivering and should afford them the autonomy and resources to do so.

Objectives will be set company wide, goals will be individual

For this reason we will decide on company wide objectives but each goal will relate to a particular individual. We will choose goals such that individuals can execute on them, can take credit for them and can can be held responsible for them.

There is one exception to this in that Tomas and I have discussed this and because his design work is currently so strongly coupled with my dev work we will work as a unit on product. I’ll go on the hook for both of us :)

Any questions, concerns, objections just hit me up or reply to this email.

Thanks team,

The most important question in a startup: Am I being proactive?

This is taken from an email that I sent out to our team earlier today.

Some jobs in life come to you - answering phones, answering emails, responding to requests. They turn up and you process them. As long as you spend the day processing them then you’ve done your work. These tasks keep us in place, they stop our businesses unravelling, they maintain our status quo. If we already have a company, a revenue stream and a business model then that is exactly what we want. If we do not then it is exactly what we do not want.

In a big company, your job is to maintain the status quo. If all eBay does for the next decade is continue to be the top online marketplace and make 9% profit off all transactions they will have succeeded. Most of that work is reactive - keep competitors at bay, acquire them when they get too feisty, make sure systems don’t go down: as a friend from eBay once told me: “the main thing people care about here is making sure we don’t fuck it all up”.

However if, over the next 10 years, all our little startup does is to keep 100 users on the system with one super-user and and ten more somewhat engaged, then we will have failed spectacularly. We don’t yet have the luxury of having anything to fuck up. We dream of the day when our fuck-ups have consequences. Our fuck-ups go sadly unnoticed.

Big companies fear change because it usually means something’s gone wrong. Startups are entirely the opposite. If startups are not changing then they are dying. Everything we do is about changing numbers not maintaining them, everything is about building product, growing users, building momentum, increasing engagement. None of those things are about maintaining the status quo, none of them are about not screwing up; all of them are about gaining new ground.

We do not fail in unsuccessful attempts to take new ground, we fail in not making those attempts in the first place.

Reactive tasks are about maintaining your current position, they are about not losing ground, they are low risk. You know they’re feasible because you already hold that position, you know what the ground feels like under your feet. You know that you can probably complete that task without failing. Pro-active tasks are quite the opposite. They require taking new ground and taking ground that you’re not sure can even be taken.

Being proactive and making this happen is hard and comes hand in hand with failure. It means going out on a limb, doing jobs that risk not having any worthy outcome, doing things that may just fail to work altogether. It also requires being wrong and ideally being wrong 50% of the time.

Most of what a startup does is exploration and testing. Our goal is to find a repeatable scalable business model, our job is the search for that. We are literally discovering what works and what we can successfully repeat. We are figuring out what product our users want, who wants it most and how we can reach them. Once we have tested that then we can repeat it but first we must test it.

Information theory tells us that the optimal testing strategy yields positive outcomes 50% of the time. If on average you’re right more than that then you waited too late to test, less than that and you tested too early. The goal of testing is not to prove that you are right it is to see *if* you are right.

But optimising to be right 50% of the time means optimising to be wrong 50% of the time and that is 100% more of the time than most people can handle.

It’s easy to respond to an email, you cannot fail. It’s there, it’s asking you to respond to it, you already know there’s an audience waiting to read it you can’t go wrong. It’s far harder to risk the rejection that comes with cold calling a customer who may not want to hear from you. Far harder to report the 0% clickthrough rate from your latest, experimental email campaign or that the blog post you spent a day writing only ended up with 10 visits.

But these are the jobs that actually move us forward. These are the jobs which, while infused with risk, are also laced with sparkly rewards. These are the crazy email campaigns that may yield a 50% clickthrough rate, the blog post that happens to resonate and generates 60,000 visitors. These are the alpha-team tasks that parachute you into new ground and from which all of the reactive tasks subsequently unfold.

These jobs are proactive not reactive. It is the outcome of these jobs that form the anecdotes we tell people at parties, they are what go into our investor decks, they are what we feed the press in interviews. These are the forays that build our company.

So - as you put jobs into your daily to-do list, ask yourself: “is this proactive or reactive”? If it’s the former and it’s “tangible, fail-able and do-able” then it’s probably an excellent task. If it’s not then perhaps it really does need to happen but also ask yourself whether there is another way that you to spend that time that really moves the company forward. Because maintaining the status quo means maintaining a non-existent business. We are about change.

Comments on Hacker News

How to build a product that takes over the world

I love this early interview with Mark Zuckerberg. I remember seeing it when it came out in 2005 and being impressed, even then, with how humble and pragmatic the vision for the service was.

The company is early enough that it’s still college-only and called The Facebook. It’s so small that you can see Dustin Moskovitz doing a kegstand in the background without any PRs diving in to tackle him out of the shot.

The thing I really love about the video though is Mark’s total focus on product (The Facebook) and service, and his utterly pragmatic view for how it can potentially evolve.

When asked, “Where are you taking Facebook?” he gives the following answer:

"There doesn’t necessarily have to be something more, a lot of people are focussed on taking over the world, doing the biggest thing, getting the most users.

I think that part of making a difference and doing something cool is focussing intensely. There’s a level of service that we could provide when we were just at Harvard that we can’t provide for all of the colleges and there’s a level of service we can provide as a college network that we couldn’t provide if we went to other types of things.

So I really want to see everyone focus on college and create a really cool college directory product that’s very relevant for students and has a lot of information that people care about when they’re in college. I don’t know what that is and it’s not everything that’s on The Facebook now”.

A more powerful and succinct endorsement for PG’s advice that founders should make something people want, do things that don’t scale and offer surprisingly good customer service would probably be hard to come by.

Here’s the video:

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 two.

However it also means you can be a huge contributor to your team while still 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 your hassles.

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 and of 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 you help 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 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.