The Big TDD Misunderstanding https://linkedrecords.com/the-big-tdd-misunderstanding-8e22c...
The Big TDD Misunderstanding https://linkedrecords.com/the-big-tdd-misunderstanding-8e22c...
This post on embeddings by simonw
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...
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.
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...
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
These are some of my favourites:
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.
Mine is: https://danluu.com/p95-skill/
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.
OMFG I didn’t realize that guy could get even more insufferable.
The visualizations help with the understanding while keeping it engaging too
Forgot about this guy!
These writeups and animations are great.
There is so much one can learn in this thread alone.
Merry Christmas :)
This post is a hilarious example of how little most users on HN pay attention to the actual content at hand. The title is explicit about asking for specific posts, yet almost all the comments as of right now just link to a whole blog.
Your comment (and hypocritically, this comment as well) is also a hilarious example of how some people on HN also disregard the actual content of the parent post and instead point out/share their negative meta-observations of the HN community at large.
> "what are your absolute favorite blogs"
A reasonable person could infer from the title and this line that OP is fine with both.
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
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.
The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle
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.
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...
HECK YES!!!!
This! is up my alley. thanks.
-
Ill come back with more when i grok ;-) this whole channel
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.
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.
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.
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.
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-...
I've greatly enjoyed reading this Mainlining blog series from ichernev, about porting an Android phone to PostmarketOS:
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.
It's more hardware than software, but "Infra-Red, In Situ (IRIS) Inspection of Silicon" by Bunnie Huang was interesting.
This is collection of all the blogs that I found insightful.
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...
bytebytego, really good content
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!
Not a blog post, but it could be one, this video about Github Actions: https://www.youtube.com/watch?v=9qljpi5jiMQ
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...
I enjoyed this post on pull/push based query engines - its examples were wonderfully simple.
Jake Lazaroff’s CRDT intro: https://jakelazaroff.com/words/an-interactive-intro-to-crdts...
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.
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
Anything from Brandur is usually great - https://brandur.org/
Also, https://www.applied-cartography.com/ from Justin Duke
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.
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.
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!
We're Knot Friends
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.
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 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.
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
Talking about it is how we figure out what to agree on.
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.
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.)
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.
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.
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.