html-man
Five years ago I started work for my current employer. Evaluating those past five years, it's interesting to see how my core job has changed over the years. In my previous articles on the death of one man show development (part 1, part 2) I approached the topic from a rather broad and detached perspective, to make it more concrete this will be a personal evaluation, illustrating the changes I went through and the trajectory that is laid out for me in the coming years.
focus is key
When I started in the web business I simply "made websites". People gave me a design and I made them a working, fully functional website. ASP development, html and css, javascript, SQL queries, you name it. One thing I learned through all that is that when you have to do all these tasks yourself, it's hard not to compromise on quality. I often adapted back-end code to make the implementation of front-end code easier (and the other way around), but working like that doesn't really help the quality of the overall project. If you do everything by yourself, it's just a lot easier to cut corners without anyone noticing.
Working in a team proposes a different dynamic. First of all you have an obligation to the people who come before you, doing a good job of translating their work into your own deliverables. At the same time, there's an obligation to the people that follow you, making sure they are given proper deliverables to work with. To do that you need focus, doing the best job you can within the field that is assigned to you.
When I started at my current employer my focus was html, css and a little javascript (front-end work in general), which was already quite narrow at the time. But that focus shifted even further over the years, to just plain html work. It's not that I don't write css anymore, but that part of my job is slowly fading and it's being assigned to other people now.
becoming the html dude
There are various reasons and explanations for this change in focus, but ultimately it feels like a very natural shift that comes forth of our growing industry rather than from my own growth.
First of all, writing html and css were more related to each other five years ago. Today we can depend on the power of css3 to do a lot of the dirty work for us, but back then writing html was 50% semantic and structural work and 50% getting your code ready for the css. That is slowly changing nowadays, so we can spend more time on semantic and structural relevance in our code. Taking into account styling limitations is becoming less and less of a problem these days.
Another thing that influenced my job a lot these past months is the arrival of html5. New challenges presented themselves, allowing us to write richer html code, but at the same time making the html job a bit more difficult. Fiddling with sections, articles and only 1 heading level took up quite a lot of my time, which could not be spend on getting the hang of the latest css3 evolutions.
A third thing that changed a lot for me was the development of an inhouse tool to automatically construct static web templates. Rather than making static html pages and spending half of my time copying html from page 1 to page 30, I can now focus on writing a single component once, making it flexible enough to incorporate all instances and variations of this component on a whole set of templates. This part in particular will have a big influence on my job in the future as you really learn to write rock-solid, flexible and expandable html code.
siding with the wireframe guys
If you write static html, consistency is a tricky thing to uphold. It's just too easy to copy a particular piece of code and to make slight adaptations to it, according to the needs of the wireframe you're following. But experience taught me that many of these little inconsistencies are just there by accident, the result of actively working on a big set of wireframes and momentarily losing sight of the bigger picture, or simply by failing to see the connection between certain components on a page or site.
Working with instances of master html components brings these little inconsistencies to the surface, taking the job of the html-guy much closer to the people drawing up the wireframes. So while my "old" job started after the visual designs were finalized and continued from there on as "front-end development" (including html, css and javascript), I can now start work from a preliminary set of wireframes, do my html stuff and start consistency discussions a lot quicker.
The way I see it, html and css will keep growing apart from each other in the future. Which is only natural because the html work that needs to be done is more closely related to the job of wireframing a site anyway, while the css work ties in with the visual design part of building a website. This rupture between html and css will probably mean that people doing html and css at the same time will either be forced to take sides, or to jump ship halfway through a project.
conclusion
For smaller projects nothing much will change in the near future I guess, but more and more sizable companies are willing to invest in tailored html-frameworks to role out on all their sites. This goes beyond looking at a few wireframes and writing html for that, but it will become an essential part of our job to deliver solid, flexible and future-proof html components that can be used in a range of circumstances, most of them not defined beforehand.
This is a very interesting challenge that makes the song we've been singing these last 10 years very tangible and real indeed. If html is all about semantics and structure, then a single component could and should be only defined once, to be used across multiple sites and projects.