Sunil Shenoy

I have been smiling ear to ear since yesterday evening. The reason? I can finally swim on my back. 🎉

I never took swimming lessons till two weeks ago. I have been swimming for as long as I can remember. From swimming for fun at the beach to swimming in the pool, until I can hold my breath, making sure that I am never in the deep end of the pool. Had to be in a place where I could stand in the pool. 🙈

I would watch videos on Youtube for hours on how to swim well. I would learn breathing techniques and go back to the pool to practise the next day. I slowly started to improve. A few weeks later I could be in the deep end of the pool and not worry as much.

My swimming technique was never as good, though. I would watch other people swim, and as I went from one end to the other, I would notice how I would struggle. Improving my swimming technique was on my list of things to do. This year I decided it was time.

The last two weeks, I have learnt so much. My swimming technique I have been told is improving, and I can finally swim on my back 🎉

I was a regular user of JOINs in SQL until I heard a podcast where the podcast people were discussing why SQL JOINs were not a good idea. I had never thought about this before. JOINs felt like the best way to combine data from multiple tables and get the result set desired.

JOINs is one of the foundations of RDBMS. If you use an RDBMS solution, you must be using JOINs. You store data using foreign keys in multiple tables and use JOINs to combine them to get the result desired.

Why were a lot of people writing about avoiding JOINS? I kept asking myself this question the first few weeks after I heard the suggestion.

After a year of launching the product, I realised why SQL joins should be avoided. Digging through the APM stats, almost all slow queries used had JOINs across two or more tables. Using JOINs over a large dataset turns out is expensive. Unless you are ready to throw a lot of hardware at the server hosting the database. As an upcoming startup, this was not an option.

I slowly started removing all JOINs from all the slow queries reported and porting them over to scripting solution used and used caching solutions to speed up transactions. Customers were happy, and so were the APM stats.

SQL joins on small datasets are great. One query to get data across multiple tables 👍️ . Just avoid using them over large datasets.

Most of us were forced to work from home last year. Very few had the opportunity to ease into this new way of working. If you worked from the office all your life, working from home can be daunting.

Before working in Mumbai at my previous work, I had always worked from the office. Working from home felt a bit different in the first few weeks. There was just so much freedom and time saved from the daily commute. I could watch Netflix, youtube and listen to music on my speakers without disturbing others around me and working the way which made me more productive. The first few weeks were not productive, though. Ok. It was months and not weeks. The new way of working took a while for me to settle into. After the second month, though, I knew I had to be strict about my working hours and playtime. There was work waiting to get done, and unless I spent dedicated hours on it, it would not get done.

I would imagine everyone went through a similar phase last year—a few months of unproductive time and then getting good with day and time management. Most of us now are used to the new way of working. Being able to work from anywhere.

I spoke to a few people I know, and they tell me they don’t like working from home, even though they are now used to it. When questioned about which part they dislike, almost everyone said the same thing. They miss being around people and don’t mind going back to the office once things went back to normal.

A right balance I feel would be the best way forward. A few days in a week, where you get to meet people, interact, share ideas and have meetings and the rest of the days when you put you head down and work on tasks that need to get done as a result of discussions that week. That’s what worked best for me the last ten years before I moved to Australia.

Software architecture decisions need to be reviewed from time to time. As your customer base increases and as the data you handle grows, it’s a good idea to look at how individual pages read data.

Does the reporting page still work as good when the data it is trying to read grows from 1000 rows from 100000 rows?

here are a few fixes that I have looked into before when pages fail to load due to an increase in data the page is trying to process:

• if you are reading from a Relational Database, have you added indexes to the columns used as part of the JOIN?
• is the database configuration optimised? A few times my.cnf file has improved the database performance for MySQL and ensured that it is using adequate memory available for its usage on the server.
• can you throw more hardware at the problem? Usually, a quick fix, while you continue to make improvements under the hood.
• can you avoid using multiple JOINS on the page? JOIN usually are the cause of slow queries bring the page to a halt.

Code refactoring should be a monthly exercise. Regular improvements to the code base are essential to ensure that your code stays clean as your system grows with new features and more data.

Besides building software and usability engineering aspects of computer science if I had to pick another segment I enjoyed spending time on, performance monitoring has to be it.

I am obsessed with monitoring transaction performance, and the impact transactions have on the database, CPU usage, and the various errors returned. Its all in the service of ensuring that the end-user has a great experience using the software you spend so much time building.

I would assume before that the user would let us know when the software was too slow or when it crashes. As I started to look through my habits, I realised that I hardly do this myself. If the software is too slow, I slowly stop using it. If it crashes, I will let the support team know, but unless the software is an integral part of my workflow, I will switch to an alternative.

