Attention all front-end and middle-tier developers! Here is a paradigm shift for you, though any back-end programmer will tell you this is the way the SDLC should work: Make SOLVING THE PROBLEM a separate issue from WRITING YOUR CODE.

Too many times I see code snippets, plug-ins, and other ‘one-offs’ in code written in a way which makes it obvious that the developer didn’t give much consideration to the problem they were solving. Very often, I see a JavaScript file which has either WAY too many comments to be out on the web, or a JavaScript file which obviously was put together on the fly without any thought to structure or readability. One easy way to fix this problem is to separate the solving of a problem from the writing of your code. The advantages are many: 1) You will code more efficiently. 2) Your code will be readable. 3) Your code will be more scalable. 4) Requirements crystallize while solving the problem. 5) Your code will be re-usable. Just a few advantages to shifting your thinking to this method.

When I’ve spoken on this subject to other front-end developers, I get many blank stares. Additionally, after I speak I get some questions privately telling me that developers have to code to problem solve. I disagree. Problem solving while coding should be limited to creative ways to achieve a result within your code, not creative ways to solve the business problem put in front of you. If you code without a solid sense of direction and purpose (beyond a “Gotta fix this” mentality) you will not put out a product you can be proud of a year from now. You will instead be manufacturing a stop-gap measure to address an issue temporarily, even if it ends up being a ‘permanent’ fix.

So, how does a front-end developer, a species notoriously known for ‘quick fixes’, begin this journey to writing better code? It’s actually pretty simple to start with: Refuse to write code until you solve the problem. This problem solving can involve many parts of your organization or just yourself, depending on the problem being addressed. Need to write a service bridge to connect platforms? Probably able to do that yourself. Need to write an API set for external clients? Probably need to involve others in your problem solving. A simple 20 minutes session with a whiteboard can save 5 hours of coding headaches and clean-up. Even if your under budgetary constraints, this approach is beneficial. Remember, $10 spent on planning saves $100 in development and $1,000 during maintenance.

On a more complex level, when building frameworks, you may need some complex visual aids. Invest in Microsoft Visio or a similar program. Diagram your data flows. Organize your classes and properties. Dissect the problem into discrete chunks and solve those problems, writing the solution in business-speak. Try not to think about the code-base you’ll write to address these problems, just write how you will solve them.

Now, this all sounds easy, but it takes practice. It wasn’t until I started developing large-scale frameworks and worked as the architect on sites/applications under huge user loads that I learned this and was able to put it into practice. Now, using this approach, I think that my colleagues agree I’m one of the more efficient coders you’ll meet.