DEV Community: Andrew Hedges

The History of Sticky Keys

Andrew Hedges — Fri, 23 Dec 2022 20:48:00 +0000

The cover image for the post shows a screenshot of Windows 11 with the Sticky Keys modal activated. The modal asks, “Do you want to turn on Sticky Keys?”

For a more accessible version of this post, see the original article on the Assistiv Labs website.

Calculus was invented twice, by both Newton and Leibniz. We remember Morse and his eponymous Code, but four other inventors, independently, created a first telegraph. The Wright brothers are popularly known to have flown the first airplane—but at least four others also claim to have flown first.

And in the 1980s, Sticky Keys, the accessibility feature you’ve perhaps inadvertently enabled by pressing the Shift key five times in a row, the tool that today is baked into every PC on the market today, was invented twice, by researchers in Wisconsin and a writer in Tennessee.

A stack of pennies, an oversized keyboard, and developers who couldn’t stop imagining ways to make the world a bit better managed to do just that, in a few lines of code. Sometimes you have to invent the future twice before it sticks.

A virtual stack of pennies

It was the dawn of the personal computing revolution and almost everything was left to be defined. We hadn’t even settled on a single keyboard layout yet.

And here was a team at the University of Wisconsin, already imagining how these early personal computers could help level the playing field and give everyone the same capabilities, especially those with disabilities.

The original Autocom device, via the Trace Center

It all started in 1971, when undergraduate engineering student Gregg Vanderheiden was recruited to help find a way to help a friend with cerebral palsy communicate. Six months later, by hacking a device together from military surplus and donated parts, Vanderheiden and team had invented the Autocom, which let disabled students point to letters on a board to type words on a TV screen.

A National Science Foundation grant later, and the Trace Center was born at the University of Wisconsin (more recently moved to the University of Maryland), started by Vanderheiden and fellow classmates to “capitalize on the potential that technologies hold for people experiencing barriers due to disability.” Which, by the time the 1980s rolled around, meant making PCs better for everyone.

Imagine, wrote Gregg Vanderheiden in a 1982 BYTE special edition titled “Computers and the Disabled,” “an abbreviation expansion routine that would allow an individual to abbreviate all commonly used words and greatly reduce the number of keystrokes required to type out messages, programs, etc. The program would automatically expand the abbreviations as the user typed them.” He’d dreamed up and started building features similar to what we’d come to know as TextExpander and autocomplete, two years before the first Mac was released.

But there was another problem that he couldn’t quite solve. “We had a friend who had polio,” Vanderheiden related in a call, “and used a mouthstick for everything. He’d made a stack of pennies onto which he had soldered a copper ring, and whenever he wanted to press a key he would pick it up with his mouthstick and press the key. Capslock worked for letters, but everything else was a challenge.” You could put the pennies on shift, say, then press a letter to capitalize it or a number to enter a special character. But you couldn’t press Ctrl-Alt-Delete, or any other more complicated shortcut.

So in the BYTE article, Vanderheiden imagined a mechanical workaround—“A weight on a hinge that can be tipped to hold down the shift key,” he mused— could, perhaps, help his friend.

That’d work—but imagine placing a weight on Control, another on Alt, and finally pressing Delete with a finger. It’d be tedious at best, error-prone at worst. Charles Lee, a mechanical engineer who’d joined the Trace Center team in 1984, realized a software solution was hiding in plain sight at the beginning of another BYTE article several years later.

What if you combined the ideas for expanding abbreviations and weights to hold down keys, and made a program that’d hold down keys for you, virtually? “At the Trace Center,” recalled Lee over email, “we had been working on various typing acceleration techniques, but to be truly effective, they needed to be able to ‘fool’ programs to think the person was typing on the keyboard.”

After brainstorming with Vanderheiden, deciding how to activate and deactivate the software, Lee set to work coding what he called 1-Finger, for DOS, over what was likely the winter of 1985-1986. “The original program was written in assembly language,” said Lee, and it took over as the keyboard driver to block and insert keyboard actions until you turned it off. “Once it was activated by pressing the shift key five times in a row, the 1-finger program would cause all of the modifier keys (e.g., Shift, Alt, Control) to become ‘sticky,’” explains an upcoming history of the Trace Center.

