Martin Rue

To Be Productive, Be Prepared

2013-01-04T00:00:00-08:00

To Be Productive, Be Prepared

January 04, 2013

Often we think of motivation and productivity as being connected by a sort of feedback loop. When we're motivated we make progress and seeing that progress keeps us motivated.

But that relationship is missing something important.

Motivation is the willingness to want to do something. This is of course an important first step in potentially being productive. We are better at things we want to do, rather than things we're forced to do by others, or by our own self discipline.

But motivation is nothing more than that. It helps us start, but it doesn't mean we'll finish, or even produce half of what we want to. Even when we are motivated, if we don't make enough progress our motivation has a way of epically disappearing.

I could be 100% motivated to learn to speak German, literally jumping out of bed each morning to do another lesson. But what if my tutor is too hard on me? What if she gives me work far beyond my ability? Of course I won't progress as much as I want to and my motivation will start to diminish.

Motivation by itself gives us the willingness to do something, but nothing more. Once we make a start, the game changes and it becomes about knowing how to make progress.

Knowing how to make progress and making progress are two different things, but we often conflate them and treat them as the same thing. We basically jump into the task and start. Only, it's not really starting because we're repeatedly stopping to think about design, architecture, security, how it will look, how it will work, which database to use [the list goes on].

But knowing how to make progress before you start is important. Before you start your next task, complete the following in as much detail as possible:

Describe exactly what will the new [feature/bug/work unit] will do
Describe exactly how it will do it, giving technical details
If it has a visual element, quickly sketch what it'll look like

If you can do this before you start, you'll have a good idea of:

What you're doing and what the definition of complete is for this work
What to add and what to change in order to make it happen
Roughly how it looks, which often clarifies details of point 2

Your mileage may vary in terms of how much detail you're able to think about before starting, but the more detail you have the fewer interruptions you'll need to bear while actually trying to make progress.

Productivity doesn't come from feeling motivated, it comes from knowing what you need to do in enough detail that you can complete it without continually stopping and losing your focus.

In the end, it's all about preparation.

You need to be prepared in order to be productive, don't just expect it to happen as a side effect of feeling motivated.

Stay Young Enough To Try Anything

2012-11-15T00:00:00-08:00

Stay Young Enough To Try Anything

November 15, 2012

"I am not young enough to know everything."

This is one of my favourite quotes. Not just because it's a clever joke about young people often believing they know better, but because of the quality that it alludes to – one I believe is really important in being creative.

When we are younger we tend to think we know much more than we actually do. As we grow up we become aware of two things: how much we still don't know and how lots of the stuff we did know is now constantly changing.

Eventually we reach the same conclusion as Oscar Wilde. This seems like a good thing – a more mature perspective of the true state of things – but we have to be careful not to lose a powerful quality with it.

The quality I'm referring to is the willingness to try.

We come to realise that projects we once thought would take a night actually take weeks. We learn that something always goes wrong. We know that there will be hidden complexities we're not expecting.

Knowing this isn't a bad thing, but it can change the attitude we had from our younger days when we'd say things like "Screw it, I can build an OS in a weekend!" and then try and do it. It starts to become easier to talk ourselves out of big ideas, or believe we need to read 3 or 4 books on data structures before we even attempt to solve this complex problem because it has a funky data structure.

The fact is everyone has more to learn, and in the scheme of things we all know nothing. But the last thing you want is for this to discourage you from trying. We learn best by trying, and if you start by looking for complexities and potential problems, trust me you'll find them, and you'll end up trying very little.

So let's not be young enough to know everything, but let's stay young enough to try anything. Maybe you'll create some awesome things, maybe you won't, but the experience of pushing yourself into those unknowns and learning from them is invaluable.

Startups Are Not Sexy

2012-11-11T00:00:00-08:00

Startups Are Not Sexy

November 11, 2012

Over the last 10 years the number of people I know working on their own startup has probably increased by a factor of 10. Hundreds of startup success stories and movies such as The Social Network have popularised the idea of building your own startup, just like TV shows such as The X Factor have popularised the idea of being a singer.

Now everyone wants to build their own startup, buy their respective Phoenix Club and turn it into their ping-pong room. The only problem is that the motivation should be toward solving a problem, not 'building a startup' because it's cool to tell your friends about and makes you feel important.

