I gave myself a year to get an semi-ambitious project out there after a 3-year break.

But really, what was more important? I would argue the lessons learned. I have had time to reflect upon my previous practices as a developer and what I have learned along the way since, I could incorporate into a set of professional practices that aid my productivity and also my state of mind.

I call it:

The X Number of Greatest Tools Ever.

Here is part one.

Create a Working Model

I purposely gave this approach a name and a grand one. Why? To make it memorable and allow it to evolve and become it's own thing.

But first...

How I used to code

Cut to three years prior. How would I implement a feature? I remember I would go directly to my development project and begin implementing new code.

The problem here I was running before I can walk.

When I ran into a problem, I had no knowledge to fall back on, no foundation of understanding. This was frustrating but really just a symptom of impatience.

What is a working model?

For me, it means implementing some code in a separate project, or as many projects as needed to achieve my objective. The code could be from a sample project, a tutorial or official documentation.

Just reading about the code is one part of the puzzle, you need to get hands on and execute it.

Coming back to the documentation later, means you have a frame of reference: your working model.

Once you have typed out the code (not just copied and pasted it), got it to compile, you have the start of your working model.

It feels good to be making progress by laying the ground work. Next, spend some time adding break points and stepping through it.

Benefits

Using this approach, I increased my level of confidence in my code I had already debugged it outside of my main project and so knew the purpose of each line.

This also provides familiarity. If there are no issues with sample code do you spend time to debug it? Perhaps due to time pressures, you may move on to the next task, missing out of an opportunity to learn what the code is actually doing.

Familiarity is important for being able to maintain the code, make enhancements, bug fixes and just bend it to your will as opposed to fear of making changes in case you break something.

You are also helping out your future self and fellow developers. Coming back to your code in the future or when someone else in your team is picking it up, you are saving everyone time.

You are leaving a trail of how something was implemented and the reasons for. In the future, you may received questions like:

• where did you get the sample code?

• why did you implement it this way?

You can add all this information into your sample project or an internal wiki, with links to the sample project, add comments for your thinking and generally contribute to leaving a positive legacy.

Finally, by executing the code in a separate project, you will learn what dependencies are required in order for it to run correctly, you are getting a fuller picture without the 'noise' of the everything else.

This may all sound time-consuming, but you may have heard the saying:

there's always time to get it right.

This way, for me at least, is a lot less frustrating, less random and more enjoyable.

The first part of The X Number of Greatest Tools Ever is Create a Working Model.

Do you agree? I want to hear from you. What are your Greatest Ever tools that get your through the tough times?

I hope this helps, thanks for reading.

Mulk