We all know the movies, comics, or shows where there’s a little inventor hard at work at either ruining or saving the day: Dexter’s Lab, Jimmy Neutron, Phineas and Ferb. I always loved watching those shows either by myself or with my brother and sister. They always had a lot of fun characters and stuff happening and a lot of unexpected things and inventions along the way. I wanted to be like the inventing kids, because fixing someone else’s problem or doing something silly just seems like incredible fun. And as soon as I started to learn how to program, I found out that this gave me the power to make these inventions, but virtual. Basically you’re just as any other engineer, but instead of having to think about the limitation of real world physics, you’re just solving problems.
I must’ve been about 12~14 when I started programming, which I think is a lot later than when most “youth” programmers start. At first, any project is a learning project. This means that while you’re working, you’re learning something new, which was (atleast for me) incredibly rewarding. However, when it came to being close to just having to do the “grunt” work of the project, it became uninteresting. Whether it was just re-bulking parts that I already did like a lot of database operations or rewriting the same functionality in several places; It just wasn’t as rewarding as learning something new or starting something new, no matter how much energy it cost to abandon a project and start a new one.
This pattern repeated itself way up until my… well… very recently, embarrassingly enough. If these crazy limbo-esque crisis days have taught me anything, it’s to conserve energy especially if you’re forced to stay inside all day. So burning out over a lot of new and old projects is far from a good idea. Besides, at the start of the crisis I straight up couldn’t afford doing so as a freelancer, because most of my time had become incredibly valuable as a (potential) economic crisis was (and still might be) looming.
A lot of things actually. The things I’ve learned apply to a whole list of different kinds of projects. So like most things in life, it’s better to not summarise very complex issues or events with just a singular solution. So instead, here’s a list of lessons:
I’ve gone into a lot of projects with big ideas and expectations, whether it concerned revenue, the team itself or the place the project itself would go to technically. There are a lot of expectations I had with a lot of different projects that didn’t pan out. I thought that I was being conservative with my expectations by lowering my grandiose ones, but really I should’ve realistically evaluated what could’ve happened with a lot more factors than “what if it really takes off?”.
When working with other people, this can be become even more important, as people who are willing to work together in the beginning might behave differently than when they’re at their worst. A business partner that seems nice in the beginning and really understanding might as well be further away from you than an acquaintance when shit hits the fan.
Obviously, this does not mean you should jump ship when something goes wrong. But when you see that a lot of things that you initially planned don’t pan out, it usually means that your idea might not have been so great after all. Examples of this are soft launches that don’t get any attention or the app really not being finished on time and being far from being attainable. It also means that when you’re met with a clear roadblock that needs a lot more man hours and money to complete, that it’s a worthwhile time to reconsider. The thing that I learned is that you can actually feel if a collaboration or a project is gonna fail, fairly early on. Take this gut feeling with you, so that when the time comes, you can cut your losses and start a new project, with the knowledge you gained from getting out before burning out.
I didn’t do this for quite a few projects, and honestly it burned me out so much I needed to recover for several months. If you measure that against the cons of stopping a project early, it should be an easy call.
It’s kind of an extension of the previous point, but still worthwhile to consider. If you plan the “success” strategy of project meticulously, you might find that when things don’t go well, there doesn’t seem to be a clearcut plan. This is obviously because you were biased in your planning. This makes your project more likely to fail, so backup plans are always good to have. However, there’s also a completely different kind of plan: what are you gonna do when stuff doesn’t pan out? It doesn’t matter if the project is personal to you or if it’s just business. It doesn’t matter if it’s a smaller project or a huge one you do for a client. How are you gonna make sure that you’re gonna land on your feet again if something were to go wrong. Thinking about this will make sure that when the situation arises you’re ready to take it on without too many (mental) health, financial or social losses.
I run into this curse from time to time. Whenever I start planning a project, it becomes more boring and less fun for me to complete. What I’ve started doing is just keeping whole parts of the process somewhat non-committal and more free by not putting it in any of my digital notebooks or planning software, but rather focus on getting it to work on actual paper first. Just make small todo lists on post-it notes instead. If you have a gut feeling that the project might not pan out early on, it doesn’t cost that much energy to stop.
When you’re keeping the project up like this for a longer period of time without running into any issues: congrats! This doesn’t mean you have to commit fully by going into planning software or by writing more documentation on what you want the project to be; everything that’s on paper should suffice. However, the non-committal and paper focussed workflow could also make it easier for you to distance yourself from the project when you need to.
We all know the feeling and saying of “the last 10% of a project is actually the last 90%”. It might refer to different things or technical debt. However, if you’re working on artistic or very personal projects, it might be closer related to something that I heard being referred to as “project grief”.
Project grief is the feeling that whenever a project begins to take significant shape, the work you do on it becomes less satisfying because there are not as much things you can change, add or remove to radically shift the outcome of a project. Things will naturally be less rewarding, and thusly you’ll lose motivation and you’re more likely to not finish your project.
Learning to deal with this feeling can be challenging, and is a whole subject I think requires another blog post from me. But if you’re reading just this article and not another one, just take into consideration that managing a project is a skill in itself. So therefore, don’t forget that you might have to teach yourself that skill, or that you might not be a natural at it from the get go.
If there’s some guaranteed financial gain or legal obligations to a project, it’s a lot easier to make it worthwhile for yourself. I mean, it is extrinsic motivation after all, which might not be as powerful as its intrinsic brother. But when you’re struggling to continue on a project, any motivation will do. The problem becomes a lot bigger when those things aren’t (yet) a thing on your project. What can you do?
A great way is to write about it, either for yourself in the form of a diary or a like I’m doing on this blog. It doesn’t have to be consistent, it doesn’t have to become a chore in itself, but it can be enough to make you see your choices in a project in a different perspective. Rather than thinking “what would I like to do?”, you’re forced to think in terms of “how will I justify this decision?”, which can be a very good way to make sure you don’t make a wrong or hasty decision.
I, for one, am planning to write a lot more about my thought processes and development in the form of this blog or devlogs on forums like TIGSource. I’m already noticing that my (side)projects feel a lot more real when I get other people to give me feedback or help me out with the issues I’m running into.
Don’t take any of this for granted. The fact that you started a project is something that a lot of people dream about, but haven’t learned themselves what to do. Every part of doing this has a learning curve, some steeper than others, and some harder for you than for other people. The best thing we can do is to remember that with time, we get better at the things that we do and the best way of learning is fail and see what you need to avoid next time.
I’ve made a lot of bad decisions and honestly failed a whole lot in the last few years. Whether it was starting a company with a (ex) SO, taking out an entire year of my work to do activism, giving too much labour for too little money, starting a company in the midst of a global crisis & more!
All of these things limited my ability to do what I’m good at: make things. The sooner you realise it’s all part of the process, the sooner you’ll get better at it!