Just last week at my job we apparently converged on a Kubernetes deployment to host a static site, due to company security policies related to publicly exposing buckets to the internet... I died a little inside that day.
I have personally seen well meaning older devs saying that building on Microsoft Access with VBA is absolutely a viable greenfield stack in 2026 for small business.
And we wonder why ageism exists in our industry. Not saying that’s fair or all of it by any stretch, but ouch. It goes to show many of these worst practices are alive, well, and employable.
This is a reasonable idea if the users maintaining the system aren't technical AT ALL. Think small business who wants a homebrew inventory system for some reason. There is almost always a better tool, but Access is still very approachable for non technical users
did you try making it a slop but ended up making UI good?
fun website, seems we're back in the days of early 2000s when discovering new websites like this was fun
I dunno why nobody used things like external includes in XML, but the worst parts of YAML were there too. (But at least, I think XML doesn't have macro expansions, so that's a win.)
Thank you. I've been doing distributed systems for years, when and to the degree appropriate, but this Worst Of Breed career guidance resource should help me position my skills, for current hiring priorities, to maximize my impact, towards enterprise objectives, going forward.
But seriously, it's not only cynical careerists who are pumping resume keywords like it's a game everyone is playing, and everyone keeps quiet about RDD, etc., because nobody wants to spoil it for everyone. It's also people who are really into one of the keywords, and think it's the most important thing, or the only important thing.
-- Past Case Study #1 --
Context: interview with systems research PhD brand-new founders, after my cold outreach pitch as a "startup generalist" (I think I said it in the headline) who would complement the scientists.
Me: (paraphrased) You're the experts in novel distributed systems research niche X, and I can't help you with that. What I can help with is all the other early startup work you'll need done, like bespoke infrastructure that works with X, Web consoles, mobile apps, some systems programming, product definition, project management, helping academic researchers and industry engineers work together, whatever needs to be done.
PhD founder: (this might be an exact quote) We need an expert, not a generalist.
-- Past Case Study #2 --
Context: interview with a mid-stage startup's CTO, who was hired for distributed systems expertise.
Me: I suspect that a Postgres server on a modest cloud server can handle the entire planet's activity of X. And (since the company's recruiting materials emphasized bias for action, and rapid iteration) we could very quickly build and validate that empirically with simulated transaction load. Of course, in production, we'd set up Postgres with distributed failover, etc.
CTO: I going to need a severalth one-on-one interview with you, an offer is imminent, but it's unclear whether you'll ever be allowed to talk with anyone else on the team, who you pointedly have still not yet met.
I am personally offended by [0]. Maybe you should spend some time doing proper data modeling when you design your app, and maybe adding a new column should be a painful exercise.
Haphazard schema is the quickest way to develop terrible performance, loss of referential integrity, and insane queries. Well, outside of sticking everything into a JSON column.
During my exit interview at a BigCo, when they asked why I was leaving I said "I just don't think it was a very good fit", which I believe is the most polite way of saying "I just didn't like the job".
The manager doing the exit interview started getting defensive and blaming my "attitude problems" [1], and eventually I started explaining that it felt like the entirety of the culture at BigCo, particularly amongst management but even with engineers, came down to "try and justify your existence in the company". Instead of doing things ways that are easy and straightforward, you instead were incentivized to make your code complicated so you can brag about how complicated it is, and then drop constant references to your management about how hard what you're doing is.
The manager didn't like this response, and got more defensive, we ended up going back and forth, and eventually the interview ended and despite taking a pretty considerable paycut I was ok with my decision.
I didn't know the term "Resume Driven Development" until after I left, but that was a pretty accurate description.
[1] Not completely wrong, but that doesn't absolve them of their sins.
This might now be one of my favorite websites in the internet. It won me when I saw the "Excel Backend" design pattern [0]. I wish so fucking much I had never seen this before or heard of using Excel as a database.
update: I'm feeling actual physical pain by reading this and remembering every single piece of software or website I've seen that actually applies these patterns [1].
29 comments
[ 3.1 ms ] story [ 70.7 ms ] threadAnd we wonder why ageism exists in our industry. Not saying that’s fair or all of it by any stretch, but ouch. It goes to show many of these worst practices are alive, well, and employable.
I'm _not staying you should_, but if it works and makes money, it may not be that dumb.
UUencode all 354 fields (64MB string) and put it in a hidden input field!
Twice!!
But seriously, it's not only cynical careerists who are pumping resume keywords like it's a game everyone is playing, and everyone keeps quiet about RDD, etc., because nobody wants to spoil it for everyone. It's also people who are really into one of the keywords, and think it's the most important thing, or the only important thing.
-- Past Case Study #1 --
Context: interview with systems research PhD brand-new founders, after my cold outreach pitch as a "startup generalist" (I think I said it in the headline) who would complement the scientists.
Me: (paraphrased) You're the experts in novel distributed systems research niche X, and I can't help you with that. What I can help with is all the other early startup work you'll need done, like bespoke infrastructure that works with X, Web consoles, mobile apps, some systems programming, product definition, project management, helping academic researchers and industry engineers work together, whatever needs to be done.
PhD founder: (this might be an exact quote) We need an expert, not a generalist.
-- Past Case Study #2 --
Context: interview with a mid-stage startup's CTO, who was hired for distributed systems expertise.
Me: I suspect that a Postgres server on a modest cloud server can handle the entire planet's activity of X. And (since the company's recruiting materials emphasized bias for action, and rapid iteration) we could very quickly build and validate that empirically with simulated transaction load. Of course, in production, we'd set up Postgres with distributed failover, etc.
CTO: I going to need a severalth one-on-one interview with you, an offer is imminent, but it's unclear whether you'll ever be allowed to talk with anyone else on the team, who you pointedly have still not yet met.
Haphazard schema is the quickest way to develop terrible performance, loss of referential integrity, and insane queries. Well, outside of sticking everything into a JSON column.
0: https://worstofbreed.net/patterns/schema-bureaucracy/
I want to name names - I could cross-reference some of these with specific company names that you've heard of, but I shan't.
I'll definitely keep this website in my hip pocket to privately throw at teams going forward, as needed.
The manager doing the exit interview started getting defensive and blaming my "attitude problems" [1], and eventually I started explaining that it felt like the entirety of the culture at BigCo, particularly amongst management but even with engineers, came down to "try and justify your existence in the company". Instead of doing things ways that are easy and straightforward, you instead were incentivized to make your code complicated so you can brag about how complicated it is, and then drop constant references to your management about how hard what you're doing is.
The manager didn't like this response, and got more defensive, we ended up going back and forth, and eventually the interview ended and despite taking a pretty considerable paycut I was ok with my decision.
I didn't know the term "Resume Driven Development" until after I left, but that was a pretty accurate description.
[1] Not completely wrong, but that doesn't absolve them of their sins.
> "We are doing DevOps now! The developers write Dockerfiles and the Ops team operates Jenkins, which cannot build the Dockerfiles."
I have DEFINITELY seen this done in production back when containers were en vogue! This and Dockerfiles passed around by email.
update: I'm feeling actual physical pain by reading this and remembering every single piece of software or website I've seen that actually applies these patterns [1].
[0]: https://worstofbreed.net/patterns/excel-backend/
[1]: https://worstofbreed.net/patterns/js-bundle-bloat/
But instead it crystallizes the core methodologies of the entire industry.
This should probably be some sort of industry certification or ISO standard.