Sunil Shenoy

Even if you don’t check all the boxes in the role requirement. Not many who apply for the role check all the boxes.

When I learn of any software company, I am always curious to understand what their software stack looks like. The best place to know what the stack looks like is the Careers page. Based on the kind of skills the company is looking to hire, you can learn a lot about their software stack.

I am always curious if people applying for the open roles tick all the boxes listed as a requirement for the job.

After having worked in the industry for more than ten years, the one thing I am sure of is to tick those role requirements; you will have to be either working in the company itself or a company which created software using the same stack as “this” company.

Should you not then apply for these roles? You should. If you tick a few boxes in the stack, I highly encourage you to apply for that next job role. As long as you know the base requirement of the role, you can learn the rest while in the position.

Remote friendly is almost a requirement if you are looking to hire these days. I am all for remote first / remote-friendly companies. If your work involves spending a lot of time with computers, travelling to get to an “office” is not a requirement company should force on their employees.

Each company is different, though, in how they operate. Every person similarly is other in what they accept out of their role. Some are happy to come to the office and spend those 5-6 hours of dedicated time at a desk, while others prefer being at home, having their setup and not have to worry about changing different modes of transport to start work.

I have been thinking about how this affects a companies culture, though. For example, do remote companies find it challenging to set a culture vs companies where employees meet often and sometimes even go out for drinks after office works on Friday? I would love to read more about this.

I was reading this article today and could not agree more.

But with that said, something has been missing.

What most people don’t realize is that remote-first is held together by infrequent but hugely powerful in-person meetings. To be more direct: I don’t think remote-first works without in-person retreats and gatherings. Retreats are the glue that bonds us together as a team.

Remote teams will always need in-person interaction to succeed

Remote teams will always indeed need in-person interaction to succeed. If you want to go all remote with your business, I hope you have plans for frequent in-person interactions.

If your work involves running or being part of a software business, keeping it secure is almost a full-time job. However, if you don’t have someone handling this role, it is good to have proper checks to ensure that attackers go through as many gates as possible.

A few things you will need:

• Ensure that you have a WAF in place. For example, if you are using Amazon, enable Amazon WAF. If you use Cloudflare for your DNS, Cloudflare also offers WAF as a service.
• Update your web server, Nginx or apache with all the security settings supported.
• Ensure that your servers IPTables only allow for traffic on desired ports and blocks all other traffic.
• Fail2ban. Install this and have it running all the time.
• Ensure that SSH only accepts traffic from IP’s that you trust.
• Get a dedicated IP address for the above and accept traffic to SSH only from this IP.
• Ensure that your servers operating system and the packages are as up to date as possible.

These should be a good starting point. You can do other things to keep your software secure, which should be at the application level. For example, ensure that you sanitise the user’s output data.

wake up in the morning, walk to the beach and swim in the ocean.

hear sound of waves crashing from home not just the few hours that you at the beach.

watch sunrise from the beach a few days in a week.

watch sunset from the beach a few days in a week.

learn how to surf.

get better a playing volleyball.

sunbathe, take a nap on the beach and walk back home.

… a few things I am looking forward to as I plan to move closer to the beach in NSW.

is difficult.

is good.

is constant.

is sometimes needed.

can sometimes be not what you want at this moment.

is sudden sometimes.

begins at the end of your comfort zone.

makes you rethink things.

is sometimes not in your control and not what I wanted this week.

I used to document things a lot better before. I loved spending time writing down what went behind creating something. The though process. The decisions. However, something changed in the last two years. With things being more real-time at work now, documentation took a backseat.

Last week, as I wanted to remember why I did certain things or what all went behind having the feature built the way it has been, I could not find any information at one place. I did, though, come across a lot of chat threads. But, unfortunately, a lot of separate chat threads where the conversation jumped from one topic to the other and I had to spend time grouping information about the topic.

