Developer Personal Projects
Unstructured Experimentation and Kaizen
A key part of the way I learned how to code was trial and error experimentation. In professional environments, it can often not be an option to experiment. Deadlines can tie the quality of a software product to time in a way which often does a disservice to the final result.
Unless you get paid to do self-directed projects without deadlines (if this is you, count your blessings), production work environments can often hinder rather than encourage developing new technical skills.
Many people in the industry follow, or at least talk about, /kaizen/, or continuous development. The idea, which came out of the Toyota car production process, is to always be identifying ways to improve and intentionally try to improve those things. You can apply this to your own professional skill development. The idea is to gain skills which could open up opportunities later. In addition, experience experimenting with code (as opposed to working on products for market) can provide invaluable context to the regular execution of your job. There are many schools of thought in the tech industry, and most of them are worth looking into.
Kaizen, as well as agile software development, comes about with the philosophy that there is always room for improvement. As a professional developer, personal projects are where I find the most satisfaction. It keeps development in general fresh and new when professional work may be more limited in what's possible to do and explore.
Keep a list of project ideas
Whether or not you're a developer, do you ever get ideas for an app? Do you ever find yourself frustrated when using software or websites when something doesn't work the way you think it should? These insights represent the raw material of technological innovation. Keep a list of these ideas when you have them. I like physically writing things down, such as in a journal. If you prefer some other way of keeping track of notes, anything can work for this.
Starting out with lots of ideas gives you the space to come up with lots of bad ideas as well as the good ones. As a writer, I find the process of getting out all the bad ideas is crucial to finding the few good ones. This is only one part, but the odds of creating a good product when you don't already have significant experience are small. Trial-and-error is an excellent, and may I add free, way to gain the experience which informs the creation of almost all of the software we can describe with the coveted status of "easy to use."
Unless you have a photographic memory, and the odds are you do not, you're going to want to write down ideas as they come. Good ideas will stick around but they'll be more likely to stick around if you write them down in a journal.
Minimum Viable Product
One of the most difficult part of solo developing is knowing how not to over-engineer. There's an amazing program in Madison that runs a free web coding boot-camp for low-income people. I did some tutoring for the program and talked with some of the students. In one part of the boot-camp, the students come up with app ideas and present them. What I noticed then, and have continued to notice ever since, was that many people's initial app ideas project too far out into the future of the software.
When designing software products, especially not as part of a team, early over-engineering is extremely common and can be deadly to a product prototype. Someone will present an idea, such as a social media website for musicians to share their music and recordings. That idea, by itself, is a gargantuan under-taking. Then, I think it's human nature to continue extrapolating on that original idea. Our musician social media site now includes a full-featured media player, live chat, and huge databases of music professionals. Any one of these could be an app in its own right.
It can be very helpful to think of web software features as self-contained from other features as you can. Following the ideas of domain-driven design (DDD), we can split up features into being as modular as possible. Take your app idea, split it into its component features. Then, identify the features without which the app would not function at all. Focus on the features without which the software would just not work whatsoever.
In order to complete the first phase of your product prototype, limit the tasks you're giving yourself to be only the most crucial for the absolute most basic functionality.
As you undertake the process of building out the crucial underlying infrastructure and features, your idea can shift into an entirely new direction. For applications the features of which have not be pre-determined (rare in the professional world), let the process of writing the software direct how the process goes.
Prototyping Technologies
We live in an age of frameworks. Those frameworks, to some degree, determine the nature of the software built on it. Don't fight your framework if you don't have to. Use the most common features and libraries. Work with the most robust libraries you can. It will dramatically cut down on the time it will take to reach a "finished" product. You'll spend less time debugging issues and more time making something that you can show to your friends or to potential employers.
Don't worry about perfecting the styles. If it only works in Chrome, hey, maybe that's ok for now. Don't sweat the small stuff. Don't project too far out. Make something that is complete in itself, even if it only does one or two simple tasks. I think we often under-estimate the value of simple applications. Sometimes, it's the small things which will best fill the most common needs people have. To start, try to do one thing, and try to do that one thing really well. The more you can limit your time speculating about future features, the faster you'll get a prototype. The faster you get a prototype, the faster you'll be informed about what's possible/easy and what is not.
Go the Distance
Try to identify your most promising ideas and focus on those to the exclusion of others. You will make the wrong choice, probably multiple times. Whether or not you do, make sure to take a healthy portion of personal project ideas to completion. I think it's important to live with software you yourself have created. Maintaining other people's code can be a nightmare. Try maintaining your own softare and you'll learn some common mistakes you can avoid. Also, read the book Clean Code.
Take at least some ideas all the way to making a minimum viable product (MVP). Even if 3/4s of the way through, you realize that your idea won't work the way you had hoped it would, just finish the damn thing. We need practice finishing software projects just like we need practice starting them. The secret to writing good software is practice and experimentation. So grit your teeth, set yourself in front of the old MacBook (sorry if you have to develop on Windows), and finish what you started. Even if it doesn't turn out to be the killer app idea for you to retire on, you'll learn something. When we finish projects, even small personal projects, it reminds us what we are capable of. That reminder can provide some really valuable motivation by which we can make our next idea, and finish that one too.
Sometimes, Kill Your Darlings
A lot of the advice that is given for writing or other creative pursuits can also apply to software development. The phrase "kill your darlings" absolutely falls into that category. Sometimes, you will have ideas that you love that don't actually turn out the way you imagined. What, in your mind, was a critical draw for people to want to use your app can turn out to be superfluous. Don't put superfluous features into a product. It will distract from the core draw. Nothing should distract from the main functionality of your application or website. Give the people what they want!
Share It
Join an online community of developers and find a way to discuss your projects with others. If you put a site out into the world, it can be a great way to connect with others. At the least, share it with friends or family. They may not care about your projects if they're not the intended audience, but hey, it's something to talk about. Brag about your accomplishments and show them off. People can't know about what you've done unless you tell them.
What projects do you have going on? What personal project have you already done that you're proud of? I'm interested, so tell me! Keep coding.