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.