Category: Blogging

Year 2020: New Beginnings

The time is 2357hrs on Jan 1, 2020 when I started writing this entry and by the time I post it, it will be the 2nd day of the new year.

I don’t have any new year resolution, nor will I define one for the rest of the year.

But there will be a few things that I want to focus on.

I will be a better writer than I was in 2019.

I will be a better software developer than I was in 2019

I will work on my confidence and self-esteem issues and be a better version of me in 2020.

And I have no doubt there will be a ton of setbacks and growing pains.

But I will keep fighting on, to live a life that I want and be able to tell my 80 year old self I have no regrets.

What are you?

In your professional life, are you a creator, a robot or somewhere in between?

Your answer reflects your attitude towards work. Therefore, it makes perfect sense for you to be getting the kind of salary you are getting.

If you don’t like what you are making in terms of income, why aren’t you changing your answer?

In your personal life, do you feel like you are a giver, receiver or somewhere in between?

Your answer reflects your attitude towards life in general. If you find that you are not feeling fulfilled, then maybe it’s time you review your mindset and change.

The house by the sea

Just imagine this.

You live in a house, built out of bamboo and wood, out by the sea. It sat on top of wooden pillars that served as the house’s foundation. They were hammered into the sea bed with the top of the pillars jutting above the sea as though they are struggling for air. But all is good. You got a house to live in and you are out here by the sea, enjoying what nature’s got to offer you.

Then, environment effects attacked the house and its foundation, eating away pieces of wood and bamboo. Years went by. Decades went by. Holes began to appear along the house walls and sections started falling apart. Simultaneously, the house is wobbly and sinking centimetres every year due to weakened foundation. The sea bed in which the pillars stood had grown soft and unable to support the weight of the house.

But it’s your house and you can’t move. You refuse to let it fall apart. And so, you went to work to patch up the house. Every day without fail, you are fixing something. You knew it’s going to be a life long work.

Sadly, that’s not the only thing you have to deal with. You live with bad neighbours. Every time you patch up a section of your house, your neighbours come along and throw rocks at your house causing further damage. And you just keep patching.

And one day, you slipped and hurt yourself so badly that you almost couldn’t move. The pain was unbearable. Yet, you still keep going. You don’t really have a choice. Your house is falling apart, allowing the elements in. You are either wet, cold or too hot. The house can’t keep you in a goldilocks state.

So you work even though the world is against you.

Reflecting on my first pair programming interview

For those who don’t know what is pair programming, it is basically a software development technique where two developers/software engineers work together on the same machine. At any one time, one would be doing the actual programming and the other would be reviewing the written code. In both cases, communication between the two developers/engineers is very important.

Pair programming is usually done at some companies who want shipped codes or software that has fewer defects. After all, defects on shipped code could mean higher cost in terms of quality checks and troubleshooting.

And for some companies pair programming is also done as one of the interview stages. One of the purpose is the interviewer to figure out if you are suitable for the position. Interviewees are judged on their soft skills such as communication, ability to problem solve, plan and think critically, and technical capabilities. Another purpose would be to determine if the interviewee is able to work with other developers in the company.

Pair programming interviews are also there for the interviewees to understand who they are working with and how they may have to work in the company. It’s a good chance to find out if he or she is suitable for the applied role.

For me, despite working as a software engineer for five years now, I have never done pair programming. Most of the time, I work alone or in a team. And when it comes to interviews, the toughest kind I get are those where you have to do technical quizzes, solve programming challenges or do whiteboard problem solving.

So having to do a pair programming interview for the first time is both exciting and scary. And sad to say, I didn’t pass the interview.

Towards the end of the interview, the interviewer gave some really honest and constructive feedbacks that are helpful for my personal growth. I thank him for that and for the time he spent on me.

At the same time, I feel really shitty about the interview failure, which is expected. But my mood is now about to fall off the cliff. For some context, I have been struggling with burnout for months, depression and forms of anxiety for the last four. My mood was only just stabilising after three weeks of anti-depressants.

