It’s the last day of vacation. My wife and I stayed in Seattle an extra night so we could unwind and then catch up with a friend this morning before we head back home.
While I am having a wonderful Filipino breakfast at Ludi’s, you get to re-read Fixing Imposter Syndrome.
If you get to Seattle and find the Biscuit Bitch too busy, walk down a block to Ludi’s and try their offerings. It’s wonderful. Garlicy, but I love the Long-silog.
I’m still on vacation. Today I think is Sitka on our Alaskan cruise, but in any case, no internet for me. Didn’t buy a package, not trying to check things in port.
You get to re-read Bean Counting to Burnout while I hike in the woods around town.
I’m still in Europe, now in Rome. I’m sure it’s amazing, but while I’m gone, you get Writing Before Reading. I don’t see this in the archive, so here it is in total:
This editorial was originally published on May 21, 2020. It is being republished as Steve is gone this week. Have your thoughts changed on reading and writing code?
Coding is one of the few (or maybe only) places where we learn to write a language before we learn to read it. Many of us get started in some way by working through exercises, looking at very small snippets of code and then starting to write our own. Perhaps that’s because we experiment by changing the behavior of the computer, which naturally takes some writing work on our part.
Perhaps we can do better, and should to better. Perhaps we would become less susceptible to the Not Invented Here (NIH) stance that so many developers seem to take. Not with major projects, but often with small sections of code or libraries, preferring to structure something new than re-used (and take the time to understand) what’s already there.
This isn’t to imply that most developers need to write their own code or don’t work to understand others, but often they prefer to rebuild something in a way that is more familiar. It’s a form of the Mere-exposure effect, and it sometimes leads developers to prefer certain patterns, tools, platforms, and more. Perhaps it’s the opposite of the shiny ball syndrome, which leads people to chase the newest thing available in their area.
I know there are plenty of developers that copy and paste code from the Internet as well, which might seem to be a way of getting around NIH syndrome, but I think many people do this when they find code that solves a problem. Even if they don’t understand how it works, they’ll seek to reapply that same code to a new problem.
I do think reading code is hard. In some sense, it sucks. I’d often prefer to understand the basic inputs and outputs, perhaps rewriting the code to work in a way that’s more comfortable for me to understand. Maybe I better understand my own code, maybe I’m falling victim to the IKEA effect (I’d rather depend on my own software than someone else’s), or maybe I’m just being lazy.
There are plenty of articles on how to read other people’s code, and I am trying to get better at this. I do try to debug and reason out how queries are written that solve problems in the forums. I may break apart queries and try to understand how someone has used a window function or a CROSS APPLY in a certain way. It helps build my skills, but it also helps me learn to better read other people’s code and perhaps carry that skill into the future.
Steve Jones
I was very lucky, and honored, this year to be picked as a part of the Redgate President’s Club. This is our sales award club, which primarily goes to reps, but sales engineers and others are picked. I was one of the wild cards, as I helped on a lot of deals last year, so today I’m in Cambridge meeting with product people and execs.
While I’m over there, you get to re-read Other IDEs. Leave a comment and let me know if things have changed since I first wrote that. Are you using another IDE?
Voice of the DBA 