Maintaining software, a path to software craftsmanship
The wet dream of every single junior / enthusiast / new developer start the same way, create new, bug free, successful and profitable software. Believe me I know, I was there.
While some people, and let me make this very clear by some I mean a very small fraction of the programmer community, are successful in their first time creation, truth is experience only comes from the making. So this last phrase probably sounds very confusing, I just said most people will probably fail in their first software creation at the same time that making software is the path to be good at it.
Yes, I did say that and it's only confusing because we try to transpose the concept of creation which we apply in making concrete stuff to the digital world. While concrete things keep the design ownership until totally remade, software is a living thing, it mutates at every single change, it does not mean you need to redesign the entire software to make it yours or be part of it. At every single change you are blending your ideas and changing the design (for good or bad). That's why open software and collaboration grows everyday.
Starting a new project the correct way is the most difficult endeavor a developer can jump in. You need a good idea, knowledge of best practices, very good knowledge of frameworks and marketing your project, if people don't know about your project they won't use it. And no matter how ready you think your software is, it will start to crumble as soon as people start using it.
So, how junior and mid level developers ascend to senior level of experience you may ask? Maintaining software! And not just maintaining your creations, or just one project, making a career of maintaining all kinds of software. At some point your brain will read code so fast it will start to appear like a second language. Learning new program languages won't be a problem, just a matter of time and patience. Good practices will become a second skin, you now understand why the fast and incomplete patch is a bad thing.
Why maintaining software is so useful for a developer career. Simply because most of these factors will happen soon or later, opening an opportunity for improvement:
- Software is mutable, it will always need maintenance. No matter how good your solution to the current problems is, new problems will arise and demand new solutions. Well, right here, new devs will find the opportunity to understand the current architecture and find the right spots to patch. The right spot is the point of less friction between the current and the new software architecture. Here the developer is training his comprehension of the current architecture and how to not destroy it, the company paid for it!
- In other occasions the software or part of it becomes obsolete / wrong, but it's too danger to start anew, all that business logic cannot go away! So forget the less friction theory, time to refactor, time to bring Design Patterns into play and build adapters, bridges, strategies, singletons, etc... It's my personal opinion this is a crucial point in someones career. You can precipitate yourself and destroy the software, producing the wrong artifact or you can give a experience leap learning how to bring legacy code to a new level inter-operating with brand new stuff. Make no mistake, it's a lot of work to do that, most devs will prefer to start anew...
- There's always room for refactoring, testing and improvement. Worst case scenario, you will learn business logic that is more important than pure programming. Understanding other's way of thinking may be as hard as playing chess. Be humble, be sure to really understand how a functionality works before changing it. Intelligent people will recur to testing here, seize the opportunity.
- For the last, the most neglected aspect, people that build software and go away never learn what went wrong. But hey, that may be your job! The great chance of seeing something built and learning how to build it at the same time understand why and where it failed, unfortunately most inexperienced developers throw away this opportunity doing a quick and incomplete fix, and most of the time due to bad management that do not understand that fast fix is more expensive than a correct one.
So after some time maintaining software, when beginning a new project you'll be provided with enough experience to avoid a lot of mistakes, mistakes that you learned from others mistakes, and that's wisdom.
Of course not everybody is in the position of having a complex project to maintain, fear not, github is full of open source projects needing help. Be humble and start from the bottom, the path to success is not marketing your name into the project, but acquiring experience.
The best experience a programmer can have is to be criticized for the first time in a pull request! Forget your ego, the software quality comes first.
Good luck, always follow the good practices and keep refactoring.
Note: I need gramar revisions, feel free to apply to the job. I wont pay ya, but it will encourage me to write more.
You just put my whole professional philosophy in an article.