Improving your workflow

Like I said before, when you know how to solve a problem, coding is simply a matter of typing. As developers, it is really tempting to start a project by coding. It's hard to argue this method, because I do have projects that worked just like that and I managed to complete them. However, the better approach is to organize your workflow before getting started.

The common saying is, "you wouldn't build a house without a blue print." Why do the same mistake with a software project? The reason us programmers do start coding immediately is the cost of making mistakes is not as big or obvious. If I build a house without blueprints, chances are it will collapse, injure and kill people. Good enough to frighten any builder.

However with software, the collapse is not fatal, at least not with web programming. If no one can use Facebook for a day or two, I think we will still be alright.

The problem that occurs with unplanned workflow is the project becomes complex early in development. When you are writing code as you go, chances are you will become disorganized very quick.

Even if you are an experienced programmer, it is still very hard to keep track of everything that happens within a project if it doesn't follow a convention.

By creating a good workflow is taking time to organize.

Let's take one of the projects I worked on a few years ago. I wanted to create a tool to takes screen shots of any websites. I would say I was semi-organized because my methods could have used some improvement.

The ideal workflow for shotsrv.com

This project was born out of a discussion with two friends. We wanted to create a quick tool that takes screen shots, similar to a crappy tool our employer was using for an obscene amount of money.

Starting with coding immediately would have been a mistake in most cases, but like I said before, it's only a matter of typing if you know how to solve the problem. I didn't know how to solve the problem so I had to do research first to see how I can implement it and build a prototype. All it was a command on the terminal. And it worked.

After this, I went completely crazy and created a website and wrapped the whole thing inside and deployed it. Even added a paid subscription service. Of course it failed in many ways. To this day, I am afraid to look at the code base because I don't know what does what.

But here are a few things I could have done to make the project gracefully come to life.

Organizing the project.

I talked about the layman's way to multi task before and this would have been the perfect place to practice it, if I was applying this concept at the time of course.

If the computer worked on a single task at a time each action will make the system unresponsive until the task is completed. It might even be faster at that task but the overall work will take much longer to complete. So the computer is doing the optimum thing by taking this divide and conquer approach.

Dividing the tasks into small tasks that can be developed independently is the best approach. For a service like this one, there was to be a pleasant UI, a backend, a user authorization system, an API, a subscription, some CRON jobs, and a server setup.

Each of these could be further divided into smaller chunks. The UI can be divided into HTML, CSS, JavaScript. Each of those can be reorganized into smaller modules: layout, registration, newsletter, header, footer, and so on.

Organizing can take hours to complete, but it pays off in the end. When you have all this information on paper, or note taking application, it is much easier to see the big picture. Maybe a feature you thought was cool, conflicts with another or makes no sense at all. All this work is done before you write any code that would be in the final product. Just the prototype maybe.

Because each part is independent, you can easily update one without affecting the others. If your page design doesn't look very appealing, you can change it without messing with the API or any part of the website. For that matter you can decide to discard it and make it a native app instead of a website, without sacrificing much effort.

---

If we were to create a Facebook clone today, it would be very hard to start while staring at a blank page. Our coding skills are not gonna make the project start any faster. However, our organizational skills and workflow will take us from point A to point B.

The workflow you choose to implement will help you complete your project faster then your ability to code.

---