No constraints, no fun
When I’m at work, my code is a communication tool. I think carefully about naming variables and functions, formatting, comments. I give up my opinions about code style, because consistency is more important. I split my work into logical chunks so that other people on the team can understand and review what’s going on. I use the same technology stack as other engineers, which makes it easier to share code, onboard new people and optimize. Maintainability is important, so any time invested in making things stable and approachable is worth it.
When I’m at a hackathon, all that matters is an interesting product. It’s important to spend time thinking about how it’s different from other things that exist already. Time is also a limiting factor and forces me to use the technology I’m familiar with that gets things done. Code quality, performance, design and other things hardly matter. The code is disposable, it doesn’t really matter if it even works properly, so it’s a good idea to use mocks and fake data. It’s all about a proof of concept.
When I’m at a programming competition, rapid test cycle is the key. I write tests for non trivial building blocks, compose them and test again. I know that the price of mistake is very high (I’ll end up spending way more time debugging). Code readability doesn’t matter.
When I’m working on side projects there are no constraints. I can make more time by going to sleep later or skipping chores. I am free to pick any technology stack I want. I am free to prioritize architecture, design, performance, UX, user research, marketing or whatever. I have no deadlines.
And this is where the paradox of choice gets me.
Related posts:
A side project story: Hacker Gifts (2018-2024)
A side project story: octave.im (2013-2016)
Hello! This text lives here to convince you to subscribe. If you are reading this, consider clicking that subscribe button for more details.
I write about programming, software design and side projects Subscribe