<ul><li> Weaknesses That Shaped Me To Become a Better Developer.</li></ul>

Have Look.

<h2 data-selectable-paragraph="">The Programmer World</h2><figure><img alt="Person covering their face with their hand" src="https://miro.medium.com/max/500/0*bJ72uxiKue6Riw7W" width="680" height="453"><figcaption class="ig ih cw cu cv ii ij cb b fw cd ce" data-selectable-paragraph="" dir="ltr">Picture by <a href="https://www.pexels.com/@mixu-513809" class="ch ik" rel="noopener" dir="ltr">Mixu</a> in <a href="https://www.pexels.com/photo/woman-showing-her-hand-1243046/" class="ch ik" rel="noopener" dir="ltr">Pexels</a></figcaption></figure>We all are human. We are not perfect. We have weaknesses. It affects us. It does make us a lesser person than what we want. However, if we know how to channel it properly, it can become a great tool to move us forward.Similarly, as developers, some of these weaknesses may seem to be a stumbling block to our career, but we can turn it over and help us progress.Below are a few of my experiences.<h1 data-selectable-paragraph="">1. Cannot Articulate Without Substance</h1>Communication is important for one’s career. The ability to articulate well makes one a better communicator.For me, I find it hard to articulate something without really knowing it. I need to work on it, be sure how it is done before I can start communicating and sharing it out. It always amazes me that some people have the ability to make a solid presentation from the little they know.Therefore, when beginning a new career, a new project that I’m unfamiliar with, I hardly can make any commitment and rarely provide any inputs. I always have a slower start. This inability makes me strive, get myself prepared for it, dirty my hands, and ensure I know the details.Once I get on to it, I will be able to share, communicate, and commit to it better. I know what I say, as I am experienced with it. I know the context, and I am able to articulate it much better. Things that I say are now more substantial and reliable.These limitations force me to prepare for any project and work. Can’t complain.<h1 data-selectable-paragraph="">2. Poor Command in Verbal Communication</h1>English is not my native language. I learned it as a compulsory subject in school. Language was never one of my favorite subjects, and I don’t have a strong command of any language.My writing skill is better than my oral skill. Verbal communication is harder as we need to think on our feet. But in writing, we have time to choose proper words and structure our sentences properly.Due to this limitation, whenever I am preparing for the kick-off of a project etc., I will usually write out what I need to share, as it clears my mind. Then, I will send my writing before the project’s start, so others can get a heads-up of what’s coming.When creating technical writeups, most of the time, I use diagrams to illustrate what I meant as much as possible. I find this simplifies all technical points I try to make. These diagrams turn out to also be useful during kick-off and discussion as I share them with the team.Documentation is not my favorite thing to do. I do it because I need to. And it turns out to help much and be appreciated by my fellow developers.<h1 data-selectable-paragraph="">3. The Urge To Know All Details as Much as Possible</h1>I have this problem. When I discover something I don’t know, I will want to dive into it as much as possible. It is related to my previous problem, where if I cannot fully comprehend it, I feel lost.A simple example: I know that PorterDuff Mode is for image processing. Most people use it just for rounding an image. If we need to do the same, we can just reuse or copy the code. There’s no need to learn what else PorterDuff Mode can do.In feeling the gap, I just get myself some time to deep dive into the details. Checking out every possible aspect, and understand how to practically use them.Another example is the complete suite of Kotlin Collection Functions. I compile it as much and try to go through 200 of them, one by one.It is really time-consuming. Lots of effort spent. I don’t claim to be an expert nor remember everything I have learned, but what I have learned makes some footprints in my memory. As I have documented what I have learned, in times when there’s a scenario it can be of use, I can recollect something exists, and go back to it much faster (how I did it is in point five below).It is impossible to learn everything. It takes time. But whatever learned will be a plus.<h1 data-selectable-paragraph="">4. Never the Brilliant One; It Takes Time to Learn</h1>I envy people who think fast. Grab abstract knowledge quickly. When they listen to technical sharing, nodding in full understanding of what has been shared.I’m not like that. I have to listen to tech sharing over and over again. I have to code it to see and understand what the trainer says. I have to slowly dig into it like peeling an onion, understanding each layer slowly, and getting to the very basic components to understand from there. Then slowly get back to the big picture.In the process of doing so, I get to discover much more and understand the nuances of the subject. I also dig into why the particular topic was so difficult for me to understand at the beginning; perhaps I lost some context or misunderstood part of the statement.As I understand more about the subject, I choose to write and share it in a simpler manner with all, in hopes that those who face the same challenge will learn it easier. One example is below:Such a collection of learning helps me build my knowledge slowly but surely. It is painful at the beginning but gets easier as we stack up the knowledge we learn.It is still hard when I get into a new subject or area, but with effort, it is not impossible to learn and master it.<h1 data-selectable-paragraph="">5. I Am Forgetful … I Forget What I Learned Quickly</h1>When I deep dive into a particular technical topic, I feel like I have a great view of it. I can explain the details, and address any issues I face with it. That’s such a great feeling.However, as a developer, we don’t dwell on some technical areas for a long time. We use one extensively for a period of time, and then move on. It might be a while until we get back to this technical area again.In my experience, although we move on, at times we need to get back into that technical area again. Given the deep context of those items, I cannot recall what I have learned. I may have a vague memory of it, but lots of digging is needed to get back to where I was previously.Because of such forgetful attributes I have, the moment I learn deeply on a certain topic, I quickly document what I learned. I create a simple project with real code on git-repo, write down every nuance possible, and elaborate it as clearly as possible.Again, writing this up takes time. We might not get back to use it again. So that’s the reason I share it with others on Medium. At least it helps others if we never need it again.But when we do need it again, it becomes super, super helpful! A quick glance, and I recall so much more. Even if I forgot the detail of it, I have the repo example of the simple workable code I wrote previously.Everything becomes super clear as I was the author of it. (okay… not super clear at times, I regret not putting some details and writing it clearer… but you know, it still helps heaps).<h1 data-selectable-paragraph="">6. Lacking Confidence and Feeling Incompetent</h1>Perhaps due to my family upbringing or my own personality trait as above, I hardly feel competent in anything I do. I need to work really hard before I can feel I am “okay” in some areas.When I first started my career, I looked up to senior and more experienced developers. They had so much industrial knowledge that I hardly learned about back in uni. I felt timid in their presence during technical discussions, so I eagerly learned from them as much as I could when the opportunity arose.As I age and gain more knowledge, I am no longer that timid. I interact better with others, though I still feel lacking from time to time, especially compared to the knowledge of the people surrounding me, which includes developers who are more junior than me.That feeling does make me humble because I know there is still much to be learned. I often ask the younger developers about the areas I don’t understand and seek to learn from them. I have to say I learned a lot!Hence, that feeling of incompetency makes me look up to everyone and know I can still learn something from everyone. I am never shy to ask, as I am not the expert. Each time I ask and learn, it makes me a better developer.<h1 data-selectable-paragraph="">7. A Slow Thinker… as I Think Too Much!</h1>Years back, the girl I liked asked me if I wanted to join an event one day. A normal response would say “yes,” but I hesitated. I thought what if this, what if that…A manager considered giving me a promotion on a job. I hesitated, thinking “Can I make it?”, “What if I fail?”Terrible terrible trait! I’m trying to be more decisive and improve my decision-making abilities.However, such a scenario-building thinking process, when applied to doing programming, helps so much! As I code or document, my brain starts to think of various corner cases and potential issues happening.Initially, the “many-branches-of-thinking” was much of a distraction, as we complicate a given problem. As I learn how to park them and partition them, it becomes a way of scoping the work into smaller tasks and formulating test scenarios.I better make sure I don’t dump this trait entirely. 😅<h1 data-selectable-paragraph="">8. Easy Going… No Particular Preference Mostly</h1>This is a very counterintuitive trait for a programmer. A programmer is supposed to be opinionated and have a strong preference — from the choice of language to the preference of style.Styles as simple as tabs vs. spaces, semicolons, curly braces have caused decades of fighting in the programming world.For me, well, I have some views, but I can see the point from both sides. I did try to be opinionated (as that seems like a requirement to be a programmer 😛), but ultimately, I still succumbed to the majority preference.How can this be a great trait for programmers? Well, I make friends and connect well with everyone. I blend into the developers’ group and assimilate well with the group. I learn and see the viewpoints of both, and get to slowly digest and rationalize them.After getting all inputs from different ends, I do form my opinions. Such opinions can be more holistic, as they encompass different sides of considerations.With that, I do have opinions now, but I’m still flexible, and I flow well. To me, group preference takes precedence over oneself, and I get to see from more angles.<h1 data-selectable-paragraph="">TL; DR</h1>We all have weaknesses. It is inevitable. But that doesn’t mean these weaknesses have to define what we can be.If we just flow with it and succumb to it, we feel defeated and get into a vicious cycle, which makes it harder and harder to get out.However, if we work on it, make efforts to compensate for what the weakness doesn’t provide us, we might be surprised by the outcome. It might turn out better than if we didn’t have the weaknesses. They can be a blessing in disguise.

