I need some advice on project management.I start a project, and often times it will a large project for a solo developer. Usually its a web project. I handle everything from the UI, to the JS, PHP, server management etc. Half way in I feel out of my depth. I lose where I am, so I spend a couple of days away from the project to avoid the stress and before you know it, it becomes another unfinished project.I try to use frameworks and code libraries to make my developments easier on myself. Sometimes I will complete a project so it works and then go back and handle errors, design the UI properly and stuff. But without fail I will always end up out of my depth.I've though about outsourcing tasks such as the UI, and the behaviour, and focusing just on the PHP - which I feel is my strong point. But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?I am sure there are many others who have felt like this either at home, or at work, and I would love some advice on managing my projects better.
Managing Personal Projects As Solo Developer - Getting out of depth and failing projects
project management;programming practices;solo development
Had the exact same problem:If I'd put my project away for a few days, I'd come back to it and have a real hard time picking it back up. I'd had to re-familiarize myself with it, try to re-understand where my thought train was going and sometimes wonder why did I ever decide to code it the way I did so far. More often than not this would simply make me abandon the project or restart it from scratch. All this became a real problem once I realized that the situation forced me to:only start small, simple projects. Starting a big project would just bring me past the confusion threshold where I could no longer resume it after leaving it alone for a few daysif I really wanted to do something more involved and complex I'd have to do it all in one sitting, namely work on it every day until it was done with no breaksThis was just stressful. I decided that before I'd go on making solo personal projects, I'd have to try to address this issue. I started complex projects on purpose, just to see exactly why I was having a hard time resuming them after a few days' break. I'd start implementing an algorithm I wasn't familiar with until then (like A* or Mini-max, etc), stop coding in the middle of it all, and try to finish it a few days later.Here's some of my conclusions on this:monolithic anything is bad. Make small concise functions/methods, classes, packages, modules. Don't ever, not once, cut corners on this, thinking oh come on, I'll just add the draw.sprite code to the updateGameState() function this time only, how bad can it be or that I'll just add this calculateArea function right in the SelectButtonWidget class, just this once, it'll be so much faster than making a separate class and instance for it. This makes code hard to follow, and thus hard to resume after a few days break, when you no longer remember all the mental aliases you've just done like all drawing code is in the drawables package except the one for drawing a sprite which is in the updateState() function of the X class of the Y package.unit tests make the code a whole lot more readable than comments Did you, out of desperation, add pages and pages of comments to your code in the hope that it will be more readable next week when you resume your project after returning from your vacation? I know I did. Never helped. Not only did it not make the code more readable (some times it made it less, as it didn't help me re-understand what my code was doing while at the same time clutter my code), but it was taking A LOT of time to add comments everywhere. Also this lead to such conundrums as do I comment at the class level, method/function level, for each line of code, only for the important ones, etc etc. Investing all that comment writing time into unit tests was a lot better. Unit tests check for something, and you can readily tell what they're checking for and hence what the code is supposed to do. Also, the where to place them comments conundrum was gone. Unit test everything. Start with whatever you think is most important but make a goal of unit testing anything. unit tests just rock Not only is your code more readable and easier to (re)understand, you'll not even need to to (re)understand it all when you come back to it, but only those areas you want to work on presently. Just peek at the unit tests of the parts of the code you wanna modify right now to see what they're exactly supposed to do. Then modify them, add more unit tests if necessary, and just re-run the whole unit test battery to make sure you haven't broken anything. If they all pass, you instantly know all is good with your code, without having to go through all of it by hand.never optimize until the very end In the grand scheme of it all, this point is debatable. Will my code run faster if I delay optimizations as much as possible, or of I do them incrementally while I implement things? I honestly don't know. But strictly from the point of view of code readability and how easy it is to resume a project after putting it aside for a while, I'm pretty sure that the practice of delaying optimization until the very end is the best way to go. What I mean is: as long as your implementation is not close to being done, focus on having nice, readable, modularized code. Once the functionality is all in, debugged, unit and functional tested, you can get to the task of optimizing the code. You'll have a nice version of your code which you are confident that it works ok, and is clear and easy to read, and to which you can always return if the refactoring for the purpose of optimization gives you trouble.