Theory: Deceiving children is a losing proposition.
Theory: Designers and engineers should learn each other’s crafts.
Software development is a world of ignorance, segregation and bigotry. I’m talking about prejudice, not of race, gender or religion; but of areas of expertise, specifically those of design and engineering. This is something I’ve learned from first hand experience, working both in the industry and on open source projects for over a decade. I believe that the most effective way to solve this problem is for designers and engineers to learn each other’s crafts, and I’d like to tell you why.
All my life I’ve been passionate about creating things. Christmas presents I remember from my childhood include rubber bands, tape, and a soldering iron. I have always loved the process of creation. How you can turn ideas into something you can play with, something you can use, something you can enjoy.
When I was 16 years old, I tested out of high school and began contracting as a user interface designer for a firm which happened to be run by my neighbor. I really loved working as a designer, but wanted to be able to make my designs do things. I was especially interested in creating games and graphics applications. I enrolled in a programming class at a nearby community college. My time in that classroom convinced me that I would never be a programmer.
After dropping the class, I felt defeated. Maybe I just wasn’t smart enough. But then I considered how I had taught myself how to play the drums and the guitar. I had taught myself how to make films and design graphical user interfaces. Had I simply taken the wrong approach to learning how to program?
A few months later, I sat down with an HTML version of a C++ book and within a few hours I was hooked. Since then I’ve learned more languages, and have a genuine love for programming. Either I suck at college or that teacher was rubbish, regardless, I’m just glad I found my way.
Over time I developed a consulting business and got involved in open source. As a contractor, clients would give me projects ranging from video production to software development, and everything in between. As I expanded my skill set I became more valuable, and my clients were better served. It’s what I love about consulting. It’s what I miss about consulting.
What I don’t love about consulting is how isolated you are. Early in my career I received a lot of mentorship in the area of user interface design. My work in open source provided some mentorship as well. But I felt like something was missing. So I began to look for a “normal” job, for the first time in my life.
I was shocked at how narrow the job descriptions were. After spending so much time broadening my skill set to increase my value, I was forced to reconsider my approach. I applied for all sorts of positions, not yet sure what relatively small field I should box myself into for the next several years. I took a short-term gig working on embedded Linux systems while I continued my search.
After a few interviews I realized that companies were looking for specialists. I considered dividing my resume into several versions, each tailored to a different field. I wondered how trapped I would feel at a job with such a narrow description. I was worried I might pick the wrong field, and terribly miss working in another.
Finally I found a position working for the non-profit organization that runs Wikipedia. It was a small shop, everything was open source, and they seemed to view my broad experience as an asset. Although I was hired as an engineer, I was soon assigned to work on making Wikipedia easier to use, and it seemed that my broad skill set was going to come in handy after all.
What I soon realized however is that even the most open minded organizations are deeply entrenched with prejudice. Because my title was software engineer, for the first time in my career I was no longer a designer. After many years of hard fought battles, I feel I’ve established my place at Wikimedia, and remain involved in both engineering and design. But as long as my title says engineer, it seems that I will always face prejudice.
In my experience, modern society in general, and tech culture in particular, has become obsessed with specialization. It can be seen in the way the way universities teach, companies hire, and open source meritocracies are run.
This commitment to intellectual monogamy is destructive. When we limit ourselves to small focused areas of expertise, we become more territorial. Barriers to entry are erected around specialized fields, made of nomenclature, terminology and litmus tests. These barriers discourage newcomers, and propagate prejudice towards the people on the outside of them.
Intellectual monogamy is also quite ineffective. It narrows the perspective from which all problems are viewed, severely limiting lateral thinking abilities. It also stresses the limits of human communication by focusing so much on dividing that it gets in the way of conquering.
Sadly, when people do take a more distributed approach, they risk becoming known as a “Jack of all trades, master of none”. To be clear, intellectual promiscuity is no better than intellectual monogamy.
Certainly there are some people who achieve significant breadth and depth.
Leonardo Da Vinci is regarded as being a polymath. A polymath is basically someone who has significant knowledge in multiple areas. A true renaissance man, he could also be described as an intellectual polygamist. His deep commitments to both art and science were complimentary and empowering, not a dilution of his potential.
But during the renaissance, things were different. Leon Battista Alberti (1404–1472) said that “a man can do all things if he will.” This concept, known as Renaissance Humanism, boils down to a belief that humans have limitless capacity to develop, and they should develop skills in all areas.
Both intellectual monogamy and promiscuity suffer from the same problem – single dimensionality which leads to linear gains. When we increase both breadth and depth, we can achieve quadratic gains in our total area of expertise.
It begs the question however, whether this is even achievable by most of us. Many believe that the Da Vincis of the world had greater innate talents than others. Innate talent, however, is not even known to be reality or myth. If innate talent does exist, it’s severely overrated. Either way it’s not what it seems.
The notion of talent is quite similar to luck. Both are poorly understood and often given undue credit. The causes of these phenomena can be divided into two categories; internal forces which we can control and external forces we cannot. Louis Pasteur once said, “Chance favors the prepared mind.” In the case of talent, one might say that “Nurture favors the diligent mind.” Open source must be a community dedicated to supporting people in a variety of fields, so that the diligent can best develop the skills needed to accomplish our shared goals.
Open source has been very successful in this way for engineers. The mentorship and support that most projects provide contributors is amazing and has resulted in a surplus of skilled participants set on giving back and sticking around. Is that the experience of a designer? It surely depends on the project. Observationally it appears that in the majority of cases, participants with such ambitions find themselves alone and uninspired. And to be frank, in most cases these designers aren’t prepared for the opportunities being presented to them.
The danger of low expectations
What I’ve learned from my experience contributing to open source projects is that most of my fellow contributors work in the tech industry to make a living. What I’ve learned from working in the tech industry is how unnecessarily divided the fields of design and engineering are made to be. As a result, the two groups have incredibly low expectations of mutual knowledge.
If a designer hands an engineer graphics assets that have been prepared without any consideration given to the medium they are to be realized in, they are a bad designer. Just as a print designer must understand how 4 color process printing works and how to prepare artwork for press, so too must a web designer understand how HTML and CSS work, as well as how to properly optimized graphics for the web.
And to be fair, if an engineer creates a product with a user interface that can not be improved without major code changes, they are a bad engineer. If you are writing a program a human is meant to use, you should be concerned with use cases. Even if you are writing a service or a library, APIs are used by humans, and user experience should be an important factor in everything you do.
What’s dangerous is when we no longer expect such basic knowledge of each other. The funny, or perhaps tragic, thing about expectations, is that people tend to live up to them, but rarely exceed them.
We should expect more out of each other, and not be afraid to be critical of someone not living up to those expectations. If someone can’t take criticism then they aren’t dedicated enough to their craft to be taken seriously anyway. Being willing to fight to maintain high standards doesn’t make you a bad person, it makes you a leader.
A few years ago, at a soulless corporate conference in this Portland, OR, I sat down in an enormous convention center ballroom, excited to attend the only talk about design on the entire schedule. What followed was 45 minutes of bad advice and offensive prejudice. But more concerning than the misguided speaker’s remarks and ironically poorly designed slide deck was how much the audience appeared so comfortable with her dogmatic sentiments and bigoted slurs. The talk was called “How Not to Design Like an Engineer”.
Throughout the talk, two common stereotypes were referred to again and again. Designer and engineer. Like all other stereotypes, they incite prejudice. But just as not all Italians are mobsters, not all designers are impractical, and not all engineers are aesthetically impaired.
As progressive and evolved as many of us may think we are, the truth is that most of us are quite prejudiced in this area. What does it mean to design like an engineer anyway? She went on to advise engineers to do whatever it takes to get a designer involved, and blindly follow their every whim. Given a view of humanity where specialization is the panacea to supposed finite limitations of human capacity, perhaps the speaker wasn’t too far off the mark. But I don’t buy into that view of humanity. None of us should.
It was that day that I realized just how bad things really were and decided to, at least eventually, write this essay. My message is simple. Designers and engineers should learn each other’s craft. Especially in open source. Or, to put it another way, become a designineer.
If designers learn engineering, they will realize the value of open source, free licensing, remixing and reuse. They will become better designers as they move away from proprietary graphics tools and toward prototyping using open formats and standards. Their aptitude for details will bring a valuable motivation for cleanliness and consistency within a codebase.
If engineers learn design skills, they will realize the value of aesthetic experiences. They will become better engineers as they prioritize user experience, whether it be the user of an application, a consumer of an API or an engineer working on the same project with them. Their aptitude for process optimization will bring a fresh perspective on interaction design problems.
Both groups will benefit from a shared vocabulary as they communicate and solve problems together. With a greater understanding of each other, they will have more empathy and develop healthier and more supportive relationships with each other.
When I began work at the Wikimedia Foundation, I didn’t immediately get on well with the development community. I was a new hire, and many of these people had been contributing to this open source project for years. The more knowledge I gained of MediaWiki, the easier it became to work with them, and I eventually became one of them.
Shared knowledge creates a special bond between people. If you’ve ever seen two Arrested Development fans go on for hours quoting lines at each other, you know exactly what I mean. Mutual understanding increases good faith between contributors of a project, and if there’s anything that developers and designers need more of, it’s good faith.
Bike-shedding. It’s an incredible phenomenon where people who otherwise know how to choose their battles will dive in headfirst and spend hours fighting about trivial matters – all based on opinions. Plato once said that “opinion is the medium between knowledge and ignorance.” While engineering is hardly immune to this valueless pastime, it’s especially common in collaborative design.
The solution is always the same however, no matter what the field. Ideas should be tested and backed with data. We should demand such rigor, and subject ourselves to the same standards. And for the record, the bike shed should always be painted green.
I want to come back to something I mentioned before, about barriers to entry. Specialized fields tend to grow these barriers somewhat organically. Specialized vocabulary is part of that barrier. If you’ve ever heard a designer say the word affordance, or an engineer use the word closure, you’ve seen it first hand.
Shared vocabulary is perhaps the most important kind of shared knowledge. Speaking to people in their own language demonstrates a level of respect and recognition of the value of their craft. When we learn another craft, the barriers come crumbling down.
In the project you’re working on now, I want you to think about the ratio of decisions you make on your own and those you make collaboratively. Each decision we make has consequences, some intended, some not. There will always be blind spots that cause unintended consequences. In hindsight we call these decisions mistakes. Collaboration with others is the most common defense against knowledge gaps, but this model breaks down at some point because it depends too much on communication and oversight. The more people involved that have a broad knowledge of the full stack, the fewer mistakes will be made.
Whether you are a ready to learn more about design or engineering, the way to learn a new craft is the same. Be patient. Give yourself projects. Do it your own way.
Patience is important when learning anything. Set aside a real amount of time and use it to explore and experiment. There are free courses from major universities, but research doesn’t have to be structured. If what you are doing doesn’t feel enjoyable, try it a different way. You will eventually strike a nerve and get sucked in, at which point it will feel more like play than work.
Unless you are going to take a class that will provide assignments, you will need come up with them yourself. The best way to go about doing this is to donate your efforts. Burgeoning engineers can release their work under open licenses and build upon existing open source projects. When learning design, you can create things for people who desperately want or need them. Free work for worthy causes gives you motivation to complete the work without the pressure to perform at a professional level. Personal projects done in private are very easy to drop, so if you are going that route you will need to be very disciplined.
I want you to get serious about learning another craft, but I’m not suggesting you do so at the detriment of what makes you awesome. Approaching a new craft should not be an act of abandoning the ones you already know. Sketch out your program on paper before coding, or use Github to store and share design work. When attention to visual detail and knowledge of implementation are combined, your creative process will be set free.
Step out of your comfort zone and get serious about adjacent crafts. It will make you better at what you do, and you may find a passion you never knew was there.
It’s taken for granted
It’s worth your time
- The Lazy Programmer’s Guide to Secure Computing by Marc Stiegler
- jQuery Anti-Patterns for Performance by Paul Irish
- 10 Advanced jQuery performance tuning tips by Jon Raasch
- Learning to code like jQuery codes internally by Paul Irish
- More things to learn from jQuery’s internals by Paul Irish
Theory: If Santa Claus were real, he would be in jail.
Theory: Xbox 360 is the worst game console on the market.
An Xbox 360 is like a pet parakeet; expensive, noisy, fragile and less clever than you’d hoped for. In the tradition of its predecessor, the Xbox 360 is yet another example of Microsoft’s lack of attention to detail, shameful quality control and ignorance in the craft of industrial design. The user interface is clumsy and obnoxious; a literal patchwork of advertisements and poorly conceived menus that warp you to arbitrary locations in a maze-like environment. I reluctantly bought an Xbox 360, despite previous bad experiences with Microsoft hardware and software, because I wanted to play some specific first-person shooter games with my friends online. However, my distrust in Microsoft has only been emboldened by this experience and I’d like to tell you why.
Day 1: My new Xbox 360 Slim arrives at my doorstep. I hook it up to my TV quickly and prepare to be impressed. I touch the power button and am greeted with an abrasive and dissonant chime that makes my ears recoil in defense. The fan spins up and the entire machine begins vibrating such that the table it’s sitting on becomes an amplifier for a low frequency rumble that can be heard in the other room. I grab some foam pieces from the box it came in and construct a platform for it to sit atop hoping to reduce the noise and vibration coming from within the black plastic case that creaks as I pick it up. It seems to help, but I’m starting to feel like I’ve made a bad financial decision. Video appears on the screen, then a complex setup process. After a few hours of slow updates and network problems, it turns out that the built-in WiFi adapter is not compatible with my Airport Extreme. I order a $60 WiFi adapter on Amazon and call it a day.
Day 3: I plug in the WiFi adapter and add some complex configurations to my Apple AirPort Extreme and suddenly Xbox Live begins to function properly. I insert a used copy of Call of Duty: Modern Warfare 3, which I purchased at a local game store earlier that day. The user interface claims it is “Reading” the disc, accompanied by a cacophony of robotic noises. ”Disc Read Error”. After an hour of trying, I call it a night.
Day 4: I return to the game store, return the supposedly damaged used game and purchase a brand new one. Once home, I insert my brand new copy of Call of Duty: Modern Warfare 3. ”Disc Read Error”. I eject the disc, and blow into the disc reader with my mouth as if it were an NES cartage gone bad. Finally, it works, but it’s not clear why. Every game I have still gets these errors every few times I play them.
The software sucks
Complaints about Windows 8′s user interface apply equally, if not more so, to the Xbox. The design dispenses with any logical organization or prioritization of controls in favor of making everything a square tile. Some tiles are larger, but it’s not clear why. Some tiles are advertisements, and assault your ears with unwanted noise when you select them. You can not control the arrangement of the tiles. The tiles are everywhere. The only other user interface layout is the dashboard, which is essentially just a bunch of vertically stacked lists, sometimes with an information panel to the right. This layout is vastly overused, to the point where all the screens look nearly identical. Tasks that should be simple and direct are instead complex and exhausting having been crammed into a series of list screens that inexplicably take a few seconds for each to load. It would appear that a combination of laziness and ignorance in user interface design is the culprit. Why I expected anything else out of Microsoft escapes me.
Did I mention the hardware sucks?
The Xbox 360 Slim is far from slim. While it is smaller than the original Xbox 360, that’s really not saying much. For such a large case you might expect it to contain an integrated power supply. Instead there is an enormous power brick with an inconveniently short cable connecting it to the Xbox using a proprietary connector. While the eject button on the original Xbox 360 was a common point of failure, breaking easily and making it impossible to press, the pendulum has clearly swung too far in the other direction. The new eject button is so sensitive that it’s easy to trip on accident. The front facing USB ports are cleverly hidden behind a spring-loaded door, but the width of the door dictates that they be so far inset that getting a USB plug into one of them correctly involves two hands, a head-mounted flashlight and needle-nose pliers. I of course have to use these ports often because the Microsoft brand rechargeable batteries only last a few hours between charges before the controller begins randomly flashing at me and eventually disconnecting despite the battery gauge in the dashboard claiming it’s 50% full. Using a play-and-charge cable resolves the issue, but then I’m back to a wired controller.
It’s almost worth it
Games like Call of Duty: Modern Warfare 3 are amazing, which takes some of the sting out of the miserable experience of owning an Xbox 360. I’m pretty disappointed with Halo 4 so far, but that’s probably a topic that deserves its own post. The bottom line is that Xbox Live is the redeeming value of the Xbox. It’s the one thing they’ve done mostly right, and I give them respect for that. It’s easy to gripe that it’s too expensive, but its success would suggest that it’s priced appropriately for the market.
If you are considering buying an Xbox 360, I strongly suggest you accept that it will be more expensive and less impressive than you would expect. You should prepare yourself to be disappointed, frustrated and even angry. The lower you set your expectations the happier you will be. Microsoft has failed me, once again, and they will fail you too if you give them the chance. Should you dare to venture down this treacherous path, good luck to you. You will need it.
Motorcycle Engine Size Restrictions
Theory: The only thing more dangerous than letting a 15-1/2 year old American kid ride a powerful motorcycle is to let a 14 year old Italian kid ride any motorcycle.
Walking Distance to Food
Theory: People are more likely to compromise on the quality of food when obtaining it was either virtually effortless or extremely difficult.
Theory: SublimeText is the best GUI text editor in existence.
Using SublimeText is like waking up on Christmas morning. There’s this feeling of constantly being impressed with new toys you never had before, but suddenly feel like you don’t want to live without. I spent ages looking for something that would suit my needs better than Eclipse, only to end up back where I started. But the instant I started using SublimeText, I knew I’d found what I was looking for, and I would love to tell you why.
Why do text editors take so much time to load, switch between and scroll through large files? Aside from editing actual text, these are the key functional aspects of a GUI text editor. By these measures, and a few others as well, SublimeText is stupid fast.
The first thing anyone will notice about full-on IDEs like Eclipse or Netbeans is that they are sluggish and clunky. Most other editors are fairly quick, but not impressively so. True, a few milliseconds here and there don’t appear to add up to much at the end of the day. However, once you get used to the feel of an editor that’s as responsive as an F1 car everything else feels like driving a yacht.
When measured against other editors, it’s sufficiently feature rich. For navigating it’s got folder views, panes and tabs. There’s support for syntax highlighting just about any language you’ve heard of and plenty of good color schemes. The find and replace tools are addictive and unobtrusive. Indentation style is accurately detected and applied on a per-file basis. Print margins, line numbers and indentation guides are rendered in a lightweight way. Finally, SublimeText has a plug-in system and even a package manager, so most of what isn’t supported out of the box can be supported with plug-ins. It’s even compatible with TextMate bundles.
It doesn’t have features you don’t need
There’s a couple of things missing here and there, but they all seem to be features nobody really needs. Features like code outlines are typically failed attempts to solve problems like navigation anyways. It doesn’t integrate a version control system, or use icons in the folder view. Some people may debate the values of integrating these and other features, but I find that life without poor implementations of debatably useful features is better, and I’m confident that you will too.
It has features you didn’t know you needed (but do)
You can place more than one cursor, select more than one contiguous region of text, select vertically, and then combine those multiple selections into a single one, or split a multi-line selection into multiple single line selections. I have found this is especially useful for adding commas to the end of many lines of text at a time. Tasks you would typically employ regular expressions to accomplish are now achievable using an intuitive graphical user interface.
While navigating around a file, you see a zoomed out view of your syntax highlighted code on the right. It’s a mini-map of the entire file, which can be scrolled through by clicking and dragging. This mini-map gives you a feel for where you are in a file like nothing else I’ve ever seen. Interestingly, syntax coloring combined with indentation creates visual patterns in code that make functions and statements easy to identify from a bird’s eye view.
You edit your preferences as JSON files. Press save and they are instantly applied. Maybe this is especially suited to front-end web developers like myself, but any programmer can appreciate that there’s no hood for anything to be under.
Seriously, it feels like this editor is implemented in hardware or something. But speed isn’t just about how fast the program runs on my computer. It’s how fast I can work when I am using it. I personally use a plugin called SublimeLinter, which adds static code analysis hints to code as you type it. This alone has sold many of my colleagues on it enough to give the editor a shot. The speed at which you can accurately write code is something that any editor should aim to increase, and SublimeText does so with ease.
It’s not open source?
Yeah, I know – this sucks doesn’t it. This kept me away for ages, but let us not forget that Linux used to use BitKeeper until the great Git was invented. The deal is, the open source community benefits when awesome open source code is produced quickly. If an editor that costs $60 is the guilty pleasure that helps you be more productive and happy, I suggest you indulge yourself and move on with your life. Furthermore, as a software engineer, I can appreciate what’s been built here, and feel my $60 is well spent on supporting an application that inhales code and exhales awesome.
Give it a try, see for yourself.
For the record, I was not compensated or encouraged in any way to write this by anyone. I use this tool every day and have come to love it. I just want to share the love.