I'm writing this just before leaving on a vacation trip. Expect one or more entries during July, though!

I started reading the new Dave Farley book, Continous Delivery Pipelines. Remembering how much I liked the Continuous Delivery book, it's likely I'll reference some nuggets of wisdom from this one in later posts.

I was nodding hard while reading this post on how pair programming helped a developer leave and return from maternity leave. Reducing code ownership is one of the greatest assets your team gains when you adopt pairing and mobbing. No one can become the only expert on a particular component, which increases the bus factor. The benefits from there are self-explanatory.

I hate when the client asks me to implement an A-star algorithm to find the best from a group of nodes. Fortunately, our days as software engineers are not quite like that, even though that might be the image people get from technical interviews.

Becoming a lousy developer is easier than becoming a good one. If you resonate with these practices, there's still time to turn around and do the opposite.

Have you written any email validation logic recently? It's probably wrong. After reading the article, you can take two paths. Either you implement the validation with the horrifying and monstrous Perl regex (don't!) or sprinkle just enough confirmation to satisfy the most common use cases.

The Team Topologies book is still on my to-read list, but I enjoyed this post about three different cognitive loads a team can encounter. In brief, prioritisation issues, no time for learning, and constant context switching will rapidly drain your team's motivation. What is an unmotivated developer to do? Switch jobs, of course — you don't want that, do you?