So for DevSpace in October, I was happy to present my first soft skills talk: Building a Development Community in your Workplace.

I got a lot of good feedback on it, and some people were asking for some more background information on it.  It’s tough to condense a 1 hour talk into a blog post and not bore the heck out of you, so I’ll make you a deal.  I’ll distill it into my core talking points, and if you’re interested in a specific part of it, let me know and I’ll write a more in-depth blog post.

 

It all started back at PyTennessee 2015.  This was my first conference, and I was floored at what this sort of environment offered.  I got to talk with great people, learn awesome stuff, and just generally have a good time.  But as soon as Monday rolled around the next week, I didn’t feel that great.  I chalked it up to being tired from a conference, and having to go back to work after a great weekend.

A few months later, I had the privilege to go to StrangeLoop in St. Louis.  This was a much bigger affair, and we had talks from senior engineers from Twitter, Microsoft, and Mastercard there.  I loved being there, but another strange thing happened.  Even before the conference ended, I was feeling that same “down” feeling that reminded me of PyTennessee.  I wasn’t quite sure what it was.  It stuck with me longer too.

Time went on, and finally I was able to identify what was troubling me.  I saw all these cool engineers building cool things, and I really had to look hard at my life.  What was I doing?

I identified myself as the following :

” I am a software engineer who works in embedded telecom.”

Man that sounds boring.  I felt like I wasn’t progressing in my job at all.  But I wasn’t happy with how that sounded.  But things got better.  No, I didn’t get a new job, or change teams at that time, but instead, tried to change my perspective.  I don’t know what precipitated the change, or what triggered in my brain, but I started searching for the cool in my job.

Eventually, I came to identify myself as this:

“I build software that controls fiber optic hardware that provides television, phone, and internet at gigabit+ speeds”

Whoa, that sounds way cooler.  And that’s when it hit me.  I had been doing cool stuff all along.  If you get nothing else out of this blog post, I challenge you to think about the stuff that makes your job cool.  If you don’t think there is any way to salvage that, drop me a line.  I’m sure I can find something cool in your job.

 

So why do I tell you this?  Well, once I realized I was working on cool stuff, it was a short jump to realize my coworkers did really awesome stuff too.  And that’s when I decided to get that same feeling that I get from Meetups and conferences into my workplace.  That same high of learning something new, getting your mind blown by cool tricks, all of it.  I wanted to build a community.

What is a community?

Here’s how I define community:

An environment where individual members are trying to make the group better rather than solely focusing on themselves.

You have to have a continuous learning, avenues to share your work, and the empowerment to contribute.  A lot of the initiatives I ended up reinforce one of these pillars of community.

I also believe that building a development community in your workplace also benefits the company in a few ways

• There is a financial aspect to this.  A community is less likely to be siloed, less likely to be doing duplicate work in their own dark corners.  You create a workforce that keeps trying to make itself more efficient, and in the end, you churn out your product faster
• Morale.  Manual labor jobs often see financial incentives as a big driver, but other jobs often see creativity and the ability to execute vision as a big driver.  With a community, you have developers building off each other, solving problems in new ways, and learning things that they might not have otherwise learned.  This feeds us as software engineers.
• Less bugs.  The more eyes you have on a piece of code, the more likely you are to find bugs.  So as engineers build and share, the code they write is more likely to get reused, which is a net win for robustness in the end.

So how do we get there?  Well I break it down into two areas, the technological, and the personal.

Technological

What can you do in your own office, with your own technical practices, to encourage community?

First, you can think about how you write software.  I like to think of it as a spectrum of community-oriented software.

1.  Prototype – You build code only to explore, ultimately to be thrown away.  This can’t even be used by you later on
2. Personal – You build code to solve your immediate need
3. Project – You build code that can be used in your project
4. Reusable – You build code that can be used in other projects, because it solves a more general need
5. Extensible – You build code that not only can be used in other projects, but can be easily extended such that it can solve problems you never even thought of.

With any piece of software you write, you should always ask yourself, how far to the right on the spectrum should this go?  There is a cost as you move right on the spectrum, but there are community benefits as well.  You have to figure out if its worth it.  You may even need to improve your skills to make it worth it.  But the further right on the spectrum you go, the more likely you are to benefit the community

Here’s my quick lessons for how to get further on the right of the spectrum

