What Whiplash Teaches Us About the "Sink or Swim" Method in Engineering

I love movies - Particularly ones that can be referenced to bring a point home in a professional discussion. Such is the case with the movie “Whiplash” and the debate over the “sink or swim” methodology in engineer onboarding.

Quick Recap

Whiplash is an American film from 2014. It’s great. If you haven’t seen it, you should. Don’t take my word for it, though - it got  and is . J.K. Simmons got an Oscar for playing Terence Fletcher, a conductor and bandleader, and the character I want to focus this post about.A short reminder about the plot - Andrew, an aspiring young drummer and student, enrolls into Terence Fletcher’s ensemble, hoping to become one of the greats. During the film, he (like the rest of Fletcher’s students) suffers harsh and repeated abuse at the hands of Fletcher, who is cruel and unforgiving. Here’s a scene where Andrew discovers what he got himself into:Later in the film, Fletcher reveals that there is a method to his madness. His goal is not to be a conductor or teach his students. His goal is to discover and give rise to a phenomenal talent. Generations of traumatized students who are pushed to their limits, will be a worthy sacrifice, if only one of them rises to greatness. Here is the scene where he explains this to Andrew:

What does Whiplash have to do with Diving into a Codebase?

We have talked with hundreds of engineering managers and mentors in the past few years about how they onboard their engineers. A recurring theme we heard was the “Sink or Swim” method. This means that new hires are thrown in at the deep end, getting tasks from the backlog from day one, with little or no help. Actually, this is what inspired my co-founder, Gilad Navot, to come up with the name of our company - Swimm (because every engineer should swim).The justification to this method is that it weeds out weaker developers, who eventually sink (leave or get fired). Some of the most prestigious companies employ this method (no name dropping here). There are no chairs flying or slaps to the face like in Whiplash, but there is a lot in common.You might be thinking - “Okay. That makes sense. It’s survival of the fittest.” Maybe you have been through a similar experience and believe it was beneficial. You might be right. There are situations where this method is best, particularly if you’re hiring for a high pressure role that requires extreme independence and being able to deal with uncertainty. However, our experience is that most engineering roles are not like that at all.

So what can be the drawbacks of using Sink or Swim?

No second chance for a first impression. You do this to weed out 10% who you think are not good enough for your company. However, by doing so, you also create a very hard and unwelcoming onboarding experience for the other 90%. So the first impression of your company you create is this:

If you have a problem, no one is going to help you, because you’re expendable.

Not the right test. Are you really sure that the 10% that left were a weaker fit for your company? Ask yourself what working as a veteran developer in your company is like. Do you still constantly feel disoriented, never know where to find anything you need, don’t really know any of your colleagues and who’s in charge of what? If that is the case, the sink or swim method is probably a good choice. However, you should really find a different company to work for…

So if a new hire doesn’t thrive in that kind of setting, it really doesn’t mean they won’t thrive after they learn the ropes.

Lost time. Onboarding could be so much more efficient, if there’s good mentorship and preparation. In other words, using sink or swim means your new hires will take more time to become effective, and you will lose precious engineering time.

The “Dog Paddle”. An engineering manager we met at Google told us that the worst outcome of the sink or swim method is not the new hires that sunk - It’s the ones that “dog paddle”. These engineers just barely made it through, but they never really learned everything they needed. They can stay with you for years, suffering from low self efficacy and messing up basic tasks. You taught them to survive, but you never taught them how to be excellent.

So why is this happening?

If this method is so problematic, why do so many companies, managers and mentors still use it when onboarding new engineers?We believe there are two main reasons:

1. Ideology or Excuse

Many mentors refer to this method as an ideology. Which is a different way of saying that there’s no need to prove that it works or that it is the best method. Again, for some, this is in fact the best choice. However, we have found that many mentors use this ideology as an excuse. Which is easier? Admitting that the checklist you call an onboarding plan is terrible and you don’t really have the time or skills to make it better, or convincing yourself that it is lacking on purpose?

2. Old Habits Die Hard

This is a classic dynamic, particularly in situations where there are veterans and “newbies”. If you were “thrown in the deep end” when you first joined your company, it will be hard to treat a new hire differently, now that you’re the veteran. Doing so would mean acknowledging that what you went through was not really necessary - Something you preferred to repress.

Recap

So what about Fletcher then? Was he right or just sadistic? I will leave it to you to decide. I will tell you this - turns out the story Fletcher tells about the great Charlie Parker and the flying cymbal in the 2nd clip above is not entirely true - .Oh. And if you have seen the film, you will enjoy revisiting the fantastic last scene in these two clips (*** Spoiler Alert***  , ).

Hey, I’m , co-Founder of , a DevTool we launched after witnessing how engineer onboarding practices could massively affect R&D effectiveness. My background is in Tech, Training and Policy. I hold a Masters in Public Policy from Princeton, an MBA and a B.Sc. in Physics and Math.

Previously published at

Lead Image illustration by , Steelbook Competition, 2015