‘You get what you give’ isn’t just a late ’90s catchy pop song set in a late ’90s mall that gives me late ’90s cringe (and nostalgia, but those go hand-in-hand, eh?). It’s also a great way to approach your career! This is something core to the tech scene I’ve adopted in Boulder, Colorado as codified by Techstars with their Give First rule in their Code of Conduct. Their other rules are great ones to build your career around, too.
I have found that giving provides many benefits to the giver:
Offering to help engenders a greater sense of observation and consideration of others’ needs and feelings. This is something we all can work on, given our reputation as social introverts.
It feels good to help others with no strings attached.
If you want to attach (small) strings for your own motivation, you increase how others view you in a positive light.
You may/likely will find rewarding hobbies, coding interests, or other intrinsic rewards without much effort.
You become less arrogant.
You help build your community in a positive way, no matter how small the give is.
People are quicker to recommend you for a job or position if you ever fall on harder times.
It improves your own sense of self-worth and confidence.
You make more friends outside of work.
Did I mention that it just feels good?
My one caveat: There are always people who will take advantage, do try to be open-minded and kind, but watch out for takers, they will burn you out! Thankfully, they are few and far between.
Another great example of this is Jason Cole’s “Year of Giving Dangerously”. I must add that this way of living is out of reach for you as a new developer, but something to keep in mind for over the course of your career. Give in small ways until you can give in bigger ways!
Also, be aware that being seen as only a taker is not a good thing. See my caveat above and think back on any time in your life that you’ve ran into one. Maybe someone who always wanted to copy your answers or homework, but never contributed? Or those group projects where you felt like you were doing all the work? Don’t be a taker.
Volunteer in your community. Be the good you want to see in the world.
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.