A startup only exists as a result of the desire to solve a real problem and by going through the long and difficult process of building the product your users want to pay for. Often the problem is something you personally care about and want to solve for yourself, or seen solved for some other reason.

The reality is nothing like what is portrayed in movies and on the internet. You spend an insane amount of time going through the cycle of getting it wrong, learning and attempting to getting it right again. You sacrifice most of your free time and have to be disciplined enough to make constant progress. It's hard work.

We tell people that during YC there are really only three things you should focus on: building things, talking to users, and exercising. Maybe this is a bit extreme, but the point is that early on in a startup all that matters is figuring out how to make something people want and doing it well. Don't spend all your time networking. Don't hire an army of interns. Just build stuff and talk to users. – Jessica Livingston

The only thing that matters in the beginning is your product, and the only way to build the right product is by talking to your users and understanding what they want. No amount of talking to other people about what you're doing, attending events, reading books or anything else is more important. When time is as scarce as it is in a startup, you have to make sure you're not wasting it on things that don't directly help you reach your goal.

So trust me, building a startup isn't sexy and my friends aren't envious of the evenings and weekends I spend behind my desk writing code. When I attend events, hiding the anxiety that I should be building the product instead isn't fun. And I certainly don't spend my days zip-lining from the roof into a pool.

But my co-founder and I are passionately focused on solving the problem and building our product, the startup just happens as a result.

Let's Get Real About Ambition

2012-10-26T00:00:00-07:00

Let's Get Real About Ambition

October 26, 2012

Do you have a goal or ambition?

Maybe you want to build a startup, work on that side project, learn a new language or become better at something you already know. Most of us aspire to something.

Being ambitious is a good thing, but the problem is it's too easy. It's like the conversation you have with your friends about what you'd spend the lottery money on if you won. It's fun, it makes you feel good for a bit, but ultimately it's completely useless on its own.

Let's get real – what are you doing every single fucking day to make it happen?

"Too tired after work"? "Can't get motivated enough to make a start"? "Really busy at work lately, no time"?

You know what? Accept it. It's life's ugly truth – most people lose around half their waking hours to earn money. I do too. But you sleep for 7 hours, that leaves 79 free awake hours in your week. Your 9-5 uses up ~40% of your time.

And yes, it's hard work – of course it is. If it wasn't everyone would reach their ambitions and we'd all have everything we want. The fact is, if you can't push through that with discipline, excitement, motivation, Red Bull, whatever the hell works for you, your ambitions will always be ambitions.

Being ambitious isn't impressive. Achieving your ambitions is impressive.

Ambition is cheap, show me the hard work.

What Is 'The Zone' Anyway?

2012-06-21T00:00:00-07:00

What Is 'The Zone' Anyway?

June 21, 2012

Recently I've been thinking more and more about the zone. I've been trying to work out what it actually is. Most often it's described as being in a super productive state for short periods of time, where the best code you've ever written just flows from your fingertips.

That certainly describes what it feels like to be in the zone, but what causes this state in the first place? And why can't we just enter it any time we like and have it last beyond the typical short bursts that most people experience it in?

Well, I believe we can. While there are lots of factors that affect our ability to get into (and stay in) the zone, I think there are fundamentally just two things need to be right for it to happen. Before getting to those two, let's look at some of the others:

Focus

The zone is often said to be a state of intense focus, so focus is more of a synonym than an individual attribute, but in any case, it implies some of the other factors.

Energy

You'll struggle to find someone falling to sleep while in the zone. In fact, the portrayed image of being in the zone is quite the opposite – someone alert and awake, passionately engaged in what they're doing.

It's really important to have energy. If you're barely maintaining consciousness due to a late night of cocktails, bad chat-up lines and a story you could never tell your mother, getting into the zone is going to be difficult.

No Distractions

Another approach for getting into the zone is to avoid all distractions. Some people are more sensitive to distraction than others, but we should always aim to minimise the kinds of distraction that pulls our mind out of what we're currently doing. Avoiding the context switching cost is a big win.

Music

Some people find that listening to music helps them get into the zone. I listen to music when I'm writing code and I do think it can be distracting, but often much less distracting than the average office conversation. Music is a personal thing and I suspect it doesn't affect our ability to get into the zone that much either way, although if it makes us comfortable, perhaps being comfortable does.

