Feature Chats

Overview

A casual look a the power of discussing your side-project with like-minded friends.

Once Upon A Time

…there were two developers, who needed help staying on top of their team’s Pull Requests. One developer said “I shall write an app to help myself! I shall query the GitHub API and expose the things that matter in a way that works for my brain!”

They started pondering aloud how they would approach the problem, and soon the other developer said things like “ooh” and “cool” and “you could…”

But, the developers soon realized that while they both wanted to stay on top of their team’s work, they had very different priorities and needs. The second developer, having seen the value of the core idea, set off to make a very different app. Their parting was amicable. Two friends with different needs.

As the days unfolded, the developers would get together and chat as they munched upon their breakfast or lunch. They would discuss the problems they were working through, and features they were considering. Ideas, suggestions, and even warnings from hard-won experience were shared. Each developer cheering their friends successes, and helping them when things were difficult.

Recently

Those discussions branched into two different apps. Dachary made PR Focus, and I made DevGood, which I’ve yet to release. Simultaneously, I’ve been working on Backup Brain which is a completely unrelated Bookmark Manager. Dachary’s got a handful of unreleased iOS apps she’s been working on in the background too.

Yesterday Dachary was discussing how she’d implemented the upcoming ability to “Tag” Pull Requests in PR Focus. I’d already implemented tags1 in Backup Brain and pointed out, that while she doesn’t need to address it in the initial version she will need to support the ability to rename tags, and have it change on all the PRs with that tag. She pointed out that that “just worked” because of how she’d designed her data model.

I realized that in my quest to not fall into the trap of using MongoDB as if it were a relational database, I’d gone too far and not used relations when I should have. I’d “painted myself into a corner” as it were.

This morning, as we munched on breakfast and she chatted about how close she was to finishing tag support, I realized that my situation was even worse. I want Backup Brain to autocomplete tag names as you type them in, but I can only do that efficiently with a centralized list of tags.

Insight

My tags problem is pretty trivial in the grand scheme of coding problems, but Dachary noticed the very non-trivial thing that surrounded it: our discussions.

Our apps have become so much better as a direct result of the discussions we’ve had. Sometimes it’s as simple as solving a problem by Rubber Ducking it with the other person. Sometimes we avoid issues entirely by describing what we were thinking of doing, and having the other person point out problems we hadn’t foreseen, or alternative approaches which would be way better. Sometimes the other person has hard experiences & perspectives that we don’t, because they’ve lived different lives & learned different things2.

She noticed that it didn’t matter if the apps we were discussing were even remotely related. The same challenges come up again and again in wildly divergent codebases. She codes in Swift & Swift UI. I code in, well a lot of things, but usually Ruby and Rails. She’s working on user requested features for her PR Tracking app. I’m working on random stuff for a Bookmarking app, and yet we keep coming across places where the current work, or work that came up in discussions is relevant to what we’re working on today.

Takeaway

Being best friends with a developer you trust and live with is uncommon. We have a definite advantage over most in this regard, but that kind of arrangement isn’t required. What you need is a similarly minded geeky friend with projects of their own, someone who’d enjoy chatting about their geeky projects with you just as much as you’d enjoy chatting about yours with them.

Find someone you can hop on a call with over lunch & work through an idea. Set up weekly chats, or meet-ups. Talk about your code. Shoot the shit. Enjoy your friend, and help their project be great. Let them do the same for you. Allow yourself, and your friend to dig into whatever part of the discussion seems interesting. Drill down on “silly” programming details and questions. Allow yourself to be ignorant in front of them, and allow your friend to help explain things to you. Trust them to not think less of you for not knowing literally everything. Do the same for them.

It doesn’t matter if you code in the same language, framework or whatever. The only thing that matters is that you’ve both got projects you’re frequently working on.

So, go forth, find a friend, and chat! Make better apps. Become a better developer.


  1. I’ve spent a lot of time thinking about, and hunting down existing academic research on “tagging” in knowledge managers. There’s some very cool research that’s been done on how people categorize and retrieve information, and how we can support that with tags & related techniques. ↩︎

  2. It’s almost as if diverse perspectives within your team help make a better product that helps more people. Imagine a world where automatic soap dispensers worked for all the black people, and AI didn’t spout disproven racist medical advice to doctors! Gasp! this post & short video about Meredith Brousarrd’s book More Than a Glitch: confronting race, gender, and ability bias in Tech. ↩︎