We all are human. We are not perfect. We have weaknesses. It affects us. It does make us a lesser person than what we want. However, if we know how to channel it properly, it can become a great tool…

computerscience

Computer Science

We all are human. We are not perfect. We have weaknesses. It affects us. It does make us a lesser person than what we want. However, if we know how to channel it properly, it can become a great tool to move us forward.

Similarly, as developers, some of these weaknesses may seem to be a stumbling block to our career, but we can turn it over and help us progress.

Below are a few of my experiences.

Communication is important for one’s career. The ability to articulate well makes one a better communicator.

For me, I find it hard to articulate something without really knowing it. I need to work on it, be sure how it is done before I can start communicating and sharing it out. It always amazes me that some people have the ability to make a solid presentation from the little they know.

Therefore, when beginning a new career, a new project that I’m unfamiliar with, I hardly can make any commitment and rarely provide any inputs. I always have a slower start. This inability makes me strive, get myself prepared for it, dirty my hands, and ensure I know the details.

Once I get on to it, I will be able to share, communicate, and commit to it better. I know what I say, as I am experienced with it. I know the context, and I am able to articulate it much better. Things that I say are now more substantial and reliable.

These limitations force me to prepare for any project and work. Can’t complain.

English is not my native language. I learned it as a compulsory subject in school. Language was never one of my favorite subjects, and I don’t have a strong command of any language.

