Accidentally in Code

Tag: productivity

  • High Throughput, Low Completion

    High Throughput, Low Completion

    A dark room dominated by two large monitors displaying green Matrix-style cascading code, surrounded by a chaotic wall of wires, knobs, fairy lights, and tinkered electronics.
    Credit: Flickr / MeTaMiND EvoLuTioN MeTaVoLuTioN

    I have never been someone who organises things.

    I have a great memory and a high tolerance for ambiguity, and I evolved to match the era of the internet where searching things by keyword was sufficient. I documented, extensively. But I did not really organize. Not myself, nor – despite my job – other people. I used to joke that I caused people to organise themselves around me: I remembered everything and asked a lot of questions; working with me effectively required those below me to have it together.

    In as much as I optimised for anything, I optimised for being able to think.

    Big things documented. The weekly list on a sheet of paper. How they fit together, how to reason about things, how to prioritize… that lived in my head.

    Like everyone, AI has shifted my workflows, and somehow I have become a person who organises things.

    What broke

    The first thing that broke is that Jean and I DDoSed each other. We got productive enough that relying on reliability of the other wasn’t enough – we needed a source of truth to know everything that was going on, and who was doing it. We threw out our system (although if I’m being honest, system is a generous description) and built a new one. Nothing that fancy – just a shared system in GitHub and clarity about the state something was in and what it was waiting on.

    Then I DDoSed myself. Too many things in flight, flitting between them, nudging them along. So many terminals I needed to color code them in order to be able to find them. There’s an HBR piece on AI brain fry defining it as mental fatigue from oversight of AI tools beyond your cognitive capacity, with measurable effects on errors and decision-making. This was 100% what I had done to myself. The brain fry is the feeling. The result was too many things moving and nothing finishing. I worry in general that the push to “AI driven productivity gains” drives people into this headspace – with all the harm that brings – and misses the point of the productivity, which is the outcomes the productivity is meant to drive.

    Jean suggested I look at turning Claude code into a “chief of staff”, and so I forked the repo and started iterating aggressively. My trello board went in the bin – the API that had seemed like a nice to have a week earlier suddenly a fundamental requirement – GitHub became the source of truth. I added in my existing skills for email and social media. I figured out how to version and symlink them.

    It was an expensive and chatty todo list. Becoming more like an actual chief of staff required a set of underlying skills – for course operations, inbox triage, analytics, social, the things I do every week – and a way to surface state. Given the starting point, it became the place I looked to put the things I needed, as I realised I needed them.

    This is essentially the principles of context engineering, applied to my own effectiveness. As an engineering manager, my role was to notice and remove bottlenecks. To figure out the failure mode and make (or cause to be made) the process that addresses it. To build the structure that makes individual output add up to team output. Now my productivity has gone way beyond what I thought was achievable as one person, and the result was looking a lot less like individual productivity problems used to, and much more like the kind of problems that occur in a team.

    The value of organising things became a lot more apparent. In the same way people used to organise themselves in order to manage up to me, now I create organizational systems to build skills that can help me manage myself – help me finish things, rather than starting one more thing, because the green terminal isn’t currently running anything and it could be.

    My prompts are short, and laden with typos. But a collection of skills makes me effective. The working-with-cate skill tells Claude how to be effective with me in return. The DRI program manager skill surfaces the things that need attention. The inbox management skill ensures loops get closed and don’t fall through the cracks, the content manager skill keeps me on track on the internet. Some are just for me. Increasingly, they are shared with the people I work with.

    The skill alone is not enough, they need to be backed by data. For my non-technical colleagues, that is often notion. For other engineers, it’s often GitHub. Or another API. Combining an API on DRI with the GitHub repo is what makes the DRI PM skill accurate – and as such, useful.

    In functional programming, we talk about pure functions, and side effects. AI alone was like a pure function where I – the lossy human – was responsible for the side effects. Increasingly, to be more effective, I want the side effects. I want the skill to write to the source of truth, and flag updates to itself when it realises it is less useful than it is supposed to be.

    To manage the side effects, you need guardrails. Now my collection of skills has progressed such that I added a structured rubric to run skills against.

    The ever increasing burden of reviewing

    Which brings us to the skill of reviewing. When my job was weighted more toward reviewing other people’s work than producing my own, AI looked, frankly, like a productivity tool for everyone except me. It is much more fun to be a creator than a reviewer in this timeline. The skeptics aren’t wrong about slop.

    But liberated from other people’s nonsense and trying to grapple with my own, I stopped debugging at one level of indirection, and started getting to the core of it.

    The answer is not “stop reviewing.” The answer is to get structurally better at reviewing – which mostly means asking better questions and shaping the work so it’s queryable.

    For example, PRs. I know there’s a debate on this, and I get it. I still believe PRs are useful. Firstly because they segment the change – if it breaks something, you know where to look. Secondly because the PR itself is a queryable unit. You can run rules over it, check whether the standards you encoded are being met. Reviewing – for me at least – looks less like looking at the code, and more like thinking through how to validate the work, ensuring that has happened, and figuring out what to learn when it has not.

    There’s a good chance my opinion will be different next week. The willingness to put everything I think I know in the bin weekly if not daily is currently the most useful thing I can do to accelerate my own learning. I don’t think anyone really knows what they are doing yet; the constant iteration is necessary to navigate the learning curve.

    The metric isn’t output, it’s completion

    The trap I fell into is that the cost of generating drops and you can have a lot more things going. Just because you can doesn’t mean you should.

    Individual productivity is not a pure function. There are side effects and interdependencies. Hooking up the waiting list to my email and to GitHub is a win – when the thing I’m waiting on comes in, the item moves from waiting to needing my action. Similarly, surfacing the things others are waiting on from me is a reminder that team movement beats individual productivity.

    Part of why I wasn’t given to organize things, is that I’m an ADHD-creative type. Executive function is boring, which makes it expensive, which makes me not do it. Building an operational floor for myself helps liberate me from worrying about things, from expensive “did I remember this” panic. I’ve given that work to the robot, so I can work to my actual strengths.

    In the first period – before the DDoSing began – I felt the high of AI making me more capable at the things I’m good at. Now I’m leaning into how to be effective at handing off the things I’m bad at. We’re not going to be winning any prizes for organisation, but that’s okay because organization is not the point. The point is the output. The point is finishing the thing. Shipping it.

    Everyone is figuring this out

    If it is this much work for one person spanning two small teams, of course large organisations are struggling. The learning curve is hard — trying to navigate new tools and a step change in productivity at one time. I’m unconvinced anyone has it figured out, despite some people loudly claiming they do. I’m so grateful I have this time to work through this learning curve working with fewer people, in a more collaborative set up.

    I was heads down for a while, but lately I’ve been talking to more people, being more willing to share where I’m at, and offer suggestions. In doing so, I realised I had rewired my brain. Things seemed obvious to me that weren’t obvious before. How to reshape a problem, how to systematise it, how not just to increase the throughput, but drive the overall goal forward, too.

    This rewiring happened because I had the space to mess around – to try things, abandon them, try different things, talk it through with someone who was also open they are figuring it out. You cannot build that space by reading a blog post about it. You have to do, and badly, and give yourself permission to learn.

    Fundamentally, I’m optimistic about the value of engineers, despite the narrative that we can be replaced by AI. I think learning and adapting is a core skill for us, and we have it to call on, even if the timing is not what we would choose. But sometimes that skill alone feels insufficient, and for that, Jean and I built Navigating the AI Shift. We saw the dissonance and the struggle, and designed a structured space for engineers and EMs to do some rewiring, with the support and accountability of coaching but at a more accessible price point.

    The first cohort starts May 11. We’d love you to join us.

  • Ground Decisions

    Ground Decisions

    Credit: Unsplash / Bao Menglong

    Often, when we talk about automation, we talk about planes. We say they fly themselves, which, sure – and technically the largest planes can even land themselves, if the airport has the equipment (it’s mainly used for bad weather). However most takeoffs and landings remain manual. My pilot friend also points out that many decisions (fuel is a big one) get made on the ground.

    The other thing my pilot friend pointed out is that pilots are in for any decisions they make. They are not just flying the plane; they are in the plane. Contrast this with the surgeon, who performs the surgery, and walks out of the operating room afterwards, regardless of the patient outcome.

    In this analogy, VCs are surgeons. Developers are pilots. And the hype-men… travel agents selling plane tickets, mainly.

    The problem with much of the hype around AI is that it’s not meeting the people who actually do the work where they are at. We’re not being clear about what’s takeoff, what’s landing, and what the ground decisions are.

    The cracks are starting to show. I’ve seen various bits and pieces, but nothing captures it better than Luca Rossi’s summary of CircleCI’s State of Software Delivery 2026 data: elite teams nearly doubled throughput YoY, median barely moved. 81% use AI, so the differentiator is not the tooling; it’s infrastructure. Teams with CI pipelines under 15 minutes in 2023 are 5x more likely to be top performers today.

    I am fascinated by the software factory model — Dan Shapiro’s Level 4, where programmers are less programmers and more managers of AI agents and tasks — and the challenges of retro-fitting it onto an existing engineering organisation. It’s been a lightbulb moment for me – I feel like I finally get why the layoffs happened first, and why the productivity gains have failed to materialise.

    I think the answer lies in the ground decisions, or the open questions from an organisational perspective.

    How does the developer tooling calculus change?

    With teams of developers, we used to know the things that were useful for a team of 20 but not 2, and the things that made sense at 200 but not 20. That calculus seems to have changed fundamentally for two reasons. First, headcount is not (or shouldn’t be) a good proxy for productivity. Second, tooling itself is easier to build.

    Concrete example: every organisation eventually evolves to have a design system. Few start with one. But if you were building a web app today, would it make sense to start with a design system from day one? The answer might be yes.

    How do budgets need to evolve?

    Historically, dev team budgets are mainly salaries and some tooling. But StrongDM, who built one of the first real software factories, use $1K/engineer/day in token spend as their benchmark for whether you’re doing it seriously.

    Firstly, how do you factor that kind of ongoing cost in? Secondly, is managing more complex budgets and ROI going to become a bigger expectation of engineering managers? And what does it take to get good at that?

    What does skill definition look like now?

    It’s clear that a different skill composition will be more valuable in this model. My predictions are that judgement – understanding what to build and why, what is good to ship (aka takeoff and landing) – and feedback – providing clear direction and iterating well – will be bigger differentiators, and earlier in someone’s career than before. What people call prompt engineering is just problem definition and refinement – skills that have always mattered, now moved to the front.

    What does this mean for hiring and onboarding?

    Skill definition leads neatly into these two problems: what do you evaluate, and how do you onboard?

    In hiring, most of the conversation has been about the ways AI generates noise from candidates and heartless automated rejections from companies. Which is a real problem, but not the most interesting one. Beyond that: once there’s a human in the process, are the skills being evaluated the best predictors of success in this new model?

    Similarly with onboarding: having hired many people over the years, I used to have dialled in what good looked like at key intervals — 30, 60, 90 days. But in this model, what does a good trajectory look like when AI can both accelerate and abstract from understanding the systems?

    I have my own concerns about AI, I’m not going to pretend otherwise. But I also think the adoption curve is inevitable, and I’d rather help engineering leaders navigate the reality in front of them than relitigate whether we should be here at all.

    Coming back to the pilot analogy:

    • Takeoff – what we build and why
    • Landing – shipping and the decisions around it – what’s actually good enough to meet the definition of done?
    • Ground decisions – the open questions above.

    What am I missing? What’s your definition of take off and landing, and what are the ground decisions that are changing in real time?

  • The Spreadsheet: Using AI to Understand How I Spend My Time

    The Spreadsheet: Using AI to Understand How I Spend My Time

    Credit: Google DeepMind / Unsplash

    For years, I’ve known intellectually that my best days aren’t my busiest days. That sustainable productivity requires balancing multiple priorities. That beating myself up about not accomplishing “enough” is counterproductive.

    But knowing something intellectually and remembering it when you need to are very different things.

    So a couple of months ago I started trying something different to help me better understand how I spend my time, what works, and what doesn’t. I wanted to

    • Capture what I was actually doing across multiple areas
    • Track not just activities but impact and how I felt
    • Mine the data for insights about what was actually working

    A long time ago, I tried tracking my time in 15 minute increments, which was helpful, but a lot of work. At DuckDuckGo I used to keep a list of what I’d done for the week and then outside of work I mainly used Trello. But then I only got the dopamine hit of the checkbox for finishing things – not all the effort that went into them.

    The Solution: A Spreadsheet

    I set up a spreadsheet.

    • One tab per week – easy to review without drowning in data
    • Columns for categories: Adulting, Human Being, Development, Promotion, Revenue, Twill, DDG (while relevant)
    • Two assessment columns: Daily impact rating and overall vibe, color coded (green/yellow/red).
    • Color coding: I also highlighted high-impact activities in green.
    • Keep it open: I left it in a browser tab and jotted things down as they happened

    The key was making it easy. I wasn’t timing anything precisely or categorizing every minute. Just capturing: “What did I do today? Did it matter? How did I feel?”

    After a month, I had enough data to start asking bigger questions about what was working overall and what was not.

    The AI Analysis

    I fed my spreadsheet to Claude and asked it to analyze my patterns over the past month. What came back was a thorough, personalized report that I would never produce myself. First because of the time, and secondly because I’m inclined to be overly harsh on myself for what I accomplish – and what I don’t.

    This is one of the core ways I use AI: to give me faster and more detailed feedback loops.

    The feedback tends to be very positive, which is why real data matters—it keeps the AI grounded. It also tends to be generic, which is why identifying a process that works for me first, then using AI to give feedback and iterate, works better than asking for generic suggestions.

    But when you combine genuine data with AI analysis, something useful happens. Here are some of the insights I got from Claude’s analysis.

    The High-Impact Day Formula

    Claude identified patterns in my color-coded days. It turns out my best days share these characteristics:

    • 2-3 categories active (not all six—trying to do everything leads to feeling scattered)
    • 1 significant accomplishment I can point to
    • Mix of strategic + tactical work (both vision and execution)
    • Human Being time included (exercise, relationship time)
    • Clear assessment at end of day of what I achieved

    This was validating. My instinct to prioritize exercise and quality time with my partner isn’t “nice to have”, it’s foundational.

    Wins + Opportunities

    Claude validated me as someone who:

    ✅ Values wellbeing and relationships
    ✅ Manages multiple work streams effectively
    ✅ Navigates major transitions with awareness
    ✅ Balances doing with being

    But also (accurately) called out that I would benefit from:

    ⚠️ More deliberate planning (light vs. focus days)
    ⚠️ Increased development investment
    ⚠️ Recovery time after intense periods
    ⚠️ Clearer daily priorities to reduce “busy but unclear” feeling

    The Core Insight

    I’m pretty sure I already knew this, I just forget when focused on all the things I haven’t done (yet). I hope that building a structured way to give myself a regular reminder is not just good for my productivity – but also for my mental wellbeing.

    My best days aren’t when I work most, but when I have clarity about what matters, make visible progress, and maintain my human being practices.

    This felt particularly important to pay attention to as I navigate a transition from a structured and meeting heavy work environment to a more portfolio setup, but honestly most of the same insights probably would have been true 6 or 12 months ago.

    Rinse and Repeat

    The nice thing about this system, was I could use the insights and feed the data back in a week later. Claude was encouraging about my progress, which was nice – I tend to start the week a little overwhelmed by everything I want to accomplish and it helped me ground myself in what I am capable of.

    After taking the feedback, I managed to have a week as a person that:

    • Works hard without sacrificing relationships
    • Rests intentionally without guilt
    • Acknowledges challenges without catastrophizing
    • Celebrates progress without waiting for perfection
    • Maintains systems without being rigid

    Obviously I still had things I can do better (specifically: spending more time on development). But for one week later – a busy one! – that was pretty great progress. This solidified the Monday morning ritual – run the spreadsheet through and ask “how did I do?” and “what can I learn?”

    Failing

    I live for the validation, but a few weeks later I took a long weekend and missed the Monday ritual. By Friday, I was toast. I ran the spreadsheet through Claude, and it brought the Real TalkTM. Pointing out that I had:

    • Sprinted through the week before the long weekend.
    • Not actually rested – had a hectic (but fun!) weekend away.
    • Came back and tried to jump back to full capacity whilst noting myself “discombobulated and tired”.
    • Missed my physical anchors (no yoga or spin).

    Claude ordered me to stop and rest, and I obeyed. It was a good call – I managed a nice afternoon reading a novel before spending the entire weekend sick.

    I know this is a pattern I have. That I push myself to “earn” a break by getting everything I would have done in that time around it. It’s destructive. But the good thing is that the failing enforced the value of this ritual more than any succeeding would have done.

    Try It Yourself

    If you’re curious about your own patterns:

    1. Pick 5-7 categories that matter to your life (work projects, learning, relationships, health, etc.)
    2. Create a simple spreadsheet with these as columns.
    3. Add an overall impact and overall vibe columns to capture how you feel about how the day went.
    4. For 2-4 weeks, jot down what you do each day.
    5. Use color for an easy visual emphasis.
    6. Feed it to an AI and ask for patterns – note that in your prompting you’ll likely need to be explicit about the color coding and what it means.

    Maybe you’ll learn something new, or maybe – like me – you’ll be reminded of the things you know but forget when you’re stressed. Either way, I hope it’s useful.

    If you try this, I’d love to hear what you discover. What patterns emerged? What surprised you?

  • How I’ve Been Using AI

    How I’ve Been Using AI

    By Ralf Steinberger from Milan, Berlin + Munich, Italy + Germany – 21st century robots. Seen from the future, they will just look cute., CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=110354735

    I feel like the whole AI conversation is dominated by two extremes. Those who believe in AGI, and AI skeptics. I’m trying to approach it as a tool that may or may not be useful. Here are some things I’ve found so far.

    Useful as an editing partner. For things where I have a clear point of view, I produce a first draft and then use AI to refine and clarify. It will just go on endlessly though, so I have been telling it “I have limited time to spend on this, please stop once the feedback is chasing diminishing returns”. I think this works for me because I am quick to write and slow to edit.

    ➡️ For similar reasons, I’m enthused about AI feedback on PRs.

    Helpful for generating feedback. If I’m reviewing something, I can use a similar process to refine my feedback. So I will put in the doc, my initial thoughts, and ask it what else – again being judicious about what I include. Or the doc, the additional clarification I wrote, and then use the combination of those to generate a feedback. It means that I can read something once and query it, rather than reading multiple times to check my thoughts – the longer what it is I’m reviewing, the more useful that is.

    ➡️ Like all women in tech, I’m continually walking the tightrope between being a b*tch and being a pushover, so I’m trying to offload any overthinking of “tone” to AI. My current workflow here is to tell it: “You are a busy engineering leader, who wants {team|person|whatever} to get their shit together”, and then “Now soften it a bit so people don’t think you’re mean”.

    Mixed for structuring things. I’ve also been trying to use AI to create structures or plans, typically for things I don’t know much about (if I know about it, the structure is normally very clear to me). Here, I’ve had mixed results.

    • For example, I tried to use it to generate a book promotion plan for me. It was okay, but initially gave me a full time job’s worth of work. After a few rounds I got something that is more doable, but I’m still not sure how good it is (also I have failed to do it, suggesting the lack of plan was not the only problem).
    • Another example, I tried to use it to create a structure for a proposal around professional development. I put in some bits and pieces – a conversation with a colleague about it, some disjointed thoughts, and got something out that I only have the expertise to tell is bad, and I’m not sure how to make it better. (Although telling the AI “this is bad, try again” has been surprisingly effective).

    Both of these examples were places where I have some amount of expertise, but a relatively narrow point of view, deeply anchored in my own experience. As a result, I was struggling to move something forward or know how to prioritize, I wanted AI to help me get from half formed idea -> plan, but perhaps I need to add an interim step of half formed idea -> deeper understanding -> plan.

    All in all, this I think supports a theme of what I’ve been hearing about AI, for example on the impact on senior devs (good for productivity) versus juniors (destroying their learning).

    • For things you know well, it can be a productivity boost.
    • For things you don’t know, it can give the illusion of knowledge. This is dangerous for knowledge workers, as it can result in wasting time and going down the wrong path. Also, if you submit it to someone who does have that knowledge, an excess of nonsense will be judged more harshly than a gap.
    • It tends to be overly comprehensive and includes excessive low value information.

    For my own takeaways:

    • As a writer, it’s a productivity tool not a generator. I am clear on my voice and despise reading obviously AI generated content so I would not do that to others.
    • As an overthinker and procrastinator, it’s good to offload some things that I might spend disproportionate time on or not do.
    • As a leader, who spends more time reviewing other’s work than creating, I need to adjust my approach to filter out noise and validate structure first.
  • Most Productivity Advice is Bullshit

    Most Productivity Advice is Bullshit


    I’ve been having a productive time, up the mountain. I’ve achieved things at work, blogged regularly, sent out Technically Speaking with Chiu-Ki, made some progress on The Dark Place that is my personal inbox, I feel fit and healthy.

    I’ve achieved this by skiing for two hours weekday mornings (longer at the weekends) – hard, so it’s good exercise, and the fresh air and freedom from devices clears my head. Then I work until I go to sleep. I could advocate for mountain life – and it’s good, I hope I can do it again next year – but actually that rests on the same things that most “productivity advice” does, just more blatantly.

    Money. It’s quite expensive to live in a mountain village during the ski season. But a lot of things that show up in productivity advice cost money: separate workspaces, daily yoga classes, a diet of solent.

    Control over schedule. I shifted my hours to work 12-9 most days. This, by the way, isn’t sustainable – working weird hours is not good for various things, including my social life. But I could do it here because I love to ski. Not everyone’s job is that flexible (by time, let alone by location). There’s also a social cost because it makes it hard to have friends who live on more “normal” schedules. You get to be more “productive” because “no-one is around” and that probably comes with some downsides, too.

    Some specialised skill. Firstly, a flexible job is normally the result of some specialisation. Secondly, and less obviously, I already knew how to ski well and had all the equipment. It would have been much harder for someone who didn’t already ski well to come live up here and learn to ski in a couple of hours every morning. They’d have a harder time coordinating ski lessons, and working to a schedule (I can make it top to bottom in 8 minutes and I have done that in order to make it in in time). They’d have to stay within a smaller area and get stuck in the crowds. They’d be more exhausted by it, and more likely to hurt themselves.

    General good health. Most productivity advice comes with a suggestion of exercise that is infeasible for people with chronic or temporary but severe health conditions. There was a period when I injured my knee so badly I could barely walk for about three months. Firstly, the gym felt like a far off dream, and if I went at all, lasted very little time and left me feeling bad about myself. Secondly, just the basics of life like getting to uni or the grocery store were really painful and left me exhausted, not to mention the time I spent in physio.

    Lack of dependents. To be able to live this selfishly requires that no-one depends on you. There’s a reason the bizarre productivity advice I find on the internet is never written by women with kids. I can eat cereal and yogurt to save time for lunch or dinner every day or at some approximation of a mealtime that coincides with a gap in my schedule and feeling hungry, and no-one else has to deal with that. I don’t have to be back home by a certain time, or pause what I’m doing to pay someone else attention.

    If the prerequisite for productivity advice being useful is having control, being selfish, healthy, specialised, and unconcerned about money… well that’s not useful to everyone. Or even that many people at all.

  • One of Those Days

    One of Those Days

    first_run

    I had one of those days last week. I woke up later than I wanted to, and it took me a while to get moving. Then just as I was getting started, I realized that I had to deal with some insurance thing, which was – of course – a complete pain.

    Eventually, I was out on the mountain on my skis, but the crowds were out in force by then. But I made my way to this part of the mountain I hadn’t been to before, and found this beautiful red run and a chair lift without much of a queue, and skied it again, and again, and again. I went all the way to the other side of Grandvalira, ate lunch, and came back. It ended up being a really good – albeit exhausting – day.

    I like to think that I am some kind of Super Cate. That I bounce out of bed every morning and Achieve All The Things. This is true… maybe 60% of the time. Long haul flights, my cycle, getting sick… all derail it regularly. As do things that are well within my control such as, dehydration, forgetting to eat, exercising a lot, not exercising enough (and then not sleeping).

    So a lot of the time, I can’t live up to my own expectations, and my own idea of myself… and I spend too much of that time beating myself up. For not being able to just shake off whatever it is, for not having done a better job at Life the previous day.

    I feel like I’ve been confronting the difference between Super Cate and Cate a lot since I came to live up this mountain and ski. I used to be a ski instructor – something I was proud of, because (amongst other reasons) I didn’t learn to ski until I was 20. But I last skiied properly in New Zealand, because a couple of hours at the world’s longest indoor ski slope in Dubai doesn’t count. So when I arrived I was super anxious, and out of practise. I’ve been getting better (deliberate practise and a great instructor) but I’m just not as much of a daredevil as I was at 22. I’ve had about six concussions since then (most of them skiing, although there was that time a TV fell on my head), not to mention badly injuring my shoulder and my knee. I’ve been hit, badly, whilst skiing, twice. When I’m on the slopes (and there aren’t too many people around), I feel like I’m flying again, but the act of getting geared up for it is a complete PITA. I know two-three runs in I’ll be super happy, but that can take an hour to get to. It’s not a very immediate reward.

    My most bitter breakup was over an argument about where to go on vacation. Of course it wasn’t really about that, or so I concluded once the hurt (and frankly, amusement) faded. It was about his need to be seen a certain way, and my inability to bolster that self image.

    I think that the gap between who you like to think you are, and who you actually are, is a hard place to be. It’s not something you can ask other people to do for you, or fix for you – you have to do the work yourself. When I’m not being Super Cate, the way it highlights my inadequacies… I hate it. But those days are also when I see most clearly what I need to do to be the kind of human I aspire to be. If I can stop beating myself up, I might just make progress instead.

    The days when Super Cate bounces out of bed and goes hurtling around the mountain and then Achieves All The Digital Things are awesome, and energizing, and invigorating. But the days when Human Cate is not feeling it, does it anyway, and ends up having a good time before collapsing on a heap on the sofa… well Human Cate worked harder for it. I’m prouder of her.

  • Being Productive Offline

    Being Productive Offline

    shows a productivity of 89%
    Rescue Time score from my flight

    Normally I embrace flights as a chance to generally disconnect (who else is unenthused about in-flight wifi? Holla!). I read, sometimes I write, but I’m not too concerned about “achieving things”. Sometimes I try to find something to work on offline, typically at the last minute in the lounge and it’s not been very successful.

    This last trip though… with so much going on and an 11 hour flight in business class (my travel agent got me a deal – yay!) I saw it as a chance to do some Real Work whilst disconnected. 

    One thing I think we lose by living “in the cloud” is that our computers have become portals to other people’s data centres and without internet much of what we do day to day doesn’t work. So it’s important to be organised.

    I finally figured out how to be effective offline.

    • In the week or so leading up to it, I started tagging things in my trello board with a label to mean that this could be done offline.
    • I organised my Google Drive, made sure things were shared with the right account (offline multi-account support is lacking) and sync’d the folders that I needed to my computer.
    • I don’t entirely trust Google Drive to work offline so I also downloaded reference things as a pdf as a backup (turns out: good decision).
    • The day before I went through my “offline” tagged things and moved them to a plain text document (Trello offline support is sketchy).
    • I collected things I needed (e.g. blog posts I’d written that I was building a talk from) with the list or in another plain text document.
    • I made sure my GitHub repos were sync’d to my laptop.

    When I got on the plane I was good to go! Key things that made a difference:

    • I had a choice of things to do. Because I’d been organised I had around 5 significant projects to work on. I got through two. Turns out I was in the mood for refactoring, so I got through a bunch of coding tasks on Show and Hide, and then refreshed the slide deck for our workshop.
    • I’d identified a bunch of coding stuff that was really straight forward where I wouldn’t need to look things up.
    • I’m not usually a fan of “work on what I feel like” but having not had a huge amount of sleep, it was nice to take on a task that didn’t require me to be creative.
    • Noise cancelling headphones. I love these Bose ones (Amazon), but they are pricy.
    • Not gonna lie, being in business class. I had a little nap, and some delicious food, then feeling refreshed, I got to work.

    Afterwards:

    • The slide deck I put in the Google Drive folder, the next time I connected it sync’d to the cloud and Chiu-Ki could see it. No need to remember anything!
    • Code was a little tricker. I’d done a significant refactoring and branches had built on each other. I kept a list of what order they were in, and then spent around an hour creating and reviewing my own pull requests early the next morning (yay early morning jet lag productivity).
    • I caught up Trello on what I’d got done.
    • Because I had prepped more stuff than I had got through I am covered for a bunch more time offline! A lot of it falls under important but not urgent and it’s nice to have time to focus there. My next long-ish flight, I picked up where I left off and made some more progress.
  • A Small Focus Hack

    A Small Focus Hack

    Happy New Year Danbo
    Credit: Flickr / Leland Francisco

    I decided that my word for 2015 was “ship”. Part of this is that it’s easy to flounder in an unstructured environment (which I did a bit at the end of 2014). The way I decided to solve this was to give myself structure, and goals.

    How do you measure bigger milestones though? It makes sense to have a separate place, away from how we manage our todo lists.

    My strategy: a simple text document. At the top a list of projects or significant milestones I’m working towards.

    Below, each month is a heading. Under it goes things that “shipped” that month. New client contracts, talks, alphas, betas, releases, open sourced libraries.

    When I want to see what I’ve achieved this year, this is where I look. It keeps me focused on moving the needle, reminds me not to fill my days with transient busywork, but rather the 2-5 (typically 3) things that will still matter months from now.

  • Creative Solitude

    Creative Solitude

    Danbo Phelps
    Credit: Flickr / Andrés Nieto Porras

    Before I  left for South America I kept being asked “aren’t you going to be lonely” like loneliness is some terrible thing to be avoided at all costs.

    Since I’ve been here, people have been commenting “you seem to be very productive” and it’s true. I have been.

    I say, “I’m embracing a kind of creative solitude.”

    And yeah, definitely at times it’s been lonely. And overwhelming. I’ve gone and eaten pizza (I almost never eat pizza) because it’s easy. I’ve cried, once. I’ve taken out the Xanax… but managed not to swallow it.

    I see loneliness as a normal part of being human, and I think sometimes it’s healthy to embrace it. Fearing it keeps us in bad relationships (friends, roommates, lovers).

    So yeah it’s been a little lonely. But quite creative. And very productive. And actually… I’m pretty content.