This post by Erik Dietrich covers the situation where a developer becomes an “expert beginner”. This is something to avoid as you build your career–don’t work in a place where you are isolated or unable to progress. He breaks progress in any area down into a number of components–Beginner, Advanced Beginner, Competent, etc.
As such, Advanced Beginners can break one of two ways: they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert. This actually isn’t as immediately ridiculous as it sounds. Let’s go back to my erstwhile bowling career and consider what might have happened had I been the only or best bowler in the alley. I would have started out doing poorly and then quickly picked the low hanging fruit of skill acquisition to rapidly advance. Dunning-Kruger notwithstanding, I might have rationally concluded that I had a pretty good aptitude for bowling as my skill level grew quickly. And I might also have concluded somewhat rationally (if rather arrogantly) that me leveling off indicated that I had reached the pinnacle of bowling skill. After all, I don’t see anyone around me that’s better than me, and there must be some point of mastery, so I guess I’m there.
This post is worth reading in whole. It resonates with me because I’ve spent most of my career in small companies. I do that because it fits best with my desires and my life goals. But I’m acutely aware that as I become more experienced, I am typically one of the most experienced technical folks in the room. This is a problem, because I could believe that I had most or all of the answers based on my experience (what the Expert Beginner believes).
I strenuously combat that by engaging with my peers in person and online, and I think this is a great way to do so. It’s not as deep an engagement as working with them, of course, but affords me the ability to work at small companies.
Ways to engage with the larger software community include:
The work environment you are in is a great place to level up, but depending on your situation, you may end up with few people you can learn from. In that case, it is imperative that you improve yourself through engaging with the larger software community.
This is a guest blog post from Rick Manelius. Enjoy.
Dear new developer,
Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?
Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.
A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials. Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.
I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.
Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.
Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.
To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.
Before I overwhelm you any further…
…there is hope.
You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.
Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.
The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.
Adopt a Hive Mind Approach
We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.
By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.
So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.
Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.
So get out there! And good luck!
Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.
A big part of your job is keeping up to date with new technologies and happenings in the tech world. This can sometimes be a distraction, because there is all kinds of new stuff coming out all the time, whether from big companies releasing new tools or platforms, people publishing interesting code or articles on their experiences, or marketing from smaller companies. I avoid this distraction by relying on a community to do some filtering for me. Obviously that means that you need to find the right community, otherwise the filtering won’t be effective.
If you know the exact type of technology you want to focus on (say React Native or Haskell for web development), you can sign up for an email list(s) related to the projects. Or you can go to github and start to follow the issue lists. Or if you know people involved in the project, you can follow them on Twitter. Matt Raible, a prolific developer and blogger, once mentioned that he learns a new technology by unfollowing everyone he is following on Twitter, then following only people talking about the technology, so that his Twitter feed is rich with focused information.
However, if you aren’t sure exactly what to focus on, a more general community might be a better fit. These ebb and flow over the years but they also cross pollinate, so if you join one and a few years later it feels like it is not as active, be on the lookout for the up and coming community to jump to.
Slashdot was the first focused online web based community one I ever took part in. I enjoyed the discussions and linux focus. Recently I’ve moved on to Hacker News, which has a nice mix of technology, science business and politics that I enjoy. But there are other great options like Reddit (where you can find any subgenre you want, but you may want to stick with the big reddits like /r/programming), Stackoverflow (for programming q&a), and lobste.rs (which is less business and more technology focused).
Whatever community you join, whether it is a specific project or a general link sharing site like Hacker News, make sure you actually become a member of the community. Just like the value of a meetup is in who you meet time after time, visiting an online community just once is unlikely to be valuable. And be especially wary of self promotion (this Reddit page has some great guidelines about how to be an effective member of an online community, but seek out such guidance wherever you land).
Once you find and join a community, take part in it. Comment, submit links that you find interesting, and visit it. Be ready to be offended or hurt by some comments, especially if you say something dumb. I have definitely said dumb things or spoken on topics that I wasn’t fully informed about. I feel a flush of shame, leave the community alone for a few hours,and then come back and apologize or acknowledge my mistake. It’s unpleasant but part of the package.
The more pleasant part of the package is being exposed to new things. If it solves a problem you see, you may want to discuss bringing a new technology or piece of open source software into your work. Your work may have policies around new technology, but it never hurts to bring it up and discuss whether it may be applicable. You also may find interesting commentary and perspective on the technology you are already using at work, and sharing that can be a good way to help the team get better with it.
It’s also fun to occasionally submit something, whether an interesting open source project, an article on your blog, or something else you’ve seen. I’ve done that a few times and it’s nice when a submission blows up and becomes popular. It’s also a nice way to say “thank you” to someone who has written something interesting and help them out–I can think of multiple submissions that were interesting articles written by people I knew and when the submission got popular, the people were thankful I’d posted it.
In summation, find an online community, participate it in, and you will reap the rewards.