The EU does some good things, but tends to overreach a lot too: pyfound.blogspot.com/2023/04/t…
The EU does some good things, but tends to overreach a lot too: pyfound.blogspot.com/2023/04/t…
Interesting thoughts on downtime: neuroleadership.com/your-brai…
Thoughts on incident reviews: newsletter.pragmaticengineer.com/p/inciden…
The developer learning curve here is exactly what I have observed (and went through): www.mindtheproduct.com/overengin…
More microservices thoughts: www.bennadel.com/blog/3944…
Interesting post on using a monorepo and ‘living at HEAD’: www.tweag.io/blog/2023…
Good intro to precommit, with a Django focus: builtwithdjango.com/blog/impr…
More microservices thoughts: vlfig.me/posts/mic…
Interesting definition of legacy code in this episode, as code where you can no longer communicate with the author. I quite like this, although probably more as a guideline than a rule. overcast.fm/+F4RCVYuD…
Excellent advice on creating PRs: mtlynch.io/code-revi…
Classifying comments (some of these would be docstrings in Python): antirez.com/news/124
“people are not fungible resources” - somehow people seem to lose this knowledge as they move up the management ladder. jacobsingh.name/the-case-…
Lots of thoughts on this based on the last few years. Should probably write it up when writing opportunities arise again. blog.pragmaticengineer.com/project-m…
Taking the time to do the right thing rather than taking the easy option (with cookies, in this case): leavemealone.com/blog/no-m…
I’ve shared this lots of places, but not here. This is my all-time favourite bug investigation story: www.ibiblio.org/harris/50…
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.