4 ms·

This was called “desk checking.” You had to learn to read code and actually understand what it was doing. You may only get a few chances a day to run your code.

This was called “desk checking.” You had to learn to read code and actually understand what it was doing. You may only get a few chances a day to run your code. I remember the feeling submitting my job (a deck of punch cards) and then getting my cards and a small printout back in a few minutes because of an ABEND (abnormal end, or crash). I still do that, along with targeted experimenting on small bits of code I need to understand better. The skill of reading code and “running” it in the head seems forgotten now, though I think talented programmers usually get there.

alisonatwork 6y ago
One of my biggest disappointments in pair programming over the past few years is realizing how many developers are unable to explain what the code they just wrote actually does. Like, they can't do a verbal debug, stepping through each line and describing the expected state. Everyone copies from the best, but it seems a lot of developers just copy, paste and then let the IDE autofix any warnings. The code block becomes a magical incantation rather than a sequence of operations. It never occurred to me that the reason I look at code differently is simply because I am from am older generation. I only started coding professionally in the 90s, but even then compiling wasn't especially fast so it was expected to review code before kicking off a build. And as a kid in the 80s I spent more time reading code in books and magazines than actually at a computer typing it in, so I had to think about and imagine what it would do. There is definitely a lot to be said for the modern world of linters, unit tests etc running continuously - I wouldn't want to give up any of that up! But I do wonder if the developers who aren't able to explain what their code actually does are missing some fundamental skill. Clearly it doesn't matter to the customer because these developers still produce working products, but it feels to me like some level of quality has been lost.
- gregjor 6y ago
  My experience as well. Combined with the irresistible attraction to new and increasingly complex frameworks, tools, and infrastructure, this leads to a lot of failed projects. As an aging “not a good culture fit” programmer I found a niche taking on, finishing, and supporting the code left behind by developers who got in over their head and didn’t really understand what their code does.

alisonatwork 6y ago

One of my biggest disappointments in pair programming over the past few years is realizing how many developers are unable to explain what the code they just wrote actually does. Like, they can't do a verbal debug, stepping through each line and describing the expected state. Everyone copies from the best, but it seems a lot of developers just copy, paste and then let the IDE autofix any warnings. The code block becomes a magical incantation rather than a sequence of operations. It never occurred to me that the reason I look at code differently is simply because I am from am older generation. I only started coding professionally in the 90s, but even then compiling wasn't especially fast so it was expected to review code before kicking off a build. And as a kid in the 80s I spent more time reading code in books and magazines than actually at a computer typing it in, so I had to think about and imagine what it would do. There is definitely a lot to be said for the modern world of linters, unit tests etc running continuously - I wouldn't want to give up any of that up! But I do wonder if the developers who aren't able to explain what their code actually does are missing some fundamental skill. Clearly it doesn't matter to the customer because these developers still produce working products, but it feels to me like some level of quality has been lost.

gregjor 6y ago
My experience as well. Combined with the irresistible attraction to new and increasingly complex frameworks, tools, and infrastructure, this leads to a lot of failed projects. As an aging “not a good culture fit” programmer I found a niche taking on, finishing, and supporting the code left behind by developers who got in over their head and didn’t really understand what their code does.