What are your programming weaknesses?

It's human nature to focus on strength first. As a programmer, it’s natural to consider the programming strength when it comes to considering it as a career goal. I personally believe that your weaknesses are the biggest roadblock to your success. It has a huge impact when you attend a technical interview where some of the weaknesses start coming to the forefront. This also applies in your daily professional deliverables. I am sure most of us have experienced this at some point in our career where we either missed an important deadline or failed an interview. We are all humans and we all have weaknesses. It’s ok as long as you acknowledge and work on it. Even the strongest Superman has a weakness in the form of kryptonite, which makes him extremely weak. The first step towards working on your weaknesses is to identify them.

How to identify weaknesses?

The best way to identify a weakness is by learning its side effects. This is one of the easiest approaches in understanding the areas you need to work on the most.

Coding too slowly: Very often, we find ourselves starting off on a normal pace but eventually lose the pace. Why? We often put it back on a few of the decisions that the team may have made, such as priorities, timelines, requirement changes, etc. However, we often neglect to focus on our own performance and do not give it a benefit of doubt. Few of the personal lack can be due to multiple factors:

1. Issues in understanding the requirements
2. Inadequate programming skills
3. Struggle to adopt the coding environment
4. Unable to keep up with internal processes
5. Inability to make certain programming decisions

Lots of bugs and regression in your code: This is a very common theme for many programmers. You code and produce bugs, you fix one and produce two more issues. This can be the result of a combination of multiple reasons. The primary reason for making one break two is inability to test your own code. This occurs because of lack of focus, overconfidence, and unaware of interwoven modules and requirements. Many times, it can also be due to cutting corners when it comes to fixing a bug, such as ensuring to deliver something on time but by losing the overall quality.

Fail to deliver: It’s natural to finish what you’ve started. However, it does happen where due to lack of estimating (read guesstimating :)) skills, you may either inflate or deflate a timeline. Making estimate errors are very common in project management and perhaps one of the most important skills as a programmer you may need to work upon. I’ve also encountered many programmers who cannot push back an assigned work. In other words, they do not know how to say “No”. Learning to say “No” is an important communication skill. When a No is backed with the right rationale, it can often work as a convincing factor to stay within the timeline.

Coding weaknesses

So far, we’ve discussed some higher level soft skill weaknesses. However, it’s not necessary that the roadblock is restricted to only the management-related limitations. Let’s look at some of the lower level coding habits that can have an impact on your performance.

• Writes monolithic code: A lot of times, we get carried away with a notion to code logic into one big file. Say, 4000 lines of code residing in one giant file, which makes debugging and readability a big struggle, especially, when someone else has to take over your code! In such cases, it’s best to modularize your code.
• Lack of documentation or comments: As programmers, we all hate writing documentation. We safely assume that what we understand is what we write and what we write is understood by the rest too! Code comments and general documentation that can narrate the importance of methods, parameters, and many such components of your code makes it a full package.
• Not formatting your code regularly: Even in this modern age of advanced coding tools and technology, a lot of programmers do not fully use the code formatting features. The outcome is an unhealthy state of readability, which consumes more debugging time and proves painful if someone else has to work on an unformatted code.
• Lack of nomenclature: When one doesn’t follow nomenclature, it results in an inconsistent naming convention across the entire system. For example, a getter or setter method usually would start with an action verb like “getName” or “setName”. Similarly, variables would follow a meaningful noun such as “employeeName”. Likewise, there are naming conventions to use capital letters, which are often called camel casing.

Overall, I would say plan before you write your code and it will solve a lot of your problems. Ask for help if you don’t understand something but make sure you have tried a few things and researched enough for the issue you’ve encountered.