As I spend the long weekend at home thinking of things I want to get better at, I want to start creating more “wiki” pages about things I work on.

I read this post yesterday, Are software engineering “best practices” just developer preferences? and immediately shared it with my work colleagues and made a note for myself to write about it.

Software Engineering is really frustrating because there’s basically never a “right” answer and so most decisions come down to “whatever the senior engineer wants.” This is probably why people feel imposter syndrome so much in coding: You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.”

I have often struggled with the best way of organising the code I write. Almost everyone who creates web applications agreed on the MVC way of managing their code, but anything after that was always “it depends”.

Every project I have worked on in the last fifteen years has been different—different ways of organising code. Although I disagreed with some of the ways the code was written before me, I continued to work with it and make incremental changes so that it was easier to find methods/interfaces when it was my time to debug.

Who’s right here? Who knows! The app works either way, and it’s still maintainable just a little more annoying (imo).

When I joined the current company, I was introduced to Design Patterns again. I had not looked at Software Design Patterns in the last ten plus years. I had worked on smaller projects before. Not a lot of code, so simple MVC with few standard interfaces worked well.

There was a lot to learn as I read parts of the book. I did not have to pay attention to all the patterns. Colleagues in this company followed two design patterns. So I had to learn and get better at organising/writing code this way.

The job after this will be different. The code organised there would be based on the first few developers who worked on the software. Developers who made the decision that “this” was the best way of organising code.

Are software engineering “best practices” just developer preferences?

I had this discussion with a friend a few months ago. On a sunny weekend, when life was not restricted to the 5 KM radius as it has been since the last few months.

The discussion was about how we are way too small to matter from a larger perspective, the universe’s perspective—a tiny dot in the larger scheme of things. Yet, we think and worry too much about the smallest of things that bother us at an individual level. As I thought about this today, I was reminded of this post by Alex.

And yet some things seem so meaningful. A golden sunset, a lover’s embrace, an old friend’s laughter. That is the paradox of life, at a macro level entirely meaningless and on an individual level, steeped with meaning.

nothing matters

I bought a road bike a month ago. Before buying the road bike, I told myself I would take it out once or a week to keep myself physically active.

I had been watching a lot of people cycle in the suburb I live. So, I told myself, I wanted to get cycling gear like them before taking the bicycle out. A week later, I was still looking for the right cycling gear.

I needed to get started. It had been a week. Thanks to the magic of internet advertisement, I now had more than 20 brands following me around advertising their product. I randomly chose one, clicked “Pay Now" and waited for the gear to be delivered.

“After I get the jersey,” I told myself. Two weeks in, I was still waiting to take the bike out for a ride.

After the jersey was delivered, I got started and have not looked back since. I have been riding three to four times a week. I got myself an account on strava to track my ride. After that, I slowly bought more gear to help me cycle better.

This experience got me thinking. What is that one thing which is stopping you from getting started? Is it the shoes to help you start exercising regularly? Is it the meal plan to help you eat better? Or is that “thing” the reason to not get started at all. I hope it is not.

I wrote a few paragraphs “about me” last week. After I finished writing what I thought was the best edit I could make to the written content, I sent it to a few friends.

Few friends had some suggestions for changes I should make. I agreed to the changes that were suggested and hit the publish button again. Everyone was happy with the changes until Mayur had a look at the content. Mayur writes advertisement campaigns as part of his job and is good at writing.

Mayur broke every sentence down. He told me why he disagreed with the words I had chosen and with my sentence formation. It was great feedback. I thought I was good at writing, but his feedback made me realise I still had a long, long way to go. As much as I was cringing as he took me on the journey of “you need to re-write everything, " I agreed with all his feedback after the call as I reread the paragraphs.

I rewrote everything I had written before. I took a screenshot of the content before and after. The content written before did not read as well as the content later. I was happy to receive honest feedback.

I have been thinking about this a whole lot since yesterday. Mayur was happy to share the brutal feedback with me cause of the relationship and equation we share. I was pleased that he did not hold back.