Thus the name Sticky Keys, as 1-Finger soon was renamed, to match Filter Keys, Repeat Keys, and other accessibility tools the Trace Center developed. It worked like this. You’d turn on Sticky Keys, then press keyboard shortcuts one key at a time. With Sticky Keys enabled you could, for example, press and release shift then press and release 2 to type an @ symbol, one key at a time. You could press control, then alt, then delete. Anyone could type anything, as long as they had Sticky Keys.

The case of the oversized keyboards

An IBM ad for the original Model M keyboard, via Deskthority

While Gregg Vanderheiden was imagining solutions to make computing accessible and Charles Lee was coding them to life, IBM was making life harder for everyone.

Or so it seemed. The QWERTY letter layout was standard, but the other keys on computer keyboards were still not set in stone. Every new keyboard, seemingly, picked a new design for Ctrl, Alt, and other PC-focused keys. “Every place you pick to put them is not a good place for somebody,” said IBM’s president of keyboards, of their original key placement. “Fortunately, people adjust; in fact, if we were to change it now we would be in hot water.”

But clearly, there were improvements to make, changes worth the adjustment.
With IBM’s third PC keyboard, the Model M introduced in 1986, Big Blue settled on what became the standard PC keyboard layout we still use today. Ctrl and Alt came to live side-by-side both on the left and right side of the spacebar (with a gap that’d come to be filled by the Windows key on PCs). The Caps Lock key moved above Shift, and the function keys landed in a row along the top of the keyboard.

And it stuck. With the addition of Windows or Command keys, it’s the layout nearly every Mac and PC keyboard still uses today—only perhaps with smaller keys with less gaps between them.

For there was one glaring issue with IBM’s keyboard: It was huge. “The first thing you notice about the IBM Model M keyboard is its size,” remarked a review. It weighed 5 pounds, and was over a foot and a half (49cm) wide and 8 inches (21cm) tall.

A keyboard that big broke existing keyboard shortcuts. When the average adult’s hand span is just over 7 inches, it wasn’t long before people found they simply couldn’t press keyboard shortcuts on IBM’s oversized keyboard—especially not those like the IBM-invented ctrl-alt-delete that was inaccessible by design, since you didn’t want people restarting their computer by accident.

IBM’s original keyboards let you enter most keyboard shortcuts with only your left hand. Now, many required two hands—or a finger workout. “Maybe our muscle memories for the old function-key arrangement will pass away,” wrote Jeff Prosise, a PC Magazine writer from Tennessee, in 1988, “but so too will the convenience of entering key combinations like Ctrl-F8 and Alt-F1” with a single hand.

If the keyboard design was here to stay, Prosise decided, he’d have to do something about it.

“By day, I was an engineer for Martin Marietta,” related Prosise via email. Writing and coding was “a side job that I did for fun in the evening.”

Original STAYDOWN code from PC Magazine

With his IBM PS/2 computer and its 101-key keyboard, he’d code small productivity utilities and share them in detailed write-ups for PC Magazine. “We wrote them in assembly language to keep them super small,” said Prosise, then distributed them with both raw code in the magazine and a pre-internet dial-up service to download those tiny apps from the magazine’s servers.

“When IBM introduced their 101-key keyboard,” recalled Prosise, “you could no longer enter certain key combinations with one hand. We decided to do something about that, and physically challenged users were top of mind.”

A bit of coding and writing later, and Prosise’s solution for IBM’s oversized keyboards, STAYDOWN, was published in PC Magazine’s April 1988 edition.

“There’s nothing software can do to relocate the function keys,” wrote Prosise in his PC Magazine article, “but a bit of keyboard trickery can make the situation slightly more livable.” His app would “temporarily lock down any Ctrl, Alt, or Shift key that is pressed until it receives the break code from a second key.”

STAYDOWN stuck around. It was mentioned in a 1991 issue of Communicating Together, a magazine for those with disabilities, as a useful tool for entering keyboard shortcuts on DOS and Windows, and was still being recommended by PC Magazine in 1993.

And, incredibly enough, it’d been invented independently of the Trace Center’s work, seven years before similar functionality would finally be built into Windows.

Diplomacy and dragging tech into the future.

Easy Access in Macintosh System 6, via the Complete Mac Handbook

While PC Magazine readers were downloading STAYDOWN to hold keys down in DOS, the Trace Center team was hard at work convincing executives to build Sticky Keys and other accessibility-focused utilities into their computers. They shared their original code with Apple, Microsoft, and IBM, and lobbied for in-house developers to extend and build into their products.

