I like the format of “personal victories” when describing milestones of self-improvement in some area. I first stumbled upon it in the post about learning Chinese.

So I want to compile my own list of 15 small personal victories in a life of a software developer.

1. You can use (almost) any software by just looking on and playing with it.
2. You’ve changed a program of somebody else, and the change worked as intended.
3. You’ve conceived, planned, implemented and debugged your first useful utility. And it works! (well, sort of).
4. You’re trying to make some code to work, and have no idea why it isn’t working, and you change arbitrary lines of code, and at some point it starts working, and then! Then you suddently realize where the bug is.
5. You feel you can express any given algorithm with a programming languange you’ve learned.
6. Your software is used outside of your friends & family for the first time. They say it is generally OK.
7. You’re paid for your software for the first time.
8. When you count programming languages you’ve used, learned or at least know about, you need more fingers than you have.
9. You try to create your own genial archiver, and it can actually restore the information after compressing it. Unfortunately, your algorithm’s compressed file size is greater than the original file size.
10. It is physically painful for you to support a legacy hack-style code and you’re tired of it. You try to create an ideal software system with a clean and crisp architecture, and fail.
    Then, you put the GoF “Design Patterns” book on your table, and try again. Same result.
    Then, you try TDD, OOAD, UML, more process, less process, RUP, XP, and Scrum… You read Sposky, Uncle Bob, Buch, Beck, Jeffries, Cunningham, c2.com, newsgroups, forums and feeds, but still – nope.
    Then, you realize how existing mainstream programming languages are responsible for this misery and learn non-mainstream things like Haskell, Smalltalk, Clean, Eiffel, Decision Tables, etc. You manage to find a job in a non-mainstream area, just to see yourself still failing to create an ideal software, even with much more advanced languages and IDEs.

    (You may ask how come it is a victory, but trying to create an ideal software, and failing, seems to be a neccessary learning step).

11. When re-reading GoF yet another time, you suddenly realize that those architectures you’ve created in your latest app, just to workaround programming language deficiences, — those architectures exactly correspond to the patterns defined in the book. Then you close this book and never open it again.
12. You understand that design patterns are just particular examples of many possible distributions of functionality between classes. You learn to see consequences of each particular distribution. You understand that any architecture has both positive and negative consequences. You feel you can create a custom architecture having any given consequences (provided it is possible in the current programming language), without sticking to predefined patterns.
13. Armed with the new knowledge, you try to create an optimal system – and fail again. This time because of business constraints – your customer simply has neiter time nor money for an optimal system.
14. You can control quality of your software to meet given business constraints (budget, time and scope) – and still make the very best out of each buck paid and day spent. To do that, you learn how exactly bits, bytes, classes and data schemata translate into business value.
15. You start to value people more than software.