Technical Competence and the Interview Process

As I begin the job hunt all over again I am renewed with the realisation that sales skills, although possibly only rarely used in day to day coding, are as important as ever. Over the last 2 days I have been talking with friends, former colleagues, recruiters, HR and connections from all of the above in the Perth IT market regarding jobs.
The people who dont know me just want to to know what in vogue technical skils I have. Buzz wordy stuff that pass with the wind like WPF, MOSS, Asp.Net MVC etc etc
These technologies are all great at helping us do our job faster, prettier and more consistently but they only HELP. Core coding concepts, IMO, are of a much greater importance. I am not a WPF guru. Can i learn it? Bet your ass I can, in fact I am now. I give myself 6 weeks to do so and to be come good at it. Why six weeks? As I have been around the block a few time i have picked up a few technologies, API's & languages over the time. What i find is the more technologies, API's & languages I learn, the faster I can learn the next one. There is such a thing as "learning to learn".
In the past 2 years I feel I have become a much better developer in general.
Alot of that knowledge has come from reading the dozens of books and thousands of blog/forum posts, watching multitudes of videos and seminars and attending and presenting gigs like the Alt.Net open spaces... basically all the things that have stolen quality time from my friends and loved ones. Alot of that knowledge has come from using 3rd party API's that both kick ass (like StructureMap) and suck (like Infragistics). You learn from both, however it is with continuual exposure to new APIs that you are exposed to overall patterns and styles that you begin to associate as good or bad.
for example: Over the last couple of weeks I have found myself talking to a few friends and colleagues about the Law of Demeter. Infragistics is a perfect example of why this law (or guideline) exists. Having 5 properties chained off to change a setting in the grid is stupid and shows poor API design. Having not used this API i may not have "got" that specific law (lemons => lemonade). ;)

Learning languages like Python, Boo, F# and Ruby highlight the strengths and weaknesses of my own day to day language C#. It also highlights the fact the Java, VB.Net and C# (or whatever other c based managed language) are basically the same and people who argue between C# over VB.net or Java over VB.net need to learn a new language. Possibly they just mean they believe the .Net framework or libraries are better than java (or vica versa etc) and don't realise it.
Anyway...
Having been in the position of the interviewee and interviewer now I can see what I look for is basically the opposite of what recruiters look for... well to a degree. I assume by the time the candidate has got to me the recruiter has figured out the candidate has
-used .Net for a number of years
-has used the basic technology we are interested in (win, web, services, messaging etc)

What I look for is if the candidate has just done the one technology, eg just Asp.Net over WinForms for example. I mean they can not help that their employer dictates that what they used, but they can, in their own time, investigate other angles. In this instance i would also ask
-Have you used an MVC framework such as Monorail or ASP.net MVC?
-When did you use it and which version?
-what did you find different/better?
-Did you ever use it in production?
-have you used JSP, Ruby on Rails or Groovy on Grails or any other web based framework in another language?
-What CMS's have you used... etc etc
I don't care really what the answers here are, I am just fishing to see if this guy is a 9-5er or someone genuinely interested in his job. A 9-5er would take what the boss has given him and stick with it. Someone serious about their job investigates things outside of his comfort zone and finds out why this alternative exists and evaluates if it can help him perform better.

I also look for basic OO skills. If the candidate has never used Asp.Net but has ninja coding skills and is passionate and enthusiastic I would take him on. I can teach a monkey Asp.Net in 3 weeks. I cant teach enthusiasm. By that notion i also look for the knowledge of test and mock APIs and the use of framework libraries (e.g. castle and spring) as they tend to show the candidate understands the benefits and quality of code that can come with using such a tool.

Unfortunately this logic does not bode well with recruiters who want to pattern match. So the sales hat goes on to please the gate keepers. My problem is I wont lie to get a job. It has probably cost me some pretty kick ass roles/pay packets but, you still have to look yourself and co-workers in the eye everyday. The problem is the recruiters encourage it. My tack is to try and sell the global picture, its just not that easy. The same is true for interviews with non technicals such as PMs. They don't care if i know the intricacies of 5 different IoC containers, they want to know if I delivered production ready software on time, and so they should! However they still have the notion of patten matching. My lack of an ultra specific skill may have cost me a job yesterday (you will never guess what that skill is!). The problem is the guy would have given the job to someone of much lesser ability who had the the skill listed on his resume in a previous job. He has been hunting for months for this person... which to me would mean alarm bells ringing if I was him. If i fell in to that situation i would look for good people that you can train. If the good person has the skill set, awesome! If not, get the best you can and train them, FAST.

