It’s our first big volleyball tournament of the season. Today, Saturday, and Sunday I’ll be downtown in Denver coaching a team of 13 year olds.
My break is your break (from me). Re-read Chopping Off Data today.
Category: Editorial
-
Learning From Breakage
I’ve had the fortunate, or maybe unfortunate, experience of being thrown into a few jobs with no training. At a couple of my bartending jobs, I had to start working without any training, calling over someone to help run the ordering machine while I made and served drinks. I managed to slowly learn how things worked throughout that first shift, so I was ready to work on my own the second night. I had a similar experience at a tech job, starting as the lead DBA/IT Manager in a crisis, having to try and solve problems after ask others how things were supposed to work. I ended up fixing a bit of code, adjusting networking, and directing others on my first day.
When we have a crisis, we often learn a lot from the situation. I’ve been through crashed upgrades, virus breakouts, hardware failures, and more in my career. While each was stressful and often not enjoyable, I learned a lot each time and came through the incident a more capable developer/DBA/whatever. When we work through a tough time, we are often better equipped for the next time something goes wrong.
I ran across a great piece that says you never really know a system unless you’ve broken one. This is Tim O’Brien, a software architect who has learned a lot about databases from failure. In fact, I love his interview question for data professionals: “tell me about the worst database schema you ever created. What did it teach you to avoid?” I’ve certainly learned a few things over time from my schema designs, but those are stories for another piece.
The piece draws parallels to today’s use of GenAI technology and vibe coders who seem to have success that they highlight in posts without discussing the problems. I do believe AI technology is going to make a lot of things easier (and faster) to build and then fix when they break. And they are going to break, partially because AI tech might not do a great job, and partially because we might not direct it well enough. Clear communication is key when working with AI.
I’ve started to build some skills with AI, but as I try to tackle more complex tasks or scale up my work, I realize that I often don’t know enough about either the problem or AI technology, and I’m going to make mistakes. I’m going to break things and then have to fix them, or more likely, learn how to get the AI to reduce the number of broken things in some way before I have to take over.
And learning to take over might be the number one skill with AI tech, but that’s something that you will only learn from the AI not working well for you in a variety of situations.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
-
Republish: Representative Data Challenges
It’s a holiday in the US, though I’m in the UK, having arrived this morning and heading to work. I’ve got a long day ahead, and a long week as I spend a few days here and then head home on Thursday.
In the meantime, you can get re-read Representative Data Challenges. I wish I’d talked more about this, especially the idea that so many bugs in software systems are data related, because we haven’t tested on representative data.
-
No Defaults Passwords Ever
I appreciate default passwords on systems. Often, for routers or other devices, I might need a way to connect initially. Or, if I perform a hardware reset, I want some password that I can use to reconfigure things. However, I am pretty good (not perfect, but really good) at changing those passwords to something else. It drives my wife slightly crazy at times, but I save the passwords and stick them in a manager I share with her periodically.
SQL Server doesn’t store a default password when you install it. If you enable the sa account, you need to create your own password. I primarily deal with containers, and I always set one, usually my own default. However, lots of software either allows a blank password or has a default password set on installation. Oracle even lists theirs in docs. That’s not the worst idea if sysadmins change them, but if they don’t, it’s a threat vector for attackers. I was working with a customer last year who had an Oracle database. I asked them to try a default user/pwd as a test and it worked. I think my head was slowly shaking for the rest of the call.
Recently, Silicon Valley saw the result of a default password not being changed when someone hacked the crosswalk signals and uploaded fake audio files that played when the signals changed. The vendor (not surprisingly) advised the city to change the passwords to something strong. A somewhat harmless prank, but it’s possible that someone might have made a more nefarious change.
It’s 2026. We know there are people out there with malicious intentions, as well as those whose prank goes sidesways and have unexpected side effects. There isn’t a good reason to keep default passwords anywhere, including in your own personal devices. These days, connectivity among many systems is a reality with network, Bluetooth, NFC, and who knows what other connections are possible. Your personal devices ought to have defaults changed for your own protection.
Inside organizations, it can be worse as the weakest link can be exploited to gain access to other systems. Quite a few hacks started in test systems and progressed to accessing production data. Even places we might not expect to be problematic, such as version control systems, have been used by hackers to gain access.
To me, finding a default password is worthy of a reprimand and a note in whoever’s file forgot to change it. A second offense ought to lead to a suspension at a minimum and possibly termination. This is such a low bar of required security that I can’t think of a good excuse to allow it anywhere.
Steve Jones
