If Carpenters Were Hired Like Programmers


Programmers often experience a high degree of frustration during the interview process. The thing I’ve always found funny about job interviews is that they’re always “looking for candidates who can hit the ground running,” so they’ll reject anyone missing one out of the ten required buzzwords.

I recently stumbled on two articles with an identical theme; “If Carpenters Were Hired Like Programmers” and “What If Cars Were Rented Like We Hire Programmers”.  The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters).  The comments sections on Reddit (link below)  and Hacker News(links below) are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme.  No analogy is perfect.

Programming is a business, technical and specialist skill, it’s perfectly normal to expect senior roles to have previous specialist experience in a particular framework or tool. And it’s important for us as a tech community to recognize that, and understand how that will affect our projects and our businesses.

It’s generally true that a good developer’s main skill is problem-solving, and a good developer will generally be able to pick up a new framework or language fairly easily. But a good developer in framework X will probably not be able to join a project and hit the ground running in framework Y. They will usually need support, co-workers who are more knowledgeable in that framework, and time. How much time? Six months to a year isn’t an unreasonably short time, even for an otherwise expert developer.

There are naturally exceptions. If a company is recruiting for a junior role, specialist knowledge probably matters a lot less. If a company is recruiting for a long-term permanent position, they can often afford the time for a great developer to learn a new specialty. So for some roles, it’s unimportant, but it’s not an unreasonable point to discuss. And technical development is neither carpentry, nor hiring a car, nor any of the other many flawed analogies.

Related links:



Mercedes Congratulates BMW on 100 Years


Not too sure how many of you know this but automobile giants BMW turned 100 last week. I came across this newspaper cut out just last night while browsing the net. This is an advertisement from Mercedes congratulating BMW for their feat.

Mercedes is a 130 year old company, and been in the industry 30 years longer than BMW.


The translation from German reads:

“Thank you for 100 years of competition.
The earlier 30 years have been relatively dull.”

I couldn’t agree more. There’s certainly no love lost between the German rivals, but at least they know how to have some fun.

Business isn’t about eliminating your rivals, its about appreciating the work done by your competitors and maintaining healthy competition while striving for excellence.

Brilliant business ethics shown by Mercedes here.

Great job Mercedes and congratulations BMW.

Mercedes Congratulates BMW on 100 Years via Interesting Engineering


Keep ECM Easy


Chad Fowler (@chadfowler) the author of The Passionate Programmer recently twitted that we should stop making things complex. Just by the number of retweets (2.4K) and likes (2K) it is clear that most of us will agree that we end up making things harder than they need to be.


Source: https://twitter.com/chadfowler/status/646624348028190720

This me to think that about my own area of enterprise content management, and realize that how we end up making things harder, following are some examples:

  • Folders are highly misused form of content organization, we tend to create deep folder hierarchies, we should always ask the question that do we really need that 10-15 level deep folder structure.
  • People love metadata and they understand the benefits of 1 or 2 metadata fields. But when we start asking for 5 or more, they start wondering how that will make their job any easier.
  • Workflow on addition of documents inside a container, I don’t understand why people need a workflow to be initiated for every document being added inside the container. Just think how would users feels when suddenly few hundred workflows are initiated and assigned to users because someone did a bulk upload inside the same folders.
  • Notifications are one of the best way to keep users aware about their pending tasks. Therefore be careful while enabling the notifications for add document or add versions kind of actions, you don’t want to spam users with 300 emails, if someone bulk uploads the documents. These kind of notifications can be the new type of spam messages.
  • Be careful while enabling auditing events for different actions. One example is auditing the document open event, this could be a good for a regulated event but bad for a generic documents and will create millions of rows in database tables. In such cases it become a huge task for system to clean these audit entries, I worked on a project where audit cleanup job used to take 8-10 hrs. Therefore don’t audit if it is not required.
  • Integrating ECM systems integrated into their everyday work environment is an important tool for adoption. But integrating everything without the clear understanding of problem being solved can lead to an expensive money pit which leaves everyone angry. (Read more: Don’t Waste Money on Pointless Integrations By Laurence Hart)

There are many such examples where we end up making things harder for users and systems both. The need for a simple solution that people can use to take advantage of ECM systems remains unfulfilled. The EFSS market isn’t providing enough of a solution because organizations still need the advanced features under the covers to meet their requirements.

The Dyson vacuum cleaner, the Burj Khalifa, Grameen Bank, OOP and SOA and Dropbox are some examples of  simple design with a perfect combination of form and functionality. Jack Dorsey, creator of Twitter and founder of Square, once said:

It’s really complex to make something simple.

You’d think that it’s simple to build a simple product, right? After all — a simple product does not have much features, therefore there is not much to design or build. Right? No, unfortunately that’s not the case.

Dorsey is not the only one with this reasoning. John Lilly, former Mozilla CEO and partner at Greylock , had dealt with this same issue (like many others). Here is how he explains the problem:

The thing is, getting to simple is not simple. It’s hard. Knowing how to simplify ‘ and, actually, crucially, what to simplify is a hard, hard problem. Simple actions that nobody does don’t matter. Hard actions that everyone wants to do are good, but vulnerable to simple solutions.

Simple is incredibly powerful, and super, super sticky because it can quickly get woven into the lives of many people.