DEV Community: Sean H

The Most Valuable Skill in Software Development

Sean H — Sun, 09 Aug 2026 00:00:00 +0000

The most valuable skill in software development is not React, Rust, Kubernetes, TypeScript, AI prompting, or whatever tool is currently being called "the future" by someone with a newsletter and a suspiciously clean demo app.

It is learning fast enough that the industry does not leave you behind.

Yeah, that sounds like motivational poster advice. Put it under a photo of a mountain and it immediately gets worse.

But in software, it is annoyingly practical. Specific technical knowledge is valuable. It also expires faster than people like to admit.

I started writing software professionally around 2005. Since then, web development has gone through enough eras to deserve one of those "Top 10 Moments That Changed Everything" headlines. Except there are seven here, because history refused to pad the list for SEO.

So here is the web development speedrun: seven periods where the ground moved, everyone updated their resume, and yesterday's "obvious best practice" quietly became a museum exhibit.

2000: Server Pages Ran The Show

The old web was easy to explain. The browser asked for a page. The server queried the database, generated HTML, and sent it back. PHP, ASP, JSP, Apache, IIS, MySQL, SQL Server. You could draw the architecture on a napkin and still have room for coffee stains.

JavaScript existed, but it mostly had a summer job. Validate a form. Open a popup. Swap an image. Maybe make snow fall across the page because a client had recently discovered Christmas.

The lesson was simple: the server owned the application. The browser displayed the receipt.

2005: AJAX Made Pages Feel Alive

Then AJAX showed up and made the web feel less like submitting tax forms through a fax machine. A page could talk to the server without reloading the whole screen. Google Maps was the big "oh, this is different" moment. Drag the map, new data appears, no white flash, no tiny loading bar asking you to reconsider your choices.

Browser programming was still a swamp, so libraries came to the rescue: Prototype, MooTools, Dojo, and eventually jQuery. For a while, jQuery basically was frontend development. Write a selector, do a thing, move on with your life.

The lesson changed too: the browser was not just a document viewer. It could participate.

2010: The SPA Shift

Around 2010, participation turned into occupation. The browser stopped helping the application and started becoming the application.

Servers sent JSON. The client handled routing, templates, state, data fetching, validation, and enough JavaScript to make your laptop sound like it was preparing for takeoff. Backbone, Knockout, and AngularJS gave structure to the pile.

This was a real career split. Frontend stopped meaning "the person who knows CSS" and started meaning "the person who owns a full application runtime that happens to live inside Chrome."

The lesson was that moving work to the client buys responsiveness, but it also buys state management, build tooling, cache invalidation, and the sort of bug that only happens after a user clicks Back twice while holding a salad.

2013: Components Became The Unit Of UI

Then React changed the conversation. Not because nobody had ever thought about components before, but because React made a lot of developers think about UI as a tree of reusable pieces instead of a page you manually poked with DOM updates.

Instead of "find this element and change it," the pitch became "describe the UI for this state." That sounds small until your application has more than four screens and a user who insists on doing things in the wrong order, which is to say, a user.

React, Angular, Vue, Svelte, JSX, virtual DOM debates, state libraries, CSS-in-JS, build systems, bundlers, linters, formatters. Frontend became software engineering with worse naming and more tabs open.

The lesson: architecture had reached the interface. UI code was not garnish anymore. It was the meal.

2018: Frameworks Became Platforms

By 2018, the framework was no longer just a library you used to render views. It wanted to own routing, compilation, deployment, data fetching, optimization, image handling, code splitting, server rendering, static generation, and occasionally your sense of proportion.

Next.js is the obvious example, but the broader shift was everywhere. Nuxt, Gatsby, SvelteKit, Remix, Astro. The framework became the place where frontend, backend, build system, and hosting assumptions started shaking hands.

Meanwhile the backend was expanding too. Cloud services, queues, caches, Docker, Kubernetes, serverless, observability, IAM policies. "I write application code" quietly turned into "I also understand enough infrastructure to be dangerous in three consoles."

The lesson: tools were not just helping you build the app. They were deciding what an app was.

2024: Server And Client Recombined

After years of pulling the frontend and backend apart, the industry started putting them back together with a straight face.

Server components, server functions, loaders, actions, edge rendering, islands, partial hydration. The exact terms depend on which framework's docs you are reading and how recently they renamed the feature.

The funny part is the shape. In 2000, PHP queried the database, generated HTML, and sent it to the browser. In 2024, a server component can query the database, generate UI, and send it to the browser. To be fair, the details are very different. Streaming, caching, hydration, edge execution, shared types, and partial rendering all matter.