My writing skill is better than my oral skill. Verbal communication is harder as we need to think on our feet. But in writing, we have time to choose proper words and structure our sentences properly.

Due to this limitation, whenever I am preparing for the kick-off of a project etc., I will usually write out what I need to share, as it clears my mind. Then, I will send my writing before the project’s start, so others can get a heads-up of what’s coming.

When creating technical writeups, most of the time, I use diagrams to illustrate what I meant as much as possible. I find this simplifies all technical points I try to make. These diagrams turn out to also be useful during kick-off and discussion as I share them with the team.

Documentation is not my favorite thing to do. I do it because I need to. And it turns out to help much and be appreciated by my fellow developers.

3. The Urge To Know All Details as Much as Possible

I have this problem. When I discover something I don’t know, I will want to dive into it as much as possible. It is related to my previous problem, where if I cannot fully comprehend it, I feel lost.

A simple example: I know that PorterDuff Mode is for image processing. Most people use it just for rounding an image. If we need to do the same, we can just reuse or copy the code. There’s no need to learn what else PorterDuff Mode can do.

In feeling the gap, I just get myself some time to deep dive into the details. Checking out every possible aspect, and understand how to practically use them.

Another example is the complete suite of Kotlin Collection Functions. I compile it as much and try to go through 200 of them, one by one.

It is really time-consuming. Lots of effort spent. I don’t claim to be an expert nor remember everything I have learned, but what I have learned makes some footprints in my memory. As I have documented what I have learned, in times when there’s a scenario it can be of use, I can recollect something exists, and go back to it much faster (how I did it is in point five below).

It is impossible to learn everything. It takes time. But whatever learned will be a plus.

4. Never the Brilliant One; It Takes Time to Learn

I envy people who think fast. Grab abstract knowledge quickly. When they listen to technical sharing, nodding in full understanding of what has been shared.

I’m not like that. I have to listen to tech sharing over and over again. I have to code it to see and understand what the trainer says. I have to slowly dig into it like peeling an onion, understanding each layer slowly, and getting to the very basic components to understand from there. Then slowly get back to the big picture.

In the process of doing so, I get to discover much more and understand the nuances of the subject. I also dig into why the particular topic was so difficult for me to understand at the beginning; perhaps I lost some context or misunderstood part of the statement.

As I understand more about the subject, I choose to write and share it in a simpler manner with all, in hopes that those who face the same challenge will learn it easier. One example is below:

Such a collection of learning helps me build my knowledge slowly but surely. It is painful at the beginning but gets easier as we stack up the knowledge we learn.

It is still hard when I get into a new subject or area, but with effort, it is not impossible to learn and master it.

