paint-brush
Why Solo Developers Should Never Take the Easy Routeby@gareth
227 reads

Why Solo Developers Should Never Take the Easy Route

by Gareth MahoneyMarch 5th, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

This story is my own take on why working solo shouldn't mean you take the easy route as a developer. Sometimes you've got to force yourself to do things to become better at what you do.

Company Mentioned

Mention Thumbnail
featured image - Why Solo Developers Should Never Take the Easy Route
Gareth Mahoney HackerNoon profile picture

This story is my own take on why working solo shouldn't mean you take the easy route as a developer. Sometimes you've got to force yourself to do things to become better at what you do.

As a solo developer, it can sometimes be difficult to do what you know
you should do. It’s often the case where you feel like you’ve got
something working and that’s all that matters. It fits the exact brief
and it’s a job well done. Or maybe, you think, well if this was to
break, it’s only me that has to fix it in the end anyway.

You read a lot about Git repositories, working in the cloud, and various
other things, but they seem to really only work for a team. You decide
to work locally, just keeping good notes of the code you write, and
building up your own repository.

You miss out on code reviews as you’re flying solo, so you try to make
sure you cover as much as you can through name variables, code comments, and the occasional form of documentation.

Avoid taking the easy route

When starting a new project, try using a git repo of your choice to back
up your code and get used to git commands. Pulling and pushing code,
versioning control etc. are all key parts of writing software. Just
because you work by yourself, doesn’t mean you can’t learn it.

Try your hand at documentation. If you’re stuck on how to write it,
check out a module that you’re using and see how they’ve done it. You
can learn a lot by attempting to replicate how they did theirs. For
example, a large number of python packages use Sphinx to document their packages. Give it a go!

Finally, write tests, even when you don’t want to. There’s a comforting
feeling when you go back to a project you’ve written several months ago
and find that you’ve left yourself this perfect guide to show when
something has broken or not. It’s like a gift from past you to present
you.

Final Thoughts

Without a watchful eye, it’s tempting to just shortcut through solo
projects. You might think, it’ll be okay, if anything goes wrong, I can
pick it up then.

Start to teach yourself to think differently.

Think: how can I make this better for myself in the future if I had to come back here in a few months?

The thought of “leave this better than I found it” can apply to your own work as well.

Also published at https://www.automateall.co.uk/AvoidingTheEasyRoute