Ask HN: Share your favorite software blog posts of 2023
85 comments
Bicycle by Bartosz Ciechanowski: https://ciechanow.ski/bicycle/ - HN post: https://news.ycombinator.com/item?id=35343495
Bartosz has many great blog posts, maybe most famously the one on mechanical watches published in 2022: https://ciechanow.ski/mechanical-watch/
HN posts for Bartosz's blog: https://news.ycombinator.com/from?site=ciechanow.ski
Bartosz has many great blog posts, maybe most famously the one on mechanical watches published in 2022: https://ciechanow.ski/mechanical-watch/
HN posts for Bartosz's blog: https://news.ycombinator.com/from?site=ciechanow.ski
That Bicycle post is Pulitzer worthy - every middle school student should be taught that post in science.
As a cyclist for decades - I still learned a lot - how to put to words that which I had innate muscle memory knowledge of, but no language for.
The demonstrations are fantastic.
Hands down should get some sort of IRL award of meaning.
I forgot I had seen the watch as well... Man this guy is amazing!
Thanks for resurrecting these for me.
As a cyclist for decades - I still learned a lot - how to put to words that which I had innate muscle memory knowledge of, but no language for.
The demonstrations are fantastic.
Hands down should get some sort of IRL award of meaning.
I forgot I had seen the watch as well... Man this guy is amazing!
Thanks for resurrecting these for me.
Technically not a blog, but the FIRESHIP youtube channel changed my life: https://www.youtube.com/@Fireship
A wild mix of super short videos about current software engineering topics, extremely well made, always on the edge of slapstick comedy, trashy memes, inside jokes, but still extremely densely packed with actual information. Plus, the nearly daily video series "the code report" is godlike: https://www.youtube.com/watch?v=GyllRd2E6fg&list=PL0vfts4Vzf...
A wild mix of super short videos about current software engineering topics, extremely well made, always on the edge of slapstick comedy, trashy memes, inside jokes, but still extremely densely packed with actual information. Plus, the nearly daily video series "the code report" is godlike: https://www.youtube.com/watch?v=GyllRd2E6fg&list=PL0vfts4Vzf...
HECK YES!!!!
This! is up my alley. thanks.
-
Ill come back with more when i grok ;-) this whole channel
This! is up my alley. thanks.
-
Ill come back with more when i grok ;-) this whole channel
How Instagram scaled to 14 million users with only 3 engineers: https://read.engineerscodex.com/p/how-instagram-scaled-to-14...
Where LLMs are headed: https://blog.quastor.org/p/language-models-future
SwiftUI at Airbnb: https://www.infoq.com/news/2023/10/airbnb-transitioning-swif...
GPU Computing Explained: https://codeconfessions.substack.com/p/gpu-computing
Building and operating S3: https://www.allthingsdistributed.com/2023/07/building-and-op...
Meta’s new Serverless platform: https://read.engineerscodex.com/p/meta-xfaas-serverless-func...
Where LLMs are headed: https://blog.quastor.org/p/language-models-future
SwiftUI at Airbnb: https://www.infoq.com/news/2023/10/airbnb-transitioning-swif...
GPU Computing Explained: https://codeconfessions.substack.com/p/gpu-computing
Building and operating S3: https://www.allthingsdistributed.com/2023/07/building-and-op...
Meta’s new Serverless platform: https://read.engineerscodex.com/p/meta-xfaas-serverless-func...
Excellent posts indeed! Thanks for sharing these.
Working With Discovery Trees: https://www.industriallogic.com/blog/discovery-trees/
Happened to see Paige Watson present about FaST Agile at the PhillyXP meetup group and then tried some of the concepts with my team at work to great success. We were looking for a good way to turn high-level product asks into actionable work and Discovery Trees fit the bill for us.
Happened to see Paige Watson present about FaST Agile at the PhillyXP meetup group and then tried some of the concepts with my team at work to great success. We were looking for a good way to turn high-level product asks into actionable work and Discovery Trees fit the bill for us.
New amazing web security research by James Kettle:
Smashing the state machine: the true potential of web race conditions
https://portswigger.net/research/smashing-the-state-machine
The talk (on YouTube) is also absolutely brilliantly done.
James finds new vulnerabilities classes where others don’t even see potential for problems. Absolutely amazing!
Smashing the state machine: the true potential of web race conditions
https://portswigger.net/research/smashing-the-state-machine
The talk (on YouTube) is also absolutely brilliantly done.
James finds new vulnerabilities classes where others don’t even see potential for problems. Absolutely amazing!
This post on embeddings by simonw
https://simonwillison.net/2023/Oct/23/embeddings/
https://simonwillison.net/2023/Oct/23/embeddings/
This one as well by a former intern from a decade ago who now writes on python and ml internals:
How Many Lines of C it Takes to Execute a + b in Python?
https://codeconfessions.substack.com/p/a-war-story-involving...
How Many Lines of C it Takes to Execute a + b in Python?
https://codeconfessions.substack.com/p/a-war-story-involving...
Thanks for sharing Bosky.
I think you gave the wrong URL :)
This one talks about how CPython executes a + b: https://codeconfessions.substack.com/p/cpython-dynamic-dispa...
I think you gave the wrong URL :)
This one talks about how CPython executes a + b: https://codeconfessions.substack.com/p/cpython-dynamic-dispa...
Ow. There's a paywall halfway through. Don't do what I did and get interested in the story if you aren't up to subscribing.
Maybe the reason for CoW being triggered is reference counting. Does anyone know?
Usually from GC. Anthony Sottile has a nice explanatory video: https://youtu.be/sdmcCQ7Em04?si=9PObAJixALFiZ9vd
Sorry about that. Most of my posts are open, but I usually put one of these behind the paywall in a month. I opened this one.
The Big TDD Misunderstanding
https://linkedrecords.com/the-big-tdd-misunderstanding-8e22c...
My opinion on methodologies is that if it is too often misunderstood, then it is wrong.
The entire point of giving a methodology a name and writing about it is to get everyone on the same page. So if people have different ideas on what TDD is, then people should stop talking about TDD until everyone agree what is and what is not TDD.
And only after everyone agrees, one should talk about the pros and cons and assess the success of the methodology depending on the situation. "you are doing it wrong" is not helpful.
Back to the article. I think not mentioning TDD at all would make it a better article.
The entire point of giving a methodology a name and writing about it is to get everyone on the same page. So if people have different ideas on what TDD is, then people should stop talking about TDD until everyone agree what is and what is not TDD.
And only after everyone agrees, one should talk about the pros and cons and assess the success of the methodology depending on the situation. "you are doing it wrong" is not helpful.
Back to the article. I think not mentioning TDD at all would make it a better article.
I've had this problem with team vocabulary. Once one word gets used to describe 2 or more things it becomes impossible to roll back.
I tried banning a particular word once and coming up with 6 new words on the basis that you couldnt tell which of the 6 meanings somebody was using unless you used a different term for each one. That didnt work very well. People got too attached to the old, overloaded term.
Expecting an entire industry to stop using a term theyve become used to is not realistic.
I tried banning a particular word once and coming up with 6 new words on the basis that you couldnt tell which of the 6 meanings somebody was using unless you used a different term for each one. That didnt work very well. People got too attached to the old, overloaded term.
Expecting an entire industry to stop using a term theyve become used to is not realistic.
Talking about it is how we figure out what to agree on.
TDD cultists are awful about that, none of them do TDD the same way and if you don’t like TDD it’s because you’re wrong and are certainly doing TDD wrong.
I wrote a short rant about it last week: https://dev.to/thiht/tdd-is-a-personal-practice-3o76
I wrote a short rant about it last week: https://dev.to/thiht/tdd-is-a-personal-practice-3o76
They will all be misunderstood, unless the title is the manifesto. But since the title needs to be short, it won't be.
Another example: Nation State. I can't get a clear answer to what that really means :-).
Back to computers: REST is a great example.
Another example: Nation State. I can't get a clear answer to what that really means :-).
Back to computers: REST is a great example.
The entire point of giving a methodology a name is making money off it as a tech influencer slash management consultant. Those people don't care one iota about whether everyone agrees or not.
The biggest missing element, in my mind, of the pro-"classicist" and anti-"mockist" view is that the practice of writing unit tests with mocking leads to refactoring your code until it works with that approach, which in turn leads to better-designed code. I don't like the emphasis of "yeah but refactoring code leads to needing to rewrite mocked tests", because if you've designed your code well, then the need to adjust an api boundary should be less frequent than the need to adjust the internal implementation details. Focusing on integration tests means you can get away with poorly designed code full of corner cases that your integration tests can't catch. Besides, "we can keep the fast feedback loop with parallel tests" really increases the demands on complicated tooling that breaks often.
You can only get away with poorly designed code if that's not caught in the code review. I'd argue that while that might be a nice side benefit of some testing practices, forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals!
(Also, you can easily run integration tests in parallel with a little planning and attention to detail. For example, if your IDs don't rely on a sequence (like UUIDs), you can generally run them in parallel regardless of database connections.)
(Also, you can easily run integration tests in parallel with a little planning and attention to detail. For example, if your IDs don't rely on a sequence (like UUIDs), you can generally run them in parallel regardless of database connections.)
[deleted]
> forcing you to rewrite your code isn't relevant to the test - in fact the opposite! Your tests should work irrespective of your code's internals!
Are you avoiding rewriting your code so you can write integration tests, or are you writing integration tests so you can avoid rewriting your code?
Those that have been around the block of refactoring code so you can write good unit tests, tend to realize that the better-designed code isn't a side benefit. It's the entire point. The test is the side benefit.
Integration tests should be avoided if the same coverage can be reached with a refactor and some unit tests. For instance, it's very common for components to rely on complicated combinations of state. For instance, imagine a nightmare component that has nine boolean state parameters. To integration-test every combination, that's 512 cases. But in cases like those, you might discover through refactoring that some of those state combinations can compressed. For instance, you might be able to refactor into three sub-components, each of which take three boolean parameters and return one boolean result, and where the parent component only depends on those three booleans, which can be mocked. So then in that case, you've reduced the amount of tests you need to write to 32 total... that's 1/16th the effort.
I mean, I know that in common practice, neither are done, and people just leave the component largely untested, and then get bug reports that they close as "Can't reproduce".
Are you avoiding rewriting your code so you can write integration tests, or are you writing integration tests so you can avoid rewriting your code?
Those that have been around the block of refactoring code so you can write good unit tests, tend to realize that the better-designed code isn't a side benefit. It's the entire point. The test is the side benefit.
Integration tests should be avoided if the same coverage can be reached with a refactor and some unit tests. For instance, it's very common for components to rely on complicated combinations of state. For instance, imagine a nightmare component that has nine boolean state parameters. To integration-test every combination, that's 512 cases. But in cases like those, you might discover through refactoring that some of those state combinations can compressed. For instance, you might be able to refactor into three sub-components, each of which take three boolean parameters and return one boolean result, and where the parent component only depends on those three booleans, which can be mocked. So then in that case, you've reduced the amount of tests you need to write to 32 total... that's 1/16th the effort.
I mean, I know that in common practice, neither are done, and people just leave the component largely untested, and then get bug reports that they close as "Can't reproduce".
Thanks for the heads up. It’s 10 years old, but I hadn’t seen “Mockists Are Dead. Long Live Classicists.” before (https://www.thoughtworks.com/insights/blog/mockists-are-dead...).
The Classicist point of view resonates strongly with me - I’ve long considered mocking in tests to be a code smell, and only usually justified for stubbing external services or hardware.
The Classicist point of view resonates strongly with me - I’ve long considered mocking in tests to be a code smell, and only usually justified for stubbing external services or hardware.
> Now, you change a little thing in your code base, and the only thing the testing suite tells you is that you will be busy the rest of the day rewriting false positive test cases.
Never happened to me, and we use a lot of junit tests at work.
I don't see the value in "Do not isolate code". Isolating a single method or such is often necessary, especially a unit test of a Utils class. But I only tend to do this if the "user story" centric test cases don't end up covering everything.
Never happened to me, and we use a lot of junit tests at work.
I don't see the value in "Do not isolate code". Isolating a single method or such is often necessary, especially a unit test of a Utils class. But I only tend to do this if the "user story" centric test cases don't end up covering everything.
This is pretty good and much of it resonates with my recent thinking on testing (I seem to revisit this topic every few years and rethink testing in general). I appreciate that it's pragmatic and not dogmatic. There's a lot of "tradition" in testing that has kind of built up over the years and not a lot of questioning the assumptions. Thanks for sharing.
The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle
https://labs.quansight.org/blog/building-scipy-with-flang
https://labs.quansight.org/blog/building-scipy-with-flang
Wow! Thanks for sharing. Sometimes I get disheartened about programming, then posts like this remind me how complicated the world actually is. And how much perseverance and elbow grease we put in to make the world simpler.
I haven't found my favorite this year, but instead I was heavily into newsletters. Currently I'm subscribed to:
https://www.pragmaticengineer.com/ - industry insights.
https://www.workspaces.xyz/ - people sharing their home office setup incl. photos.
https://bigtechdigest.substack.com/ - all recent tech articles from companies engineering blogs.
https://leaddev.com/ - leadership stuff.
https://hackernewsletter.com/ - weekly hackernews summary nicely split into categories.
https://www.ben-evans.com/ - product and business around tech with nice deep dives.
https://www.pragmaticengineer.com/ - industry insights.
https://www.workspaces.xyz/ - people sharing their home office setup incl. photos.
https://bigtechdigest.substack.com/ - all recent tech articles from companies engineering blogs.
https://leaddev.com/ - leadership stuff.
https://hackernewsletter.com/ - weekly hackernews summary nicely split into categories.
https://www.ben-evans.com/ - product and business around tech with nice deep dives.
Please share one post from each
I’m a fan of Terry Tao’s blog, which while not strictly software, is both good for advice and discusses one of my passions — formal verification.
https://terrytao.wordpress.com/2023/12/05/a-slightly-longer-...
https://terrytao.wordpress.com/career-advice/ask-yourself-du...
Both previously appeared on HN.
https://terrytao.wordpress.com/2023/12/05/a-slightly-longer-...
https://terrytao.wordpress.com/career-advice/ask-yourself-du...
Both previously appeared on HN.
Another shameless plug. I'm pretty proud of my Learning Zig series (1). It's been translated into Chinese, Russian and Korean.
Some may know my other writings (e.g. Little Go/Redis/MongoDB Book). I don't feel like I captured Zig quite as well, but it's hopefully a useful resources especially if you're coming from a garbage collected language.
(1) https://www.openmymind.net/learning_zig/
Some may know my other writings (e.g. Little Go/Redis/MongoDB Book). I don't feel like I captured Zig quite as well, but it's hopefully a useful resources especially if you're coming from a garbage collected language.
(1) https://www.openmymind.net/learning_zig/
I have read your blogs and The Little Go Book. I must say that they are great. Thank you for writing those and keep writing.
https://samwho.dev/blog/
The visualizations help with the understanding while keeping it engaging too
The visualizations help with the understanding while keeping it engaging too
Paul Graham's Essays keep me amused during this winter season - https://www.paulgraham.com/articles.html
They go way back, and I do expect(and look forward to) new content.
Came across them via multiple sources, but what got me hooked was a reference from Robert Morris' work.
Kinda funny to reference this here :D.
Came across them via multiple sources, but what got me hooked was a reference from Robert Morris' work.
Kinda funny to reference this here :D.
Anything from Brandur is usually great - https://brandur.org/
Also, https://www.applied-cartography.com/ from Justin Duke
Also, https://www.applied-cartography.com/ from Justin Duke
Jake Lazaroff’s CRDT intro: https://jakelazaroff.com/words/an-interactive-intro-to-crdts...
https://danluu.com/ is my all time favourite. Unfortunately hasn’t posted in 2023, but I reread old posts often.
do you have a specific post?
I think entire blog would be too big to check out, just to be in line with this post
Mine is: https://danluu.com/p95-skill/
These are some of my favourites:
- https://danluu.com/culture/
- https://danluu.com/p95-skill/
- https://danluu.com/wat/
- https://danluu.com/look-stupid/
- https://danluu.com/culture/
- https://danluu.com/p95-skill/
- https://danluu.com/wat/
- https://danluu.com/look-stupid/
I really like the "culture matters" and "look stupid" posts. I've been allowing myself to look stupid since I was a kid in school. Dan is humble (frequently saying things such as "If an idiot like me can [do X]"), but I think this strategy requires a certain degree of intellectual security. For me the logic isn't just "this question may sound stupid but the knowledge gained outweighs that". It's also "this question may sound stupid but anyone who thinks I'm dumb is wrong".
I do not know how real-world accurate it is, but I enjoy the p95 post. For a huge number of skills in my life, I got to an acceptable level of performance, and then more or less never developed it.
I enjoyed this post on pull/push based query engines - its examples were wonderfully simple.
https://justinjaffray.com/query-engines-push-vs.-pull/
https://justinjaffray.com/query-engines-push-vs.-pull/
I wrote a lot of articles on fundamentals (verifiable time estimation, leverage points with systems theory, using the Kelly criterion to shape project portfolio, system observability, evolution, etc.) with the intention of ending up on lists like these. None of them gained much traction, which means I need to get better at condensing the key points.
In the end, I think my most popular article of the year ended up being a relatively short note on how Bill Tindall approached software development for the moon landings: https://two-wrongs.com/tindall-on-software-delays.html
In the end, I think my most popular article of the year ended up being a relatively short note on how Bill Tindall approached software development for the moon landings: https://two-wrongs.com/tindall-on-software-delays.html
I was happy to get back into blogging in 2023 and write ‘A trip to the internet in 1996 with The Rough Guide 2.0’ -> https://www.planetjones.net/blog/10-06-2023/a-trip-to-the-in...
That was cool, thanks :) [p.s. you have a typo in infoseek.com (.con)]
Not a blog post, but it could be one, this video about Github Actions: https://www.youtube.com/watch?v=9qljpi5jiMQ
We're Knot Friends
https://jeremykun.com/2023/04/01/were-knot-friends/
https://jeremykun.com/2023/04/01/were-knot-friends/
This is collection of all the blogs that I found insightful.
https://prashantbarahi.com.np/read-in-public
https://prashantbarahi.com.np/read-in-public
Here’s a shameless plug for my collection of short, succinct Django articles at https://photondesigner.com/articles
The latest article is: “The simplest way to build an instant messaging app with Django ” https://www.photondesigner.com/articles/instant-messenger
The latest article is: “The simplest way to build an instant messaging app with Django ” https://www.photondesigner.com/articles/instant-messenger
Nice!
Shameless plug, as many others on this thread seem to have done. :) I wrote about the spectrum of macro systems available in different languages and why I think greater adoption for macros in development has been slow here: https://lambdaland.org/posts/2023-10-17_fearless_macros/
I learned a lot while writing it!
I learned a lot while writing it!
This post (The Techno-Optimist Manifesto), but in particular this section (that contains such gems as “Our enemy is anti-merit, anti-ambition, anti-striving, anti-achievement, anti-greatness”):
https://a16z.com/the-techno-optimist-manifesto/#section--13
"In lieu of endnotes, read the works of these people." Goes on to list 53 authors in alphabetical order.
Getting to the point he’s at requires a lot of patience, dedication and effort. And money to buy time.
Probably the most pompous drivel I’ve read all year.
This isn’t a software blog post. It’s a juvenile political screed with some tech buzzwords.
This isn’t a software blog post. It’s a juvenile political screed with some tech buzzwords.
OMFG I didn’t realize that guy could get even more insufferable.
I've greatly enjoyed reading this Mainlining blog series from ichernev, about porting an Android phone to PostmarketOS:
https://mainlining.dev/
It teaches you how to probe the system, scrape out the proprietary microcode, and use it to build against a newer kernel (albeit with much tweaking)
https://mainlining.dev/
It teaches you how to probe the system, scrape out the proprietary microcode, and use it to build against a newer kernel (albeit with much tweaking)
This book review of Kieran Egan‘s Educated Mind: https://www.astralcodexten.com/p/your-book-review-the-educat...
I haven’t thought much about education and school, but this got me interested.
I haven’t thought much about education and school, but this got me interested.
Like some of the renegades in the comments, I'm tempted to share an entire blog. Instead I'll share some highlights from my favorite blog of 2023. It's not tech-focused per se, but rather politics/policy by a former "Last Week Tonight w/ John Oliver" writer and EPA speechwriter, Jeff Mauer. The blog is called "I Might Be Wrong". It's a perfect mix of smart and funny.
Here are some highlights from this past year:
"YIKES: Bing's Chatbot Made a Pass at Me After Only 90 Minutes of Relentless Prodding" https://imightbewrong.substack.com/p/yikes-bings-chatbot-mad...
Six Products That Will Gently Defeat Your Baby. https://imightbewrong.substack.com/p/six-products-that-will-...
AI Spells Doom for Incompetent Hacks. https://imightbewrong.substack.com/p/ai-spells-doom-for-inco...
The "Rules" About Which Actors Can Play Who Never Made Sense. https://imightbewrong.substack.com/p/the-rules-about-which-a...
Holy Moly Do We Ever Over-Value College https://imightbewrong.substack.com/p/holy-moly-do-we-ever-ov...
Before You End Fencing Scholarships, Consider the Impact That Would Have on Major League Fencing https://imightbewrong.substack.com/p/before-you-end-fencing-...
Why Is Homelessness a Municipal Issue? https://imightbewrong.substack.com/p/why-is-homelessness-a-m...
EDIT: Just noticed the "software" qualifier in the OP. I almost deleted this comment, but it includes a few software-adjacent articles, on AI, so I'll leave it up.
Here are some highlights from this past year:
"YIKES: Bing's Chatbot Made a Pass at Me After Only 90 Minutes of Relentless Prodding" https://imightbewrong.substack.com/p/yikes-bings-chatbot-mad...
Six Products That Will Gently Defeat Your Baby. https://imightbewrong.substack.com/p/six-products-that-will-...
AI Spells Doom for Incompetent Hacks. https://imightbewrong.substack.com/p/ai-spells-doom-for-inco...
The "Rules" About Which Actors Can Play Who Never Made Sense. https://imightbewrong.substack.com/p/the-rules-about-which-a...
Holy Moly Do We Ever Over-Value College https://imightbewrong.substack.com/p/holy-moly-do-we-ever-ov...
Before You End Fencing Scholarships, Consider the Impact That Would Have on Major League Fencing https://imightbewrong.substack.com/p/before-you-end-fencing-...
Why Is Homelessness a Municipal Issue? https://imightbewrong.substack.com/p/why-is-homelessness-a-m...
EDIT: Just noticed the "software" qualifier in the OP. I almost deleted this comment, but it includes a few software-adjacent articles, on AI, so I'll leave it up.
It's more hardware than software, but "Infra-Red, In Situ (IRIS) Inspection of Silicon" by Bunnie Huang was interesting.
https://www.bunniestudios.com/blog/?p=6712
https://www.bunniestudios.com/blog/?p=6712
Building a scalable Django WebSocket chat (messenger) app with Centrifugo
https://centrifugal.dev/docs/tutorial/intro
[deleted]
A Casual Discussion on L4 Load Balancing - by @laixintao(in Chinese)
https://www.kawabangga.com/posts/5301
https://www.kawabangga.com/posts/5301
bytebytego, really good content
For me, it was a post from Levels.fyi, inspiring story about simple and effective tech solutions.
"How Levels.fyi scaled to millions of users with Google Sheets as a backend"
https://www.levels.fyi/blog/scaling-to-millions-with-google-...
"How Levels.fyi scaled to millions of users with Google Sheets as a backend"
https://www.levels.fyi/blog/scaling-to-millions-with-google-...
Etheryte(2)
This is going to be a shameless plug of my own writing, not even technical but I needed to put it down in writing, so I did.
I found Timers to be a perfect tool to free up my brain and reminding me when I need to do something else. Making tea but I need to walk around, or do something else; timer on and I can get back to the right brew that I wanted. Browsing HackerNews but I need to get out after a specific time; timer on and I can get out.
Start a Zoom meeting but the attendant(s) are missing; timer on for 5 minute increment, then decide to ignore/cancel the meeting in either 5-min or 10-min.
https://brajeshwar.com/2023/timer/
I found Timers to be a perfect tool to free up my brain and reminding me when I need to do something else. Making tea but I need to walk around, or do something else; timer on and I can get back to the right brew that I wanted. Browsing HackerNews but I need to get out after a specific time; timer on and I can get out.
Start a Zoom meeting but the attendant(s) are missing; timer on for 5 minute increment, then decide to ignore/cancel the meeting in either 5-min or 10-min.
https://brajeshwar.com/2023/timer/
P.S. Wishing you all a Merry Christmas and Happy Holidays!