Apple was the first to bite. Developer Ed Tecot decided to build Sticky Keys into the Macintosh’s keyboard drivers—covertly, over the weekend, since Sticky Keys “was number seven on the priority list and they were under strict orders to never work on anything that was below their top three priorities,” as the Trace Center’s history relates. But Tecot’s code passed review and shipped. The dates have been lost to time, but the Mac had Sticky Keys by 1987. By Macintosh System 6’s release in April 1988—the same month PC Magazine published STAYDOWN—Sticky Keys was included along with other accessibility tools in the Easy Access bundle.

“To my delight,” wrote the now-defunct accessibility-focused magazine Mainstream in 1990, “Apple had removed a long-standing computing hurdle. The Sticky Keys feature of Easy Access eliminates the need to hold down more than one key at a time.”

One month after its release, Sticky Keys endeared itself to Apple’s management. “I was at work one day at Trace,” recalled Vanderheiden, “when I received a phone call from Chris Espinosa, the VP of software at Apple. He asked me how to turn on the feature where you could operate the computer with one hand.” Turns out, he’d slipped on ice in Paris, injured his elbow, and couldn’t type two-handed keyboard shortcuts. Apple’s early investments in accessibility had quickly paid off.

Microsoft’s original StickyKeys in Windows 95

Microsoft took a bit longer to come around. At the same time PC Magazine was sharing STAYDOWN for free, Microsoft had bundled an early version of Trace’s Sticky Keys along with printer drivers into the Access Pack for Windows 2 and 3, something you could download from the early pre-web internet or order for free from the software giant—though PC Magazine mentioned it required a $20 shipping and handling fee.

It took another determined employee to push Microsoft to go the whole way. “Greg Lowney, then a one-person accessibility program at Microsoft, lobbied hard along with us to get the access features built into the operating system as standard components,” recalls Vanderheiden. His determination eventually got the software giant focused on accessibility. Accessibility, for Lowney, was a side project at the beginning.

“I started working with Charles Lee at least as early as January 1989,” recalled Greg Lowney over email, who was “Program Manager for the Windows ‘Core’ (most of the basic components and technical aspects)” at the time. “Eventually I had enough influence to start adding accessibility work to my list of official objectives and formally dedicate 10% of my time to it, even before upper management became convinced of its importance,” said Lowney. That originally led to shipping Sticky Keys in first the Access Utility for Windows 3.0, Windows NT, and a supplemental disk for MS-DOS 3.3 and newer—and to Lowney becoming Director of Accessibility after Windows 3.11 shipped.

Right before releasing Windows 95, Microsoft held their first disability summit and launched a corporate policy on accessibility. When Windows 95 was launched, mere weeks later, Sticky Keys came baked into the latest operating system, along with Filter Keys (to ignore repeated keystrokes), Toggle Keys (to make a sound when Caps Lock and Num Lock keys were pressed), and more.

Progress is a slow, halting process. New technology comes out, simplifying some things, complicating others. Someone comes up with a hack, a fix, a workaround to solve the issue. Someone else realizes this idea could solve other problems that have been plaguing a whole community for a while. And gradually it snowballs until a new standard is invented, baked into what future users will assume is just how technology always worked.

The infamous Sticky Keys popup in Windows 11, today, that you’ll see if you press Shift 5 times.

Today, Sticky Keys is a standard, baked into PCs and Macs, Chromebooks and iPads alike, codified for the future in ISO standard 9241-171:2008. It’s turned off by default on Macs—as the inventors intended. “You want sticky keys turned off by default because it’s just going to annoy them,” shared Vanderheiden in the call. “It doesn’t help you, it doesn’t help them, it doesn’t help the disability community.” But somehow, the wires got crossed with Windows, and to this day it’s enabled by default, an accidental 5-Shift-press away from discovery.

And at least that means it’s discovered by the people who need it, by those like Espinosa who were in an accident, by those like developer Rachel Andrew who use it to overcome RSI, by those with coordination problems who otherwise would have to rely on Caps Lock, by those whose only way to use a computer is with a plastic stick held in their mouth. It leveled the playing field, set the stage for other accessibility features like screen readers to be built-in, and made technology a bit more accessible for everyone.

On inventing the future.