Still. Come on. It is at least a little funny.

The lesson: software rarely moves in a straight line. It moves in spirals. We reject an old idea, discover the replacement has its own problems, then bring the old idea back wearing better shoes.

2026: AI And Beyond

Now AI is changing the workflow around all of this. Code completion became chat. Chat became agents. Agents became multi-agent workflows. Models can read repositories, write plans, edit code, run tests, and then explain why the bug they introduced was actually a nuanced tradeoff.

This is not just another framework. It changes how developers interact with every framework. Ironically, that makes learning more important, not less.

If implementation gets cheaper, more of the job moves into judgment. What should we build? How should it work? Which architecture makes sense? What are the tradeoffs? Is the generated code correct? Where is the model confidently wrong?

AI can produce code. It cannot remove your responsibility for knowing whether the code belongs there.

The Actual Skill

Look back at those eras and the pattern is obvious. The tool names change faster than the underlying problems. HTTP still matters. Databases still matter. State still matters. Caching, latency, concurrency, debugging, and understanding users still matter, even when the users are doing their best to make that difficult.

That is the real career insurance: understand the durable problems, notice when something is a real shift, and learn it without turning your identity into a sticker on your laptop.

The landscape will change again. Another architecture. Another deployment model. Another abstraction. Another tool that makes today's workflow look like we were banging rocks together. That is not a reason to panic. It is the job.

The developers who last are rarely the ones who knew the most about yesterday's tools. They are the ones who can become a beginner without staying one for very long.

AI and the Rebound Effect

Sean H — Sat, 08 Aug 2026 13:53:22 +0000

Apparently AI was supposed to make developers work less.

That was the idea, anyway. Write code faster. Automate the boring parts. Finish the same feature in half the time. Close the laptop at 2 p.m. and go become the kind of person who owns hiking shoes for reasons other than taking out the trash.

That is not what happened.

A lot of developers are working more with AI, not less. Not because AI is useless. The problem is almost the opposite. AI is useful enough that it makes more work feel worth doing.

There is a name for this kind of thing: the rebound effect.

The Rebound Effect

The rebound effect is what happens when something becomes cheaper or easier, and people respond by doing more of it instead of simply enjoying the savings.

You make cars more fuel efficient, and people drive more. You make lighting cheaper, and people light more buildings, more streets, and more screens. You make code cheaper to produce, and, well, look around.

The washing machine is the easy example. It did make laundry easier. No question. But it did not simply delete laundry from household life. Standards changed. Clothes got washed more often. People owned more clothes. Clean clothes every day became normal instead of fancy.

Historian Ruth Schwartz Cowan wrote about this in More Work for Mother. Labor-saving technology often saves labor on the individual task, then quietly raises the standard for how much of that task everyone is expected to do.

AI looks a lot like that, except the laundry is software and the hamper is Jira.

Why Developers Are Working More

The real difference with AI is that it lowers the activation energy of programming.

Before AI, a lot of ideas died in the parking lot. You would think, "I could build that," and then immediately remember the setup, the docs, the boilerplate, the weird library behavior, the test data, the CSS problem hiding under the couch, and the two hours you were about to lose to some TypeScript error that looks like it was generated by a cursed obelisk.

So you would do the healthy thing and ignore the idea.

Now you can ask an AI to scaffold the project, explain the library, write the first pass, generate the test cases, fix the annoying bug, and summarize the docs you did not want to read. The idea that used to feel like a weekend suddenly feels like something you can try before dinner.

That sounds great, and it is great. But it changes the math.

Instead of eight hours of work becoming four hours of work and four hours of leisure, it becomes eight hours of work with twice as many things attempted.

Or ten hours, because now you are on a roll.

This is where the rebound effect shows up. AI lowers the cost of doing software work, so more software work clears the bar.

The side project becomes reasonable. The refactor becomes reasonable. The docs become reasonable. The "quick" prototype becomes reasonable. The little polish pass becomes reasonable. The feature nobody asked for but you can suddenly imagine shipping by Friday becomes, unfortunately, reasonable.

More Things Become Worth Doing

This is the key shift: AI does not just make existing tasks faster. It changes which tasks feel worth starting.

A task that used to be obviously too much work now sits right on the line. Maybe it is not worth two days. But is it worth forty minutes with an AI assistant? Maybe. And once enough tasks move into that category, your day fills back up.

