A huge part of writing code well is communicating effectively. I hear it all the time. I tweet it. I co-sign it. I get it.
But it wasn't until we sat down with Aldric that it really meant anything. Up to that point, we'd mostly communicated with each other, Vinney and I. We pair most of the time, and we're always in each other's head. I took a lot of that for granted until we found ourselves waiting sheepishly while Aldric poked around our app in what would be our first code review.
He paused at a method.
"So you're returning all the events. That's a lot of events."
"Oh no, it just returns upcoming events."
"But it's called 'all_events' ..."
*pause*
"Yes. Yes it is ... We should probably change that."
It was the first of many face palms. But more importantly, it brought a lot of tangibility to the programming mantra we'd accepted. The problem with "communicating effectively" is that it doesn't identify who I'm communicating with.
Till then I'd likened it to writing a blog post or a personal essay. There is an ambiguous Audience. I'm not sure what it's looking for, or what it's doing here, but it's nice to see you! And I hope you find something here that tickles your fancy. But among Audience, I expect that only a small percentage will really "get" it. And if you don't get my tone or my slang, I can brush you off and claim this just wasn't *for* you. I don't optimize my writing for the Audience, I optimize for the few.
It doesn't really work that way in coding. I'm communicating with every coder. Every coder should get it. And my intent should be crystal clear.
I admit it was a bit exasperating to focus so much on method names. It felt like there were so many bigger design problems to talk about.
But it forced me to confront why it mattered so much. Why naming was such a topic at the Flatiron School. Why it always seemed like such a big deal. And it all comes back to communication. The whole point of communicating is to establish a relationship, a sense of trust, a platform to build on. Naming was the beginning of the developer-outside-developer relationship. It established expectations. It was the first time I was communicating with Aldric. And in my somewhat-ambiguous naming, I had broken that trust. If my names mislead him, he’ll not only begin to doubt more complex decisions I’ve made, but he’s forced to look beyond the name and understand the work each method is doing.
It destroys the role of the method as an api for the other developer. He can’t take my method at face value, he has to see it and understand it before he can use it. Not the best way way to start a relationship.
It was a great reminder of who we were communicating with and why communicating effectively was essential, even in the seeming simplicity of naming. And now, instead of wondering if I’m communicating effectively, I find myself peering at our method names and asking a much deeper question -- “What would Aldric think?”