Week Two At The Iron Yard
Well, we made it through week two of the Iron Yard Indy, and to quote Keanu Reeves at his finest…
It’s a little hard to describe exactly what makes the experience so intense.
If you want to quantify it in terms of its components, then I can quickly summarize for you what you may already know:
- You have instructors with decades of dev and/or design experience, for whom their 10,000 hour-mark is a distant memory.
- You have a cohort of peers who are extremely intelligent, very motivated, and who put in the necessary legwork to prepare for an advanced accelerated course of skill-building.
- You have a curriculum designed to mirror professional workflows as closely as possible, and to demand frequent, proficient, and in-depth use of essential skills.
- Every cohort the curriculum is being iterated on with a meticulous and results-oriented approach.
- You embed this engineering immersion program in Indianapolis, a city with a thriving tech community and strong possibilities of continued growth (if you are uncertain about Indy’s tech presence, you might open with googling “Indianapolis tech boom” as a point of entry.)
Sounds like a promising start, right?
Does it also sound like something that might be tough?
Now if you want to characterize The Iron Yard Indy (TIYI here on out) in terms of its challenges:
- Breaking down problems
It’s pretty easy to solve a toy problem on paper with fuzzy constraints. It gets harder when you start defining and tightening up your constraints, and it gets even harder when you start bringing your vision into reality. As long as you don’t have a product, you can continue to delight in the beauty of an idea without having to worry about anyone else’s judgment — perhaps especially your own.
All of that changes as soon as you start dropping characters in a text file.
Breaking down a problem into pieces isn’t romantic. It isn’t flashy or impressive, and it often isn’t even pretty. For perfectionists with ruthless aesthetic concerns (not that there are any of those around here or anything), giving up entirely on the idea of building something perfect and permanent is a big challenge.
It can be very, very frustrating to invest time and energy into a particular build path when you know for a fact that right at that moment, there are probably at least 10 people in the world doing a better job of building that exact same thing. Not to mention how much better and faster you yourself could build it if you just had access to the right people (which is not to say the right people aren’t at TIYI, but it would be a disservice to you if they held your hand.)
These are recurrent problems that designers and engineers have in common with all other artists, and it’s no exaggeration to say that I’ll either continue to solve them — admittedly in an imperfect and iterative way — or quit development.
It’s nice to have the stakes clear, especially when you’re…
2. Dealing [constructively] with the consequences of your decisions
We make our reality through our choices, and software design is no exception — in fact if anything, it often seems like the software gods take a perverse delight in beating you over the head with that fact.
You make your bed, you sleep in it.
You reap what you sow.
What goes around, comes around.
So you can by all means spit into the wind, look a gift horse in the mouth, or build a platonically elegant and trivially more performant solution that makes your team and future you ragefully embark on the following traversal…
possessions.find {|object| object.sharp?}…but you’d probably rather build something that just does its job pretty well and can be understood by real live humans.
I can’t tell you how many times trying to code an elegant and robustly extensible solution straight out the gate has come back to bite me.
Actually sorry, that’s not accurate. That implies that at some point in the build process my solution stopped biting me and went off to do its own thing. Instead, I have many times found myself scoffing at a perfectly legitimate, complete, and eminently iterable solution with a haughty rendition of “well, that’s the dumb solution and I’m way smarter than that.”
And then I spend hours staring at my screen in an pit of elegant despair.
Great job, smart guy.
Great job.
3. Facing your demons
One of the beautiful and terrible things about making any kind of art that will eventually be seen by others (and I doubt anyone will succeed in convincing me that software engineering is not art) is that you’ll be forced to confront your personal demons.
From the moment you first put brush to canvas in an attempt to authentically create, your fears and neuroses are watching your every move intently, shivering eagerly as they rip and claw to be the first to tear out of whatever dark recesses they inhabit and beeline straight to your most vulnerable places. And while those who promulgate the need to make friends with your fears are far from wrong, it’s also true that at the heart of the matter your demons are not your friends — they will take every advantage given and do every bit as much damage as you let them.
So if you’re anything like me, you may find yourself wondering your own personal version of the following thoughts:
Can I make it as a developer?
Can I find other people who are like me, or who at least value my contributions?
Can I get a job at an ethical shop with an altruistically oriented business model and a crack team of kind and collaborative coders?
Or am I doomed to forever work at suffocating jobs — answering to people who have no ethical imagination — doing things I hate?
Without the confidence and experience to just jump into a project — top-down it, hack it out, and glide smoothly past the inevitable failures — I often find myself spinning my wheels. The indecision can be paralyzing.
In fact, this just occurred to me while writing this — so thank you for that — but I think I would do well to remind myself that basically anyone can code. It isn’t rocket science and it isn’t brain surgery. It’s telling a computer what to do, and it’s even possible to do it effectively with only the most rudimentary understanding of what the hardware is doing (although I should be clear, I do plan on significantly leveling up my understanding of what’s going on in the tower in the near future).
In short, if the solution seems impossibly hard, the odds are overwhelmingly in favor of me being the one who is making it that way. Time to chill out, MVP and iterate.
What’s gooder than that?
