Photo by Kaleidico / Unsplash

Developer Workflow

Coding Jul 22, 2022

Speaking with a client earlier today about workflow made me realize that I have never really documented my typical workflow and it could be useful for people getting in to programming to have some examples about how professionals handle typical workflows. I think everyone has their own process here, and none of them are wrong - this is something that you create that fits your needs and examples like this are just ways to build a more robust workflow for yourself.

When starting a new project from scratch I typically like to think about the project and its needs to get a good overall idea of how things will look and feel. Getting this outline really helps get a vision of the project that you can build from and it generally helps me to understand the needs. Everything from infrastructure to database schema/models can be drafted here - of course nothing concrete because as you go along you will likely find things that need to be changed. This phase is critical for scoping out the project to avoid getting overwhelmed and abandoning it which I think every developer does quite frequently myself included. You should also write this down, I'm guilty of not writing enough down and forgetting really important things during development which slows things down and requires rewriting things so please, grab a notebook and take some notes or better yet, use a project management tool like Github Project Boards or Shortcut.

Once a good plan is thought out and I have a structure in mind I go one of two ways - start writing code or start rolling out infrastructure. Typically starting with some code may be a good idea because infrastructure costs money and most of the time it costs money even when it's not in use. There are some cases where having some infrastructure ahead of time may help for example if you're working on a project other people on components that need to communicate with each other (ie. backend and frontend). The initial code is usually just a lot of scaffolding, getting things set up for the future. Laying out models or schema, database connections, etc. so that you can plug in to these things later. With REST API backends I use this time to handle the component structure too, adding folders and empty route handlers, middleware, utilities and things of that nature that will be needed later to build a solid base to plug the rest of the code in to.

The initial code phase is a long one and requires you to really think about the project and to write your code in a modular fashion so that it can be flexible to fit the needs of the project as you move into this step which will build upon that base code with your core "business logic". Implementing your API routes, your internal processes or whatever is more specific to your project. This is a recursive process that lands you with an MVP at the end but requires a lot of thinking about the process that you're doing even during this single step. What I usually do is begin writing a specific feature as a "rough draft" - each time I make some meaningful changes I'll manually test them and then continue. Once I feel the feature is completed I take some time to go over my code and refactor it to make it more readable and fix any edge cases or performance issues that come to mind. This is critical in my opinion because it allows you to think about your code outside of the problem solving context and helps you produce higher quality contributions to your projects. Once I'm comfortable with what I have I will write tests for the feature which allows me to go over it once more but this time with tests in mind, thinking about the overall solution and patching up any edge cases that come to mind once again. Finally once all of this is completed I submit the code and mark it completed to move on to the next feature.

At the end of this you will have a solid MVP that you're proud of, with nice clean code and proper tests written at the time the feature was made so that you don't even have to memorize what each component does - it's okay to forget sometimes.

One more note is that my process has evolved a lot over the years, the latest iteration here was changed over the past few years to fit the Git feature branch model of development because that's my favorite way to work on code with other people. Your process may be different and there's nothing wrong with that! Produce quality results and your clients/customers will be happy.

Let me know in the comments what your workflow is and how it differs, I'm always open to suggestions and discussion about how to improve this and I think it's important to put this information out there for others to read so that they can learn and build upon what everyone else is doing.



Steven has been writing software and exploring computers since the age of 17 all the way back in 2008!