A Web Master is still a real role. More among smaller businesses who don't have a web team, or bigger businesses that outsource most the technical aspects of their web presence.
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.
"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").
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.
Good job on this list, for decades titles have been really lousy in this industry.
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 actually think 'Architect' is a pretty good term, when used correctly. Someone who plans out the architecture of an app, maybe lays the groundwork, but leaves the actual development to others.
> Web Design: ...Specific skills would be design-tools-of-choice, HTML, CSS, and light JavaScript.
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.
And on the flip side, if you are a freelancer with a title of "Web Designer" then it is expected that you can also build the webpages that you create. Businesses want someone to design & build them a website and if you can only do part of that job then you can only make part of the money they want to pay. I don't know anyone doing web design consulting/freelancing who can't also write HTML and CSS.
I've met a few freelancers that claim to be able to do both, but they tend to fall into either the designer or developer camp; either a good developer that can just about use Photoshop, or a designer that can throw some mark-up together. In each instance they've always classed themselves as "Web Designer and Developer" and never as either.
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 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.
The analogy is the least important part of the post. The argument still stands that a designer designs and a developer develops.
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.
> In each instance they've always classed themselves as "Web Designer and Developer" and never as either.
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.
> 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.
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.
One thing I have noticed that when I've been only doing development for an extended period of time, my design skills go out the window and it takes a while to bring myself back to a level where I consider myself "good" again. The reverse is also true.
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.
On the contrary, the agency I work at now is almost purely a development agency. We usually get freelancers in to handle design, but I will pick up Photoshop whenever I can to do very basic things, such as to mock-up a form change.
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.
> I will pick up Photoshop whenever I can to do very basic things, such as to mock-up a form change.
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.
You're making a number of baseless assumptions about the quality of my job. I'd say my company is more than ideal. In fact, I'd say that we're pretty darn close to having one of the best processes I've seen in an agency or startup.
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.
> You're making a number of baseless assumptions about the quality of my job... We work very closely with designers.
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.
I had written comments for the rest of your points, but then I read your final paragraph.
> 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.
It is well understood in programming circles that the code layout/design is one of the most important aspects of maintainability, and achieving that requires exercising the same parts of the brain that any other design work does.
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.
This is essentially my argument. A lot of people seem to start out gaining skills in design and development, as needed by their job, but as they gain experience they always tend to go into one camp. I know plenty of people that class themselves as both designers and developers, but few at senior-level that would consider themselves just as good with either.
I find it safe to say that if someone classes themselves as a designer, they design. Writing mark-up is not design.
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?
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.
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.
> 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.
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".
Just wait until you try to get a visa using these titles. The government is pretty humourless about "ninjas" and the like, and I've even been questioned about my transition from "Software Engineer" to "Web Developer" before (doing the exact same thing in both).
Interesting question being asked in the comment section I'd like to repeat here. Is it correct to call yourself a (software, web, backend, whatever) engineer without actually holding an university engineering degree?
Why not? If someone hires you to be an engineer and you succeed, then go for it. In the end I think what matters most in what you call yourself is the confidence you have in your skills.
I take your point, but I think it depends on where you work. I used to be a "web developer", I still consider myself that (I don't particularly care what my title is tbh).
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.
Certainly it does. I used to be a Software Engineer. I'm now a Developer. I've got a new job lined up where I'm going to be an R&D Programmer. I'm still the same person (although the work will be slightly different in each case).
I wasn't prescribing either way, I was just answering your question.
The main problem I see with engineering in a web dev context is it isn't really engineering. A lot of times it's more assembling. That isn't as glamorous as "engineering" and to a lot of people I've encountered/worked with, that "engineer" title is important.
I personally don't see it, for the most part, as a true engineering discipline.
Engineering degree in what? Mechanical engineering? Electrical engineering? Architectural engineering? etc. These have nothing to with software either.
Politicians often don't have a university degree related to politics...
The point still stands. Just because you studied it at university does not make you an engineer in the field or necessarily any good at it. We don't need parrots, we need thinkers and sometimes that means drawing on experience from different fields.
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?
No, but being registered with a certification body does for example the IEEE (http://www.ieee.org/). Just for interest sake, would you apply your same logic to surgeons and pilots etc?
Surgeons, sure you need relevant education. But pilots, do you require them to have a degree in flying, or aeronautics? Sure they have to be licensed, but that's different from having a degree in the subject - which is what the original question was.
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.
But that brings us back to the original question, would it be appropriate for a web developer to call himself an engineer. What engineering effort is there in web development?
But I agree with you, talk is cheap, and certifications are meaningless if the person cannot do the job.
Also, there is a growing cadre of people who specialize in data visualizations. What title suits someone who does primarily data visualizations? I also, for example, consider myself a storyteller—though I spend my time coding stories—on the web. Is there such a thing as web storyteller? What's the correct title here?
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.
I will concede that the "snake oil" works in the short term. If your business thrives on the one time short term burst (like the #1 for buy viagra) then sure, it works.
But if your goal is to build a long term sustainable business, then those things won't work, as you point out.
If you're hiring someone to do SEO, they need to not only implement SEO tactics (like you say, URL's, title tags, robots, GWT, etc.), but also create a surrounding SEO program/strategy.
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.
Job titles (in my experience) have been 100% worthless to my day to day. I go in and do what's necessary based on what skills I have. Sometimes that means writing code for the web (html, css, etc.), sometimes that means writing a windows service to run a long running or recurring process, sometimes it means writing stored procedures, and sometimes it means writing a process to automate deployments.
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.
Yeah, that's true. I really enjoy working with a) designers, and b) good IT/devops people. I definitely wasn't trying to suggest there shouldn't be specialization ... but it is frustrating when you run up against no-my-job kind of people.
When writing resumes in the past I've taken lousy job titles and updated them with actual job titles equivalent to the work I was doing -- for example changing "Software Developer" to "Front End Developer" or "Full Stack Developer".
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.
Sounds fair to me. As long as you're not being deceptive about what the job actually entailed, and are trying to describe it more fully, I see no problem with switching job titles - they're just a descriptive label.
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.
I used to hate telling people I was a Web Developer. People would always say, "oh you build websites! I've done that some myself with Front Page!". Basically most of my career I've done traditional business applications. Just happens they have a web interface. So I always just say Software Developer.
It bothers me that the word "designer" has been twisted by the web community to mean only non-engineering design (e.g. design of aesthetic appearance).
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?
In my experience, it's only the web community who has this "look and feel" definition of design.
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:
The difference between a well designed and badly designed circuit can make a huge difference in performance and longevity of product, which is definitely something the end user 'sees'.
A Product Manager is absolutely not similar to a Project Manager. These are two completely different jobs and skill sets.
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.
Like most other job titles involving the web, I think "Product Manager" can mean different things to different companies.
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.
Achieving commercial success often means managing delivery as well, but saying the two roles are equivalent is a mistake.
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.
> Dev Ops: I wish this had a more job-title-y feeling to it. As it stands it sounds like what you would call the whole team of people with this job.
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.
Do any job titles these days warrant the 'Web' prefix? So much software touches the web it's kind of pointless.
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.
> '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.
Why is "Mobile _____" overly specific, but something like "JavaScript Developer" or "SEO Specialist" isn't? Responsive design/developing could definitely fall under "Front End Developer", but I feel like it's as focused a title as some of the other ones.
79 comments
[ 3.3 ms ] story [ 148 ms ] thread_______ Hacker - Cheesy for anything with the possible exception of a job with the specific responsibility of finding security exploits.
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.
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").
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 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".
I use those from time to time, when I'm totally positive the irony be understood correctly.
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.
I personally don't see it, for the most part, as a true engineering discipline.
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.
Jeff doesn't like PHP much.
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.
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.
...whaaat?!
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.
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.
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.