In the last couple of months, I’ve been working on a few coding projects and failed to complete them. The projects always start with a lot of ambition: “I want to learn concept x, learn library y. I want to add a cheeky error 404/500, because why not?”

Half,or the entire, the time, it was my fault. It happens to the best of us, and failure is okay.

Some of the reasons(*cough * excuses) I failed are:

• I got too ambitious, wanted to use the shiniest tools I saw on GitHub and got blocked.
• I failed to create time because I committed to a dozen other projects
• I failed to think through the scope and features for the MVP
• Binged The Witcher because it sounded more fun.

In this article, I’ll try to address the first 3 reasons to build a better system for myself – aimed primarily at people who are relatively new or slightly experienced.

Keep it simple stupid(KISS)

It’s unlikely this is the first time you’ve heard of this principle, but it works. Working with the shiniest framework, libraries, tools you can find is a double edge sword. You are likely to end up spending a lot of time trying to figure out how to get them working.

I’m not against using frameworks or libraries that would boost the performance of your application or improve the developer experience etc. The problem is letting yourself go down a rabbit hole learning how the library/tool works and working on the project less.

Pick the tools you’re familiar with instead. Focus on shipping your Minimum Viable Product (MVP). You can choose to iterate on it with the tool that can solve the problem.

Time is a finite resource.

If you really want to learn that library, my 2 cents are to focus on shipping your MVP first, then introduce one new thing to your codebase in every iteration.

In my case, I picked up nexus-result-field, Azure Functions, Azure Pipelines for deployment. I spent more time than I should have to try to make things work with nexus-result-field. This library improves typing GraphQL responses from queries and mutations (for another day).

Don’t re-invent the wheel - deployment

Deployment is an essential part of the development workflow. Companies like Vercel and Netlify have created platforms that enabled one-click-deploys, making it easy for plebs like me to deploy often.

Shipping from the start of the project ensures you don’t end up creating massive complex app that can’t be deployed.

Constant shipping creates a form of feedback loop – in the event something breaks in the process, you can easily fix it. It also creates some form of motivation to continue working on the project because your changes are live on every merge.

I tried setting up a deployment pipeline using Azure DevOps to deploy my app to Azure Functions and create staging environments/ deployment slots for a CI/CD kind of pipeline. Spoiler alert, it wasn’t the best idea.

One project at a time

If you’re like me, you may likely be easily distracted in the event you try pursuing multiple projects at a time. There is the fear that you may forget or lose excitement in the project if you wait a little longer – similar to how I stalk my amazon package immediately after placing the order and hit refresh every half hour. No? Just me? Cool.

Switching between projects is possible, but in my case, I experience a lot of attention residue every time I switch between tasks. This leads to me getting distracted, switching back to the first project, forgetting the second, and deadlines catching up with me.

Juggling between projects and tasks will only risk hurting your attention.

Conclusion

Take my learning with a grain of salt.

If you have questions, I’d be happy to answer them. Looking forward to your comments or feedback.