“Are inventions inevitable?” asked a 1922 paper by William Ogburn and Dorthy Thomas. No, both Betteridge’s law of headlines and their conclusion would reply. Yet simultaneous inventions—the same thing being invented at the same time by different people—occur too often to be simple coincidences.

Orgburn and Thomas found three factors that made it more likely something would be invented: A defined problem or need, a desire to fulfill that need, and “cultural preparedness” or understanding of how to approach the problem in general. When the factors align, it’s only a matter of time before innovators start pulling a solution together.

Soon enough, what was previously a hole in our technological advancement becomes a new baseline, a default, something we expect to exist.

Neither Sticky Keys nor STAYDOWN were invented in a vacuum. Both were motivated by the difficulty of entering keyboard shortcuts, both were inspired by clever technical solutions that made it possible to press shortcuts one at a time. One thing led to another, like Intel co-founder Robert Noyce said of the invention process: “Every day, you would say, ‘Well, if I could do this, then maybe I could do that, and that would let me do this,’ and eventually you had the concept.”

Of course we have calculus, airplanes, and Sticky Keys. Of course Sticky Keys—and other accessibility tools—became default computing features that are relied on by people everywhere. It’d be hard to imagine a world without them.

References and additional resources

Special thanks to Gregg Vanderheiden for early access to an upcoming history of the Trace Center, and to Jeff Prosise and Greg Lowney for taking the time to talk with us about their early work.

Additional reading:

Computers can play a dual role for disabled individuals, Gregg Vanderheiden, BYTE Magazine 1982
A journey through early augmentative communication and computer access, a 2002 article by Gregg Vanderheiden about the Trace Center’s work
Splitting up the keyboard combos, Jeff Prosise’s original 1988 PC Magazine article introducing STAYDOWN
The Trace Center’s website, detailing their history and their current work today.

We mentor early-career developers. Here’s what they need to succeed.

Andrew Hedges — Wed, 19 Aug 2020 21:49:34 +0000

Note: This article first appeared on LinkedIn.

Knowing how to code is just one aspect of being a professional web developer. Another super important skill is knowing how to collaborate effectively on a software team. Most coding bootcamps don’t teach this skill or don’t teach it effectively. This leads early-career developers to stumble in interviews and require a lot of ramp up time in their first tech jobs. The Collab Lab is a program Stacie Taylor and I created to help solve this problem.

The Collab Lab Turns One

In the year since we launched, The Collab Lab has helped 44 early-career web developers learn how to work on software teams. We provide remote, collaborative project practice for developers who have worked to develop a baseline of technical skills, but who haven’t yet had the experience of working on a technical team.

Our two dozen volunteer mentors are all professional web developers and engineering leaders. We structure our projects to be simplified, but otherwise very real-world in how they’re run. Participants employ pair programming to complete stories managed on a project board. They present weekly demos of their progress and participate in learning modules and retrospectives. Participants report feeling more confident in interviews and more prepared for their first developer job.

What helps early-career developers?

Through the course of running 12 projects of 8 weeks each over this last year, we’ve learned a ton about how to make early-career developers successful. It boils down to the following 5 themes:

Structure
Process
Interdependence
Context
Encouragement

Sure, call it SPICE if it helps you remember it. 😅

Structure

Early-career developers benefit from clear guardrails and easy-to-consume written documentation on processes and requirements.

At The Collab Lab, that takes the form of a project brief that acts as a one-stop shop for the information germane to the project. It includes a summary of important links, our expectations of the participants (including pair programming), our weekly project cadence, and even some low-level details such as how we name branches in our code repositories.

Some senior developers might find it overkill, but I’d argue that even experienced teams benefit from having this information clearly documented.

Process

In any organization, but especially in a remote one, written documentation of processes helps developers understand what to expect—and what is expected—day-to-day.

That project brief I mentioned before clearly outlines how our developers will know what to work on as well as the steps for determining when a user story is done. For many of our participants, this is their first experience working on a software team. By documenting the code review and approval process, they can refer to the expectations when things get confusing.

Interdependence

The Collab Lab has been a distributed endeavor from the outset. We use Slack and GitHub to coordinate our projects at a distance. On these remote teams, we encourage interdependence. We emphasize that this isn’t school. Our participants are not being judged or graded. They’re a team working together to get something done.

