JZ Jeff Zych

Play the Right Note

Like many Americans, I started learning guitar back in high school. I began where everyone did – strumming basic chords and melodies and building up my finger strength. I got a little better every day, and could eventually play simple songs.

I kept practicing and getting better and pushed myself to learn advanced techniques. I wanted to know how to play all the notes — every scale, every chord, alternate picking, sweep picking, tapping, and so on. I didn’t want my technical proficiency to limit what I could play.

Over time I built up a repertoire of techniques to use. Even though I could play a lot of technically advanced parts, I didn’t necessarily know how to play the guitar well.

When he was developing as a writer, David Foster Wallace (author of Infinite Jest) had a similar focus on the advanced stuff. In his multi-day interview of the author, Although of Course You End Up Becoming Yourself, interviewer David Lipsky asks Wallace what his younger self would think of his new work, and if he thought things like character were pointless. Wallace responded with:

Not pointless but that they were easy. And that the hard stuff was more, you know, front of the head. It’s never as stark as pointless or not pointless. It’s, you know, what’s interesting, what’s advanced, what’s next? It’s gotta be — right? Not what’s true, but what’s fresh and novel and whatever. It’s very difficult to get out of that.

In his early work, David pushed himself to produce advanced work that would be considered “fresh” and “novel.” Not because that helped him communicate a larger truth to his readers, but because he wanted to push himself as a writer.

I’ve observed this focus on technical mastery in every creative field. Young filmmakers care more about getting the perfect lighting and shooting on film (rather than digital) than they do about story (check out the HBO series Project Greenlight for great examples of this). Digital product designers create slick UIs that look great on Dribbble, but aren’t usable or feasible or valuable. Programmers build technically impressive solutions to problems that don’t exist.

It’s easy to focus on this “hard” stuff because it has a clear path forward. Just practice what you aren’t good at and you’ll improve. And by learning the “hard” stuff, you’ll distinguish yourself from amateurs and beginners. When I was in high school, this is what I thought it meant to “master” the guitar.

As a result, I overlooked the “easy” stuff. The “easy” stuff is knowing when to use advanced techniques, and when to do something simple. It’s using your skills in service of achieving a higher goal – writing a song, communicating a truth to the reader, telling a good story, building something useful for people, etc.

I’ve since learned that to truly master your craft, you need to know the “hard” technical skills, and how to use those skills. So don’t just focus on learning all the notes. Learn when to play the right note, too.


Color Saver

This weekend I built a quick Mac screensaver that displays the current time as a color. The hour is mapped onto the red channel, the minute onto the green channel, and the second onto the blue channel.

