jump to navigation

writing your own language is bad, m’kay ? September 13, 2006

Posted by Imran Ghory in Software development.
39 comments

Joel Spolsky‘s been at the centre of some recent controversy over his VBScript extending language Wasabi — what really shocks me is not that he wrote his own language, but the appalling lack of ability of those attacking his decision to give a coherent argument against it. Forget C – universities obviously need to go back to teaching students rhetoric.

Even some generally intelligent high-profile bloggers such as Jeff Atwood attacked it without giving any justification other than a vastly over-simplistic “writing your own language is bad, m’kay ?”.

Out of the hundreds of people who have commented on it I’ve not seen one person suggesting a reasonable alternative for Joel’s business problem.

So I’d like to throw out the question what would you do in the following situation:

You have a product which is deployed to client web-servers and is written in VBscript, your market research has indicated that having your product work under more web environments (i.e. non-VBscript ones) would bring in significantly more sales. Having looked into it you find that getting the clients to install a new run-time environment or language is unviable – too many are unwilling to do this. So you have to use something that’s already installed almost everywhere (or at least everywhere you can’t deploy VBScript) – a quick look at Netcraft will tell you that the answers PHP.

So now you know you need to port your app to PHP, how would you do it ?

You could do it by hand and then forever after have two codebases you’ld have to keep in sync. Anyone who’s ever tried to do that before will know down that path lies years of pain and maintenance nightmares.

You could make a framework in both languages which is data driven, trying to move as much of your application code as possible into the data. But this is essentially the same as coming up with a new language and writing an interpreter for it in both PHP and VBscript.

You could write a program which turned your VBScript into PHP. This seems essentially the route Joel took (adding some extra functionallity while he was at it).

Anyone have any other suggestions for how you would solve this problem ?

Because frankly Joel’s solution is the best programming solution to his business problem that I can think of.

Who needs good software developers anyway ? August 7, 2006

Posted by Imran Ghory in recruitment, Software development.
83 comments

One of the interesting replies to my previous post on developer recruitment was a claim that shocked many of my other readers – the essence is captured in the following quote: “For most of the developers working in the industry, coding is about cut and paste“. Shocking maybe – but realistically it’s true.

The majority of developers working today are working on fairly straight forward systems doing fairly simplistic things like tying up a gui to a database. For the most parts that means you don’t need to be a good software developer, broadly speaking it doesn’t matter if you don’t have an in-depth understanding of your programming language or lack a formal comp sci education.

However there is another world, a much more fun world in my opinion although others may disagree. A world in which you need to have expertise in your language, where you really need to understand what exactly your code is doing and often how it’s achieving it. A world in which you need to be a good software developer to survive and get the job done.

I’d argue that this world is fundamentally composed of two types of companies:

  • Those for whom their software is their competitive advantage
  • Those which have complex mission critical systems

The second type in some ways a subset of the first; in that if those companies didn’t have good software developers not only would they lack competitive advantage, but that they wouldn’t even stand a chance in the market.

One easy way to identify who needs good software developers is to look at who’s hiring good software developers. And one way to do that is to look at their interviewing practices. If a company gives a heavy technical drilling, expecting the candidate to write code, debug on paper, discuss algorithms then chances are that they want good software developers. But because good software developers come at a premium it’s a reasonable inference that a company which has a solid technical interview process actually needs good software developers.

If you’re interviewing for a company that falls into one of the two types I’ve mentioned above and they’re not probing you technically, then I’d suggest running away very very quickly. Chances are they’re not going to be around much longer….

So who actually are these companies who need good software developers then ? – well going on the earlier assumption that generally only companies that need good software developers would try to hire them: if we could find a list of companies that had tough technical interviews that would probably be a reasonable approximation. Fortunately there are several such lists the most prominent of which is probably Gayle Laakmann’s site on tech interviews.

Going through the companies on Laakmann’s site they all nicely fit into the two fundamental types I mentioned above. A lot of them are software companies either shrink-wrap (Microsoft, Apple, etc.) or software-as-a-service (Amazon, Expedia) in which the strength of their software is their primary market advantage – the benefit to them of good developers is obvious. Some are defence firms (Boeing) or similar where robust and reliable mission critical systems doesn’t give them competitive advantage but are a simple requirement if they want to operate in the market.