Each week, our teams of 4 break into 2 pairs. The expectation is that each pair will spend a significant amount of time each week synchronously pair programming. As early-career developers, they’re more likely to succeed at the task at hand if they can create a Venn diagram of knowledge to apply to the problem.

Another practice we emphasize that encourages interdependence is working in the open. This transparency is a core value at Zapier, where I’m an engineering manager. Being “noisy” in Slack helps everyone feel more connected and keeps the team up-to-date on both progress and blockers as the weeks progress.

Context

When we kick off new projects, we ask each participant to watch a video run-through of a previous team’s working application. This is possible because we do the same project each time, but for most organizations the equivalent could take the form of a click-through prototype or even just design mock-ups.

Another way we provide context to our developers is by using the following user story format:

As a ______
I want to ______
So that ______

For example, the following is one of the stories from the smart shopping list project:

As a user
I want to add new items to my shopping list
So that I can start recording purchases

This format is helpful to early-career developers because it’s not just a to-do list of requirements. It provides a description of the value being provided to the end user, including the “why” of the feature. This empowers our developers to come up with creative solutions to the problems presented to them.

Encouragement

When we train our Collab Lab mentors, we literally tell them to be cheerleaders for their teams. Their more formal role is a hybrid of senior developer and product owner, but the most important thing they do most weeks is help the people on their team have confidence they can do the thing.

Because we work in Slack for the most part, this cheerleading often takes the form of lots of GIFs and emoji. ✨ That might not be a great fit for your organization’s culture (in which case I feel sad for you 😅), but because we work remotely, we find it builds much-needed emotional connection among our participants and mentors.

Connection and encouragement—including the praxis of growth mindset by focusing on formative, not summative feedback—go a long way toward overcoming imposter syndrome, that all-too-common feeling that you’re a fraud who’s going to be found out any minute now. By modeling vulnerability and celebrating setbacks, our mentors create a space where it’s safe to experiment and grow.

Increasing the diversity of your team by hiring bootcamp grads only works in the long term if you do the hard work of creating an inclusive, supportive working environment.

Is it worth the effort?

There are myriad benefits to hiring early-career developers. The enthusiasm they bring to a team is contagious, and they can serve as motivation to better document requirements, systems, and processes. It’s also a group that tends to include more people from groups underrepresented in tech, so it’s a great way to increase diversity on your teams.

But like anything worth doing, you may need to make changes to make the effort successful. Harnessing that enthusiasm takes planning and organization. Increasing the diversity of your team by hiring bootcamp grads only works in the long term if you do the hard work of creating an inclusive, supportive working environment.

There are no shortcuts in life or tech, but if you lay the proper groundwork, you’ll set yourself up to help your early-career developers succeed.

❦

Andrew Hedges, Founder of The Collab Lab, is an engineering manager at Zapier, a fully-remote workflow automation company. He holds a Masters of Education from the University of Maryland College Park in counseling and human development. Andrew lives in beautiful Portland, Oregon.

Stacie Taylor, Co-Founder of The Collab Lab, is an engineer at Zapier. She is a former product manager turned engineer and a fierce advocate for early-career developers. Stacie lives in sunny Sacramento, California.

Follow The Collab Lab on Twitter.

Application Process 2.0

Andrew Hedges — Tue, 23 Jun 2020 00:12:16 +0000

The Collab Lab kicked off our first cohort on August 22, 2019. In the 10 months since, demand to participate in the program has been steadily strong. This is great because it tells us we’re filling a real need! What’s been not so great has been the experience for people applying to be in the program. So we’re making some changes.

What’s changing?

Starting now, for each new cohort, we will be opening a one-week window during which applications to participate will be accepted.

In more concrete terms, we will kick off our next two cohorts on August 2, 2020. The application window for these cohorts will be July 5 – 11. We will review applications submitted within those dates and make decisions the following week.

🚨 If you have applied before, you will need to apply again! 🚨

For future readers of this post, you can always visit the-collab-lab.codes/apply for the most up-to-date info about upcoming cohorts.

Why are we making this change?

Until now, when you applied to participate in The Collab Lab, you essentially joined a long and growing waitlist.

Then…you waited. Sometimes for a long, long time.

How long? Since we started tracking it, people who have been selected for a cohort have waited an average of 122 days between their application and their acceptance. And that wait time has grown over time.

That’s unacceptable.