When asked for feedback, I have held back at giving honest feedback to people I have a good equation with. I chose to be nice and always said good things. This experience made me realise I should not. Maybe the feedback helps them improve. I do want the best for them, and that’s where the feedback is coming from.

As I decided to write about this topic, my mind told me that I had written about this before. As I searched through the archive, it looked like I did not.

Defaults matter.

No matter what we’re building — whether it’s a habit, a tool, a company, or a culture — we need to pay very close attention to what the defaults are. If someone follows our process and accepts all the defaults, what kind of outcome does that create for them and the people around them?

The defaults matter

In the article linked above, Jason thought about defaults in terms of habits, company, and culture. I have always thought about it in terms of tools.

There are so many tools I have stopped using cause I did not quite like the defaults the software shipped with. Did the software not have an option to change the font, spacing or colours? They did. It’s just that after changing these, I did not quite like how the software felt. I was not too fond of the defaults the software shipped with either.

The tools that I have stuck with are those for which I liked the defaults. As I write this post on Craft, I have hardly made any changes to the software since I installed it. The same was not true for every other writing software I tried before.

I have wanted to write long-form content here. So this last week I was looking for topics, I could write about. I have been relatively consistent with writing short posts in the past few months and am pretty happy that I rarely missed posting here. I love writing, and starting this blog has been one of the best decisions I have made.

Writing short content now does not take as much time as it used to before. I now know how long it would take to format the content, think about the topic, edit the post, and check for grammatical errors. A know territory. Is it time to switch to the unknown? I want to.

I came across this blog post this week. Write 5x more but write 5x less

There are 2 things I have come to believe about writing:

1. The average person should write 5x more things than they do.
2. The average written thing should be 5x shorter than it is.

And I agree. We should all be writing more. I should be writing more about the decisions I make at work. I should be writing more in private about lessons learnt. I should be writing more about new things I learn.

I should be writing more but less about work. I should be writing more long-form content here. That’s one thing I will not complain about—more writing.

A friend recently finished working for more than fifteen years at the company he works. He is still there. He enjoys his work and does great work at what he does.

My dad always worked for one company in his life. Larsen & Toubro. I remember he was recognised by the company in front of an audience when he finished 25 years. He always spoke with pride about the company and was proud of the work his company did.

I wish more people are like my friend and my dad. Likewise, I want more companies are like my dad and my friend’s companies—companies that value their employees and provide them with a win-win situation.

Many people tumble through different companies before they find the company they want to spend the rest of their lives. For my friend and dad, it happened to be the first company they worked for.

I hope as a company you are working towards having more people who want to work with you for a long time. When you are looking for a job, you are looking for a company where you want to spend a lot of time contributing—a marathon, not a sprint. I am sad that this is rare these days, and most jobs/companies are focused on the sprint and not the marathon when thinking about the employer/employee relationship.

What did I do yesterday? Yesterday felt like a blur. When I started to think about everything I have done in the last ten weeks, I don’t remember most of it. I should start to journal my days.

New South Wales in Australia has been under lockdown for ten weeks now. I remember having grand plans when the lockdown started. I wanted to build an app. I wanted to create an API, and I wanted to launch a small app by the time we got out of lockdown in two weeks, then. In the tenth week and with three more weeks to go, I still have not made much progress. I got distracted. Other things took priority, and working on the app was no longer on top of the list.

We all have twenty-four hours. Sleep, food, work takes out sixteen to seventeen hours on most days. There is exercise and then catching up with friends and family. To get to something outside of these top 5 activities means that I need to be extra cautious of my time scheduled for other activities. Maybe I don’t want it as badly. If I did, it would be part of the top 5 activities. We all have that twenty-four hours in a day. What activities are you giving priority to?

I remember recording my first podcast episode last year. I re-recorded at least ten times. I knew you could edit podcasts, but I did not know how to. I wanted to get it right and get it right without having to edit.

