Don’t Forget: Keep the Web Simple

I just had the pleasure of being reminded how simple and great the web is at An Event Apart in Austin, TX.

In one of the talks I attended, Jeremy Keith reminded us that though the web has become a complicated beast, it is still amazing in its simplest form. And we shouldn’t forget that.

This sentiment rang very true to me – It made me recall the pure excitement I felt back in the mid-1990’s, when I was 13 years old, putting my first web pages on the Internet. A kid like me could create something from nothing, and better yet, self-publish it and have it accessible by the whole world. Anyone could see my content!

Since I started my professional career, I’ve been focused on very large web applications, many times with heavy server side work. More recently, I’ve worked on large Single Page Applications that run lots of Javascript in the browser.

I love what I do, but these types of applications have been complex beasts to work with. There have been days where all my time is spent wrangling the latest-and-greatest Javascript frameworks, leaving me frustrated because such-and-such plugin doesn’t work with AngularJS 1.2, or whatever the framework du jour is. Or why I cant get my Grunt build working that day.

Along this path, I forgot about the power of a browser rendering simple HTML and CSS. And perhaps more importantly, having that content be globally accessible in one simple place – a URL.

These ideas of were underscored by almost every other speaker at An Event Apart. They reminded us that in order to create the most useful web sites for a user, we need to forget about fancy layouts and CSS. Instead we should focus on content first and ask ourselves: “What is most important for the user?” We should make that content simple and easy to find, regardless of how advanced their device or web browser is. Then, get it captured in plain, semantically meaningful HTML markup. The rest will fall into place.

I write this with the hope that it will help me remember these ideas for the next web app I build.

My notes for An Event Apart from Austin 2015 are posted on Github

Show, don’t tell

During my first few years of working in software, I had the opportunity to work with a mentor who had quite possibly the best approach to introducing new ideas that I’ve ever seen. The best way I can sum up his approach would be “Show, don’t tell. And don’t be a jerk.”

To give some more context, we worked in an organization where change was widely viewed as something to be feared, rather than something to be embraced. Ideas for change were often met with resistance, especially by management.

The primary way that my mentor worked his magic was through small experiments. The bulk of the work done on his own time. If there was something that he viewed needed to be changed, he would take a small slice of that problem, and apply his idea to it.  It might not solve the whole problem, but he showed the path toward it.  For example, if we had a problem with triaging production issues from messy logs, he might take a crack at spiffing up the styling alert emails that got sent out (this was before Splunk and other tools).  But not everywhere, maybe just in one place on just one  of our many applications.

Then, he’d show it to the team to see what they thought.  Seeing a working example of his idea, the team would often embrace it. We also had a working template to start from, should we decide to pursue it. This was a seed that he planted, and if the team decided to nurture it, that idea would grow a life of it’s own with just a little bit of initial effort.

What didn’t he do? Talk about his idea for change before he started. You didn’t hear “I think we need to change X to Y because…”

I’m guilty of doing this, and it doesn’t work.  Talking about an idea significant change without action dooms it from the start. Imaginations run wild and what-if scenarios scurry about like frightened mice. All the time wasted during this pontificating could be spent doing a small experiment to see if the idea really works. If you do that experiment simply, and test it cheaply, chances are you have a lot less to lose than a meeting where the whole team talks for an hour.

We also can’t forget that people sometimes are apprehensive of change in a team. They’re comfortable working the way they already work. Why would they change? But if you have visible progress that something works, instead of just words, that’s hard to be afraid of or argue with. Also, don’t forget to hear them out. Why are they resistant? Sometimes simply letting people talk through their feelings goes a long way. And they may have very good reasons for feeling as they do.

You have to be prepared for this strategy to fail. You will have ideas that are great and your team just isn’t ready for. Or, you will have terrible ideas that are rejected for good reasons. You cannot get defensive if these experiments do not pan out. You cannot under any circumstances get upset if those ideas are not embraced immediately. If they aren’t, try again, softly, with a slightly different experiment.

Many of us in software work with Agile processes, quickly iterating over software features until we hit on what our users want. Think of changing an organization the same way. If it doesn’t work the first time, what can you do better? Was it a problem with your idea, or was it just not communicated successfully? Was your example too small, so that it didn’t really present the power of your idea?

Above all:  Don’t be a jerk. Lasting change on a team requires buyin, and that doesn’t happen if you’re not empathetic.

So go out there, do good work and plant some seeds for change in your team.