• Solve other’s needs – Ask how you can reasonably generalize your work.  There is a way to generalize too much, so be wary.  Talk to others.  Learn what pains them.  See if you’ve solved something similar.
• Challenge your assumptions – Nothing stops reuse faster than some bad assumptions.  Does your username/password code ALWAYS have to connect to a MongoDB with a very specific collection name.  Maybe in your project, but if you break that assumption down, you might find other ways to reuse the code
• Composability – Follow the spirit of unix programming.  Build small things that do one thing and do it well.  I can’t tell you how many times I find a piece of code I want to reuse, but it’s directly connected to 18 other things that don’t fit my domain.  Make it small, and let your users compose solutions out of your lego building blocks
• It’s what you ship – Make your code independently shippable.  Make it a Ruby Gem, A Pypi package, a tarball easy to install, whatever it takes.  The easier it is to consume your work, the more likely it is to consume.
• It’s more than what you ship – Code isn’t all there is.  Make it easy to run and read your tests.  Make it easy to extend.  Consider Readme-Driven Development.

Above all, communicate.  We can no longer be antisocial creatures.  Communities are built on relationships, and we need to be able to effectively communicate to our peers to build those relationships.

Asynchonous communication is key as well.   As problems are solved over time, or over geographically disperse team members, you may not be able to benefit from direct communication.  Make your commit messages awesome, so people can understand your intent.  Make your code crystal clear.  Add comments only if you have to, and only to explain why you did something, now what you did.  These are your only ways of communicating with the future.

Consider setting up your own wiki, like pmwiki or mediawiki.  Host your own StackOverflow  or an open-source clone.

The reason these are all important are so that you start building up information outside of tribal knowledge and outside of people’s heads.  You have resources new hires can easily look at and learn.

Personal

So you can’t just do technical practices alone.  You have to meet, either in the flesh, or in cyberspace to coalesce your ideas with others.  Here are some of the ways I recommend doing that

Tech Talks

I host tech talks at work, and I recently wrote a post about it.  Every two or three weeks, we get together for an hour and have anywhere from 1 hour long talk to 2 thirty minute talks to 8 lightning talks.  We get around 60-80 engineers each time and cover anything technical related.  This helps with our continuous learning, sharing of work, and the empowerment of being able to give a talk regardless of experience.  I go out of my way to encourage our co-ops and interns to present.

Dailies

I learned about this from Jonathan Boccarra.  He wrote a great post on it.  The idea is that you take 10 minutes out of every day and present on a topic.  I think this works much better to a scaled down, team-oriented community than a larger tech talk does.

IBATs (I Built a Thing)

This can fit in as tech talks or dailies, or can also just be a chat room on Slack or whatever.  Have people showcase what they built, and have them do a Q&A on it.  This encourages people to build software for others, and allows them to get critical feedback.

Hackathons

I co-organize Hackathons at work as well.  About once a quarter we take a full day to work on anything we think is important.  It can be business related, but it doesn’t necessarily have to be.  You can see more on it with the blog post I wrote for the ADTRAN technology blog.  This is a great way to get people to work with others that they normally don’t get a chance to and solve some interesting problems.

Coding Challenges

I also host weekly coding challenges.  Every week, we delve into something different, such as functional programming in Ruby, using C++14 to code golf stats functions, or trying to cause buffer overflows in a web stack.  Every week there is something to learn, and a nice gamified challenge to entice people to stretch their mind (there are points and prizes awarded)

Activity Clubs

Start a book club, or try to learn something as a team together.   I just got some of my buddies together, and we took turns presenting object oriented patterns, or functional programming ideas.  We’re talking about game design next.  Find ways to get outside your comfort zone, and talk to people.

How Do I get Started?

Just pick something and try it.  Here’s a quick list of my advice

• Keep an open ear – listen to what people in your office are interested in.   Run ideas through some people.
• Scale appropriately – every company is different, so one size doesn’t fit all.  Adapt these ideas accordingly.  You can pilot ideas with just your team first.  Invite others to come, but try to build momentum.  Don’t go for the large stuff right off the bat.  Pick ideas that are appropriate for your company size
• Schedule appropriately – Also, different companies have different scheduling needs.  Use feedback to guide you.  Dailies might be too often, or tech talks might be too infrequent.
• Find ways to inspire others – encourage others to share their ideas.  You might find that they have the same fears you once did about not feeling “cool” enough.  Ask meaningful questions about their work, and welcome them into your community
• Use external communities as a guide – Go to meetups and conferences and external hackathons.  See what you like about them.  See what ideas you can use in your own workplace
• Communicate – This is a recurring theme, but an important one.  You can’t just have a community of one.

 

I consider the best engineers I’ve ever worked with to be the ones that didn’t focus on making themselves better, but the ones making everyone around them better.  This to me is the embodiment of a development community.   Continue to empower people, encourage them to share ideas, and never stop learning.  I really feel like you can make a difference this way.