james mckay dot net

Jeff Atwood wrote an interesting post the other day where he asked the question, Is Open Source Experience Overrated? He quoted an anonymous developer who had lamented not being able to find a job despite being the architect of a couple of open source projects:

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no – but it seems his impression was already set based on my performance in the coding test. The coding test did not indicate what criteria they were using for evaluation but my solution seemed to kill the interview.

I must confess that I was a little bit incredulous when I read this. It seems the correspondent was expecting the recruiter to consider his open source contributions as a substitute for his poor performance in the coding test — and it would be an irresponsible recruiter who did that.

The problem with open source contributions is that they don’t necessarily tell a recruiter what they need to know about you. They indicate passion and enthusiasm for programming, which is a plus, but they don’t necessarily indicate competence — and passion is no substitute for competence. In fact, some open source projects, such as this example cited by Ayende the other week, are very badly written and do not reflect well on the developer. And in the recruitment process, it’s competence that a responsible recruiter will be looking for first and foremost. That’s why it’s so important to have a coding test. The team needs to have a certain baseline standard, and that standard needs to be treated as a “must have” — failing the technical test should be an automatic “no hire,” regardless of passion or experience. Yes, they should take a look at your open source contributions, but they only really become relevant in the later stages of the recruitment process, once they have carried out the technical screening and are getting into the final round of interviews.

Here are some examples of things that a recruiter may want to know about your abilities that he or she is unlikely to find in a typical open source project:

• How quickly you can write code
• How quickly you can troubleshoot code
• How quickly you can learn new technologies
• The extent of your understanding of the company’s core technologies (how much you have committed to memory, and how much you need to refer to the documentation)
• How well you can understand and implement customer requirements
• How clean you can keep your code when working to tight deadlines
• Whether you can grok recursion
• Whether you understand Big O Notation and its implications for performance
• How well you can integrate with the rest of the team

Different companies also have different attitudes towards open source. The ones that are most likely to be interested will advertise job openings in the open source community itself — they reason that that way they have a generally richer pool of talent to draw on than the hordes of unqualified and mediocre people that you get in places like monster.com and recruitment agencies. Larger organisations, on the other hand, are only likely to take notice if your contributions are to a project that they’re actually using, such as NHibernate or Tomcat, and some companies actually have a prejudice against it, so it pays to do some research and bear in mind that YMMV.

One other thing. If you want to pitch your open source contributions to your prospective employer, you need to make sure that your code is the best quality that you can give it. You might find that they take it into account in ways that you hadn’t expected, and if you’re doing stupid things such as silently swallowing exceptions, or writing thousand-line, hundred-parameter, multi-responsibility, copy-and-paste methods, or giving them names like DoIt(), or if your code formatting is sloppy and difficult to follow with inconsistent indentation, it may work to your disadvantage if they ask a technical reviewer to look at it. Open source coding isn’t like coding for work or profit: you have no deadlines, so you can afford to give it a lot more tender loving care.

Comments closed »

Posted at 08:00 on 20 April 2009.
Tagged: Jeff Atwood, open source, recruitment

If I can give one single piece of advice to ASP.NET developers anywhere, it will be this:

Learn another web development environment.

I really can not emphasise this strongly enough. From what I’ve observed, developers who only work with ASP.NET seem to have quite a bit of difficulty thinking outside of the Microsoft box. I am frequently confronted with indiscriminate and even inappropriate use of aspects of the .NET framework that don’t scale, such as DataSets, view state, or drag-and-drop programming. There’s nothing wrong with all these per se, but one of the most important things you need to know about how to use them is when not to use them. When all you have is a hammer, everything starts to look like a nail.

The ASP.NET Web Forms model in particular was originally designed to make web development look like Windows development, and ease the transition for VB6 developers from programming for rich Windows clients to the web. The result of this is that it has made the easy aspects of web development almost brain dead, while introducing a horrendously leaky abstraction layer that makes the hard things even harder, with masses of gotchas and pitfalls to trip you up if you venture outside it.

