Last night [February 1, 2018], after returning from a coding class, I posted about how I had almost played hooky because we were starting a new topic and I was afraid it was going to be too hard.

And about how I’d realized that that was just a tad hypocritical, since I’d just spent three days at Legal Tech talking about how lawyers and law firms shouldn’t fear change.

Today, I got to thinking about why I ended up attending class.

The cons were that I was tired (ie, I wouldn’t be able to concentrate as well as I might at another time), under-prepared (work ran late the previous evening and I hadn’t completed the pre-reading) and, well, it was dinner time and I was hungry.

That is to say, how I generally felt when I was an associate at Herbert Smith and got an email about some training I was supposed to attend.

The pro that got me out the door relates, in large part, to the structure of the class.

Admission to the program took 150-200 hours. The actual program takes an additional ~ 360 hours, plus homework., split between lecture and and what they call pair-programming (working with a partner to solve problem-sets). Interspersed are a series of checkpoints (individual exams you’re required to pass in order to continue with the program). Now I’m in “junior phase” – 9 class hours a week, plus one immersive weekend a month, and associated hw.

Throughout, I’ve been nervous.

In some ways this is silly – I was always decently book smart, and this program is designed to enable people to succeed, not fail.

On the other hand, it’s a bloody computer, and seriously, they think I’m going to make one work?

However, since the beginning, three things have been emphasized:

1. Clear goals, results driven process. Amidst backlash against coding bootcamps that take student money and fail to deliver skills/jobs (reminiscent of certain un-accredited law schools), this program is committed to transparent hiring outcomes. While I’m not planning to change jobs (I’m doing this as a general ed course to be better in my current role at PacerPro), going in knowing that the managers of the program have tracked and measured whether or not their methodology works is rather reassuring. Plus, the student projects from past cohorts are pretty cool.
2. Road-mapping. You know what you’re going to do, when you’re going to do it, and about how long it’s going to take you.
3. Interactive, real-time problem solving. The managers of the program emphasize the importance of being able to work cooperatively in a team (turns out someone measured it, because of course they did, and working in pairs results in fewer errors). The side effect of learning in pairs is that – you get to know your group in a low-pressure, actually pretty fun environment.

In part, the fact that I did a training I didn’t want to – and that I liked it and learned a lot – set me to thinking about how we approach software roll-outs at PacerPro. While we have moved away from software that requires any attorney training (as my brother puts it, trainings are a bandaid for poor user interface), our admin console still requires manager training – and I realized that for those sessions, I would do well to learn from my coding camp’s methodology.

It also, of course, made me wish that more of my trainings as an attorney had been structured this way – short lectures, followed by problem sets where we worked with someone else at the firm trying out the new tool. I think I would have gotten more out of them, and it would have positively impacted team-building (particularly if you paired junior and senior attorneys, attorneys and paralegals, paralegals and docketers, etc).

That said, I know a large chunk of my network has a lot more experience in this realm than I do.

Thoughts?

Editor’s Note: This article published with the author’s permission – first publication on LinkedIn.