Job Titles in the Web Industry
css-tricks.com
css-tricks.com
As someone who has been called "one of the world's experts on SEO", let me just say this title and industry is BS.
Here is my expert opinion on SEO: Write good content, make it easy for a human to read, and get other humans to share it with other humans in their network of friends.
I'll admit that there is a very small set of things you can so to help your rankings in search engines: have a descriptive URL, a unique title on each page, a proper robots.txt, a sitemap, basically all the stuff that is called out in the Google Webmaster tools.
Beyond that it is all snake oil. I challenge anyone to show my objective metrics proving any one SEO technique works.
But if your goal is to build a long term sustainable business, then those things won't work, as you point out.
Doing things like keyword research, selecting keywords to target audience segments, measuring the effectiveness of the targeting, etc. is all part of what an SEO should be doing. You're not simply optimizing SERP rankings as much as possible. A good SEO should be able to bring in results and measure that their plan that brings in 10k visitors and results in $10k in revenue is superior to the plan that brings in 100k visitors but only 5k in revenue.
For these reasons, I think it's completely unjust to call SEO work beyond tactical implementation "snake oil". Sure, there are less-than-honest people calling themselves "SEO Specialists/Strategists/Ninjas/Whatever", but if I'm a company hiring an SEO, I expect MEASURED business results in return and scrupulous and honest contractors, employees, and agencies should be able to deliver that.
I've just yet to see anyone show me objective results that show they brought in 10K users for $10K in revenue or anything of the sort.
It's always upset me a little that I've had to communicate with people using this narrow definition of what I do from day to day. And so, I prefer the title Software Engineer because it's not specific to mobile, web, devops, etc.
When I started job hunting a few years back companies (in the UK) were advertising for "Software Engineers". I didn't want to sell myself as subpar so my job titles got rewritten on my CV to help market myself. At some point, the term "web developer" got associated with people just "messing around" with non-serious tech, scripted languages for example were seen as for people just starting out and not serious, whereas any serious "software engineer" would use OOP, design principles and frameworks. This is amongst people I worked with, so by no means a reflection of whole industry.
I wasn't prescribing either way, I was just answering your question.
Politicians often don't have a university degree related to politics...
Software engineering.
I know plenty of software engineers that never went to university, and one of the best dev's a know studied Russian. Undoubtedly mathematics is the underpinning for programming, if someone held that degree would they be any less of an engineer, esp given a lot of work relies heavily on algorithms?
As for being a member of a relevant organisation, I think that comes down to what you are working on. If I had a mission critical* piece of software (used in military, medical, lift mechanism etc) then I would specify that all employees need to have certain minimal credentials. Am I going to be better at my job coding up some websites which just provide some info, probably not.
Anyway, IMO titles are meaningless in this industry, the ability to do the job is far more important.
*subjective, I know.
But I agree with you, talk is cheap, and certifications are meaningless if the person cannot do the job.
What's the opinion on this? Is it considered deceptive if it matches the work that you were doing?
My thought is that it more accurately represents what you were doing for HR filters, since I don't really care about my title on a personal level.
Job titles in software development are mostly invented out of whole cloth anyway as it's such a young and dynamic profession, and many labels are borrowed from other professions solely to lend a patina of authority to the role - developers are not engineers or architects in my opinion except by analogy.
All engineering students must take "design" classes where they learn to design things like bridges, electrical circuits, distribution systems, spacecraft, snowmobiles, software, or boilers. Is that not design?
As such, electrical circuits and the internals of software don't really count. They're hidden from the user.
An electrical engineer who designs an electrical circuit calls that process "circuit design." An aerospace engineer who designs a spacecraft trajectory calls that process "trajectory design." See the Wikipedia article on design:
https://en.wikipedia.org/wiki/Design
You'll see that the web community is living in a language bubble.
Jeff doesn't like PHP much.
I didn't see Technical/Web/Application Architect on the list. It's been very common to add "architect" to the end of a title, even to go as far as to have Application Architects under Sr. Application Architects... I wonder if eventually we'll have "Sr. Principal Application Architects".
I'm curious to see what HN would consider calling an Application/Technical/Product Architect and if there is a better name or more clear description.
I've worked in a startup, and at a few design/web agencies, and I'm yet to see a single "Web Designer" write HTML/CSS, let alone JavaScript. A Web Designer does just that; creates designs for the web. There are some designers that like to write mark-up, but they never class themselves as designers without mentioning that they can handle front-end development too.
I find it safe to say that if someone classes themselves as a designer, they design. Writing mark-up is not design.
One other issue I have is with the prefix "Lead". Senior indicates experience, whereas Lead states that they lead a team. My first full-time job after university was at a start-up and after six months I became the Lead Developer. I was in no way Senior, but the title Lead was correct as I led all development, along with the decisions that came along with it.
Either way, I'd never hire one person to do everything, and no company I've ever worked at, including non-tech companies have ever been ignorant enough to suggest that one person should do everything. A designer designs and a developer develops. I wouldn't expect a plasterer to fit my windows on my house.
I don't think that analogy fits.
A more apt analogy would be "an architect creates the construction documents for his/her designs." I'm an architect and I can also do web design and front-end development (with some light server-side code). Understanding the medium is essential to be a good designer. Html/css informs visual design for the web, just like materiality and structure informs building design. Design thrives on informed constraints--otherwise it's just art.
Some web designers today go straight to code after some sketches.
Some designers do go straight to code, but usually in a prototyping stage and absolutely not as a build for a final website. The original post is about outlining a job title, and anyone that has worked with a half-decent designer will know that there is FAR more to design than simply setting up a PSD or sketching out a structure, using either a prototyping tool or straight in code (using something like Zurb Foundation).
I'd argue that there's far more to understanding the medium, and the constraints of building for the web. Any design agency will run a business through a number of processes to come up with a design that accurately represents them, before ANY design work has been done. UX is a part of this, but there are also many other stages in planning. Some agencies are big on archtypes, some are big on kick-off workshops.
When you take all that stuff into consideration, the analogy isn't so far off. What a lot of professional designers do is very far from mocking up a structure in code or in a PSD.
On the flip side, I know some designers that do create prototypes using something like Foundation, but very few of them would ever want to be trusted with a front-end build for a real project.
I've had independent jobs as a designer (including one that was not related to software at all) and as a developer. Though I do bill myself as a designer and developer because I enjoy both and prefer to have a job that is the mix of both.
> I'd never hire one person to do everything
I think that's fair for a number of reasons, but why not hire two people who are great at both aspects? Then they can collaborate on both sides of the project, which is surely better than having someone who can only design and someone who can only develop.
This is the way I've always found it to be in reality. I too have worked in both areas, and although I am good with Photoshop I've worked with too many good designers to ever want to classify myself as one of them.
> I think that's fair for a number of reasons, but why not hire two people who are great at both aspects? Then they can collaborate on both sides of the project, which is surely better than having someone who can only design and someone who can only develop.
Because I'd want someone who is both a great coder, and someone that knows design inside and out. I'm yet to see a single person that can boast impressive (senior-level) skills in both fields.
Sure, there are plenty of developers that can design a good site, but the best designers do FAR more than this. Their skills lie in the process, rather than the ability to design. In similar vein, a great developer is far more than a code monkey. They have considered opinions on the functionality of a site, they are at home with JavaScript, understand cross-browser constraints, and are expected to work alongside designers to help with the process.
With that, perhaps because of the hostile environment for designer/developers we've created in industry, you are always interacting with people who come from an environment that only fostered one side of their skills? And given that you are hard lined on the separation in your own workplace, you're not going to see them grow in the other direction either.
Where I work, we've actually been encouraging the designers to learn how to program (not just simple markup stuff) and the results have been quite promising. It's really just a matter of practice, I am convinced.
However, I've worked with enough designers to know that even though I can create a design, that I am no designer, and that it would be offensive to a real designers ability for me to compare myself with them. I can cook a mean steak, but I'm no Gordon Ramsey.
I agree entirely that all designers should learn to handle basic code, and vice versa. In fact, any agency I've worked at has worked similarly, and was very keen to get each "side" working collaboratively and learning how the other half lives. It's a necessary part of getting an agency working in the same direction. However, putting a designer in front of an IDE doesn't make them a developer by title.
That's not exactly the kind of environment that fosters improvement on the design side though. In fact, your situation sounds similar to mine right now where the design work I do end up doing is basic things like that and the results usually end up being pretty poor.
Your structure really has to treat design and development as one in the same if you want to see growth on both sides. But those jobs are so rare, people are forced into only one aspect of the job, which produces what you've witnessed. And thus begins the feedback loop.
We work very closely with designers. We're a part of all kick-off meetings, we're involved in all phases, we even sit in during workshops so we understand the process from the client perspective. It is a process that works well in all manners of small business, and most importantly, it works for our clients.
My design work is basic because the task is basic. Why pay for a designers time when I can modify something in 5 minutes? It's basic common sense to do so.
Unless you disagree with my earlier premise that the skills see some atrophy if not used, then you most certainly do not have an environment that fosters designer/developer skills. If you have specialized roles, and you are handing the majority of the design work over to a dedicated designer, then you are left with a developer seeing an emphasis on developing code. I do not have to make any assumptions, that is just basic mathematics.
Jumping into Photoshop every once in a while to help out does not lead to a "senior level designer" as you already attested to yourself. You have to have intense focus on both almost every day if you want to see senior level quality on both sides. It can be done, but the jobs are quite rare, so few people ever have the opportunity to reach that level. It goes without saying that finding such people then becomes a challenge, but not because of it being some fundamental truth.
Programming itself requires design skills, so we know all (good) programmers have what it takes to be good designers by default, they just need an environment to frequently practice those skills in contexts other than the text editor.
> Programming itself requires design skills, so we know all (good) programmers have what it takes to be good designers by default, they just need an environment to frequently practice those skills in contexts other than the text editor.
This is a huge red flag for me. The design skills you are talking about are incomparable to the design skills my comments have referenced.
The most obtuse example is the old Perl one-liner, which is generally void of any real design thought, and can scare away the best programmers just at the first glance. But even code that attempts to be written well can fall short without the developer having some design sensibilities; the same sensibilities that apply to any design medium.
Good code, and therefore maintainable code, brings on a positive emotional response before you even start reading the content within. That's straight up design. The exact same kind of work you do in Photoshop, a piece of paper with a pencil, paint and canvas, etc.
You claimed earlier to not be able to call yourself a designer, so I'm going to assume you do not have the experience outside of the code medium to see the overlap, but that doesn't mean it is not there.
Writing markup absolutely is part of design, just as putting pencil to paper can also form part of a designer's job. I say this as a designer who uses both. It is of course not the most important part of design, but I'd argue it's essential to understand your medium, and on the web HTML and pixels is the medium, just as paper and the four colour process was for a previous generation of designers.
If you work in places where roles are specialised, you won't see anyone crossing the boundaries because they've all been kept in their box by the organisation they work for. That doesn't mean that people don't cross the boundaries elsewhere.
If you'd worked in several startups I'm quite sure you'd find designers who were also proficient in development, and certainly designers who like to produce HTML so that they can control the final styling and tweak it as necessary when it is in production, without having to go through a gatekeeper to do so. I'm not sure why you're so insistent that web designers cannot use HTML? Many designers use HTML to produce their mockups, and also to produce final designs, and some even do some programming too. There are many parallels between designing in code and designing in graphics - both are problem solving at heart.
The site you are writing this on was created by the author of Hackers and Painters after all :)
So you'd expect a designer to be able to write concise mark-up that works on all required browsers, works well on modern mobile devices and writes clean code?
If so, I'd like to meet someone that fits this description.
For the gist of my argument, please read through my other comments on this.
Your argument about workplace is very loaded towards your argument. Agencies are very specialised work places, but you talk about it as if it's a negative thing. Surely, it is essential for such companies to specialise because agencies are expected to work across a wide range of clients, and to have the experience to handle the full digital process?
I've worked in a startup before, a non-technical startup, and even they had the sense to hire a good designer to handle a redesign.
I'm "insistent" that a designer should design because that's their job title. I've never stated that a designer should never touch HTML, only that a designer shouldn't be expected to write HTML to the same level of quality as a front-end developer.
> The site you are writing this on was created by the author of Hackers and Painters after all :)
And how many designers would be happy to put this design on their portfolio?
Yes I would - it's not rocket science, though I'm not really interested in satisfying your demands for internet proof, sorry. If I were hiring a web designer I'd prefer one who was familiar with HTML and used it to design up to final templates over one who didn't, though of course I'm sure there'd be exceptions - there's no need for dogmatism about what makes a good designer.
Specialisation also has drawbacks, and it's quite possible to be a bad specialist, just as it's possible to be a mediocre generalist. That doesn't mean that all generalists are incapable of producing clean HTML or good code, or that good designer means that they don't do development, and they stick to photoshop.
There's a huge difference between being "familiar with HTML" and what I described. It's this difference that can make or break a number of projects, especially when you're working on big budget jobs for clients that require legacy browser compatibility.
> Specialisation also has drawbacks, and it's quite possible to be a bad specialist, just as it's possible to be a mediocre generalist. That doesn't mean that all generalists are incapable of producing clean HTML or good code, or that good designer means that they don't do development, and they stick to photoshop.
It's possible, but they're often the exceptions that prove the rule. Either way, it's a huge stretch to call a developer specialising because they do "development".
While a common misconception, Product managers are charged with knowing the market/users/competition and driving the product to commercial success, as much as a development success.
Project/program managers focus on specific delivery.
Coming from the traditional marketing definition of the role, a product manager is typically the "CEO" of the product and is in charge of aligning the product with the market.
In tech, particularly with smaller companies and startups, the need to wear many hats, and the unique issues with project management in relation to software development, has often times seen the product manager also take on project management duties. This may be a mistake or may be a requirement, depending on the resources of the company, but I largely agree with the structure of having both a product manager and a program manager and not blending the two.
Someone who is a true product manager, can usually pickup project management duties. The inverse is not true. I have seen many times someone with a project management background trying to get into product management without shifting the attitude or thinking the two are one and the same, only to drive developers nuts and fail to deliver good products.
It does, of course, exclude titles that are not specific to the web industry: - CEO - salesperson - HR person - accounting
There is an argument for adding "customer support" to this list, as a person doing customer support for web-based products/services generally need a specific skill-set.
I use those from time to time, when I'm totally positive the irony be understood correctly.
Do we put ____ guru in the same bin as the ninjas?
It would be worth adding data analyst or data scientist, as this is a growing aspect of managing a platform.
That is what we call a whole team of people at my company. Most of the people on the team have the title Build Engineer or Automation Engineer, along with a few System Administrators.
_______ Hacker - Cheesy for anything with the possible exception of a job with the specific responsibility of finding security exploits.
I think you can tack on 'Front End' if you're good with JS, MV*, HTML/CSS.... and 'Back End' if you understand DB concepts & scalability or architecture stuff.
It's been my experience as a front-end developer that you need to understand the entire stack. From the wireframes to the database. Perhaps this is a "full-stack" developer to some, but there's been an increase in the amount of "front-end developer" job postings that require you understand every aspect of the application.
If the user will eventually see that data, then it's the responsibility of the front-end developer, this includes all information stored in the database and the ability to store, manipulate, and create that data.
...whaaat?!
A Web Master generally does upkeep/maintenance of the website, minor modifications/customisations, content updates, maybe some social media stuff. "A little bit of everything but not a lot of any thing".
People sometimes give it a different title these days but I don't see why Web Master isn't still valid.
http://en.wikipedia.org/wiki/Webmaster
"A little bit of everything but not a lot of any thing".
I don't think wearing many hats has to mean you're subpar with a specific hat; just like having hobbies doesn't make you less of a front end developer, neither does having an eye for design or people skills or knowing backend stuff. It's not like everybody who wears just one hat always and automatically masters that subject, that's just a fallacy. To the contrary, we all know that having expertise in wildly varying fields can inform and enhance the creative and analytical processes a great deal. Too little focus is bad, but so is too much focus (or, "specialization is for insects").