Some little details cause trouble entirely disproportionate to their importance. One such thing is a little quirk in how Oracle handles indexes.
I have some code which gets a list of tables using a particular criteria and then gets all of the indexes associated with those tables. Under normal circumstances, the code works fine. However, when testing in a clean database, it will completely fail to find any of the associated indexes, even though they’ve been verified to exist.
…or have they? It turns out that when the corresponding table does not contain any data, the index may still be associated with the table but it doesn’t really exist. So when you run a query like this:
select * from dba_indexes ind
join dba_segments s
It returns no results. Cue confusion. Adding a row to the table causes the index to actually be created and allows my script to start working correctly.
When I first started working as a developer over seven years ago, it was a bit overwhelming. Not only had I never worked as a programmer or used any of the languages I’d now need, I also had to get used to a lot of internal tools and processes that often had minimal documentation. It was, in a word, exhausting.
Matt was another developer on the team who had already been with the company for half a year, and he was really good at his job. He wasn’t officially my mentor, but he encouraged me to ask questions. I had him as my code reviewer for my first major piece of development, and let’s just say he had a LOT of comments – everything from functional improvements to changes in variable names. It was frustrating, to say the least – but also educational. Having Matt review my code was a great way to learn what good code should look like, and as time went on I would actively seek to have him as my code reviewer whenever I was working on something particularly complicated; having Matt look at my code gave me more confidence that everything was correct.
Matt recently passed away from cancer; one of my regrets is that I never got to know him socially. We had several shared interests, but I just haven’t made a practice of socializing with my coworkers outside of work. However, his passing leaves me as the senior developer on my team; out of thirteen people I’ve been on the team longest (although one person has been at the company longer) and I’ve been on the team at least 2 1/2 years longer than anyone else who is focused entirely on development (rather than being a team lead). This puts me in the position of often being the person that other developers come to with questions.
I’ve never forgotten how Matt encouraged me to ask questions and assured me that the feeling of being overwhelmed was normal (if I recall correctly, he said it took him about a year to really get settled in). I’m trying to do the same for the newer developers (although, since I’m hard of hearing, I encourage people to email me as it’s more of a challenge when they drop by my office).
No matter how good of a developer you are, there’s a limit to how much code you can produce (although Matt produced quite a lot). By helping your team to work better, though, you can have an effect on far more code than you can personally touch. I like to think that my efforts lead to improved code quality even on parts of the codebase that I never touch myself.
Thanks, Matt. Wish you were (still) here.