the lows

25 Nov


We’ve all heard the startup “war stories”,  usually in the form of how hurdles were overcome to “smash it” or the gallant loser that could do nothing to stop his business falter. Now when reading these things I’ve always found it hard to empathise, because at the end of the day, I’m just not actually experiencing them, even the greatest writer in the world can’t make that happen. There often tends to be some new-found wisdom attached to these stories because time affords you that. I’m not sure if hearing it from the pit makes much difference either, you’ve got to feel it, then really not forget it, maybe it should be written down as it happening, not when it’s finishing, or maybe not. However, things really feel real when you’re in the thick of it, there are no anecdotes, no perspective, no money, only tomorrow, only bills, only lack of sleep, only walls not doors, the lights don’t turn on. It’s not hard, it doesn’t make you a hero, it doesn’t deserve sympathy, it’s not the way it should be, how it should be doesn’t matter because it’s the way it is.  The Lows.

managing your enthusiasm

3 Apr

If there is one thing that is likely to unsteady the ship as a sole founder is lack of enthusiasm. No one there to push you on. No one to confide in. No one to help when things are just not working. All these things can lead you down the dark path.


I was reminded just how bad this can get over the last week or so when I got myself into a rut while trying to solve a problem with my code.

To be specific:  I use fabric.js to draw shapes on an HTML5 canvas, however, I have pretty much wrote my own way to scale objects up and down as I found that if you have an image as a shape background then you get unacceptable pixelization – I tried the static and dynamic resize filters but they appear too slow. All was working fine but things were going wrong when you have a group shape as resizing wasn’t working correctly – amongst other things.

What I thought should have been an easy task turned into a nightmare. I was hacking away – essentially like a headless horseman – grasping at any straw to solve my problem without ever really thinking about the problem. The real problem was just that I wanted to solve the big problem without really knowing what all the little problems were. You see this so much these days with code, folk expect to find the solution to their problem on StackOverflow, and if they do, they copy-paste in the solution without ever understanding the problem. The day always comes where you can’t do this or it doesn’t really solve your problem and you only realise too late. That’s another story for another day though!

So the more days that went past the more I got frustrated by this problem. As each day ticked by my daily schedule (as I talked about before) was just a worthless piece of paper that I filled out each morning trying to pretend that I was in control. Each day my enthusiasm was dropping exponentially. This is where is really hit home having no one to talk over the problem with – talking it over with friends is likely not much use as no one is likely to understand what you are doing deeply enough to make any technical contribution. I was honestly at the point where I thought it was easier to just abandon Neonburn before I’d ever given it a chance. It’s amazing how the mind works, you’re happy to give up something you’ve given months and months of your life over to just because of one little problem.

Thankfully I started making small wins by edging little by little to a working solution, at which point the enthusiasm gradually startsed increasing. I started to understand the problem (I abstracted it mathematically rather than trying to write code to solve my problem). All of a sudden things were looking better and it’s amazing how good it feels getting these little wins. It’s important to accept that just because you can describe the problem succinctly it means that the said thing is easy to accomplish technically – think hoverboard!

So I’m not entirely sure of the moral of this story is. It’s probably along the lines of give yourself little wins all the time which of course means you need to set yourself smaller tasks. Walking away from something is actually the easy option, but then again so is battling away without really thinking about what you are fighting. However, I in no way believe that this won’t happen to me again. The only thing I remember thinking at the time that got me back on track was: this has happened before, and you always get it fixed even if it seems impossible at the time (this is assuming that you know it’s at least possible). I don’t want to trout out the whole “never give up” mantra as that sounds too much self-improvement-guy, it’s more a “never give up without having a proper logical converstation with yourself about it” – that’s not as snappy though!

getting over the line

27 Mar

Why is getting over the line so difficult? When developing software and someone asks you how are you getting on, you always inevitably hear “it’s nearly done, just this, this and this” to do. Next week “this, this and this” are the exact same things. Your first thought is then to say “do we really need these things done before we launch/release?” Surely if they’re not essentially then you just release? The problem is, this will boil down to how you define “essential”.


For example, I have a really hard time with the concept of a MVP (minimum viable product). Maybe I’m just not the customer for someone launching an MVP as I would abandon it in minutes if it was (A) difficult to do what I wanted it to do, and (B) bug ridden. The thing is, I can’t honestly understand why anyone would tolerate an app with these shortcomings. Is it just the case that a product has to be 10% better to convince some to buy/switch? That seems low to me. I’d say in my case it’d need to be at least 50% better to motivate me to switch. (Those we made up numbers!)

