This year was a transition period for me from a career perspective. I was hearing, understanding and practicing stuff like microservices, fault tolerance, cross-site deployment, REST APIs, software deployment system, agile development and attending meetings & training sessions with the people on the other side of the planet 😅 . 3 years back I never thought I would end up being some place like this. That version of me just wanted to be a compositor.

Enough of blabbering, please connect with me on LinkedIn and come see what I’ve been through this year.

Code Review

As a Junior Pipeline Developer at Method Studios, it was first time my code was going to be part of some multinational corporate codebase. Well, code reviews can be cruel at times, but I can say, getting hurt act as a catalyst in changing one’s life. Someone with 2-5x experience than me can see how my code can break create regression in the future which will create a headache in debugging.

Writing any software is just 10% of the job. Rest 90% is maintaining it. Yes, you can write code and it will work. Have you documented your code? Have you written tests? Is your coding consistent over entire project? If your answer is no to all of these; no problem. Your code will still work. It will work even if you leave the company. But the person who comes after you will for sure curse you.

For me, one such case was to avoid the use of global variables. So the story is like this: I used as much global variables as possible

Code review can prevent these headaches right at the start. It also gives us a chance to hone our skills, systematically.

While writing code, make sure to keep the human being in mind who will be reading that in the future. Also, assume that they will be dumb (no offense).

Separate Client and Library Code

While reading through software packages this year, I started to see a pattern in almost every package. Packages used to have an api.py file that has no implementation. I learned to separate the library code and client code. This library code can be later be reused by other packages without caring about how the frontend has been developed. This pattern was always there in web application like Twitter, Facebook (or whatever services which open their API). They use the same API to to make their own application which all the public use. But also the API can be used from the third party like we developer. Better late than never.

Lesson learned: Expose the API so other similar packages can use it.

Separate Configuration from Application Code

Although I have seen this already in software like text editors, DCC softwares, terminals and pretty much every thing (which had some sort of configs system) had one thing in common, they had a system configuration, then there was a user configuration (on Linux this is in $HOME and $HOME/.config). This pattern is extended by text editors and IDEs to have a separate project configuration.

As a multinational company, Method has multiple facilities. And I saw this pattern being extended to have facility level configuration, so that each facility has some freedom in choosing optimal settings for them. Reasons may include limit access to resources, but it varies. This pattern is extended to fulfill some domain related needs which I not need to discuss.

You ship your code with default application settings, let people create their own. You maintain a map of settings and keep overwriting localized setting over the global one.

BoltDB

BoltDB is analogical to what SQLite is for SQL servers but key/value databases. I stumbled upon it when I was making a URL shortener. I’ve heard some nice stuff about this and look forward to using it for smaller applications.

But there is one bad news. Currently, it’s Go only.

Test Coverage

I don’t exactly remember by whom I was told to break larger functions into smaller ones. It was just too much of overkill to break them just for sake of readability. Now my mindset has changed a little bit. Now there’s one more reason to break them down, for test coverage. It is a lot easier to write tests for smaller units and increase the test coverage than to write tests for longer functions and sacrifice coverage.

Keyboard Layout

The keyboard layout you are using was designed around the time light bulb was invented by Thomas Edison. At that time there were no computers, and the layout was used in typewriters. Later on, when computers came out, the same layout was used for keyboards.

It is 2020 now, and we have already sent so many probes in deep space. See, how far we have got.

If you are a keyboard guy, I would highly recommend switching to one of the modern layouts. It’s a one-time investment. Do mercy to your fingers. Typing on QWERTY is redundant. What’s the profit of so much of technological advancements if your fingers are living in the 1870s?

I use Colemak, but there are other modern layouts out there. Each offers benefits over the other, but none of them are as easier as Colemak. It only swaps 17 from the QWERTY layout, means it is a lot easier to switch to Colemak than Dvorak (moves 33 keys) and Workman…

If you liked this post, please subscribe to the newsletter below for more updates like this.