The Development Kraken
I have trained a lot of people on Microsoft BizTalk Server over the years and one thing always struck me. The general feedback that I would get from developers was that they had given BizTalk a shot and gave up or started a project, got it running, but had no idea how it was working. They had reached the end of their rope.
Now, BizTalk and ESB concepts are not exactly light reading. In fact, it can get pretty complicated (I always loved showing this poster). I was always shocked by how people looked at these tasks like they were insurmountable problems. There was too much there and there was no way to get their hands around it.
I think of these kinds of issues as the development kraken. At first you think everything is going fine, but then you start leafing through the product documentation and get a little uneasy. Everything is still good, but you can see the monster out on the horizon. You create a development environment, but nothing makes sense. All of a sudden, boom one tentacle hits your ship. Still everything is okay, you think I can still manage this. Soon, a week of work time has been burned and you feel as if you know less then you did when you started. The ship has been wrapped up and you are going down fast.
So, how do we conquer the development kraken and start learning new concepts and languages?
Break it Down
Every big task can be broken down into smaller component pieces. I really like the tactic that Tim Ferriss applies for these kinds of problems.
- Identify the main components
- Find what you will most commonly be doing
- Look for patterns and commonality between components
- Exploit those relationships
For enterprise systems like BizTalk, we can do the same breakdown. We have two main components, Administration and Development. If we are new, we will probably be starting with development. Let’s look at what we can develop: pipelines, orchestrations, maps, schemas. Since most everything is based around schemas in BizTalk, maybe you decide to work there first and get a good understanding of how they are built. From there work your way up. Your understanding of schemas will make understanding mapping far easier, so that becomes your next point of learning. This pattern will continue to spiral out until you have got it all covered. All the while, you were only having to learn one new component at a time.
Google it to Hell
Chances are that you are not the first person to come across this technology. If you were, then you probably wrote it and should already be an expert, so go grab a coffee and put you feet up. Otherwise, open your browser, hit ctrl+k and start searching away.
When I was first getting started with BizTalk, there were not a lot of resources, but fortunately there was an excellent, small community of Active Developers online. People like Richard Seroter, Steef-Jan Wigger, Eric Stott and so many others became an immediate wealth of knowledge. They had posts about new features, issues, examples, etc. It was like peering over their cubicle and being able to take handfuls of brain popcorn out to snack on. Most posts only took a couple of minutes to fly through and at the end, I had a pretty good idea of what kinds of challenges I was going to come across.
I always get a hard time because I keep a pretty sizable amount tabs open. Usually, I am hovering around 40-60 tabs at any given time of the day. It isn’t that I am looking at any of those tabs at any time, but as soon as I come across an idea or an issue, I search it up and open new tabs on the first handful of relevant links. If you open 5 tabs, chances are 3 are pure garbage or some kind of link farm advertising. So, while they may have a few nuggets of good data, they are probably going to be instant closers. Chances are that the other two will have something good in there. The point of opening up the first 5 or 6 links is that you will have them at your disposal without either having to do your original search again or going back. Sometimes, what you need is maybe a link or two in from where you originally landed, so having that site open in its own tab will ensure that you can dig deeper without fear of losing what you already had searched for.
Look for Examples
If you are already online looking for information, you should also start amassing a list of examples. Whether it is sample code or tutorials, any kind of example is helpful. I usually try to pull down the code and start tinkering.
Go Buy The Book….Now!
In fact, buy all the books. If reading blogs and online documentation is like eating brain popcorn, books are the gray matter buffet. Someone or a group of someones sat down and decided to pour all of their knowledge into a tome all for you and they are only going to charge you a nominal fee to get to that knowledge. $50-100 for a book is an unbelievable deal for the amount of knowledge you can get.
I am always amazed at how much people are put off by reading technical documentation, especially developers. This is actually pretty upsetting. So you are telling me that by the power of grayskull you are going to just learn how to code the hell out of something? Think again. There is a reason why people say RTFM.
There is no way around it, you need to put in the time. Between reading and running examples, you need to log the hours. Some people will say you don’t, but I think this is one of the most important aspects.
For me, when I know I have something large that I need to learn, I cut out all other media. I am always shocked by how much extra time I gain, if I cut out simple things like tv, video games, etc. The more time that you spend immersing yourself in the topic, the faster things will click.
So, there you have it. Those are my steps for conquering the development kraken. What do you think? Do you have a different tactic? Let me know.