Software developers write code. By definition. Sure a lot of folks who are involved in the software making business don't write code, but these people generally have job titles like "architect" or "program manager" or "tester". And so, for instance, when a .Net developer moves into a BizTalk project for the first time they're gonna expect to write code. Because that's what they do. But here's the thing: BizTalk development doesn't need code. It is entirely possible to build an enterprise scale BizTalk application with either no custom code at all or very very little. Every .Net developer who read that just went "say what!?" But its true. With BizTalk development you have to have a very good reason to drop into code, and it takes time to understand when that is. And that's the crux of the BizTalk development paradigm.
I'll bet you that the first thing the majority of developers do when encountering BizTalk for the first time is go for the Expression Shape. Its the natural reaction. And there's nothing wrong with that, but if you're learning BizTalk and you don't spend the time to understand when and why you should write code and have helper classes etc and when and why you shouldn't, then you're not really a BizTalk developer. You're a .Net developer who can use BizTalk (sort of). If you take the time to understand the purpose of BizTalk, the way the MessageBox works, the way all the moving parts interact, then you're a BizTalk developer who can also do .Net development.
Let me put it this way: if I was a tech lead of a BizTalk development team and I was onboarding a new guy, as part of his wax on wax off training to become a BizTalk developer, I'd disallow him from writing code for the first couple of weeks (maybe a month). Only after you've learned to build stuff in BizTalk without code, can you learn to do stuff in BizTalk with code.
I'd be interested to hear comments/feedback on this if you find it provocative.
Mark