Analyze Your Past Projects to Grow as a Programmer
If you have been working as a programmer for a few years, chances are you have a collection of projects under your belt. They may be personal projects you completed on the way to becoming a developer in the first place—part of the learning curve. As you know, the best way to become experienced is to create functional programs through code, starting small and working your way up to more complex problems
But what do you do with your projects after you complete them? Do you set them on a shelf in the back of your head while stuffing them in the hard drive of your old computer as a souvenir? Do you then wipe your hands and move on to the next one?
In my experience working at a Java development company, the way to move forward with consistently higher quality products is performing a thorough analysis of your previous work. By extracting every ounce of useful information from past projects, you learn from your mistakes and approach future projects from a different and more useful angle.
Revisit Uncompleted Older Projects
Earning the knowledge foundation to be a successful programmer takes a lot of work and experience. Often we are talking about years and years of projects. Some were completed, but some were likely left behind because you did not have the experience to complete them at the time.
What about those that required more knowledge than you had before? The great thing about advancing your experience and capabilities is that you can go back and complete the ideas you had before. Perhaps you can build upon what you had created, or you can scrap it and start over, taking it in a different direction.
You might surprise yourself and develop a worthwhile product as a result. Your previous, newbie thinking unhindered by an understanding of what could and could not be done and your new advanced programming knowledge could be a powerful combination.
Project File Organization
As I mentioned, if you have been working as a developer for a while, you have likely worked on a considerable number of projects. Of course, this includes all assignments, from the ones you did as a part of learning to code, to bigger passion projects and also others you were hired to perform.
So how much do you think you would be able to remember for each project after you stack up 10 or 15 more? My advice is to keep your project files organized and accessible. You may be asked to display some of them when looking for a new job. Or you may want to revisit a project you picked up years ago. Having a sound organization system set in place makes it so much easier to find what you need quickly.
Create a Summary of Finished Projects
Having a good organizational system also means including documentation describing the approach you took with the project along with the intended purpose and the steps you took to execute it. All this information can come in handy in addition to teaching you proper documentation habits that you will need in any professional career.
This should not be carried out only as a planning tool or on-going perspective of your work. It is also important to take a look at your work once finished so you can sum up the results. Include notes on how the product turned out differently from what you initially anticipated and why you chose to take it in that direction. What were the tools you used to make the project, and what does it look like in its finished form?
Include anything you consider essential to the project. Keep it concise but include info that is relevant, specific, and potentially helpful. The purpose of this document is to remind you quickly about the project if you decide to take a look at it years later.
Analyze Previous Work and Isolate Mistakes
Nitpicking your project apart is one of the best ways to extract every last drop of useful information from it. But to do it effectively, you need to really zero in on your mistakes.
Go back and think about how you could have executed it differently. Examine the pros and cons of the current solution and what the pros and cons of the other solution would be. Isolate the parts you think are not working well, and focus on precisely what makes you think it is not up to par.
By isolating what could have been done better, you are making sure that on your next project, you will avoid the same traps you fell in the first time around.
Share Your Takeaways
As much as taking notes on your project performance is great to help you to grow as a developer, you should also consider sharing your experience. Knowledge sharing is a great way to become a part of the software development community.
Considering that programmers tend to create solutions to problems that have rarely been tackled before when you’re struggling with something, you should look for what other people may have thought to do. And likewise, you should share your own experience. You could help someone else or stumble upon a different method that you hadn’t thought of or known about.
Even if you choose to keep the code private, by explaining the concept along with the solution you have come up with and how, in hindsight, thinking about how you can make the result better can be a lot of help should you revisit the project.
Of course, sharing your work applies to personal projects, as most developers’ contracts contain a confidentiality clause that is punishable when breached. Share details only on projects you worked on by yourself, and only as much as you are comfortable sharing.
Remain open-minded about the feedback you may receive. Some may be great. Some may be negative, which is usually the most helpful feedback—no one ever advanced their skill by being told how great they are doing.
Track and Understand Your Progress
Being an active programmer and creating many projects is great. The best way to become a good programmer is through a lot of coding experience.
You need to really zoom in on your mistakes. Understand why you took this approach, why you think it is not a good approach, how you can tweak it to extract even better results in the future, and what the benefits of new solutions would be.
What is a project you would handle differently? In what way? Add to the discussion and share your experience!