When is a project done?
Just like with writing a paper, code can be edited endlessly to make small improvements here and there. But after a certain point, is it worth sinking more time into a project? Deadlines can be very helpful in this regard. Yes, you can always add more features, refactor things to be more efficient, update the UI to look more modern, add a new feature, add better logging and monitoring, add more unit tests, incorporate new things you learned and want to try out… but time really does matter for personal projects. If you’re working and/or in college, your time will be limited enough as it is. So having deadlines will really help. You don’t have to have a single deadline for finishing the project. That’s not good enough. You can say that this week, you will get required feature X done, and if you have time, you will do optional features Y and Z. Then you reassess where you’re at and set another sprint for the next week, again prioritizing required features and then only adding optional features if you have free time. Many incremental deadlines for portions of the program is better than just saying you’ll get the entire app finished in 3 months. Time management, whether on a weekly, daily, or even hourly basis, can help you make the best use of your time and will ensure that you have a final project ending.
Some projects need to be maintained over time, especially if they’re network-related, such as a web CMS that has a login system. There might be vulnerabilities within your code, or even with the dependencies that it relies on. In that case, you will have feature deadlines and maintenance schedules, which are separate. Or you might eventually retire the project altogether. But if you do that, it’s good to make a note of that in your GitHub repository so that people won’t be using potentially insecure code without knowing the risks. However, for offline software, it’s not as much of a problem, security-wise.
In many of my own projects, including this book, I’ve wanted to add a huge list of time-consuming things but eventually had to refocus on what’s most important and cut out unnecessary time-wasting things that would delay shipping the product. This is important not only for personal projects, but you’ll encounter this kind of situation in software development jobs too, where you think you need to do a lot of different things, but you only have time for the most important ones. In a job setting, it might actually be easier from a time management standpoint, because someone else will be in charge of scheduling, budgeting, and that kind of thing. But when you’re on your own, or if you’re a freelance developer, you’re your own boss and you decide your time frames.
It can be all too easy to delay and procrastinate on personal projects. You can take months longer than you thought, sometimes by adding more features, debugging complicated problems, or just prioritizing the other aspects of your life, like working overtime, social life, relationships, and so on. It’s all too easy to convince yourself that personal projects are less important, but when that happens, your progress will slow to a halt. Having realistic goals and excellent time management skills will help you get through projects more efficiently.
I know someone who says “I’ll do it later” a lot. They end up not doing many things they planned on doing. Procrastination will kill your personal projects. Not having personal projects will make your portfolio look really bad. Don’t procrastinate. It’s easy, and lots of people do it, but try your best to put at least a little bit of time into your personal projects – if you can’t work on them every single day, at least commit to once a week. Schedules really help.
Plan based on time rather than accomplishments. For example, say you’ll work on coding a certain function or class for 90 minutes instead of saying you will finish the entire programming for it (which doesn’t list how long it will take). Because what if something takes you much longer than you thought? Then you can end up in a situation where you spend too much time on one thing and not enough on others. Maybe you have other classes and assignments to do. Maybe you stayed up too late to finish something and ended up not getting much sleep. Time is crucial for any project, personal or otherwise.
An app is never really finished. You can always find a reason to add more to it or delay it because of extenuating circumstances. But you will want to get your project to be roughly finished in a reasonable amount of time. But your goal should not be to only have one personal project by the time you’re interviewing for jobs – you need multiple personal projects. It’s up to you to decide which ones you want to do, but you need to do at least a few projects, no matter what they are. If you don’t plan your time in advance, you won’t make effective use of it.
The only ongoing updates your software absolutely needs after its release are security updates (if it does anything over a network, such as a web app). This can include updating dependencies to their latest versions, or rewriting your code if it’s insecure. But you don’t need to keep on adding new bells and whistles to it.
Open source vs. selling proprietary apps
Many potboiler apps tend to be proprietary. They don’t push any real boundaries, and many are hard to distinguish from one another and easily forgettable. I would describe them as “generic brand” apps. They implement existing technology instead of doing anything innovative. The only intention is to make the developer money. By contrast, a lot of open source stuff is beneficial but sometimes hard to make money off of.
Open source encourages me to have good coding practices because other people can see what I’m writing. Not only that, but it allows for collaboration much more quickly, impresses employers and recruiters, and also provides people with a public ledger that shows how often you develop personal projects (or other open source stuff). It’s true that open source is generally harder to monetize than proprietary software, but there is still value in building up your portfolio. Getting your foot in the door to get a job as a software developer can be more important than making a few $1-10 app sales here and there. People aren’t going to trust some random developer nobody’s ever heard of before. They would rather install a popular proprietary app than an unknown one. Trust and reputation are a huge deal in software. By contrast, when you release your projects as open source, people don’t need to rely on trust – they can audit the source code themselves to verify that there isn’t any malware in it. This is especially important in our day and age where plenty of things get hacked, and cybercrime has shifted from silly pranks into serious fraud to help criminals make a lot of money.
I might switch over to a proprietary model in the future, but I am still very much a fan of open source, at least for the time being. I use a lot of open source projects, so it feels good to be able to write my own.
How to avoid becoming obsolete
There are definitely some dinosaurs in tech, some of whom are against higher-level languages like Python, or full stack web apps rather than native clients, and instead tell people we all need to learn C and pointers and manual memory management, because that’s what they did, so apparently everyone else needs to do it too. And yes, there is a continual erosion of privacy, like with Google Analytics and all that jazz, but it’s not going to kill you. What will be the death of your career is opting out of modern tech. That’s a more significant threat to you than some small amount of data collection. And sure, there are new security issues for web development, like CSRF or RFI, that weren’t a problem for previous generations of tech. Though C and C++ were arguably more dangerous languages because of how easy it was for the programmer to have some memory-related issue that could lead to buffer overflows and whatnot, but I digress.
The reality of the matter is that the world is changing, so best practices for programming in the past, and advice for which languages to learn, have become outdated. Perl, C, and other such languages haven’t adapted for the modern development landscape. Many people also cling to desktop-centric computing ideas, when we’re actually shifting more towards IoT and mobile. Web is also hugely important. Java’s mantra is “write once, run anywhere,” but that’s more true for the web than for Java applications. Older programmers, especially ones who espouse purist ideals of privacy and security, will talk about how mobile platforms, cloud, and other modern stuff is terrible. But if you choose to opt out of modern tech trends, you are resigning yourself to obscurity.
I take a more pragmatic approach to these issues of modernity, privacy, development preferences, and so on. If it’s widely used, I should consider learning or using it, whether I like it or not. Additionally, you need to stay up to date with development news and figure out if something is popular but in decline, or popular and becoming more prevalent. Think not just about the current status of something, but how it’ll be used in the near future. Will more people be using it, or fewer? Is it only being used for legacy development? What are some compelling reasons to learn this particular thing over other things?
I use many different platforms, many different IDEs, languages, frameworks, and other tools that enable me to write software. Hindsight is 20/20, but it’s hard for us to see who the winners and losers of our day will be. So instead of betting on a specific thing, it’s best to dabble in many different things, so that, when many eventually fail and become abandoned, you’re not going down with the ship, because you still have other options due to your diversified skill set.
If you look at the history of computing, you will see that a lot of giant tech companies no longer exist because they failed to keep up with modern tech trends. Your personal projects need to be modern too. Don’t use obscure programming languages nobody else uses, and don’t do things that were considered high-tech 10-15 years ago. Try to make your software modern – at least for your most advanced projects. If you get into web development, you ought to get into responsive design. You also need to know git.
One example of this issue is Ruby. It used to be hugely popular for web development, but it’s been in continual decline in recent years. That’s not a big deal for someone who knows Ruby in addition to many other languages, but for Ruby purists, this is horrendous. Who knows what modern tech will still be around in 5-10 years? The only way to ensure that your usefulness as a developer will continue on is if you had a broad range of skills. Sometimes, breadth can be more important than depth, at least before you’ve settled into a niche (career-wise). You can start out as a generalist to keep as many doors open as possible, and then get into more focused areas for career advancement opportunities once you’ve gotten your foot in the door. But I personally think web, mobile, and security are hot areas to get into.
My approach to learning might seem circuitous, but I believe in having a more well-rounded computer science education instead of having tunnel vision and missing out on other sub-topics.
Your projects should not be done in isolation. They need to reflect current industry trends and what kinds of skills are in demand. Look for job areas that are growing rather than flat or declining. Employer demand is way more important than your own personal preferences. Maybe you prefer quaint languages like Common Lisp, but you will find more jobs in Java, JavaScript, PHP, SQL, and Python. I might recant these particular suggestions in the future when newer languages emerge, but this is current as of early 2020.
No technology can stay at its zenith forever. There will come a pivotal moment – or a few – when the tech you specialize in becomes obsolete. You’ll go from feeling like a high-tech wizard to a stone age dinosaur. It’s hard to predict when a given technology will reach its apex, but it’s quite easy to notice when it’s in freefall, though many will experience denial during this stage. Flash is an example of a software behemoth whose market share plummeted due to mobile and malware issues. It didn’t dry up completely overnight, but when Adobe’s browser plugin started to decline, developers had to choose between sticking with what they’ve always done and taking the time and effort to learn something new that would secure more longevity for their career. An aversion to change can be dangerous in software development.
Congratulations on finishing section 15!
Now you have a good idea for where to start with your own project portfolio. Not only that, but you’re almost all the way through this site’s material.