I just finished listening to a software development podcast and towards the end of the panel discussion it got rather heated, or perhaps it just sounded that way on an MP3 and you just had to be there? At any rate - one of the panel members (seemed) to lose it a bit and a started raising his voice and getting his back up over what he seemed to think was an unfair statement or sentiment regarding 
one of the technologies under discussion. Anyway, this reminded me of something I want to try and be vigilant about and observe and that is not to be the guy in the corner losing his cool, cause the moment you do that you have lost the argument, your credibility is diminished and respect from your fellow debaters and audience will be lost. The software development business is littered with opportunity to shoot yourself in your zealot foot but try to resist the temptation, I know I will.
Something that intrigues me is the very nature of the way software development skills are rated. It’s not altogether unheard of that the more technology specific stuff you put into your resume the better understood or rather perceived you might be and the more design and practice oriented stuff you put in that resume, may find you perceived all the more esoteric.
I am pretty sure that too much attention in my resume given to practices such as DDD and DI /IoC amongst other things, has been been perceived as fringe and understanding of their value was getting lost in some cases. Typically employers and recruiters are often more interested in how many years of Ajax, ASP.Net, Web Services, ADO.Net etc that you have and I should point out that this is not a criticism of either merely an observation; it comes down to the individual to demonstrate what indeed the value of such knowledge and skills are to any relevant interested party.
So basically I guess my point is this, if your constantly finding yourself perplexed
by what skill you need next, then perhaps you should look at the outlying aspects rather than the obvious and make sure that you give some time to practices or learning new patterns that will help improve the quality of your work regardless of your technology choices. I should point out that whilst many would consider Inversion of Control a technology (I use IoC as an example here), I consider it more a methodology or design practice for the sake of this post and demonstrating the point I am trying to make.
So rather than worry about WCF or WF 4.0 or some other fancy PDC 2008 technology today, perhaps look at Castle Windsor or Spring.Net and begin to get to grips with how DI / IoC can help you write better software or even buy Jimmy Nilsson or Eric Evans books and have a look at Domain Driven Design and see what you can learn from that approach - a wise man once told me "it’s not always about the latest tech!"
PS: I am not saying you should ignore new things as a matter of course (I plan to look at Oslo and M in the coming months myself) but try to balance and give some priority to assigning value to that of the here and now!
One thing I often remark is my preference for developers who exhibit habits that identify them as being ‘invested in their careers’. One such habit (in my humble opinion) is regular listening to pod casts however I should say that if a developer doesn’t listen to pod casts does not mean that they are not invested, perhaps they have other such ‘invested’ habits. Anyway, this post wasn’t meant to be a discussion of what are and aren’t the habits but rather a list of pod casts that I listen to and think are worth checking out if you weren’t aware of them previously.
THE LIST:
There was a compiled list of pod casts knocking around recently that is more complete (I will post a link when I can find it) but these are the ones I listen too regularly.
one of the technologies under discussion. Anyway, this reminded me of something I want to try and be vigilant about and observe and that is not to be the guy in the corner losing his cool, cause the moment you do that you have lost the argument, your credibility is diminished and respect from your fellow debaters and audience will be lost. The software development business is littered with opportunity to shoot yourself in your zealot foot but try to resist the temptation, I know I will.
