I started learning programming around 1990, when computer access was still limited.
I didn't have a computer at home. At college, we had a limited number of machines and often had to wait for access.
As a result, I spent a lot of time writing programs on paper.
This wasn't an exercise in learning programming "the old-fashioned way." It was simply what we had to do.
The limited computer time changed how we approached programming.
Before entering the code, we would mentally execute the routine. We would trace variables through the program, follow conditions, calculate loop iterations and think about the expected output.
An obvious error could waste a significant part of our computer session.
The development environment was primitive compared with what we use today. There was no IDE autocomplete, Stack Overflow, online search for every obscure error or AI assistant capable of generating an implementation.
We had documentation, textbooks and our own understanding.
One useful consequence was that we became comfortable reasoning about code without executing it.
That skill still matters.
Modern tools have moved software development in the opposite direction. We can now execute, test, debug and regenerate code extremely quickly. AI has pushed this even further.
Give an AI coding assistant a description of a feature and it can produce a surprisingly large amount of implementation code.
But that creates an interesting distinction between code generation and software engineering.
Code generation is increasingly cheap.
Understanding requirements, identifying assumptions, choosing appropriate abstractions, recognizing architectural problems and deciding whether a generated solution is actually correct are still engineering problems.
This is particularly important when using AI.
If I ask an AI to generate a method and it gets the syntax wrong, that's easy to fix.
If I don't understand the business rule the method is supposed to implement, I may not even recognize that the generated code is wrong.
That's why I don't see AI as a reason for developers to stop learning how software works.
I see almost the opposite.
The less effort we spend typing code, the more of our effort should go into understanding the system.
When I was a student, limited computer access forced us to think before executing the program.
Today we have almost unlimited ability to generate and execute code.
The discipline now has to come from us.
Understand the problem first.
Then let the tools do the repetitive work.
Originally published on MatrixTrak
I write about software development, technology and the lessons I've picked up from more than two decades of building software. More articles are available at https://matrixtrak.com/blog.
Top comments (0)