Aug 252020
 

With my final day at Mozilla looming, I’m having to come to terms with the fact that there will be a vast amount of documentation work on MDN that I will not get to finish.

Dammit, really wanted to finish the WebRTC and WebXR documentation. There was stuff left I wanted to get done in WebSockets. There are connections to be made among topic areas that will have to be done by others.

Certainly, I can continue to contribute to MDN, and I’m sure I will from time to time, but I will be far more time-limited, so any additions I make will be task-directed; that is, if I’m doing something on the web and run into an issue with MDN content, I might fix it if time allows.

I’m very proud of the work I did on MDN’s content over the years. There are many things I’d do differently given a time machine… or even just more time.

Alas, it is not to be.

 Posted by at 2:40 PM
Aug 182020
 

By now, most folks have heard about Mozilla’s recent layoff of about 250 of its employees. It’s also fairly well known that the entire MDN Web Docs content team was let go, aside from our direct manager, the eminently-qualified and truly excellent Chris Mills. That, sadly, includes myself.

Yes, after nearly 14½ years writing web developer documentation for MDN, I am moving on to new things. I don’t know yet what those new things are, but the options are plentiful and I’m certain I’ll land somewhere great soon.

Winding down

But it’s weird. I’ve spent over half my career as a technical writer at Mozilla. When I started, we were near the end of documenting Firefox 1.5, whose feature features (sorry) were the exciting new <canvas> element and CSS improvements including CSS columns. A couple of weeks ago, I finished writing my portions of the documentation for Firefox 80, for which I wrote about changes to WebRTC and Web Audio, as well as the Media Source API.

Indeed, in my winding-down days, when I’m no longer assigned specific work to do, I find myself furiously writing as much new material as I can for the WebRTC documentation, because I think it’s important, and there are just enough holes in the docs as it stands to make life frustrating for newcomers to the technology. I won’t be able to fix them all before I’m gone, but I’ll do what I can.

Because that’s how I roll. I love writing developer documentation, especially for technologies for which no documentation yet exists. It’s what I do. Digging into a technology and coding and debugging and re-coding (and cursing and swearing a bit, perhaps) until I have working code that ensures that I understand what I’m going to write about is a blast! Using that code, and what I learned while creating it, to create documentation to help developers avoid at least some of the debugging (and cursing and swearing a bit, perhaps) that I had to go through.

The thrill of creation is only outweighed by the deep-down satisfaction that comes from knowing that what you’ve produced will help others do what they need to do faster, more efficiently, and—possibly most importantly—better.

That’s the dream.

Wrapping up

Anyway, I will miss Mozilla terribly; it was a truly wonderful place to work. I’ll miss working on MDN content every day; it was my life from the day I joined as the sole full-time writer, through the hiring and departure of several other writers, until the end.

First, let me thank the volunteer community of writers, editors, and translators who’ve worked on MDN in the past—and who I hope will continue to do so going forward. We need you more than ever now!

Jean-Luc Picard demonstrates the facepalm

Me, if I’ve forgotten to mention anyone.

Then there are our staff writers, both past and present. Jean-Yves Perrier left the team a long while ago, but he was a fantastic colleague and a great guy. Jérémie Pattonier was a blast to work with and a great asset to our team. Paul Rouget, too, was a great contributor and a great person to work with (until he moved on to engineering roles; then he became a great person to get key information from, because he was so easy to engage with).

Chris Mills, our amazing documentation team manager and fabulous writer in his own right, will be remaining at Mozilla, and hopefully will find ways to make MDN stay on top of the heap. I’m rooting for you, Chris!

Florian Scholz, our content lead and the youngest member of our team (a combination that tells you how amazing he is) was a fantastic contributor from his school days onward, and I was thrilled to have him join our staff. I’m exceptionally proud of his success at MDN.

Janet Swisher, who managed our community as well as writing documentation, may have been the rock of our team. She’s been a steadfast and reliable colleague and a fantastic source of advice and ideas. She kept us on track a lot of times when we could have veered sharply off the rails and over a cliff.

Will Bamberg has never been afraid to take on a big project. From developer tools to browser extensions to designing our new documentation platform, I’ve always been amazed by his focus and his ability to do big things well.

Thank you all for the hard work, the brilliant ideas, and the devotion to making the web better by teaching developers to create better sites. We made the world a little better for everyone in it, and I’m very, very proud of all of us.

Farewell, my friends.

 Posted by at 1:10 PM
Apr 142020
 

First, let’s get the most important part out of the way: I hope you and yours are faring as well as possible during these difficult times. Though much of what’s happening was inescapable, enough mistakes were made that we find ourselves in an essentially generation-defining crisis. This is the time my daughter will point at and tell her kids, “You think you have it rough? Back in my day…”

Please do everything you can to contain the spread of COVID-19. Stay home to the greatest possible extent.Don’t have visitors, or go out visiting others, and if you must interact with other people, stay as far apart as can be managed—at least six feet—and don’t allow your hands or face to come into contact with anything that others have touched. And, of course, wash those hands. A lot.

