Tag: impact

  • The French Ski Problem

    The French Ski Problem

    skis mountain
    Credit: Flickr / Nils Rinaldi

    In 1988, there was a revolution in the ski industry. Previously, skis had been straight-edged and the skier controlled them through force and incline. The new shaped skis were parabolic, with a side-cut edge that caused the ski to turn when introduced to the snow. Pressure causes the ski to bend: more pressure, more bend, tighter turns.

    The whole way of skiing changed as a result. The stance got wider, the centre of gravity, lower. The turn became a way to accelerate, rather than a way to stop.

    But the French wouldn’t let a little thing like physics get in their way. They adopted the parabolic skis but continued to ski upright, legs close together, weight slightly back, cigarette and/or cellphone optional. They still managed to achieve impressive speeds – to even qualify as a ski instructor in France, you need to pass the “Test Technique” skiing within a percentage of the time of a professional skier – but they ski like no one else in the world.

    When talking about innovation, we often see what I call “The French Ski Problem,” the risk of focusing on novelty without application, rather than incremental improvements somewhere more widely applicable.

    If you are an innovator in the ski industry, you could make:

    1. Improvements to parabolic skiing: Useful to everyone.
    2. Improvements to straight ski technique on parabolic skis: Useful only in France.
    3. Improvements to straight ski skiing: Not useful anywhere.

    To which you might ask, who is worrying about (2) or (3), and the answer in skiing is: I have no idea. But in Software, (1) are human problems, (3) are made up engineer problems, and (2) is the nebulous space in between – often real solutions, to niche problems.

    (3) is infrastructure with no human benefit, because nothing actually wins out on technical superiority (e.g. that test framework that nobody actually uses). (2) is infrastructure with human benefit, that allows for better speed, or increased stability (e.g. Twitter’s move of their infrastructure, it’s been a long time since I saw the Fail Whale). And (1) addresses the pain points of real humans, allows them to do their jobs better, live richer lives (e.g. the invention of the smartphone). This is where we connect people to the people they love, even when they are thousands of miles apart. Where we make sense of huge quantities of data, so that they can make better decisions, or have improved medical care. Where we create platforms that allow people different and novel ways to make a living.

    My main point here is impact. A small incremental improvement of (1), is vastly more impactful than anything done at (2), let alone (3).

    A question to ask is, are we building infrastructure, or are we building a product (1)? If we’re building infrastructure, does it enable the product (2), or are we just… building infrastructure (3)?

    Real innovation doesn’t happen in a vacuum, it comes from solving problems. There’s a reason why incredible earthquake preparedness innovation comes out of New Zealand, that mobile innovation is brightest in the developing world (where cellphones are often people’s primary, or only device), and Silicon Valley is an endless source of products for rich young men.

    Thanks to Alice and Linda who helped with this post.

  • Guerilla Ruthlessness

    Guerilla Ruthlessness

    Sneaking cat
    Credit: Flickr / Hans Pama

    I used to be very into “productivity”, but I’m somewhat over it lately. Whilst I still favorite the articles on twitter to read later, I’ve stopped buying books about it.

    There’s a lot of advice out there, keep a todo list! Keep a done list! Keep a don’t list! Various ways to arrange, and schedule, and avoid, and ACHIEVE. But find your way through this, and then there is the problem, productivity doesn’t mean effectiveness. If you’re getting a thousand things done but never the most important thing, you’re gonna have a bad time.

    For me, given what I do, I distilled everything down to an idea that has not changed in the past year:

    You get 4-6 hours of good coding time a day. Be ruthless about finding it.

    Of course, my execution has evolved and changed and will continue to. I used to be more overt about it, I would tell people I only checked email once a day. And it’s been easier and harder at times – easier when I was working on my own thing, mostly by myself and just sending stuff out for code review. Hardest it’s ever been now, when I have two engineers fulltime sending me codereviews, another part time on my section of our project, and then two more on another team wanting the occasional code review or advice. It’s easy to feel pulled in so many directions and scattered, like a day has gone by and at no point did my thoughts follow the track they were on to their natural conclusion.

    And it’s hard to be ruthless. We know that guy who is ruthlessly selfish, and gets a lot done but never helps anyone else, who’s always achieving his own thing but anyone who needs his input needs to fit in around him. We don’t want to be that guy. And we know it’s harder for women too, who are punished for being selfish – I remember I once got feedback saying “6 months ago you were a bit slow at this, for this understandable reason” and thinking would you have said that about a dude? Really?

    But it’s necessary. I look at people who are successful, and I see them finding a way to be a little bit selfish, carve something out for themselves so that they can keep having impact. And people who are just as brilliant but who seem to be stalling, they’re not managing to do that. There’s a big difference between the successful person finding a way to be a little bit selfish and the jerk. The jerk, it’s a way of life, they don’t realize they are doing it and that we’ve noticed means we’re probably safe from becoming them. The successful person is just carefully carving out a little bit of time that isn’t dictated by other people to do their thing. And it looks like it pays off.

    So now I carry out what I am calling “guerilla ruthlessness”. Which means I’m carefully picking off the ways that I can keep my focus without inflicting that goal obviously on other people and annoying them.

    Email.

    I don’t have it open all the time. I don’t check it that frequently. I just don’t tell anyone not to expect a reply from me. It turns out, I don’t need to tell people to IM me if it’s important, they just know. And they do, or they speak to me. Normally I open it up between tasks, which is probably more often than really necessary, but people feel like they get a decent response time whilst I’m never interrupted by new mail.

    I get the digest for everything. This means I get the day’s messages for that group (e.g. my team) I get it in 25 message batches. Then I skim the headings, read anything that stands out (it’s amazing how much doesn’t) and archive.

    I don’t send it. Seriously the #1 productivity tip of all time. STOP SENDING EMAIL. It’s amazing how much less you get if you don’t send it in the first place. There’s some thing where I can’t reply to messages in our team group because I get the digest and it’s turned off in the web interface. So I haven’t responded to one of these emails in over 3 months, and this has not been a problem.

    Headphones, all the time.

    I have these great chunky purple headphones. They look like they keep the sound out. They don’t, really. Unless I’m in the zone and someone sneaks up behind me. It just means I can ignore people without seeming rude until I finish my thought or what it is that I’m doing.

    “Just let me finish this…”

    I do things in small increments. It’s less to load in my head, less barrier (intimidation) to starting, and it doesn’t take hours. So when someone says “Hey Cate, do you have a minute?” or “Cate, can you do this code review”, I say “sure, just let me finish this” and then I finish it, or at least to a part where stopping is no big deal (like the code is written but I need to write the tests). Turns out, if someone is asking you to help them, they won’t usually mind waiting 5 minutes and will just go and get a drink, or do something else. And then whilst I’m reviewing their stuff, or whatever it is, someone will often be reviewing mine…

     

    Often you’re in a position of responsibility because you take responsibility, you feel responsible. You make other people a priority because you never want to be that jerk who thinks of noone but himself. But taken to it’s ultimate conclusion, it would drive me mad and leave me feeling wrung out and miserable. And these little bits that I keep back for me, not always but mostly, they add up to my 4-6 hours, and I still leave work at a reasonable time.

    Not today though. Today I had constant interruptions, was distracted by the election results, and I’m waiting on a new computer and it felt like every time I approached “the zone” mine froze. And so it took me over 12 hours in the office to carve out my 4-6 hours and achieve my Most Important Task. This is not something that happens often, and I so I was reminded why.

     

  • Advice for Future Engineers

    Credit: xkcd

    I can’t tell you how happy this xkcd made me. It’s a powerful statement on women in science (and engineering) but also contains this snippet of amazing advice.

    You don’t become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process.

    Timely cartoon for me, because every week I do something to try and make a dent in the huge problem that is the lack of women in CS. Last week, actually, it was 4 things. The week before I gave up a piece of my weekend. It’s easy to get tired, and feel like I’m not making any kind of difference. Some advice I got not long ago – don’t let this burn you out on engineering. Don’t leave because you feel that you have to fix it, but you can’t.

    I thought I wouldn’t get discouraged, but the person who gave me this advice was completely right and soon enough after I had a bit of a crisis. Because I felt that I was slogging away at this and a couple of things happened that were upsetting personally but also, I thought, impeded what I was doing. I could have screamed in frustration at someone’s thoughtlessness. Like, I’m plugging away at this, week in, week out. And you just set me back, damnit. How many f*cking weeks did you just set me back?!

    My calendar beeped at me, and I went where it told me to go. And I met a girl, whose mind had been changed and was excited to be an engineer because of a program – the kind of thing that I spend so much time trying to support. It had made a difference.

    We talked about a few things, but in part her doubts about being an engineer.

    What if you build a bridge, and it collapses, and people die?

    I happened to be in Minnesota when the bridge collapsed. We were terrified that people that we knew had been hurt, and later we went to see the aftermath. It was chilling. In Canada, engineers wear the Iron Ring – a symbol of the responsibility of being an engineer. If you screw up, people die. Take it seriously.

    But you don’t design a bridge in a locked room, send it out into the world, have it built with no impact from other people. Don’t not be an engineer because at 16 or 17 you worry that you can’t be responsible for building a bridge all by yourself. (I would be more worried about the 17 year old that was confident he could build a bridge by himself, frankly).

    Be it a bridge, or some other scary project – you’ll never do it all by yourself.

    What if I’m not completely sure what I want to do in 10 years time?

    I think it’s insane to plan for 10 years from now. The world is changing so fast, how can we know what it will look like? What will excite us?

    I love my job, and I feel tremendously fortunate to get to do what I do. But, I know if I were 10 years older computer science would not be as appealing a career. 10 years ago the problems that were worked on were very different. The constraints of memory and performance more severe. The opportunities to make things pretty less abundant. I took the grounding from university, not all of which was interesting to me, and I get to turn it into a career I love where I work on things I’m passionate about.

    You won’t know all the options you’ll have 5, 10 years from now. So why decide before you have to?

    Just two pieces of advice for potential future engineers, with the standard disclaimer that YMMV. If you have more advice, please – leave it in the comments!