A valid fear!

People were worried that tools like Drag and Drop tools were flowing into the market and they will replace the need for any programmers.

After a decade of experience and I am still listening to arguments about the fear of automated tools replacing the programmers.

Here is another Youtube video and I will explain the arguments:

Let’s discuss it:

Python Vs C language

The first argument is python saves time and it is easier when compared to the C language. Similarly, tools are like NoCode and Shopify have enabled people and companies to create solutions fast. This results in more business and customers and that require software engineers to support them.

It’s basically the argument that “programming nowadays is just glue Code”. But the problem is that all of these shortcuts solve a limited set of problems. It is very hard to rely on these shortcut tools because when a business grows there will be the need for more custom solutions.

This is because these tools and higher-level programming languages do not cover every aspect of the possible solutions.

Advice: Learn more

The advice given here is that one should learn as much as possible about the new and upcoming frameworks. I agree with the advice but I will emphasize that besides the learning framework one should learn about the principles upon which these frameworks are built.

Hence the fear of new tools and frameworks replacing programming jobs is never going to go away. It will be there and upcoming tools and technologies in the programming world are a good thing that indicates that there is growth and there will be more programming jobs.

I asked if he is making less money or something else? He said. “No. I want to change my career from programming to something else.”

“I cannot imagine myself doing programming when I am old. It’s a lot of stress. It’s a job for young guys”, he said.

It brings out all my fears of my earlier programming career. I used to think about how will I survive that if I had to work hard and learn a lot of things when I am 50+ years old. My internal belief was older people cannot program.

Now after a decade of programming experience I can witness that I am only getting better.

With experience, I have developed certain core skills like architecture, design, testing, and debugging that I can learn any new technology rapidly.

Also, I researched aged programmers who are working professionally. To my surprise, they are still good at their job.

One phrase that helped me understand the dynamics:

“Medical doctor who is old does not mean that he cannot diagnose and write a prescription. The same is true for aged programmers.”

Even programmers who move into management roles love to do programming as a hobby. One of my senior manager who is about to retire and is 60+ years old told me that after retirement he will be programming for his side projects.

Fear of programming as an aged person is related to job security. This fear is justified because at the start professional programming is hard and one has to learn a lot to get the wings.

So they assume from initial hard work that their life will be full of anxiety and as they age they will be unable to compete with the younger programmers.

But the opposite is true. With experience in programming, they get better and more valuable.

What do you think about programming when you are 50+ years of age?

Therefore, I asked friends and relatives. I asked those who were treated successfully and even those who were not.

Time was ticking because the problem could get worse if I did not take the action.

Today, I am thinking that did I make the right decision? The total number of people I talked to was 15. Is this a good sample size to select a doctor who is going to treat me physically?

Another method would be to get 5000 people who were treated by each doctor and draw a graph and do statistical analysis and select one in the top 1%.

That would be insane

Anyway, I selected the doctor based on simple research and got treated successfully.

Software engineers like me are skeptical. I need a statistically powerful study to support any argument or idea or design principles.

Because developers who know about object-oriented design are mostly show off. They were only dropping big terms to impress junior developers.

But there is a serious lack of scientific studies in OOD and let’s explore why. In any research, the sample size must be statistically powerful. The larger the sample size the better the quality of the research. But studying larger samples requires more resources.

A large study requires management for administration. Experts for evaluation. Participants in the study volunteer or paid. Time because a large study can take months and years. Constraints to enforce e.g. testing for a variable and keeping other parameters constant.

Imagine asking what would be the benefits of applying polymorphism in 500 different software development projects while keeping everything else constant. But keeping things constant is difficult in software projects.

I searched for such studies where hundreds of software projects participated and people measured the effectiveness of ‘X’ design principles or patterns. I have not found one yet.

This was very heartbroken for me:). I only trust something when it is supported by a significant scientific study or a mathematically proven formula. Using formulas is another love for analytical persons.

I love formulas because I love Galileo. He once deduced that all objects either heavy like a hammer or not so heavy like a bird’s feather will fall at the same speed. Galileo said it hundreds of years ago and NASA has tested his mathematical capabilities in a lunar mission. See the details on the moon:

Object-oriented design Formulas

In the beginning, when I was learning about design patterns I thought of them as mathematical formulas. I believed if I use ‘X’ design pattern then I will get ‘Y’ benefits.

I even went one step further. If applying one design pattern as a formula is helpful then why not apply all the design patterns and get the aggregated result.

Guess what? It only works when you are applying design patterns in class or demo projects. In real-world projects, it does not work like that.

So what is the solution?

The most effective method is to select one design principle and apply it and test it for yourself. You will know if it is working or not.

Easy? If it is easy then what is the purpose of design books? Books do not promise you the competency.

There are two types of books. One is catalog books e.g. ‘Design Patterns: Elements of Reusable OO Software by four amigos’. They are boring, dry, and complex.

The second types of books contain personal experiences and basic examples like animal and duck e.g. ‘Head First Design Patterns’. They are basic and fluffy.

My article on object-oriented design patterns tries to be both i.e. good reference and real-world examples.

No design books claim to be the perfect book and everything authors find helpful may or may not beneficial to you.