In reality, I think I’d be more encouraging of MVP+ – basically MVP that does something but I’m not expected to deal and workaround shitty bugs all day, and you wouldn’t be embarrassed if you asked someone to pay for it. I don’t see a meaningful B2B product as something that you can do throw together in 2 weeks.

Having said all this, I think it’s important as a founder to realise when you need to show what you have created – what is the point in doing it otherwise. I’m one of the guilty ones when it comes to holding off for an MVP++! There comes a day when you need to get off your arse and take a risk – but just minimise it and don’t turn customers off for good by releasing crap.

So in summary, if your product is good enough that you’d feel happy charging money for it (assuming you have a reasonable moral compass) then it’s definitely time to let the world see it, otherwise I’d think twice.

PS. 50% better than others and I’d happily take money for it Haha.

accountability and digital signs

17 Mar

One of the main concerns that you have as a single founder is forcing yourself to meet goals on a week to week (or daily) basis. Obviously the easiest way to achieve your goals (assuming you have taken the right step and set some) is to have customers pushing and pressing you for action. On the other hand, as a customer I wouldn’t be too happy having to micro-manage a startup on a daily basis. With co-founders this tasks becomes easier, as peer pressure kicks in and accountability becomes easier to manage.


One way to mitigate this problem is by using your blog to force a level of accountability. Given this, it’s with great pleasure (or more importantly as I said I would do in my last blog post!) I’d like to introduce my very-soon-to-be-live product Neonburn.

So what is Neonburn? Well it’s an online web app that allows you to easily create and design an interactive digital sign for display on an Android tablet or mobile device. The main benefits of using Neonburn:

  • Easy to create and design without any specialist knowledge or design skills.
  • The signs are interactive so you can control what happens when someone taps certain objects on the screen.
  • Signs remotely update when changed via the online app – ideal if you have new promotions that you want to advertise and don’t want to have to manually change each individual tablet, or maybe you don’t even have physical access to the devices at all.
  • No other apps on the device can be accessed once the app is deployed, and the device always boots to your sign, i.e. customers can’t interact with the device in ways that you don’t want them to.

The application is going to be of interest to you if you manage a retail store or public house and want to make your customers aware of your current promotions, while multi-site organisations will find the ability to remotely change signs in multiple locations simultaneously (without the need for a physical presence) invaluable. The interactive aspect of the signs are ideal for improving customer engagement in situations such as trade shows, or to create interactive displays at museums and galleries. It could also be used by retail stores looking to give customers an interactive tour of their products – without the need to directly involve sales staff. Finally it just makes for a very cool looking signs in your workplace – especially if you have propaganda a set of values or metrics that you want to ensure everyone knows about.

If you would like to be one of the first to try this out (or you want this product right now!!) then please sign up for the pre-launch newsletter on the website.

By next week the plan is to have the web app open to those looking to create some great looking signs and then by the end of next week to have the app on the beta channel of the Google Play Store. Obviously, anyone who’s keen to be involved in the process at this early stage can count on getting a discount before we open to the big wide world! Go on.

being a solo founder

12 Mar

So it’s been a while now since my last post and also since I decided to go solo and start out on business for myself. I’m not 100% sure that the former is due to the latter but it most definitely has had an impact. Writing posts is actually a good healthy habit that I have somehow managed to remove from my diet, and to be honest, has probably been to the detriment of creating my own business overall. The fall-off was mainly to do with the fear of writing about stuff that either A) Seems obvious or B) that no one wants to read about. I’ve now got myself over this by simply thinking who cares!


Given the above it’s with great pleasure that I present “The fuckwits guide to starting your own business“. This will probably turn into a more what-not-to-do set of posts given my success rate but it’s a case of you’ll get what you get.

First up. Going solo. That is, being a solo founder.

If anyone has not read the stuff by Paul Graham and so the idea has not been force fed that this is kind-of seen as a bad idea then let me tell you it is. Never do it if you have the option of getting someone on board with you, and this is as close as I can bring myself to say don’t bother starting up unless you have a co-founder – yes it’s that important. Unless you have the complete and total discipline to avoid getting sucked down the tar pit of either A) working too hard on the product development or B) working too hard to customer development, then it’s important to have the perspective granted by having more than one founder. I’d imagine that most developers with suffer from (A) more so than (B), and I’ve known that I’m suffering from (A) for quite some time and yet I continue to sink in the tar pit – I’m almost hoping that vocalising it jolts me into action (it didn’t with my last blog post about the very same thing though).

