New tech blog and post

I have launched a new blog to cover topics related to technology, software and other more technical stuff. It is to leave this blog free to host contents related to my personal growth, insights, feelings and fiction.

You can check the first post of the tech blog here. It is a technical article that introduce you to Microservices.

The clearing that lead into the light

The last two weeks saw me dedicating my time to serving the nation. Those two weeks being away from my job, be with friends who served with me during the two years of national service and doing light duty had allowed me to clear my head and helped raise my mood. Of course I won’t say it was a perfect streak. There were days when I had low mood, but with my friends around, I still felt better as compared to what I have gone through for the past four months.

That’s where the title of this entry came from. My head felt lighter and clearer. I’m less withdrawn too. In hindsight, this whole episode can be seen as part of my growing pains. Yes, there are antidepressant and therapy sessions involved but at least I’m proud that I didn’t take the easy and irresponsible way out. I saw that I had a problem and needed professional help. So I went to get it.

And I’m not going to compare myself with others. Everyone has got their own strengths and weakness. I’m not a genius, the fastest thinker around or the best performing employee of the year and I’m not going to proclaim to be any of those. I’m just going to focus on what I do best, be humble, develop more skills and bring them to the table to contribute in whatever way I can. Comparing is just a waste of time and being sensitive to the result of comparison is one of the few contributing factors that let me down this dark path. Right now, all I ask is people giving me the space and opportunity to learn and grow at my own pace.

Another good thing that came out of those two weeks was that I started a new writing project, which to me is a major win considering how worthless and useless I felt just a few weeks ago. Every setback was really painful for me then. And this time, instead of jumping straight into writing, I went the route of outlining and planning out my approach. Some lessons had to be learnt from jumping straight into a project without some sort of a plan and then failing not just once but several times over the years.

At first, I did it with pen and paper. Then I typed out the outlines and plan onto Apple Note. I’m still in the process of digitising the rest of the content. And when I do have some additional ideas, I will pen it down on paper first. Overall, this project is kind of like a phoenix rising from ashes because it is based on the previous project that I scrapped two months ago because I felt the story was heading in the wrong direction. The theme remained the same while changes were made to the characters and settings.

I’m also trying produce more useful, technical contents based on my professional experience. This, I believe, is a good way for me to communicate what I’ve learnt and in turn help others. Previously, I mentioned that I volunteered some of my time to write technical articles for a company. The process was enjoyable and I’d like to continue that for other companies too. I’m on a look out for such opportunity and will get in touch if I find that I can contribute in a meaningful way.

Lastly, I was officially requested to help out in another project so that the official deployment/rollout end of November can be as smooth as possible. There were enhancement and modification to be made for a specific module before the rollout. And I am the best person to do it because I was the one who designed, developed and supported that module since that project’s inception. Now, it’s all about clearing that last mile and seeing it through.

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.

Songs that communicate my feelings and thoughts

As I spent the day working on my personal projects, interacting with friends and applying for new jobs, I had to navigate through the emotional roller coaster due to certain triggers that led to flashbacks. Below are some songs that best communicate how I am feeling. Antidepressant made things a little easier for me to manage but low mood sometimes do popup.

Linkin Park – Heavy

Kodaline – Brother (Cover by Samuel Di Leo)

Linkin Park – One More Light

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.