I really enjoy reading posts where authors talk through a mistake that they have made and what they learned from it. I find these posts to be reall...
For further actions, you may consider blocking this person and/or reporting abuse
I have made mistakes I hope to never make again.
I have:
Harder to sum up, but I've definitely made software design choices which caused problems later, and are still causing problems today. The notorious technical debt.
All of these experiences give me caution which I hope to pass on to others, but it's also important to know that some mistakes are not overly avoiding. As they say in CSS, if everything is
!important
, nothing is!important
. I think mistakes related to data and privacy are the top mistakes to avoid. Any mistake with a known remedy or short-lived impact are not dramatically worth avoiding.I had a colleague once who dropped a table of data from live. Luckily it was a relatively new system :)
So back in the day, I was working for a tech startup in Boston's metro-west area. I was one of the front-end devs, and we were building some great tech that was being fed a transcript via an API. But the boss wanted to get experimental.
"Wouldn't it be great if, as we progress through the transcript, we could pop up related material at a particular time? Say, the transcript mentions Steve Jobs, we pull up his Wikipedia profile and the top five news stories, or it mentions Microsoft, we display their stock ticker, business news, and related content on the fly?"
And yeah, that sounded neat. But let's be real - it was 2007.
So I tried, I found a great early BaaS from Yahoo! called Pipes. Way ahead of its time, but it allowed us to scrape, munge and combine feeds, based on what we passed to a call to a particular pipe. It was a meta-API, of sorts.
So yeah. The first few days of playing with the parts, things were looking very promising. The Pipe was working as I wanted, it could handle different types, it could return different data, and I could consume it however I like. Sweet!
And then at scale. From the live transcript. That's where I broke things.
See, in one way you can take a particular key term at a particular point in time, pass the request, get the data. With a very small change, you can take all the key terms, from all the points in time, and request them all. For each key term. Thousands per minute.
I inadvertently used Yahoo! for an ugly sort of DDoS on multiple search engines and sites. Boss and I had to go to a meeting with numerous tech heads, explain what our code did and why - they were more curious about the use case and the "how and why", and less about blame.
Honestly, I think we learn more from those moments someone breaks stuff.
This a great anecdote, Toby! Thank ya for sharing
Haha! Love it. π
I also love that everyone was more curious about how and why it happened versus trying to put blame on anyone. That sounds like a good, healthy environment to be in.
And I so agree with ya about folks learning lots from those moments when someone breaks stuff. Nothing like a painful mistake to help ya learn something! Said the man who has made many a painful mistake, haha. π
New branch for debugging, pulled from prod and not test. The picture speaks for itselfβ¦.
ahhh pain....
Yep, was an interesting meeting the next day. That was the moment I disabled βauto-commitβ on every datagrip installation from then on.
UPDATE users SET password='...';
Ah yeah... the plain text passwords.
How i miss them (somewhat).
It was so easy and convenient.
Now every password is hashed before so writing it directly to db is not an option anymore.
Alternate route: Hash Api Endpoint which takes plaintext as body and returns the hash.
Not as convinient but it works :D
so long
Actually, the passwords were hashed, and I was actually using the hashing function to get the new passwords string... did not help anything in this case. π€£
Is this a mistake or a good way to remind your users to change the password ? π€£
Well, we sold it as a security feature to our users... π€£
Wonderful
Lol not nearly my biggest mistake ever but a particularly frustrating (and now funny one) back when I was building my photography section for my personal site:
I don't remember the exact filename but I had a file named something like "3DCssRenderer.js". I was developing locally on Windows and deploying to an Ubuntu server (obv not best idea as we'll learn in a moment but I was being lazy)
The code was working 100% fine on my machine but when deployed to the remote server the 3DCssRenderer.js couldn't be found which wasn't an error I was anticipating
After like 6 hours of tedious debugging I eventually realized the file was named 3DCssRenderer.js (uppercase C) but somewhere I made a typo and something was looking for a "3DcssRenderer.js" (lowercase c).
Windows isn't case sensitive but Linux is hence why it worked locally and not remotely (and of course it was "C" vs. "c" which isn't obvious at quick glance). Sure enough fixed the typo and it worked perfectly after that π This experience has actually helped me a few times now helping colleagues solve similar bizarre bugs
Oh yeah Case sensitive or Line-Break difference between Windows - *unix Systems is something prob. everyone of us stumbled upon
Case sensitivity was one of those things I "knew" about but hadn't properly internalized until I encountered this error lol line breaks as well, I've def got a painful carriage return story or two floating around somewhere...
When I read the question, I immediately thought of starting CSS but on a shit*y foundation. It can't be the worst thing, but it sucks to start all over again when you've made good progress. πΆ
I do feel that some of the gowns on display at Paris Fashion Week 2023 were the result of some badly-coded CSS: instagram.com/reel/Cn2KL2MMJwE/
lol, these are ridiculous!
I second this @parenttobias! :) Not every design is meant to be "avant-garde". Sometimes, the most fashionable design is the simplest one. :) Lol, can you imagine a model like Naomi Campbell or Shalom Harlow wearing that dress in public? Lol! :)
ahaha yeah
Not communicating when things started to go off rails from the estimate on a big development.
I am not doing this for long, however my biggest mistake so far was to set up a cronjob wrong. Instead of sending an email to all inactive accounts on the 15th of a month it send an email every minute to all inactive accounts on the 15th of the month. Over 300 people received 600+ email from us.
Directly coding wise, I was adding to an
enum
list and thought it would be helpful to add it alphabetically so you'd see it when scanning the list. This gave theenum
s different values as they were assigned automatically as incrementing values. Very strange program behaviour followed.Related to coding but not exactly, I almost lost two weeks worth of work by not know what I was doing in Git
I had some dodgy "retry on network fail" logic in our client android app that accidentally retried twice for each failure (which of course escalated quickly). Tested fine, got pushed to production and then we started getting messages from the server team.
So I basically created a bot army out of our android users and got them to DDOS our own servers π
That was a decade ago, but to this day I try and avoid any automatic retries. If it's an option, I much prefer to let the user chose to retry manually
πππ the ending sounds like ptsd
And yep I have been there
One of my biggest mistakes was when I was the Lead Backend Dev at Eden Life Care(this startup never launched btw). If I remember correctly, I kept chaning dependencies for authentication/authorization for the project. It came to a point where I actually had to restart the project when I was still the only dev working on it(this was a few days after I started the project - which was a good thing).
Another mistake was not focusing on coding for music. I started playing the guitar when I was 13 and been in a band since I was 15 years old and have just started coding with music.
It was long time ago, when we were using FTP clients. I accidentally moved everything from root to one of the folders (without realising). This was on the website that counts its visitiors in millions. After the initial shock of everything not working, it took me almost 30 minutes to figure out what was going on. π
Blowing a capacitor on my monitor while testing a VGA display driver I was writing. Loud bang and a puff of smoke. Oddly, the monitor still worked! π
Back in the day when drag n drop SFTP was a real thingβ¦ overwriting a folder that crashed a live multi template site (of multiple vendors).. basically crashing 5 insurance sites in a flash π
Forgot a βοΈ and my π¬ is burning my desk!
Refusing to learn something new.
For the last 2 years, I was just using Flask to make websites even though I knew that Next.js would definitely be more faster and useful.
Delete from tablename ...was not my dev environnement π₯
Once I forgot how to breathe
Everybody drops the production database at some point in their career... but only once!
I've made a few howlers in my time but fortunately none that did lasting damage and couldn't be rectified quickly. The mistakes that really stick with me are less in code (where automated tests and manual QA are the norm) and more in architectural mistakes. They don't cause problems as obvious as the production database not being there any more but the cumulative pain of having to live with those decisions for years is far greater than having to hastily restore a backup!
I was once part of a team responsible for the maintenance of a tool suite. One day we received a change request from our client with a recommendation that the change be implemented in one of the tools in the suite we maintained. However we saw that it was better and easier to introduce the change to another tool, and we did convince the client of our viewpoint. We then proceeded with implementing the change in the tool of our choice, just to find out just one day before the delivery that the change couldn't be completed in the tool of our choice due to some false assumptions we made regarding the tool. Actually we also we found out that the changes would land more seamlessly with the original tool chosen by the client from the outset. We ended up to migrate everything overnight from the tool of our choice to that of the customer's and delivered on the following day the change made to the tool of the customer's choice, of course to their biggest surprise. π
Stopping to read blogs.
Okay, well not really.
One thing I recall from back when I was maybe 12 and just learning to code in GW-BASIC, it was common to put your surge protector under the desk, even in computers labs at schools. You'd be surprised how often you would lean back to streach and step on the power switch before you saved your work.
In college, the dumbest thing (or funniest depending on your perspective) I ever did was write a little runtime-C executable in during my C class to submit a CTRL/ALT/DEL and dropped it in the autoexec in the computer lab and see how people responded. I actually showed it to the prof and we laughted about it and he mentioned doing similar things to coworkers in the past. It would just reboot the machine until you hit CRTL-C. But it was funny to watch people wonder what was going on. I removed it after messing with a few people in class that day. Unfortuantly, someone else thought it was funny and copied it to another computer without me knowing and left it for the computer lab-techs to find, who thought it was a virus, and proceeded to lock the lab down for two days, formatted all of the drives and reinstalled all of the software, then the university drafted a new virus policy for the campus. Pretty harsh when all they had to do was CTRL-C. To this day, I have no idea why my prof didn't make the connection. Maybe he did and like me, just kept quiet. Or maybe he was the one that copied it to the other computers.
But in my professional career? Well, I have my top 100. But I can't pick just one. They are all too special to pick a #1.