Languages such as PHP, Ruby on Rails or Python don’t have the same leaky abstractions, so developers tend to not only program “closer to the metal” but to think closer to the metal as well. This is why most of the cool sites, with stunning Ajax effects, tend to be written in these languages and target these platforms, while ASP.NET is largely languishing in the enterprisey world of Dilbert-esque cubicle farms.

I recommend you choose your alternative carefully, however. Rails and Python are the best choices. They will teach you patterns, practices, conventions, O/R mapping, MVC, and all round agile and pragmatic programming, and they tend to be taken up by smart and experienced developers who know what they’re doing. I have mixed feelings about Java: while you can learn a lot from it, like .NET it is very enterprisey, and at a time when everyone is getting excited about dynamic languages, Java is heading in completely the opposite direction. And I certainly don’t recommend PHP as a learning exercise: it is a beginners’ language — and a mind-bogglingly badly designed one at that — and while PHP guys are generally pretty enthusiastic and some of them are quite smart, and there are some decent PHP frameworks such as CakePHP and Symfony, the overwhelming majority of the PHP community simply don’t have what it takes to be programmers. Having said that, you need to know it, simply because it’s so pervasive.

You should also learn Linux if you can. It will teach you about modular design and the value of scripting everything that can be scripted. This is right at the heart of why Unix is Unix: a large part of its philosophy involves chaining text-based programs where the output of one can be passed as the input to another, to produce some fairly powerful command-based functionality, and scripting repetitive tasks so that their outcomes can be reliably reproduced. These are philosophies that seem largely lost in the world of Windows, which relies much more heavily on the visual, drag, drop and click approach of dialog boxes and wizards, even though they are every bit as essential if you want to have robust procedures and practices in place.

And whichever platform you take on board, you simply must familiarise yourself thoroughly with CSS, DHTML, JavaScript and Ajax, and at least one JavaScript framework such as Prototype or jQuery.

Personally, I still think that ASP.NET is technically the best platform on which to develop scalable, high performance, reliable web applications. However, in order to make the most of it, you need to have a good feel for what approaches you can import and learn from other platforms. Otherwise you will be stuck with the limitations and leaky abstractions of Web Forms.

Comments closed »

Posted at 14:00 on 6 June 2008.
Tagged: .NET, best practices, Java, PHP, programming, Python, recruitment, Ruby

Now if things carry on the way they are going, one of these days, we are probably going to get an application for our developer position from Zefram Cochrane. He’d be more than welcome — I’m sure that someone smart enough to invent the warp drive should have C# pretty much figured out by now even though he hasn’t been born yet, though I shudder to think what his penchant for loud heavy metal music would do to our score on the Joel Test.

Of course, Dr Cochrane is just trekkie fantasy, but even so, reality at the beginning of the 21st century does occasionally send us applications such as one (with no CV attached) from someone claiming “Ihave 34 year experience in asp.net c#” (sic). Given that in the absence of time travel and warp drives, no-one will have 34 years of experience of C# until 2035 at the earliest, I think we’ll wait until then before sending that guy the coding exercise we use as a screener. However, by that time, chances are that C# will be the new COBOL, having been replaced by something more esoteric.

It also sends us ones such as this e-mail the other day that was simultaneously funny, annoying and at the same time rather sad:

This Email is to introduce my company and to ask, if you can give us a chance to prove ourselves and provide our recruitment services to your company.

My name is ______, I represent a Recruitment consultancy called __________. I am attaching my company’s Terms of Business for your consideration and rates wise we are flexible like 12 – 15%.

We mainly work in IT sector e.g, (Web Developers / Designers; Software Developers, Testers, Business Analysts and Project Managers).

You have written that you wont accept calls from AGENCIES so thats why I am emailing you to try my luck.

Please consider and respond positively & if you have any questions please feel free to ask.

In other words, “I see you’ve said no agencies, so I thought I’d write to offer the services of my … agency.”

