Tech Sisyphus

Content tech jobs require you keep up with the full stack used to build a content-focused app. A general understanding is needed of all parts, and expertise in several is preferred.

Rolling that Boulder

Revenge of Moore's Law

In my last post, I write a little about how driving the site forward takes work, especially if you want to build a good site.

Images are the best example. Images can quickly destroy site performance if they are too large, the wrong format, not cached, or not optimized.

HTML doesn't do the content tech expert any favors as the <img> tag just stuffs an image into the DOM. This was great in 1999 when browser were weird and creating pages was difficult.

Now, we have to use srcset to tell img to do the right thing BUT we also have to have images optimized for each entry in teh srcset.

So. This is more work and points at a larger issue.

The tech keeps changing. Back in 1999, nobody imagined the iPhone 11 when browser viewports were assumed to be 760x480 and sites were hardcoded to a width using tables and pixel-specific values for cell widths and so on.

While images are one example, content tech is continuing to evolve as content needs to be searchable and indexed by services like Algolia or others. It needs to be marked up with schema so that search engines can easily know topics or details about content and show content as rich snippets, in business sidebars, and more.

The tech keeps changing. Thanks Moore's Law!

The web moves fast. Too fast.

Who loves internet explorer 6?

There's value in becoming a wise old elder, who knows every detail of a specific system or technology.

Well, there's value in that until Moore's Law wipes out that technology. Very few platforms survive more than 5-10 years in IT. With the web, it can be even less as browsers dictate what is useful/current and when the browsers are retired, so is that tech.

Side-note: Have you every screamed "I HATE INTERNET EXPLORER" in your career? I mean, it was a good-enough browser but when people built sites that only ran on IE? Oof.


While a person who knows MUMPS or IBM Mainframes might have a job forever, folks who work with the web need to keep up or they get left behind.

A content tech development plan

Fundamentals, frameworks, then platforms.

In general, the only way I found to prevent being left behind is to divide the tech into two parts:

  • Fundamentals: HTML, CSS, JavaScript
  • Frameworks: tools that combine the fundamentals in ways that make it easier to build pages
  • Platforms: software, like content management systems, that provide data, network, and other core services required to get sites build on fundamentals/frameworks out to visitors

This site and the rebuilding process is a great example of how I approached this stack in order to keep up with the tech.


HTML, CSS, and JavaScript

On one hand, these fundamentals don't change often and when they do they have to be backward compatible. Theoretically, you could keep coding things the same way you did 5 or 10 years ago and browsers would process it and chuck out a page.

But, the fundamentals DO evolve to address new needs. That `img` tag that once took a source property and that was it? It had to be updated so that it kept up with new display options.

JavaScript is especially prone to this. You could still write pages with jQuery and plenty of people do. The problem is that jQuery was written to provide a standard interface to programmers when every browser underneath was different. jQuery solved a problem (weird browsers) that doesn't exist today to the extent that jQuery is needed.

If you don't keep up with the tech, you wind up programming with a library that isn't really the tech and when that library is no longer supported and turns out to have critical security issues, you're in a bad place.

Even with the fundamentals, content tech professionals have to track what's happening.


React, Ember, Backbone, jQuery, and more

Of course, if we have to rebuild the same stuff every time we create a new site, life is terrible.

Frameworks provide us with tools that make site creation easier. jQuery let us write code in a way that would execute on any browser at a time when browsers were terrible, weird, and sometimes evil.

As browsers matured, frameworks also had to mature. While browsers are now much more consistent and adhere to universal language standards, other problems emerged like "how do you build a site that takes full advantage of a new phone on fiber WiFI but also works great on a second-hand phone on a 3G network?"

Frameworks attempt to address those problems as the evolve and emerge. React makes it easier to build huge sites. Then NextJS helps turn React sites into more streamlined versions so that performance is better across devices.

What's important, I think, are two things:

  • Understand the problem the framework is trying to fix. Lots of frameworks I've found are "opinionated" which often means that some smart people made a framework that doesn't address anything specifically but just kind of bundles some stuff up into a confusing hairball of code.
  • Understand the edges and limitations of the framework. Know where the framework stops being useful. Most importantly, know when you can use plain old JavaScript to accomplish a task without the overhead of the framework. (I'm looking at you, people who continue to load jQuery!)

And, of course, as new frameworks emerge, pay attention.

Usually, new frameworks are the confusing hairball type that can be tossed because new problems to solve are rare. But sometimes, a solid leader shows up that solves a new problem OR uses a development in the Fundamentals in an important way.

When that happens, people rally around and it's good to watch that leader framework evolve even if you don't need it at first. Seeing how they change (often by scanning the issues in Github every month or so) can help you understand the problems it's solving.


WordPress, Cloudflare, and all that other stuff

Platforms are the worst because they are owned by a vendor, they play games to make it hard to switch to other platforms, and once you leave the platform all the things you learned about the platform are useless.

But, just like with frameworks, platforms solve problems. There's no way I'm going to build a CDN that can compete with Cloudflare. When I need to think about caching content, I'm going to use services from Cloudflare or Azure or Akamai or some other "A" vendor who shall remain nameless lest I summon them like Beetlejuice.

The thing is to learn enough to build solid sites by relying on the fundamentals and frameworks. Platforms solve problems that are worth paying money to solve. Use them to solve those problems, but, again, know the edges.

Learn enough about the platforms so you don't overpay or miss an opportunity to make some other complexity/cost/risk go away. But then stop. Unless you like being locked-in to a vendor...

The bottom line here is (a) don't become an expert unless you need to be an expert and (b) never forget to keep up on the fundamentals and frameworks.

A Schedule to Refresh

How to stay up-to-date with Content Tech

This is my opinion, but this approach worked pretty well for me. YMMV.

  • Fundamentals: I never stop paying attention to these. There are tons of expert writers who talk about interesting ways to use what's already out there and then are happy to explain how to use new developments to great effect. The other key here is to write code using just the fundamentals as often as possible. Practice makes for expertise.
  • Frameworks: For these, I pay attention to release change-logs. Watching what is changing is the best way to know how the frameworks are trying to solve new problems or refine what they were already doing for old problems using new fundamentals.
  • Platforms: Get training as part of a plan to adopt a new platform. Bundle it into the price of a new contract if it's a major enterprise expense, or find a way to get really high quality training thru something like Udemy if the classes exist. For some platforms, like Sitecore or AEM? Prepare to pay a small fortune for initial training BUT THEN you don't get trained again, you just pay CLOSE attention to vendor blogs and join their Slack, Discord, developer email list, RSS feed, and so on. Platforms can be amazing, but also awful.

OK. This post is done.

It's time for me to go roll that training boulder back up the hill and find out why NextJS is throwing a wacky error, then review Typescript because something I'm doing there is wrong and I'm using an explicit "any" type which...well, I'm not proud about.