Why do we write foolish LinkedIn profile headlines?

All of us or at least those, who use their LinkedIn account are quite used to seeing profile headlines like “Investor, Thought Leader, Digital Transformation Agent, Keynote Speaker, Builder” or “Keynote Speaker, Author, Writer, Builder” or people in the Agile world, who put out to the world all their hard-earned certificates. There are so many examples like these. People seem to be creative in coming up with such bloated, larger than life headlines.

We cover our vulnerabilities and insecurities by believing in a fake image that we build for ourselves. In the age of social media and instant gratification, we fall in a loop where we constantly want to show off that we are doing something new and evolving. We don’t want to accept that we are just like other people. We want to show that we are different. We are in a different league. 

I am also guilty of doing this 8 years back when I was a technology evangelist. As far as I remember my headline used to be “Technology Evangelist | Speaker | Writer | Traveller,” something in those lines. I wanted to show off and tell the world that I have done so many things. 

I soon realized that I am playing a status game. I am driven by constant validation and there is so much pressure I am putting on myself to be first in the race where I am the only runner.  

All status games are zero sum. 

Zero-sum is a situation in game theory in which one person’s gain is equivalent to another’s loss, so the net change in wealth or benefit is zero. 

Today, while discussing this topic with a friend, I realized that we do this because most of us have not achieved much or have not accomplished a larger body of work that we can be proud of. There is so much pressure to be successful for whatever definition of success we have defined for ourselves. We cover this fear or call it insecurity by posting our larger than life image. Deep inside we know that we lack creativity and there is nothing that will outlive us.

On Being A Full Stack Developer

