Designer Eats Engineer | Hacker News Reader

Designer Eats Engineer

medium.com

44 pointsnbashaw49 comments

I'm a designer - by formal education and by thinking style. I graduated with a BA in Art. By trade, however, I'm a developer. I get paid to write, formulate, and conceptualize iOS Apps and how they connect with Android, our web services and designing the experience for the easiest use and most pleasurable use. I've never taken a CS class besides the one all undergraduates take (ala "This is Word and Excel, today we're doing sums").

All of this is besides the point, but hopefully it'll illustrate why I hate arguments from both sides of the fence about visual design vs engineering. Engineers tend to think visual designers can't possibly code/build like the engineers. Because they went to school and put in the time, that this knowledge is somehow inaccessible to designers - and that's the way it should be. Flip the coin over and you have very similar arguments. Designers tend to think engineers will never be able to realize aesthetics in their own work, to intuit the feeling certain colors and ratios of visual elements have with each other that leads to the ill-defined "pleasure."

Both are wrong, very very wrong. All of this knowledge is accessible to everyone - if you work towards it. A designer can learn to intuit which data structures are necessary to build this/that app, thinking about scalability to infinity while maintaining practicality in the small-scale, before writing a line of code, in the same way an engineer can learn WHY aspects of design are beautiful, and how this beauty is relative to the system (aka the painting, or all of the songs of an album) as a whole. These are trainable things. But you just gotta' get out of your comfort zone and preconceived notions about both design and engineering.

I disagree strongly with the author,

Yea I designer can learn how to do dev stuff, is he going to do it efficiently in a work environment? I think not. The author talk about front-end development like it's coming increasingly easy, it's the contrary, it's more complex than it ever was.

Front-end development is not anymore about doing some css, html & creating a poorly written jquery plugins. It's a whole stack now, you got preprocessors to make css more powerful, a whole lot of tools to automate process, and js mvc to the booth & much more advanced javascript code to handle.

Is there exceptions? of course there are, some engineer are incredibly gifted designers and the other way is true, but in general? it's going to stay separate jobs.

Another important point is that the VAST majority of software is not pretty consumer iphone and Rails apps. Some of the products I've worked on have been ugly as sin, but no company truly cares about that vs. the value gained. Imagine two scenarios: 1) A beautiful designed piece of software that increases company revenues by 10%. 2) An ugly (but same ease of use) piece of software that increases company revenues by 10.1%.

Which would you rather use at your company?

Do I think design is important? Sure. But to say that "designers are eating engineers" because it's easier now to make a twiiter/instagram mash up is ignoring the multi million line code bases that account for most of the "valuable" software.

I dunno, as someone that lacks formal education in either field yet is trying to learn them both on my own, it certainly feels like I'm at a disadvantage at times, that I'll never be quite as good as the BSc's and BA's.

I think you're right in that some people can do both. But how good the product is, well, depends a lot on the problem at hand.

I spent 8 years at uni doing both visual arts and IT, majoring in programming. I've spent most of my professional career doing a combination of design and programming and I actually believe that the knowledge you gain from one thing influences the other.

But both fields are massive, and I believe I could spend my entire career being good at either. Or I could spend my career being mediocre are both.

For what it's worth I do a lot of ops work at the moment too, and it's the same kind of thing, but ops + programming is even closer than design + programming. Every good ops guy i've ever met is good at programming, and every good programmer i've ever met is good at ops.

I love the vernacular of the various software development cultures I see.

In particular, the terms "engineer" and "designer" stand out to me.

While software development is generally thought to fall under the 'E' in STEM, it really has little to do with traditional engineering disciplines. (Eg. Building bridges or buildings.) In fact, in other disciplines it takes longer to build the final product than it does to design it, whereas with software, for most projects where the risk of wasting expensive resources is not involved, it's easier to write a prototype than to design your software up front. And yet the word "engineer" is used primarily to refer to a software developer, even though the term doesn't really fit the process of software development.