Making it all the more frustrating for you, the applicant, is the fact that once you applied, the process was for all intents and purposes opaque. To many of you, it wasn’t even clear you were putting your name on a waitlist!

What does it mean for you?

At its simplest, the new process means that if you apply there will be two possible results:

🤗 You get accepted. Yay! We’ll be in touch with next steps.
😥 You get rejected. For now…try again!

We anticipate more applicants than we will have slots. If you’re qualified, but the numbers just didn’t work out, we’ll let you know that and you can totally apply the next time using the same info. If, on the other hand, we evaluated your experience and determined you didn’t meet the minimum requirements in some way, we’ll let you know that, too. That way you can put in the work to increase your chances of being accepted before the next application window opens.

So, yes, you may have to apply multiple times in order to be selected. At least with this new process, you’ll know where you stand!

So…what now?

As we said earlier in the email, our next two cohorts will kick off on August 2, 2020. The next application window will be open from July 5 – 11.

If you’re interested in applying for our upcoming cohorts, visit the-collab-lab.codes/apply to sign up to be reminded to come back to the site to submit your application that week.

We welcome your feedback on this new process. Thank you for hanging in there in these early days as we iron out how to scale up the program. We look forward to working with you in a future cohort!

Black Lives Matter

Andrew Hedges — Tue, 02 Jun 2020 22:28:10 +0000

I published a post to The Collab Lab’s internal Slack team on Sunday, but considering the events of the last couple of days wanted to take the step of taking the message public. It’s nothing profound, simply an expression of support for the amazing people who contribute to and take part in the programs of our little nonprofit.

To make it fully explicit, we at The Collab Lab believe that Black lives matter. We strive to be anti-racist. We acknowledge the many ways that privilege has benefited many of us. We are committed to doing everything we can to lift up the people who come to Collab Lab looking for that next bit of experience that might mean the difference between finding that foothold in tech or not.

If you have the means, consider donating to organizations fighting for justice for Black people. You can also educate yourself, patronize Black-owned businesses, etc. Here is an excellent compilation of aligned organizations and businesses.

@channel I just wanted to take a minute to acknowledge what’s going on in the world at the moment. I was born 17 days after Dr MLK, Jr was assassinated. That summer of ’68 saw massive protests including surrounding the Democratic National Convention. Yep, like 2020, 1968 was also an election year and Richard Nixon ended up being elected President. 😐

So little has changed in the last 50 years, I feel more sad and disappointed with my country than I ever have. As if the pandemic wasn’t enough, we’re seeing (mostly) peaceful uprisings by the American people being violently suppressed by police who have transformed themselves into armed militias and are acting not to serve and protect, but to destroy and intimidate.

Kareem Abdul-Jabbar (former NBA star for the LA Lakers) started life as Lew Alcindor and changed his name partly as a result of the unrest in the late 1960s. He’s written an incredibly thoughtful piece that might be helpful in putting some context around what is going on.

I know many of you are feeling a ton of strong and probably at times contradictory feelings about everything happening in the US and the world at the moment. The Collab Lab is a community and we will do everything we can to support each other through all of this.

We exist to right inequities in the tech industry. I see that as directly connected to the larger issues of social justice that are playing out right now on our screens and in some cases in front of our houses.

Be safe. Be strong. No justice, no peace. ✊

Cohort 4 Recap

Andrew Hedges — Tue, 24 Mar 2020 03:03:47 +0000

Collab Lab’s 4th cohort wrapped up today. They’re awesome and you should hire them! Well, if you can. Some of them already have jobs! 🙂

This cohort consisted of Haley Elder, Jaela Wesley, Matthew Hughes, and Rachael Bouissey. The mentors were Michael Sholty, Radhika Morabia, and Stacie Taylor-Cima.

Each time I get on our last call with a cohort, I can’t believe that it’s gone so fast. Cohort 4 felt like it was done in the blink of an eye!

This group came in with some strong development chops and it showed. The mentors commented that this group was able to act more independently than they expected because they were comfortable with the technologies being used out of the gate.

This freed us to focus in on learning how a software team works as well as allowed the participants to get creative with how they satisfied the requirements of the project.

As with every group we’ve welcome through, the group learned a ton about working as a team remotely as they went. By the end, they’d fully bought in to the need to be “noisy” in the team channel about status, both progress and blockers.