Fortunately I know people in the market and luckily I haven't burnt any bridges and have forged some pretty good relationships here in Perth. Which is lucky, because Perth is a small very well connected network. So hopefully mouths start moving and the word gets out that a new developer is in town ;). Otherwise I may follow a good friends advise and make it a leisurely summer of freelance development and lying on the beach, corona in hand.... things could be worse ;)

I would like to hear other comments from others... from the perspective of both the candidate and the employer.

cheers
Rhys

Announcing Gallio and MbUnit v3.0.4

Jeff brown has recently announced the release of the new MbUnit and Gallio suite.

Looks to have quite a large number of improvements. For more details see Jeffs write up here

"Im leaving on a jet plane..

..don't know when I'll be back again"

Yep so its my last week here in the UK as I pack my stuff and get ready to head back to the land of Aus. First up will be Perth to catch up with my better half then we decide wether to stay in Perth or venture eastwards and see if Sydney/Melbourne are better suited for us and our plans of world domination.

The plan is to head back to London in the new year, but the with the current climate London is not boding well for us (my partner is in finance), so we would rather be in the sun while riding the "crunch" out.

I would like to thank the team at Channel 4 for having me most of the time is was in the UK. I would especially like to thank the team for placing the faith in me with the VAPS project and letting me run wild on the new architecture & design. I really think it is going to be a lot easier to work with, test and maintain so stick with it.  :)

I would also like to to say thanks to the "London .Net Meet Up" guys the "London DNUG" and most of all the Alt.net guys who have been great sounding board.

Fingers crossed that the world is in a better state and London is a viable option for us in the New Year. Until then is back to hot sun, cold beer and Water Polo... oh and some code here and there ;)

Loosen Your Domain

Really good 101 on using messaging in a system.
http://www.viddler.com/explore/PhatBoyG/videos/2/

DTO's from XSD's

Something I found out today. The xsd.exe from the VS command prompt can create your c# XML representations for you. Its lightening fast and means you can use code like this to get you XML to a CLR type:
MessageBase messageLoader = xmlSerializer.Deserialize(new StringReader(messageDocument.InnerXml)) as MessageBase;

Where MessageBase is my base abstract message class (this is obviously for getting XML messages off a queue). Of course this casting works with interfaces too.

Awesome! Thanks to Jamie for the heads up :)

Friction on new projects

As the last post mentioned, I have been involved in a new project at work so it has been a good opportunity to introduce the team to some new concepts and investigate a few things my self.

Firstly the good:

• The last post mentioned that I have cleaned up the way we do stuff in terms of "code on the page". Its always good to be able to clean up coding standards
• introduction of IoC using Structure Map. I choose SM as I felt it was one of the most user friendly for those un familiar to IoC. I have used the Castle a fair bit however, what is good for me is not necessarily best for the team.
• Introduction of Rhino Mocks. Even though at work we are still .Net 3.0 Rhino Mocks we felt was a good choice over NMock2 as it has more fwd compatibility and the strong type of the delegates is well received (I hate strings)
• A much more refined user friendly architecture and overall structure

The Bad

The Friction on TFS, MSTest and MSBuild has been, to be honest, amazing. If the same project was using SVN, Nant and (N/Mb/x)Unit the CI would have been trivial, 30mins if all went well and maybe a couple of hours if things got a bit hairy. Not so with this nasty little threesome. TFS in itself is pretty good at combining check-ins with bugs/tasks and it has a nice interface. However the price tags and the pain in the ass it becomes when anything else needs to be done is just silly. MSTest, well does any one like it? As for MSBuild, well I don't mind it, I just prefer Nant as my main build script

So if you are going to go Greenfield be sure to check out what you need to do to get the whole system up and running. Unfortunately the powers that be a petrified of any OSS entering the realm of their MS world... I should probably keep quiet that the ORM, IoC, AOP, Logger and who knows what else all fall in to the banished category...

So this week I guess I will have the fun of putting my fingers in to all of this mess. I am not really sure where to start.. CI Factory? Until then we just have a continuous compiler