I can't help but feel that the word "engineer" is less of a descriptive and more like a title, such as "writer" in graffiti. [0]

"designer" is interesting because it assumes that all design work is the same in all contexts. Software is special in regards to design, because it features graphic design challenges which are also industrial design challenges. So while a reader peering in from the outside might be confused by the ambiguous "designer", in reality the term is usually referring to interaction design.

This ambiguity gets especially interesting when you see the conversations that seem unaware of the difference between industrial and graphic design, leaving you guessing if the participants know or not. (Eg. "A lot of designers just want to make something pretty.")

[0]: https://en.wikipedia.org/wiki/Graffiti_glossary

I certainly resonate with this line of reasoning. When working for Intel (putatively as a hardware engineer) I got criticized during a review period for 'sandbagging'[1] with the justification that the assembler I wrote I said would take 3 months (which it did) but I spend two months goofing off and one month writing it. I realized two things, one that hardware engineering had lots of great milestones, and two that software development sounded a lot like 'art' to people who aren't familiar with it.

The salient clue was the Michelangelo quote "Every block of stone has a statue inside it and it is the task of the sculptor to discover it." Where a programmer might say every megabyte of memory has a program inside it and is is the task of the programmer to discover it. There aren't as many really crisp milestones you can say "we are here" and point to the place on the schedule where you are 'n' weeks away from completion.

[1] sandbagging - creating an estimate for the time it will take to do something far in excess of the time it will really take in order to facilitate goofing off while not getting behind in your schedule commitments.

The problem here isn't that programmers aren't like other engineers, it's that a software "design" is closer to what other engineers would call a specification. A better comparison to the finished non-software design is a finished piece of code, because that's the point where both pieces can be turned over to some non-engineer (either a compiler or a factory, say) to be made.

> Engineering is getting easier

Engineering always "gets easier", that's the whole point of engineering. Assuming that people aren't going to climb onto the shoulders of the latest giants to do even more interesting stuff is ridiculous.

How small is the bubble you are living in if you think that the hundreds of years of increased specialization has just reversed itself?

Yes, everyone in the web field should be able to make a reasonable looking CRUD web app these days. That doesn't mean this skillset is some new pinnacle, it means that this is the new minimum, accessible by dilettantes and amateurs. This is great news, it's commonly called "progress".

If all you have are generalists who can do what any high school kid can do these days then I hate to tell you what your competitors with highly skilled specialists are working on; you'll find out when they put you out of business.

Nick Bilton also wrote on this topic today -- it seems shortsighted. This comment [1] sums it up:

"Maeda's observation about user-facing design isn't going to last very long. Mark Weiser's long-predicted age of 'quiet computing' wherein a computing systems know enough about individuals and groups to act automatically on their behalf (and therefore, requiring no user-interaction) is incrementally coming to pass. Such systems are dependent on instrumentation, granular data collection, and high-volume analytics.

...

While design is important right now, its ultimate successor is intelligent invisibility. That profound advance is almost entirely dependent on the hardest core science and engineering."

Take Prismatic [2] for example, one of the more interesting new apps from 2012, one of its primary features is how little user interaction it requires to generate a personalized news feed. Other apps in its category have nice design but require much more user interaction to setup.

"The best interface is no interface."

[1]. http://bits.blogs.nytimes.com/2013/01/13/disruptions-design-...

[2]. http://getprismatic.com/

To be fair, he is clearly talking only in the context of web design and development(engineering).

I don't think he is shortsighted per se, only overreaching with his post title.

Should read as:

"Specialized subset of designers and engineers share skill-base."

OP also misses the other side of the coin: design-lead tools like Bootstrap have made it much easier for engineers to design great looking apps.

It's convergence, not competition.