And some like the financial firms (Goldman Sachs) fall into both types – high-quality, reliable and efficient software is required to maintain advantage over your competitors. When a few milliseconds delay in executing a trade can be the difference between profit and loss paying a small premium for the best developers is a no-brainer. And on the complex system side you can’t have developers building sophisticated multi-threaded trading systems. You really do need to have an in-depth understanding of issues such as synchronicity and floating point number implementations when you have literally billions of dollars at stake.

So when you next see someone commenting on developer recruitment, pause for a minute and consider which of the two worlds they come from. If their opinion shocks you it may be because they do come from another world. Metaphorically anyway.

Tech CVs: the lies ! the lies ! July 19, 2006

Posted by Imran Ghory in recruitment, Software development.
38 comments

There’s nothing more likely to get you thrown out of a job interview than it becoming obvious that you’ve lied on your CV, coming a close second is coming across as completely incompetent in your area of expertise.

So you would hope that it would be common knowledge not to put things down on your CV which you don’t know about. I can’t imagine taxi firms get applicants who think having sat in a car qualifies them at drivers, or people claiming to be French translators due to having slept through 5 years of french lessons at school.

Yet IT seems somehow different…there seems to be an obsession with having magic words on yor CV. As if having “J2EE” or “XML” will turn you from a Clark Kent candidate into a Superman candidate. Sure having those keywords may get you that interview, but once they find out you’ve lied there’s a good chance you’ll get blacklisted from that company forever.

And if you’re applying through a recruiter say good-bye to all those juicy high-paying jobs sitting on her desk. One of the most important part of a recruitment consultant’s job is maintaining a good relationship with her clients (the companies, not you, who do you think pays her?) – and if you’re pissing her clients off she’s not going to risk letting you interview with her best clients.

For some reason the worst offenders seem to be the newly graduated, i’ve had graduates claiming C experience not knowing what “printf” is, I’ve had graduates with 3 years Java experience not knowing what a JVM is. And to take the mick I’ve had a candidate who put Python on their CV who when asked about it answered “Oh I don’t know Python – but I was planning to learn it when I wrote my CV”.

I’ve come to the conclusion that one of the main problems is that candidates especially junior ones might think that they know more than they do, simply because it’s hard to tell how much you don’t know unless you’ve been in an enviroment surrounded with people who know a lot more than you.

So to help solve the problem I’ve come up with a list of common tech skills and languages people put on their CV along with the minimum level of knowledge I’d expect to associate with it:

  • Programming in general
    • Understand the different types of programming languages and their advantages and disadvantages.
    • Understand variables, function calls and recursion.
    • Understand the difference between assignment by reference and value and passing by reference and value. And how this applies to your favourite language.
  • Object-Orientation
    • Understand the key concepts of OO – especially encapsulation, inheritence, polymorphism.
    • Know the advantages/disadvantages of inheritence versus composition.
  • Design Patterns
    • Know the easier design patterns iterators, singletons, etc.
    • Have knowledge of the gang of four book.
  • C
    • Know standard I/O, know how to read parameters from the command line
    • Understand pointers
    • Understand dynamic memory allocation
    • Understand the scope of variables
    • Understand the difference between preprocessor, compiler and linker
  • C++
    • All of the C stuff
    • Understand the virtual keyword
    • Know what parts of a class a compiler will provide by default and what the default ones do.
    • Know what a constructor/destructor are and when they’re called.
  • Java
    • Know what the JVM is and what it does
    • Understand roughly how garbage collection works
  • Python
    • Understand the importance of indenting
    • Why some numbers are immutable
    • Tuples, sets, dictionaries,etc.
  • XML
    • The advantages/disadvantages of using XML (say versus a fixed-length encoding system)
    • The advantages/disadvantages of the SAX and DOM models
    • How to parse XML using your favourite languages/libraries
    • Know what XSLT is
  • Unix
    • Know how to use the console for day-to-day file handling
    • Understand piping and redirection of inputs/outputs

I think that’s enough brain-dumping for now….but I’m sure I’ll be back to add some more later on.

So if any of those had you thinking “do I really know the stuff on my CV” perhaps it’s time to brush-up your word processing skills….