Summary

It’s been two months since I last wrote a retrospective. This is why.

Work

I’m really enjoying my day job.

The team

The work is tough at times but the team is excellent. None of us are rockstar engineer’s, but we all muck in, learn what we need and get it done. It’s a long way from my time in the special forces but for a development team it’s pretty darn good. I’m proud of them and what we’re achieving with all thats stacked against us. And, from my experience, it’s in battle or in times of hardship that you really become a team, and also become friends. Smooth sailing never made a skilled sailor.

The work

I’m not going to dox my employer. But the work we do makes a difference. You likely can’t see it, and if we do our job right, never will but it matters. At the micro, I do stuff that any developer does daily; code, debug, fix, review, and deploy. Except that in this job I have numerous business and environmental constraints that 99% of other engineers would never come across.

It makes work slow, error-prone and brittle at times. Local development is hard. Sometimes impossible - we’ll do it live is a pretty normal! This sounds like a whinge but it’s actually a binding force for us in our mission. Embracing the suck has made us invent ingenious ways to overcome some of these constraints and exposed me to so much more than other developers in my position.

Life

I only have so much time each day to:

• Work my day job
• Be present with the family
• Work on after hours pursuits
• Exercise
• Chores

Something has to give but also energy has to be dispersed across all.

Mudmap

Mudmap still lives but I’ve given it less attention than it deserves for the reasons stated above. I’d love to do more, and be able to build the things users ask for. Maintaining it is an energy drain that isn’t refilled by my interest in working on it. Though at times, I have had bursts of inspiration because of its potential, and its that potential which prevents me from shutting it down.

Possibly the biggest gripe is the difficulty in getting everything to install correctly on each device. I’ve yet to discover a repeatable or diagnosable reason as to why it works for some but not others. I think this is a problem many similar bring-your-own-hardware platforms have to deal with. Each time I get a customer email stating they couldn’t install correctly my heart sinks a little. It’s also hard not to be your code and blame yourself (a distinct possibility) for the issues. Energy sinkhole.

Pursuit of joy

Like all developers, I love creating and trying out new toys and techniques. Building a new application is great fun and is a great way to procrastinate. It is also a great way to try new things and bring them in to your day job, or gain better understanding of how something in your day job works. Lots of my colleagues don’t do this and seem to learn everything on the job without any additional work. That ain’t me, never has been. In the army, I’d go home and read the manual so that things sunk in. I have to do that in tech too - I’m a hard worker not a smart guy. My school aptitude tests put me in the “labour hire” job prospects category not the “attend university” one. So, sometimes I get engrossed in learning something at the detriment of other things like Mudmap.

On the flip side, my after hours learning has earned me a reputation as the Kubernetes guy at work. I’m also the Go guy now too. I can now say I’ve a working familiarity with gRPC and NATS as well. Doing these things helped me make several interview rounds (and get offers) in the last three months for 20-40% pay rises without having to do a single LeetCode session or other Code riddle bullshit. That being said, I acknowledge my CompSci fundamentals are a limiting factor so I’m now reading up on those things to round out my knowledge.

Lots of words to say; I enjoy my craft and like to jump around at the detriment of long-term projects such as Mudmap.

What’s next

I love how well mtlynch and czue write their retro’s. I took most of my inspiration from Michael’s, but I think pigeonholing myself into something that works for him is a misstep.

For instance, Michael is doing a fantastic job of documenting his many projects but mostly his successful business, TinyPilot. For me though, I work 40 hours a week in a day job I can’t talk much about and approximately 10-20 hours outside of that broken into 1-2 hour chunks over nights and weekends. Setting myself ambitious goals was actually causing me some anxiety, especially if my month’s work took a big hit from external factors.

What I’m planning to do now is just be more retrospective about what I did rather than only talk about how well I did on x goal. At the end of the day, I write on here for me not an audience. So my writings should reflect that and help guide future me when looking back.

Does this mean I’ll forsake any thought of setting goals for each month? No but I’m not going to be dogmatic about how I layout the retrospective and instead let it flow. Some months I might only do 10 hours on Mudmap but do 30 hours on something that teaches me a hell of a lot about <insert tech>.

Goals

Okay, I’m setting one goal for next month.

1. Write Octobers retrospective. Time to get back on the retro horse.

Analytics