Professional Development
There are a number of fields where it is or is considered important to be, at the very least, in step with changes in the industry, if not ahead of the curve. Software is one of those fields. As such, it is important to be well or widely read on topics in engineering or technology so you can choose to plan your future rather than be a victim of it.
Software and software technologies change quickly. Even if the changes are incremental, they can stack up pretty quickly. One thing that I like to keep in mind is that professional development doesn't have to be an individual battle. It's excellent to be well-versed in new technologies, but often it is highly effective to be cocktail party conversant in them too. Therefore, it makes sense for learning to be a team effort, when possible.
I recently put together a chunk of significant technology here that is slated to be part of our 6.0 product. I will talk about it in the future, but at present it's still a little raw and still very much intellectual property, so I need to figure out how to cast it in a way that is digestible and useful for you, dear reader, without giving away the farm.
In the meantime, at a daily Scrum I polled to see if engineering wanted to be on the receiving end of a talk about this technology. Response was positive, so I put together an hour-and-a-half lunch time meeting to cover the material. In considering why I wanted to do this, it came down to a small, but important set of reasons:
- In Case I Die - I learned this from a former manager who use to work in the Navy, helping train new crew who would take over a crew that was leaving. Especially in a small environment, anyone who is a key contributor should be asking the morbid question, "what would happen if I died?" While it's slightly depressing to think of yourself as mortal and replaceable, it is still vital to make sure you can mitigate the effects of you disappearing. Teaching others what you do and how you do it is one way of meeting that goal.
- To Make The World a Better Place - I like to learn and I like to teach. I think that everything gets better with both. If can help make my peers better engineers or I can be a better engineer by listening to my peers, then we will make better products. Everybody wins.
- Inspiration - very often, I create enabling technologies. Atalasoft itself is a vendor of enabling technologies for you. You purchase our products and have to worry a lot less about the fiddly details that go into image processing. You worry about what you're going to do and less about how. That's a win. In addition, showing off internal technologies is a way for your peers to see what you're doing and ask the question, "what could I do if I had access to this technology?" That leads to more product ideas and a healthier suite of tools.
- Honing Your Mad Skillz - presentation and communication are skills and they need to be exercised to get better. For me, this is not a big deal because I'm a ham. For others it is. I cannot stress how important communication skills are in a software team and formal presentation of something complicated will help your informal communication when you're trying to pair program or explain a problem you're having. There's also another side-effect - when you're prepping for a presentation, you may find that you will be doing some refactoring along the way as you start to put things under a microscope.
When you're prepping, allow about three to four times the length of your total presentation for preparation - more if you need to practice. Me, I'm pretty good at speaking off the cuff about things in which I'm well-versed, but I also know that I'll be missing talking points or important details. I accept that trade-off grudgingly.
When you're preparing to prepare, take a cue from the teaching professional and think about the Learning Outcome of your presentation. Make a short list of (probably no more than 5) things that you want your audience to be able to walk away with. Look the list over and make sure that the items are at least specific and realistic (these are two elements of the SMART system for making goals, by the way). While you're putting your presentation together, if you're stuck trying to decide whether to include an item or not, make sure it hits one of your goals.
Tell them what you're going to say, then say it, then tell them what you told them. This technique gives your audience a way to keep oriented and it makes it easier to follow where you are. There's nothing like a good summary at the end to help cement the learning. I didn't do this at my last presentation and I regret it.
Be true to your own style, but don't forget that humor helps. Myself, I like to recognize that my audience for software talks usually consists of nitpickers. In fact, if someone is picking nits with my presentation, it tells me that they are engaged and except for having momentum killed, I consider that a good sign. Personally, I like to acknowledge that I'm intentionally avoiding all the seamy details by labeling specific things in my talks with "THIS IS A LIE." It's kind of like Dave Barry saying, "I swear, I am not making this up." It's a nod to my audience that time does not permit me to tell the whole story here so I'm intentionally lying to you, and maybe I'll tell you the truth later, but in the meantime you can believe that data packets are magically transformed by fairies from Gumdrop Lane.
Don't be afraid to do kinesthetic exercises to explain complicated tasks. Several years ago at a different company, I architected a general processing pipeline for managing data flow operations in an application. I did a presentation to our sales and marketing staff so they would understand the capabilities of our technology. It was being built more flexibly than it strictly needed to be so that we could react to requirement changes that customers might have. To that end, I described the overall technology then illustrated the pipeline by giving each person a job that was analogous to worker elements in the pipeline. Then I started running data through the pipeline by passing note cards to the first person in line. Based on their instructions, each person examined the card, decided if they needed to do something (trigger an action or modify the data), do it, then pass on the message. It worked perfectly and really made it clear what could be done with the technology. It also stressed how something apparently complex could be built from fairly simple, easy-to-create parts.
Do good work, be open to learning from the good work your team does, and be open to sharing what you've learned.