Ha, good point. Although I think what's happening is slightly more important than "specialized subset of designers and engineers share skill-base". I don't think engineers are changing as much or as quickly as web designers are. Bootstrap works for internal tools but if you want to make something consumer-facing it doesn't even come close to being adequate.

"Bootstrap works for internal tools but if you want to make something consumer-facing it doesn't even come close to being adequate."

Except that it actually is adequate, a lot of the time. Much like your 'designer-as-engineer' code is often adequate.

Same coin, different sides.

Touché :)

> design-lead tools like Bootstrap have made it much easier for engineers to design great looking apps

using a css framework has nothing to do with design, it's an implementation detail. using a preconfigured theme doesn't make it designed (for sure doesn't make it designed well).

//edit: reworded it.

*Well you edited your text to be more specific, so I edited mine :)

Well, I guess plugging Heroku to Stripe has "nothing to do with" engineering as well.

But, for the sake of discussion between rational people, we should bypass excessive pedantry.

EDIT: -- I see the comment above was modified to add the emphasis and ", it's an implementation detail..."

Please don't fixate on the one example provided. It's a tool that greatly aids design. Starting up a Heroku instance with a CMS isn't engineering either, but that's Not The Point.

yeah, I edited it not to be so vague.

me arguing your opinion about programmers <air quote>designing</air quote> <air quote>great looking</air quote> apps is not pedantry nor is it irrational. better tools are there to make you work faster, they don't make you work better.

And me arguing your opinion about designers <air quote>engineering</air quote> <air quote>secure, scalable, easy to maintain</air quote> apps is not pedantry either.

But one side of this argument seems to be blind to the obvious parallels.

> You no longer need a CS degree to build reasonably scalable web-applications.

When did you ever need a CS degree for anything? I pull mine out to show what kind of dumbass i am to have this "toilet trophy" when i spend hours unclusterfucking code written by a guy who poured concrete a month before becoming "software engineer." Oh no wait... he's a "hacker." Aside from companies in SV, nobody gives a shit. Many companies in Midwest hire developers based on how well they fit their team. Degree? What's that?

For quite some time now, the development of software engineering has been making economically viable for some programming tasks to be preformed by Technicians, this is not new. But it is nice to see people starting to accept this.

And this is very, VERY, healthy for software. Technicians are not Engineers (as in, rigorously trained in science and math with a practical focus).

It means that more people can become Technical Programmers, and Designers and Engineers can stop worring about implementation details and focus on innovation and value generation.

PS: Or, both can be good Technicians, besides being Designers or Engineers. As somebody said, a shared skill-base. The problem is thinking that Technician is the only role for the Engineer.

Having good visual taste, and knowing to tell between good and bad design is very important, sometimes more than the ability to create it, and I think this is what distinguishes the "designer" from the "developer".

So I wouldn't say designer eats developer, but developer with visual taste and attention to detail who treats JavaScript as a real language, who knows HTML5 and CSS3, knows what is "responsive" and "Web Font" definitely eats "I don't care of anything happening outside my precious server side code as all the rest is just HTML" kind of developer

"Designer Eats Engineer"

"... I don’t think designers are going to replace most engineers"

Did you the write the title or the conclusion first?

I should have followed that sentence up with "but engineers are shifting towards the back-end as designers increasingly take their place on the front-end".

> easier than ever to learn to build industrial-strength products

Well, ok, it might be "easier than ever", but it is still very hard. Just see how relatively niche applications like github are struggling and how out-of-the-box tools like RoR or Mongo have frequent issues.

I would compare building web apps to driving boats: doing a simple prototype is sailing a dinghy in good weather at sight from the coast. It is easy, but scale it to "industrial-strength" and you are lost in nowhere under heavy storm: you'd better have a better boat, which means a bigger one, those that have more momentum, and then you cannot jibe anymore, you have to do proper by-the-book tacking, which is slower, safer, less cool, old fashioned, and all that.