“All you can do is take the vocabulary, take the inspiration, apply yourself, customize the design patterns to your needs and most importantly observe the benefits.”

Consider the doctor I chose for treatment. What if I don’t see the benefits after 2 or 3 months? What would I do? I would change. If something is not working or you are not getting the desired benefits you can drop it. Or try again in another project.

Do this repeatedly and you will know if the design pattern or principle is going to be effective or not. That will be the moment when you become someone who used to know about patterns and now you are competent in design patterns.

Ultimately, you will see the following benefits of design patterns:

a) Your strong code structure helps you to go home early because it does not break with the new changes. OOD skills help you convert a fragile codebase into a stronger one.

b) Imagine there is a new framework in the market and companies are hiring at higher salaries for developers adept in that framework. It will only take days for you to learn that framework because it is an implementation of one of the design patterns.

c) You will feel good when you see a junior developer using your framework and enjoying all the benefits that you have envisioned years before.

If you want to learn more about real-world examples of object-oriented design then check this out.

I have done a lot of coding and used half a dozen programming languages but I did not understand what the heck the code was doing. Any code that I have written till now looked childish.

I believed I made a wrong career choice and I will never gonna be like that developer. I thought there was a mistake in the recruitment process and I am working here until they find me out. I felt like a fraud.

So, I made a promise to myself that I will work hard and prove myself before they find out my incompetence.

I kept learning new frameworks, new programming languages and work harder for years to prove myself and not being caught as a fraud. Until one day, I met a developer Matt. He was a ‘Real’ developer– the kind of developer that everybody wants to be.

One day Matt told me about his insecurities and why sometimes he felt like a fraud. I thought that Mat has caught me and now he is faking his story to taunt me. The truth is Matt was impostor–like me!

I look around, I researched and found that impostor syndrome is common among developers and it is a major roadblock when they want to prove themselves. Today I will tell you how impostor syndrome is disguised in other feelings and how it is hurting you in different situations.

Impostor Syndrome: A Major Roadblock in Developer’s Life

According to wiki:

“Impostor Syndrome is a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a ‘fraud’.”

But you don’t wake up one day and say, “OH — Yesterday I was feeling imposturous”. It’s hard to identify impostor syndrome because it’s difficult to express feelings in words.

You may say, I don’t feel like a fraud or I don’t feel resemblance with your experience or wiki’s definition. There are so many variations to impostor syndrome. So in this post, I have catalog situations and feelings that indicate impostor syndrome in action.

Read these situations and find out if they match yours. Finally, I have researched all the solutions. Distilled them and create a set of tools that you can apply to cure impostor syndrome.

Why the impostor syndrome happens

It is a complex subject for psychologists like Clance and Imes. But experts converge on our underlying urge to prove ourselves to our boss, teacher or even family. This can be either to please them or to gain benefits.

Proving ourselves is our basic need and similar to basic needs like survival and It is more important for every beginning developer. Unfortunately, no one is going to tell you explicitly except the HR department who at the end of the interview or at the end of probation did not call you back. Why? Because you were unable to prove yourself.

Perks For Real Developers

If you continuously prove yourself you will become a rockstar/real developer. One thing that rockstar developer can do is they work from home. Imagine a day when you don’t want to wake up on the alarm clock and suit yourself for office. Imagine no commute delays or traffic jams.

You can get your coffee, open your laptop, open the repository remotely and start working right from your bed.

This is what ‘Real’ or ‘Rockstar’ developer means to me. Not what is shown as a hacker in movies.

For you, it could be different. By proving yourself you can earn more. With your enhance your skill-set and you can re-negotiate your pay package at the time of appraisal. Or you can switch jobs for more salary.

By proving yourself you can control your environment. If you don’t like the environment or the nature of your job or your manager you can switch. There are always job openings for real developers.

By proving yourself you have more time. Now you can complete the task in less time and you can use this free time for your own learning/leisure activities.

By proving yourself you have the opportunity to do the real work. Recognized work–something that you can tell in parties.

The PLAN to become a ‘Real’ Developer

Our goal is to become a ‘Real’ developer. The biggest roadblock to this goal is impostor syndrome and following is the plan to achieve the goal.

Let’s get to step one.

Situations and Feelings

These are the situations for developers where they feel a variation of impostor syndrome. See if any of the feelings are familiar to you.

1. When Someone Asked you a Question

Imagine when someone, junior or senior, asked you a question and you are unable to give an answer. How do you feel? Incompetent or bad?

Programming is a vast field and nobody cannot memorize everything. Even the programmer with decades of experience has to look up while programming.

So when you are asked a question and you don’t know the answer it does not mean you are incompetent. You just have one more thing to learn.

2. Comparing Yourself With Others on Linkedin

One of my habits is to browse the LinkedIn profile of other developers. When I see another developer experienced in dozen technologies and I have experience in 2 programming language and one framework–I feel bad.

This is closely related to highlight reel phenomenon. Looking facebook posts of your friends and see them doing all the fun and telling yourself ‘they are living a great life and I am living a miserable life’.

The problem is you are only seeing the highlights of their life. You are not looking at the failures or downtime that they have in their life. Because nobody shares them!

Comparing ourselves with others is the main source of feeling incompetent. The social media tools have amplified this feeling and it is one of the reasons for impostor syndrome in developers.