After the second episode, though, I knew the number of retakes was just not going to cut it anymore. I had to learn how to edit. I spent one weekend going through a few tutorials on editing podcasts, and I was ready to record again. This time, I could make mistakes while recording. I could blabber, I could tell myself that I needed to edit this part out. I was talking to my future self, and my future self would thank me for learning how to edit.

Sanat and I recorded again yesterday. Sanat has gotten good at editing podcasts now. Power of iPad and Ferrite descript from what I am told. We made many mistakes. Lots of ums and ahs and … “I got nothing”… “I lost my chain of thought here”.

This morning, it got me thinking how difficult it is to record live or present in front of a live audience. When you don’t get a chance to leave notes for your future self. Where losing chain of thought is not an option. But, for those who present to a live audience and do it well, I have a newfound appreciation for that skill.

You don’t have to take action on every idea. You can make a decision without knowing every last detail and option. It’s okay if you don’t finish every book you start. You don’t have to respond to every email you receive. There’s no need to push every project to the max. Having breathing room — a little bit left over — is perfectly acceptable. In fact… I would argue that it’s preferred.

Shawn Blanc - 2x2: Do Less

A much-needed reminder for today. Rather than planning something for every day, have off days. We all need to have some off days. Not think about work. Not think about exercise. Days when we Move away from Focus mode and switch to “Do Not Disturb While Driving” mode.

Until a certain number of items, lists are helpful. Are you launching something new or moving something from one place to another? Create a list. It helps you ensure that you don’t miss things critical on that day. On the D day, when there are many thoughts in your mind, lists can be the calm you need.

To capture data to day activities, lists are not always helpful unless you have a system for when things go out. Unless you do, I would not recommend using a list-based system to track your to-do list.

If the rate at which new items are added to the list does not match the rate at which things are ticked off, lists can be a daunting place to return. That is why most to-do lists app fail for me. That is why most bug tracking apps have failed for me.

a friend asked me this yesterday. “why are you learning a new programming language?” I had to stop and think about this for a while.

I have been working with the LAMP stack from the time I started building software. I have tried different languages in between. Ruby(on Rails), Python, Node.js and a few other flavours of JS frameworks are other languages I tried in between based on project requirements. I never got a chance to spend a lot of time with these other languages, though.

There are quite a lot of programming languages available to learn out there. Should I deep dive into Python or Ruby that I have spent time with before? or learn something new? These questions have been a question on my mind for a few weeks now. I never really liked the other languages that much, though. I enjoyed working with C and C++, and PHP was a natural extension to these languages.

Go from what I read online, “is modern C language”.

Why learn something new, though? To break away from the routine. To decide if the next language is something I also want to spend more time with. After spending more than nine years with PHP, I now feel ready to pick up a few other languages that I want to learn. Keep the brain active.

I look forward to the next challenge. PHP will always be a language that I spend a lot of time with(for now), but from now on, I want to challenge myself to learn a new language every year. This year is the year of Go.

If your profession or passion involves writing code, this thought has entered your mind sometimes or the other as you shared the code you wrote with your colleagues or pushed the code onto Github as a public repository.

I have never participated in a pair programming exercise so far. From what I heard from a few people who have participated in pair programming exercises, the experience has not been good. After the activity, they felt that even though they got the solution right, the person on the other side judged them for how they went about writing the code. The code compiled well and worked but was not written the way the other person had expected it to be written.

“You did not use the right design pattern”, “did not abstract the code well enough”, “did not use an inbuilt function and went about duplicating an inbuilt method”.

Reviewing code well is challenging. Writing code well is challenging. But, we are all getting better at the craft the more time we spend at this.

“Code is Poetry” — WordPress coined this phrase and has it on its website. Code is indeed poetry. Some people are spending a lot of time getting better at writing poetry. Some write poetry to make a living and not because they feel as passionate about it.