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


Dropbox’s Exodus from the Cloud


Moving to cloud has been the talk of the boardrooms for a long time. Many startups have launched their products using different cloud providers and few have been moving on an off cloud. One example I particularly remember is when when San Francisco based social gaming company Zynga reached its own hyper growth phase, the company moved off of the cloud and into its own data centers. But then its business imploded, and it was left with infrastructure it didn’t really need. It’s now back on Amazon. (Read full story here)

While the companies are busy planning their migrations to cloud, but at the same time we should plan for the moving between the clouds, to avoid vendor lock.

Data migration is a particular problem because a cloud storage service is often seen as the ultimate data archive and the capacities an organization will try to transfer can be very large — petabytes instead of terabytes. Migrating large data sets is always a challenge, but public clouds have the additional issues of limited bandwidth and potential download fees.

Wired magazine recently published the story on Dropbox’s Exodus From the Amazon Cloud, following is an extract:

“Just getting the bits out of Amazon and into other data centers was an epic task. Digitally moving petabytes of data from one machine to another isn’t exactly on the same scale as downloading a few songs for your laptop. Even the fattest Internet pipes only have so much bandwidth.”

Read full story here: The Epic Story of Dropbox’s Exodus From the Amazon Cloud Empire via WIRED

Moving those bytes around is a huge task. Even small and middle size companies will have to face this challenge in due time.

Are you prepared?


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.



ECM and Fitness Trackers


“My new fitness tracker counted 5,000, unfortunately 4,900 of them were to the fridge and back!”

From a fitness perspective wearable products are great at quantifying your activity, but they don’t make you more active, unless you change your habits; you’ll just have an expensive device that tells you how much you don’t do.

On the other hand if you started a regular fitness routine and replace junk food with healthy foods, you would get healthier — with or without the FitBit tracking you.

I can relate this scenario to content management also, need not to say how many times companies will buy the technologies, thinking that it will resolve all of their content management problems. Later realizing that the new fancy toy (technology or tool) has not fixed their content management problems.

This is like blaming the FitBit for not going on my five mile run today.

“Wearable devices have gotten a lot of interest in their potential impact to improve individuals’ health, but there’s been little evidence that these alone can help people sustain changes in behavior,” says author Mitesh S. Patel, MD, a researcher at the University of Pennsylvania. “The more important part is building effective strategies to engage individuals around these devices.”

Technology can give us huge advances, but if enterprises haven’t built a mature content management strategy, pumping money and time into technology is not going to change anything.

Need for MobileUI in ECM Systems


Recently I faced an interesting problem therefore thought to share it here, our ECM system is the single source of truth for standards and policy related documents. Also it’s easy to share the link of the document rather than attaching the whole document while sharing information.

Since most of the users check their emails using mobile devices, therefore now they are facing a new issue. Whenever they try to opens a document link shared using email, it tries to open the document in mobile browser using the same layout as if it was being opened on a desktop. This makes it very hard to open and edit the documents.

This issue has created a demand for a mobile compatible interface for our ECM system so that they can at least browse and read content using mobile devices.

It’s interesting to see, how just moving one application (emails) to mobiles, has created a demand for mobile compatible version of another system (ECM).

Most of the ECM technologies needs add on modules (with extra licensing cost) to support mobile devices. Or a mobile app needs to be developed using SOAP or RESTfull APIs.

We are using one of the product from Leaders Quadrant of Gartner Magic Quadrant for ECM and we have two options 1) either pay to buy a new product for mobile compatibility or 2) develop our own app using APIs.

This is one of the areas where new vendors like Box.net have an advantage over established players, as it is built for cloud and mobile. It works smoothly on all kind of devices (desktop, tablet and mobiles) without any need of customization or add-on software.

A piece of advice to ECM vendors, don’t just design a system which works on desktops only, design a adoptive UI so that default it can be accessed from any kind of devices.

Sharing Documents through Email


Email is the easiest way to communicate with people as we have been using it for decades, but it poses few challenges while when we start sharing or collaborating on documents through email.

Sharing document through email, crates multiple copies of document and if needs to be modified, then everyone has to wait for their turn to add their inputs and comments and in this process, multiple copies of document will be made and we will have no track which one is the updated one. Documents in email will be quickly outdated.

Also sharing a document over email is a security issue, as everyone can edit the document and they may end up sharing this document with others which can pose issues if the document contains confidential information. Security is irrelevant while sharing a document through email.

The struggles with email collaboration

  • Dozens of emails from various team members, most featuring identical subject lines that make it difficult to weed out crucial responses from irrelevant ones, especially when conversations fork into multiple threads.
  • It’s nearly impossible to maintain clarity about what needs to get done, and by whom.
  • Poor version control: Just when you think the document is final, you find out two different people made extensive edits… to yesterday’s file. Keeping track of the most current version of an attached document is the modern-era’s needle in a haystack.
  • Lack of transparency: It’s hard to track which pieces of information are still missing and where approvals stand.
  • Limited reuse: The approved document’s final resting place is someone’s inbox, never to be shared again unless you specifically remember that someone proposed something similar last year.
  • Group conversations grow unwieldy too quickly.

Email-communication-vs-collaborationDon’t get me wrong, email is an incredibly useful tool, it’s just a misused one. Email is an effective means for communication, but when it comes to collaborating with your team on projects and getting work done, it’s a major hindrance to your team’s productivity. Therefore the question arises, is email a communication tool or a collaboration tool? Is there even a difference between communication and collaboration? While there is a myriad of definitions and well written explanations of the differences between communication and collaboration, my personal favorite comes from Anthony Bradley at Gartner Research. Anthony says that [1]:

“Communication is the exchange of information to achieve a better understanding.”


“Collaboration is the exchange of information, and things, to advance the state of a collaborative product.”

Collaboration is different, even though communication and collaboration will seem like same, but they are not. Collaboration is a higher form of communication. That is to say that communication is required for collaboration but not all communication is collaboration. Also I like the following definition of collaboration from AIIM [2]:

“Collaboration is a working practice whereby individuals work together to a common purpose to achieve business benefit.”

How a collaboration helps you

  • Instead of endless email, team members can participate in discussion threads that efficiently summarize where various facets of the document stand.
  • Document management: Everyone has access to the latest draft, and you can check the proposal document out of the system like a library book while you’re working on your piece, single source of truth.
  • Searchable files: You can apply metadata or tag files to make them easy to find later. This means you can quickly locate the document after six month also.
  • Security: Apply security policies to documents, so that only authorized personals have access to documents.
  • Auditing: A well-established auditing policies can keep track of who and when the document was accessed, it is particularly useful in regulatory environments.

The closing remark, an ECM system with focus on collaboration can solve all of the above mentioned, and many more, issues and can effectively improve the productivity and quality of information being created and stored.

Send links to documents, which is stored in the ECM system rather than sending the document itself, it will store the change history, audit and managed and IP stays safely inside the firewall, seen only by authorized users.

[1] Click here to check out Anthony Bradley’s part 1 of 4-part blog about how email is anti-social (read other Part 2, Part 3 and Part 4 here)
[2] What is Collaboration? http://www.aiim.org/What-is-Collaboration

Disclaimer: This post is inspired from an experience, where I was using a document to implement the taxonomy for a new BU in our ECM system. I received the document through email and I came to know that old version of the document was shared, as few more changes were made on the flight. This caused a lot of rework for us. Therefore I thought to document my observations and learning in this post. Thanks for reading.