I am doing software development for the last 15 years. Since I heard the term “Full Stack Developer” few years back I had a strong dislike for this term. To most people full stack developer is someone who can write frontend code, build backend APIs, and deploy applications to cloud. They can code in multiple programming languages(JS/Typescript, Golang/Java/C#/Python), knows enough to design and store data in either relational and NoSQL databases, follow DevOps practices (CI, Configuration management, etc.), knows about multiple architecture styles – Microservices, Monolithic, Serverless, and can at least deploy to one public cloud. Along with all this they also know and practice automation testing and can write clean, maintainable code.

Continue reading “On Being A Full Stack Developer”

Why I dislike meetings?

One aspect of work that I don’t like is meetings. The reason I have hard time at meetings is because they force you to come up with a magical solution to a problem that you don’t understand completely. You are forced to put forward your incomplete thoughts just to justify your presence in the meeting.  This then turns out to a mess where everyone tries to run over each other. It becomes a battle of who can come up with a sentence that has all the right keywords that decision makers want to listen. Rather than listening to others and logically arguing about each other thoughts our mind is thinking what to say next to score brownie points.

I don’t have a solution to this problem. I try to be quiet in such meetings that makes me ineligible for the follow up meeting 🙂

React License

Yesterday, I wrote a private note on my organization Slack channel educating people on React license. We use React in few of our projects.

Everyone please read this as it is important to understand what you get into when you decide to use React or any of the Facebook’s open source project. All open source projects uses some form of license like Apache, MIT, BSD, etc.

Facebook uses BSD license along with the patent clause. BSD license is a very open license, that allow you to do anything with React. The culprit here is patent clause. The use of patent clause means following:

If you file a patent claim against Facebook or React, then your React patent clause will be revoked automatically. Facebook will in return counter claim that you violated Facebook’s patent clause so you are doomed now.

On the surface this doesn’t mean much to us as most of us are not in the capacity to sue Facebook.

But devil is in the details, Patent clause give Facebook the power to held any organization hostage that uses Facebook open source projects. To get the point through. Let’s take an hypothetical example that Facebook decided to offer a tool that infringes your company’s IP. Facebook can force your company to allow them to use your patent for free. Otherwise, your license will be revoked and you might have to rewrite the application as it uses React. As we all know rewrites are very costly so an organization might be forced to accept Facebook request.

Apache foundation and WordPress has decided not to use React in future. They are planning to move to some other open source project.

Couple of hours later, Facebook made a press release stating Facebook has decided to relicense React and few other projects. This is great news for the community but this will be applicable from React version 16. React 16 is rewrite of React from scratch. Also, majority of other Facebook open source project have the patent clause. It would be interesting to see if Facebook relicense other projects as well or not.

The decision to relicense React came after backlash from the community. I think the biggest influencer in this decision is WordPress deciding not to use React in their project.

Matt Mullenweg from WordPress wrote in his blog,

the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library. It will likely delay Gutenberg at least a few weeks, and may push the release into next year.

Thank you WordPress. You forced Facebook to make this change.

7 Habits I Wish Every (Junior) Programmer Should Have

Over the last 11 years as a programmer, I have made some habits that have helped me in my day to day work. In the process, these habits have successfully translated into productivity and they have made me more organized.
I consider these as essential habits that every programmer should have, but I find them missing especially in junior developers. In my case, I was fortunate enough to be mentored by my seniors, who taught me these basic stuff. In this blog, I will share 7 habits that must be inculcated to become an effective programmer.

Habit 1: Spend time to organize stuff

As a software developer, we have to work with many files like installers, project sources, documents,etc. Make a directory layout with a separate directory for each topic. For example, I put all the softwares in the tools directory, project source code in the dev directory, and technical books or documentation goes to the books directory. Inside each directory, there are sub-directories for different sub-topics. Below you can see a directory layout that I use on my machine.

| — books
| | — java
| | — javascript
| | — mobile
| ` — react
| — dev
| | — office
| | — opensource
| | — personal
| ` — tmp
` — tools
| — browser
| — editors
| — ide
` — vms

Habit 2: Use version control for everything

Make sure you put all the projects in a version control system. You can use it for taking backups or for storing revisions of your software projects. I use Git along with Github for all my projects both personal and official. I have a Github repository called writings where I store my blogs, articles, or a random list of things. Couple of years back, I wrote one book. I used Git to store my book artifacts including content, images, invoices, source code etc. Using a version control helped me in analyzing my writing habits. For example, the Github repository contribution graph shown below clearly shows my writing flow during that period.

Habit 3: Invest in books

Gone are those days when we can survive with our limited skills. But, nowadays we must keep ourselves updated with latest technologies. I find books as the best medium to learn. Whenever someone asks me how to learn a specific topic or how I learned, then I recommend them a couple of books. The immediate question that I am asked is Do you have a PDF for the book? or Can you refer me to the location from where I can download it for free?. My answer to them is Always invest in your learning. Buy an original book be it an ebook or a paperback. When you invest your money, you make an effort to read.

Habit 4: Don’t fear the command-line

Most junior programmers fear the black screen i.e. terminal. They are always looking for the GUI tools that they can use instead of poking with the command-line. I have met many developers who are unaware of the most basic commands of their terminals. What I have learned over the years is, you spend more time in the terminal than on any other tool. Even learning the basics of the command-line can take you very far. There are tasks that can be performed more quickly with command-line tools than any GUI tool. For example remote SSH. Also, you can automate stuff by putting commands in a script easily. Every developer should try to at least learn the basic commands like cp, mv, find, grep, ps. One reason why beginners find command-line difficult to use is, they are overwhelmed by the help offered by man pages. It contains so much information that most of the time you don’t understand what to do. I have recently discovered a very helpful node.js module tldr that gives just enough information one needs to know to use a command. An example is shown below.

$ tldr zip
Package and compress (archive) files into zip file.
- Package and compress multiple directories and files:
zip -r compressed.zip /path/to/dir1 /path/to/dir2 /path/to/file
- Add files to an existing zip file:
zip compressed.zip path/to/file
- Remove unwanted files from an existing zip file:
zip -d compressed.zip “foo/*.tmp”

Also, I find Conquering the Command Line book by Mark Bates as a very good introduction to most commands that we need to know.

Habit 5: Master your IDE(tools)

A good craftsman always master his tools. This should be true for us programmers too. Knowing the shortcuts of your editor or IDE can make you productive and help you in writing less code. Developers should know refactoring shortcuts like extracting a method or renaming stuff. When you use shortcuts a lot, then actions like formatting a code becomes ingrained. You don’t even have to think about it,you automatically do the right stuff. IDE like IntelliJ and Eclipse have one shortcut that can give you a list of all other shortcuts. For IntelliJ it is CMD+Shift+A on Mac or Ctrl+Shift+A on Windows. Always keep a cheatsheet of your favorite tool handy.

Habit 6: Write and share everyday learning

We all learn something new each day. It could be a new command, a shortcut, a new tool, a new language feature or something new in your web framework. Start sharing what you have learned today with the world by posting a small blog post or creating a Github repository where you can keep all your tips. I started blogging in 2009 and it has been one of the best decisions of my life. Had I not, I don’t think I would have become a technology evangelist and later ended up writing a book. Yesterday, I found a very cool project by Josh Branchaud called TIL Today I learned. Josh is maintaining this repo for last one year and has collected more than 300 tips that he had learned. A very cool idea indeed!!

Habit 7: Watch conference videos

One habit that I introduced early in my professional career is to watch technology conference videos on Infoq. Most of the conferences post their videos either on Youtube or Vimeo. Watching good programmers can not only help you in understanding a topic, but it can also motivate you to learn and become like them. Good programmers talk very passionately and I swear that is infectious. Most of the technology videos are also hands-on so you can learn how they use their tools or other day to day things that are not part of the topic. Often, my reading list comes from these good programmers.

I consider the above points as good habits that developers should adopt. They have helped me a lot.

What we should not write on company’s blog?

These days organization expects their employees to write blogs/publish articles so that the organization gains more visibility. I believe blogs are a very good way by which you can gain more popularity and visibility in the developer’s community.  But I see lot of blogs published on company’s official blog as  developer’s personal experience or personal learning. These blogs lack the content and value as expected from a company blog. People just write the blog for the heck of writing it.

In my opinion writing such blogs does not increase the organization visibility.There should be a difference between what you should write in your personal blog to what you should write in an organization blog.

The blogs that you should write on a personal blog rather than on company blog are:-

1) Hello World blogs = These type of blogs does not provide any value as you can find such blogs all over the web. They just contain a very basic explanation of the concept or framework with or without a Hello World program. These blogs have one characteristic that the person who wrote this blog will also never read it again.
2) Opinionated blogs = These type of blogs contain your opinion about a topic, concept or an event. Writing opinionated blogs is not bad but
if you are writing your opinion on the company’s blog then it in a way represent your organization opinion also. So, when ever you write an opinionated blog, please match it with your organization values.
3) Blog with links to other blogs/articles= These blogs does not have any content of their own they just point to other links (video or text).

These are some of the types of blogs that should not be written on an official blog. Company’s blog should have good content and quality should matter over number of blogs published. Please post in your comments on what you think.

Reasons for incompetent software developers in India

Reasons for incompetent software developers in India

Most of the times, I have heard that Indian developers don’t have the quality as compared to their counterparts who are working in western countries.  Development teams in western countries often blame their offshore counterparts for slowing them down.  It has been said that Indians are not technically competent; write poor code, they don’t give any suggestions for the problems, etc.

In my opinion, most of these are true. Yes, we are not at par with developers in western countries and we sometimes really suck. Please note that this is just my personal opinion and not all software developers in India are bad. It’s the problem of quantity versus quality. In this blog, I will be putting up some reasons why I feel Indians developers lag behind developers from other countries.


  1. Developer by chance not by choice = In India anybody can become a software developer whatever his/her qualification is. I, myself, was a mechanical engineer, but in the college campus was recruited by a Software company so I ended up becoming software developer. Likewise I have so many friends who become software developer by chance. Most of the college students who join any Software company does not know anything about software development or have any knowledge about programming.
  2. College education does not help = I have graduated from one of the good college in India but I can tell you one thing that the quality of education in India is very poor whichever college you get graduated from. In India, importance is given to marks than to practical learning, students just cram the things and get score but practically they know nothing. I recently interview a guy who had close to 6 years of experience, graduated from a good college in Computer Science with a very high percentage, was not able to write a Fibonacci series program.
  3. Developers don’t keep themselves updated = If you ask a developer which last technical book you read or how you keep yourself updated, most of the times you will not get any answer. Nobody wants to learn or improve themselves. Whenever I get a chance to speak to developers I ask which last technical book they have read 99% of the time answer is either none or Head First SCJP book.
  4. Everybody wants to become a manager = In India you can become team leader at 5 years of work experience. Once you become team leader, your next goal is to become manager and for becoming manager you need to be good at giving your work to others, doing dirty politics, and most important doing nothing. So, you can see, we do not know anything about programming when we enter the software development world and at an experience of 5 years most of the developers start thinking about becoming manager. Last week I was giving Java 8 training to a set of developers with average experience of less than 4 years and I asked a question how many of you think you will be coding 5 years down the line. No one raised their hand. I was shocked to see this.
  5. No contribution to open-source community = I don’t know any of my friends or friends of friends including me who has contributed to open-source community.  We can only use the open-source project and if we find any bug in the project we will never fix it but blame the developers who wrote the code.

There can be more reasons but at this point of time I can think of these 5 only.  I am trying to make myself a better developer by reading, writing, listening. Tell me what you guys think?

Anonymous Blogger

Anonymous Blogger

Today, I was thinking why I and many other bloggers write as anonymous blogger without disclosing their correct identity.   I am writing down some reasons which lead me to write in an anonymous manner:-

  1. Fear of not looking stupid: – I feel this is the number one reason why people hide their identity.  This can be related to a blog which does not make sense or poor code examples.
  2. Writing on the topics which you can’t write otherwise: – There are topics on which you don’t want to write with your correct identity like your workplace environment, your manager  J , interview questions and many others. By hiding your identity, you can very easily do this.

Does Java Puzzlers make Good Interview Questions?

Intent of my Blog

Recently i wrote an blog entry on one of the java puzzlers that was asked to me in an interview.I received some of the comments which said this is unfair to ask java puzzlers in an interview.So i thought of writing an blog which discusses whether java puzzlers make good interview questions or not.

Does Java Puzzlers make Good Interview Questions?

I think before answering this question that should we ask java puzzlers in an interview or not we need to define some guidelines about what makes a good interview question. And if java puzzlers fit within those guidelines then we can ask the them in an interview.I am giving my personal point of view please add in your comments if you think something different.

Guideline for a Good Technical Interview Question

  1. Question should be How not what = Should be Practical which means that Interviewer should not ask the definition of some term or concept the interview question should be such that it discusses  practical application of concept.Asking how has the advantage that interviewer gets the correct feedback about interviewee that interviewee actually understand the concept.
  2. Question should be on simpler concepts = Asking a difficult question doesn’t make an interview question good.In my personal opinion interview question should be about the concepts which a developer normally use. You can vary the difficulty level of question depending upon position you are hiring but the concept should be simple.For example you can ask questions on overriding which can be simple or difficult but the concept of overriding is such that every java developer should know.
  3. Question can be Extended =  A good interview question should be such that you can build your interview on that question which means that if you ask a question on overriding you can start with the easier question and then build your interview by asking questions that increases in difficulty.
  4. Question should not be specific to API = The question that i mentioned in my post was good but it was specific to the HashSet remove method arguments. Let me explain, when you create an hashset  like HashSet<Short> s = new HashSet<Short>() you might expect that when you are doing s.remove(i-1) should remove only short objects but when you take a look at the remove method it takes Object .This is something specific to api which  most of the developers might not know. So asking such a question becomes useless.
  5. Question should provide a learning point = A good interview question should provide a value add to the interviewee. It might be possible that interviewee knows everything which is great and you can hire him/her. But even if he/she doesn’t know the answer they can at least  learn a good technical point.

Does java puzzlers fit these guidelines?

In my view java puzzler fit some of the guidelines:-

  1. All Java Puzzler are about How not What so java puzzlers can provide interviewer the practical understanding of the interviewee.
  2. Java Puzzlers are about simpler concepts but the Puzzlers are not simple because they discuss the trap or corner cases of the API. You can use these concepts for interviews but the questions are very specific to api and most of the times should not be asked in interview.
  3. Java Puzzlers can be extended but again because they are not easy most of the times you will not get the correct answer.
  4. Java Puzzlers are specific to API and they require very good understanding of java api.
  5. Java Puzzlers definitely provide a learning value to interviewee because these questions touches the corner cases  of the api which normally developers doesn’t know.


In my view you can ask some of the java puzzlers in an interview as java puzzlers definetly provide a value. Sometimes you should only take a concept and build you question on that and sometime take the whole question. If you think the java puzzler you are asking is difficult and a normal developer who hasn’t read java puzzlers book can’t answer please dont make that question a decider question means your decision to hire a person should not be based only on  java puzzler. Java Puzzlers are definetly very good questions and you should use them wisely in interview.

These are some of my view points. Please share your also.