So, yes, you should hire them! But know that a couple of them are already working as developers, so if you want ’em, you better swoop in fast! 🙂

Cohort 3 Recap

Andrew Hedges — Sun, 09 Feb 2020 22:24:30 +0000

Something we’re quickly learning at The Collab Lab is that every cohort we run is different. It makes sense! Each is a unique collection of participants and mentors with different strengths and weaknesses. The other thing we’re quickly learning is that every cohort is amazing in their own way!

TCL-3 got off to a somewhat rocky start. We had 2 participants drop out after the first week and had to scramble to fill the spots. Luckily, we found 2 amazing people to make the group complete again!

This cohort ended up composed of the following lovely people: Amber Jiles, Mike Ramirez, Monica Johnson, and Nikema Prophet. The mentors were Lars Brekken, Stacie Taylor-Cima, & Steve Gardner.

What made this cohort stand apart was their tenacity.

The Collab Lab is structured such that the 4 developers pair off each week to take on 1 story from the backlog over the course of the 8 weeks. A couple of weeks in, we fell behind on keeping that pace. We talked as a group about the situation and decided not to extend the project, but rather chose what scope was highest priority and focused on getting that done within the original 8-week plan.

The group decided to mob program the last week, assigning leads for the 2 tasks they wanted to accomplish. Monica and Nikema stepped up into those leadership roles and did great jobs at it!

Other examples of overcoming adversity and going above and beyond from this group include the following:

Monica working from a shared laptop (not even sure how she managed that!)
Nikema blogging consistently throughout the project about what she was learning
Mike sharing his experience as a tech recruiter with Nikema and others
Hitting the Firebase query limit (which, to be fair, has happened to every cohort so far!)
Nikema and others proactively finding bugs in the app and filing issues
Nikema, in particular, submitting refactor PRs a couple of times during the course of the project
Working around a fair bit of travel from the group; Mike went to Germany over the Christmas holiday; Steve, Stacie, and Andrew all had a work retreat smack in the middle of it all
At least 1 participant and 1 of the mentors were almost brand new to React, so they had to learn doubly fast!

One of the things I love on our weekly calls is when our kids “disrupt” the call. Several of us in this group are parents, which occasionally leads to adorable moments like the following (skip ahead to the 11 minute mark)…

The Collab Lab

Andrew Hedges — Fri, 03 Jan 2020 06:26:30 +0000

The Collab Lab is collaborative, remote project practice for early career developers. We kicked off our first cohort in August of 2019 and have been off to the races ever since.

Projects are structured such that most participants can keep up by devoting 5 hours per week over the 8-week duration. We accept only 4 developers per cohort, so we have a long backlog of people who want to take part, but we’re working hard to scale up what we do and are always accepting expressions of interest! 📈

The core of Collab Lab is pair programming. A sometimes controversial practice in the web development world, we believe that pairing is an excellent way for early career developers to gain experience as they learn.

One of the side benefits of pairing is that you are forced to articulate your thought processes verbally. For many developers, this is the first time they’ve had to say these things out loud! Multiple Collab Lab participants have reported that talking through their work has helped them in technical interviews.

What we accomplished in our first 6 months

Ran our first cohort! 🎉
Ran our second and third cohorts!!! 💯
Grew our mentor team from, well…zero, to 7! 💪
Appointed Stacie Taylor-Cima as our official point of contact for Code of Conduct concerns ✨

What we’re tryna accomplish in 2020

Run our first cohort outside North American time zones 🌍
Run 3 cohorts, simultaneously 😳
Add 2 additional projects to the 1 currently on offer 📋
Complete the process of becoming a 501(c)(3) for tax purposes 💸
Leverage our new, non-profit status to take better advantage of the several freemium tools we use and to get discounts on our paid tools 🧰
Build our donor base to at least $200/month to support the premium use of tools such as Slack, Zoom, G Suite, Netflify, and Firebase 💰

If nothing else, the last 6 months have taught us that there is a huge need for training on how to collaborate on a software team.

Bootcamps are great as an introduction to coding (disclosure: Andrew is a former instructor for and current advisor to a coding bootcamp in Portland, Oregon), but they often don’t provide opportunities for their students to experience what it’s like to contribute to software teams.

The Collab Lab fills that gap. For free. To as many people as we can. From under-represented groups whenever possible.

Find out more at the-collab-lab.codes