That was one reply to my article about testing:

So I thought, well... 🤔

Image credits:
https://blog.gardeviance.org/2008/04/three-stages-of-expertise.html

Actually, I've been thinking about this and my personal development for a couple of years.

First, I recognized that I was changing a lot of things, about how I code and how I look at technology and problems.

I started to code very early in 5th grade. By the time I was done with secondary school, I decided not to study computer science (and went for electrical engineering instead) because I thought there's nothing more I could learn about programming. I thought, I was just the best programmer in the world.

As you already may guess by now, I was totally wrong. 🤦🏻‍♂️

I had to learn what software engineering is about: Architecture, testing, performance, maintainability and much more that I have not really considered being an important part, in fact being the distinction between a programmer and a software developer.

So I read a lot of articles, books and tried to turn all the knobs to 11 which led to very complex software that was build to cover all possible cases that could ever happen.

There are a couple of similar articles like this. In fact, there are plenty of suggestions about possible phases, you can have 4, or five or even more (see References. All tackling slightly different aspects of being a programmer.

From my perspective, I distilled my personal evolution into three phases and its transitions:

Rapid Prototyping

• Writing code quickly and fast, the more code, the better!
• No or very few automated tests (See tweet above)
• No clean code
  • No sensible source code structure
  • Large files & methods
  • No proper naming ("There are plenty of letters in the alphabet!")
  • Hard-coding values and file names all over the place
• No underlying design principles or architecture
• No one else can read or understand the code
  • "I can write a RegEx to parse the XML"
  • "Look, that source file finally has over 1000 lines of code! Only professional programmers write that much code!"
• Being a programmer instead of a software engineer

Over-Engineering

After failing in a couple of projects, I read articles and books about what I could do and try to apply all of that which leads to

• Implementing features for the future without being requirement
  • Making everything configurable an pluggable
  • Designing for scalability and performance
• Complicated design & architecture ("I've applied all GoF patterns!")
  • High abstraction but low domain knowledge
  • Using the most complicated and esoteric language features
• 100% unit test code coverage
• Starting with clean code
• Learning about new technologies and trying to immediately use them
• DRY to the max
  • "Let's put that code into a library!"
• No one else can understand the code (but at least they can read it)

Pragmatism

After also failing with the previous approach, I tried to:

• Only build what's necessary (YAGNI)
• Find a good testing balance (testing pyramid)
• Clean code
• Domain specific code -- CarWheel instead of AbstractVehicleRotatingDataItemFactory -- Don't think about how to implement something but also why
• Accept that low redundancy (DRY) leads to high coupling and balance the two
• Optimizing for performance or scalability only when it's actually necessary (either by dedicated requirement or when the application runs measurably bad)
• Learning about new technologies but look behind the hype (Testability, documentation, contributions, security etc) and probably wait until it's battle-tested
• Recognize code smells

Conclusion

Those three phases are not scientifically proven. In fact, it's just what I've personally learned by thinking about myself on the one hand. There even might be other phases, I haven't experienced yet. On the other hand, it seems to fit to a lot of developers I've met during the last 15 years.

You can't necessary assign years of experience to those phases, some might as well skip a phase or it's been reduced to a short period depending on the personality, the way of learning or mentoring.

The most important thing is: You never never stop to learn. Make sure there is always someone smarter than you.

I learn new things every day and I am very grateful for my colleagues and friends.

Do you find any similarities in yourself?

References

• https://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/
• https://www.quora.com/What-are-the-growth-stages-of-a-programmer