alacrity in action
| Tags: ,

Photo by 500CPMI’m sure you have, many times, seen recruitment for software development positions that expected candidates to have x number of years experience with a particular technology. Best if it’s a litany of technologies (ignore when they ask for 5 years with a technology that has only been out for 2). If you need a developer that’s what you do. If you’re a recruitment agent that’s all you can do (OK, with some exceptions).

Ultimately, employers who state such requirements make one fundamental mistake. They think the only factor limiting how quickly they create software is how quickly their developers can type.

Yes, if you have worked with NHibernate for 2 years you will write the mapping file more quickly and you might already know what fetch strategy to use. You will not, however, deliver good, valuable software more quickly. The speed at which you type has never been, is not, and I don’t think will ever be a limiting factor, ever. It’s like thinking Picasso would have created more works of art if only he could have made his brush strokes more quickly, or that Pollock would have made a bigger impact on the art world if he could pour paint more quickly. Wrong.

There are many other things to look for in a good developer (more on that another time perhaps) but for now, start with people who are smart and get things done not the ones who have experienced a specific technology for more years and thus can write the code for that technology more quickly.

Clash Of Clans HackRobuxed Roblox HackNo Human Verification Roblox HackCocgemsgiveaways Com HackSuper Mario Run HackIskid Org Robux HackRobloxgiveaway Xyz Cheat Hack8ballpool ppf info Hack8ballpoolhack Us Hackvaingiveaways Top Vainglory HackIskid Org Robux Hack“My Cafe Recipes Stories HackPanda Pop HackFree Streaming Movie Online 2017


Comments3

  1. This looks like a non-sequitur to me. Where does typing faster come into it? I think it *does* make a difference how much experience you’ve got with a particular technology – you’re more likely to have been burned by the various things that can go wrong, and know how to avoid them in the future.

    Obviously it’s far from the only important thing, and I’d rather work with a good developer who can learn a new platform quickly than a bad one who happens to have a lot of experience in the one I’m interested in right now, but I think it’s a mistake to brush experience aside quite as thoroughly as you’re doing here. There’s a lot more to experience than typing speed. Do you think Picasso’s final work wasn’t influenced by the ones from the rest of his life? Was his first ever painting as good as his last?

    • Thanks for your comment Jon. I will try to clarify my thinking. Firstly my intention was not to brush experience aside altogether. I recognise its value and I do think it is an essential element to becoming competent, excellent and expert developer. Yes, Picasso’s final works evolved far from where he started.
      I do however, want to brush aside the particular view of experience that I often see when people set out to recruit developers. That is to assume that the longer you have used a particular set of APIs the better a developer you are in general and to use it as the *only* indicator. Also – on the flip side of that – if you have not used a particular technology for at least an arbitrary length of time you can’t possibly do a good job using it. I have met developers who used ASP.NET for 5 years and ultimately, software they created was worse than that created by others who only used it for a few months.
      The reason I mention speed of writing code in this context is because I think it is the only aspect that may correlate directly with the length of time you used a particular API. Writing good software is about much more than knowing what methods there are on the set of classes you have available. If I employ someone to write LINQ statements and they have never done it before it will take them more time to write even the basic ones compared to someone who have more experience using LINQ. Will the latter create better software – I can’t possibly tell, not based on this one aspect only.
      Finally, I increasingly like Kevlin’s argument that we don;t learn from failure – if you have failed with a particular technology more times it does not make you any more likely to succeed with it than someone who have never failed using it (though there are other aspects that may help you be successful but it’s not the failure itself).

  2. Pingback: Marcin Floryan » I don’t need no CV … but it can be helpful

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.