Phases of an incompetent programmer
Going through different stages while we gain experience is something of the most common. But when it comes to programmers the progression is usually something more peculiar.
An interesting and fun approach is the one proposed by Mark O’Connor, programmer and researcher of Artificial Intelligence, in a somewhat old publication of his Yield Thought blog in which he shares the phases through which the incompetent programmer passes.
The rookie enthusiast
The rookie enthusiast is full of passion and emotion for the only language he controls, which can already be VB, PHP or actionscript.
When he understands the syntax of that language, he feels that he completely dominates it in all its forms although the end result leaves enough to be desired.
The newbie writes surprisingly fast, but it all ends in a single huge file full of global variables.
Having programmed for a few years and learned a second language, he is firmly convinced that he is the Messiah of the programming world.
He reinforces this worldview with his conviction that everything he does not understand (that is, almost everything) is useless, outdated and a waste of time.
The monster of abstraction
After a while, all new programmers will realize that they start each new flash game by copying 90% of the previous one. Suddenly, it occurs to them that they could write a “super” game engine to write a new game as simple as finding sprites and writing a configuration file that contains the rules.
Reddened by this success, the aspiring fan of abstraction begins to believe that all programs should be generalized.
Any programmer exposed to the bitter reality of working in a heartless commercial software company, mixing bits on a hard drive for the same salary each month, eventually develops a certain protective layer.
Neither speed nor ingenuity are rewarded, so a professional developer often begins to develop a very careful and measured style that guarantees that he will never be caught by errors or administration, which he considers to be practically the same.
After about a decade of jumping from one stereotype to the next, the rookie has already grown, but it feels like a hollow shell of the enthusiast he once was.
One morning, he wakes up and realizes that the thick layer of unit tests, assertions, error checking and class design that has developed around his programming style are just crutches, crutches that drag him down and that He no longer needs. He takes them off and begins to write the simplest and simplest code he can think of to do what he needs.