3. Start of a New Project

Recently, I started a new project from scratch. I have to figure out requirements, learn different technologies and work with abstract ideas. I feel incompetent.

Working on an ongoing project is easier than starting a new project from scratch. Imagine someone developing enterprise applications for years and now has to work on the embedded processor using ‘C’ language.

Therefore, if you feel bad or incompetent starting a new project then remember it is impostor syndrome.

4. When There is a new Technology to Learn

In the old days, I was working with a group of developers who were using Asp.net Web Forms that was going to be replaced by asp.net MVC.

They feel bad even threatened when the boss introduced them to MVC. Why? Were they incompetent? They were doing great work with web forms for years. They were not incompetent but they were feeling incompetent because there is a new technology to learn.

Learn anything new will always lead you to impostor syndrome. So whenever you are learning anything (driving a car or learning new framework) beware of impostor syndrome.

5. Because You Are Alone

As a beginner, mostly you are a learner in addition to the developer. In programming, your learning will never end. But as a junior, you will have to learn even more.

Learning and impostor syndrome are closely related and one of the reason is that learning is a sole journey. People around could guide you but in the end, it is you who has to go through the fire.

This sole journey amplifies the negative feelings and developers get demotivated and think of themselves as incompetent. Beware it is impostor syndrome.

6. Seniors Are Not Helpful

Seniors developers often tell the story of their heroism. How they solve a critical problem five years ago that no one else can do. You will admire them when you listen to them.

Also, visualizing their story will make you feel incompetent besides admiration. Remember, when we compare we feel impostor.

7. Grunt Work is For Juniors

As a junior developer, you are not allowed to do any serious stuff like working on production code. You are only allowed to play in the back alley like updating the copy on a website.

This is necessary because they are testing you and would not give you the driving seat on the first day.

The problem is you are dying to prove yourself. These minuscule tasks belittle you and make you feel incompetent. Don’t be the victim of this fake feeling.

8. When Rework

For me rework means overtime. It also means shame. Whenever I made a mistake that leads to rework I feel shameful and incompetent.

This is amplified when the code is in the production. Which means a lot of people are going to be affected by that.

We are like other people and we make mistakes. We should not be hard on ourselves. I am not incompetent– I just made a mistake.

9. Giving estimates is difficult

Giving an estimate for a task is difficult even for a senior developer. Giving an estimate for software development tasks is art as well as science. It will take time to be skillful in giving estimates.

When I was a junior I always gave heroic estimates. I want to become someone who can do the job on the spot or as quickly as possible. Which I could not. Poor estimation skills lead me to think that I am not a good developer.

But when I read the book Software Estimation by Steve McConnell then I realize that I was not a bad developer — I was just bad in estimation. Here is my article on software estimation.

10. When Committing Your Code

Imagine you have completed a task and are going to commit the code. How will you feel just before you submit the code?

Because in the morning, there will be eyeballs on your code. What if the person reviewing your code catch errors. What if the person reviewing has a grudge with you and he wants to prove you incompetent.

If these motion going through your head just before committing the code then this is impostor syndrome.

11. Change of Routine

As a junior developer, there is a big shift in your routine. Before joining the industry you were a student. Student of computer science in university, boot camp, online or even self-taught.

Now the routine is different. There is an 8-hour workday, commuting, colleagues and bosses. In the student days, you can sleep longer and work on your own terms. Now you will be guided by others and you have to stick to some rules.

This change of routine is exhilarating for many people. With this tough routine, they think that they are not good enough or fit enough for a programming career.

What If Above Situation/Feelings are Not Familiar

If any of the situations mentioned does not sound true to and you are still feeling incompetent. What should you do? Do the following:

1) Subscribe here to get updates on more situation and feelings

2) Find is it impostor syndrome or you are really incompetent

How would you know?

See the external factors. If anybody around you tells that you are good either explicitly or implicitly. Then consider yourself competent. This praise should be in a professional setting and not by your friends or family.

Also, look for inner motivation. If everybody tells you that you are not good but in your heart, you know that you want to be in a programming career. Then all you have to do is work hard and you will be in the league of top programmers.

Enough of diagnosis and identification now let’s get to step two: the solutions.

Solutions for Impostor Syndrome In Developers

1. Express Feelings in Words

This post is inspired by Dr. David Burns book Feeling Good. Where he teaches how to deal with negative emotions like failure, stress, anxiety and etc by putting a label on them. According to research, when you put a label on your emotions and feelings the negative effects of the emotions will be reduced.

Putting a label on feelings or describing feelings in ‘words’ will bring it from the emotional part of the brain to rational parts of the brain which will automatically reduce outburst of emotions.

This is what I tried to achieve in this post. I outline situations and feelings disguised as an impostor. With these list of feelings, you can recognize an impostor feeling and say: “Oh Yes–Feeling incompetent when starting a new project–this is impostor syndrome”.

Recognizing the feeling and describing them in words will help you reduce the negative impact of impostor syndrome.

2. Everybody has it even the ‘Rockstar’ Developers

When I was young I thought about ‘rockstar’ developer as someone flawless who can do any task without any errors in the first attempt.