It boggles my mind to think what was going through this guy’s mind when he drafted this e-mail up. Did he think that because we aren’t taking calls from agencies that e-mails are fine? Sorry, we don’t say “no calls from agencies” — we say “Strictly NO AGENCIES please.” That means no phone calls, no e-mails, no letters, no carrier pigeons, no agencies, period.

Or does he think that because he’s called his company a “recruitment consultancy” that somehow exempts it from being an agency? Sorry, it doesn’t.

If you are a recruitment consultancy, whether you like it or not, you are an agency.

If you are a headhunter, you are an agency.

If you are enquiring on behalf of anyone other than yourself, you are an agency.

(Strictly speaking, that means that even if you are somebody’s girlfriend, calling on behalf of your better half, you are an agency, though that is admittedly probably stretching the point. Okay — strike that, if you are getting paid to enquire on behalf of anyone other than yourself, you are an agency.)

I’m not saying there’s anything wrong with agencies per se, other than that the quality of developers that they come up with can be pretty unpredictable, but as with all things such as these, we have a strict company policy in regard to these things of “don’t call us, we’ll call you.”

However, that aside, does someone who doesn’t understand that “no agencies” means “no agencies” really have the right stuff in his head to find us a competent developer? Methinks not, somehow…

Comments closed (2) »

Posted at 14:00 on 30 May 2008.
Tagged: recruitment

We got an application in from a seemingly very talented web designer the other day in response to our job posting. With some pretty impressive artwork on her online portfolio, she might be a serious consideration if we were looking for someone to fulfil a role involving primarily graphic design.

However, there is just one question. We are looking for a developer, rather than a designer — so will she make the grade in that particular department?

I get the impression that the difference between web developers and web designers is somewhat lost on many people. This is probably quite understandable — the edges between the two is a rather blurry one, with a good deal of overlap, and both require a lot of creativity — and many people manage to handle both roles remarkably well. However, they involve completely different skill sets and aptitudes.

Designers tend to focus very much on the front end. They are (or at least they should be) good at art and graphic design, and if they are designing for the web, they should know HTML and CSS. They will be able to produce great WordPress themes, Flash animations and other eye candy. They most likely also know some basic PHP, MySQL and JavaScript.

The great unknown, however, is how well they can handle the more technical aspects of building a web application. Some of them are good at this, some are not so good. It is all too easy to forget that web development is software development — as a web developer, you are concerned with the much more technical aspects of the job. You need to understand database normalisation and object oriented design patterns, for starters, otherwise you will end up producing unnecessary duplication and bad code. You also need to have a firm grasp of security — at the very least you should understand topics such as SQL injection, cross site scripting and defence in depth. Then there are other aspects such as data structures, string manipulation, regular expressions, web services, scalability, caching, threading, concurrency, transactions, and so on. If any of that sounds like Klingon to you, then either you are not a developer or else you need to mug up on a few basic essentials.

Indeed, since you have to understand fairly difficult concepts such as concurrency, scalability and threading, web development can actually be harder to get right than traditional desktop development.

I sometimes wonder if web development gets such a bad reputation for the quality of code sometimes because there are a lot of people out there describing themselves as web developers when actually they are better suited to working as web designers. In order to be a good developer you need to be able to think at multiple levels of abstraction at the same time, pick up on patterns in things, and so on. Not everyone has the brain circuitry that enables them to do this.

By all accounts, a good test of this is how you handle recursion. Many people — even some computer science students — simply can’t understand it, viewing it purely as a bug that causes a stack overflow and therefore needs to be avoided. However, being able to use recursion effectively is a fundamental skill that crops up over and over again in programming. Traversing a directory tree, the nodes in a DOM document, or the page structure in a hierarchical content management system, should be second nature to all developers everywhere.

Comments closed »

Posted at 14:00 on 29 May 2008.
Tagged: design, programming, recruitment

We’re looking to take on another developer.

