Since I’m still in the early stages of my career as a web developer, I spend a lot of time thinking about the art of learning.
I’m obsessed with optimizing my learning to squeeze the most out of my work and build my own skill set. I want both to catch up with my peers (a mental placebo I feed myself to encourage learning, whether I really need to or not), and meet my personal learning goals. Ever since I’ve given up on the myth of following my passion, I’ve set out to be the best I can at my job, and I’m working hard at going wide and deep with my skill set.
There isn’t a universal method for learning. There are, however, universal patterns which I believe contribute to rapid learning in our industry. Instead of trying to tackle all of these patterns, I’ll just focus here on a single segment: patterns in the learner’s environment.
Usually, in our industry, this environment is the workplace; but the principles I’m thinking of are just as valid elsewhere. Your environment could also be education, or some other “micro-environment” like meet-ups, conferences, or even Twitter conversations. There are environments that enable flourishing learners, and there are environments that discourage learners.
Here are some of the patterns I’m noticing that create an atmosphere where learners can flourish:
1. Value Learnability Over Competency
Do we reward those who have learned or those who are diligently learning?
It’s important to accept the fact that every member of our team is in a state of learning flux, regardless of how far down that path they are. Once we realize this, it’s easy to take the next step and develop a culture of openness about where we are on that path.
“Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” —Jake Scruggs in “My Apprenticeship”
If less competent team members tuck away their ignorance for fear of being exposed, they will almost undoubtedly grow very slowly, or not at all. Contrast this with an environment where team members know each others’ strengths and weaknesses. As soon as workers reach a problem they can’t solve within a reasonable time, they can reach out to the team members who will be able to quickly mentor them through the problem.
You might think of this as an “agile” approach to learning. The team has the freedom to tackle extremely difficult problems one small step at a time with a process that looks something like this:
Dive deep into a challenging design or development problem.
Struggle against the outer wall of our knowledge, learning as we struggle. Spend more time in the medium trying stuff, than out of the medium looking for answers.
After reaching an absolute time constraint or knowledge constraint, reach out to a more competent team member for help. At this point, we’ve mostly exhausted our own mental resources.
Solve the problem quickly under the leadership of a mentor—and with it, we gain confidence and kill the strain of inferiority/incompetency.
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” —The Agile Manifesto Principles
If we have the assurance that someone on our team will be able to help eventually get us unstuck, we’ll feel free to dive right into the problem and try “breaking things” first.
2. Allow Space for Modest Failures
Are we protecting a carefully crafted image of perfection, or giving each other ample room to fail in ways that strengthen our skillsets and morale?
It’s been said many times and in many ways that the way to achieve lots of success is to endure lots of failures. This adage is almost right, but I believe there’s a subtle error in it. Of course, failure has its place in success. But in order for it to be healthy, it must be the right kind of failure, and it should usually be modest.
Severe failure can be debilitating—an enemy to our progress. The right kind of failure for blossoming developers is moderated, ever-so-slightly protected failure. It’s the kind of failure that can be recovered from. It’s the kind of failure that builds muscle rather than breaking bones.
We can create a culture where this sort of helpful failure happens regularly in order to foster rapid learning. In learning new development languages, for example, the assignment from a mentor to a learner might look something like this:
“Here’s a challenging JavaScript problem for you to solve. I recommend trying these few approaches, and definitely don’t try this method—it’s a dead-end street.”
If the assignment is a new development environment, the conversation might go like this:
“Try setting up this server from scratch. It’ll be tough, but here are a few guides to get you started. Be careful not to type this seemingly harmless command, or you’ll wipe the whole box instantly.”
If the discussion is about a user interface design problem, the mentor might say this:
“Here’s a rough sketch of what I’ve been imagining on this page. I’m not stuck on it—so think of something better if you can. We can’t use this color because it’s a huge cultural faux pas in our client’s market. Otherwise, here are the constraints—let’s see what you come up with.
This works so predictably, because it stretches the learners’ skills just past their current comfort level, while protecting them from wasting precious hours on unproductive learning. The role of the rapid learning environment here is mainly to keep learners from doing the wrong thing too long, and nudge them toward practicing the right things.
3. Value Personal Growth Over Completion
Do we value finishing the project, or improving our skills during the course of the project?
This is a tough one. There’s obviously a level of tension between project deadlines and team growth. The work has to get done.
I’m referring to the overall tendency of the organization, though. There are dozens of small choices that a team makes during the course of a project that nudge them either toward growth, or toward a speedier completion.
Sometimes, deadlines just have to take priority. There are times, though, where more experienced workers can afford to hand off challenging projects to less experienced workers, aiming for that worker’s long-term growth instead of aiming to complete the project as quickly as possible.
Valuing personal growth over speedy completion is an investment in the future. Pushing a project out the door by choosing the fastest on the team and making heavy use of preexisting frameworks and plugins might get us a paycheck more quickly. Over the life of the company, however, it can lead to an increasing rift in skill “classes” and stagnation.
Individual developers have responsibility here also. Instead of merely putting out fires, we can take the time to help each other build robust mental models of the problems we encounter. Every problem can be an opportunity for group learning.
We Can All Help
You might be thinking of your own organization as you consider these principles, and thinking of either how well or how poorly your leadership builds them into your culture. While a company’s leaders have tremendous power to push the course of their team toward or away from a culture of learning, I’m thinking mainly about our individual attitudes.
As a coworker or meet-up organizer, you can have a life-changing impact on the way your peers grow by creating a friendly, approachable atmosphere whenever you teach. After all, this work isn’t a race to the top. The web has always been a demonstration of the power of collaboration, and there’s no good reason to change that now.
