Posts Tagged: work

The tiny designer

Very solid design (with an unusual color palette) to a free 5-week email course. As author Jarrod Drysdale writes:

The Tiny Designer is a course about the big (monumental, even) design that we can make together. Non-designers will learn the important parts of design, so that you can understand what designers do, achieve your goals, and better communicate your ideas. Designers: learn to teach and guide others through your design process so they’ll better appreciate what you do.

I’ve written previously (and given a webinar) about team relationships and how important collaboration is. This course looks like it could share some helpful, related advice.

Building responsive teams

I’m giving a free webinar over at InVision a week from today (6/9) at 3pm EST. It’s all about building responsive teams, teams well equipped for responsive web design and native design on multiple, changing devices. No prerequisites – if you’re a designer, developer, project manager, or practically anyone working in or around a tech team, hopefully you’ll find something of interest. Just register in advance and you’ll be able to stream the video and audio live. (I expect an archive of the talk will be up later as well for those who can’t make it.)

80/20 practitioners make better communicators

Katie Kovalcin, writing for A List Apart:

When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.

To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.

Work is better than talent

Designer Liam Campell, writing on Medium:

I don’t buy the story that you’ve either got a natural knack for design, or you’re totally hopeless. And yet I hear designers describe the programmers they work with as “design blind” with a slimy sense of pity; the insidious implication being that designers are not made, they are born — that some special children are ordained by the stars at birth into the sacred order of designers, and all others are doomed to brutish, unenlightened lives of “design blindness”.

What bullshit.

Designing the hiring process

Michael Owens writes over at Medium about common patterns shared around hiring solid designers. The post gives a lot of feedback (from several different perspectives, many that are contradictory) on some of the most common evaluation methods, including design exercises, interview panels, and portfolio reviews.

Stop telling women what they aren’t capable of

Engineer Kelly Ellis reveals the real fallacy in relying on the “pipeline” argument (that there’s just not enough qualified women available) when it comes to the gender problems the larger tech industry has. As Ellis argues, there’s a larger problem of women leaving the industry early. They can often face a hostile, male-centric culture or dated stereotypes that programming inherently (and falsely) doesn’t match their gender’s “natural qualities.”

Designers, start communicating

Wunderlist designer Timothy Achumba:

As designers it’s our responsibility to create an environment that encourages open communication with developers, as early as possible in the design process as to avoid problems like this. We need to let them into our world, help them understand what we’re trying to achieve and allow them help us to achieve it in the most efficient way. This constant stream of communication should continue right up to the launch of what you’re building. It keeps everyone involved aligned with the vision, it helps to form a strategy best for achieving the goal and creates a friendly, open and honest culture in the workplace.

Words to live by.

Why developers hate being interrupted

The Tomorrow Lab’s Derek Johnson writes one of the smartest pieces I’ve read on why sudden interruptions (or last minute, poorly planned meetings) can wreck such havoc on a developer’s workflow:

Developers don’t wear headphones because we enjoy music more than anyone else, it’s because headphones shut everything out and give us the mental space we need to build a very complicated model…

…If you’re an interrupter and you get a terser response than you might have expected please don’t take it personally. We’re just aware of the model starting to loosen at the more precarious points and are getting frantic about the need to get back at work.

Dueing it wrong

Writer Shawn Blanc on smart custom perspectives in Omnifocus:

In short, you should create your own custom perspective for “Today”. And let that list show you all the tasks which are either Due today or which are Flagged. When you are doing your daily review and scrubbing your list, don’t think about what’s due — because it should already be given a proper due date — instead, just flag the tasks you want to get done that day. Then, go to your Today perspective and now you’ve got a list of items which are both urgent (i.e. due today) and important (i.e. flagged).

Bingo. When I started using Omnifocus, virtually everything had a strict due date, which became maddening after time. When everything is “due”, it’s hard to manage what is really important. Overall, be less aggressive with real due dates unless it’s really due.

“Experienced” front end web developers

What defines an experienced web developer in 2014? Looking back on my own progress, I transitioned from entry level to senior roles and became “experienced”. Yet it was surprising to reflect on what skills and traits led me to that point.

Some experience stems from core programming knowledge: familiarity with HTML, CSS, and JavaScript syntax, along with optimization techniques for each language. And given how fast the web changes, experience can imply some web frameworks mastery. Today, popular examples include MVC frameworks (Angular, Ember), web components (Polymer) and responsive grid patterns (Foundation, Susy).

Programming chops also contribute; practically any position requires a baseline technical aptitude to sustain a team’s momentum. Yet as my career has gone on, I’ve found three traits outside of tech that usually separate the experienced from the entry level: wisdom, communication and “T-shaped” skills.

Wisdom is experience defined by long-term development cycles. It’s working through projects over months or years. For solo, agency and freelance developers, it’s defining a long term relationship with one or more clients for an extended period. Developers with high wisdom levels know how to work with other tech personnel. They quickly assess their team’s strengths, weaknesses, and who’s best to delegate for different aspects of the job. They also give assured estimates and know how to best integrate their tech skills into a larger team.

Communication centers on verbal and written skills. Part of that is back and forth with the rest of the tech team through succinct bug tickets and clear project status reports. And on most front end development projects, tight communication with the designers and project managers is essential. In addition, business staff often notice and gravitate towards developers with strong speaking and presentation skills, regardless of their technical aptitude.

T-shaped skills aren’t directly related to web development yet are helpful for the overall company. Aesthetic design, UX, analytics, marketing and business are common examples. T-shape skills are especially important for front end web developers, as they are often faced with many client-facing micro decisions due to lack of time or definition from other groups. For example, there may be a high fidelity spec for a new page design, but a few elements don’t quite match, so the developer adjusts some spacing and padding. Or a new web app is launching and a developer realizes select user actions aren’t being captured by analytics; he or she makes a quick correction. Many of these details aren’t noticed until well after a product is shipped but can have a cumulative benefit for users.

All three of these attributes have one thing in common: there’s rarely shortcuts. It takes time, earned from months and years of work within a team. When you run through an entire dev project cycle – tech assistance to early design iterations, developing a feature set, fixing QA bugs and launching the product – there’s invaluable knowledge gained that can’t be gleamed from a blog post or weekend workshop. Admittedly, some developers are naturally gifted communicators and are equipped with a T-shaped skill base by the time they reach their first web gig. Yet having worked with a large variety of web developers in my career, that’s rare.

So, some advice to those starting out: it’s ok to take a break from learning the hottest web framework to brush up on your speaking and writing skills. It’s also smart to ask questions and have interests in the rest of your business. And if you get the chance to work with well-respected, senior developers, do so. Be patient and take in everything you can. Experience takes time.