A recent lesson I learned from pesky trail and error, is that you should always design first and program later.

Planning and Reflecting is the best way to program, if you run into a problem that you had not anticipated then you are not planning enough.

Your programs should each have a clear and concise design document, filled with: a firm and solid purpose, an array of processes, and a design document.

find the purpose of your project.⌗

Try to think of all the purposes for your project and write them down. I say purposes to indicate that there are many ways to look at this, and multiple answers.

For example, if you are writing a website for a company. Think about the company, their image, what will they get from your beautiful website.

Afterwards you think of what you could benefit from this website: increased skillset, new experience, a fat stack of cash, maybe even a new business relationship or maybe the high you get from following your passion.

Lastly, think about the users and what they want. What could impress them? Maybe, they’re technically savy users and want the minimalist experience possible. Perhaps, they’re customers who have very bad internet connection, so you gotta optimize frequently.

Study the purpose, as it will be the savior from when your project is horribly sinking/failing. The more that you study the purpose, the better your program’s reception will be.

define the processes⌗

We got the purpose locked down, what we need is to outline the processes.

This heavily depends on the purpose, as processes are the implementation of your project’s goals and features.

For example, if you want to do user authentication, you need to figure out if you wanna roll-your-own or reuse an already existing library.

Since time is always scarce, knowing what process you will spend your time on will help you in the long run to adapt to future problems.

Never close doors in terms how your processes are implemented. Instead, write down powerful abstractions that are extensible and adapt easily to future improvements &/ change.

Don’t forget to plan out the importance of each processes, and figure out a schedule to implement them.

document everything⌗

You have all your ideas in mind, all connected in a messy web of relationships.

What you need to do next is untagle that web into a simple document full of detailed actions to follow.

Preferrably you sort these actions by priority, i.e writing the interfaces first then the implementations. But to each their own, and different strokes for different folks.

Don’t forget that you are not perfect, and it’s better to learn from your current and future mistakes than to quit. Moreover, software development is a process, that means it takes time, and you could fail sometimes. Practice will certainly lessen your chances of failure, so it’s better than nothing :)

bonus: assume others will visit your codebase⌗

This, I think, has happened to all programmers. Your project has grown a ton, you want to implement a new future, but you find out that your codebase is hard to read and you get lost finding out how to implement the new future rather than actually implementing it.

No one wants ugly code, even if you work solo, or your software is closed source, make sure that your code is clear and easily-understable. A good rule to follow, is that the total your comments should be equal or bigger than your lines of code.

Detail your comments. Assume that you have alzheimer’s and need to be constantly reminded of what each function, variable, or data-structure does.