Category Archives: Team

2014 Developer Learning Guide: Part 2

In Part 1 of this sequence of blog posts, we covered online and print learning. Part 3 is now available as well. This time we will review some of the in-person options for learning and focus in on smaller groups. But first…

An Elaboration On “The Best”

I suggested in 2014 Developer Learning Guide: Part 1 that A-players, top developers, etc. only want to work for companies that have a great learning culture. This doesn’t necessarily mean that they already ARE working for these companies. The point is that, given the choice, the best developers know the value of learning and want to be part of groups where everyone is actively engaged in it. If you are already working for a company like this, I congratulate you on your outstanding choice!

The most common argument I’ve heard for choosing or sticking with a company with poor learning policies/funding: “If a company pays well enough, I can afford my own learning/training.”

Money Vortex
Don’t get caught in a money vortex that leads to stagnation.

This is true. The fallacy is that all of the developers will use their “extra money” for this purpose. We all have obligations and sometimes paying off that credit card or taking a family trip might take priority over paying for our own training. When the employer provides budget and opportunity specifically for training, the entire team is far more likely to take advantage of it. This leads to the entire team learning and growing together. You avoid the situation where stragglers are content to stagnate and contribute a steadily degrading quality of work (and contribute steadily degrading quality of feedback on teammates’ work).

TL;DR I stand by my original statement with a few caveats.

This is not to say that everyone should try to learn in the same ways. Some people don’t take much away from certain types of training and learning opportunities. There is absolutely nothing wrong with this, in fact, it is the purpose of these posts to provide a comprehensive list of the options that are out there! My hope is that you won’t focus on only one type of training. A rich selection of options awaits. I encourage you to try many and find out which work best for you.

In-Person (Smaller Groups)

Book Clubs

Start or join a book club/group/discussion. If you don’t like the word “club” find something different. Oprah won’t mind… why do you even care what she thinks? oprahAndDubmun Hopefully your company is willing  to sponsor a  book group with lunch provided and books paid. This is a minimal expense and provides a great return on investment. Reading books alone often isn’t enough. Having discussions with peers (who will definitely have takeaways you didn’t consider) is a great way to help maximize learning. In addition, adding coding exercises that pertain to the book topic occasionally really helps to cement the knowledge. More on that later…

One thing I’d like to call out here: if your group is larger than six people, consider breaking out into smaller groups for the majority of your discussion time. This is a neat trick I picked up from Mike Clement at Utah Software Craftsmanship meetups. Large groups tend to lend themselves a couple of antipatterns:

  • At best some participants may not participate because the more dominant voices in the room are taking up too much time.
  • At worst, you may have people napping in the back.

We implemented the breakout approach at my current company with great success. We get back together for an overall discussion for 10-15 minutes at the end of the hour and cover the points each group thought were most important.

Selecting the right kind of book is a very important concern here. Voting as a group is a nice way to get an idea of what people are interested in. Always be sure to select titles that will be good for discussion. Code cookbooks are an outstanding example of what not to read. I tend to prefer books grounded in theory, patterns, practices more than how-to books on specific technologies. If you aren’t sure where to start or don’t have money for books initially, there is a lot of great free material for discussions available online. Many blog post make for excellent discussions (hint, wink, nudge).

Presentations/User Groups/Meetups/Open Space

This section is a little more broad. Intentionally. There is an entire class of in-person interactions that can be extremely valuable learning tools. Many are existing groups and some you’ll have to go out of your way to create.

IPresentToYouTheOceanPresentations – The most formal entry of the section. Presentations are sometimes more valuable for the presenter than they are for the people watching. Nothing cements knowledge in your brain like stressing over sharing it with 5 to 500 other people all at once (for me anyway).

What you will take away from attending a presentation depends on your own personal learning style, the effectiveness of the presenter, and how much attention you actually pay to the presentation. I get nuggets from attending presentations but in general they have moderate value for me. So, “Present, present, present!” becomes my mantra.

“But where can I present?” you ask? The opportunities are out there. Present at work, user groups/meetups, coding dojos, code camps, large conferences, or just record yourself and post it online. Not sure how to get started? Go and watch someone present and ask them how they did it. This is also a topic I may write more on in the future.

