I recently wrapped up rewriting one of our team’s core business applications. It’s an important application for our customers.
Just as important, it helps justify my headcount position within the team, as the revenue it generates ultimately funds my salary as well as the salaries of my fellow coworkers. That, in turn, allows us to continue adding new features and functionality to our core business apps and increasing revenue for the company.
The original app desperately needed an extreme makeover. It involved a lot of tedious and manual processes that required a person to spend a significant amount of time to complete the business process the app was supposed to help address.
My job was to take that old app and rewrite it in a way to integrate with several enterprise-wide frameworks and systems.
Most of the technology I was going to need to use as part of this rewrite was stuff I already knew about and was familiar with.
But there was one big piece of technology I was very unfamiliar with … a message brokering system called RabbitMQ.
And don’t ask me about the rabbits, Lennie!
A message brokering system is much like those corkboards you see on college campuses or in supermarkets where people can post announcements for new events, “for sale” or “help wanted” ads, or whatever someone wants to advertise to any people who might be interested.
Anyone can come up to the corkboard and peruse what’s been posted. In message brokering parlance, they are referred to as “subscribers”. Those that post things on the corkboard are the “publishers”.
The whole reason behind creating a corkboard/message brokering system, is you have no idea which subscribers are interested in what publishers have to offer. All you’re doing is creating a conduit for publishers and subscribers to know about each other, but you have no idea if and when that will happen.
E-commerce type systems often use some sort of message brokering system to handle monetary transactions. In this case, a seller is a publisher and a subscriber is a customer interested in what a seller has to offer.
The system I was rewriting used at its core the RabbitMQ message brokering system.
And I had no clue how it worked, and more importantly, how to incorporate it into my rewrite.
But like it or not, I needed to get up to speed quickly with a brand new technology. There was no other alternative technology stack available.
Pretty standard procedure for software engineers, actually. We may have lots of experience with lots of different technologies… it’s the nature of the business.
But the rub is technology is always progressing, always evolving, and it never stands still.
It’s actually what keeps me in the software programming game. How many other professions can claim the same thing? How many different ways can you drill a tooth? Or fix a car engine? Or land an airplane?
But of course, the onus is on the software engineer to learn something new, FAST. You usually don’t have the luxury of spending a huge amount of time getting up to speed with a new technology.
That’s where the power of prototyping comes in handy.
At least for myself, the quickest way I learn something is literally by doing it.
And that’s exactly what I did. I installed the RabbitMQ software locally on my development computer and used it as my own personal sandbox environment.
I created all the core objects which RabbitMQ needed… Exchanges, queues, routing keys, creating custom event handler listeners.
And I began reading and studying the quite excellent documentation which the creators of RabbitMQ provided.
It wasn’t long before I began grokking the core concepts and technology driving RabbitMQ.
This is the true power of prototyping and working on proof of concept applications.
It’s important for software engineers to defend the importance of prototyping. Sadly, not everyone agrees time and resources should be spent on it.
Management may balk at the time you, the software engineer, asks for to get up to speed with a new technology.
It’s the classic engineering versus business conflict. The business arm of an organization obviously wants everything done yesterday and under budget. The technology wing of the company will argue about the business decisions and direction the company chooses to head.
It’s happened with every organization I’ve ever worked for, and I’m at the point in my career, where I’m not shocked when I’m asked to forego any technical research when I’m unclear on a particular technical concept or technology.
But that doesn’t mean I’m not going to learn it, one way or another.
If time doesn’t get allocated or approved on the company clock, to learn something new, I’m going to learn it on my own time. It’s that important.
If I don’t learn it, I’ll end up floundering around, wasting my time and more importantly, the company’s time, shooting in the dark and making wild guesses about how to implement a new piece of technology.
So the next time management, or whomever, balks at the time you want to set aside to learn something new, don’t just let it slide. It’s worth the effort making your case. There ain’t no such thing as a free lunch. Everything comes at a price, especially learning new things.
And no Lennie, stop asking about the rabbits.
