Tag: coding

  • What Raccoon Are You Quiz  (and some thoughts on vibe coding)

    What Raccoon Are You Quiz (and some thoughts on vibe coding)

    Raccoons are very much part of my brand, so many friends (and my boss) sent me the latest adventures of the drunken raccoon in the liquor store. The past couple of years I’ve also been framing my talks about tech as we used to be instagram raccoons – and now we all live in Toronto.

    So I made a personality quiz for tech workers – what raccoon are you right now?

    Take it. Find out if you’re the drunk raccoon passed out in a liquor store, the MPR raccoon stuck 23 floors up, or the unkillable Toronto raccoon that defeated every “raccoon-proof” garbage bin the city designed.

    Creation

    I’m a software engineer by training, but JS is not my friend, so I took this as an opportunity to try some vibe coding using Claude. I set up a repo on GitHub to use GitHub pages, committed changes as we went, reviewed the code, and made my own edits after.

    It was fun! Without AI it would have taken me much longer to turn this concept into something, and probably not something I would have prioritized. I used AI to give me options, generate the things I didn’t care deeply about, accelerate tedious work, and focused my attention on making the quiz fun and interesting. I started with the list of raccoons and about half the question topics, and then refined from there.

    Rather than do it all in one go, I iterated gradually.

    • Starting with the base quiz.
    • Breaking the files up to make them easier for me to work with.
    • Adding extra features like dark mode, runner up reveal, and back buttons one by one (thanks to my partner for the early testing and feature requests).

    Once I had something that I believed I could ship, I reached out to an artist (Joe Groove) I work with so they could create some adorable illustrations to go with it.

    What I Learned

    From idea to working quiz was very quick, and I was able to chip away at it in bits and pieces of time. That’s transformative for small side projects where it’s more about the creative concept than the code quality.

    But some caveats:

    • No-one else will need to edit this, and I don’t anticipate it will change dramatically.
    • It’s a small webpage hosted on GitHub, so no performance considerations.
    • There’s no PII, no metrics, no business dependencies.
    • If it breaks, I can just take it down (or regenerate it again from scratch).

    Back to the Raccoons

    The raccoon archetypes matter because they reflect something real about tech work right now. The drunk raccoon in the liquor store. The stuck raccoon in the sewer grate. The alligator rider surfing capitalism precariously.

    AI didn’t replace my judgment—it let me build something in hours that would have taken days. I still made every creative decision. I still designed the structure. I still wrote the results that matter.

    Go take the quiz. Find out which raccoon you are. And if your result makes you realize thinking more strategically about your career might help, check out my course with Jean at DRI Your Career, or my book The Engineering Leader.

  • The Procrastination Project

    The Procrastination Project

    Reverse Whack-A-Mole
    Credit: Flickr / Chris Clayson

    There is something I’m working on that I’m really excited about, that if we have hung out in person I may well have talked about, but it has been going nowhere.

    So “I’m working on X” has really only been true if “work” is defined as “not getting around to and feeling really guilty about”.

    This was a project that I didn’t have the nerve to apply for, I thought about it, decided my ideas weren’t good enough, but someone reached out to me, and I was like YES! Here are my ideas. And they were positive and so it was all agreed and then I just… made no progress.

    (And that, by the way, is an example of why it’s worth asking women to do things and rather than complaining that they didn’t put themselves forward).

    I procrastinate productively. So whilst I was not doing this one project, I submitted talks for two conferences. And my blog was scheduled two months out and all I had created for this, my most important side project was… an outline.

    To make this seem even more stupid, not only is this something I really want to do (directly related to my secret “What I would do if I wasn’t afraid” plan), I’ve already done at least 50% of it, and this is in many ways just a restructure and repackage of that work, with some extra bits and pieces.

    After weeks of this, I finally made some progress. Not on the full day that I set aside for it, which I spent filling up my buffer of blogposts (rationale: “maybe when I have blog content done for all of this month I’ll feel like I can focus”, and then when that was done, “maybe if I just get these finished they’ll be out of my head and I can focus”). But when I set myself a goal of working for an hour on it, with a limit of 90 minutes I could work on it, because I needed to leave (checkout, eat, go to airport). And I went back to the outline, which I had forced myself to write a month earlier, and just started following it.

    Turns out it was a pretty good outline. It should be, I guess. I thought about it for a month before I wrote it down.

    And voila. Two out of 5 sections were done.

    I don’t know that I have anything to add here than hasn’t been covered again and again elsewhere. But whilst my excuses were good and genuinely, I had been moving/without internet/sick/travelling/insanely busy at work it was only on a Sunday morning – having shut myself away since Friday night citing need to make progress on this – that I finally took a hard look at myself and admitted that I was afraid to fail at this. Better to keep it as a possibility rather than try and fail.

    Which is obviously stupid, so I sat down and got working.

    Some observations:

    • An outline really helps. Creating an outline is such a low bar, if I’ve been thinking about something (which if wracked with guilt over not doing it, I have) it shouldn’t take too long to write one.
    • Once I have a good outline, it’s easy to just follow it and fill in the blanks.
    • I procrastinate more on coding (for personal projects, not at work), it’s like I’m more afraid to be bad at it (who cares if I suck as a writer? I’m an engineer, there’s a pretty low bar for me there) or just feel like I have less to add.
    • Shutting myself away and just working through my excuses until I run out works. It does take a while though.
    • At least I procrastinate productively. I achieved a lot whilst not achieving this.
  • From Hard Focus, to Flow, to Stop

    From Hard Focus, to Flow, to Stop

    Crocodile Rock - Millport
    © Copyright Raymond Okonski and licensed for reuse under the Creative Commons Licence.

    Interesting project the past few weeks. Basically I was swapping out a large and central component to what my team is building. It was really tough, to do that and keep everything functional. Normally I ask – what is the least amount I can do to make an improvement? This time, I had to ask, what’s the most I can eliminate and still remain functional?

    A genuine challenge, and it was good for me.  The first couple of days were hard focus, and tough lessons. A day writing code that I couldn’t even compile until it was done, because it wouldn’t without everything. By 4pm I felt like my brain had bled out through my eyes, and went back to the hotel (I was in NYC) to collapse. At the end of it, I realized I had to do something else first, before I could test and check in.

    So I came back and did that. Again, by the end of the 2nd large thing I felt physically exhausted.

    Day 3 I put them together and checked in. After that I could do smaller things, figure out what wasn’t working, delete things, make small improvements. Change the way we were doing things – because we didn’t have to follow the way the replaced thing was working anymore.

    Once functional, but not beautiful, I picked a new (smaller) UI component, and replaced it with an improved version. Again – hard focus. Desperate to be distracted. It’s like a fight. With the problem – because I’m still figuring out the best way to approach things – and with myself because it’s frustrating, and difficult.

    The following week I have to do the same (UI component) thing again. By this time I’m flying – it’s flow. I’ve learned how to do things to build on each other he hard way, and this time I’m cutting CL after CL and I’m zooming. This little project is coming to an end, soon.

    But… plans change, and this little project is now obsolete. I’m completely “in the zone” and racing towards the finish, and it’s like a rug being pulled from under me. All of a sudden I’m back to asking – what next, what order. Feeling discouraged. Someone reminds me that it’s the right decision, and what I always thought was right, but somehow when I was “in flow” I forgot.

    Some observations about hard focus and flow.

    • Hard focus is hard. It’s like a fight, and I would love anyone to distract me at any time.
    • It’s also completely exhausting. 4 hours of hard focus will leave me physically and mentally exhausted.
    • Flow comes after, it’s the sweet spot before something gets boring but you know what you’re doing.
    • Still figuring out new things in flow, but it’s more like building on understanding, “oh I don’t actually need this”, or “this is neater”.
    • Things stuck on in hard focus take much longer to move forward on than in flow. In flow a tea-break will do. In hard focus it’s more like lunch or a new day.
    • Flow can last for days, effectively. I’ll get tired and stop, but I’ll come back the following day and pick right up again.
    • Hard focus is a fight every morning, even more so than the rest of the day.
    • Being derailed in the middle of flow, for whatever the reason, is horrible.
    • In hard focus, I look at my task list to decide what to do. In flow, I look at my task list to mark off things I’ve done. The next step is always so obvious.
    • I’m actually more on top of twitter etc when I’m in “flow” because I have more compile time, more waiting on submit scripts. Distractions are less interesting than what I’m doing, so they never really take me away from it.

    Anyway, what can you do? Learn from it, and move on. After a day off, I’m heading back in search of flow.

  • Math Error vs Code Error

    Math Error vs Code Error

    There’s a fractal I’ve been wanting to make for a while. And the other week I woke up with a flash of insight and coded it, and it looked like this:

    Initial Fractal
    Initial Fractal

    And I was really happy, until I realized it wasn’t the fractal that I’d meant to make. Oops. So I revisited it and remembered some ancient trigonometry… and it didn’t work.

    So I checked my trig. And then rechecked it. And then redid it completely. Got infuriatingly close. Checked some more – wondered why the lines that I thought would be pointing up were pointing down, and vice versa.

    Eventually, I stared in complete bafflement at a line that should have had an 18 degree angle to the x-axis, but was more like 45. Stared at my code. At the line.

    Checked the API. Realized I should have been using radians. Kicked myself repeatedly.

    My math had probably been right all along – it was just so easy to doubt my ability that I kept doubting myself, rather than debugging.

    Anyway, now I have a pretty fractal. And a little more confidence in trig!

    Snowflake Fractal
    Snowflake Fractal

  • Progress

    climbing in red rocks silhouette
    Credit: flickr / lastbeats

    How do you define progress? As a grad student, the weeks I spend reading papers and thinking don’t feel like progress – it’s the week, or day, or hour, when things start to come together that does.

    In going back to training, it’s not the gradual improvements in fitness and energy. It’s when I can train for two hours straight and still get up the following morning and go to the gym. It’s fitting into jeans a size smaller.

    In programming – lines of code, is progress. A feature, it progress. Passing test cases, is progress. A new idea is not, so much. Ideas are many – implementation is key.

    Maybe that’s why I wish I got to code more.

    In training, “progress” makes the things that make progress happen seem easier. Seeing results makes me more motivated to stop work and go kickboxing. Having more energy makes it physically easier to get up and go, too.

    In grad school, having made “progress”, the act of going back and enabling more feels like stopping. But weeks of reading, and thinking, and failing, make progress happen. Time to better recognize that, I think.