5 key principles for better web development

Every creative discipline has its own set of good practices and principles that have evolved over time. They're generally born out of common challenges people in that industry face.

I think there are many things we can learn from each other, across the disciplines. So as a frontend developer, here are five key principles that have transformed the way I approach my work.

01. Everything has a life cycle

A few years back, I began working on my first enterprise project. It was a massive learning curve for me and, despite many setbacks over the course of the project, I was so proud of this thing of beauty I'd created when it went live. I checked the site monthly to see how people were using it. It was thriving in its infancy; it was full of articles being read and commented on.

Slowly new features were requested. These were exciting times. My emotional attachment to the project grew stronger. Then one day I read the words many creatives fear. Words of woe: 'Our NEW website has gone live'. It was over.

It's how it should be. But I've since learnt to give each part of the lifecycle the respect it deserves. Developers use the acronym CRUD (Create, Read, Update, Delete) to refer to the four basic functions of a piece of information. Let's apply it in a broader sense:

• When you are creating, remember you are not simply creating something to go live. You are creating something to live, breath and grow. Allow for change and embrace it.
• When reading, take the opportunity to feel good about what is in front of you now, which a few months ago was probably nothing but a pie-in-the-sky dream.
• Hopefully you would have taken some time at the beginning and put enough thought and care into the creating so that updating becomes just a continuation. Remember this may not be you doing the work. Create your site so the next developer will love you.
• Don't be afraid to delete a project if it's had its season. Even when you are emotionally attached. It's for the greater good. Creations have to die for creativity to survive.

02. Some things are broken, and some things are complicated

I have a theory. It's called 'The 10-step lifecycle of a CMS'.

1. A lowly developer curses at his screen while implementing a 'badly planned feature' in an 'even worse architected CMS than the last one'.
2. Said lowly developer makes the bold claim "I could do this so much better" while realising all his colleagues are either laughing at his rage or tweeting about it.
3. Lowly developer (now lead architect) builds new CMS.
4. CMS is hailed to be revolutionary as it is simple and easy to use.
5. Lead architect is thanked but asked if he could include a small feature.
6. Lead architect is thanked but asked if he could include a small feature.
7. Lead architect is thanked but asked if he could include a small feature.
8. Lead architect is thanked but asked if he could include a small feature.
9. Lead architect is told this new feature is suddenly more important than the last one.
10. A lowly developer curses at his screen while implementing a badly planned 'feature' in an 'even worse architected CMS than the last one'.

CMSs are hard. My point here is that some things are broken, and some things are complicated. It's worth deciphering this before potentially going down that rabbit hole.

Here are some useful questions I'm trying to ask myself:

• Has someone attempted this before?
• If I'm fixing something, how can I verify original problem has been resolved?
• How much time do I need before I will see some real value?

If the answers to these questions show that it makes sense to get involved, then jump in at the deep-end.

03. You need to stop repeating yourself (a lot)

I am a self-confessed fanatic when it comes to frameworks and plugging them together to find elegant architectural systems. There are a couple of techie terms that I battle with on a regular basis because, while the concept is simple to grasp, the implementation isn't always so black and white.

The issue is: there's a lot of factory-generated code gradually turning into a muddy puddle of 'stuff that does stuff'. On the other side of the spectrum, people like me have a tendency to keep endless catalogs of proverbial snippets that are never re-used. Whichever side of this spectrum you lean towards, our battle is to find where the value is.

The DRY (Don't Repeat Yourself) and SRP (Single Responsibility Principle) make us think about the significance of the piece of the work we are producing at any one time.

• How does this fit into the bigger picture?
• What is its key purpose?
• What is its relationship to the other pieces of the puzzle?
• How can it be built so that it encourages an open relationship to potential future uses?

Merging the two and injecting a little pragmatism and experience has helped me get closer to the elegant solutions I've been after. But how do you gain the experience to be able to apply an appropriate amount of pragmatism? I resort to a mixture of:

• Practice
• Reading
• Failing and getting back up
• Practice
• Talking with people better than you

The glue that's helped me to bind the things I'm learning together is to keep a blog. It doesn't have to be eloquent; write about the things you're finding out, how you solved a problem, how you implemented a feature.

I've often recommended keeping a blog to my team. I don't think I can overstate the significance of writing down your thoughts. There are so many benefits but here are a few:

1. You can (and will) use it as a reference in the future.
2. The physical act of putting down in words helps to solidify the key aspects of what you need to remember.
3. It will occasionally encourage conversation with people who read it, which again helps you to retain the knowledge and potentially spark further development.

Always keep in mind the immediate context of what you're building alongside how it fits in with the bigger picture and its potential. Build jigsaw pieces rather than mud pools.

04. You need to explain yourself

There seems to be some strange veil that gets lifted from your eyes and intuition when you have to teach someone (or something) else your thinking processes. There seems to be some self protection system built into us that keeps us from showing others our work for fear that we're getting it wrong.

It's good to find out you're getting things wrong and maybe think of it in another way. There are better ways out there to be discovered. So explain yourself to objects and people.

Use objects when you're trying to debug something in front of you. Explain yourself to colleagues when you're designing a concept. Do short presentations to your contemporaries after a project. I really encourage you to pluck up the courage to do longer presentations at local meetups. It's a scary thought but it's a great way to solidify your understanding on a subject and potentially be made aware of glaring issues you couldn't see.

I'm a big fan of the rubber duck technique. It's a method of helping you debug a piece of code by explaining it line-by-line to a rubber duck. It's surprisingly effective for revealing mistakes and improving the quality of your work, and not only for coding.

05. You need to keep things simple

Climbing a mountain is all about the small victories, before you know it you'll reach the top. That's been one of the most important things I have learned. My output and its quality has gone up.

A good friend once said to me "they ask if it's possible, but there's nothing you can't do...it's just a matter of time and patience".

Always start with something and make it something small. But start.

You're going to need patience at times. Learn to spot the red flags and don't be afraid to cut your losses and strip back. Nothing is ever completely wasted.

• Know your current focus
• Start and finish
• Explain things simply

If you can't describe (even to yourself) the value of your current task in an elevator pitch (30 seconds) then you either need to break things down or it may be leading you down a dark hole.

I would recommend a couple of books to start off: The Accidental Creative by Todd Henry and Steal Like an Artist by Austin Kleon.

Conclusion

I've gained so much by just thinking through and exploring these in much more detail myself. There are so many subtleties, which we pick up as we explore and we experience.

I'll leave you with the reminder that principles are only effective when held in balance with each other. I hope this will encourage you in how you approach your creative and life projects.

Words: David Taylor

David Taylor is a freelance interface developer. Sucker for a creative challenge, he has found himself coding, writing, teaching and speaking. This is an edited and updated version of an article that first appeared in net magazine.