Surprisingly okay

Generally speaking, I’ve been getting along surprisingly well during all this. I’ve been working primarily from home for over 20 years, and due to my previously-mentioned medical issues, I’ve not been driving for a couple of years now, so I’m mostly at home now, too. So the direct changes to my personal existence are pretty minimal. It mostly comes down to increasing challenges in getting things I want or need, with the much more complicated shopping for my wife (who has always been a total rock star when it comes to compensating for the drop in my contributions to keeping our family running) and the difficulties in getting deliveries of even basic grocery items.

But generally, I keep on keeping on.

My wife is obviously stressed a bit, between having my daughter home all the time and the much-increased demand on her for errands and so forth. She took a couple days to go chill out at a home my in-laws have up in the mountains, because she needed a well-deserved break, but she’s back at it now.

Sophie, my daughter, is stir crazy as all get out. Given that her favorite pastime is lying flopped across her bed texting with her friends, you’d think that she’d be happy as can be, but apparently it’s different when you have basically no choice. She’s got remote learning to do through the school, which is great, but she’s not keeping on top of it well, and her grades are not as good as they should be. She’s at an age where it’s difficult for us to manage her schoolwork, especially since we don’t always know what she needs to be doing.

On top of all that, she misses her friends. Yeah, mostly they interact virtually these days, but the times when they do get together in real life apparently were still key to her well-being.

Life these days would be a fascinating social experiment if not for the horrible human toll it takes…

We’re all fine down here. How are you?

So, my family is okay, for the most part. And my work is going along largely the same as always, other than the understandable slowdown due to just… processing what’s going on in the wider world around me. You can’t go along unaffected by the dreadfulness of it all.

If, like me, you’re soldiering on at home… but, unlike me, doing it for the first time or for the first extended stretch of time, welcome to the family of home working! I hope you’ve adapted well to it. It does take getting used to, especially if you’re someone who either enjoys lots of direct human interaction or finds it necessary for business reasons. There’s not much I can do about the “direct” part there.

But working at home isn’t so bad. Ideally, you already have a home office or den you can work in. If not, do what you can to find a good spot away from the main flow of your household action in which you can sequester yourself to work. Working while family things go on around you is not easy to do, even when you have years of home working experience. Fortunately, it shouldn’t be too hard to adjust to with a little effort.

I could sit here and type out a long post with all the suggestions in the world for how to properly work from home, but here’s the thing: I can’t tell you that. Everyone has their own needs and preferences. Some people need to feel like they’re in the middle of some action to slip into the zone. Other people need silence, with no distractions. Do you need music? Office noises? Standing or sitting? Desk or sofa?

These are decisions that, really, only you can make. I guess I’m left with only three pieces of advice I’m comfortable offering.

First, find what works for you. Experiment. Don’t let anyone dictate how you should work at home, when they aren’t you. If setting up your work space at home to be as close as possible to your desk at work makes you the most comfortable and productive you can be, then that’s your answer. On the other hand, if you find that enveloping yourself in whatever chaos might be going on around you at home is somehow comforting and helps you get things done, then by all means, go with it.

Second, if you feel like the way your household operates conflicts with your typical daily work hours, try talking to your manager or supervisor about amending your work schedule. If you need to take shifts supervising your kids’ remote learning each day, try to work with your employer to arrange to swap out those hours for some other hours during the week. Start work early or work late in order to have that time in the afternoon or morning for your kids. Or put in a few hours on Saturday. Find ways to alter your work schedule to fit in better with working at home.

Third, set up a back channel for chatting with your coworkers. This can be a chat room on your service of choice, or a video channel people can just drop into and out of to chitchat in the kind of way people in an office do over the cubicle walls or when bumping into each other at the coffee machine. This is especially useful if your company already has remote workers you can talk to and get insights and support from. Indeed, odds are good they already have a place for talking about the remote experience at your company.

Flexibility is key when working from home. Ideally, both your home and your work are willing to make adjustments to let you do your best possible work while keeping your home life intact.

Stay home and stay safe

These days, the best thing you can do to slow the spread of COVID-19 until a vaccine can be found is to stay at home. Hopefully with a little effort, patience, and flexibility, you’ll find a comfortable way to do so.

Take care, and stay away from me. I don’t know where you’ve been. ?

 Posted by at 12:19 PM
Aug 062019
 

Picture of an old clockOne of my most dreaded tasks is that of estimating how long tasks will take to complete while doing sprint planning. I have never been good at this, and it has always felt like time stolen away from the pool of hours available to do what I can’t help thinking of as “real work.”

While I’m quite a bit better at the time estimating process than I was a decade ago—and perhaps infinitely better at it than I was 20 years ago—I still find that I, like a lot of the creative and technical professionals I know, dread the process of poring over bug and task lists, project planning documents, and the like in order to estimate how long things will take to do.