The TODO list does not shrink. It mutates.

You close one ticket and notice three adjacent improvements. You fix one bug and ask the AI to search for similar bugs. You write one endpoint and decide the client library should probably be updated too. You generate tests, then notice the tests could be better, then notice the code could be easier to test.

This is not laziness. It is not hustle culture either, at least not always. A lot of developers genuinely like building things. AI removes enough friction that the part of your brain that says "eh, tomorrow" gets quieter.

Economists have a related extreme called Jevons paradox. Make something more efficient, and total use can go up instead of down. Steam engines got better at using coal, and coal use increased. Programming tools get better at producing software, and we produce more software.

Companies Will Not Invent the Four-Day Week for You

To be fair, this is not only a personal problem. There is a company version too, and it is not subtle.

If one developer with AI can produce what three developers previously produced, companies are unlikely to say, "Great news. Everyone can work Tuesday and Wednesday and spend the rest of the week making soup."

They are more likely to say, "Great news. Imagine how much software we can ship now."

Then competitors adopt the same tools. Expectations adjust upward. Yesterday's impressive output becomes tomorrow's baseline. The washing machine did not eliminate laundry. It helped make daily clean clothes feel ordinary. AI may do something similar to software.

Leisure Is a Choice, Not an Automatic Dividend

None of this means AI is bad. I am not interested in pretending that writing boilerplate by hand was some kind of character-building exercise. Getting unstuck faster is good. Exploring more ideas is good. Spending less time fixing infuriating bugs is very good.

The issue is what happens after the savings show up.

Technology can create surplus time, but surplus time does not automatically turn into leisure. Usually it gets spent. Sometimes by your employer. Sometimes by the market. Sometimes by your own ambition at 11:30 p.m. when you really should know better.

So if you feel busier with AI than without it, you are not imagining things. AI made you faster, and then your backlog immediately noticed.

The real trick is not learning how to use AI to do more work. Most of us figured that out pretty quickly. The trick is deciding when not to.

The Evolution of a Software Engineer

Sean H — Sat, 11 Jul 2026 00:18:06 +0000

The first year

class HelloWorld
{
public static void main(String args[])
{
// Displays "Hello World!" on the console.
System.out.println("Hello World!");
}
}

The second year

/**
* Hello world class
*
* Used to display the phrase "Hello World" in a console.
*
* @author Sean
*/
class HelloWorld
{
/**
* The phrase to display in the console
*/
public static final string PHRASE = "Hello World!";

/**
* Main method
*
* @param args Command line arguments
* @return void
*/
public static void main(String args[])
{
// Display our phrase in the console.
System.out.println(PHRASE);
}
}

The third year

/**
* Hello world class
*
* Used to display the phrase "Hello World" in a console.
*
* @author Sean
* @license LGPL
* @version 1.2
* @see System.out.println
* @see README
* @todo Create factory methods
* @link https://github.com/sean/helloworld
*/
class HelloWorld
{
/**
* The default phrase to display in the console
*/
public static final string PHRASE = "Hello World!";

/**
* The phrase to display in the console
*/
private string hello_world = null;

/**
* Constructor
*
* @param hw The phrase to display in the console
*/
public HelloWorld(string hw)
{
hello_world = hw;
}

/**
* Display the phrase "Hello World!" in a console
*
* @return void
*/
public void sayPhrase()
{
// Display our phrase in the console.
System.out.println(hello_world);
}

/**
* Main method
*
* @param args Command line arguments
* @return void
*/
public static void main(String args[])
{
HelloWorld hw = new HelloWorld(PHRASE);
try {
        hw.sayPhrase();
} catch (Exception e) {
        // Do nothing!
}
}
}

The fifth year