Cleaning up bad NHibernate/DDD practices

I have of late managed to be involved in a new green-fields project at work. I am sure everyone can relate to the elation you get when you have the opportunity to work on something new an "do it properly this time". I have had the privilege of being able to set everything up how I wanted. Not being a complete ass I have tried to get the team involved as much as possible and explain why/how I am doing things along the way. I think the thing I have found most enjoyable is setting up the means to creating a decent domain.

For the first time we have

• A clear delineation between value types and entities
• real value types
• generic repositories that only allow entities*
• protected empty constructors on all entities forcing you to construct the entity with the more public greedy constructor that actually puts the entity in a valid state
• Corrected sub classing of entities when behaviour is different for different types
• Non insertable type field on subclasses (that match the discriminator column) so the guys can still query "the old way"**
• Protected setters by default
• DBC that matches our DB & business constraints, down to the setter level
• A serious drive to push DOMAIN logic in to the DOMAIN objects
• Specifications

This is all pretty basic but these key aspect were not in our last big project. It may sound like having one repository per aggregate root would be a hard thing, but to be honest its a good thing and the headaches it could have saved my on the last project; NHibernate issues (transient state/dif object same id etc) and more importantly undetected business rule errors in the code.

What I am really hoping is that now the the hard work has been done that the team can more clearly see why we do things in the way we do them.

*I need buy in from the team on the whole Entity/Value type thing before dropping the Aggregate Root bomb shell

**Again this is perhaps not the best way to do it, but I feel for the moment its the best way for the team, while moving in the right direction

Ruby continues its war path

Ruby is now supported in VS thanks to the guys at SapphireSteel Software

More info:
http://www.infoq.com/news/2008/10/rubyinsteel-personal

So now i can have Python and Ruby from VS.... nice.

MSTest == Fail

I know i have already blogged about my dislike of MSTest, but this POC is really getting to me. The amount of hoops you have to jump thru to get it working in anything other than VS is just beyond me. I am seriously thinking of pulling my team over to MbUnit because this is getting out of hand.

• Its slow
• Requires Visual Studio. This makes it pretty dirty when setting up build servers. So now our build server has an instance of VS on it... well done M$, you just got an extra license becuase you suck.
  
• Poor integration with MS build; M$ own build script language. Why the hell does this not have native MSTest tasks? Hel go one step futher and make a pluggable interface so any test framework can be directly integrated.
  
• Using config settings just doesnt work. MS in all there wisdom decide to exclude files from the build dir that you have explicitly said to include. Well done morons. No i have to put dirty hacks in my tests to pick up 3rd party config settings.
  

Compare this with MbUnit. Um... there are no issues, well none that i have come across. Its fast, it integrates well, it has no wired application requirements...I just dont understand how one of the biggest software munfacturers in the world can balls this up so bad. The fact that the software is for developers just means any mistake will be amplified, you think they would make it better than anything under the sun... jeez they even had JUnit, NUnit, MbUnit (and many more) to copy from. You would think a product that you are paying for would at least be as good as the free alternatives.
My disappointment continues.

Book, Book And Books

I have decided to throw up a list of books I have read over the last year on my website. Up until .Net 3.0 I never really read a lot of tech books, the Google machine answered most of my questions. On the pending release of .Net 3.0 I realised that the web was not going to offer me the answers i wanted and the head start i needed, so i got closer to the source. I grabbed a few of the books and realised the benefit of actually reading up on info BEFORE you needed it.

My usual reason for reading articles, blogs etc was because I had a problem and need to get around it. To be honest that's a pretty bad way to approach your profession. A doctor doesn't go and read a heart surgery blog when he has accidentally torn the bicuspid... well i hope not.

Another push toward my now ever growing library was Alt.Net Seattle earlier this year. Sometime you just don't know how much you don't know. Meeting guys like Martin Fowler, Brad Abrams, Udi Dahan, Greg Young, Ayende etc and talking with them face to face, you soon get a reality check. Luckily I was not the only on there that felt this way.

