mentorship

Dependency Infection

I’m getting more and more comfortable with the fact that design principles just don’t come as naturally to me as I’d like them to. I need to study them. I need to practice them. And I need to search outside myself for examples of object oriented programming done right. When I find a great example, I get really excited because I feel smarter for having seen abstract concepts at work in the real world.

Example: You know who’s really good at OOP?

The Joker, that’s who.

Today we learned a bunch of stuff about dependency. Dependency happens when one part of a program needs another part of the program in order to function properly. If I built a program based on a Coke machine, the robotic arm that grabs the Coke would need to depend on the information passed along by the purchaser’s button press, or else it wouldn’t know what type of can to grab. If I changed the order of the buttons, the machine would probably send me the wrong beverage can unless I also reprogrammed the robotic arm. Thanks to dependency, that “reprogramming the arm” job is now a necessary part of the “change the button order” job… unless I can anticipate that the buttons might need to be changed around from time to time, and then find a way to plan for that eventuality in my machine design.

That planning process is one of the main pillars of OO design, and it has a lot to do with something called separation of concerns. I think. Someone correct me if I’m missing something, I just learned this as of this morning. But assuming I’m on the right track, separation of concerns is the art of telling various pieces of the program, “Do this and exactly this and only this. Know that and exactly that and only that. If you need help with something, ask only this one other thing for the right information. Anything beyond those three tasks is not your job. It doesn’t concern you.

The object oriented programmer is like a master thief who assembles a variety of tools to pull off the perfect heist. Only these tools aren’t just tools, they’re people, and they need to work together in perfect harmony. But here’s the catch: the whole score must end up in the master’s hands. None of the other thieves can get a piece. But how does that even work? How can you get a big and complicated job done without telling each worker enough information to rip you off in the process?

The Joker knows how. He comes in with a plan fully hatched and then implements each piece in turn. Good programmers do the same thing, only instead of bank blueprints and instructions for each wannabe master thief, they use whiteboards and pseudocode.

I’m not a planner by nature, but you can bet your ass I’m becoming one at DBC. The challenges are becoming more realistic now, and that means workloads too big to mess round with on the fly. It’s getting increasingly harder to write code that fixes bad code, because there are enough moving pieces that I inevitably write more bad code and create entanglements that turn my app into a brittle and inflexible mess. Like a house of cards ready to tumble if a single queen needs to be swapped out for an ace, strongly interdependent programs have objects that aren’t easy to update later on.

Think of the real world implications. Your client expected the project to come in on time and under budget, and you made it happen…at first. But now, they decide they want to change how user data is submitted, and you look at the source code and realize you have four other structures that assumed the user data format would never change. Now, your client thinks you just need to tweak a feature, and they expect to pay feature tweak money for the job. But you’ll need program rewrite money because you let your little thieves know too much about other thieves’ business. Guess who’s leaving in the bus full of money? Your code, not you.

Dependency management is a fascinating principle and I need to spend a lot of time practicing it this weekend, whether it’s alone, with a mentor, or as a cohort. We’ll all be meeting on campus tomorrow to hold each other accountable for our success as a group. A few of us could probably benefit from a phase repeat, but we’re trying to get that number down to zero through hard work, focused practice, and a healthy dose of empathy. The all-stars among us will focus on teaching the strugglers. Ultimately, we’ll all learn from one another. I plan to do a lot of teaching and even more learning as I try to break out of my comfort zone and work on the skills that good leaders need to have: patience, compassion, trust, enthusiasm, and the ability to see awesome potential in the people I’m working with. And I hope my partners will see my potential when I’m the slow learner in the pair.

When the idea for a cohort-wide learning blitz first surfaced, there were concerns that people on the bubble might not get the push they needed to pass – after all, how can you move ahead when you’re reaching back to help someone behind you? But someone suggested that the moderate-mastery coders in our group could pair off together and feed off one another’s similar skills to learn new things. Like a virus, optimism spread  through our ranks and got us really fired up to code during the hours many would have reserved for free time. The sacrifice will be worth it. This weekend will make us all stronger.

And that’s a really good thing. Because we’re not code or thieves or Coke machine arms. We’re human beings, and there’s no rule against us depending on each other a whole lot.

Bobolinks, assemble!

Advertisements

Dev Bootcamp Rap Recap: Week 1

Let’s try something different on the weekends, yes?

Yes.

Listen up.

Annotated lyrics below:

I’ve only been here for a week
But I’m already feeling like it’s gonna be the year of the geek
My peers in this effort are clever and clearly unique
Climbing this mountain and a coding career’s what we seek
And while we’re nearing the peak, we have Sherpas
who pack for us and transform us from bad learners
into stack warriors fast forwarding our grasp on how the code works. 
It don’t hurt to ask for it if you need guidance,
cause the speed frightens the bravest of souls
searching for knowledge they can aim to control. 
Working with scholars trying to daily expose your vast ignorance
leaves a bitter taste in your mouth like black licorice;
I won’t candy coat it, it’s hard work for most folks,
but getting through it together is how you grow close.
This OO and TDD is no joke at DBC…
who needs degrees if your code’s dope?

Time to put an end to the foolishness
I got foo-bars and drop gems like a Rubyist.
The loop exists until I’m greater than or equal to great
at believing mistakes are the building blocks of usefulness.
Cause perfectionism’s a recipe for hurting
but still, some people do it to themselves like recursion…
this is programming examined by a wordsmith
my stack’s overflowing with verses. 
You ask if it’s worth it, 
like, “should I really have the time to blog?”
maybe you heard it’s long nights involved and that’s true. 
But if I’m never signing off I’ll burn out like a dying log
and that’s realer than a float or an integer
I’m trying to state the obvious: 
you gotta save time for yourself like a modulus, 
cause if it’s nothing left over you’ll stress over the smallest little problems
and not arrive at accomplishment.
That’s why I gotta spit sometimes
I’ve only got one mind
adjusting to the hustle of crunch time.
I bust rhymes and return to the screen craft
with a passion for tapping keys, stabbing at tab as I punch lines…
So what’s prime? How do you test for it?
Describe the type of data structure that’s best for it.
I’m going in like a nested array
debugging out till the end of the day.
– thIIIrd person

Back to the keyboard tomorrow. This was fun. Let’s do it next week.