It was hard for me to even suggest that starting a business without a co-founder just shouldn’t be done, as invariably it’s never that straightforward and, in my heart (not head), I think it’s better to start something than nothing. Before deciding to go solo I had been down the rabbit hole of attempting to start a business with others but it always failed to materialise. 99% of the time the reason it failed to even get out the starting blocks was that the other folk were often not willing to take the risk that was involved of possibly having no meaningful income (by which I mean closely matched to their current income) for an extended period of time – possibly more a British (Scottish?) problem.

OK negativity aside what can you do to make it work? Obviously I don’t know or I wouldn’t be failing so miserably at it. However, here are the steps that I’m about to take moving forward:

  1. Be more accountable. I’m currently pretty disciplined on the number of hours I work – I use a timer to ensure that I do enough hours in a day. However a fellow startup founder Lee from suggested an accountability buddy! This struck me as a good idea but I felt I had to take it a step further and use this blog to make my accountability a bit more public rather than depending on a single person.
  2. Segment time better. Be more specific about how I spend my time during the day. So something like 8am-10am software development, 10:15am-11:15am write blog post, 11:30-13:30 customer development, and so on. I’ve tried this in the past and if memory serves me correctly it works well – this blog post is sort of evidence of that! Obviously there are days where this becomes harder to organise but it should be the exception rather than the rule.
  3. Get out and speak to people. Potential customers here are the obvious choice but it’s worth meeting other founders or investors even just to catch up. I want to prevent myself from going dark for extended periods of time as it’s never a good idea.
  4. Blog. People like hearing about what other folk are doing so I should do it more – many Scottish people have a curious trait of enjoying seeing others failing, so there’s always an audience! Also developers love telling people how their way of doing stuff is WRONG, so again, even with technical articles, always an audience.

Anyway, shit, over my allocated segmented time for this. Don’t worry going to pencil in another hour for Monday! Maybe more details of what I’ve actually created. Over and out.

It’s so easy to do things wrong even when you know they are wrong

9 Sep

Jesus. How could I be so stupid. Have you ever done that thing? You know? That thing! It sort of rolls like this.

You’re creating something, it doesn’t matter what it is, you’ve read all the books, been practising your art for years, you’re ready to create something big. You start building it, so utterly sure that you’re doing all the right things, then someone says are you doing *this*, confident you answer “Yes of course I am,” because it’s so obvious that you would be doing that thing as it’s fundamental. But you’re not.

That happened to me when building my product. I would swear I was doing what you should be doing, building something small first then incrementally expanding it based on user feedback, implementing their feedback, and iterating. Then came the question, “What about the many other users that could potentially use this product, what do they say?”. Ehhhhh, what do you mean all the other users? Oh shit. I knew I should have been talking to as many people as possible, it costs nothing, I almost thought I was, I really did, but I wasn’t expanding my horizon to the people that mattered. It seems so fundamental that you’ll not believe that someone wasn’t doing it. You’re probably laughing at me now.

Maybe everyone else is doing the right things and I’m just that loser. Probably not though. I think my point is to make sure you are doing the things you think you are doing. Just asking yourself if you are doing them may not be enough, have someone challenge you on it.

oh no, I just updated a ruby gem!

26 Aug

Are you a ruby developer? Do you want to manufacturer something to do? Well here is a quick tip. Take your beautiful working Rails 3 application that you started creating 6 months ago and type in “bundle update”.

I don’t think there exists a time when I have issued that command and then 10 seconds after it completed not thought “what the fuck was I thinking”. Just about every gem that updates seems to make several breaking changes. For real comedy value it’s worth doing it between major Rails releases, actually, I take that back, make that minor Rails releases.

This just doesn’t seem to happen with C++ libraries. When coding in C++ (which I do almost every day) I can reliably update to even major version changes and still be pretty much guaranteed that what worked before will still be working now. At most you get a “deprecation” warning. Not in the Ruby world, oh no, here progress is rapid but backwards compatibility is an afterthought. It really is no wonder that enterprises are so cagey about moving to, how can we say it, well in the words of Steve Yegge, hardcore liberal languages. There is something to be said for stability.

So is this a bad thing? As much as I would like to say that I think it is, I’m just not that sure. There is nothing more frustrating than using something that is not willing to change (I’m looking squarely at you Java). It’s the fact that there is no attempt to maintain backwards compatibility for at least a short period of time that doesn’t fill me with confidence.

These days you see many people picking the latest and greatest technology to build a business on. This always makes me squirm just a little. This may be OK for a small business with technical founders. However, it makes little sense for a company with shareholders where employees can leave at any time. I certainly wouldn’t want a company I’d invested my money in being in left open to the vagaries of change quite so much.

stop trying to show how smart you are

23 Aug