I like being proactive about software performance and enjoy making small tweaks to improve performance and fix errors before they become a significant customer issue.

As of today signal has been down for more than a day.

New users signing up to use your service is always exciting. A product you have been building for a few years now gets in the spotlight. I am happy for signal and the movement they are working towards—privacy matters.

If I had to choose between a gradual increase in traffic and sudden user growth, I would always prefer the gradual increase. As a software developer and someone who has spent a lot of time learning about servers, load balancers, databases and provisioning servers, handling large user traffic require a lot of rework in building the software architecture. A team of engineers working to ensure that traffic and data are split/read from multiple channels is a project worth spending a few months/years on.

It’s disappointing for the users though, a service they were looking forward to using is suddenly unavailable vs a service they have been relying on which continues to be available. Do you switch back to the original service or continue to wait for the new service to be available? When it comes to the instant messaging platform, I would assume very few would choose to stay.

I hope that signal gets back online soon and is ready for the next wave of traffic, coming their way. It’s a good service from a nonprofit organisation. I like the UI and their focus on privacy. I, for one, will continue to move more conversations to signal slowly.

I have been quite regular with my gym visits for the last five months. I don’t remember the last time I so regular with my exercise routine. It’s a good feeling. I don’t plan on stopping; I don’t want to stop. I am going extra hard with my exercises this year.

I joined a second gym this week to spend more time on weight training after office hours. As much as I enjoy functional training, I have been missing spending more time weight training. I have also been wanting to get back to swimming. All this starts next week: functional training plus weight training plus swimming.

It is going to be tiring. I have never put my body through so much before. But I am looking forward to it.

I talked with a trainer at the second gym this week and asked me what I wanted to focus on. I had not thought about this question for a long time. “Improving my stamina”.

I am looking forward to my training schedule for the next few weeks/months.

There is so much to write and talk about when it comes to code quality. If there was one topic I could go on and on about it has to be this. Maybe that should be what I should write about whenever I am stuck for writing here.

I read this article yesterday. Facebook’s code quality problem.

The Facebook iOS app has over 18,000 Objective-C classes, and in a single week 429 people contributing to it. That’s 429 people working, in some way, on the Facebook iOS app. Rather than take the obvious lesson that there are too many people working on this application, the presentation goes on to blame everything from git to Xcode for those 18,000 classes.

Reading through the article reminded me of how important it is to have a good architecture in place for your software. As your application grows, the time spent on architecture discussion will pay off ten folds.

I first heard someone says “long time listener first time caller” some six years ago in a podcast I was listening to on 5by5 network. These words stuck with me. I can imagine being uncomfortable calling a radio show or podcast. You are talking to someone comfortable talking on podcast/radio, but you, the person on the other end, have not done this before. An agreement/saying that puts the person calling for the first time at ease. I wish more industries/avenues had this kind of agreement/saying.

Perhaps it is a way for the caller to have it both ways: “long time listener” establishes credentials in terms of knowledge…. but if they blow it, their excuse is that they are a “first-time caller”. In talk radio land, I guess that first-time caller label is supposed to evoke sympathy from the host.

source

Not knowing something before walking into a meeting would scare me. I remember being terrified of such days where I would have to give a speech—not knowing everything about what I was going to talk. Scary.

Yet here I was today, discussing being part of a meeting tomorrow and not knowing what I would say in the forum did not put my mind racing through a hundred different thoughts. I am now somehow comfortable with being new at something. I am comfortable knowing that it takes time to get better at something. Being better at something requires dedicated time and effort. Somehow learning this has made a world of difference to most things I approach these days.

I want to get better at a few things this year, and I am comfortable knowing that it will take time to get there.

I spent two hours yesterday playing this game Cashflow Classic with a few friends.

Rich Dad Poor Dad is a 1997 book written by Robert Kiyosaki and Sharon Lechter. It advocates the importance of financial literacy, financial independence and building wealth by investing in assets, real estate investing, starting and owning businesses, and increasing one’s financial intelligence.

I remember reading this book more than ten years ago after a cousin suggested I give it a read. I don’t know much from the book now, but playing this game yesterday got me to look into the last part of the paragraph above. “Increasing one’s financial intelligence”. That’s one area I wish a lot more people got better at, including myself.

Instead of having meetings, people “talk” to each other via GitHub, Notion, and (occasionally) Slack, expecting responses within 24 hours. Because there are no standups or “syncs” and some projects can involve expensive feedback loops to collaborate, working this way requires clear and thoughtful communication.

Everyone writes well and writes a lot.

There are no deadlines either. We ship incrementally, and launch things whenever the stuff in development is better than what’s currently in production.

No Meetings, No Deadlines, No Full-Time Employees

