More microservices thinking: www.bennadel.com/blog/3944… (h/t Kostas)
More microservices thinking: www.bennadel.com/blog/3944… (h/t Kostas)
Thoughts on microservices vs. modules: blogs.newardassociates.com/blog/2023…
Interesting follow-up to the earlier post on “incompetent but nice” employees, including “I think this is me” responses: jacobian.org/2023/mar/…
I enjoy opinionated guides in general, but this is amazingly well written. I agree with essentially all of it, but I don’t think that’s where my admiration is sourced. spookylukey.github.io/django-vi…
“Never accept a diff if there’s no explanation for the question, “how will you know when this code breaks? how will you know if the deploy is not behaving as planned?” Instrument every commit so you can answer this question in production.”
This should really be in our PR template, along with the “how do I revert this” section.
I still hear this “no deploy on Friday” type thing way more than I would like :(
I also love this bit:
“Policies (and enumerated exceptions to policies, and exceptions to exceptions) are a piss-poor substitute for judgment. Rules are blunt instruments that stunt your engineers' development and critical thinking skills.”
I think (1) and (2) are things that should be addressed if they occur regularly, but generally agree with all this: www.mrlacey.com/2020/07/y…
I’ve done this role, and seen others do this role, although not with this name. It seems challenging to fit it into a bigger company but some are clearly doing it, so maybe that’s just a weakness of where I currently am. posthog.com/blog/what…
A long time back, we had some code freezes that were primarily to give breathing space to figure out what had gone wrong, and those seem reasonable. We had some that were ‘customers are angry, let’s be quiet while they calm down’ and that’s less good. These days we have about 7.5% of the year in scheduled freezes and that’s worst. www.thoughtworks.com/insights/…
This is a few years old, but I only came across it today: public coding conventions. I wish more organisations did this (tbh, I wish more would actually explicitly document them even in private!). It’s great to pick up tips on how to improve things in your own space, but it’s also great when looking at an organisation and getting an impression if you’d be a good fit there.
This is basically just “deploy != release” or even “use feature flags”, but if you want that with a lot of good words behind it: charity.wtf/2023/03/0…
Very much agree with this:
“The most effective developers I’ve worked with understand this, and are adept navigating this zone. They are curious about the perspectives and needs of other stakeholders, and ask good questions. They push back when things don’t make sense, but do so tactfully. And they understand the realities of building software in an industry context, where there are budgets, deadlines, and other less-than fun realities. They don’t expect everything is perfectly spelled out for them (whether by designer, business analyst, or architect), because they know, as the one closest to the implementation, they have a crucial perspective to voice. But they also know they don’t have all the answers. In other words, they know that building the right software is a back-and-forth, collaborative process.”
www.bennorthrop.com/Essays/20…
Essentially, the message here is that the key is finding the Goldilocks size for meetings. Not everyone in one meeting, but not endless 1-1s either. More writing and more async processes sidestep a lot of this too. skamille.medium.com/which-mee…
Ignoring the 10x dev question, this is a good list of productivity impacts: antirez.com/news/112
I’ve had an “architect” title at various times, and I agree with pretty much all of this. The times when it was best was when it was really similar to “an engineer performing a slightly different (but substantially overlapping) set of functions as a senior engineer”. charity.wtf/2023/03/0…
Might have some time soon to catch up on my work reading, and might look at queuing some of these. blog.pragmaticengineer.com/holiday-t…
I would have loved to use this back when I was teaching :) regexcrossword.com
Pretty DMARC education site: www.learndmarc.com - h/t Kostas
When to delegate, vs. when to say “no”: larahogan.github.io/blog/when…
It helps that they say lots of things I agree with, but I enjoyed this episode: overcast.fm/+F4RA618T…
More truth from xkcd: xkcd.com/2582/
Interesting thoughts about when to introduce processes: rkg.blog/desperati…
I 💚 Sentry. dcramer.github.io/the-scale…
There was a really interesting (way less technical) post a while back from Josh Wardle (the Wordle guy, before Wordle when his big things were this and The Button) about lessons learned about how people work together and avoiding negativity in community activities etc. But I annoyingly cannot find it now. www.redditinc.com/blog/how-… - h/t Kostas
It’s sad that Teams is slowly killing Slack. slack.design/articles/…