Recent designers I've met around NYC have been novices, jquery dependents, and people who took a 12 week how to code ruby class and somehow got hired. To me a designer is someone who can make a site look good in photoshop and then hand it off to be implemented/coded. Designers who code, but who are not 'coders' scare the crap out of me and I avoid them like the plague. Web 'apps' today are that, apps, making API calls, binding data, and managing state - along with profiling for speed, memory, and where resources are loaded from. It's just like any other GUI of the last 20 years. Sure there are UI designers, but they typically aren't coding it together, but I guess the short supply of programmers has exacerbated the situation.

It's easy to find examples of novices in any field - to me what's more interesting is looking at what the experts are doing. The folks I'm thinking of are both excellent visual designers and excellent backbone hackers. This is what's new and interesting to me.

Why does a designer who can code scare you? It's a good thing. I'm a designer that works in code and it often makes my relationship with devs a lot smoother. I understand limitations, can reduce dev time significantly, and together, we share strengths producing a wonderful interface.

The design then pass off flow sucks. It puts too much emphasis on ornament and not enough on functionality. As a designer, understanding how it's implemented and why improves your work significantly.

It's not a 'good thing' to deal with piles of legacy spaghetti code with no method to it's madness. Sure if you've been coding UIs for years, I'm sure we'd work fine together. In my experience, coding designers, have not been experienced coders.

I'm not sure what your relationship or proximity to these designers is, but the best thing you can do to cure this is educate. It can be frustrating, sure, but making an effort to teach and explain what's wrong can make all the difference.

Just because someone isn't top of the line doesn't mean they should be dismissed or frowned upon.

Further, if it's something mission critical, just politely ask them if you can work on it to ensure its quality.

Designers that use WYSIWYG means of developing are scary. Those of us that code because it gives us far more control and speeds up development time are not.

Engineers are solving other problems, but engineering did not get easier

Exactly. CRUD web apps with tens of thousands of users are now trivial from a software engineering standpoint. More interesting challenges lie elsewhere.

More interesting to whom? CRUD apps are still capable of creating massive value for users by solving overlooked problems. It's a big deal that designers can now build them without the help of any professional engineers.

More interesting to those of us who take great delight in solving harder problems.

Just because a problem is technically challenging doesn't mean it's overall a more important or harder problem than one that only requires basic CRUD functionality. Airbnb is a great counter-example.

More interesting to some engineers of course!

It's like what MS Access did to databases years ago. People still need databases, it's just the low hanging fruit is covered (poorly) by Access, and then after the badly designer database has been in production for a few years and grown, some sorry DBA/dev gets to charge a crap load to fix it.

Throughout the history of computing, the number of problems to be solved has grown faster than the number of problems solved. It's a safe bet this trend will continue as we enter the age of ubiquitous computing.

I think this black and white view of a "competition" for important is stupid.

The reality is that now we are realizing that we need the 3 sides to be strong;

- UX/UI

- biz/marketing

- Dev

What a pointless article, especially since his conclusion negates pretty much everything he wrote:

> I don't think designers are going to replace most engineers.

In other words, some designers will develop skills to do some web development (but probably won't get a job at Google), just like some engineers can do some graphic design (but probably won't design font page for the next Coca Cola campaign). Nothing new here.

Heresy! Kidding, actually the world definitely needs more of both designers and engineers. Computing power+programmer=problems getting solved, well that's the theory anyways.

I couldn't help but think by reading this that the polymath bar to becoming a renaissance man is being lowered.

There is an important distinction between developer and engineer. Anyone can become a developer, engineering on the other hand requires a bunch of training.

Let me guess, you have an engineering degree and think you have studied more than any developer.

Nope. I'm also not a developer.

I think actually very few web designers came from print, as you can tell by Photoshop as the tool of choice. If they had come from print design, they would have probably used Illustrator or some other vector based tool.

Web designers should be using Illustrator or Fireworks over Photoshop.

Reply on news.ycombinator.com