This is amplified by the movies where one hacker writes scripts in minutes, runs the script and everything (most of the time a vault) cracks open. I know people believe who still believe in these movies. They are either junior or ignorant. They like to code as shown in the movies.

Once I attended a presentation by a rockstar developer. I was amazed by his presentation and the way he wrote code and shown the demo. I watched his tutorials and videos online. He is the kind of developer I want to be. His name is Scott Hanselman.

When browsing about impostor syndrome I was stumbled upon  Scott post on impostor syndrome. My rockstar developer think that he is phony–like me! HMMMM.

I was surprised and relieved to know that almost every rockstar in music, films, games have gone through this syndrome like Neil Gaiman and Neil Armstrong. They still have it but they don’t become a victim of it.

Therefore knowing that even the top people in the industry have impostor syndrome will help you in relieving the negative effects of impostor syndrome.

3. Keep up the Motivation

It is very difficult to keep yourself motivated.  You may feel motivated by reading about a top performer having impostor syndrome but it will not last.

I have created a tool of motivation that you can use it to keep your motivation up on-demand. I created it by documenting my progress. I use my journal to document my progress. Here is the step-by-step guide to documenting your progress.

At the end of the quarter and year, I review my past progress with the help of my journal. I always get amazed by looking at the projects I have completed. This is like a personal appraisal but an authentic one.

Keep this journal close to you and use it as harpoon of motivation. Whenever impostor syndrome hinders you, read your progress and you will be motivated.

4. Stop Comparing

Many emotions related to impostor syndrome were based on one human condition. We compare ourselves with others.

We want to be like them or want them to be like us. We forget we are different. We have different lives, different backgrounds, and different conditions. We will always be different therefore stop comparing yourself with anybody else.

Instead of comparing use the scale to calculate your competence level. Know your competence level and know the level of anybody who is ahead of you. Then just work hard to get there.

5. Accept you have Role in the Success

Recently, I heard a developer saying: “I have only 5% of the work but now it seems like I am responsible for the whole project.”

Yes, he did the 5 percent work but he was a link in the chain or a part of the team. Without him, the chain will break and the product will fail. So yes he did the 5% percent work but he is an important person.

Similarly, it doesn’t matter how small your contribution remember that you have contributed to the success of the project.

6. Discussing With Others

When professor Richard Felder tells his students about the impostor syndrome there was a moment of relief not only in students but in other professors as well.

The moment when you tell someone else that you have the impostor syndrome and he shares a similar experience. You will feel better.

This is what I am doing by writing this post. I am telling you about my impostor syndrome to get relief. You can do this to get relief from impostor syndrome by discussing it in comments.

7. Advance Solution: Dance with it

This is similar to dealing with any other emotions like fear. Every top-selling author when sits down to write another book he fears that he will fail. Every serial successful entrepreneur when starting a new business fears that his business will fail.

What do they do? They know there will be fear so they just learn to live with it. There is a great book and the title describe this whole idea “Feel the Fear and Do it Anyway” by Susan.

Just know that there will be a feeling of incompetence or fraud and move on and do your work.

Opposite of Impostor Syndrome

Before leaving, let me tell you what is not impostor syndrome. Consider a spectrum. If one end is happiness the other is sadness. Similarly, if one end of the spectrum is impostor syndrome then at the other end is Dunning-Kruggar syndrome. It means, a fake feeling of competence. People who overestimate their capabilities.

You may have met such people but I bet that you definitely have met a genius jerk. If you add attitude to this end of the spectrum then you will get a jerk genius.

ATTITUDE + DUNNING KRUGAR = Jerk Genious.

This is someone who thinks the current organization is dependent on him. They ridicule every other developer. They are always angry, looking for other mistakes, reject other’s advice and always tell their stories of heroism. Research indicates that they are making harm to the organization even if they are brilliant.

Being a software developer is a journey. In each journey, you are on different stages. So this framework will tell you at what stage you are in your journey.

Also, this framework is helpful in getting you out of overwhelm. In a programming career, you hear about new tech, frameworks, languages quite often. This can be overwhelming for junior developers. But when you know how will you look like after some experience then you will not feel overwhelmed.

This framework is not here to demoralize you. Once you know where you are you can easily plan your next move.

Stage 0: You are not a programmer– obvious.

Stage 1: You can develop in a scripting language.

Stage 2: You are acquainted with writing apps in a real programming language.

Wondering what is the difference between scripting and programming language. Look at the answer in this post.

For me, the scripting language is something that is easier to work. JavaScript is a good example (no type checking and easier on forgetting ‘;’ )

Easier than scripting languages are markup languages–examples are HTML and CSS.

Stage 3: You can write complete apps in a programming language and can design a simple API.

Stage 4: You have a complete grasp on developing API and you can write optimized code for the hardware.

Stage 5: You develop operating systems and drivers.

This is a very simple back of the napkin paper framework that you can use to identify your capabilities.

Use this framework when you see a more skillful developer.  With this framework, you will know that you can get to his level of expertise or even ahead but it’s just a matter of time and hard work.

Great

If you like this post then subscribe to get the step-by-step guide to create your personal tool for fighting impostor syndrome.

Also, this guide will help you to:

• Document your progress
• Make better software task estimation
• Keep motivated
• Authentic self-appraisal