A few of us (and i don't want to drag these guys down to my level) started interrogating the Big Guns on what we need to do to get to the next level. Now we are not schmuck devs, but we realised the way to get up to the next level is some structured learning. The likes of Dru Sellars, Greg Young, Ian Cooper, Udi Dahan and Jarrod Ferguson were incredibly helpful in passing on there recommendations.

Since then I have stepped up my reading of about 1-2 books a year to almost 20 since late April, that's just shy of a book a week! I feel like a sponge, sucking up everything I can get my hands on.
The improvement is the quality of code has improved, my ability to acknowledge that MY code may need to be refactored is now apparent. My TDD skills are far superior to the start of the year. DDD is something I actually understand and can implement (whether i do it well is up for debate). Because of my improve domains Service Orientated Architectures are easier to create and evolve. My awareness that as a senior/lead Dev coding is only one of the small areas of my job. The ability to release good quality, testable, stable applications and do it fast are all thing we must manage.
The only problem is what the hell do I do with all these books? Being the travelling man I am, I now have dozens of kilos of books that i can not (cost effectively) take with me back to Australia. Damn, because many of these are books you want to keep around the office or at least easily accessible at home.
Anyway the page is not up yet but it should be under http://www.fullstack.co.uk/articles/library.aspx soon. Check it out. I am only going to put up books i think are worthwhile reading, so if its on there go buy the book.

.Net and cloud computing

Looks like Windows (and therfore .Net sans Mono) and MS-SQL will be availiable soon on the amazon cloud:
http://www.infoq.com/news/2008/10/EC2-Windows

Loose coupling: The Illusion

I must say I totally agree with the sentiment Jeremy has here. Loose coupling is an illusion to most of the projects have worked on. The project I current work on has the client UI in a distributed system knowing that we use NHibernate as our ORM. Unbelievable. Needless to saying Unit testing this solution is VERY hard! To me, this is the first place where loose couping rears its head. If you can not unit test a class due to concrete dependencies rearing their ugly head, then its either

• Deal with the fact that you are not, in fact, loosely coupled or
  
• Fix it.

As mention in Jeremy's post having separate assemblies is not loose coupling. At best this forces a direction of flow of control, at worst it hides circular references or creates the illusion of loose coupling. Jeremy doesn't break his solution down to quite the project granularity I do and nor do others (JP Boodhoo for example is know to have very few projects in a solution). The notion is that you are not trying to hide behind the perception of more assemblies == less coupling. You can also separate the single project into multiple assemblies in your build scripts if required. It then becomes a gentleman's agreement amongst the team that coupling rules will be adhered too. Now this is much easier to police with a tool like NDepend.

Currently I am without NDepend so I still break up my solution to multiple projects, for a couple of reasons. I like to be able to visually see what is going on quickly and I like the default name spacing that is then applied (Sure this can be done with folders too). Probably the aspect I like most however is that i can see what reference what at any given time by checking the references (again, we don't have NDepend on this project). By opening the UI project I can now see that Data Access references are made, or there are WCF references in a Data access project. Without NDepend this is my last resort to policing the silly things that go on in the current (and no doubt futures) project.

With NDepend I would certainly be moving toward smaller projects. *Thinking out loud* I think a common assembly for server side (with my default and abstract data access/repository stuff) a server side assembly and a client side assembly. It kinda makes sense. If none of that server side stuff will ever be accessed by an other application or assembly then why break it up? Hmmm...

Anyway, on the path to loose(r) coupling consider a couple of things:

• Are you using a Test first approach. Although it is not necessary it tends to flush out dependencies early on
• Are you using a means of Dependency injection? If you are new'ing up dependencies in line then you have just tightly coupled yourself to an implementations. Check out this for a start on DI including poor mans DI, which is still infinitely better than no DI, IMO
• Code to interfaces not implementations. I always thought this was a pretty obvious statement, but apparently not. Your DEPENDENCIES should be interfaces. Anything you interact with in terms of Actions (ie methods or delegates/events) should ideally be via the interface. I very rarely see a point of having DTO's implement an interface...
• Stream line code that interacts with the unmockable (file system, DB, WCF/Windows services etc) ; it should be as thin as possible. Try to get your working code out of these classes. This is more of a testing issue, but will also lead to better design.
• Get NDepend. It is a kick ass tool that i wish my boss would get for me :(
• Code reviews. Get out of trouble at the first sign, its very hard to "loosen up" an app once the tight coupling has set in.

Loose coupling is a design goal we should strive for but I believe it deserves a bit more than just lip service. Get the team on board an explain the benefits. The earlier this begins in the project timeline, obviously, the better