5. I Am Forgetful … I Forget What I Learned Quickly

When I deep dive into a particular technical topic, I feel like I have a great view of it. I can explain the details, and address any issues I face with it. That’s such a great feeling.

However, as a developer, we don’t dwell on some technical areas for a long time. We use one extensively for a period of time, and then move on. It might be a while until we get back to this technical area again.

In my experience, although we move on, at times we need to get back into that technical area again. Given the deep context of those items, I cannot recall what I have learned. I may have a vague memory of it, but lots of digging is needed to get back to where I was previously.

Because of such forgetful attributes I have, the moment I learn deeply on a certain topic, I quickly document what I learned. I create a simple project with real code on git-repo, write down every nuance possible, and elaborate it as clearly as possible.

Again, writing this up takes time. We might not get back to use it again. So that’s the reason I share it with others on Medium. At least it helps others if we never need it again.

But when we do need it again, it becomes super, super helpful! A quick glance, and I recall so much more. Even if I forgot the detail of it, I have the repo example of the simple workable code I wrote previously.

Everything becomes super clear as I was the author of it. (okay… not super clear at times, I regret not putting some details and writing it clearer… but you know, it still helps heaps).

6. Lacking Confidence and Feeling Incompetent

Perhaps due to my family upbringing or my own personality trait as above, I hardly feel competent in anything I do. I need to work really hard before I can feel I am “okay” in some areas.

When I first started my career, I looked up to senior and more experienced developers. They had so much industrial knowledge that I hardly learned about back in uni. I felt timid in their presence during technical discussions, so I eagerly learned from them as much as I could when the opportunity arose.

As I age and gain more knowledge, I am no longer that timid. I interact better with others, though I still feel lacking from time to time, especially compared to the knowledge of the people surrounding me, which includes developers who are more junior than me.

That feeling does make me humble because I know there is still much to be learned. I often ask the younger developers about the areas I don’t understand and seek to learn from them. I have to say I learned a lot!

Hence, that feeling of incompetency makes me look up to everyone and know I can still learn something from everyone. I am never shy to ask, as I am not the expert. Each time I ask and learn, it makes me a better developer.

7. A Slow Thinker… as I Think Too Much!

Years back, the girl I liked asked me if I wanted to join an event one day. A normal response would say “yes,” but I hesitated. I thought what if this, what if that…

A manager considered giving me a promotion on a job. I hesitated, thinking “Can I make it?”, “What if I fail?”

Terrible terrible trait! I’m trying to be more decisive and improve my decision-making abilities.

However, such a scenario-building thinking process, when applied to doing programming, helps so much! As I code or document, my brain starts to think of various corner cases and potential issues happening.

Initially, the “many-branches-of-thinking” was much of a distraction, as we complicate a given problem. As I learn how to park them and partition them, it becomes a way of scoping the work into smaller tasks and formulating test scenarios.

I better make sure I don’t dump this trait entirely. 😅

8. Easy Going… No Particular Preference Mostly

This is a very counterintuitive trait for a programmer. A programmer is supposed to be opinionated and have a strong preference — from the choice of language to the preference of style.

Styles as simple as tabs vs. spaces, semicolons, curly braces have caused decades of fighting in the programming world.

For me, well, I have some views, but I can see the point from both sides. I did try to be opinionated (as that seems like a requirement to be a programmer 😛), but ultimately, I still succumbed to the majority preference.

How can this be a great trait for programmers? Well, I make friends and connect well with everyone. I blend into the developers’ group and assimilate well with the group. I learn and see the viewpoints of both, and get to slowly digest and rationalize them.

After getting all inputs from different ends, I do form my opinions. Such opinions can be more holistic, as they encompass different sides of considerations.

With that, I do have opinions now, but I’m still flexible, and I flow well. To me, group preference takes precedence over oneself, and I get to see from more angles.

We all have weaknesses. It is inevitable. But that doesn’t mean these weaknesses have to define what we can be.

If we just flow with it and succumb to it, we feel defeated and get into a vicious cycle, which makes it harder and harder to get out.

However, if we work on it, make efforts to compensate for what the weakness doesn’t provide us, we might be surprised by the outcome. It might turn out better than if we didn’t have the weaknesses. They can be a blessing in disguise.

8 Weaknesses That Shaped Me To Become a Better Developer

Have Look.

Chinmay Anand's ideas are part of this journey:

Related collections

Similar ideas