[maxbutton id=”2″ url=”http://eepurl.com/b34ZpL” ]

If you look at your past three months you will find that most of your efforts were about creating your rapport. Senior developers face this challenge too but they have already fought their battles and rapport is not number one in their plate.

Why juniors have to prove themselves? Because the hiring process is designed like that. At every stage of the hiring process, the developer has to prove his worth. Most importantly this does not stop at the end of the probation.

So, what you can do to prove yourself without making your life harder? Let me outline a simple process to prove yourself. It is divided into three stages.

Stage 1

In the first stage learn everything that is there to learn in your working environment. Learn every tool/framework your team is using. Learn about the building process, deployment process, issue tracking process and as much as about your organization.

While doing so, don’t nudge other developers frequently. Ask only when you are unable to do it yourself.

You will be given small tasks to prove yourself. Do these insulting small tasks with due diligence. Prove yourself in these small combats until you are the commander.

Stage 2

Learn transferable skills. Transferable skills are those skills that can be used across different fields. Examples are problem-solving, researching, and writing. Specific examples for programming are algorithm design, object-oriented analysis and design, and process management like SCRUM or XP.

This is possible that the technologies or skills that you learn in the first stage will be non-existent after 5 years. Whereas transferable skills will be with you for a lifetime.

The outcome of this stage will make you valuable across every other organization in the world. On the other hand, the outcome of the first stage will make you valuable in limited settings like your current organization or a very similar one.

Stage 3

The third stage is highly advanced and it will make you a developer that people will pay anything to have you. This stage is about defining your values and principles.

For example, everybody in my office knows that I am strictly against sharing my personal time with office time. Therefore, I end up with the team that shares the same principles and is the most productive team.

If you don’t define your principles others will define them. You will be dependent on others. You become a submissive employee who said ‘Yes’ to every wish of your employer.

At What Stage You Should Be?

You cannot say in the first week of the job: “Here are my rules and I only work by my rules”.

When you begin the most important thing is to learn about the environment and technology. After 3-6 month you should focus on transferable skills. After 3-5 years you are eligible to define your own principles and create your life around that.

Roadblocks and Challenges

Nothing in life is linear beside watching Netflix. There will be roadblocks along the way. Now I will tackle the roadblocks that a beginner developer will face.

Programming is Hard

If you consider programming hard when you were in college or a boot camp then here is a surprise for you. Real-life programming is even harder.

Also, if programming was easy for you during studies than brace yourself. Professional programming is going to test you. The scale at which you were working previously was small and pretty much predicted. Now you will have to deal with uncertainties and challenges of continuous change.

So, keep this in mind that it will be hard for you but as time progresses you are bound to become good in programming. All you have to do is stick to programming.

Learning

This is a good roadblock. Programming is not like other careers. In some careers, if you stick to rules you will be fine. In programming, the most challenging rule is: “Learn new rules of technology”.

‘Keep learning’ is a distinct feature of our field. The pace of upcoming technologies is so fast that a lot of things have changed in the last decade.

Why learning is hard?

The learning process is ‘Hard and slow’. I like hard but I don’t like slow. When learning, I know I will be slow and if I push myself I would create apps that an amateur developer cannot look without laughing.

Pain while learning is so much that in the whole process of learning we only remember the pain. We don’t remember the joy of accomplishments afterward.

Overwhelm vs Focus

The second reason that I resist learning is because of the overwhelming amount of technologies that are there to learn and my wish to learn them all.

But I could not because learning takes time and I will have to ‘choose’(Yes the ‘Decision Fatigue’ is real according to Mark Zuckerberg and Steve Jobs)

Once I wanted to learn about everything there is to learn about MVC from Microsoft, Java, Node and couple of other frameworks. But it’s not logical and I end up being learning MVC from Microsoft which fits the larger goal of mine.

3. Your Seniors

Dealing with senior developers is a challenging part for junior developers. There is a very fine line between getting help from them and offending them.

If you want to see how an offended developer looks like then visit StackOverflow and ask any basic question on the forum.

Many senior developers think that nowadays juniors don’t work hard or they don’t have enough training to do the job. Seniors developers forgot that they were junior too not a very long time ago and they did ask basic questions.

4. Fake Feeling of Incompetence.

Also known as impostor syndrome. Very common in junior developers. Also common in college students. You can deduct (as I have) impostor syndrome is common people who are learning.

Secondly, this is common in people who are doing a great job like Neil Gaiman and Neil Armstrong.

You are doing both. You are learning and doing a great job.

Knowing that you are feeling is impostor syndrome is a difficult thing. It is not like that one day you wake up and said: “Hmmm.. Yesterday I was feeling imposturous. ” This syndrome has many variations and forms that are difficult to identify.

If I write in my diary about my impostor syndrome that would be: “I am working hard for the last 2 years and when I look back there is not enough work done by me. Just routine tasks that add up to nothing. Now, I believe I am just a supporting role and not very important to the team”.

I still think that I am impostor even if I have been the best developer as told to me by seniors and management ‘offically’. But still, I don’t believe it. That’s impostor syndrome for me.

The most effective solution to fight this syndrome is recognizing that it exists. When you ‘Label’ your emotion than more than 80 percent negative effect of that emotion is gone.

5. You are the Roadblock

I knew a junior developer who was not taking breaks(like break tea, coffee, lunch). In the first year, he kept his head down and worked hard to prove himself.

He reminds me of myself too. Keeping track of every second of the day and anxious when I was assigned tasks. For the most part, this is good but not the optimal method to prove yourself.

Do you wanna know what did I lose with this attitude? I lose direction. What did I get? Burnout.

When you are busy doing the next task in your plate you forgot what you are missing in the long run. Most of the work that I did on the early days did not make any significant improvement in the bigger goals of my life.

Secondly, keeping hard on your yourself will burn you out. Before starting our programming career, we are mostly students in a university or a boot camp. Life was hard there.

When you join industry this struggles continues and if you don’t give yourself a break this accumulated stress will burn you out. I have seen victims of burnout. They now falsely believe that programming career is not for them.

More On Proving Yourself

If you like this post then subscribe to learn more about how to prove yourself. You will also get my step-by-step guide to creating your personal tool for fighting impostor syndrome.

Also, this guide will help you to:

• Document your progress
• Make better software task estimation
• Keep motivated
• Authentic self-appraisal

[maxbutton id=”2″ url=”http://eepurl.com/b34ZpL” ]

But the challenging part for me is should I update/add code directly or make improvement in the design before anything else.

How do I know if my codebase requires improvement in design? I know that instinctively and many other developers know that too. If your instincts are not good enough then your codebase will tell you by making your life harder if you try to change/update it.

We know what hard means. It means sitting late hours, breaking other tested/working features, stress and bashing from seniors/managers/customers and etc.

Who is responsible

A bad codebase can be compiled to a functional product. I know a lot of badly structured codebases that compiled to working products and are working fine. (only for the time being–but I know one day they will break when someone is going for ‘new updates’)

Developers are lazy species. We don’t want to invest in things that don’t move the project. Often we want to get the work done now and think about the future later.

I don’t want to put all the responsibility to developers. In fact, developers are the least responsible. Most importantly it’s our eco-system that is not supportive. It’s about the manager/team lead and the customers.

Managers don’t need a good codebase they need a working product. So does our customers. This cumulative act of not doing anything leads to bad design. Which lead to the bad codebase.

Inside-Out

Today let’s not focus on the outside world. Focus on us-the developers-why good quality codebase is important to us? Should we improve code structure before adding new code? Here is how I think about it:

Once I read that coffee/caffeine stimulates some chemicals in our brain. This stimulation makes us efficient but temporarily. It’s like getting charged up. When these chemicals get depleted so does our efficiency.

But this depleted energy is not at the normal level or previous non-caffeinated performance level. You will be unable to do a simple task. So, by taking coffee we are getting efficient temporarily but at the cost of lower downtime in the future.

Similarly, we are buying time from the future when we are not doing the necessary design changes today. By not updating code structure, it will be hard to update the codebase in the future.

So it’s up to you to decide whether you want to invest in the future or borrow from the future?

I am good at these types of tasks. I have vast experience and can do without any hassles. But still, I hate it.

Sound awkward?… Something you are good at and you hate it!… But Why?

I hate it because I am done with it. Doing a monotonous job is boring as hell.

There were days when I feel challenged when doing DAQ jobs. I solved many problems and posted articles about them.

We are programmers. We like creativity and we hate routine. Doing a similar type of job in a routine is boring for us.

One of my friends is working on android apps development in another organization. Whenever we meet I like to talk about android development because I love android development and have developed/published apps as my side projects.

Guess what my friend said about apps development? He does not like it.

For him, there is no more challenge in app development. App development has become a routine for him. He is more interested in the kind of work that I do.

Also, from research, I found that sticking to one technology domain will make you a dinosaur. If you do not learn new things you will perish.

You might be thinking that ‘Hmmm… what happens to the phrase: “Jack of all trades and master of none”. How will you achieve skills and ability if you do not stick to one technology?

There are two approaches. I will discuss them briefly.

1) Be the Ultimate Master in One Thing

Be so good in your field that nobody matches you. It’s like the number one player in sports. Or the number one surgeon of ‘XYZ’ body part.

If you are the best you will always be called upon. This is the approach that we are most familiar with.

2) The idea sex–Be good enough in two or more fields