I was inspired by What Colour Is It, which converts the current time into a hex value (e.g. 11:02:47 is #110247). But What Colour Is It doesn’t map to every hex value. Its range is limited to #000000 (midnight, AKA black) to #235959 (11:59:59 PM, a darkish blue green), which misses brighter colors closer to white (#FFFFFF). Instead, Color Saver maps the time component onto the full range (0–255) of each color channel.

I experimented with mapping the time components onto hue, saturation, and lightness instead, but that resulted in more ugly colors more often. For example, when seconds represent the color’s lightness, the color will go from completely black to white in the course of a minute, every minute of the day. I found this to be jarring and unpleasant. Mapping onto the RGB channels instead is more calming and mesmerizing.

Download Color Saver from Dropbox. Note: I didn’t code sign the screensaver, so when you double-click to install it you’ll get a warning that it’s from an untrusted source. You’ll have to make an exception in the “Security & Privacy” section of System Preferences to install it.

Feel free to check out the source code on Github.

Tags: projects

Things I Learned in 2015

I learned that writing helps clarify my thoughts. It makes me much more articulate. It forces me to engage with a topic and wrestle it to the ground so that I understand it much more deeply than I did when I started.

I learned that writing is hard. But like design and code and tennis, it’s a skill that can be practiced and learned.

I learned that blogging consistently is hard. Coming up with ideas and pushing them out into the world takes work, and takes practice to form into a habit. I learned that I’d rather focus on quality and writing about what I think is interesting, even if that means I don’t publish as often.

I learned that even when I have a lot of ideas to write about, not all of them are worth working on. I’m okay with letting ideas go rather than trying to force myself to work on them. I’ve learned this is a good litmus test for knowing what’s worth spending my time on. The most interesting topics will naturally drive me to work on them.

I learned that it’s just as much work, often more, to promote your writing, as it is to do the writing itself. I learned what it feels like to have a post at the top of Designer News. And I learned what it feels like when people misinterpret what I was trying to communicate.

Just like writing, I learned that dating takes a lot of time and energy (even when it’s online). I learned that I can’t put in that time and energy unless I’m attracted (both mentally and physically) to a woman. I can’t force it. I learned that even with online dating, or because of it, it will take a lot of dates before finding someone who feels “right.”

I learned that most single people of my generation, both men and women, are frustrated to some degree by dating. Online dating has made it easier than ever to meet people, but the increase in quantity has not increased the quality.

I learned that an abundance of choice — in products to buy, shows to watch, people to date, articles and books to read, etc. — increases the pressure of making the “right” choice. There’s always a nagging question of, “Is there something better?”

But I also learned that perfect is the enemy of done. There is no perfect. I need to continue practicing making a decision and moving on, without stressing about whether or not it was the “best” choice. There will always be a better choice, despite my best efforts.

I learned I enjoy management, more than I expected. Including the people management part (career development, promotions/raises, etc.). I learned transparency, candor, and empathy go a long way towards quelling people’s anxieties, especially amongst organizational change. And especially when delivering “bad” news, or giving critical feedback. This is as true for personal relationships as it is work relationships.

I learned that providing context, the “why,” behind a decision is more important than the decision itself. It helps people understand it, and accept it, even if they don’t agree with it. And it engenders trust.

I learned that I don’t miss designing and coding much since becoming a manager. The bits and pieces I get to do here and there, in and out of work, is usually enough.

I learned that just telling someone a lesson you’ve learned through experience is not likely to change their thoughts or behavior. Experience is the best teacher. This can be painful when you see someone making a mistake you could have prevented, but I’ve learned to accept this. (This is a good lesson to know if I ever have kids 👪 ).

Similarly, I learned that giving people information in an effort to increase their knowledge, or change their behavior, isn’t the most effective way of achieving this goal. It’s much more effective, albeit harder, to ask questions that lead a person to “earn” this knowledge themselves. By getting someone to come to their own conclusions, they’re more likely to internalize and act on that new knowledge. And they can apply the framework for gaining that knowledge to new situations. This is an art as much as it is a skill, and takes practice.

I learned that my top 5 strengths, according to the Clifton StrengthsFinder, are: 1. Learner; 2. Intellection; 3. Achiever; 4. Individualization; and 5. Analytical. Nothing too surprising, but cool to see nonetheless.

I learned that product development is hard, even when a person’s been doing it for a long time. Especially with teams, and as a company grows. I learned that as clueless as I might feel about how to run a team or build products, no one seems to have it completely figured out (even if they’re experienced and, from the outside, seem to know what they’re doing).

I learned that I like having physical books over eBooks. I display them on my shelves, which makes me much more likely to re-engage with a book after I’ve finished reading it. By seeing it, I’ll think about it more, and pick it up and flip through it. I don’t do this when a book is trapped in software. The same is generally true with music and movies, too.

I learned that underlining passages in books helps me focus on the core ideas being communicated, helps me stay engaged, helps me retain the information better, and makes it easy for me to flip through a book later and remember the key parts.

I learned that everything I spend time on has an opportunity cost. So I’m learning to get comfortable focusing on the things I most enjoy (such as writing), and accepting the cost of not doing other things (such as playing guitar).

I learned that with sustained effort over time I could be good at almost anything (art, music, programming, sports, etc.). But as my “opportunity cost” lesson indicates, I can’t be good at everything. I have to choose what to spend time on, and thus what to be good at. And with enough effort, perhaps I’ll even become great at something. 😄

Finally, I learned that I can’t possibly document everything I’ve learned in a year. There were too many lessons, big and small. Here’s looking forward to another year of learning in 2016!

Tags: Things I Learned

Why Designers Should Code

But Shouldn't Push Code to Production

In the 1970s, AT&T commissioned Matthew Carter to design a typeface for their phone book. They wanted a typeface that could fit more characters per line without a loss of legibility, especially at smaller sizes. This would save them money by reducing the number of pages needed to print the book.

Carter knew that phone books are printed on cheap newsprint paper that doesn’t produce high-quality text. He also understood that ink spreads when applied to this cheap paper, especially at smaller sizes, which decreases legibility. All of this posed significant challenges for creating a legible typeface for AT&T’s phone book.

But instead of giving up in desperation, Carter embraced these constraints and designed for them. The resulting typeface, Bell Centennial, maintains legibility by having a tall x-height and large, open bowls. His true masterstroke, however, was designing “ink traps” into the letterforms. Ink traps are small notches in the letter that anticipate the spread of ink on newsprint. When the ink is pressed onto paper, the ink spreads into these traps. The result is a filled in letter that’s easy to read, even at small sizes.

Closeup of Bell Centennial

Closeup of Bell Centennial by Matthew Carter. Source: Wikipedia.

Carter embraced the constraints of the medium and turned them to his advantage. His deep understanding of the printing process allowed him to make this leap.

Like print, the web is a medium with its own constraints. We often forget they’re there, but they are. To display a web page, a browser must download, parse, and render HTML, CSS, and Javascript. This code imposes limits on what web pages can do.

The best designers understand these constraints, and design for them. To gain this understanding, you must know how to code.

But this comes with a caveat: designers shouldn’t write production code. They’re experts in the user experience, not frontend technology. They should be solving customer problems, not trying to write scalable, maintainable, and performant code. That’s a full-time job that requires dedicated professionals.

So learn how to code. Ink traps don’t design themselves.

Update 12/12/15: This article sparked a lot of questions about designers not writing production code on Designer News. I responded to a lot of them and attempted to clarify what I meant by that statement.

In summary, I wasn’t trying to draw a hard and fast line on what designers should do, or what they’re capable of doing skill-wise. Writing production code on occasion is fine. But what I have a problem with is if designers are expected to code everything they design. Those are separate jobs that should be handled by separate people.


Principles of Writing Well

Writing, like design, is a craft that can be practiced and improved. To do so, I’ve been compiling a collection of principles from books and articles. I decided to share them online to crystallize my own understanding of what I’ve learned so far, and to help others who want to improve at the craft of writing as well. I will continue to update the page as I learn more.

So if you want to become a better writer, or are just curious, check out my principles of writing well.

Tags: writing
View all posts »