/**
* Enterprise Hello World class v2.2
*
* Provides an enterprise ready, scalable buisness solution
* for display the phrase "Hello World!" in a console.
*
* IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED
* TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER
* PARTY WHO MAY MODIFY AND/OR REDISTRIVUTE THE LIBRARY AS
* PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING
* ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
* DAMAGES ATRISING OUT OF THE USE OR INABILITY TO USE THE
* LIBRAY (INCLUDING BUT LIMITED TO LOSS OF DATA OR
* DATA BEINT RENDERED INACCURATE OR LOSSES SUSTAINED BY
* YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO
* OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER
* OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGES.
*
* @author Sean
* @license LGPL
* @version 2.2
* @see System.out.println
* @see README
* @see license.txt
* @todo Test of OS compatibility
* @link https://github.com/sean-inc/helloworld
*/
class HelloWorld
{
/**
* The first phrase
*/
public static final string PHRASE_HELLO = "Hello";

/**
* The second phrase
*/
public static final string PHRASE_WORLD = "World";

/**
* The first word in our phrase
*/
private Word hello = null;

/**
* The second word in our phrase
*/
private Word world = null;

/**
* Constructor
*
* @param hello First word to display in the console
* @param world Second word to display in the console
*/
public HelloWorld(Word hello, Word world)
{
this.hello = hello;
this.world = world;
}

/**
* Display the phrase "Hello World!" in a console
*
* @return void
*/
public void sayPhrase()
{
// Display our phrase in the console.
string first  = this.hello.toString();
string second = this.world.toString();
System.out.println(first + " " + second + "!");
}

/**
* Sets the phrase to use for hello
*
* @param h The first phrase
* @return void
*/
public void setHello(string h)
{
this.hello.setWord(h);
}

/**
* Gets the phrase to use for hello
*
* @return Word
*/
public Word getHello()
{
return this.hello;
}

/**
* Sets the phrase to use for world
*
* @param w The second phrase
* @return void
*/
public void setWorld(string w)
{
this.world.setWord(w);
}

/**
* Gets the phrase to use for world
*
* @return Word
*/
public Word getHello()
{
return this.world;
}

/**
* Main method
*
* @param args Command line arguments
* @return void
*/
public static void main(String args[])
{
// Create a new dic so we can display our phrase on the
// command line.
DIC d = DependencyInjectionContainer::factory();
HelloWorld hw = null;

try {
        hw = d.newInstance(HelloWorld.class);
} catch (DICInstanceException e) {
        System.err.println("There was an error creating an instance of HelloWorld.");
        return;
}

try {
        hw.setHello(PHRASE_HELLO);
        hw.setWorld(PHRASE_WORLD);
        hw.sayPhrase();
} catch (IOException e) {
        System.err.println("There was an IO error.");
} catch (ConsoleException e) {
        System.err.println("There was a console error.");
} catch (Exception e) {
        System.err.println("There was an unknown error.");
}
}
}

<beans xmlns="http://www.framework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.framework.org/schema/beans
http://www.framework.org/schema/beans/beans-2.5.xsd
http://www.framework.org/schema/context
http://www.framework.org/schema/context/context-2.5.xsd">
<context:annotation-config />
<bean id="HelloWorldBean" class="com.sean-inc">
<property name="hello" value="Word" />
<property name="world" value="Word" />
</bean>
</beans>

The tenth year

/**
* Used to display the phrase "Hello World!" in a console
*
* @author Sean
* @see README
*/
class HelloWorld
{
public static void main(String args[])
{
System.out.println("Hello World!");
}
}

As software engineers gain experience they turn trivial code into over-documented, over-abstracted enterprise systems, just to come back around to where they started from in the end.

Reprinting from my blog https://headzoo.io/2017/06/18/evolution-of-a-software-engineer.html

Is Programming Art?

Sean H — Sat, 27 Jun 2026 17:25:09 +0000

Christopher Pitt asked a simple question: Can a developer be called a creative?

I am talking about whether systems architects or PHP developers (like me!) can be called a creative, even though we predominantly deal with code, and our grasp of colours, layout and iconography is limited to the unicode characters we appropriate for console and log messages.

To be honest it never crossed my mind that programming was anything but a creative pursuit, and I’m happy to call myself an artist to anyone that will listen, but I understand why civilians (non-programmers) could see things differently.

A girlfriend once told me programming “looks boring” when I suggested learning a bit of JavaScript and HTML, and many years ago I was roommates with a painter, who, on hearing me proclaim my code was artwork, replied with a condescending, “Yeah, uh huh, sure!”

Yes, I get it. To the casual observer it may appear terribly dreary staring at a monitor all day and night, with the steady drone of click, click, click coming from a keyboard, and I understand why a classic artist (writer, painter, musician) may scoff at the idea of programming as an art form. No one is going to look at my finished work in a gallery, and discuss the artist’s soul while sipping expensive wine.

What people don’t see is the explosion of activity happening in my head while I stare at those bright monitors with my bloodshot eyes. I’ve never surfed the waves of Hawaii, but I get an adrenaline rush from conquering problems. I’ve never played a hit single to a crowed of adoring fans — and certainly never had a hot groupie throw their bra at me — but I know the feeling of being taken to a higher conscience level when I get into a groove.