But What Matters More...

While having a sharp focus through being energised and avoiding all distractions can really help us get into the zone, we're still treating the zone as though it's some magical, random state that we don't truly understand.

It's not.

Stop worrying about what type of music you're going to listen to, or what the view out of the window should be, or how you're going to block out the blatantly intentional heavy breathing of Rufus sat opposite. We get into the zone because we want to, and above all, there are two things that make us want to.

First, we really need to give a shit about what we're doing. This is so often ignored when talking about productivity in general. Remember back to the days of high school when the nerdy kids would get awesome grades at difficult subjects. They got awesome grades because they enjoyed it. People rock way more at things they enjoy, and enjoyment is much easier and far more effective than discipline. We need to be excited about the problem and feel like all we want to do is work on it right this minute.

Second, we need to know how to do it. The overwhelming desire to start work is useless if we can't because we don't even know where to start. We'll jump into the work and be idle 10 minutes later as we uncover many of the finer details we skimmed over when thinking at much higher level earlier.

I'm not advocating big upfront design here, but this doesn't mean we get to stop thinking about problems and start writing code instead. Jumping into writing code immediately is often not the smartest thing to do.

Concentration and having clear goals are key components of maintaining flow, and that's exactly what the zone is. When we're in the zone, a set of well understood achievable goals enables us to make continuous progress. Seeing constant progress is an amazing motivator, making the zone a sustainable state.

I rarely find myself coming out of the zone because the view out of the window just isn't working or because someone is breathing too heavily. I come out of the zone once I don't know what needs doing next or how to achieve it. I come out of it because I'm blocked from making progress.

Too many people treat the zone like it's a mysterious state that eludes us for intangible reasons. I don't think it is. We just need to think about the problem well enough to see potential solutions. We need to be excited about it. The zone comes pretty naturally after that.

So let's stop convincing ourselves that we're going to become one with the zone once we buy those £300 noise-cancelling headphones. You're not going to get into the zone if you don't understand what you're trying to achieve or don't enjoy trying to achieve it.

Talk About Your Stuff

2012-02-01T00:00:00-08:00

Talk About Your Stuff

February 01, 2012

Growing up I was a pretty shy kid. I didn't talk to many people and I loved hacking away at things almost in secret. I would get pretty nervous if anyone asked me what I was doing. I guess I felt like they might judge me, or tell me that I didn't know what I was doing. The truth is, I probably didn't know what I was doing, but back then I couldn't have dealt with being told that.

Years later and I sometimes find myself doing the same thing. I sometimes don't really talk about what I'm doing, and yet, on the occasions I do it has been totally worth it. I used to think that I'd bug people too much if I talked about the stuff I was doing, or appear too self-centered, but I've realised that all of these concerns are just over-thinking.

While you certainly can bug people by mindlessly ranting on about something you're working on, there are also ways to tell people what you're doing without bugging them. After all, when I hear about projects that my friends are working on I'm always curious and interested. Seeing the occasional tweet or overhearing the occasional conversation doesn't bug me at all. There's no real reason to think I'd bug everyone unless it was all I ever spoke about.

Talking about your projects has huge benefits. I think it makes you a more interesting person; people start to learn more about what you're doing and what excites you. Of course, anyone who cares to look further may even give you some feedback, or at least their initial thoughts. For anyone who your project is relevant to, it makes them aware of it, and maybe they'll even use it or suggest it to a friend.

In the end, if you're not talking about your stuff, it's quite unlikely others are. Don't worry about bugging people, those who find it interesting will be glad you spoke about it and for everyone else it's not a hardship to ignore it. But don't only talk about your stuff, talk to others about their stuff and be interesting in others ways.

And yes, there'll always be those who disagree with what you're doing, or how you're doing it simply for the sake of being disagreeable. It has taken me a lot of years, but I think I can finally brush off people who are simply being unconstructive, focusing my energy on those that aren't.

So, talk about your stuff, it's the sure-fire way of making your stuff better.

Ask Questions

2011-12-31T00:00:00-08:00

Ask Questions

December 31, 2011

Sometimes I find myself in situations where someone appears to know exactly what my problem is. Not only do they appear to grasp the entire situation from a mere few words, they have also wasted no time in determining (from the possibly infinite pool of potential choices) the best solution. I often wonder if their costume is under their clothes or if they just change into it really quickly when required.

