At the end of the year it’s now become somewhat of a tradition that I partake in the whole year in summary thing. I do find it interesting to read these posts, and I like doing my own since it’s a good way to reflect.

After a year of how-to type blog posts it feels odd, yet fun to be back talking in first person again. Today we’ll cover quite a lot of (varied) ground in a way I wouldn’t typically be comfortable with. But I’m hoping the informality works out. The following are some of the key things I learned in 2019 that I’ll go into more detail on very soon:

• Serverless technologies require a lot of knowledge, skill and patience
• Terraform is an amazing technology (and why)
• Single event logging is an amazing monitoring method (and why)
• Motivation for blogging is difficult (and how I regained mine)
• Why I changed the way I run my newsletter (yet it’s still hard)

It seems it’s going to be a pretty detailed post so let’s get to it…

Here is my latest post for Enov8.

“Wait, what actually is DevOps?”

If only I had a dime for every time someone asked me this. For many, the term DevOps comes loaded with misconceptions and myths. Today, we’re going to look at some of the common myths that surround the term so that you have a better understanding of what it is. Armed with this knowledge, you’ll understand why you need it and be able to explain it clearly. And you’ll be equipped to share its ideas with colleagues or your boss.

Last year when I put out content around the new year about my plans I got a spike in traffic. I guess something about the personal nature of the post was attractive. Based on how much people seemed to like those posts, I thought I’d do another.

A round up of 2018 — and a goal set for 2019.

Have you been thinking about wanting to write? Did someone mention to you that it might be good for your career? Or you want to write to earn some money? Maybe you just want to document your notes and share them with others?

I can’t read your mind and know your motives to want to start writing, that’s for sure. But what I can do is this: go through the fears that are currently stopping you starting to write. How do I know what these fears are? Because I have the same writing fears and I wrestle with them every day and every week.

Here is my latest post for Simple Programmer…

Recently, I conducted an experiment with my team.

This experiment was challenging enough to make even some seasoned developers sh*t their pants.

What experiment did we run? We stopped branching our code, we threw away code review, and we started pushing directly to master.

Recently I’ve been training for a long cycling event.

The event is a three day event where we will cycle around 70-100 miles each day back-to-back.

It’s very much an endurance event and for all my adult life, I’ve been a strength athlete competing in strength sports that are maximal exertion. It couldn’t be much more of a polar opposite set of skills.

I sat at a Starbucks cross-legged with my laptop on my lap. I’d gone out to try and find the peace required to focus on the job application I was completing as a front-end product developer.

The task was simple: Create a demo app that connects to an API (Foursquare) and shows the results.

As I sat there putting the finishing touches on the demo (you can actually still see it here) I had a realization…

Here is my latest post for Simple Programmer…

There are many lists of books about becoming a better programmer. They likely include books like Refactoring, Code Complete, The Mythical Man Month, etc.

However, in the workplace, it isn’t just programming knowledge that we programmers need. Learning programming is an essential part of our work — but it’s not everything.

The authors of iconic programming books had remarkable careers, but it wasn’t just their coding knowledge that made their careers noteworthy. They were well-rounded experts and we should strive to emulate that quality as well.

Here is my latest post for Simple Programmer…

We were struggling to get our features out into production. There were lots of defects and firefighting. All this and the company was but a few months old. What was working here going to be like in a year? We were all staying as late as we could and even working weekends to try and fix issues that would appear, seemingly, from nowhere. It was hell.