User Groups/Meetups – Unfortunately I missed a great one of these (Utah Software Craftsmanship) last night because of pressing matters elsewhere. These groups are somewhat hit and miss, but if you find a few that are a good cultural fit and really match your interests they can be fantastic. User groups/meetups are a great place to learn, practice presentation skills, mingle with fellow techies, and often get free food.

Meetup LogoIf there isn’t a local user group that fits your interests, start your own. The most difficult part is securing a venue but local colleges and businesses are often willing to host your group. In addition, larger groups will attract sponsors who may provide swag for giveaways and/or food.

The best current place to look for a public group (or start one) is on Meetup.com.

Open Space Technology – I’ve only participated in one open space-style of meeting/collaboration unfortunately. It was at an Agile Roots conference back in 2009 and had a fairly profound impact on me. If you have the opportunity to attend an open space, I highly recommend it.

For more info check out OST on Wikipedia.

Coding Exercises/Katas

Coding exercises are a general term for writing code following a format lead by a presenter. There are many different subsets of exercises including design, gamified, and code katas. All of these have value, but I’m going to focus on the latter.

If you aren’t familiar with the term code kata, here is what Wikipedia says:  “code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition.http://en.wikipedia.org/wiki/Kata_(programming). I like to compare it to a martial arts kata where we work to develop the equivalent of “muscle memory” for certain coding techniques. Kata Coding dojos are specialized meetups of people who perform code katas as a group. Participating in a coding dojo is something I look forward to every week. I always learn something new and almost always have the opportunity to help others do the same.

I have a future blog post queued up about my experience with starting a coding dojo at HealthEquity over the past year.

Part 3

It turns out I have too much to say for a 2 part post. In the third and final part of this post I will cover more in-person options for learning. It focuses on larger groups and formal training. Find it here: Part 3.

Also, be sure to check out Part 1 if you missed it.

I’d love to see your thoughts and comments below or to @dubmun on Twitter.

Interview/Hire Great Devs: Part 1

Hiring great technical people starts and ends with making a great impression on the best people. This means you have to get the best people in the door.  Once you have hired some of “the best”, your team will attract more of the same but starting out can be difficult. This post focuses on what to do once you’ve attracted their initial interest. I’m specifically covering interviewing and hiring awesome developers, but much of this is applicable across technical disciplines and other skilled positions.

Initial Phase: Resume/Profile Screening

Know What You Are Looking For

NYSpyglassStart the process by knowing what kind of great technical people you are looking for. Are you looking for great young talent that is unafraid of making mistakes? Or tried and tested people who account for exceptions before they arise? Are you looking for teachers or learners (or both)? Do they need certain specific skills or only the great desire and ability to learn, grow, and improve? What is the near, mid, and long term composition of your team?

Many questions should be asked and those questions don’t always have a clear answer. Do you need a consultant or full-time hire to help determine what you are looking for?

Be able to narrow your search quickly based on your must-have criteria and let the rest be discussion points during later phases of the hiring process. Don’t spend more than 5 minutes per resume, LinkedIn profile, or StackOverflow Careers profile weeding out the “No Call” people. It should be obvious because you already know what you are looking for.

I recommend creating two Top 5 lists to assist with knowing what you are looking for. The number of items on the list isn’t the focus. Use 3 or 7 or whatever suits you. It’s the exercise that is important. Write down 5 must-have attributes and 5 must-not-have attributes. Use these lists during initial screening. Pass on anyone with less than 4 must haves or more that 1 must-not-have.

Second Phase: Phone/Online

Personality First

Phone screen or Skype/Hangout for personality and team fit first. I prefer to see people face to face but this isn’t always possible. If you are starting a new team, this phase is even more important. The person you are screening should be someone you can see yourself having an interesting conversation with over lunch. You will be spending a lot of time together building a team. Getting along well is vitally important.

