Looking back on looking forward

I was just poking around in the BlackBerry PRIV user guide, in an attempt to figure out what USB-based video out standard it uses, when I noticed that certain PRIV models support wireless charging, using the Qi and PMA standards. I got excited (I’m planning on buying one, eventually, once I feel that I’ve got my money’s worth on the spare battery I bought in the fall [read: its lifetime goes for about as crap as the original]) and checked out whether, for example, IKEA’s wireless chargers support either of those standards. Good news for me, they do. I don't have one yet, but we have a bunch of other IKEA furniture, and at least that way I can get a lamp, or and end-table, with a built-in charger for my phone. Hurray!

And I got to thinking about wireless charging, and this thought occurred to me, “great, I see that Android and BlackBerry have caught up to where Palm was seven motherfucking years ago.” Palm, and by extension, HP, were way ahead of the curve when it comes to mobile computing, and for a very good reason. Wireless charging on the Palm Pre. The OS in that phone had real multitasking from day one, beating Apple to the punch by a year. And Palm beat everybody to the punch with their Palm Pilot. Apple was dicking around on the Newton with full handwriting recognition, Palm had a comparatively minuscule processor, and they nailed it. Given their technology constraints, instead of trying to fit the technology to the ideal, they identified the paradigm (pen-like input instead of keys, because the machine was so physically small) they felt would be the killer app, and found a way to apply that paradigm to a pocket-sized device, and won the market.

They kind of reinvented handwriting with Graffiti, but that also allowed them to create an input mode that didn’t actually require user verification the way that even normal handwriting on the page does (e.g. am I staying within the lines? Is this even legible?). Graffiti allowed the Palm user to keep writing away without moving their hand across the screen, and with a simpler gesture set that was still sufficiently similar to real handwriting to be easy to to learn, but also fit inside the tiny 186 processor they had. They revolutionised computer-supported time organisation, and by God if I didn’t want one for myself the first time I laid eyes on it.

Then BlackBerry (well, Research in Motion at the time) comes along with the original BlackBerry. They did the same thing, figured out how to fill a technology gap (simple email where the person was), made it pocket sized, and ran all the way to the bank with it. And like Palm, with something that the user doesn’t actually have to look at in order to input data.

And thinking about my deep and abiding love for both of these technologies reminded me of why I called my “small business” (which I have never really got around to getting off the ground in any meaningful way) Prophecy Newmedia. The notion was that Prophecy would provide its clients with the right technology for their online presence, not just the flashiest, newest stuff. Flash included—it was a pain in the ass from beginning to end, accessibility was notably awful, and after a weird artist love affair with it, it was relegated to streaming video once CSS and AJAX calls were able to do everything Flash could, until Flash itself got end-of-lifed by the vendor, because HTML5 has replaced it.

While I haven't necessarily picked the winning vendors every time (God rest Palm’s soul, and BlackBerry hasn’t been looking very hot since they shit the bed trying to beat Apple at consumer media devices), I feel like when I see an approach to doing things that works… it works. Handheld computing is something I’ve been a devotee of for probably twenty years. Wireless charging, oh my God yes (because wires suck, just plonk the damn thing down and be done with it). Machine readability of websites was part of why I didn’t like Flash in the first place, and Google’s off and running with it, along with everybody else who does big data crunching.

What’s next? I don’t know yet. But it’s going to be exciting.

Who owns the backlog?

A conversation about bug lifetimes came up in a Slack discussion at work today, and a core question came up, that really summarised the entire tenor of the conversation: who owns the backlog?

The answer, if we’re being honest with ourselves, is everyone. The backlog of work to be done, and the prioritisation of that work, is not the exclusive province of any one member of the team, or any one group within your organisation. Everyone who has a stake in the backlog owns it, jointly.

No, seriously. This is especially true if you work in an organisational structure similar to Spotify’s popular squads model. It’s definitely a much more refreshing take on the division of labour than the fairly typical siloing of The Business, The Developers, and The Testers. Admittedly, even then, there really isn’t much excuse not to own your backlog, but when your work priorities are determined by someone on the other side of the office (if they even work in the same building as you), it’s at least understandable that developers might not have as much say about it as they’d like.

But at the end of the day, if you’re invited to periodic planning and prioritisation sessions, you own the backlog as much as everyone else in the room. Developers aren’t there to just be technical consultants on the projected time to complete a given feature. You’re there to contribute to what gets priority over something else.

This is all abstract and fluffy, I know, so here’s an example from my own life.

In the third quarter of 2015, my squad was charged with implementing a new feature on our mobile apps. As an organisation, we’d tried it once before, in 2010 or 2011, and it was an embarrassing failure, so I suspect that, throughout the business, people were a little shy about trying it again. But we had some new technology in place to support this feature, and we thought we could achieve it in a couple of months, by standing on the shoulders of giants, so to speak.

