Build, Run, Repeat
Recently when working on hobby projects on weekends and evenings, increasingly my language of choice is becoming Rust. I’ve been writing code in Rust near-enough daily for a couple of months, and to say that the experience is enjoyable would probably be an understatement. The language isn’t perfect, and it’s definitely got some rough edges - as you’d expect given how new it is. But the packages and ecosystem grows daily, and for good reason - more than anything else, it’s just a pleasure to write.
This week, we bought a new WiFi router for the house. Our internet has been dropping in and out, and the ISP provided router is pretty terrible regardless - so it was time to invest in a nice solid mesh network. Expecting to encounter trouble in the setup, it wasn’t surprising that the living room was rapidly filled by cables, boxes, laptops and devices, trying to get the internet even working again. At first, the assumption was (and those who work in development will already be suspicious), that the issue was my ISP modem trying to connect to the WiFi router. Plenty of angry people online had the same issue, so a great deal of time was spent factory-resetting and restarting the two devices.
Over the last 6 months, Docker and containerised applications have gone from being a minor part of my life - and often a source of annoyance - to being critical in how I work. I use containers literally every day now - both in work, and when I’m tinkering outside of it. In fact when I began resurrecting this blog recently, the first thing I did was throw a docker-compose and devcontainer setup into it. I’m not late to the party out of ignorance, but because recently my mindset has really focused on one key goal - the importance of improving daily work.
Like many other desk workers around the world, I now perform my work from home. After however many months of social distancing the office seems like a distant memory, and the vast majority of my interaction with my colleagues is online. At the heart of this for me is the group chatting and collaboration tool Microsoft Teams, which I’ve now been using for some time - even before the pandemic. There are a lot of these tools out there and they all have slight differences, but a recent change in the Teams UI caught my attention. Teams has a concept of… well, Teams (the naming isn’t the greatest), essentially groups of people within an organisation. You can then form “channels” within that team, and within the channel you can start a “conversation” - a starting post, that other users then directly reply to. Until recently, creating a new conversation was done the same way as sending a chat message - type it out and hit enter. However there is now a button with the words “New Conversation”, that you must click to reveal the interface for starting a new conversation. At first glance this seems like an unnecessary extra step, especially given it’s been deliberately added - but there is more to this than meets the eye.
One of the common sayings in the fitness community is “progress, not perfection”. This is the idea that you’ll never do something perfectly, especially not on the first try - but that unless you attempt to do it, you’ll never get any better. I think the same mindset is important to hold when working as a software developer. I’ve found both developers and designers (myself included) can be prone to hesitating on delivering work. Hitting that “release” button or dropboxing that print-ready file to the printer. This week I’m going to share some hints on how to worry less about getting started.
subscribe via RSS