Sitting feeling bright and somewhat giddy with my own self confidence I decided to dust down my copy of “C++ Template Metaprogramming” by David Abrahams and Aleksey Gurtovoy. Thinking I really need to be the master of something and further thinking C++ template programming was that “thing”. I approached the task with some gusto for at least a few days hours minutes, however, as with most advanced study you really have to be willing to dedicate your life to it. It’s never long before the inevitable gloom of reality sets in and you realise that this is more than an afternoons work. Without much control your brain starts telling you that there are much more important things you could be doing. Thankfully for everyone else on your team you stop and decide that it’s just not worth it.

The fact is that writing code that only those who have decided to dedicate a fair chunk of their life to is never going to be the right choice. There is nothing worse than trying to understand code like this. There are times where it pays to be smart, like when you have a better (much) faster algorithm, or doing something saves you hundreds of lines of code. But most of the time you see this kind of code it’s people just trying to prove how smart they are.

Now C++ is not alone in this. Ruby has exactly the same problem – you can get stuff happening as if by magic. I could be wrong but I imagine most people read code from top to bottom, working line by line, they don’t expect code to be auto generated or happen as some elaborate method_missing technique. Sure I can maybe relax my vitriol for those building frameworks where things are being used in some generic unknown context. However the vast majority of applications out there don’t have to deal with these problems. The biggest problem these applications face is that the developers creating them want to architect some elaborate framework to fit a very specific use case – it almost makes me cry. I’m not sure why as a profession we don’t revel in an approach that oozes simplicity. This is certainly what the smartest developers I’ve working with have always managed to do.

questioning the truth

9 Aug

So, a colleague once told me of a story where an important academic paper (well important in its respected field) presented results that turned out to be false. Not exactly NEWS (think more first-world-problem) but this paper was peer reviewed and appeared in a prominent journal but still managed to slip through. This paper turned out to be cited in many places and only when my colleague tried to reproduce the results many years later did it become apparent things were not right – it turned out to be a bug in the original authors code that caused skewed results in his empirical analysis.

The thing is though, this kind of shit happens all the time, and it’s really fucking annoying. If you attended any conferences, meetups, usergroups, etc this practice is rife. Someone standing in front of an audience says something and it’s almost always instantly taken as fact, without the need to provide sources of proof. The audience then believe this to be true, as in many causes they are in no position to prove otherwise, and those that do voice an opinion are seen as being “aggressive”. The sad fact is that most of the time errors/hearsay go uncorrected, and people walk away misinformed.

The fact of the matter is that you really need assume what someone has said might not be true, do your own follow up and make decisions based on what the evidence supports. Remember that many people have agendas, and also that it’s very possible that speakers are talking about something that they have only a rudimentary understand of. Don’t blindly assume that what someone purports to be be true is actually the truth.

writing code used to be simple

4 Apr

Not that many years ago, though more than I care to remember, the process of writing code started with pen on paper. I’m not talking about 1970 here where you had to apply for compute time on some mainframe to see your ideas come alive, rather 1995 where it seemed the normal practice was to encouraging us disobedient students to first distil our ideas (and code) on paper. I’m gathering that this practice is largely forgotten? Despite its disappearance this can still be good practice but is made difficult by the increasing complexity of modern code libraries and frameworks.

Take Ruby on Rails for example. This used to be the poster child of getting an application up and running quickly. This might be still be true if you have years of experience developing Rails applications but for a newbie, forget it, you are going to struggle. The introduction of the asset pipeline, amongst other things, has made learning how to use Rails a labour of love.

It’s not just Rails though. A lot of the code that you need will already be wrapped up in a library written by someone else. Creating a modern software application is essentially just a case of rearranging these packages into a new unique order. In fact, the need for the order to be unique can probably be dropped.

Using these libraries is good though? Right? I mean we should never “reinvent the wheel”?

So how many times do you find yourself spending more time trying to figure out how the fuck to use some library than if you had written it yourself? No-one really expects there to be detailed documentation, which is just as well, as in general you’d be thoroughly disappointed. Maybe it’s because I’m dumb, but figuring out how to use a library can be a complete time sink. I mean, I hate to encourage this, as it seems like I’m committing a heinous crime, ’cause that’s what I’m told I’m doing, but just write the code yourself if it gets it working quicker for you. Obviously don’t rewrite the exact library that you are shying away from using, that is just stupid, but if you only need a subset of it’s functionality then go for it.

Never forget though, there will be a team of astronauts telling you that’s not what you should be doing. They will be spouting dogma, about this and that. However, if abandoning some well written (and not so well written) rules allows you to create a product that people use and love then tell the astronauts there are people who want to hear their shit on the moon and let them go there.