At the same time, we’ve been trying to commit to dual-track agile, so we’d set an aggressive schedule of in-house user testing sessions with the Android app, to validate our workflows and UI. This user testing is fairly expensive, especially if you miss a date, so we agreed upon certain milestones for each round of testing.

In order to make these milestones, we had to make a number of compromises internally. Lots of stuff where we said, “well, it doesn’t need to be complete for the test, but we need something in this UI element, so we’ll hardcode this thing, and fix it after the test.” The only problem—and you can probably see this coming already—is that we didn’t fix those things promptly after the user test. We continued plowing through new features to make the next test. Like I said, it was an aggressive schedule.

Cut to a month or so later, when those hardcoded elements start causing bugs in the interface. I probably spent a week and a half correcting and compensating for things we considered “acceptable” for the user tests, that if I’d either implemented properly in the first place, or immediately corrected it after that test, would have taken a day. This was obviously really frustrating, and I mentioned that frustration in my end-of-year review. I complained that because we were so focussed on the milestones, at launch, it wasn't properly monitored, and it delayed other work, and said I was disappointed with having to release something retroactively dubbed a “public beta”.

When my manager and I reviewed the year, both his comments and mine, he had one simple question for me that stopped me in my tracks: why didn’t you say something right then? And I didn’t have an answer for him. Because I didn’t say anything at the time it came up. I didn’t open tickets for the defects. I may have mentioned the concessions made, in passing, during standups, and counted on my project manager and product owner to open the tickets.

So why didn’t I say something? Because I was acting like someone else owned the backlog, and my job is just to take work off it. This isn’t true. I could have saved myself, and everyone else, a lot of trouble, by recognising that I own the backlog as much as anybody else. If bugs are languishing in the backlog, then it’s your responsibility, as a member of the team, to bring that up during planning sessions. Your manager will appreciate your taking the lead on reducing technical debt and advocating for improving your code base.

On emotional labour

My awesome wife who's awesome wrote an amazing tweetstorm earlier tonight about the unpaid emotional labour women are socialised to do, and it’s made me pensive about a few things.

First up: I am absolutely guilty of a lot of these things. I hope less so recently than I used to be, but I have enough self-awareness to admit that yes, I have said and done these things. (She promises me it wasn’t directed at me, but that doesn’t mean I’m innocent—and I think I know her well enough to know she’d never subtweet the Hell out of me like that—but I think even that is part of the truckload of unpaid emotional labour that she, as a woman, has been brought up to do) And to be quite honest, if you’re a guy… you’ve done these things too. If you look at me and think to yourself, “well, I don’t think I’m like this,” you almost certainly are like that. Only if you can specifically identify things you do that are not like that… you’re like that.

Because, honestly, guys are socialised to do exactly that. And you even see a lot of it in what jobs in tech are coded as being “inherently” oriented toward men or women. QA and project management, which are both roles that require diligence, attention to minute detail, and an aptitude for predicting someone’s needs before they are aware of it, are coded as and performed by women much more than most other roles in the tech industry. Of tech roles within a tech company, they’re the only positions that I’ve consistently observed having anything close to gender-wise parity.

So why do I think that guys are socialised not to do this work? Because, let’s be honest, it is work. I had an opportunity to fill in for my team’s project manager (who, it’s important to point out, is a woman) late last year, and holy mother of God that job is hard. Like, Nintendo-hard. And at least she’s getting paid for it, but I guarantee she’s been doing this her whole life, because that’s what society’s taught her to do. And I haven’t. Instead, I’ve grown up around a lot of media that’s suggested that one set of gifts (chocolate, teddy bears, and diamonds) will satisfy any woman I may be involved with (here’s a hint: that’s a load of crap), and an escalating and never-ending series of ostensible jokes along the lines of “bitches be cray” when her birthday, or anniversary is forgotten.

And why the hell shouldn’t they be? Seriously, think about it for a minute. The person who you’ve decided to open up to and be most vulnerable with comes home on your birthday, or on the anniversary of the day you got married, and they have no idea what’s happened today, however long ago. They can’t bring it to mind at all.

Wouldn’t you be upset? I would be. I have been.

Long story short, just like math and art, the everyday things that women “just seem to do better than men” are things that they’ve practised, constantly, since they were very young. (Men have, conversely, been raised to ignore those things.) Anything you do every day of your life, for about as long as you can remember… yeah, you’re going to be pretty damn good at. Doesn’t make it easy, just habit. (Professional athletes are a great example of this) If you really want to show some kind of appreciation for the women in your life, and all the things they do for you… do them yourself.