Posts Tagged: work

Pocket Premium

It’s very rare I write a plug about my day job here, but this deserves a mention: today Pocket unveiled Pocket Premium, a for-pay subscription service that adds permanent library, full-text search and suggested tags to the core (free) Pocket platform. It was a huge effort among the whole team and my web work added significant improvements for all users: a slicker, smarter search, a conversion of the whole site to a smarter blend of Typekit, Picturefill 2 for responsive imagery across our marketing pages and much more.

Working from home

In the last year I’ve worked more from home than I have in all my previous roles combined. It’s a move that comes with both a lot of freedom but also new challenges. Tech writer Matt Gemmell writes about the subject at length in this post. There’s plenty of smart advice that’s worked for me as well in practice, especially sticking to a schedule and scheduling blocks of time for email.

A matter of workflow

Web designer and developer Dan Davies ran a fascinating experiment; he asked twenty three UK-based web developers on their workflow and overall opinions on responsive web design. As you might imagine there’s a lot of repetition, but many answers were insightful, especially those regarding tools used (a handful of which I’ve barely heard of) and pitching RWD fundamentals on clients.

Do you take work for granted or with gratitude?

Smart post by iDoneThis manager Janet Choi analyzing how a few small bits of gratitude can dramatically improve productivity and morale at work. At first reading through how LinkedIn implemented this practice in their meetings felt cheesy: everyone goes around and shares a personal and professional “win”. But then I considered how often I’ve seen meetings turn into negative complaints on how a feature or design isn’t working. Injecting some forced positively up front could open up a nice change of pace.

The real problem behind “Designer Duds”

Fascinating rebuttal to my linked post from designer Mills Baker yesterday, this time from Goran Peuc:

He exposed a good question and a good topic, but exposed it from the wrong angle and with the wrong starting thought, wrong premise to the whole thing.

A premise that designers had a seat at the table to begin with.

Spoiler alert: they didn’t.

Designer duds: losing our seat at the table

Designer Mills Baker:

But for the design community, the issue is larger than anyone’s feelings, or even the success or failure of these apps. I worry about the reckoning to come when Square sells to Apple for less than its investors had hoped, or when Medium shuts down or gets acquired (or pivots to provide something other than an attractive, New Yorker-themed CMS for writers, the poorest people in the first world)…

In order to avoid losing its place atop organizations, design must deliver results. Designers must also accept that if they don’t, they’re not actually designing well.

Why RWD looks like RWD

Web developer and consultant Tim Kadlec:

The more multi-device work you do, the more you discover that the toughest problems to be solved aren’t related to technology. The toughest problems are related to people, process, workflow and politics…

…Transitioning from the traditional waterfall/siloed approach to a fluid process where designers and developers are working more closely together can be a very difficult adjustment. Not only do you have to battle the internal politics involved in such a move, but you have to experiment to find the right comfort level. Until organizations make that transition it’s natural for things to be off-balance a little bit.

Exactly. As I’ve written myself and linked to elsewhere, responsive web design is more than a few tweaks and fixes taken in isolation. It’s a change in workflow that requires buy in from several key players.

Context reports

Author, manager and developer Michael Lopp:

This morning I realized I might have a productive way to twist status reports into a useful exercise. Let’s call them context reports. A status report documents actions both completed and planned. A context report documents the reason why (and to a lesser extent how) you’re completing these actions and I suspect this information is far more useful to everyone involved.

Being in a job where I’m rarely physically present in most meetings, it’s annoying when I see bullet after bullet point of exactly what happened. The why is so much more important.

Your 60-hour work week is not a badge of honour

Designer Jeff Archibald:

If you’re working 60 hours a week, something has broken down organizationally. You are doing two people’s jobs. You aren’t telling your boss you’re overworked (or maybe he/she doesn’t care). You are probably a pinch point, a bottleneck. You are far less productive. You are frantically swimming against the current, just trying to keep your head above water.

These signs? They are not the signs of a healthy business or work environment.

I admittedly had a period much earlier in my career where I started falling into the “macho crazy hours” trap. That productivity was measured in time and late nights in the office. But then you wake up; perhaps a launch doesn’t go according to schedule, or there’s a management shakeup in the office. You start realizing you haven’t seen your significant other much or hung out with friends like you use to. That’s when you realize having a healthy work environment with happy employees working sane hours (with rare exceptions from time to time, but the key word is exceptions) is critical to your well being.

Work hard and show pride in your work, but realize there’s a limit.

Leading designers at Square, Dropbox, and Flipboard on how to land a dream job

Ben Blumenfeld over at Fast Company writes some solid advice, not just for landing a “dream job” but any tech job. What’s standout most is a quite from a design director at Square:

Designers spend so much time creating beautiful work and preparing their portfolio very thoughtfully; they shouldn’t forget the importance of having prepared questions as well–related to our customers, products, team or anything else that shows considered thinking beyond their presentation.

Having interviewed many candidates for developer roles, I find it a bit shocking how many otherwise very prepared, strong candidates have few to any questions that relate to the specific company they are interviewing for. You get the sense the candidate is a talented web developer that has no real passion for your product at all.