(Actual) Full responsive development

It’s surprisingly common for designers and developers to create websites that work well on their giant 27 inch monitors and on their iPhone. This leaves a lot of users with the middle screen sizes that will have less than ideal or straight up broken experiences. I always make sure to test the full spectrum of screen sizes to ensure a good browsing experience for everyone.

A particular pet peeve of mine is the main navigation going to a hamburger at a desktop screen size rather than making sure the navigation stays visible outside of the hamburger for as long as possible. For icing on the cake, the main nav item(s) should stay visible outside of the hamburger for as long as possible – even on smartphones. If we can remove that extra click to reveal the hamburger navigation, then that is ideal.

Seek out opportunities for growth

I really don’t want to just build the bare minimum website and be done with it.

I want to help the company I’m working for grow and meet their business needs. Doesn’t matter if it is new up sell opportunities for our clients or new features, conversion strategies, or other optimizations – I want to identify these and provide an opportunity for additional growth.

Process over results

Every website owner wants the same result: a website that converts. Doens’t matter if the conversion is a sale, contact, signup, share, or whatever. The general goals stay the same.

In order to get to that result, website creation and maintenance must undergo a deliberate process to achieve those results. The process is far from an exact science, especially since every industry and conversion goal presents unique challenges to be overcome. But a process must be followed to achieve any positive result. This process covers every part of creating and growing a website – project management, design, development, copy writing, testing, optimizing, and everything between.

The key is to focus on an effective process because working through the process is the only way to get to an end result.

For example, if I want the desired result of turning off the lightswitch, I can’t do any random things in order to achieve those results. I have to set the goal, break down the process, and work through the process. In this simplistic example, the process is instinctual – stand up, put one foot in front of the other towards the light switch, raise my arm, and flip the switch. No one would argue anything different.

But when it comes to websites, people think any random steps in the process will help them achieve their desired results – a website that converts.

The only way to achieve the result of a good website is to focus on improving every step of the process, both in terms of efficiency and quality. This means testing and discarding the unproven ideas (and pride) if the data does not support them.

Never stop learning

I absolutely love learning new things. Almost doesn’t matter the topic, I simply love learning new things. My mother in law loves to make fun of me for always having various random facts to contribute to most any conversation.

My love of learning is one of the reasons why I love my job working on websites. Half of a frontend developer’s job is to learn whatever new framework, CMS, plugin, integration or any other doodad the site needs. This means the number of different skill sets that go into a complete website design, development, management, and marketing goes beyond what any one person can learn. This allows me to always have an opportunity to grown and learn as an individual and as a web professional.

The web will certainly never be a boring or stagnant industry to be in – and I love it that way.

Code libraries are good and bad at the same time

The age old question for a developer is, “Do I use this framework/library/plugin/addon/etc or code it from scratch?”

There are a lot of benefits to either route and neither route is the correct answer for all situations.

Using pre-existing code is an excellent way to speed up development. Almost everyone uses some sort of existing codebase, be it a framework they built themselves, Boostrap, Vue.js or React, or a CMS. As much as developers love to talk about how they write stuff from scratch (I do it too), there are oh so many instances where writing something from scratch is not advantageous to the project. Let’s take a look at two examples to make my point.

eCommerce – if I were to build a full custom eCommerce platform, it would take forever and be super expensive to build. But even if I were to finish it within this lifetime, most likely it won’t have nearly as many features as the existing platforms out there – especially when plugins are tossed into the mix. Not to mention my platform will have undergone substantially less testing. It’s pretty obvious that building a custom eCommerce platform is a pretty poor choice for 99% of eCommerce websites that don’t have a several million dollar budget.

But now let’s take this to something smaller and more relatable – such as Bootstrap. Bootstrap is an established framework that has undergone lots of testing and is surrounded by tons of free documentation, addons, and various code snippets to accomplish all sorts of tweaks and customizations. Furthermore, if I write something with Bootstrap, almost any other developer can look at my code and reasonably understand how it was built and how to maintain it. For most client based web projects, this makes Bootstrap an excellent choice. It doesn’t matter the lifesycle of the agency or where the client goes, most any developer can jump in and get to work and many common customizations can be easily found on the web, further speeding up the web project.

But this doesn’t mean that all web projects can be a perfect fit for Bootstrap. While Bootstrap has a lot of useful components, it has plenty of things that most websites don’t need. While a good gulp compiler can remove most of the excess CSS and JS, it’d take a decent amount of customization to really whittle it down to nothing. Even though we’re talking about just a few kb here and there, every bit of savings helps. There are web projects that are so simple and light that a custom solution would be appropriate. Or to the opposite end of the spectrum, there are web projects that have a large enough budget that a custom CSS library could be built to ensure every byte of code is purpose built for the project. Even though I’ve built my own CSS frameworks in the past, in my opinion, these types of projects are few and far between.

All that being said, I have built the Whiteboard Framework – a custom WordPress framework to speed up development. While it has gone through a pendulum of activity, over its lifespan it’s been downloaded well over a million times. Starting with a good custom baseline to customize to your heart’s content is a good way to use a framework while reducing the bloat of the framework.