Split PersonalityThe personality screen doesn’t need to be long. Maybe 15-30 minutes. If it goes well, move on to the next phase without hesitation. If is doesn’t, this is the end of the road for this candidate regardless of their other credentials. This may seem extreme or harsh but honestly it saves your time and effort as well as the candidate’s.

On the flip side of this is the importance of representing the culture and personality of your group as accurately as possible. Talk about your goals and aspirations as a team and as a company. This gives the candidate an opportunity to self-select out of the hiring process as well. You don’t want to hire people who won’t be happy in your environment. Honesty is definitely the best policy.

If you are looking for a leader (or emerging leader) this is also the time to make a early assessment of the candidate’s ability to fill this role. Confidence and charisma matter more here that they might otherwise.

The Learning/Knowing Equation

A technical (and partly cultural) phone/online screen of the people you think might be a good personality fit is the logical next step. The interview should be performed by a trusted technical member of your team. This phase is going to go back to the first section because you must know what you are looking for. Rank candidates based on that knowledge.

That said, don’t hold out for a “unicorn”. For our purposes, a unicorn is a developer who knows your tech stack inside-out, knows your business, and knows what you need to do to solve all your current and future problems. I believe unicorns can be developed if you hire people with the right potential, but they cannot be found and hired. At some point the mask comes off.

unicornDeveloper

With this in mind, your focus should be on the candidate’s ability to learn and on gauging what they already know and their ability to teach it. These traits are and probably always will be vital for a technology employee. Of course you’d like someone with experience in some of your technology. The point here is not to miss out on someone who is a fantastic learner/teacher and doesn’t check all of the other boxes on your checklist.

teaching LearningI describe this second screening as partly cultural for a reason. Your interviewer should be verifying that the candidate not only can learn and adapt quickly, but also if they enjoy learning and adapting quickly. When going through the things they do know, the interviewer should look for something they are personally less familiar with. They then can encourage the candidate to teach it to them.  Remember to discover if the candidate is not only capable of teaching but also if they enjoy it. The collaboration component is important.

There are great tools to help with this phase. A good screen-sharing app like GoToMeeting, Skype, or Screen Hero is the best way to do some quick pairing on a simple problem. The problem should be something the candidate may not be wholly familiar with so that their capability of dealing with the unknown can be assessed. That said, this should still be fairly short and sweet. 30-45 minutes tops.

If it seems like this is a good possible fit, personally invite the candidate to visit your facility. If you don’t have a facility, invite them to lunch. If you are looking at remote or relocation hires and the position is permanent, you should arrange transportation/lodging. Under no circumstances should you ever make an offer at this point in the process.

The candidate should have a clear and concise understanding of the next steps at this point. If you are unsure if you should move on to in-person contact, the answer is no.

Part 2 Coming Soon

I will cover the particulars of the types of things you should be doing to “Hire Awesome” in the in person interviews. No specific date, but stay tuned. In the meantime, I’d love to see your thoughts and comments here or on Twitter.

I Like Food

Hopefully this article isn’t as banal as the title suggests. “I like food” is what I say when someone in the office asks me to join them for lunch (usually).

Why?

food-question-mark-628x363

 

Because I like my teammates? Sure.

Because I’m hungry? Usually.

Because I like food? Also true.

Because want to enhance my relationship with my coworkers and build camaraderie among the group? Getting warmer but not quite. The familiarity that comes from knowing someone outside of work does tend to humanize them and help with relationships and camaraderie (and all those touchy-feely things we engineers aren’t supposed to care about because we’rerobotswhoonlyknowhowtowritecodeanddrinkmountaindewandurinateinemptybiggulps).

In my experience, the real benefit is in improvements to communication and cohesiveness. It’s in the ability we gain to understand each other as people, to know our strengths and weaknesses, to use shorthand in communication, to avoid causing or taking offense, and to just be more effective working together. Whenever possible, I like to participate in non-work activities with my brothers-and-sisters-in-code (and sometimes with others at the company as well) because it makes us more effective. Good companies/managers understand this concept and go out of their way to engage teams in “teambuilding”. This can be a dirty word in the wrong environment. Don’t work in that environment!

ready_to_eat

So unless I have an important errand to run or previous plans, invite me to lunch. I like food.