The majority of our work is in C#/.NET, so obviously we’ve adjusted our skills requirement accordingly. However, what we are really looking for are smart people who get things done and have a real passion for what they are doing. If you’re smart and passionate, it isn’t a disaster if you don’t have two years of .NET experience, because smart, passionate developers can pick up pretty much anything very quickly, and besides, in this game you have to be learning very quickly all the time.

So, how can you identify the passionate ones?

For starters, I personally think that CVs tell you very little. When I see your average developer CV, my eyes tend to glaze over and all I see is white noise. They show that you have x years of experience in y platform, and that you know what all the current buzzwords are, but that is about it. They don’t tell me whether you spent those x years cutting and pasting code snippets out of those stupid PHP tutorials that teach you to write SQL injection vulnerabilities, or whether you were implementing recursive algorithms and Markov chains in your sleep.

No, the easiest way to get a decent first impression is to Google them and see what their online footprint looks like. You can typeset your CV in Comic Sans for all I care, but if we find you have a blog, we will sit up and take notice. Merely the fact that you are going beyond the 9-5 mentality and showcasing your skills to the world puts you head and shoulders above the crowd.

However, even then, there are blogs and there are blogs. Some developer blogs are very dry indeed — they consist of little more than a string of deadpan howtos and regurgitations of whatever SDK you are using. I’m not saying your blog shouldn’t contain any of those at all, but you need to convey some life with them. What’s the story behind the bug you’re blogging about? What’s your opinion on Hungarian notation? I don’t care if you say something I don’t agree with — the very fact that you actually have an opinion and aren’t being totally insipid is worth a tremendous amount.

Even better are contributions to an open source project. They don’t have to be in .NET — if all your publicly showcased code is in PHP, that’s fine. Rails is even better, simply because Rails developers seem to be the most passionate ones of the lot. One of the best conversations with another developer that I’ve had in a long time was with a Rails developer at MiniBar about a year ago. His enthusiasm was infectious.

And this is where my gripe is. Why don’t we see the same passion and enthusiasm in .NET land?

This is something I’ve noticed in general. PHP often has a reputation for producing a lot of bad code, but PHP developers are much more likely to blog, and their blogs frequently seem to have a lot more sparkle to them. The PHP guys that I know may not necessarily be brilliant coders, but they almost all have much more passion and drive than their .NET and Java counterparts. I think it’s fair to say that this exhibits itself in higher standards too, particularly visually: more often than not, PHP and Rails blogs are pure eye candy, and you certainly never see any of them producing anything as gross as purple and blue Lucida Sans.

You see it in the open source world too. My friend Sam McGeown recently lamented the fact that there are no real .NET WordPress killers. I don’t think it’s likely that there ever will be either: open source is generally acknowledged to be very much a second class citizen in the Microsoft ecosystem, and far too many open source .NET projects simply peter out and die completely after a year or two.

Some people think the problem is that Microsoft has been dragging its heels over open source for far too long. This is true to an extent, but apart from that, the problem is that the .NET (and to a lesser extent, Java) ecosystems are just too enterprisey for their own good. They tend to find their niche in large development teams in large companies, where developers are generally small fish in a huge pond. In the enterprise, you are spending all day every day implementing frustratingly crazy business rules, and you are not writing code for the end users but for their bosses, who often won’t sign off on an Ajax drop down search if it costs them an extra five hundred pounds. In an environment such as that, code gets written to the lowest common denominator and there can be little impetus to pull out all the stops and go the extra mile. The way up the career ladder is not to become a better developer, but to step off the coding ladder altogether and into project management, or enterprise architecture, or an MBA, and make way for another generation of mediocre programmers.

Unfortunately, nearly all the developers in the .NET ecosystem seem to have most of their commercial experience in that kind of setup. They can maybe offer us seven or eight years of experience as 9-5 developers, but the passion just isn’t there. Sure, there are people who buck the trend, but I can’t avoid the conclusion that the overwhelming majority of smart, passionate, enthusiastic developers work with PHP, Rails and Python.

Comments closed (1) »

Posted at 08:19 on 20 May 2008.
Tagged: .NET, enterprisey, programming, recruitment