While there could be a few exceptions to the fact that it's severely unlikely someone has really nailed your entire problem domain and a solution in a mere 10-word conversation – such as perhaps Linus if you were talking about kernel programming – I'm calling bullshit every time.

There are too many programmers (and not just programmers, in fact) who are just big soft balls of ego. It's cute, in pitiful kind of way. They are also really easy to spot. Just ask them a question you know they won't know, and yet against all odds, they'll know it. Well, they'll make you think they know it by giving you an answer and then they'll go and save a child from a burning building.

You can't make good decisions without understanding, and to build an understanding of the problem you must ask questions. If you're not asking questions, you're substituting them with assumptions which simply isn't going to help anybody.

The smartest people I know would never tell you "use X", "you're doing it wrong" or throw phrases around like "best practice" unless they had asked enough questions to fully understand the context. Neither would they answer a question for ego's sake.

If someone is giving you lots of advice while asking few questions, do yourself a favour and stop wasting your time. It's surprising and worth remembering how the loudest and most confident ones are often the ones who can help you least.

Agile – 'A' For Adjective

2011-10-03T00:00:00-07:00

Agile – 'A' For Adjective

October 03, 2011

Are you doing happy? No, seriously, are you doing happy? OK, what about this, are you doing flexible? You probably think I'm talking nonsense, and that's because I am – I'm using adjectives as nouns.

In addition to being entirely incorrect, there's another more subtle issue with using adjectives as nouns. First, let's consider what a noun actually is. A noun is a named thing, an object or an idea, right? Nouns are generally well defined things, rarely ambiguous in meaning; a table is a table, a payment is a payment and a rule is a rule.

If I ask you 'do you have a table?' or 'have you received a payment?' you don't need to pause to consider what it is to be a table or a payment in order to answer the question.

On the other hand, if I ask you 'are you happy?' or 'are you flexible?' it'd be normal for you to consider the question more carefully, since, what does it mean to be happy or to be flexible? An adjective places an attribute on a noun to better describe it, and sometimes that attribute can be ambiguous, or at least have different criteria for different people, rightfully causing us to consider it more carefully.

When we use adjectives as nouns, it suggests they are well defined things that we all agree upon. 'Are you doing happy?' makes it sound like we've all had a lovely big committee meeting, drank coffee for a few hours and decided on an absolute definition for happy. We've made happy into a named, well defined thing. We've made it more absolute. But when we use it as an adjective, i.e. 'are you happy?' it keeps the definition more open and more relative.

And this is the problem with the question 'are you doing agile?'. It makes agile sound like a well defined process that you're either following or ignoring. But agility is an attribute that should describe a noun such as your organisation or your team. You can be agile, sure, but that won't necessarily be the same definition of agile as someone else.

Of course we all have roughly the same goal in aiming to be agile in software development. We all want to be able to respond to change as quickly and as safely as possible. To large teams, being agile might require having a well defined process that allows work to be prioritised and delegated efficiently across the team. To tiny teams, being agile doesn't necessarily have the same communication challenges and might not require a process such as scrum, but instead work better with a lighter approach such as kanban.

Some will argue that testing is the best way to agility while others will argue that simplicity is the best way. Some will insist that pairing produces the best results and others will preach the benefits of short iterations and daily stand-ups. The point is, all of them are probably agile in ways that work for them individually.

Let's start asking people if and how they are agile, rather than asking if they're doing agile. Asking if we do agile makes it sound like some kind of strongly defined process that can't be moulded into your organisation in a way that works for you – it most certainly can.

ZZüy – A Lesson In Perseverance

2011-09-17T00:00:00-07:00

ZZüy – A Lesson In Perseverance

September 17, 2011

In the last post I said that we actually need to do what we want to become better at, as well as reading and talking about it. But there's something else.

I remember when I was first introduced to programming by way of watching my older step brother type the then–very–confusing words gosub and rem onto a bright blue screen. It was exciting. I had no idea what this cryptic language did but I was definitely hooked.

As time went on we got a family PC and my first attempt at programming it wasn't exactly successful. As it turned out, you couldn't put BASIC in .html files, which seemed like such a good idea at the time. I quickly realised I had a lot to learn and decided I'd learn a language that I could use on the PC.

