What's the fastest you've gone from making a technical decision which wasn't easily reversible to regretting that decision?
Posted by TheTimeDictator@reddit | ExperiencedDevs | View on Reddit | 156 comments
More or less what the title says!
tetryds@reddit
It makes no sense to "regret" making a technical decision. Decisions shouldn't be a feeling lucky dice roll. You may make a decision then realize your assumptions were wrong, or the business needs changed, or there was a lot of miscommunication. Either way a good technical decision must account for these possibilities.
If you mean "what's the fastest you realized you didn't do your job properly?" Then yeah, same day.
minn0w@reddit
If you have this in the form of a presentation, I have many managers that need this education :-p
tetryds@reddit
Oh boy so many people do, myself from the past included
minn0w@reddit
Why is your post voted down so hard?
tetryds@reddit
This sub is not what you think it is
minn0w@reddit
lol
FinestObligations@reddit
Your opinion certainly makes sense given this title.
tetryds@reddit
People are too resentful of their work. If you make a fucking technical decision it's a decision, not something to "regret" huh
FinestObligations@reddit
Sometimes, even if technical, you have to take decisions on incomplete information. And sometimes those decisions don’t pan out due to factors that couldn’t have been anticipated.
Most people would call those regrettable.
-shrug-@reddit
I regret going for a run one day in 2016 because a car ran the light and hit me. That doesn’t mean my decision to go for a run was bad, or I should have done anything differently. It means wow, that totally sucked. It’s like saying “I’m so sorry” when someone says their pet died: and your response is the equivalent of saying “Why, did you kill him!??”
tetryds@reddit
Work is work
Pagedpuddle65@reddit
You must be fun in standups.
Lake_Erie_Monster@reddit
The difference between companies with a killer tech stack and the ones where the founders actually shipped something and made money.
Overkill is the new standard sadly.
davvblack@reddit
this is an unproductive stance. i don’t mean that colloquially, i mean that literally: this is the mindset that leads to extremely low output incompatible with anything but the largest enterprise companies. if you aren’t willing to take a bet with a 90% chance of success, you’re wasting your time getting it to 100%, and if you haven’t lost a 90% chance bet then you just haven’t taken that many bets.
tetryds@reddit
If you are not consciously making a decision with 90% confidence then you are just throwing dice. If you are, then there is no such thing as "regret" because that is part of the context of that decision. Is it that hard a concept to grasp?
davvblack@reddit
i see what you mean. this is more about a zenlike personal detachment from success or failure, which can be good for your mental health.
tetryds@reddit
It's the difference between "oh no I should have done that instead" and "well, I didn't know this at the time, or didn't have enough time or my assumptions which I validated didn't hold true afterall". That's simply being mature and making a relevant technical decision. This is how technical decisions must be made. I would be very concerned if I hired engineers who don't do this.
maulowski@reddit
6 hours
ericmutta@reddit
Defined the Price, column in my database as type INT because my country doesn't use cents. Then my very first customer wanted to store prices in dollars.
lmyslinski@reddit
Very recently - I had to pick a platform for building an agentic app (text-to-sql).
I could go with whatever I wanted (Vercel AI SDK) or what the customer wanted (MS Copilot SDK) - they are an MS partner and wanted to stay within the MS ecosystem. I highlighted the risks (immature platform, closed ecosystem) but still decided to go with it to best fit customer expectations.
I definitely underestimated the absurd level of incompetence of Microsoft.
Most basic features were a problem. Documentation was either missing, straight up incorrect, at worst insanely confusing. The amount of time I've spent trying to work around the platform limitations was far greater than I've expected.
Here's some examples: File export? Not supported. What about file uploads? Also not supported. Memory? Had to implement it myself.
The worst issue by far was insanely overcomplicated and (still broken) per-user authentication. I don't recall seeing something so overcomplicated, there isn't a single working example in their docs.
I've had to make serious architectural hoops to make this platform even work for the most basic features.
We could've spent half the time delivering twice the features had we built it from scratch ourselves.
ChristianMay21@reddit
Microsoft's business strategy is pretty much "Deliver the bare minimum for absolutely every product."
There's few things they do particularly well.
general_dispondency@reddit
MongoDB
ChristianMay21@reddit
What made you regret it? (I just started a project using MongoDB)
kokanee-fish@reddit
Redshift
PabloZissou@reddit
Oh I was considering it for a project what was your bad experience with it?
No_Investigator7017@reddit
My experience with mongo is it's good for document storage and really good and flexible to "scale" but the truth is by the time you get to a production grade system and a software lifecycle in that the nature of the logic will be to change meaning it will be inevitable for data migrations and other such work. So where it's bad - hard to do data migrations at large scale - the ability to use the data for report generation or analysis is more complicated than standard SQL
There are more but the key is this, for like data you don't really change or for data with clear relations to go with relational DB and if you need a flexible object you can even store this.
Mongo is still great at what it does but pick your use case with extreme care the faith of the next years will pivot on this decision.
My rule is relational until it can be proven otherwise.
A website with users and the transactional nature of a product more often requires SQL.
A website to serve product details only and no transactions mongo will be best.
Postgress allows both options.
Antagonyzt@reddit
They didn’t know how to use it
throwaway8u3sH0@reddit
But it's web scale 😋
latchkeylessons@reddit
Took a contract in the early/mid 2000's for a manufacturing company wanting to get their fancy new .NET Framework platform somehow running on Linux to save costs. I was still off the Dotcom bust and it sounded interesting so I said yes. About a week in I realized the state of things and that I wasn't going to single-handedly make an open source project to get .NET runtimes operating in Linux - a job which I'm sure employs thousands of MS engineers across the world maintaining .NET/Core now. I fired myself after that first week and suggested to the client they not sink funds in the project.
FutureSchool6510@reddit
I can’t think of a technical decision I have made that I have come to regret. Maybe they are still waiting to bite me lol.
I can, however, think of plenty of technical decisions other people have made that I regretted they made. Some of them I am still in the process of changing.
First one that came to mind: Someone decided Amazon DocumentDB was a good idea just because the thing we wanted to store was JSON. Turned out it wouldn’t have mattered what DB we used since we store the entire payload as a schemaless string and never look inside it. DocumentDB is a very weird DB if you ask me. It’s “MongoDB compatible” except it’s not 100% compatible because it technically isn’t actually MongoDB. I’ve heard someone say it’s built on Postgres, dunno if that’s true but wouldn’t surprise me.
party_egg@reddit
Shooting the architect a message to get his opinion on a new project before I started
Gooeyy@reddit
I’ve never worked with a proper architect, what’s the implication here?
anonyuser415@reddit
It's like notifying your city that you're going to build a small shed in your backyard
Ostensibly it seems like a good idea, but your shed is now going to take 10x as long to build
PM_Me_Your_Java_HW@reddit
I’m going through this right now and it’s fucking infuriating. The product is built. We got results faster than ever before. Then I’m ordered to get sign offs from architects and other “”security teams” and its brick wall after brick wall. Sorry bud, this needs to be in Azure even though it runs completely fine in AWS and you also need to engineer it at the same complexity as if we had 100k users.spoiler: We have 8 that would be using it daily and then open it up to our enormous client count of 70… I left my last job to get away from that bureaucratic tomfoolery and now I’m right back in it.
PM_ME_YOUR_MUSIC@reddit
Are we the same person
PM_Me_Your_Java_HW@reddit
Are you a short chunky bald man who likes to cook and engineer things? If so, yes!
PM_ME_YOUR_MUSIC@reddit
I’m making ribs
Priderage@reddit
I'm kind of with him on the "put it in the same cloud provider as the rest of the company" but that scaling to 100k users thing can fuck right off.
OtherwiseUniversity7@reddit
what if they are asking for multi-cloud deployment (well, because we must be multi-cloud multi-region resilient)
Prod_Is_For_Testing@reddit
I think it’s more like a school building a playground. There are safety standards, code compliance, vendor relationships, etc that a PE teacher wouldn’t know about
Frenzeski@reddit
ffs this is such a stupid way for architects to work, people will subvert them at every opportunity
chikamakaleyley@reddit
lol i'd almost argue that they're doing the right thing but we're stubborn and want to work on the project we want, so we should circumvent them and just make sure we propose it after its built, not touching existing production services, and all the other bases covered
chikamakaleyley@reddit
and now, the shed you're forced to build is nothing like your original idea but its a great addition to your architect's backyard
ThatFeelingIsBliss88@reddit
Oh god I was hoping this wasn’t what it meant. We have someone like that on our team. He will absolutely block your PR and make it take ten times as long than otherwise.
budding_gardener_1@reddit
and every step is going to be scrutinized 0
1One2Twenty2Two@reddit
And you'll have to tear it all down in order to replace a window.
13ass13ass@reddit
(Say it’s a non coding architect. You are now building a non coders idea of a good architecture because they’ve looped in their boss who is like the chief legal council or something. And your project will now suck and take forever to get done.)
Gooeyy@reddit
I’m stuck on the concept of “non coding architect”
How could anyone possibly competently architect software without hands-on experience?
kobbled@reddit
they do have experience, but none coding architects spend their time writing and reviewing design docs instead of writing code
XenonBG@reddit
And thusly never getting an actual feedback on their design work.
13ass13ass@reddit
Yes they exist and can be quite dangerous: Source: Reddit https://share.google/HEhjgxFczdGnVS6I5
Jaded-Asparagus-2260@reddit
Why would you use a Google shortlink to a Reddit post?
13ass13ass@reddit
Thanks for your insightful contribution to the discussion.
bashar_al_assad@reddit
He must be an architect too.
TehLittleOne@reddit
I think any architect should have experience with the code base in their system, actually implementing features and showing extreme ownership over them. I don't just mean coding experience in general, I mean coding experience at your company delivering features your team owns and works with.
That being said, as you become more and more senior it becomes more difficult to find time to actually code and deliver things. Earlier on, sure, I could sit down and code 8 hours a day in peace. These days I get lineups behind my desk. If I walk over to someone's desk to chat for 5 minutes I emerge 30 minutes later after 5 other people asked me for help.
I have effectively become a non-coding team lead, partial EM, and dare I say it, architect. I don't write very much code anymore. It effectively came to be simply because too many people need too much of my support. It's fine, it works for us, and part of why it works is because I have a level of experience others do not. My experience in this code base is more than the rest of my team combined.
Gooeyy@reddit
That I can understand, just not coding anymore rather than never at all
Logical_Review3386@reddit
A non coding architect, you say? That is something that should not exist. I've worked with those guys, don't wish to again. Also, a coding architect isn't always better, but at least you will get more than a PowerPoint out of them.
rincewinds_dad_bod@reddit
You'll suddenly spend all summer driving piles into your yard to stabilize the soil so the cement pad never sinks, even though you were originally going to buy a plastic pre build one from home Depot and set it on some gravel.
Also your company doesn't have or make cement so you'll have to actually cancel the project after you do the actual architect work based on a shitty flow chart. The cement pad costs more than the shed itself would have originally.
chikamakaleyley@reddit
i'm certain you have - they're generally the older eng that grills you every time you suggest using some new tech or upgrading systems to a more recent version
initially you think they're just old and stuck in their ways but as you gain more experience you understand they're just being cautious
all this might lead you to believe they're a dick and a little too blunt for the workplace, but you'll brush it off once you realize they were born & raised in Philly
chikamakaleyley@reddit
and yes I've worked with this guy and this is exactly what i felt. Turns out he wasn't so bad after all; he was right all along; and eventually it made sense why he types on a Kinesis
s0ulbrother@reddit
I was trying to work on something to fix a Kafka stream that had to look at various resources to determine if we needed to log something. The only real way to do this was to have it check the db but he didn’t like that idea. I asked him his idea then got back to me a couple days later and said he had nothing. My idea worked fine
ThatFeelingIsBliss88@reddit
In your case, what happened?
PedanticPydantic@reddit
Lmfao, I feel this
Hixie@reddit
I forget the exact timeline but IIRC the gap between me speccing
history.pushStatewith three arguments and the browsers implementing it and then us realizing the second argument was a mistake was a matter of weeks. Hope y'all enjoy having to pass a bogus second argument every time you use it.MelAlton@reddit
For context:
The pushState() method takes three arguments:
state:
A JavaScript object that can contain arbitrary data associated with the new history entry. This data can be retrieved when the user navigates back to this entry (e.g., using the browser's back button) via the popstate event.
title:
A string representing the title of the history entry. While historically intended to update the browser's title bar, most modern browsers currently ignore this parameter, so an empty string is often used as a placeholder.
url:
jessepence@reddit
The state object is rarely used, so you'll usually see something like
window.pushState("","","/url")because you have to provide the two unused arguments every single time. I really hope the Navigation API lands in Safari and Firefox soon.Hixie@reddit
the second argument is just called "unused" in the spec now.
FinestObligations@reddit
From now on I will always enter ”hixie” as the value
jw12321@reddit
It takes a lot of skill to get to the point where you can make a mistake with such a significant impact, so bravo regardless for helping shape the modern web :)
99ducks@reddit
Reminds me of the HTTP "referer" header
Antagonyzt@reddit
Do tell
Maxion@reddit
(It's misspelled)
FightingSideOfMe1@reddit
**kwargs
Polite_Jello_377@reddit
Congrats on making mistakes at a scale most of us could only dream of
anonyuser415@reddit
Wow, took me a minute - this is the Hixie https://en.wikipedia.org/wiki/Ian_Hickson
poetworrier@reddit
How long does it take from pressing enter?
BandicootGood5246@reddit
Many years ago was tasked with maintaining a system that relied on a FoxPro database. I wasn't that familiar with it but had a lot of SQL experience. We had a small number of in-house users and they reported it was going very slowly all of a sudden. I thought I'd just give it a reboot and see what happens
Fun fact about FoxPro is it's a non-transaction database, so if it's mid "transaction" when it's shutdown it can leave the data in an inconsistent, effectively corrupted and unworkable state. So I had fun for a few days manually unpicking the data while the system was down
Lake_Erie_Monster@reddit
Free ACID is always nice
vazgriz@reddit
"Free ACID"?
Oh they got this all screwed up
"ACID free"
Lake_Erie_Monster@reddit
Brilliant marketing!
Kind-Armadillo-2340@reddit
Free acid, no problems on shutdown.
Free acid? No! Problems on shutdown.
AmpaMicakane@reddit
If I ever build a DB testing framework it will 100% be called "electric kool aid"
DjBonadoobie@reddit
What a merry prank that would be 😄
BorderKeeper@reddit
My eyes lit up when I heard Fox. That's the language my dad coded an accounting software in. It was running in MS-DOS I still remember the UX. He keeps talking about Fox as is his beloved to this day.
ScudsCorp@reddit
In the 2000’s a local record store was using dos Fox as their database. Great for its intended purpose
ScudsCorp@reddit
“Making a mansion out of a TuffShed.” that’s what these 80’s era single system DBs are like when they’re given queries from a network.
thermitethrowaway@reddit
I worked in banking and some bloke in finance realised he was good enough at DBs to automate most of the reconciliation of credit cards we had, so he wrote a system. Then someone else had the bright idea to sell our processing services to a bigger outfit).
Sadly he used Access/VBA and which hit its file size limit within 6 months, then they contacted us in IT to dig them out of it. Then we epically failed to manage the project properly and the ensuing death march burned through a third of the dotnet team
TheTimeDictator@reddit (OP)
Yeeech, that sounds absolutely awful!
BandicootGood5246@reddit
Many lessons were learned that day. You could argue that most valuable lessons were the importance of backups or randomly doing things with tech you don't understand, but most importantly never touch FoxPro with a 10 foot pole
AIR-2-Genie4Ukraine@reddit
graphql for web devs ca 2019 ish ?
every week they found a new way of ddos'ing our backend, it wasn't even response times just a lot of useless data like 80mbs jsons per view of data. The CTO got involved when like 20% of customers complaints were "your stupid up used all my monthly data cap"
ChristianSteiffen@reddit
I never understood why some people liked GraphQL so much. Like sure, you can request everything, but most likely you’re going to build a query that is slow as fuck because the system was never intended to serve this particular query in a reasonable amount of time in the first place.
AIR-2-Genie4Ukraine@reddit
because you can throw the problem over the wall to another team and be done with it. If there is a scaling problem then it's the person on call's problem and if you are not then it's all good
DeltaEdge03@reddit
Anytime I work with people who wanted something described as “simple, it’s JUST
Ok great. Sounds like we start off with non-technical assumptions and discover the business logic along the way 🫠
valdocs_user@reddit
I worked for a startup when I was in college in the early 2000s. We were making something like today's Outlook calendar. It was on ASP.NET (a web app).
The first calendar plugin we bought turned out not to support actual ASP.NET buttons, only web links like "www.google.com" but not "post back an action to the ASP.NET app". This was bizarre because the plug-in was in ASP.NET but didn't support any actual ASP.NET controls, it turned out!
With just days to go before the planned release, I had to rip out all the references to that plug in and replace them with a different calendar plugin the company bought to replace it. This went well - it allowed ASP.NET controls on calendar items - until someone noticed the next month had only 29 days. And it wasn't February and not a leap year.
The developer who made and sold THAT calendar app had evidently assumed that since 7x5=35 which is > 31 that no month could require more than five rows for weeks and hard-coded the calendar control to 5 rows. But in a month where the 1st starts on a weekend (as this very month right now does) you need 6 rows because the 30-31 ends after the following weekend.
So now with even less time I had to rip everything out and go back to the other calendar control (merging other developers' concurrent changes not just a reset) and figure out a way to hack in ASP.NET controls to something that only supports web links.
What I did was reverse engineer enough of the ASP.NET button postback system to make it so clicking the link (I think JavaScript was involved) generated a fake control click event for an id for an ASP.NET control that wasn't really there. Then I hacked the handling on the server to watch for this and call our C# code with the appropriate information.
Morely7385@reddit
Exactly, The fix is to stop binding core logic to the SDK and treat it as a thin shell. If you must stay in MS, push uploads/exports outside the Copilot SDK: generate SAS tokens and hit Azure Blob Storage directly; an Azure Function can stitch files and return links. For memory, keep a Redis hash per user plus a short rolling summary; persist durable facts in a read-only SQL/Cosmos table. For text-to-SQL, keep the LLM constrained: emit JSON with the table/columns and intent, map to known enums, compile the SQL in code, enforce read-only credentials, run EXPLAIN and a row cap, and kill long queries. Per-user auth is saner with the on-behalf-of flow in Entra ID; hide it behind a simple API so the front end never handles tokens. Vercel AI SDK and Azure OpenAI have been fine for the model/tooling, and I’ve used DreamFactory only to expose legacy SQL as read-only REST the agent can call, with Kong handling auth and rate limits. Bottom line: keep core outside the SDK and swap the shell if it keeps wasting time.
ivyta76@reddit
I once decided to implement a new feature without thorough testing, and the immediate user backlash made me realize the importance of proper validation before any release.
DeterminedQuokka@reddit
I definitely half way through a meeting explaining a decision we made the day before said “I actually just realized I’m wrong”.
bwmat@reddit
That hasn't happened to me yet, but it reminds me if a support call last week where I was telling the customer to "just use X" to fix an issue they were having, while perusing our api, only to find a minute later that it wasn't implemented yet in their scenario (an oversight by us, years ago), a bit embarrassing to have to admit it to them right after
Antagonyzt@reddit
Admitting you were wrong is honorable and shows intellectual honesty. You should never regret that!
Twirrim@reddit
Better than stubbornly sticking with it. I've seen people do that way too often.
PabloZissou@reddit
This has sadly become the norm compared to 15 years ago on which the most balanced technical decision was the one winning arguments.
Cute_Activity7527@reddit
TBH vast majority of “BIG” decisions I made in my career were all well researched and positive.
Rest were just “meh.. it works”.
Thats why I think you should really invest when making big decisions, because later down the road those can mean life or death for your company or product.
Example - picking wrong tech stack usually means you are later stuck with legacy garbage system that is maintained by ppl you cant really replace. Its often a huge strain on the company to move forward.
Ive seen this mistake made few time already and every time it was a hard stopper for company growth.
ImprovementMain7109@reddit
At my startup we decided to go full “grown-up fintech” on day 0 and picked Kafka + event sourcing + CQRS for what was basically a slightly fancy CRUD admin + ledger. Drew the architecture on a whiteboard, felt extremely smart, started scaffolding services. About 3 hours in, watching our test env spin up 7 containers to update a single user field, I had that sinking feeling you get when you realize you just bought a structured product you don’t understand.
The regret was instant because you could already see the future: onboarding juniors takes forever, every feature touches 5 repos, debugging is a distributed systems safari, and now your “simple” product work has a fixed tax. But it wasn’t easily reversible, because we’d baked the whole domain language and data model into that event stream design. So we half-lived with it for a year, then spent another 6 months quietly collapsing things back toward “one service + one boring database” for 80% of use cases.
In hindsight it was a classic finance mistake: over-optimizing for tail risks and hypothetical scale while ignoring carry cost. We priced the upside of “it’ll scale beautifully one day” and completely mispriced the constant cognitive load.
doesnt_use_reddit@reddit
You name a bunch of dope architectures but then give examples of problems with microservices. Keep the event sourcing but ditch the micro services!
ImprovementMain7109@reddit
Yeah, fair, the microservices bit was the loudest pain. But even in a monolith, full event sourcing + Kafka + CQRS for a pretty vanilla CRUD/ledger was still way more cognitive load than value early on. If I replayed it, I’d start with a boring monolith + append-only tables/outbox, then “promote” pieces to real event streams once there’s an actual need for replay/projections, not just vibes.
BeeSavings9947@reddit
Using a component library table as the basis for a high visibility complex custom table. By the end, the amount of difficulty it took to hack the component into working as the foundation was more than it would have been to just build it from scratch.
superdurszlak@reddit
Not the kind of a technical decision you'd expect here.
Given a choice between Windows laptop and Mac, I chose Windows because I spent my previous 3 months struggling with MacOS shortcuts, UX, and their wonky Magic Mouse and Magic Keyboard. First time Mac user and I was still in shock.
Yes. I chose Windows out of my own volition.
In 2 weeks or less I was already begging IT to wipe the Windows laptop's disk and configure Linux workstation for me instead - and it turned out it's been an option all along!
Nevertheless, it paid off long term - I didn't have to use Mac which I didn't know how to use (and to this day MacOS Window management gives me headaches) nor Windows which is unsuitable for any job whatsoever nowadays.
DormantFlamingoo@reddit
MacOs presenting a skill issue here is insane, what about it made it so hard for you to learn?
superdurszlak@reddit
Over the years, up until that point I've had various workstations - HP, Lenovo, never a Mac. Then, out of a sudden, a system with a brand new keyboard layout, new suite of shortcuts, an ecosystem of it's own, various UX peculiarities I simply haven't experienced earlier in Windows 7, 10, Ubuntu/Unity, etc.
I'm quite surprised you're surprised. In my bubble MacOS was rather uncommon. I don't quite get how I was expected to not have a skill issue.
DormantFlamingoo@reddit
It's just that for me, none of those things have been a major pain point. Learning new UX patterns and keyboard layout is weird, sure, but it takes like a week TOPS to get used to that stuff. And having a shell that isn't total garbage out of the box is a godsend.
I agree linux is better, but I'm genuinely lost on how you saw MacOS as scarier than Windows lol
superdurszlak@reddit
I genuinely don't know what should I say.
Yes I suck at Mac. To the point it took me months to get a hang of it. Now what. People suck at lots of things, and I suck at a ton of other things.
HK-65@reddit
Around 40 seconds.
Deleting a Google Cloud Platform project and then realizing the project ID can never be reused.
DormantFlamingoo@reddit
I once designed a system to manage resources we needed for a core service in our app. The service was stateful, so we made it stateless by putting these shared resources in a database and just fetching them with each call (basically justa simple resource pool).
We deployed it to a shared k8s cluster in our company. At the request of our architect, I designed it so it creates the upper limit of resources needed when it starts up. So adding horizontally scaling increases our resource management overhead. This was by design because our architect wanted to change a config map and see the resource count reflect that. And I had 3 architects rubber stamp this design, so I thought it was good.
It was great when it hit prod, it doubled the speed of another service we really cared about, and was a huge win for the team.
...Then 3 months later the k8s team did a cluster migration, and I realized every cluster migration would DOUBLE our resource overhead. Not end of the world, but annoying since CPU spikes in the DB set off the pager.
I fucked up. Lesson learned though, never put state in a k8s deployment. If I did it again, I would lazily create the resources as needed, and use the DB as a cache. The tradeoff is slightly slower times during restarts, but overall more stability and lower resource overhead. And our app load is steady, so we don't have to be resilient to spikes in traffic.
I always thought it was BS that you need to "stay in a position ling enough to see the effects of your decisions", but it's actually sooooo true. Just wish I'd made the right one :(
iam0xf@reddit
Some months ago, I had to build a project that required using some sort of pub-sub. The company burns, literally, tons of money into one of the big clouds for doing basic pub-sub.
Given that, the technical leadership made a meeting and asked the team if they had any prior experience with any other system such as Kafka. The team had experience in Kafka. So it was decided to go with Kafka.
One year passed, and then I had to go with a project that required the pub-sub. We agreed that we needed a smaller project to feel the pains before migrating. The tech lead goes for something like "You have all the freedom but if I were you, I would go XYZ (continue with the cloud tech)".
I ignored (accepted the freedom) and went down with Kafka and it turned out to be a headache. Not because Kafka is bad, but because: you have to understand it deep down (which I didn't) and didn't choose the right library for the programming language I was using.
mac1175@reddit
In 2002, took on an existing application that was done in VB when I already knew on VB.NET. found myself wasting time putting in hacks to make it work while everything could have been done easier in VB.NET. I realized there are times where starting from scratch on a project that hasn't come close to launch using a better language, framework, etc. is worth the effort then working with what you got.
RedditNotFreeSpeech@reddit
rm -rf *
05fj09@reddit
Introducing no/low-code to the founders…. Big fucking mistake
GLaDOSexe3@reddit
Ive never made a decision I didnt immediately regret. Techology was a mistake and we should retrrat to the forest.
awitod@reddit
When I realized the delete operation of the copy was not a copy but a symlink to the only set of actual files
poincares_cook@reddit
I feel your pain
PerryTheH@reddit
"The worst scenario it doesn't work and it's already not working so users won't be more afected"
This was an integration with a service that didn't had sandbox and a process was not working.
Little did we know the change not only didn't fix the issue but it was a build that got our server's memory full, so the server crashed and we had issues connecting to it as we basically had like 5s from startup until server crash to run the cleanup command, we had like 2hrs of downtime for that and had to do a very dumb thing to solve pur already dumb problem. It was a storm.
So yeah, the worst was not properly identified, now we joke about it but for like a week nobody(involved) wanted to talk about it.
positivelymonkey@reddit
Those decisions are always above my pay grade.
matthra@reddit
We had this spreadsheet stored in SharePoint, I asked if it changed often and they said never, so I go through this whole process of getting power automate setup and using it to set up an automatic ingestion process. It lasted like 45 mins before the schema blew up because someone had hidden a column. Turns out it changed all of the time, and now everyone was mad that my automation didn't work. They weren't alone though because I was mad at myself for believing them.
Maxion@reddit
When you ask non-technical users if something changes, or if you ask them if X is ever used, they invariably say no. But what they mean is that they don't change that as part of their regular daily work. It's just done occasionally.
Regular non-tech people have a very hard time understanding that computers are binary.
r0ck0@reddit
Yeah asking these types of "never" questions can be useful, but only when you get answer (b) below.
Worth a crack, for the (b) outcomes. Just don't fall into the trap of thinking (a) will save you time too.
r0ck0@reddit
Or sometimes they'll even openly say "it's rare, so don't worry about it".
Then other times, they're treating phrases like "that never happens" as like a colloquial synonym for "very rare".
For them, living in a more analog/subjective world... sometimes that's an acceptable compromise to make, depending on what's at stake, cost/benefit/risk etc.
But in tech, very rare edge cases can destroy a whole company, or worse.
Non-techies (especially managers trying to balance time/resources/cost vs risk) often don't understand that our "pedantic" definitions of things like "never" aren't just us trying to be a smartass or Sheldon... we actually need very objective binary answers sometimes, even if that's not how common language is used sometimes.
vasaris@reddit
I wish somebody told me that before talking with product about technical bug prioritization. The pain is so real.
Maxion@reddit
Always handle edge cases, always fix the bugs, always refactor. Always bake that in with/to visible feature work that the customer / PM / non-technical folks want.
r0ck0@reddit
As a wise scholar once said:
MelAlton@reddit
The real lessons from production
gemengelage@reddit
I'm not sure I'd call that "making a technical decision", but thinking out loud in a meeting bit me in the ass so many times, it's a miracle I still have any ass left.
Like I'm talking about a story with my team, I start brainstorming and say the first thing that comes to mind - or that other time, when I sent a junior dev a rough draft of a code snippet in the hopes that he will get the gist of it.
And then people just take my half-baked ideas and just run with them. I've seen that exact snippet of code I wrote in the post mortem. That guy wasn't a great developer, but apparently he was the best inadvertent tester I've ever met.
Brief-Doughnut-8678@reddit
Shipping something on Friday because "we just need to get this thing out the door"
Opheltes@reddit
A coworker was trying to browbeat me to agree to deadline to deploy a brand new, not tested feature to production. And by untested, I mean literally had never been run because we had not yet obtained the API key. And the deadline he wanted me to agree to was the following week. And the kicker? The day he wanted to do it was the day before Thanksgiving.
What was my response? I literally laughed. I told him there was no way on this planet or any other I would agree to a deadline under any one of those conditions, let alone all of them.
budgester@reddit
I would have agreed, I love the sound deadlines make as they go whizzing by. Then booked holiday to make it later.
morosis1982@reddit
Never ship on Friday. We have that as a rule, unless it's a critical hotfix for a big issue, and then the rule is limit scope - do only what is strictly necessary to let us not get called tomorrow, and well 'fix it' on Monday
amejin@reddit
Funny.. for 10+ years we only ship on Friday because the weekend is non business days and it gave us 2 days to respond to "oops" issues
Nyefan@reddit
We've shipped code on two Fridays this year.
I've worked two weekends this year.
exscalliber@reddit
Same rule applies for holidays (especially the ones coming up like christmas). Ive got a project that could easily go out in a weeks time and probably not have any problems, but it can wait until i get back from holiday since i don't want to tempt fate.
MelAlton@reddit
iirc some e-commerce sites lock the production code from before thanksgiving to after jan 1
morosis1982@reddit
Our org has a code freeze from early December until early January, you can do all the work you want in Dev, nothing goes to prod unless it's solving a critical issue
Xgamer4@reddit
My company's currently under a code freeze since the beginning of November through the first week of December. We're a marketing tech company, so stability through Black Friday and Cyber Monday is actually more important than the holidays.
-shrug-@reddit
Salesforce and Amazon both do, I’ve heard secondhand.
No_Army_6195@reddit
Yup, I saw an X post from someone at Shopify and they do this
supermopman@reddit
This guy ships code
Imatros@reddit
If it's external bean counting dates, then Monday is fine. It's internally driven for whatever reason, theb make sure the peron(s) pushing for it are signed up for call in support for the weekend/holida.
frezz@reddit
Nothing wrong with shipping on a Friday, but "we need to get this thing out the door" is never a good reason to ship something
AcanthisittaKooky987@reddit
I shot the guy who understood how everything worked, and made it look like a suicide so I could take his job. Ended up achieving FIRE 5 years ahead of schedule, but in hindsight I would have handled it differently.
kenybz@reddit
Murder is bad mmkay
hxtk3@reddit
I designed a PKI system around mutually authenticated TLS for user authentication, accepting the UI hit in exchange for being basically stateless in that the system only needed to maintain records of specific elevated permissions granted to a small number of privileged users and otherwise assume a valid PKI certificate meant a valid user with default permissions. I did this because we had no persistent highly available storage in the system other than the K8s API server itself and I wanted to avoid using K8s’s etcd as a database for our application’s data plane.
Then like a month later we got new requirements to integrate with another product that, incidentally, provided persistent databases which meant that we could’ve done something normal for user account management.
amejin@reddit
That one quick production db update without a where clause...
It was an emergency that became a bigger emergency...
tecedu@reddit
Early days of chatgpt, it was wonderous, my boss and me were brainstorming through things, asked chat. It gave a recommendation, we went with it and 6 months in encountered issues, they weren’t major per se and these were things we would have encountered if we used a poc in 1 hour. But it was a big pain and in the end needed me having to refactor a bunch of things and contribute to source upstream. So it wasn’t fun explaining that our own decisions to listen to unexpected source and make a major decision to the business stakeholders.
The decision was to use delta tables instead of postgres :) , always use postgres.
And we verify what comes out of llms now.
Other decision i regret is moving onprem for a heavy compute setup, the company has money for cloud, why am I setting myself up for pain.
bwainfweeze@reddit
XML-Sec is more hole than cheese. There’s a famous paper delineating the problems with it. It contains more than a dozen, and I’m pretty sure I found at least four more.
The spec I wrote up basically contained a long list of situations where you have to reject the file outright because it’s ambiguous.
Polite_Jello_377@reddit
Dropping tables on a prod database with failed backups has to be a common one
Candid_Koala_3602@reddit
Never makes decisions ;)
Vinen@reddit
In the same meeting.
Beginning_Basis9799@reddit
Ask me at 09:00.05