I know passion and excitement, and I know what it’s like to feel drained, exhausted, high, and elated when a project is finished. Most importantly though, I know how nerve-racking it can be to finally give my work to the world. Will people love it or hate it? Will people understand and appreciate the nuance of my work, or will they think it’s boring and stupid?

Make no mistake about it, programming is a creative pursuit, and I am an artist. I may work with a keyboard and IDE instead of a paint brush or guitar, but I have the same passion and dreams as an artist, and I live and die by the acceptance or rejection of my work by fans. My work may never be seen in a Soho art gallery, but it will be seen by millions of people.

Heck, I even occasionally sit back and admire my code while sipping expensive wine.

The Case for Standardizing the Design of Websites

Sean H — Sat, 27 Jun 2026 15:32:28 +0000

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms.

But, I would argue that's a good thing. Software is supposed to feel familiar.

A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue.

Familiarity Is a Feature

Jakob's Law says:

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.

Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu.

When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different.

Different Is Not Automatically Better

There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it.

Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on.

If you are building a portfolio, an art project, a game, an interactive story, or a highly expressive brand experience, originality may be the product. In those cases, the interface itself is part of the message.

But most websites are not that. Most websites are closer to software. They exist to help users do something. And software benefits from conventions. Nobody complains that every desktop app has menus, windows, buttons, scrollbars, keyboard shortcuts, and settings screens. Nobody wants each text editor to invent a new way to save a file. Nobody wants every checkout flow to completely reinvent how payment forms work.

The Early Web Was More Like a Brochure

Part of the reason people expect websites to look different is historical. In the early days of the web, most websites were not applications. A company website was often a digital brochure: a homepage, an about page, a contact page, maybe a product page, maybe some animated graphics. The web was a publishing medium first. It was closer to a magazine rack than an app store.

So companies treated websites like marketing materials. The goal was to express the brand. Be memorable. Look different. That made sense at the time.

But the web changed. Today, websites are often full applications. Banking, email, project management, analytics, design tools, developer tools, ecommerce, healthcare portals, tax software, maps, calendars, document editors, CRMs, dashboards, admin panels, and social platforms all run in the browser.

From a user experience standpoint, these things should not behave like brochures. They should behave like software. And software works best when users can transfer knowledge from one tool to another.

Standardization Helps Users Move Faster

When websites share common design patterns, users get faster. They know where to look. They know what to click. They know what will happen next. They can predict the system. That predictability creates confidence.

This is especially important for functional websites. A developer using an API dashboard does not want to decode an experimental interface. A shopper checking out does not want to hunt for the cart. A patient using a medical portal does not want a creative navigation system. A small business owner using accounting software does not want the invoice editor to be a visual puzzle.

They want clarity. Standard layouts are not lazy. They are respectful. They tell the user, "You already know how this works." That is powerful.

Responsiveness Pushes Designs Toward Similarity

There is another practical reason websites are starting to look alike: responsive design. A modern website has to work on large desktop monitors, laptops, tablets, foldables, and phones. It has to handle different screen widths, input methods, font sizes, accessibility settings, and network conditions.

That naturally pushes designers toward patterns that survive across contexts. A three-column desktop layout becomes a single-column mobile layout. Navigation collapses. Cards stack. Tables become lists. Buttons become full-width. Sidebars move behind menus. Content is broken into modular sections. Interfaces become more grid-based and component-driven.

Once you design for responsiveness, some choices become obvious because they are durable. Cards are popular because they adapt well. Navigation bars are popular because users understand them. Responsive grids are popular because they scale. Reusable components are popular because they keep interfaces consistent across pages and devices.

A wildly unique desktop design may look impressive in a mockup. Then it falls apart on a phone.

Standardization Is Not Boring. It Is Useful.

A lot of complaints about websites looking the same come from people who spend a lot of time looking at websites as objects. Designers look at websites. Developers look at websites. Marketers look at websites. Founders look at competitors' websites. We notice patterns. We get bored. We want something fresh.

But users are not usually studying websites as creative artifacts. They are trying to get something done. For them, sameness can be a relief. Familiarity means less thinking, fewer mistakes, faster decisions, and lower frustration. That is not boring. That is good design.

The web has grown up. Websites are no longer just digital brochures. They are tools, workspaces, stores, dashboards, editors, communication systems, and applications. And applications should be predictable.

So yes, many websites are starting to look the same. Good. That means the web is slowly learning what software has known all along: users do not want every tool to be a new adventure. They want it to work.