I recently published a website that was built with technologies I was unfamiliar with. I accomplished my goals for the side-project and I learned a lot about those new techs. Yay!
However…
I didn’t feel good about the quality of my work. I took lazy short-cuts and found “creative” workarounds which ran counter to the spirit of the technologies I was supposedly trying to learn. I knew this was a problem from the start, because I’ve been down this road many times before and I recognized that I had conflicting motivations.
I wanted to learn the new techs, but I also wanted to ship before the end of the holiday season. The deadline was self-imposed, sure, but I thought it was important because the vast majority of my attempted side-projects wither up and die long before making it to the mausoleum.
What’s a dev to do?
Ever heard of the project management triangle? The idea is that all projects take time, quality, and resources and you always end up skimping on one of the three.
In my case, the resources were essentially fixed so I had to choose between my self-imposed deadline and the quality of the website. I made a conscious decision to sacrifice on the quality because I thought that it would give me the best shot at a successful outcome…and the project was a success!
So why do I feel bad?
I believe that the way we code in our side-projects contributes to the habits that we bring into our professional programming. By taking short-cuts, I am encouraging bad-habits and building unfavorable “muscle memory”.
Given the project management triangle idea above, the “right” answer is hold quality above all and either sacrifice the time or resources required for the project.
Did I make the right decision?
Ultimately, I am happy with the way things turned out. If I had opted to focus on the quality then I would probably still be researching the techs, and the side-project would have been downgraded to an idea I had once.
I completed my goals, and now that I have some experience with the new technologies I an making an informed decision to invest more time into learning them properly. I skipped a few steps along the way so I’m heading back to square one. I am going to learn these technologies from the bottom up so that the next time I have an idea for a website, I can do a better job with less compromise.
So, what’s your philosophy on side projects? Did I make the right decision?
PS: The project is open-source if you're curious about the project or my crappy code. It's on Github.
Photo by Michał Parzuchowski on Unsplash
Top comments (7)
Thanks for this JZ. I have been a bit behind on my blogging recently, mainly due to time constraints, but I have resisted just cutting the quality to satisfy my arbitrary time constraint and to 'finish the thing'. This kind of reframes the struggle in a way that makes me feel less guilty, while also making me think, maybe it is too high a bar. :)
The advantage of side projets is that you can take the time and make errors because experiments lead inevitably to errors. Unfortunately some people do that on real strategic business projects that's why we have so many technical debts in real world so these guys should rather practice on side projects that's what sportmen do: they do not practive only on championship they do their training mostly elsewhere ;)
Definitely! I think forcing myself to complete the project was a good idea. The hard-earned experience you gain finishing up the last few things at the end of a project is much different than the fun/fast experience you get in the beginning.
the question about "quality" is "how do YOU define it ?"
Are you talking about :
I used to think about all these topics at once leading to constant refactoring and failing at self-imposed deadlines.
Now i think as the deadline (for side project) as the estimated point of "robust code".
How to know when a code is robust ? with units tests.
So now refactoring is only made to pass the tests, assuring that the code has the more important quality : the lesser bugs possible.
Then with free time and motivation i can, later, try to optimize and the tests make it sure that i don't blow everything up.
Actually i blow things up often, but i'm at least aware of it and can fix it :)
So for side project deadline is not really set.
why ? because theres a billions side project made to learn a technology, rarely they are useful for anything else.
I, personnally, choose to take more time, and build something that - i think - can be of use.
I got plenty of technology/languages tests, i don't call them "projects" though.
To me a project is an idea, something useful that you can make in that new tech or that other one you are already expert at.
Just another point of view ;)
I appreciate it!
My abstractions were weak, and I decided to tack things on rather than refactoring to accommodate. Also, 0% test coverage.
I definitely focused more on my vision for the project instead of the technologies but now I'm going back and rolling up my sleeves to learn more about Gatsby, React, and GraphQL.
I have mainly one side-project, and I started doing it to learn the tech at that time to get a job. And I think it's contributed to getting hired, cause they were looking it over a bit when interviewing me.
But I'm not sure what done is for that project, I use it mainly to do some coding, I'm the only user of it, and I still mention it on the portfolio, and also it is a playground to learn to code some things.
So, I don't know what my philosophy would be, maybe get it working and then do small improvements each time. I also keep track of things, I would like to add, things to refactor, things to explore or learn within that side project.
That's like what I can say based on my little experience with side projects.
Sounds like we agree on philosophy!
I feel like every side-project makes me stronger, I just want to be careful to balance my rushed experimentation with focus on best practices. :)