Build, Run, Repeat - page 3

  • Pretending I Have Production

    I’ve mentioned previously that I have a small personal dashboard I maintain for displaying my fitness data. My main usecase is displaying it on an old TV - I think it’s important to keep your goals and progress visible, and I’ve done it for a long time (mostly with whiteboards). One of the decisions I made recently was to establish some form of “production” that wasn’t hacked together on a Raspberry Pi.

  • Not My Job

    When I first moved into being a full time software developer, one of the first things I had to familiarise myself with was release processes. My background was as a designer, and part of that in my previous role had been building and maintaining the company website. It was how I got a taste for code, building WordPress and Drupal components. This included getting the code for the website up onto the webserver. Even before really understanding development, I managed to get away from just FTP-ing files around and instead pulling down from a git repository to do my “releases” - even if I was doing it manually, directly SSH’ed into the server.

  • Handle with Care

    I’ve recently had the pleasure of reading “The Phoenix Project”, which is a phenominal little book. It did a lot to really make me think about how I approach my working process - both in the office and on my side projects. It’s sister book, “The Unicorn Project”, is on my list for later, but one thing that I’ve recently been dealing with at work a lot is the idea of risk. Fundamentally, good software development practices seem to fly in the face of “common sense” approaches to risk - and often the worse failings seem to happen when people try and minimise risk instead of confronting it.

  • Do or do not

    This week, the thing I’ve experienced the most is a defense of just getting on with the thing, instead of worrying about doing the thing. I find sometimes developers tend to approach things from a risk adverse, cautious position. Usually the focus is on how to minimise changes done and disruption caused - especially when you’re dealing with legacy products (and who isn’t). I think where this can cause problems is working on personal projects and proving a concept. Getting wrapped up on whether it’ll work, rather than just seeing if it will.

  • Project management for fun (not profit)

    I’ve got this long running personal project I like to call “Fitdash”. It’s essentially a dashboard for my Fitbit data (they have a quite nice API that’s easy to access), to help me keep on top of maintenance and have a longer term view on my fitness goals. It’s had a lot of iterations and versions over the years, and essentially I use it as my testbed when I want to learn about a piece of tech. One of the most impactful (and surprisingly fun) changes I’ve made however has happened recently, and it has nothing to do with trying to write more code.

subscribe via RSS