I was recently reading another programmer’s blog post on Coding skills you won’t learn in school in which he was specifically talking about Object Ownership. The topic of the blog post is good in and of itself, and if you’re into lower-level programming, such as C, and data structures, like trees, then it’s worth a read.

Programming Problems: Object Ownership

But just as I was closing the tab, I came across the following paragraph at the bottom of his post:

Broken software, bad job offers: I”m sharing my mistakes so you can avoid them.

In short, it’s an invitation to join his mailing list (which is fine), but what really caught my eye was his call to action:

I’m sharing my mistakes.

For anyone who writes on the web – myself included – I think a lot of us do share our mistakes, but I couldn’t help but think about the way we go about doing it.

And it now has me re-thinking the approach to some of the posts that I’ve written and that I’ve yet to write.

Framing My Programming Problems

If there’s one thing that can be said about our industry, it’s that developers are opinionated. I don’t care what segment of the industry you’re in, this is one thing that seems to remain consistent.

I’m not implying this is a bad thing.

But when your peers – both immediate and not-to-immediate – are consistently opinionated to the point of insulting across comments, discussion threads, repositories, and so on, I think that it leads to us wanting to be very careful in how we present the programming problems we’ve solved and the mistakes that we’ve made.

My Treasure Trove of Programming Problems

My Treasure Trove of Programming Problems

This seems to be true both in code and in writing blog posts.

A Digression on Comments

That is to say:

When we write about ways to solve programming problems, I often wonder if we’re not doing it in a way that insulates ourselves from insults from as much as possible.

I know, I know. A bit of that is human nature, right? None of us want to be “called out” or picked on for something. It’s self-preservation and all that. We don’t want to be embarrassed or anything. And comments have gotten so intense in our industry we’re now seeing things such as “Don’t read the comments” across Twitter and other networks.

And I’ve even got a comment policy (which I did not have a few years ago) in which I explicitly state that I’ll moderate comments at my discretion. This is not because I want to make myself look good, but because I don’t want others introducing any form of harassment on others or hijacking a comment thread.

How I Solved This Thing

This isn’t about comments, though. This is about programming problems, right? So remove those from the equation for a moment. Imagine writing a blog post on a platform where comments are off, or it doesn’t event support comments.

Then imagine writing a post that frames how you solved a problem like this:

  1. I was tasked to do This Thing.
  2. Here’s how I initially approached solving This Thing.
  3. Here’s what broke once we released This Thing into testing.
  4. I fixed the bugs that were introduced into This Thing.
  5. This Thing passed QA, so we pushed to production.
  6. Users complained about particular problems in This Thing.
  7. These are the mistakes I made when working on This Thing and how I fixed them.

It’s direct, it’s straightforward, it follows a path of how many of us approach solving problems either for ourselves or others, and its direction admits where we went wrong, who found what problems, and how we fixed it.

It doesn’t dress it up. It doesn’t try to inflate our approach as to why we did what we did. It simply states it as a matter of:

  • this what I’ve done given my experience,
  • this is what came of it,
  • and this is what I learned from it.

I think it’s fair to say that a significant portion of our industry doesn’t value that, though. And why should we expect it to do so? We’re bombarded with phrases like “rock star programmer,” “ninja warrior coder,” and “Jedi engineering skills.”

It’s a bit more intimidating to present ourselves as if we’re consistently trying to better our skills. And, in doing so, we share our mistakes in both writing code and in the written word all along the way.

Why I Did It This Way

All of that to say, I get why I might feel safer to provide that type of explanation within the context of an opt-in mailing list (not that that’s why the author is doing it, but I think it’s a good reason nonetheless).

There are some things I’m working on doing to restructure this blog (for which I’ll talk about in a future post). But maybe one of the things I should reconsider is the why behind how I solved a certain problem – not just that I solved it.

Because I think that should lead to a healthier exchange with some, and it could help others who are reading along the way.

We’ll see.