The second approach is to be good enough in two fields and combine them. This is a new idea and popularized by the Matt Ridley in his Ted Talk.

It says that combine the experience of two fields and get something useful. Or if you know about more than one technology you are more useful because now you have the toolset to solve more problems.

For creative people like us, the second approach is more helpful. I found a piece of advice that is very helpful for software developers:

“Focusing on one technology is better for getting a job. Learning multiple technologies is better for building a career. Decide which of the two is what you want, and go from there.”

But in the technology world, new technologies emerging and disappearing day by day. How would you select, learn and apply a new technology? That I will discuss in the next email.

Finally, have you ever feel like me? Getting tired of the monotonous programming job. If yes tell me your stories.

But it was back in 2004. I was learning c++. That was the first language that I learned.

In the first few classes, I was feeling awesome. All those beginner things like variables, statements and the most comforting printf function that makes your program speak

Until I hit by the concept of loops and nested loops. They knocked me down on the ground and I end up practicing the concepts on paper the whole night.

But I can tell you now that it was worth the effort. Whenever you are learning any new language or framework you will be learning quickly in the start.

If you have learned to code HTML or python. The beginning is always easy and you are accomplishing something new every day. When you see yourself progressing you feel good and when you stuck– you know it sucks.

But advance concepts require more time to digest. The following picture represents the typical learning curve for any programming language or framework.

