I’m curious about everyone’s learning journey. Was there a programming concept that seemed confusing at first but suddenly made perfect sense after some practice or the right explanation?
For me, it always feels like one small breakthrough makes learning much easier afterward.
I’d love to hear what concept it was, how you finally understood it, and whether any resource, project, or real-world example helped. Your experience might help someone else who’s currently struggling with the same topic.
When I first started coding, my code had a lot of “sameness.” If something worked, I duplicated the code.
I think it was the book “The Pragmatic Programmer” that introduced me to the DRY concept, which stands for “do not repeat yourself.”
I started looking for duplicated logic and pulling that code into a separate function anywhere I found myself doing the same sort of thing over and over again.
These days, it’s become second nature, but back then, it really helped me write cleaner, more manageable, code.
How important it is to double, even triple check your code, script or configurations, when you know it will get multiplied, used as the state or the source of truth aso.
One error in your source file can spread like wildfire, can cause hours of headache and get expensive in professional environments.
In my case it was ONE typo in a Prisma database scheme that was copied into the (infamous) index.d.ts . Resulting in crashes, forcing me to roll back the entire project. Luckily in a private project.
Also shows how important practical work is in IT and how much you can learn from your mistakes.
Mistakes like that definitely have an impact, but I’d bet just about every seasoned developer has at least one of those “oh crap” moments to share.
I’m reminded of the time I accidentally dropped a production database table. Yup! I was managing a lot of databases at the time and was probably rushing to get something done.
I had to ask the DBA to roll back the database…so embarrassing! Then I sent out a department-wide notice to let users know they would have to redo any changes they made. My manager at the time didn’t seem to think it would have a big impact since it affected changes that would have been made on a Monday; in fact, he seemed grateful that I owned up to it. The good news is I never heard another word about it, so I was lucky. And even though it didn’t affect my annual performance review, it sure taught me to slow down and be more careful!
Even though mistakes like that are a hard lesson for us, they happen. And those are the lessons we don’t soon forget! (BTW, I’m not advocating making them! :))
Maybe the reason why AI drops a database is because of the dataset it was trained on or the lack of guardrails.
Deleting a database is a rite of passage for administrators and developers.
This is why we have backups and recovery methods. We are human, and humans make mistakes.
Here a solution:
dropping a database actually renames it instead of deleting it.
any references to the dropped database come back as “database not found”.
System admins receive a report when a database is dropped
The deletion is checked and verified as necessary
Then two system admins enter a password and the renamed database is moved to a portable memory device after 30 days
If the drop was accidental the database name is restored
BTW there is no such thing as a rogue AI. A company that builds AI and says “It wasn’t us, it was the AI”:
doesn’t really understand how an AI works
employs engineers who do not sufficiently stress test the models
isn’t taking its legal responsibilities seriously by deflecting corporate negligence
shouldn’t continue building AI
In the aviation or medical devices industries, if something behaves outside safety parameters, production is immediately halted until the issue is resolved. Claiming “We don’t know why it did that” should result in revoking the deployment licence.
I think as developers we need to take a look at ethics more closely. The systems and tools we build today may last for a very long time.
.