This is a sadly familiar story of chaos in product development. While the remedies are good things to do, I’m not convinced they address the core issue.
This is a sadly familiar story of chaos in product development. While the remedies are good things to do, I’m not convinced they address the core issue.
The analogy is a bit of a stretch in my opinion, but this IKEA Oriented Development post has some good suggestions.
Nice post that explains how to use PyParsing and Q objects in Django to build a search DSL (for example, GitHub’s where you can do “is:open reviewer:tonyandrewmeyer” and so on). [h/t Simon Willison]
Good coverage of pre-fetch and select related in Django.
Great post on using Latin abbreviations, especially cf - I do this too much, which I think originates from my time in education, where it’s an expected style.
DORA, SPACE, and using surveys as a tool to measure developer experience. I’ve never used (or worked for a company that uses) surveys like this - it would be super interesting to do, I think, although the article is right that it’s hard to do well, which can be an impediment.
A few years old, but a good set of uWSGI options that you should consider changing, as well as some lesser known functions of uWSGI. Everything is going ASGI now, and maybe uWSGI 2.1 fixes most of this, but useful in the meantime.
Interesting podcast in the history of Django, and a quote describing a very familiar issue (couldn’t figure a way to nicely share from Overcast to here, so via Mastodon).
“The 85% rule counterintuitively suggests that to reach maximum output, you need to refrain from giving maximum effort. Operating at 100% effort all of the time will result in burnout and ultimately less-optimal results”. via
I’ve used Celery a lot, and it’s been incredibly useful, but it has also been the cause of a lot of pain. I hope to write more about this, and comparing to other tools (e.g. I’m using Huey for simpler cases), when I have more time from next month. But this is an excellent summary of Celery pitfalls and suggested fixes.
Fairly positive thoughts on how LLMs and generative AI in general will impact developers - I think this generally aligns with my (current) thinking.
100%
“Engineers with more experience are usually able to more effectively paint the picture of the rough shape a project will take.” definitely what I have found (in myself and colleagues) as well. I like the focus on getting to the next demo, too. via
How Figma approached DB scaling (spoiler, horizontal via vertical partitioning). Whenever I come across things like this, which match what we did ages ago, I wonder how much of that was luck and how much past-me was better at his job than I realised.
This [post on GitHub stars] (https://the-guild.dev/blog/judging-open-source-by-github-stars) didn’t go where I expected (it covers buying stars) but was interesting. I hear people talking about stars a lot, but pay hardly any attention to it myself. Am I old?
Interesting post on how leaders manage time via @cate@hachyderm.io
The “long ass note” works for me too. And I don’t think I’ve come across Eat the Frog before, but like it and have found something similar works for me too (but I should be more disciplined at it).
This paper gives a good introduction to devex. It would be interesting to see more of what smaller organisations are doing in this space.
Challenges in changing your email address - in my experience, this tends to go particularly wrong at the interfaces of different systems (like the SSO ones mentioned there).
Interesting post on the history of influential programming languages.
Interesting comparison of memory use of a benchmark async task. Go does worse than you’d expect based on the general talk, and Python does pretty reasonable. It would be interesting to do this with a bunch of different Pythons (3.11, 3.12, different async options, threading, etc).
Nice introduction to prompt engineering vs. blind promoting. I feel like if LLMs continue to be widespread and are not a flash-in-the-pan, a lot of people will get better at the blind approach, just like many people learnt how to write effective web searches. In the meantime (and maybe always) an engineering approach has value.
Thoughts on scaling up vs out in the current world - quite focused on BigQuery style work, but also generally applicable. I’ve done a lot of scale out work over the last 15 or so years - I’m not sure how much of that I would change if doing it today.
Suggestions on evaluating dependencies. I would recommend using something like snyk.io’s advisor as well, which does a bunch of this as well as more (like some security checks).
Looking at table size & performance in MySQL.