Thoughts After Coaching 12 Rails Developers
Over the last two days, I've done twelve 30-minute coaching sessions with the students of thoughtbot's Learn Prime program.
Here are some notes I took.
Student A who has no programming background is trying to learn Ruby at the same time as Rails. Too hard, I told her. Recommended she check out the Ruby section of JumpstartLab's curriculum, which they've generously open-sourced. Have I ever mentioned what a mensch Jeff Casimir is?
Student B gets overwhelmed when he can't figure out how to write an integration test for something and freezes up, ends up writing no code. I told him to watch what thoughts he was having when he was frozen, and to question whether they were true. Straight up CBT baby. I also told him to start a new app where he's allowed (encouraged, really) to write totally crappy code. In thoughtbot's apprentice program, we call this a "breakable toy".
Student C has, despite his best intentions, chosen a schema that simply does not match with Rails' view of how data should be modeled. As a result he was fighting the framework and reinventing its already-provided wheels. I tried to gently convey the badness of his idea, but I didn't do a great job and accidentally overgentled. I don't think I conveyed the lesson as strongly as I should have. Next time.
Student D really wants to work at thoughtbot, so I recommended he gather some code he's proud of to start his application. I think he'll get in: his enthusiasm about the idea was contagious.
Student F has been the strongest programmer at each of his jobs. I recommended he seek out people to pair with at his Ruby group. Too far away. Recommend he act like a badass and start his own hackfest closer by. And/Or change jobs. Don't be the best programmer unless you're the CTO.
Student G, a newer developer, asked how to model his problem domain. I gave some advice, but shared with him the Go maximum: lose your first 100 games as quickly as possible. Nothing like a dozen Rails apps under your belt to make modeling questions easier to answer.
Student H is on a rescue mission for a PHP app with a gnarly database. His goal is to replace the PHP app with a Rails app, and has started a Rails app that reads from the existing database. Kinda. I recommended he start a new app from scratch with a sane data model and start working on what would certainly be a massively-annoying import script.
Students I, J, and K all want to know how we integrated Discourse with our own OAuth endpoint. Open-sourcing that (and helping the Discourse team get it in their codebase) are totally on my to do list, just not quite high enough yet.
Student L wanted advice on his MVP's interface, but we ended up chatting mostly about his business model. I tried to convince him to build for subscribers, not one-off purchasers. Here's hoping that was actually an improvement.