C was nothing like BASIC. It was far more exciting and looked much cooler with all its obscure syntax and low level semantics. As I started to understand things like files and sockets I became fascinated with the idea that I could build programs for other people to use.

After playing with C for a few months I felt confident enough to build something real with it, and it just so happened I had an idea I was pretty excited about. I wanted to build a simple tool that allowed two people write code together over the Internet.

There'd be two boxes. You would type your code into the box on the left, hit send and your partner would see your code in their right hand box. They could copy it across, amend it and hit send to send it back. I distinctly remember being in awe of the fact that by using a TCP socket for sending data, the other person could be on the other side of the world and this would still work – much more fun than BASIC.

So I got cosy with socket(), listen(), bind(), connect(), send() and recv(). A few weeks later I had an early version working and I couldn't wait to test it. It worked perfectly over localhost, but I wanted to see this work over the freaking phone line!

Fortunately my good friend Jacob was on hand to help. I sent him over the wonderfully small executable and gave him my IP address to connect to. I honestly could not believe it when he connected and his code appeared on my screen. I made a few changes and sent it back. It was awesome!

But then something weird happened.

Jacob's code had a series of ZZüy characters at the end. They disappeared on the next update, but then came back. I asked him about the strange characters I was seeing, but he couldn't see them. None of his code was being lost, but these extra characters were becoming very annoying.

Over the next day or two I trawled through the code line by line, desperately trying to work out how these extra characters might occur. It was tiring, and each time I thought I had found the issue, as if by magic, there they were again. I came to passionately hate the sequence of characters ZZüy. I think I still do. I'm biting on my fist right now.

It was actually a little soul destroying each time we retested a potential fix only to find it was still screwed, because after seeing those damn ZZüy characters come back, I had nothing. I had to go back through the process and find some other explanation. I like to consider myself an optimist, but a real test of that is whether you're still optimistic when you have nothing.

After another 10 or so different attempts I finally stumbled upon it. This time, I was absolutely convinced. I had been reading an article about string buffers in C when it mentioned zero–termination, and that's when it hit me. A string buffer needs to contain a zero character to signify the end of the data. It finally all made sense. Suddenly I could imagine how strlen() might work by counting until it found the zero. Suddenly I knew what the Hungarian word psz meant. And, of course, I was seeing random extra characters because the displaying of the buffer didn't know when to stop reading because there was no zero. Oh yes – this time I had definitely nailed it.

So I took the return value from recv() – the total number of bytes received – and used it as an index into the buffer to add the zero terminator. I compiled. I linked. Well, those happened together but I'm trying to build dramatic effect. I took the new executable and sent it across to Jacob. And then I waited.

A minute later he connected and over came his code. His particular choice of sample code this time caused a scroll bar to appear, but were those pesky ZZüy characters still there? Surely they were gone now that the buffer had been zero terminated. Surely.

I scrolled to the bottom of the box praying that I wouldn't see them. But the bastards, in all their glory, were still there. A group of 16 ZZüy characters staring back at me saying "nice try, but better luck next time loser". I couldn't believe that I'd failed yet again. Back to the drawing board.

The next few hours were shared between outbursts of crying and trying every shot–in–the–dark approach I could come up with to prevent ZZüy from ruining my life. But I persevered, and herein lies my point.

When Einstein was asked why he was so smart, he answered:

It's not that I'm so smart, it's just that I stay with problems longer.

I may have had an abundance of ZZüy characters, but I also had the perseverance to not let this problem beat me, however unenjoyable the process was going to be. It was probably going to take much more time than I had hoped, but ultimately I knew there was an explanation waiting to be found. I just had to persevere with the problem to better understand it.

In reality everyone has their own threshold of perseverance, and we each have different factors that cause us to hit it. Some people become frustrated very quickly, hindering their ability to persevere through the problem. Others simply lose motivation due to lack of progress. The key is to use failure positively to drive perseverance. Each failure takes you a step closer to finding a solution so long as you are learning from it – the only true type of failure is quitting.

In the end, Jacob admitted that he had been adding the ZZüy characters onto the end of his code manually ever since he'd realised the zero termination stuff fixed the bug. I don't think I've ever been so mad and so happy at the same time.

Do

2011-08-31T00:00:00-07:00

