Engineers tend to dread meetings, and for good reason: bad ones can be soul crushing. Not only are bad meetings a waste of everyone’s time, it can make the meeting’s organizers look incompetent. Paradoxically, as engineers grow in their career, meetings grow more important. You attend and organize more of them, and as a senior voice in the room, your words can have an outsized impact.
Meetings get a bad rap. Well run ones are an efficiency multiplier, leaving people energized and productive, and a team more cohesive. The right meeting can even turn around an otherwise doomed project.
One of the easiest ways to improve the quality of your meetings is to prepare for them. Without preparation, you’re fighting an uphill battle against context switching; one minute you’re coding and the next you’re in “meeting mode” without clear direction.
I like design teams built around collaboration and transparency with outsiders, especially engineers. Yet that openness has to be balanced against productivity. Even with formalized designer-engineer connections, I still structure meetings to give designers as much uninterrupted time as possible.
An open structure largely derives from designer/engineer ratios. Across technology, from hot startups to well established brands, designers are almost always heavily outnumbered. And given it’s a fairly young industry, design is often underrepresented in company leadership. Granted, with “design thinking” surging in popularity, that’s changing. But across many companies, it’s still an uphill battle. If you box your design team in, you’ll stack the deck against you.
Capturing and organizing tasks is a highly personal exercise. Some turn to simple tools like pen and paper or a Google Doc. Others prefer complex systems with filtering, contexts, and customization like Omnifocus.
After trying several options, I’ve found a sweet spot between these extremes with Todoist. It provides some structure for work, but remains flexible for whatever flow I’m managing. That said, the basics I outline here should work with most task management systems.
Andy Hunt, one of Agile Manifesto’s original authors, wrote a controversial post recently. He makes several arguments about Agile’s failings, and this one especially resonated with me:
Since agile methods conveniently provide some concrete practices to start with, new teams latch on to those, or part of those, and get stuck there.
I’ve seen this phenomenon firsthand. A team settles on a system as the solution to their productivity problems. They get bogged down in rules and convention, and integrate too quickly. The process stalls and dies. As Hunt argues, without flexibility, the company loses sight of their productivity goals.
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.
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.
Many tech and productivity blogs promote device convergence: with a single smartphone, tablet, or laptop, you’re ready for almost any activity, from gaming to video production. After years of experience with assorted tech gear, I’ve found convergence overrated. It’s the exact opposite – device specialization – that’s a lot more effective.
More concretely, the next time you unlock your phone or sit down in front of your laptop, ask yourself: “what works best here for my needs?” Isolate the apps that you use regularly and that feel natural in context; keep them on your home screen or otherwise easily accessible. Bury the rest in folders knowing full well you’ll probably be faster and more efficient if you wait to perform those activities on another device.
For me, multi-device specialization translates into a set workflow:
My iPhone is used for quick reads of the news (NYTNow), short saved articles (Pocket), catching up on Twitter (Tweetbot) and the occasional quick puzzle game (Threes).
My iPad is for daily scans of news feeds (Mr. Reeder), long reads (again, Pocket) and classic strategy games (Hearthstone, Ticket to Ride) that don’t rely on awkwardly tacked-on control schemes.
My Macbook Air is mostly used for writing, development, and design.
The PS4 is optimized for most of my gaming needs. It’s essential for any game that plays better with traditional controller input. With the comfort and immersion factor of a large screen and sound system, it’s also ideal for play sessions longer than thirty minutes at a time.
There are exceptions to the above (e.g. occasional writing edits on Writer Pro with my iPhone when I’m in the subway), but I’m generally more productive if I delay work until I reach the right device. I also happen to be someone who actively uses all this gear; some may successfully embrace a simpler workflow around a single device. But that’s not for me, and I suspect it isn’t for many others.
Overall, if you’ve found yourself struggling with your device’s size, context, power, or input method for certain activities, try changing your workflow. Move away from convergence and toward multi-device specialization.
I usually give my students and junior developers two pieces of advice: practice your skills and work on strong side projects. Practice is a given, but projects on your own time are a greatly underrated and often forgotten asset.
Strong projects challenge you in at least one way. If you’re focusing on development, maybe you’ll target a framework or an aspect of a programming language you haven’t used yet. If you’re a designer, it could be a new tool or workflow. Remember, the side project needs elements of the familiar to make regular progress so you do not get frustrated and give up, yet remain achievable over time.
Great side projects are a mix of what you can execute quickly but are also somewhat foreign and difficult. It’s a twist on your existing point of view, not one that’s completely coming from left field. One personal example: a refresh of this very site (familiar), but undertaken with a fresh set of responsive design tools and Sass underpinning the styling (foreign).
It’s not an accident I generated my latest project after work hours; the best side projects are almost always outside the day job. Because you’re free from work interference, it can and should move at your own pace. It’s ok to be disorganized too. You don’t even have to finish; the project can flounder and die days, weeks or months down line. As long as you grow from it, it’s still a success. And above all, side projects should be fun.
Shouldn’t a good job nullify the need for side projects? Not exactly. Even with the best jobs, your personal growth goals are never perfectly aligned with the company you work for. And some work, even with the best intentions, can get stuck in a boring, repetitive rut. A strong side project provides an opportunity to escape that.
At the very least, even a so-so side project teaches you something new on your own timetable. And at its best, side projects can establish your “niche” as a designer or developer, a critical way to stand out from your tech peers. They did for me; three years at Gucci, my first formalized web job, pushed me most of the way. However, it’s my Hacker News and Rdio browser extensions on my own time, along with some minimal Tumblr themes, that confirmed my interests as a web developer on the very front of front-end development that often drifts into UX and aesthetic design.
Good jobs push your career far. Good side projects push it further. Make time and a commitment to both.
The new minimal text editor Writer Pro is a worthwhile upgrade over its predecessor, iA Writer. It’s a very polished product with useful features like multiple writing modes that each have their own custom font. There’s also Syntax Control, a tool that highlights select parts of your document for easier revisions and edits.
Admittedly I didn’t expect to have such a positive experience; Writer Pro launched in a crowded field of already well made, minimal text editors. There’s Information Architects’ own iA Writer, which already shares the core Writer Pro feature set. And Byword is an editor with exceptional Markdown support, keyboard shortcuts and exporting options.
Yet Writer Pro distinguishes itself over the competition with subtle yet important design details:
The program fades out the standard Mac toolbar at the document’s top when you begin to type. It’s a small touch that removes another distraction from your writing.
You can enable Syntax Control to highlight just the sentence you’re on. When you scroll through your document, the fade out effect is lifted for easier navigation.
Most competing text editors only enable line or paragraph focus. Line focus feels too constrained on longer sentences while paragraph focus is too loose. Writer Pro’s Syntax Control set to sentence mode is a happy compromise; it highlights the sentence you’re on, regardless of length.
Writer Pro’s formats select Markdown symbols so paragraphs, list items and headlines line up vertically. It makes scanning through and organizing a larger document much easier.
Writer Pro’s font mix of Nitti, Nitti Grotesk and Tiempos is arguably better optimized for writing than options available on competing editors (more on this below.)
Writer Pro doubles down on its existing design strengths with its new writing modes: Note, Write, Edit and Read. You can jump between modes at any time; switching from one writing mode to another changes the font and cursor color to optimize for the task at hand. Content remains unchanged.
Because content is static, Writer Pro’s mode switching can feel superfluous at first; negative reviews on the Mac App Store harp on this a lot. However, after switching between modes for several weeks, the feature has a positive effect on my writing. Note mode utilizes a thin, ultra clean sans serif that pairs well, to quote iA, with the “clean and pristine” nature that notes tend to have. The typography here pushed me in the direction of shorter bullet points over long, rambling sentences.
Write mode retains the monospaced Nitti font from iA Writer. It’s blockier and inherently easier to flow from sentence to sentence, better for uninterrupted writing. Edit and Read modes use Tiempos, a higher contrast serif. This font corrects one of my complaints about the original iA Writer; Nitti was awesome for actual writing, but for editing long form pieces, Nitti’s fluid structure wasn’t ideal (there’s a reason you rarely see idiosyncratic sans-serifs like Nitti used for long reads.) Tiempos is a far better reading and editing choice.
Just to make sure I wasn’t buying into empty typographic fluff, I used Writer Pro’s modes against their suggested intentions for several days. To the program’s credit, writing was more difficult: long form pieces in Note node were written decidedly slower than average. And editing paragraphs in Write node felt awkward with too much space between characters.
Writer Pro’s other significant new feature is Syntax Control. With a click or keyboard shortcut, most of the document fades out, highlighting only the sentence you’re on or just a document’s adjectives, nouns, adverbs, verbs, prepositions or conjunctions. It’s effectively iA Writer’s “focus mode” on steroids.
Unlike writing modes that I use throughout the writing process, I only found Syntax Control useful for final edits and draft revisions on longer pieces. That slightly dulls this feature’s impact but it’s still useful to cut down on verbiage. Those who need absolute focus on what they are writing will likely appreciate Syntax Control on the current sentence (identical to iA Writer’s focus mode.) I rarely use Syntax Control this way but it’s helpful when you’re having trouble putting together a troublesome sentence.
While overall Writer Pro is impressive, there’s a few small issues that need work. The Markdown preview window has poor styling with a font size that’s too small and lines that stretch out as far as you resize the window; it feels like an afterthought feature. It’s also odd iA doesn’t automatically covert Markdown syntax (e.g. headlines, bold text, links) when you switch to Writer Pro’s Read mode. Given that iA already went far enough to make this the one mode with a change in functionality (you can’t edit, the cursor and misspelling highlights are removed) they should go all the way to maximize the reading experience. And, unfortunately, this lack of Markdown syntax conversion extends to PDF exports too. It makes PDF exports useless for Markdown writers; get a copy of Brett Terpstra’s excellent Marked 2 as a workaround for now. Additionally, as a writer who’s often typing away emails and blog posts late at night, Writer Pro could really use a “night mode” with light text on a dark background. It would violate Writer Pro’s general lack of customization, but adding the feature would enhance readability and lower eye strain in dark environments, two big wins.
I’m also seeing performance problems with Writer Pro every so often; the CPU usage suddenly spikes and you’re left with an unresponsive, sluggish program, usually after I have the program active for an extended period. It’s rare but annoying when it happens.
Over the past year I’ve written mostly in Byword on both on iOS and the Mac, with occasional forays into iA Writer when I’m in the right mood. Now, after weeks of heavy Writer Pro usage, it’s my main writing choice on the Mac going forward. That said, with its strict minimalism and higher cost, Writer Pro isn’t for everyone. If it’s your first look at a plain text writer, Byword is a more well rounded, cheaper alternative. Nonetheless, if Writer Pro’s visual mode changes and Syntax Control sound compelling, or if you’re a typographic geek like me, give Writer Pro a try.
After a week of hard work with lots of CSS editing and cross platform testing, version 2.0 of my personal site is now finished and launched. Welcome!
It’s been a long time coming. The last year has seen a dramatic experimentation on my part with blogging and social media with fairly uneven results. I’ve tried regularly flogging Twitter, cropping and posting shots up on Tumblr, even committing myself to a 700 word plus rant here on my personal site, yet nothing seemed to feel fully comfortable.
So for now at least I’m getting back to basics. Here you’ll find a mixture of Daring Fireball-esque link posts that I find interesting; tech, design and film stories predominate. I’ll also occasionally be posting more extended, traditional blog posts, though I’m aiming here more for a happy medium size, probably 500, 600 words tops.
Hopefully you enjoy the layout. It’s an HTML5 based WordPress theme written pretty much from the ground up. It’s simplistic, letting the typography (go FacitWeb!) shine with a lighter, milder color contrast than I’ve used before. It’s also fully responsive, built on a 24 column variant of the Skeleton grid system; that should make for comfortable reading on your iPhone, iPad, Android or other mobile device of choice.
Comments or questions are always appreciated. Enjoy.
Web development is constantly evolving, rewarding those that learn and adapt; developers that cling to older methods do so at their own risk. Yet the industry’s heavy workload and tight deadlines place many in a paradoxical situation: Due to their proven and familiar status, older techniques and programs often stay at the forefront of a developer’s workflow.
So how does a web developer learn and evolve while still making their deadlines? Having been in the industry for nine years, recently shifting into a position where I’ll be mentoring junior developers more often, I’ve been reflecting on that question a lot.