Skip to main content

Why programmers need to have a sense of humor?

When I asked one of my friends for his comments about my last post, this is what he had to say -, "as an MBA i know hw imp ads are so i dont quite agree wit u" (reproduced verbatim from GMail Chat History). This was the same guy who had a great sense of humor when he was working as a programmer. He quit his job as a programmer and bam!, his sense of humor went away. Now this presents a burning question in front of us - why do all good programmers need to have an innate sense of humor?

It is an established fact that computers can become boring, especially to a programmer who keeps talking to it day after day without getting any response or appreciation. It never happens that you log in to your system and the computer chimes, "Hey Bro! Where have ya been? How 'bout a cuppa coffee before you begin?" If it happens, it means that it was written by a fellow developer who had his manager breathing down his neck to complete the project. Enjoying such greeting is like wearing a Blood Diamond! So to escape this dull, meaningless drudgery day in and day out, we programmers need to have a sense of humor.

The established notion of productivity in an IT company also contributes to programmers developing a funny bone. A developer, after working working very hard, reduces the running time of a program from 30 min to 30 seconds. Excitedly, he tells his manager about it. But the MBA-retarded manager only says, "Good. While you are here, can you point me to where I can find the mails I have kept for follow-up?" Its right there man. Just below the inbox, where it says "For Follow Up". What do you want? To dish it up in front of you complete with a 'Bon App├ętit' greeting! The only way one can hope to survive in such a environment is to see the funny side of it.

The HeadFirst Design Patterns book is a great example of humor in computers. So are blogs like The Daily WTF, or XKCD.

Finally a message to all the the programmers of the world aspiring to be a great one - learn to laugh. It will surely help you in avoiding the 'SenseOfHumorNotFoundException'. No kidding!

Comments

  1. While the Head First series of books are good, humorous reads, I found the one that you refer to, "head first Design Patterns" a bit too verbose and distracting. The examples stretched way too for the comfort of a technical book. Humor is fine, but not at the cost of trivializing technology.

    ReplyDelete
  2. If you want a serious book about design patterns, there are loads available in the market. Frankly, I don't find a serious technical book to be 'comforting'!

    ReplyDelete

Post a Comment

As far as possible, please refrain from posting Anonymous comments. I would really love to know who is interested in my blog! Also check out the FAQs section for the comment policy followed on this site.

Popular posts from this blog

Integrating React with SonarQube using Azure DevOps Pipelines

In the world of automation, code quality is of paramount importance. SonarQube and Azure DevOps are two tools which solve this problem in a continuous and automated way. They play well for a majority of languages and frameworks. However, to make the integration work for React applications still remains a challenge. In this post we will explore how we can integrate a React application to SonarQube using Azure DevOps pipelines to continuously build and assess code quality. Creating the React Application Let's start at the beginning. We will use npx to create a Typescript based React app. Why Typescript? I find it easier to work and more maintainable owing to its strongly-typed behavior. You can very well follow this guide for jsx based applications too. We will use the fantastic Create-React-App (CRA) tool to create a React application called ' sonar-azuredevops-app '. > npx create-react-app sonar-azuredevops-app --template typescript Once the project creation is done, we

Centralized Configuration for .NET Core using Azure Cosmos DB and Narad

We are living in a micro services world. All these services are generally hosted in Docker container which are ephemeral. Moreover these service need to start themselves up, talk to each other, etc. All this needs configuration and there are many commercially available configuration providers like Spring Cloud Config Server, Consul etc. These are excellent tools which provide a lot more functionality than just storing configuration data. However all these have a weakness - they have a single point of failure - their storage mechanism be it a file system, database etc. There are ways to work around those but if you want a really simple place to store configuration values and at the same time make it highly available, with guaranteed global availability and millisecond reads, what can be a better tool than Azure Cosmos DB! So I set forth on this journey for ASP.NET Core projects to talk to Cosmos DB to retrieve their configuration data. For inspiration I looked at Steeltoe Con

Add Git Commit Hash and Build Number to a Static React Website using Azure DevOps

While working on a React based static website recently, there was a need to see exactly what was deployed in the Dev/Test environments to reduce confusion amongst teams. I wanted to show something like this: A quick look at the site's footer should show the Git Commit Hash and Build Number which was deployed and click through to actual commits and build results. Let's see how we achieved this using Azure DevOps. Git Commit Hash Azure DevOps exposes a variable called  $(Build.SourceVersion) which contains the hash of the commit. So I defined a variable in the Build Pipeline using it. Build Id and Build Number Azure DevOps also exposes two release time variables  $(Build.BuildId) and  $(Build.BuildNumber) which can be used to define custom variables in the pipeline. So we have a total of 3 variables defined: Next we use these variables in our React App. I created 3 global variables in index.html and assigned a token value to them. < script   type = "text/JavaScript&quo