Do

August 31, 2011

I often go back to my parents house on weekends to visit, and for nearly as long as I can remember my sister and I have enjoyed the occasional game of Counter Strike while I'm there.

Ok, that's not the entire truth. We play it relentlessly and very competitively. Neither of us can imagine the horror of being the one with fewest kills at the end of the 20 minute round. I mean, the shame of it!

About 2 years ago, having both become as good as we could, we invited Mum to play. Of course she wasn't falling over herself to transform into a teenage internet gamer and kindly refused. But my sister and I were persistent, especially once we realised a brand new player would give us a much better chance to one-up each other.

Eventually she cracked and we got her playing. It took her a while to get the mouse movement synchronised with the WSAD keys in order to make coherent movements, and we certainly didn't have friendly fire turned on.

It didn't take her long to get into it though, and after not long she was getting pretttty pissed at being shot in the face – understandably. My sister and I felt much better about not being bottom of the kill count, despite how poorly we did.

Fast-forward to today and we all still play CS regularly. In fact, Dad also plays now. So do the in-laws. After games we get into big debates about how badly one of us screwed up in the last game, or how one of us has let the other one down. CS has become our Monopoly I guess, and it's awesome fun.

But something interesting happened. Now, you have to understand that this is hard for me to talk about. I never thought this could happen, ever. My Mum got better! I don't mean in the ability to turn corners kind of way. I mean she now regularly kicks everyone's ass when we play. Yes, my Mother now gets most kills while my sister and I get whatever she didn't see while playing and peeling potatoes.

And I'm only exaggerating a little here. Compared with the first day she played, she has become way better. This is probably not too surprising since we know that people get better at things over time, right?

But it's not simply the passing of time that makes us better at things, it's what we choose to do in that time. While we may choose to read, to talk, to observe others, nothing can replace the old adage. Practise makes perfect. Sometimes we must read, talk and observe others in order to do better ourselves, but we must also do.

If we want to become better programmers, reading will certainly help by introducing us to the doings of others. Similarly, so will attending frequent user group meetings and talking to other smart people. Likewise, watching hundreds of screencasts will show us how the best do what they do, but absolutely nothing will make us better than actually writing lots of code ourselves.

Two years ago, my Mum would have been delighted if she managed a single kill in a round. Now she isn't happy unless she's in first position, killing most of the opposing team herself. All she did to get there was play.

Do, as often as you can – it's that simple.

You Know What They Say About Assumptions

2011-08-23T00:00:00-07:00

You Know What They Say About Assumptions

August 23, 2011

Do you know what they say about assumptions? Well, they're wrong. Before I explain myself, let me show you something – take a deep breath.

Yeah!

I can't help but notice that not having made the mother of all fuck-ups isn't really much of a consolation. How bad exactly would even just a few assumptions have been here? But most of us don't want to make too many assumptions – what if they're wrong?

Let's Be Clear

Every assumption you make will be wrong. To members of group A, you'll appear totally batshit crazy. But to members of group B you'll have made software that doesn't make them think they're flying a plane. And trust me, very few of your potential users are aspiring pilots. Meanwhile, aeronautical-inspired competitors of your obese dog training site will be losing customers to an alternative that doesn't make them work so hard.

Don't Make Stupid Assumptions

For your own protection, you should aim to maximise the size of group B while minimising the size of group A by making sane assumptions. Making a sane assumption means understanding what your target group of users want. You should spend time in relevant places and build a picture of your target user, and then optimise for them.

Outside of your target user group, there will still be relevant users. As such, some assumptions should be configurable, i.e. the sensible default complete with unobtrusive settings dialog. However, you should be very careful of trading off your vision for the product with configuration options that change that vision for groups of exceptional users.

If you try to please everyone, you'll build a hideously complex state machine that can be in about as many states as a plane, and you'll be the engineer. Just try and imagine what's underneath that interface. Here, have a sick bag.

Assumptions Are Opportunities

Assumptions are opportunities to make your product better. If you assume users are who they say, you can simplify the sign up procedure. If you assume users own the credit card they're using, you can drop 3-D Secure and make paying for things easier.

Don't make the mother of all fuck-ups by not making any assumptions at all and producing the puke-inducing thing above. Use assumptions to simplify and create an experience that will make your users think you wear a cape.