Yesterday I installed NetBSD in a virtual machine on my laptop. I was thinking to myself, “If I could specialize in some *nix that isn’t as popular maybe that would give me an edge up.”

Well, no. That’s just a stupid thought.

Useful ways to get an edge up, or somehow stand out as an engineer don’t involve being a specialist in something that basically no one is using. Sorry BSD. Usually there’s a very good and valid reason why very few people are using or doing something.

Yes, tons of stuff on the web probably does run on BSD. Yes, NetBSD, FreeBSD, OpenBSD, and every other Unix-like system out there is probably holding together huge swaths of the Internet so I can type junk like this.

But upon thinking this over, I’ve realized that what matters is not what you run your application on, it’s what your application does… if you want to be an implementer and not a tool builder.

At this point, I’m not a tool builder. I’m a wanna-be tool builder. I’m trying to get good enough such that I could contribute to tools that I and others use. But I have a long way to go. However, I am an implementer. I’m making things out of pieces and parts such that useful business goals can be accomplished. I’m sticking together tools that others have built in such a way that really hasn’t been done before. I’m helping create business value.

What matters to me, and to probably 90% of other “software engineers” out there, isn’t what’s underneath, as long as what’s underneath can allow me to piece it together with other tools. What matters is that I can pick a decent set of tools and utilities, stick them together, write a little bit of glue, and make something for a customer that solves problems.

Whether what’s underneath is Unix, Linux, Mac, or Windows (eww) doesn’t really matter. What matters is that the tools I need are available and can be made to work together on a platform to accomplish something useful for a customer.

Specializing in Unix, Linux, Mac, or Windows doesn’t completely help me achieve that goal. Knowing enough about each of those does.

What I should do is become familiar with each of the tool sets out there but not be an expert. Not unless being an expert is what’s creating value for others. At this point, me becoming an expert isn’t going to create as much value for my company or our customers as me being a really good generalist, so I should work more on that.

No, I’m not the best C coder that’s ever lived. I’m far from it. But becoming the best C coder shouldn’t be my current goal. My current goal is to be able to see a technical problem and say, “Yes, this tool would be a good choice” or “No, that tool would be a bad choice” and then back up either of those statements.

Here’s where my dislike for Windows and the Mac start to creep in. With free and open software I can see the code, I can fix the bugs, and I can add the features I (and my company) need. I can contribute those back to the community and get code reviews, and eventually, get the community to maintain my code for me in the same way I will do for others in the community. On any of the BSDs, most all Linux distributions, and a growing number of microcontroller platforms, I can do this. They’re open.

Windows isn’t. The Mac isn’t. Therefore, spending my time learning those tools and platforms is a waste because I can’t really understand them, I can’t fix bugs, and I can’t add features. How can I be a good implementer if I can’t fix / improve / give back to the tools I use?

I can’t.

So what matters isn’t that I pick this *nix or that *nix, be it BSD, Unix, Linux or what have you. What matters is that I’m picking up free and open software, learning the tools, and giving back when I can.

If you’re a software developer and you’re focused on a closed, locked down, un-free platform or tool set, you’re doing it wrong!


Published

25 November 2012