Reading through this article, reminded me of my time working with my previous company. We almost had the same way of working. We did not write a lot, though. I wish we had. I have always wanted to document the thought process behind each page, element, feature—something for me to improve on going forward.

I have never been in front of a professional video camera setup before. I have been part of various zoom and WhatsApp calls, but none was going to be recorded and used for social media campaigns.

Two days ago, I was asked to give a video testimonial for the gym I have been exercising in the last four months. I am having a great time at the gym and the community there has been amiable.

Part of my video testimonial mentions how I now look forward to going back to exercise versus previously being a struggle to walk myself to the gym. F45 does make training fun. I also realised I enjoy group classes more than exercising by myself or with a friend at the gym.

I can talk quite fluently during 1-1 conversation, but somehow yesterday, I kept fumbling when in front of the camera. My thought process kept breaking. It’s been a long time since that has happened to me. Matt, who recorded after me was excellent. He was able to articulate his answers well and kept it clear and concise.

Took me back to last year, when I was trying out podcasting. I would spend a lot of time editing the audio file—something for me to improve on in 2021.

I have been programming using PHP for more than a decade now. It was the first programming language I learnt, and I have continued to build most of the software in the last few years using PHP. I have tried various PHP frameworks. Laravel, CodeIgniter, CakePHP, Symfony, Yii and Slim. Laravel and CodeIgniter being my choice of framework most of the times.

I was looking to start two new side projects in 2021. Having worked with PHP for a long time now, I decided it was time to learn something new. It’s always good to see what other languages had to offer, and since these were side projects, I did not have to weigh a lot on pros/cons. Rails has always fascinated me as a language. I last worked on Rails 8 years ago, and I enjoyed my experience.

It definitely did not feel like riding a bicycle. I had to start at level 0.

TryRuby: Learn programming with Ruby was my first stop. Armed with a lot of built in functions knowledge and syntax for how to loop through data, I was ready to now install rails and get started.

Ruby on Rails Guides has been my goto to learn rails. Very well written and easy to understand.

I am hoping to talk more about the project by the end of Feb. 🤞🏻

You ask, “Are you bored?” Even if you don’t have a gut feeling, it’s a good question to randomly ask your team. When I ask, I look you straight in the eyes and if you can’t stare me in the face and answer, I’m going to keep digging until you look me in the eye.

Bored People Quit.

Worth a read for sure. Sometimes its just as simple as asking the question directly and carefully listening to the person on the other end.

I should make good on the part of my things to be better at this year “Write/share more often here.”

I was reading https://patwalls.com yesterday and the daily writing habits struct a chord with me. I have always admired Seth Godin for his daily blog posts for over six years now.

“Maybe I won’t have something to say every day”. I am stuck with this thought each time I decide to write more often. I started a podcast last year during the lockdown, and the first few weeks were easy to record. After the first few weeks, I was not sure what topic to record on. The lockdown was not too kind either. I lost all motivation to record. The mic went back into the boxes and are yet to see the light of day.

But I should get myself to record and write more often. Maybe this time it will be different. 🤞🏻

I have not missed an Apple Event about hardware releases for the last five years. I know I will not purchase the hardware released for most years, but it’s been an event a few friends watch together(now remotely), and the whole affair is a treat to watch.

Drastic improvements are difficult. The road leading up to Apple’s M1 processor, from what I been reading took ten years. From Apple’s A4 Chip in 2010 to A14 in 2020. Apple has been slowly improving on its chip design and the workload it can handle.

After watching Apple’s event on November 10’s 2020, I could not wait to start reading the reviews. The next few days and weeks, I continued to read and watch popular youtube reviewers and bloggers talk about the M1. Everyone had good to great things to say about the M1. ARM-based computers were much better than x86. I had to try it out for myself.

I had been saving money for my trip to Melbourne during the Christmas + New Year’s break, but due to the Covid outbreak in NSW, borders to other states were closed. The money got re-routed to purchasing the new M1 Mac Mini. My first desktop purchase after 14 years.

I opted for the 8 GB / 512 GB Mac Mini. I read a few opinion pieces about 8 GB vs 16 GB and was convinced about getting the 16 GB until I read this review.

Apple’s 8GB M1 Silicon isn’t Magic, but it is Magical

That’s the problem with future-proofing, Apple keeps reinventing the future.

I have been using the Mac Mini for three weeks now, and it been a joy to use. All the reviews are accurate. It is significantly faster than my 2017 Macbook Pro / 8 GB / 256 GB config. Now my primary work machine. MacBook Pro now becomes my goto travel buddy accompanying me on all my road trips/vacations.

If you are on the sidelines about buying the Apple M1, my recommendation would be. Go for it.