Guidance on a More Effective Approach to Your Project and Coding

Overview

It increasingly surprises (and disappoints) me that I have to spell this out so frequently, to so many developers and systems administrators, these days, but unfortunately it has been an increasing issue for the past 5-10 years. So much so in recent years, even with supposedly "experienced" developers with 5-10 years of real-work work experience.

So, it appears I need  to actually write down what has been so self-evident as an effective methodical process. Followed by most in previous years, I rarely needed to spell this out.

The last 3 years I have had to do so for EVERY SINGLE PROJECT I have been brought into to save.

The following is just basic rudimentary fundamentals, but critical for a successful, scalable, and manageable project. These are basic practices, that should just be automatic habits, that EVERYONE should be doing EVERY time.

If you are the only person working on the project, then you can get away with skimping on these critical fundamental basics, but the moment you want to bring anyone else onboard, have anyone else help or take over working on your technical project or your software code, such short cuts will come back to bite you, and every one else wanting to work on or use your product or service.

Also, even if you are the only person who ever works on your technical project or source code, if you come back to the project after a long period of time, you will be very grateful and able to re-onboard yourself much more quickly if you followed these basic habits, versus having to figure out what the heck you were trying to do all that time ago when you had different knowledge about how to accomplish your goals or features.

Whether your project is open source or closed, whether you are doing the work for free or getting paid, these are required basic foundational fundamental habits that every technical worker, systems administrator, engineer, or software developer should ALWAYS get in the habit of following.

In the long run you will benefit from thousands of hours of your life freed up that would have been lost if you had not followed these principles.

Documentation DURING ALL STEPS - Don't Fall Into The "We'll Document It Later" Trap

I have literally (in the correct use of the word) heard thousands of time tech team members, managers, CTOs, COOs, CEOs, investors say:

"Read the code, you don't need comments or docs, just read the code"

"There isn't enough time for documentation"

"I'll go back and add comments or docs later when I have more time later, right now it is crunch time"

"We're too small to take time to document"

"We can go back later and add comments / documentation"

"Getting the features out the door is the highest priority"

"We can worry about the design docs later, right now just get that code live"

"Just do quick and dirty for now, you can explain the code later"

"Revenue now, we'll worry about doing it right later"

"I'm doing this work for free, without anything in return"

"I can explain it to people later if they need me to"

"I'm the only one that ever looks at this, so I don't need to document it for others, I'll know what I was doing [trying to do]"

etc.

These attitudes lead to exponential tech debt, exponentially longer onboarding, exponentially slower project advancement in the long run, and exponentially less scalable solutions.

 This mostly covered the Documentation portion of the APIE process. Somewhere I have articles on the other steps I need to dig up and link here (when time permits, whenever that might be). :)

Assessment

 // TODO

Planning

 // TODO

Implementation

 // TODO

Evaluation

 // TODO

Re-

 // TODO