I quite like this idea. As https://charity.wtf puts it, we should be comfortable with deploying no matter what day or time of the week, because our tooling and processes should give us confidence. It's an antipattern and a sign that something is wrong if we don't want to do it.

But at the same time, you don't want to be staying up late on a Friday because someone pushed something, and then have it potentially ruin your weekend.

It's definitely a hard line to walk, but as this article says, we should opt for something a bit more risky, to give us more confidence

I've been using DuckDuckGo for a couple of years now, and have no complaints. The privacy baked into the product is great, and their extensibility for things like !gh to search on GitHub or searching "html pretty print" is awesome for quick productivity boosting.

I'd recommend you giving it a go, and see how you feel after a while. And if you're finding search results aren't so great every so often, you can !g to get your Google results!

This is a really great post about how we should look to use our time more wisely. Taking time to create something new instead of just consuming others' content, especially as you're all going to have some really interesting things to share.

However, we also need to remember that it's OK to have downtime, and consuming others' content is ok! (And yes, this is a little ironic coming from me, a person who is seemingly always productive and pushing out new content)!

This blog post from Monzo is such a good explanation of what the Strong Customer Authentication regulations are, especially coming from someone who's been working on it for some time. It's going to be interesting to see how the industry works at making it secure, but unobtrusive to the customer - as it's something that could cause quite a User Experience difficulty, at the risk of providing real security for our users.

This is an interesting article about how the increased size of the Internet is a cautionary tale for whether things need to be on the Cloud / accessible from the Internet.

This interview with George RR Martin is incredibly insightful into how George has been dealing with the TV series of Game of Thrones overtaking his literary pieces, and I'd really recommend a read to see his thought processes and the pros and cons of his writing being behind.

Readability of code is a very important, but so is using idiomatic language style. However the difficulty, as this article calls out, is that some folks won't find it easy to read or write code in an 'idiomatic' way. And also, who cares if you convert the readable four-line code snippet into a horrible to read one-liner? All it does is make it harder for the next person!

This is a great read about some of the risks of using YAML, especially the way that most YAML parsers default to executing arbitrary, unsafe commands from a file you're parsing.

I've used this server before to get a simple RESTful API up and running, and it's really useful.

GitHub always have a great recap of the new Git releases, and this is another - I'm particularly interested in some of the changes around git checkout

This is another good article talking about the difficulties of working on the Web, with the plethora of technologies 'required' to get even a static website off the ground, let along big business applications. It's something we're all just accepting as a thing that happens (or folks from other tech stacks are ridiculing) but no one is really looking at what we can do to prevent it or make it better.

This is a great post talking about some of the real difficulties of working in the Web ecosystem. It helps paint a picture of some problems that plague the folks working on it, and is a great view for someone who isn't as used to web development.

This post has definitely helped my recent scenario writing, and helped to shape the readability (and purpose) of the Cucumber testing I've been doing.

This is a great post - I thoroughly recommend learning how to use common commandline tools such as awk, grep, sed, but also adopting a scripting language for more complicated stuff. I don't mean Bash, or another shell scripting language, but something like Node, Python or Ruby, as it'll give you the opportunity for a greater standard library, as well as tonnes of packages built by others.

This should be a really interesting listen about getting started with the IndieWeb with David, I'd recommend it.

But in an even cooler turn of events, it was very cool to see that my article Why I Have a Website and You Should Too ( https://www.jvt.me/posts/2019/07/22/why-website/ ) discussed at roughly 39:00.

This is a really interest post about the dangers of installing work apps (such as email) on your personal device. This is something I've spent a lot of effort avoiding in the last couple of jobs, as well as going out of my way to not use any personal services (i.e. social media, email) on my work devices, as there is most likely traffic inspection or they are Man-in-the-Middle'ing the traffic, and will therefore be able to glean passwords. Although this seems paranoid, I feel it's a good mindset to have.

This is especially useful because it has a great way of enforcing the separation between home and work. However, there are still ways that this can break down - for instance, I have a work phone which is provided so I can be out of hours on call. However, I have things like email and Slack which allow me to use it throughout the day and reply to messages when I'm not necessarily with my laptop. But that's an issue because that phone goes home with me, even when I'm not on call. I'll find I'm catching up on work on the bus on the way to work, as well as keep in the mindset of work when I'm physically out of the building.

This makes it quite difficult because I'm not really switching off, even though I've said above that I'm trying to keep work and home separate. So what I've been doing for the last few months is leave my work phone at work (as long as I'm not on call!) which means if I've left the office, I'm no longer able to action anything, even if I think about it.

This is another interesting article about automation, and how it slowly incurs time costs by waiting for the right time to properly tackle the automation, rather than piece-by-piece.

This is a really interesting way of approaching automation in a gradual way - make the documentation in code, then take that code and slowly iterate over it until you have a fully automated solution. I like it - obviously we always want to have the final product, but it's a good way to get there slowly

This is a great post by Shubheksha and talking about the right way to talk about production issues.

Having a blameless culture makes it easier for new/junior engineers getting started with working on production systems, and makes everyone more comfortable working on things where they know they won't get the blame pointed at them.

I've found that, at work, diagnosing issues in our staging environment has given me such a great experience - it's been great to practice dealing with production-like issues in a non-production environment, as it gives you that time to breath, experiment and learn, as well as giving me much greater understanding of the end-to-end system.

This is going to be a very interesting talk - there is so much of this around (I'm guilty too) and it'll be good to hear some more about it from James Seconde

As I've said before, I'm a big fan of how Monzo handles their production incidents because it's quite polished and transparent

This is a really interesting post. Only the other day, Anna and I had been talking about how it'd be interesting to work 4 days a week, or even part time. It sounds like it'd be a great opportunity if you're able to financially cover it