Managing Personal Projects As Solo Developer - Getting out of depth and failing projects [closed]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/216571

Frage

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.

War es hilfreich?

Lösung

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:

  1. 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 days

  2. if 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 breaks

This 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.

Andere Tipps

Just from pure product perspective, I would ask what is the rationale of creating such projects? What is the end goal you try to reach?

If you are doing it for hobby, then I would argue that probably you don't have too good motivation and reason for doing those projects (getting bored etc.). And if there's no clear understanding why one does some things, it's very hard to expect this to be engaging for a long period of time.

If you are doing it for money, then I personally would seriously recommend taking a look into your business model and would argue that there are inefficiencies that have to be overcome. Every business or product needs a set of different people to be successful, there are good one man armies, but very seldom.

I feel that the problem here is more general and can not be solved with just adapting to new tools or development methodologies.

Somewhat on a tangent, but I find that having personal projects of the same type that I do at work (eg. Rails developer by day, personal Rails projects at night) can lead to much increased risk of burnout, fatigue, and just total unwillingness to work on it.

Focusing on the parts that are different (eg. the UI, or the server stuff) can help with the motivation I think, rather than doing 'just more of the same'.

For me the solution is not to start big projects. Instead I make a small project and evolve it.

It may not be publishable after first step, but on every step it has some known state, list of future improvements, may be some plans.

Motivation may affect how much time I spend, but the code and other things (plans, bugs, features) should be maintained in a state that allows to easily continue after at least a month delay (year delay will likely require some refreshing).

But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?

What's you motivation for these projects? Fun? Learning? Then maybe it makes sense, tho you could argue you'd learn working with others. Actually making a finished thing or business goals? Then it absolutely does not make sense. Find a way to get over it.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top