I stumbled across this Quora question via a Forbes article and then fell into a Reddit rabbit hole. There are musings on how to handle bugs and how to write readable or unreadable code. Someone wrote a note about bad programmers writing a lot of clever code, good programmers writing as little as possible, and the best programmers deleting code. And there was one interesting note stating that programming skill isn’t even important in the life of a programmer.
I haven’t been workin in tech for 20 years, I think I’m close to 15 at this point, I’d wrap it all up as the value of experience. Don’t worry, I have an example.
A meeting request came through this morning. In the agenda was a couple of links to JIRA, we were supposed to review these changes. It was just 2 links. I took a look at the changes and was getting confused, before I finished, I got an IM from a programmer that is very experienced and had been with the company for a while. The request was for us to add versioning to a form. But, we didn’t know what problem was trying to be solved or even who would be using this change.
The programmers that ended up working on that request could have gone in a hundred different directions based on those descriptions, and none of them right. The more I thought about the request, the more it seemed like an epic. Translation, too damn big to have any idea where to start or where this will end up without a serious conversation.
The programmer I was talking with agreed and sent an email. The gist of the email was that there wasn’t enough information in the JIRA cards to get them in a sprint. At a minimum, we need to understand the problem we are trying to solve and who would be using this software. The email didn’t make anyone particularly happy. It meant something that was in the plan was going into a spring a little later than expected. But it was the right thing to do. Accepting those requests as they were would most likely result in confusion and rework.
All of this happened before a line of code was written, we didn’t even need to open up an IDE to see what our current functionality was (this is sometimes useful). That is the type of problem solving that only comes from experience, from having years of experience on different projects as well as the one you are currently on. Being able to string together series of old failures into coherent thoughts about what might go wrong now is what older technologists are good at.
I fairly commonly see comments that older programmers are stuck in their ways, or unable to deal with new higher level languages, and grumpy about everything being in “the cloud”. This hasn’t been my experience, rather, I haven’t met those supposed curmudgeons. I have met lots of people that have experienced failures and problems and don’t care to experience them in the same way again.