The Lone(ly) Coder

by tkshill
At my job I code alone.
I have always coded alone.
Until now.
Now I code with friends.
Now I code with family.
I will never code alone again.
- An Ode to Open Source

This year I met a wonderful group of people called Virtual Coffee. For the first time in a long time, I'm excited about my job, and my profession. I'm writing again. I'm working on side projects again. I'm doing technical talks. I'm contributing to open source. I'm doing all the things I thought I would never do again. I had thought I was burnt out on my career; on the tech space; on software development. It turns out, I was just burnt out on programming by myself.


It's taken some time to write this point because every time I put put to paper, my words feel inadequate.

For the first time in my life I've found a developer community where my person and personality are more valued and treasured more than my additions to the codebase. And if you've never had the opportunity to be in a space where the only contribution you need give is your own presence, let me tell you, it is a treat.

For the first time in a long time, I have a friend group who shares my interests. And not a network I've constructed as part of some larger goal in my career. I'm not "expanding my influence", "building my brand", or "becoming a thought leader". And to be clear, there's nothing wrong with pursuing those types of goals. We should all be free to dream as big or as wide as we like.

But Virtual Coffee is not my goal. They're my friends. Twice a week we meet on zoom to talk with each other about all and sundry and check in. Frequently we talk about tech, and the industry. Frequently we do not. And when we're not on zoom, we're supporting each other on slack or the Twitterverse.

We have mentors in the sense that we teach each other, and learn from each other, and share our hopes and fears. We have learning moments in the sense that we self organize small talks and roundtables around topics of interest in the community. And it's all real. There are no sponsors. No corporate backers. No accelerated growth plans. By and large we're all in the tech space, but what unites is that we're all people just trying to live our lives.

???

"A graph is worth 1000 data points."


At the start of this pandemic, you couldn't have paid me to code in my spare time.

Earlier in the year, I had stalled out in a bad job from lack of support. I probably still had a desire to code, but zero self motivation, and I'd started/stopped dozens of side projects in the last few years. Compound that with personal struggles with anxiety and depression and you had the perfect recipe for a complete stall out. What was the point?

But a few months in to virtual coffee, I found myself wanting to give back to a space that had done so much for me. And Digital Ocean's Hacktoberfest was right around the corner. So the innocuous thought came to mind. It started with the question, despite our best efforts, "why is getting into open source so hard?"

After a lot of discussions in the group, we realized that the big barrier to open source was ultimately breaking through the trepidation new developers face when attempting to contribute to other people's projects. If FOMO is Fear Of Missing Out, then this would be what I call FOFU (Fear of F***ing up).

New developers are genuinely terrified that their (supposed) lack of knowledge will slow down, frustrate, or debilitate the efforts of open source work.

Combined with a lack of materials to demystify the process, and you have a situation where even the best intentioned open source repo still looks like an inaccessible space for fledgling programmers.

The bottleneck in open source wasn't the contributors; it was the maintainers who needed to remove the pain points that made projects inaccessible. But did maintainers have good resources on how to do that? Well, I wasn't sure. So I tried to make one

So that was good right? But then I thought, you should practice what you preach, so I ended up:

  • Starting up an open source project
  • Dedicated time after work for code review
  • Pair Programming*

*Taking a brief aside here to say that I used to be one of the biggest skeptics of pair programming. It seemed cloying and inefficient and invasive and everything I didn't want from my dev time. But I am a changed man.

After my experiences with hacktoberfest, I cannot think of a faster way to accelerate learning for developers than pairing on a project/problem. It's such an amazing tool that I wish every programmer had a chance to try and I regret I hadn't done it sooner. If you want to understand why and get your feet wet on the process, check out this article.

This post has kind of run away from me, and I still have a long ways to go before I can write about things coherently. I guess all I really want to say is that I'm grateful I think the most valuable asset to a developer is not how much tutorials they watch or articles they write. It's about the communities they find, and they seek.

Whether it be mentorship problems, online groups, meetup spaces, or meeting cool people in a zoom meeting, finding others who share your passions, and can provide support and resources to help you reach your goals, is invaluable for anyone looking to have a successful career.

The image of the developer has long been one of the single, siloed individual, working alone and isolation, alienated from their peers. But I don't think that's what we should be aspiring too. Neither is it what the world needs.

I think developers should work with and for each other. The day I found purpose in my craft was the day I started sharing my ideas, my time, and my struggles, with other people.

Thank you for reading, and looking forward to seeing you at the next virtual coffee.

Created 2 months ago | Updated 2 months ago

Comments

GistLog © 2021
Brought to you by the lovely humans at Tighten