Everything really is a case by case basis. People have their preferred frameworks and their preferred levels of existing code to start with. There is no absolute black and white answer. A good developer can muddle through the grey and find the best solution for the occasion while not being close minded to new frameworks.

Obsessive about project management organization

Just like how good code needs to be organized, an entire project needs to be well organized. It doesn’t matter if it’s a single developer project or a multi-developer project, task management, prioritization, and organization is critical to a project’s success.

Websites have way too many facets to them for anyone to keep it all straight in their head. A written record is key. It maximizes the efficiency of the project and helps make sure things aren’t forgotten.

I’m pretty obsessive about todo lists. I always say that I live my life in todo lists. My professional life is no different from my personal life in this matter. I very much believe in the power and importance of good task management and project organization and can get a bit obsessive about keeping it all organized and tracked.

Give back to the development community

While I don’t have the time to give back nearly as much as I would like, I still try to give back to the web development community. So much of the development world relies heavily on those who share their knowledge and code snippets freely.

I participate in various development, web, and digital marketing oriented online communities and help others out in an effort to give back. I also try to provide snippets and information through Github and Github Gists – but I wish I had the time to do more.

Planned code is the best code

I’ve seen plenty of developers just start writing code as soon as they get the task. While this can give the impression of speed and efficiency, it is often the opposite of ideal.

I prefer to take a little bit of tile to fully review the full scope of the task, any semi related tasks to ensure compatibility, and plan out the execution of the code before I start writing.

A little bit of planning can go a long way to ensure minimalist code that is manageable, scaleable, and prevents as many negative edge cases as possible.

Communicating technical concepts to non technical people

Communicating with non technical people is often a big component of being a developer. It doesn’t matter if it is internal discussion or coordinating with the client, not everyone who works on a website is a developer. Being able to coordinate with nom developers is critical to the success of a web project.

Personally, I enjoy using analogies to convey development concepts, be they level of effort, execution process, or even pros and cons.

The less code you write – the better

The lightest, fastest, and easiest to maintain websites generally are the ones with the least amount of code written. This obviously isn’t true to an extreme, but as a general rule of thumb, but simple and lightweight code helps everyone.

Overly complex code can very easily be a detriment to a website. Not only does it take more time to write up front, complex code makes it harder to maintain by the developer who wrote it, and even harder for other developers to maintain it down the line.

Excessive code will often slow down websites and create more edge case bugs than simplistic code.

The websites I’m most proud of did the most with the least amount of code written.

No bloated page builders

Page builders are the bane of site speed and maintainable code. While they make an effort to minimize their impact, they still introduce a lot of bloat and negatively impact the site speed and create a lot of edge case bugs that are time consuming to fix. The more you customize them, the more of these edge case bugs appear. The process to customize sites to match custom designs are also far from ideal as there’s always extra effort and bloat to force a certain layout.

Page builders to have some benefits – primarily speed and financial cost. But for the quality of work I want to output, the bloat they create isn’t worth the time savings. Especially given how fast I write organized and clean HTML/CSS.

I build custom websites from scratch to meet the exact needs of the client while still maintaining fast, scaleable, and maintainable code, avoiding the page builder bloat.

Data oriented development – creating websites that convert

A website can be a company’s greatest asset, or just another thing that barely makes a difference on the success of the business while sucking money out of profit margins. A great website is an asset to a company, not a drain. In order to be an asset to a company, the website has to actually convert.

I am a data junky and love to study a site’s analytics, read studies about conversion rates and what works and doesn’t work, and am not afraid to toss out ideas if the data doesn’t support them. Every decision on a website build should be run through the filter of, “will this help the conversion rate?”

Conversion rates don’t care about personal preference.

Laziness is no excuse for a slow website

So often website builds cut corners at the expense of a website’s speed. Tests after tests have shown how minor increases in a site’s load time have a substantial negative impact in a site’s conversion rate.

I go through great lengths to create development processes to ensure fast websites but still maintaining an efficient development cycle.

Scale-able and manageable code

The difference between good code and great code doesn’t come down to the quantity of bugs it has, but rather how easily the code can be digested, managed, and scaled by developers other than the guy who wrote it.

That is why I always strive to write minimalistic code with a consistent structure, plenty of comments, and organized in an easy to understand manner.

Plan ahead to best meet the client’s needs

Many developers only consider the minimum amount to complete a task. If the minimum feature set can be met – then it is “good enough.”

That’s not the case with me. I like to plan ahead and make sure my work will grow and be easy to maintain. I do this from a programmatic standpoint as well as a business standpoint. If the client gets backed into a corner, they won’t be happy. It doesn’t matter if it is due to unmanageable code, poor content management setup, plugins that can’t grow to meet their business needs, or any other random component that technically meets a feature set but doesn’t meet their goals.

I try to look at websites from a wholistic business standpoint to meet a client’s long term goals and do whatever I can to best meet those goals.