Don’t get me wrong, I’m not looking for any sympathy nor trying to guilt trip anyone. I’m just sharing what I am feeling and have been through.

So what went wrong and could be better?

Low to average technical skills

My JavaScript fundamentals are weak. I was having issues with lambda and anonymous functions as well as some other fundamentals like passing of data. It prevented me from figuring out the solutions to some of the problems I encountered. The last time I did any decent amount of JavaScript was two years ago and even then, I only used the surface of what the language is capable of.

Making matters worse, I had to work with ReactJS, which is a JavaScript framework for developing UI. I also have to work with Redux, which is another JavaScript framework for state management. And it was no fault of the interviewer. I indicated that I want to do frontend development with ReactJS during the previous interview with one of the company’s employee.

At the end, a couple of hours spent every night for the past four days to learn ReactJS and Redux simply isn’t going to cut it.

But it doesn’t change anything. If I still want to be a frontend developer and be good with ReactJS/Redux, I have to keep learning and practice. And develop some apps using those frameworks along the way.

Failure to comprehend actual requirements

This is really on me. I was given the chance to read about the requirements and end goal of the exercise. The key focus areas were listed down in the document. But for some reason, I didn’t realise that I hadn’t really read and understand the whole thing before jumping in to come up with a solution. I could only attribute it to stress and anxiety.

Due to that, the solution I came up with was half-baked and caused major problems further down the development process.

Therefore, I really have to work on improving my resilience to stress and directing the brain to focus better. This is the only way for me to be able to understand future situations more clearly and come up with a better solution.

Overengineering

In software development, there are three principles that all developers should follow for higher productivity. They are:

  1. DRY => “Don’t repeat yourself”
  2. YAGNI => “You aren’t going to need it”
  3. KISS => “Keep it stupid simple or “keep it simple, stupid”

And because of my failure to comprehend the actual problem, my half-baked solutions caused me to violate principle 2 and 3. There were additional React components that I created that weren’t necessary and made the codebase more complex.

I’ll admit that I violated those two principles a lot of time during my five years of software development experience. It is because I like to provision for future uses. Breaking those principles served me well so far because I have experienced scope creep that requires components or functionalities that I thought of in advance and had implemented. That means, I didn’t need to spend extra effort to develop and refactor my code later.

Going forward, I really need to train myself on going for the simplest and fastest solution to any problem.

Took too long and prevented successful gauge of my skills

Because of overengineering, it took me more than twenty minutes to develop the application foundation. After which, I had to redo some of my codes in order to support certain functionalities that I have overlooked because of my failure to read and comprehend the requirements. More time was wasted.

Therefore, I was unable to implement the other features of the application that would have allowed the interviewer to determine my understanding of ReactJS and Redux.

Final thoughts

Self-awareness is actually a very important skill to have. With it, you might be able to determine if you are suitable for a given role or job.

In my case, the combination of my highly-sensitive nature, under-developed stress resilience, highly self-critical and low self-esteem meant that I hadn’t really been able to function at the level required for a so-called experienced software engineer who’s been at this job for at least five years. I’m simply not ready yet to take on roles that require me to be a consultant or a quick thinker.

The other thing that I figured out was that the number of years of experience isn’t really a good gauge of your skills. The interviewer did point out that despite my years of experience, I still wasn’t able to grasp ReactJS even after 24 hours (spread over four days) of reading and practice. He implied that he was able to pick up the framework within two days instead of four.

With that, it could mean that either my fundamentals are very weak or that I’m simply not smart enough to pick up something fast. Or maybe both. For the former, I could work on it by going to read and study the fundamentals again. For the latter, well, I can only work harder than most to achieve the same skill level.

Either way, I’m just glad that I’ve been through it and knows what’s out there. There are valuable lessons to be learnt here, which is all that matters.