> Respectfully disagree. In my experience, deadlines/budgets come before quality far too often. – @senff
I’ve been involved in that as well. If you don’t care about quality that only shows who you’re dealing with.
I’m not going to hire a bum off the street just because he knows the way around a city. I’m going to hire a professional.
> Unfortunately, I think that’s not necessarily true. Some professionals won’t be able to distinguish a real developer from an amateur. – @hugogiraudel
You have a point. Not all professionals will. But those who are hiring, such as agencies, should!
> Unfortunately, I think that’s not necessarily true. Some professionals won’t be able to distinguish a real developer from an amateur.
THAT gets my +1. :)
Just to clarify: my issue is when people think they know enough about coding (whether it’s designers, or back-end devs), and when they get the chance to actually code in a project — because there is the misconception that they know how to code well. Seriously, this is not an uncommon scenario:
Front end dev (upon seeing tables or position absolute everywhere): “WTF, who did this code! That’s not me?!“
Project manager: “This back-end dev (or designer) did that, you were busy so I let him/her do it, and he had no issue doing it.“
Front end dev: “Ok but it’s really bad practice, I have to fix this.“
Project manager: “Nah, it looks/works good, no need to do any more on it!“
> I’m not going to hire a bum off the street just because he knows the way around a city. I’m going to hire a professional.
But that’s my point. When a designer learns to code (which is good by itself), it doesn’t take much for a PM to recognize him as someone who can do actual code in a project. Maybe a little less good than the senior coder, but good enough to move the project along.
Try to make an average PM understand why using position:absolute; everywhere on the page is bad practice. It’s not always easy, cause they only care about how it looks on screen right now. :)
> Front end dev (upon seeing tables or position absolute everywhere): “WTF, who did this code! That’s not me?!” Project manager: “This back-end dev (or designer) did that, you were busy so I let him/her do it, and he had no issue doing it.” Front end dev: “Ok but it’s really bad practice, I have to fix this.” Project manager: “Nah, it looks/works good, no need to do any more on it!”
And that is my point! The fault lies on the project manager. That was an amateur decision and not a professional one.
Update: But getting back to your point @senff, maybe we don’t need to learn to code but it certainly doesn’t hurt. Understanding it is much more important. Especially for Project Managers from the example above.
> And that is my point! The fault lies on the project manager. That was an amateur decision.
Oh it totally is, yes. But it’s also reality, and pretty common. And because of THAT, I don’t like it when designers get to code in a project. Once again, they should know how to code (the more the better, and indeed, that doesn’t hurt) but they should not be allowed to actually code in a project unless their knowledge of code is up to the standard of coders – but unfortunately this does happen. That’s all I’m saying.
There are some designers that simple don’t like to code, so this tool would be helpful to communicate what they want with developers/clients. Whether you agree or disagree is irrelevant. I think it comes down to personal choice. IMO designer shouldn’t be required to know any code, but it sure would be beneficial. You don’t have to know code to understand limitations of what’s possible. I think it has more to do with the process.
> We are imitators. You could determine what’s possible by just browsing the internet and finding similar solution to what you are trying to accomplish. You do not need to know code, to communicate concept and/or design.
But then that doesn’t stop the person from using tables or inline styling.
I’m not sure if I can get on board with the idea “We are imitators”. I like to think we do a lot more than imitate. If all you’re doing is imitating, where is the innovation and progression? You don’t need to know code to communicate a design or concept, but it certainly needs to be designed in a manor where it can be executed and a designer should know what can and can not be executed….in my opinion at least.
That isn’t what I’m suggesting, just suggesting if you’re constantly imitating, you’re not really improving whether you design or code.
My reasoning for a designer to have an understanding of how a website is coded is just so they can design with those restraints in mind. I’m not saying they need to know how to code a perfectly semantic site, every vendor prefix, ect.
I also think it goes both ways, if you primarily code, I think you should also learn a bit about the design aspect of it as well as not every little design element will be laid out for you on every page and sometimes you’ll have to make design decisions (at least in my experience).
You must be logged in to reply to this topic.