The flat curve represents when you are learning advanced concepts of programming. Here learning a programming language becomes painful. Really painful.

The Pain is Important to Learning

If you are a junior developer you know that in the start you will fly through the basics stuff and easy problems but when faced with difficult problems your learning curve will become flat.

For junior developers, this pain is amplified when there is no one to help them out. They feel alone and even the developers at stack overflow scold them for asking questions(which seniors consider as naive questions).

Most of the people fell off at this painful moment. But in my opinion, this is the golden moment. The moment when you start to feel the pain while learning. Because pain represents long-lasting learning.

This is the pain that I felt when learning advanced concepts in C++. There were many hurdles. Help from my classmates was not possible and the computer at my home was malfunctioning.

The only working method was to practice even when I don’t have a computer, therefore, I practice on a piece of paper and later verify my programs on a computer.

My persistence besides the pain is still paying me. After that, I have never fallen during my life whenever I encounter loops or nested loops.

Pain Gives You a New Perspective

Another painful moment for me, when I was programming a real-world application in Visual Basic 6.  I still remember that I snatched my hairs out whenever I have to make changes to my code.

Is it because of VB6? It was because of bad code structure. Procedural programming leads to bad code structure. VB6 is a procedural programming language.

But I have seen people using JAVA/C# like a procedural programming language. Even I myself have fallen to this trap. Because every OO programming language allows you to write code in OO way but does not force you to.

The pain of bad code structure pushes me to create good code structure which led me to learn OO programming. If I didn’t snatch my hairs out then I will still be using C# as a procedural programming language.

I did not learn OOP for the sake of learning another programming language. I learned it because I wanted to write a good code structure. Now I create code structures where changes are easier to implement.

So, in my opinion:

If you don’t feel the pain of bad code you will not strive for the quality code.

Why Nobody is Telling you the Truth?

There is only one reason ‘Feeling of accomplishment’. Do you know why many books and khan academy coding tutorials start with ‘hello world’ stuff? Because the ‘hello world’ is easy and it will give you a feeling of accomplishment.

If they tell you the truth and throw the hard stuff at you what will happen? You will stop reading or watching. They don’t want that.

Their claims are high like learn python in 24-hours or learn PHP in 21 days. I know because I have read a lot of books on programming. Learning a language consume more time than 24 hours or 21 days.

I am not against the basics or ‘Hello World’ stuff. I know you have to start from basics and then progress. But many programming books and tutorials start and stop at the basic stuff.

One classic example is object-oriented design books and tutorials. They start with basics of OO programming language like the definition and syntax of class and objects. But we all know that is not related to object-oriented design.

There is a difference between object-oriented programming and object-oriented design. To differentiate between OO programming and OO design there is a phrase in the book UML Distilled by Martin Fowler.

Knowing how to use a hammer does not make you an architect.

But unfortunately, many books and tutorials do the crime of including the basic oo programming stuff in OO design books and tutorials.

They do it because OO design is hard and even harder to apply in your own projects. Hence it is not possible to attain a sense of accomplishment. Therefore they include the fluff and keep themselves in the basics and the easy stuff.

When you are coming from a learning environment to a professional environment major change will be more complex projects than all projects of your classroom and on top of that, you will have to deal with your team lead.

For junior developers, its gonna be a hustle. Your team lead will ask to give estimates on the fly and often you will commit more than you can deliver. Also, you will have to deal with non-technical issues like managing someone else work or meeting the unrealistic demands.

So let’s deep dive into the types of team leads that you can face. In the end, I will share how to deal with them. Generally, there are two extremes technical and non-technical. I will start with technical and their variants and move to the non-technical team leads.

Technical Team Lead

Technical bosses are those kinds of bosses who are perceived as technical which means they have education in a technical field like computer engineering, electronics/electrical engineering and etc. Following are some of the variants of technical bosses.

A) Who Forgot what They learned

They are technical but when you really grilled them they don’t have any idea about the technical details. Why?

There could be several reasons. Maybe they joined the company as technical persons and your company doesn’t fire people. So they climb the ladder by giving 10 years to the organization and become bosses of junior technical people.

The problem is they know very little about the technical details and want to contribute to design and development. You know what happens next…

B) Technical but not in Your Field

These bosses technically sound in some other field but not in the programming field. Let’s say an organization developed a product that has different sub-systems. For example, a cellular phone development company has separate departments for communication, electronics, software development and etc.

Now it is possible that a person may have joined your organization in the electronics department as a junior electronics engineer. Afterward, he got promoted and now he is managing director of both software development and electronics.

Therefore, this type of boss knows little about your field and knows a lot about his own field i.e. electronics.

The problem is that electronics development is quite different than software development. Your boss knows about electronics and there is a mismatch in the expertise.

C) The Generalist

