32 comments

  • Koen Bok, over 8 years ago

    "I simply said, “Um… Ok. I guess. If you think so."

    This line. It's terrible to admit, but this is so recognizable, and can change your whole trajectory.

    24 points
  • Daniel De LaneyDaniel De Laney, 8 years ago (edited 8 years ago )

    I started off my career working in code and transitioned into pure design. I still use JavaScript occasionally to make prototypes interactive. Just to stay sharp I guess, or maybe because it feels nice, and I actually enjoy flexing that skill for some reason. But there’s not really a reason for it in my view, and if I didn’t already know it then I certainly wouldn’t go to the considerable trouble of learning it.

    There are some really great tools out there for showing interaction that don’t require coding skills to use—Flinto for Mac, Principle, Pixate, Invision, After Effects, and others. I like the feel of massaging code as much the next guy, but I’m not so enamored with the mystique of monospaced green text on a black background that I’m blind to how comparatively inefficient it is.

    The thing is, code was never a good idea, it’s a hack. It’s not natural and it requires people to behave like computers, rather than computers adapting to us. We’ve had to do it to get here, and I appreciate that. But I look forward to the day that our tools are so good that the code is completely hidden from us, and programming is officially a dead art.

    4 points
    • Thompson GeorgeThompson George, 8 years ago

      "if I didn’t already know it then I certainly wouldn’t go to the considerable trouble of learning it."

      lol. good luck staying relevant in this industry.

      4 points
    • Dan CortesDan Cortes, 8 years ago

      Code is a hack like math is a hack. It's not a normative way of thinking, but with practice comes proficiency and mastery. Technology isn't natural by definition, it has to be discovered and learned.

      Also, the different ways of thinking that software development opens you up to is incredible. I'm surprised anyone would want to hide all that behind a GUI for no real reason other than just to do it.

      15 points
      • Thompson GeorgeThompson George, 8 years ago

        Additionally, a GUI would severely decrease precision & accuracy, which is required for during development.

        1 point
        • Ryan Snowden, 8 years ago

          ... says the film industry, never.

          0 points
          • Thompson GeorgeThompson George, 8 years ago

            This sounds like a point from someone that doesn't code. The filmmaker uses this application so he or she doesn't have to manually code it. What do you think the driving force behind the film makers GUI is? What do you think the video is saved as? There will always be a developer that needs to write the application to help those that can't code.

            Find me a SAAS that can pass form data to two instances of SF, another CRM and send that data via email as a fallback. Code isn't going any where anytime soon. Sorry.

            1 point
      • Daniel De LaneyDaniel De Laney, 8 years ago

        And just like computers have successfully hidden a great deal of math from us, they'll eventually hide a lot of programming from us, if not all. See also: the singularity.

        I worry that this will take unnecessarily long though, because the people best equipped to bring us into to a post-code world, i.e. programmers, actually like code too much to want to do it.

        0 points
        • Jake Lazaroff, 8 years ago

          Have you ever programmed in an assembly language? Moved bits between CPU registers? What about allocating memory in C? I don't think you're being fair to the amount of math computers are already hiding from us.

          It's pretty cushy here in JavaScript-land (or Ruby-land/Python-land/etc), and it's easy to forget that a lot of the nice things we take for granted—like objects and duck typing and garbage collection—didn't always exist, and humans had to deal with these low-level maintenance things instead of just telling the computer what they wanted to happen. Think back just ten years: DOM manipulation involved a lot of complex logic until libraries like jQuery and Prototype made it accessible to everyone.

          In a lot of ways, we're already moving beyond code in the way I think you're envisioning it, too. Apple's toolkit for building iOS apps includes graphical tools for building the interface, where you just drag and drop components the way you want them to appear onscreen. Services like Parse let you build backends without ever writing a line of code. We've actually been down this road with HTML and CSS, too—we had tools like Frontpage and Dreamweaver, but collectively decided that it was better to write our code by hand. We backpedaled away from this code-less future!

          Ultimately, I think, we will move away from code for simple things like building apps. But it'll take time to get there… and there will always be something cooler and more complex that you do need code for.

          2 points
      • Joey Di Nardo, 8 years ago

        It's not a normative way of thinking, but with practice comes proficiency and mastery.Technology isn't natural by definition..

        I disagree. The fact that logic completely dominates our reasoning and our decision making coupled with the phenomenon that all computational expressions can be modeled, in the end, using a chain of logical expressions is one of the biggest reasons we think artificial intelligence may one day be able to fully replicate human reasoning and thought.

        The fact we are such logical beings to begin with is a 'hint' that perhaps they are all computational, but we simply possess such a natural genius as to think it's 'not natural by definition'.

        0 points
    • Colm TuiteColm Tuite, 8 years ago

      This is a romantic idea and in my opinion, a pretty accurate summary of things to come. But I think that day is further off than you're suggesting. My guess is that the current situation will prevail for at least the next 10 years. It may never change fully.

      Like Dan mentioned, math has been around for decades. It is possible that the limitless possibilities code offers us simply cannot be significantly abstracted without diluting their effectiveness.

      1 point
      • Daniel De LaneyDaniel De Laney, 8 years ago

        But I think that day is further off than you're suggesting. My guess is that the current situation will prevail for at least the next 10 years.

        I didn’t actually put forth an estimate, but yours sounds reasonable enough.

        0 points
      • Clay MacTavishClay MacTavish, 8 years ago

        What is the current situation exactly? Amazing advances in browser technology and platform support? The exciting evolution and maturity of JavaScript and many other web languages? The fact that more people understand the nuance?

        0 points
        • Colm TuiteColm Tuite, 8 years ago

          The situtation I'm referring to is the fact that we have millions of potential designers trying to enter the web development world who feel blocked, because the way websites are currently built is so abstract and so unfamiliar. In a lot of cases it's the exact opposite to what most visual people expect.

          I remember feeling that way myself when I was starting out. I persisted and broke through, but countless others don't. So while, as you mentioned, the current situation is a lot better than it was 5 years ago and is improving every day, it's still clearly not optimal.

          0 points
    • Clay MacTavishClay MacTavish, 8 years ago

      So many things wrong with the last few statements.

      0 points
    • account removed, 8 years ago

      As a practicing programmer who's trying to understand design better, I agree wholeheartedly with this. Just like we're seeing great progress and associated flux in design thinking and tooling (esp. prototyping), front-end programming is also undergoing massive churn, and is an area of specialization that can take you down a rabbit hole that is as deep as you want it to be. There is language churn (Elm, ES6, TypeScript, Flow, Coffee..), framework revolution (React, Ember, Angular, Mercury, Om, ..), flux in CSS methodologies (BEM, SMACSS, SUIT, Atomic), and each of these divisions have many other smaller choices to be made like testing frameworks, utility libraries, promise libraries, async, and so forth.

      The point I want to make is that it will take years of practice, attuning to a different way of thinking, and immersing our already limited mental bandwidth to a different field, for either a programmer to become better at design or for a designer to become better at programming. And a lot of this programming churn, for anyone except a professional programmer, is an unproductive use of our lives. We have to keep up in part because of fashion fads, and in part due to the massive entropy inherent in any changing system. But even for a professional programmer, not all of the churn is worthwhile - if there was a way to figure out only those things that matter, those that adds to the essence of our practice, we could simply focus on them, and cut out all the noise. This is unfortunately hard in practice.

      However, for a designer trying to be empowered to be also a maker, which the original post talks about, which is also a worthwhile goal, there are good tradeoffs that can be made - things like a basic understanding of the box model, the CSS2 specs and ability to write HTML to understand DOM flow and source order, can make a huge difference in how a designer approaches the web as a medium. Some Javascript will be gravy on top, I'd recommend React's component model, but at the end of the day, how much of our soul do we devote to all these interesting pursuits - would we find inspiration from the colors of nature, keep our eyes peeled to learn design from the real-world, or would we enjoy small pure functions and lovely abstractions? There is a balance to be struck here, which I think is something unique that each of us have to figure out for ourselves.

      3 points
    • Thompson GeorgeThompson George, 8 years ago

      "but I’m not so enamored with the mystique of monospaced green text on a black background that I’m blind to how comparatively inefficient it is."

      maybe you're just not good at it.

      3 points
  • Jorn van Dijk, over 8 years ago

    Really great read.

    2 points
  • Gabriel LovatoGabriel Lovato, 8 years ago

    "These screenshots you have here are plenty. It’s all we’ve ever done before, so there’s really no need to spend this kind of time on a prototype."

    “Um… Ok. I guess. If you think so.”

    This is the real "lesson" to be taken from this piece. The PM rejected a new way of doing things, because it was different from his usual ways and new methods most often seem like "too much work". And Andrei accepted the PM's rejection, mostly because the PM had the hierarchical authority.

    The fact that 20 years ago it was some proprietary Macromedia code is not important. The scene could happen today, and it wouldn't matter if the prototype was pure HTML/CSS/JS, in Framer with CoffeeScript, or in Pixate or Form or Principle.

    The final part about "designers should learn to code" is too specific, distracts from this actual point, and sends the whole discussion into "design vs. code" clichés.

    1 point
    • M HernandezM Hernandez, 8 years ago

      And Andrei accepted the PM's rejection, mostly because the PM had the hierarchical authority.

      Speaking as a PM today, and having been in the author's shoes before, I just want to point out that over the years I think "hierarchical authority" has been moving toward "do-what-it-takes-to-get-your-job-done".

      I agree, "designers should learn to code" as a statement isn't very fair. The author's point and the whole debate should actually be more like "designers should learn to code because ____". He doesn't say it explicitly (and I think he should)-- learning to code helps build empathy. And maybe one could get away with a career in "this industry" as a designer who doesn't have perfect empathy for the engineers they work with.

      But empathy, not just for the people consuming your work, but also for the people working along with you I would argue, only helps everyone.

      0 points
      • Gabriel LovatoGabriel Lovato, 8 years ago

        Totally agree about the empathy among working peers! That being said the empathy should go both ways, programmers should learn at least about design principles and the "whys" of design so that they don't feel they're wasting their time when polishing interfaces.

        0 points
  • Jim NielsenJim Nielsen, 8 years ago

    I've always sympathized with Tyler Gaw's statements about why he codes:

    Programming is a means to an end. I have ideas and want to see them come to life. I use code to make those ideas reality... I push myself to learn new languages, frameworks, and practices. No language is off limits

    I feel like that's what this guy is saying too. And, for what it's worth, that's how I feel about coding myself. It's a way for me to express ideas I have.

    1 point
  • Samantha S, 8 years ago

    "If there’s any kind of addiction you’ll experience as a designer, I guarantee it’s the rush you’ll get after making something with your own two hands that didn’t exist in the universe until you made it. Getting someone else to make it for you is certainly rewarding, but it’s not nearly the same experience."

    Been ruminating on making the leap for quite some time... Hmmm

    1 point
  • Gajus Kuizinas, over 8 years ago (edited over 8 years ago )

    twenty years [ago] I had pixel perfect mockups [..]

    Well, there weren't many pixels back then. : )

    1 point
  • Arjun PenemetsaArjun Penemetsa, over 8 years ago (edited over 8 years ago )

    Great post! Thoroughly enjoyed it.

    1 point
  • Mike MaiMike Mai, 8 years ago

    The best thing about designing in code is that the overhead is bigger but iterations are fast. Once you designed a style guide in code, making prototypes is easier and faster than creating mockups with Photoshop or Sketch.

    But every designer is different, we should do what works for us. There's no absolute path.

    0 points
  • Dean HaydenDean Hayden, 8 years ago

    Such an insightful read. Has actually made me rethink the 'should designers code' argument. Whilst you could argue that you could spread yourself too thin (skill set wise) I think the positives outweigh the negative.

    From my experience the closer you can get to the real thing, be it a website or app, the better. Sure, it takes time but saves agonising cycles of flats, hand holding and constant explanation.

    0 points
  • Duke CavinskiDuke Cavinski, 8 years ago (edited 8 years ago )

    I used to need to code professionally as a designer, but the field has gotten so complicated that if I were to become really proficient in javascript today, I'd rather just be a javascript developer (with probably better results according to the author's career paradigm.)

    0 points
  • Norm Sheeran, 8 years ago

    Great read!

    0 points