This is a particularly frustrating process when dealing with tasks that may be nested, have multiple—often not easily detected ahead of time—dependencies, and may involve working with technologies that aren’t actually as ready for prime time as expected. Add to that the fact that your days are filled with distractions, interruptions, and other tasks you need to deal with, and predicting how long a given project will take can start to feel like a guessing game.

The problem isn’t just one of coming up with the estimates. There’s a more fundamental problem of how to measure time. Do you estimate projects in terms of the number of work hours you’ll invest in them? The number of days or weeks you’ll spend on each task? Or some other method of measuring duration?

Hypothetical ideal days

On the MDN team, we have begun over the past year to use a time unit we call the hypothetical ideal day or simply ideal day. This is a theoretical time unit in which you are able to work, uninterrupted, on a project for an entire 8-hour work day. A given task may take any appropriate number of ideal days to complete, depending on its size and complexity. Some tasks may take less than a single ideal day, or may otherwise require a fractional number of ideal days (like 0.5 ideal days, or 1.25 ideal days).

There are a couple of additional guidelines we try to follow: we generally round to a quarter of a day, and we almost always keep our user stories’ estimates at five ideal days or less, with two or three being preferable. The larger a task is, the more likely it is that it’s really a group of related tasks.

There obviously isn’t actually any such thing as an ideal, uninterrupted day (hence the words “hypothetical” and “theoretical” a couple of paragraphs ago). Even on one’s best day, you have to stop to eat, to stretch, and do do any number of other things that you have to do during a day of work. But that’s the point to the ideal day unit: by building right into the unit the understanding that you’re not explicitly accounting for these interruptions in the time value, you can reinforce the idea that schedules are fragile, and that every time a colleague or your manager (or anyone else) causes you to be distracted from your planned tasks, the schedule will slip.

Ideal days in sprint planning

The goal, then, during sprint planning is to do your best to leave room for those distractions when mapping ideal days to the actual calendar. Our sprints on the MDN team are 12 business days long. When selecting tasks to attempt to accomplish during a sprint, we start by having each team member count up how many of those 12 days they will be available for work. This involves subtracting from that 12-day sprint any PTO days, company or local holidays, substantial meetings, and so forth.

When calculating my available days, I like to subtract a rough number of partial days to account for any appointments that I know I’ll have. We then typically subtract about 20% (or a day or two per sprint, although the actual amount varies from person to person based on how often they tend to get distracted and how quickly they rebound), to allow for distractions and sidetracking, and to cover typical administrative needs. The result is a rough estimate of the number of ideal days we’re available to work during the sprint.

With that in hand, each member of the team can select a group of tasks that can probably be completed during the number of ideal days we estimate they’ll have available during the sprint. But we know going in that these estimates are in terms of ideal days, not actual business days, and that if anything unanticipated happens, the mapping of ideal days to actual days we did won’t match up anymore, causing the work to take longer than anticipated. This understanding is fundamental to how the system works; by going into each sprint knowing that our mapping of ideal days to actual days is subject to external influences beyond our control, we avoid many of the anxieties that come from having rigid or rigid-feeling schedules.

For your consideration

For example, let’s consider a standard 12-business-day MDN sprint which spans my birthday as well as Martin Luther King, Jr. Day, which is a US Federal holiday. During those 12 days, I also have two doctor appointments scheduled which will have me out of the office for roughly half a day total, and I have about a day’s worth of meetings on my schedule as of sprint planning time. Doing the math, then, we find that I have 8.5 days available to work.

Knowing this, I then review the various task lists and find a total of around 8 to 8.5 days worth of work to do. Perhaps a little less if I think the odds are good that more time will be occupied with other things than the calendar suggests. For example, if my daughter is sick, there’s a decent chance I will be too in a few days, so I might take on just a little less work for the sprint.

As the sprint begins, then, I have an estimated 8 ideal days worth of work to do during the 12-day sprint. Because of the “ideal day” system, everyone on the team knows that if there are any additional interruptions—even short ones—the odds of completing everything on the list are reduced. As such, this system not only helps make it easier to estimate how long tasks will take, but also helps to reinforce with colleagues that we need to stay focused as much as possible, in order to finish everything on time.

If I don’t finish everything on the sprint plan by the end of the sprint, we will discuss it briefly during our end-of-sprint review to see if there’s any adjustment we need to make in future planning sessions, but it’s done with the understanding that life happens, and that sometimes delays just can’t be anticipated or avoided.

On the other hand, if I happen to finish before the sprint is over, I have time to get extra work done, so I go back to the task lists, or to my list of things I want to get done that are not on the priority list right now, and work on those things through the end of the sprint. That way, I’m able to continue to be productive regardless of how accurate my time estimates are.

I can work with this

In general, I really like this way of estimating task schedules. It does a much better job of allowing for the way I work than any other system I’ve been asked to work within. It’s not perfect, and the overhead is a little higher than I’d like, but by and large it does a pretty god job. That’s not to say we won’t try another, possibly better, way of handling the planning process in the future

But for now, my work days are as ideal as can be.

 Posted by at 5:04 PM