It’s rather rare that we talk about what goes on inside the walls of Skookum. We
have a number of rather exciting things we’re doing these days and it isn’t all
about client feature development. One such example is our Developer Working
Groups.

We get interesting client work, but there is a much wider spectrum of learning
to do. Additionally, there is so much knowledge and expertise that we want to
share with each other. Without effort, this knowledge stays within the heads of
the individuals and teams. Sharing knowledge is a hard problem. If you
aren’t intentional about sharing knowledge and neglect to optimize for it, then
you will simply lose that knowledge when people move on.

Don’t forget how much engineers typically love to learn, grow, and challenge
themselves. We are problem solvers to the core and like to be challenged.

Combining these ideas (with a few others), we have started our internal working
groups.

A working group is an ad hoc group of subject-matter experts working together to achieve specified goals.

The Source of all Truth (Wikipedia)

How they work

Our implementation of working groups have topics cycle every 6 months. Due to
the size of our development team and to optimize the effectiveness of these
groups, we keep the size at 5-8 people. Once a group has 5 individuals committed
to it they are given the green light to go forth and conquer! (Whatever that may
mean for that specific topic.)

We currently have groups discussing web service APIs, CSS architectures,
computer science, robots and AI, diving deep into ruby, discussing our
engineering approach, and building a companion for our
Hubot installation named Servo.

These are topics that our team came up with to tackle problems we’re facing (and
some that we’d like to) and problems we care about. None of our clients are
asking us to build robots...yet.

What to expect

Of course if you don’t work at Skookum this doesn’t really mean much to you.
This is one of the secret perks of being a developer here. We are given
opportunities to push ourselves and grow into the team we want to be and get to
take an active role in defining that.

Over the next few months we will be talking more about how we’re evolving due to
the working groups. Hopefully we’ll have things like a company-wide style
guides, linting built into our QA for our many tech stacks, officially adopt a
CSS architecture, and use React for everything.

Oh wait. That one is my secret plan.