It is time for a reboot

I have not been actively writing content for this particular blog.

Over the past few days, I came to the realisation that my perspective related to writing and approach to my personal brand in general have changed. Now, I believe I should probably have multiple specialised blogs instead of having one blog for everything.

Yes, it will take more effort for me to maintain and write content for multiple blogs. But, the advantage is that I can focus better on crafting contents that are more suitable for a particular blog and better serve the needs of my readers.

Therefore, I shall spend the next few days cleaning up this blog. My intention for this blog going forward is that it shall contain only contents related to writing, fiction and poems. Mental health related stories will go to their respective blog, one that I will launch soon. The same thing happened to articles related to environment and technology. I have created blogs for those topics.

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.

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:

DRY => “Don’t repeat yourself”
YAGNI => “You aren’t going to need it”
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.

Why writing longhand with pen and paper could be a good thing?

How many of you write your content using pen and paper before actually getting it onto other platforms for publishing?

If you do write using pen and paper, it’s great and would love to hear your thoughts about it.

For most of us, we’d probably write on computers. I write predominantly on computers too. It’s just a much more powerful tool, more convenient, and probably could write much faster.

However, due to the nature of my work, technology burnout is inevitable. For several days during this week, I couldn’t bring myself to use a computer or even my phone to write anything. Yet, there’s a book that need writing.

This was how the decision to reintroduce pen and paper into my writing life came about. I got a lecture pad and a black ballpoint pen. Then I got down to writing.

The experience was definitely painful at first because it’s been a while since I wrote longhand using pen and paper. After finding my handwriting in a total mess and my hand aching badly, I decided to use the pen correctly and even went to google for the right way to hold the pen or pencil for that matter. Then it was time to put it into practice.

I would say there were definitely some good and bad that came out of this process.

For me, it has been therapeutic. The chance to get away from technology is just great for my mental health.

Further more, I could focus better on my writing because there’s no internet involved. No Netflix. No music. No internet browser. If you put your technological devices out of reach, you have no choice but focus on the act of writing and the story you want to tell.

The second advantage come in the form of deliberate writing. Because writing on paper meant it’s nearly impossible to change what you wrote. Unless you want to leave behind lines after lines of strikethroughs or whiteouts, every word you want to put down on paper have to be the right word. This slows down your writing and forces you to think. This has the added advantage of allowing you to identify if there’s loopholes or problems with your content. This is especially helpful for me as a pantser because I won’t run astray with my writing and create plot holes.

The third advantage was that it’s just more natural. You can do whatever you want. Scribble along the margin of the page. Skip lines. Doodle. The freedom meant you could explore your ideas and thoughts in a more natural and faster way rather than having to conform to what the computer and software forces you to do.

The fourth advantage is the permanence of the content. Unless your notebook or lecture pad end up getting soak, caught fire or the pieces of paper blown away by the wind, you can always trust that your content won’t go away. That’s unlike when you are using a computer to write. Machine can fail. Storage devices, including cloud storage, can fail or corrupt your data.

But not everything is all so shiny and great.

The biggest disadvantage with using pen and paper is the speed of writing. Your arms and hands don’t move as fast when you have to draw out the arches and lines associated with latin characters whereas with a computer, a key press means a letter. Because of that, I find it much harder to get into the flow.

The second disadvantage is you can’t edit the content like you could on the computer. Every word that you write on paper is permanently set in stone, so to speak. If you want to change something, you have to strike out what you wrote or use whiteouts. And if you are like me who makes quite a lot of mistakes when writing, you will find that your paper may end up becoming a complete mess and hard to comprehend.

As for portability, it doesn’t concern me. I always bring a backpack when I go to work and I could just shove the lecture pad in it. And when it comes to publishing, well, since I’m writing a novel, it would be much later in the writing process that I have to type them all out. With that, I’d probably do my editing concurrently. So I get to kill two birds with one stone.

Now, I won’t say every writer should write longhand using pen and paper. For most people, it would be very tedious and tiring. So if you prefer to write using your computer, then by all means do that. At the end of the day, the most important thing is getting your content out for your audience to consume and encourage them to come back for more. But if you find that your computer is getting in the way of you doing your work, then maybe it’s time to go old-school.