Another type of boss is someone who has a little knowledge of what is going on but does not know about the minute details of the task. Majority of your bosses will be like that. Not every one of your boss knows how to fix CSS issues but they have an overall idea of how CSS work.

They are good bosses. But they become violent when they try to estimate on their little knowledge. When you say to them it will take a day or two for a task they will respond with “Ooh, in my opinion, it’s just copying and pasting and you have done something like that in the past” and you start thinking why I am here!

There are some great bosses in this category too. They have a little knowledge of your field. They will give you all the time because they trust you. Why? Because you are working on something that they knew and they are not blank.

D) Nostalgic

These are kind of bosses who have done software development in the old days i.e. 80’s and 90s (although programming is way older). Now if they continued in software development then they are smarter then you.

But if they changed their field. For example, they move to marketing or any other non-programming job or managerial job then it’s a different story.

Now when they see you programming then all the good memories or the heroic efforts that they have done in the past to rescue someone are coming back. They wanna help you like this:

They are going to interfere with you and slowed you down. They are old and they want to manage computer memory their own way. Even if you told them about built-in memory handler like JVM.

According to them, 2 Megabytes of memory is enough for your program and a Pentium 3 should be enough to run every software on the earth.

NON-TECHNICAL Team Lead

Describing a non-technical team lead is easy. Their only problem is “THEY ARE NOT TECHNICAL”. There is no variant in this category. Because you will always qualify them as ‘Non-technical’.

Either they are the ones whose money is on the stake or someone who is good at running businesses like a CEO.

In my opinion, they are easier to deal. They will doubt your opinion in the start. But since they have no knowledge of the technology, therefore, dealing with them is easy. You just have to remind them of the fact that they are non-technical. Politely of course.

Most importantly these types of bosses are looking for someone who they can trust. They just need one developer that they can trust-even if that developer is at the lower end of the spectrum in terms of technical skills.

For example, one of my friends is managing a product for a non-technical boss. Although his boss can hire a low-cost developer but he prefers my friend because my friend has earned the trust of his boss.

IDEAL Team Lead

Once I ask one of my peer friend about his future plans. I asked, “Do you want to see yourself in some sort of technical role.” He said, “yes, I don’t wanna stray away from technical knowledge.”

Then I ask about if you wanna go in some managerial role where you have to manage things. He again said yes because there are several things that can be done in better ways like the process of procurement and other non-technical stuff.

Turns out that he wants to gain best of the both worlds. So, I asked this question to a couple of others people and I found the similar results. Then I tried to find out such bosses in real-life.

I looked into heads of other departments. I found highly educated PhDs in management role. Who are top notch expert in their field but when they are in management role then they don’t have the time to do technical stuff.

I called such a boss an ideal boss. Someone who is best in the both environments. Technical and managerial. Did I find someone in the past decade? Nopes.

Don’t compare a senior developer or architect or tech lead with the boss or team lead. A senior developer is your mentor. He knows the stuff and he knows how to debug the code better than you. He may assigns you some tasks but remember that he is not your boss.

Your boss is someone who is writing the paychecks. Hiring/firing people. Getting new projects. Talking to customers. Assigning resources.

How To Deal With Team Leads as a Software Developer?

I will share three tips that work with all type of team leads.

1) Limit Your Options

First of all, you should give your team lead options to choose from when asking for a solution. Don’t leave them blank. If you leave them blank they will give you suggestions that will blast your head. So always give them options. The question is how many?

I once heard from a politician that Army Generals usually gave three options to Presidents. First is the solution that nobody likes. The third options is the solution that is the idealist and cannot be achieved but the middle one is the solution that is achievable. Most importantly this middle option is the one the general wanted to implement.

Also according to Steve McConnell in his ‘Software Estimation’ book, there are techniques that let you play with more options and there are techniques that give limited options.

So techniques with more options will give a varying range of estimates and techniques with fewer options will generate a consistent estimate. Hence give your bosses limited options to choose from. Also, options should be in the range of 2-3.

2) Solve Their Problems First

One of my readers said to me he has to deal with a cluttered codebase and it can become better if object-oriented methodology is used properly. But his team lead was interested in rectifying the problem not making a good OO design.

So, most of the bosses are interested in solving their own problems and they are less interested in how you are going to solve it.

So always tell them how the problem will be solved and how it will look like after the problem is solved. Don’t bore them with the techniques that you will use to solve it.

3) Prove yourself with your technical skill even if you have little experience

In my organization, we have bosses at different hierarchies. Once I was called upon by the boss of my boss. He asked me about a critical task and how I will solve it. I gave him all the language, tools and libraries that I have used or read about and told him that I can do the task.

He encourages me and let me go. Afterward, he asks my immediate boss “Is he gonna solve it?”

What………………? Everything that I told him was of less importance. The recommendation of my immediate boss was more important.

Since my immediate boss knows me and I have proved myself to him, therefore, he reassures the senior boss. But you can see what is happening here.

If you wanna prove yourself with your technical abilities then prove it in front of your immediate boss or even to the senior developer and they will recommend you to their boss.

When you have this level of confidence from your bosses then it will be easier to work with them.

I believe these techniques help you. Finally, what have you done to smooth out the friction with your bosses? Tell me in the comments below.