In my 15+ years as a professional software developer, I've made more than a few mistakes. Particularly in my early days, though not solely. Even a senior developer can wipe out a database or two every now and then.
And out of all of those, a few stories in particular stand out. Not because they were a complete disaster that brought the company to its knees. Not at all. But more so because these mistakes were easy to avoid and looking back it was mainly the cause of an eager and young developer looking to impress his peers. And also because they happen all the time and I know plenty of developers who have also made these errors.
During my early coding days at my first programming job, I was moved around from department to department in order to help in different projects and to see where I would best fit in. Some of this was front-end work, while other tasks involved working with databases and back-end scripts.
A big part of working with internal databases, was actually writing SQL reports for my managers and business team to review at the end of the day. Eventually, I would end up spending the majority of the day writing these reports as I became more proficient in both the schema but also in using SQL, as both go hand in hand.
And this is where the first few big mistakes started to appear. If you've never worked on a production level database before, then I will say that it is several levels beyond what a traditional hobby database looks like. For one, you might have over 100 tables to look through, each with dozens of columns, ID's, foreign key's ,etc.
And on top of that, you will also have stored procedures, database triggers, default calculated columns and dozens of automated processes running all day long updating the companies data. And millions of records to wade through. Sometimes billions.
Unless you were the one who built that database, then odds are you will have some gaps in knowledgte when working on it. And that was true for myself.
While the first few reports were created and shipped out without a hitch, eventually the complexity of the schema began to catch up. And that meant an increase in errors in my final report outputs, which is a big problem from a business standpoint as other people are making decisions based on this data.
Needless to say, it's a rough day when you have to email your managers that they should ignore the mornings report as it has discrepancies. And to fret not, as you'll have the right one ready in no time. You can easily lose the trust of your employers when this occurs, particularly if the data is time sensitive or of high value.
And if you think that getting the data wrong the first time is bad, just wait until the second time around where it also comes back corrupted.
Eventually, you will get familiar enough with a database schema that the chances of errors is drastically reduced, but never eliminated. Which is why these days I double and triple check all of my queries before I submit any data to my business team. And in fact, I spend just as much time verifying the data as I do generating it.
If your lack of SQL knowledge doesn't get you, schema complexity will. So run queries against your queries and verify. And once you have that validated, store your queries in a secure place for later use. Because I assure you, they will always come back.
But not all of my past errors involved strictly database issues.
When you work in the corporate sector, you typically aren't building entire websites from the ground up. More often than not, you are inheriting the code of many people from the past. And that code, can be a jumbled complex mess at times.
At a previous job, I was once tasked with working with a warehouse inventory management system, which I didn't write and which had no developer, as they had left the company years prior. But their code lived on and pretty much ran the entire warehouse's incoming and outgoing orders on a daily basis.
The learning curve here was massive, as I was new to warehouses in general and every acronym that I encountered was brand new to me. Inevitably though, as months progressed, I got familiar enough with the system to make slight adjustments and tweaks.
In fact, I got so familiar with the system that I decided to start to make a few refactoring tweaks. I just didn't like the way certain things were done and I felt like I could simplify the code and be a hero. And so changes were made and pushed to production.
Soon after though, error notifications started to appear in my inbox every so often. The messages were vague but they all pretty much pointed to the same place. The warehouse inventory scripts were acting up and it pretty much started soon after my code refactoring.
And I will say now, that the following long work days deep into the night looking for this cryptic error were not fun and could have easily been avoided.
Eventually I found the source of the problem. It was a SQL connection leak due to my shifting around functions trying to "improve" the system.
And I will say now that you should definitely refactor your code at some point in time in order to avoid repetition and in order to follow proper coding standards.
But when it comes to legacy code that was written by someone else, who isn't around anymore, you should tread carefully and be mindful of big changes. Because sometimes, moving a function, can bring down an entire warehouse inventory system.
I will end by saying that mistakes will continue to happen irregardless of skill level and seniority. And the biggest lessons that I have learned throughout the years, have mainly dealt with me taking my time and testing everything twice over. Because really, your mistakes are just errors that weren't fixed. And if you fix them before anyone notices, or before they affect a system, then they weren't really errors.
Measuring twice and cutting once definitely has a place in software development.