I’m tremendously proud of the team at CargoSense. Over the last year (and more), we’ve been in the trenches, building a product line that’s unlike anything our market has ever seen. It’s been immensely satisfying to see the reactions of our customers and hear about the impact we’re having on their businesses. We provide a level of insight that they’ve never seen before – and we’ve worked really hard to wrap it up in a user experience that’s a joy to use. (Not to put too fine a point on it, but that’s not exactly standard fare for, ahem, enterprise logistics software.)

I’m thankful for the technical challenges, choices, and tools that we’ve encountered building CargoSense; they’ve been a great opportunity for my own growth as a software developer – and as a CTO that’s focused on building the right architecture and partnerships to succeed.

Today we announced a little bit of news. Our...

As a member of a software development team, you have opinions. You need to communicate them or your product is going to take a wrong turn, the wrong task will be prioritized, or the wrong technical choice will plague your team’s collective existence until the end of time. That’s just the way it works. You have to speak up.

So, you think your idea could save the day. How do you persuade others?

Well, that’s a really hard question. It’s a big enough one that it could involve me agreeing to write a book, and a very dry, self-help style book at that. Instead, let me pick an easier question to answer. If you’re a technical leader, how should you not persuade others?

Let me tell you about a mistake I make from time to time. Afterwards, do yourself a favor and avoid making it too.

Don’t pull rank. Now, I know you’re going to tell me, emphatically, that you don’t, but think about it: do you...

The connection between languages and identity doesn’t stop at natural, human languages. Ask a software developer who they are or what they do, and often you’ll hear them describe themselves by the language they use most often.

“A C programmer,” one might say. “A Java Engineer,” another could murmur. “A Rubyist!” someone declares with an idealogical gleam in their eye.

These self-professed labels aren’t limiting unless we let them be, unless we decide that’s good enough, unless we stop learning. While it’s easy to pick up our favorite tool every time we need to build something, we need to make sure the tool is well-suited to the task, too. If it’s not, we should use something that is (even learning it in the process). Just imagine what you could build if you were using the right tool for the job and you even knew how to use it?

Don’t disregard perception. While it’s dangerous to see...