Good advice about programming guidelines - this sort of understanding in is what distinguishes junior and senior devs, in my experience.
Good advice about programming guidelines - this sort of understanding in is what distinguishes junior and senior devs, in my experience.
Scathing look at NASA’s moon landing programme. Good all round, but I love this: “Visionaries at NASA identified a futuristic new energy source (space billionaire egos) and found a way to tap it on a fixed-cost basis”.
Very detailed, good, description of how to write good commit messages - in the GitHub style world, I would say that with docs like this “commit message” is really “PR title and description” - ie. what will (generally) become the commit when the PR is merged. When squashing, the actual commits don’t deserve the same care.
I think one of the reasons I find people calling Gen AI “AI” so annoying is the cycle that Glyoh describes - most of which I remember from being a student doing AI work, then loosely AI dev work.
This is a clever way of circumventing DKIM but using l= has always been a bad idea, and short expiry a good idea, and over signing critical headers (like Content-Type) essential.
Fun story debugging “the wifi only works is when it’s raining”.
Public sector open-source maintenance makes a lot of theoretical sense, but I doubt it could realistically be funded as suggested, and it would subject to awful whims of successive governments. Also, is the public sector capable of remote work?
Good advice on communicating decisions you disagree with to your team - I’ve had to do this a lot, and did not always do it well.
It would be so great if this became a thing: “Specifically, every employer of software engineers should immediately institute the following benefits program: each software engineer should have a monthly discretionary budget of $50 to distribute to whatever open source dependency developers they want, in whatever way they see fit.” Glyph
Interesting thoughts on providing instruction to people using tools - in the poll on power drills, I guessed the right answer but hadn’t thought about it before (despite using one somewhat regularly for years), and probably should have learnt that.
A scathing look at the people behind Google search and its decline. It is fascinating that someone could be the current head of search at Google when they were head of search at Yahoo 2005-2012.
Tempting idea to have LLM generate draft commit messages.
Although this closing point makes me wary:
I have had it hallucinate hilarious things. Never making up changes (thus far), but doing weird shit like adding “Fixed issue #54” at the end.
An interesting write-up on a supply chain attack but I don’t get why all the example requirements files have .tar.gz URLs in them. Who does that for PyPI packages?
This is pretty neat: a SQL schema generated via an SQL query (via Simon Willison)
I like this particular take on the Apple DoJ case but especially the closing:
Microsoft didn’t fall because of the DoJ. Microsoft fell because the web disintermediated Windows. And in a way, Microsoft actually helped that to happen while trying not be disrupted.
And wait. What the fuck are we talking about? Microsoft didn’t fall. Microsoft is currently worth $3.2 trillion dollars.
“There’s a popular notion that young people don’t have the attention spans for in-depth storytelling. That’s ridiculous. Yes, they’ve become hooked on snackable content from Instagram and TikTok. But they’re also quite happy to binge 10-hour factual series on Netflix, or listen to 90-minute podcasts." - So true, and hardly ever acknowledged!
This post on K8s ends positively, but I can’t see how using K8s directly is a good idea unless you’re big enough to dedicate people to it.
Personally, I do find that deadlines help get things done - I wonder how universally true this is, though - it seems like maybe it’s true for a subset of people.
Lots off great stuff in this Sentry post but especially:
“you’re not going to hire infinite PMs, have them sit on 1:1 customer calls [- you’re] instead going to look for friction - you’re going to find customer pain points, passive negative feedback - and you’re going to optimize the product around that”
And
“developers who go from BigCo to SmallCo often bring Sentry with them. BigCo might have chosen to self-host Sentry, but SmallCo could care less, and simply opts for our cloud service. Eventually SmallCo becomes BigCo, and […] it acts in a lot of ways like a typical funnel”
Me, when I forget to turn ‘Silence Unknown Callers’ back on.
I like the idea of JS (or other languages) in Markdown as in this explainer on Observability 2.0, but “language\n...\n
” already has a well-used meaning (render the content in a pretty-print style). It seems like there should be different syntax for “execute the content and substitute the output”.
I honestly like r8 (the clear version parallelised) most, I think. Some of the other tricks, like using ints not floats are good (and more accurate anyway), but the later solutions get too optimised for my taste.
(It is true that this could matter in some cases, but I suspect that last 6.5x speed up generally isn’t needed and gets outweighed by the much trickier maintenance).
A pretty good summary of how writers about Apple get the iPad all wrong.
(I was full-time iPad for about 8 years, as a software developer, architect, PO, and PM).
Great post looking at the flaws of various Python datetime libraries. Dates and times are hard, but that’s why we use these libraries!
Not all mistakes are learning opportunities, but there are some mistakes it’s a mistake not not to make.
I’m not sure I entirely agree with re-adding backlog items (I guess if it’s infrequent), but I do with the rest. Some of these “mistakes” are hard to make, though, like turning down deals or letting people go.