Forem: Karan

Things to consider while asking for advice

Karan — Fri, 28 Sep 2018 02:48:32 +0000

This is a comment I posted earlier on this discussion. Wanted to share it with the wider community.

I frequently receive cold emails for some advice. I love helping people but its only possible to do so if -

The ask is highly specific - The help needs to be very specific request. Which means no "meeting for coffee", no "general discussion", no "pick your brains about an idea i have", nothing vague.
The ask has high context - The context has to be explained upfront and has to be specific too. The answer that is right for person X is not right for person Y. Hence the answer to most questions is always in the territory of "it depends on the situation". Describe your situation and the answer becomes useful for you.
The ask has high relevance - Do your research on the person before sending an email. Don't ask a software engineer about hardware problems. Don't ask a highly technical person management questions and vice versa. The question needs to be relevant to the experience of the person who is asked the question. If you can't figure out if its relevant - ask them that if the question is relevant to their experience.

Examples -

A good ask - “I know you have built analytics systems before. I am currently building one for my project which needs to ingest 10 GB / day and in 6 months scale to 1 TB / day. We are currently using Azure and are open to using tools from Java and Python. How do I design it so that it scales well?"
A bad ask - "I loved your post about X. Can we connect to discuss more of it?"
A good ask - "I am currently struggling with React JS and building apps in which use redux. Can you help me understand it? I will need 45 mins of active discussion to give you context."
A bad ask - "I need help on what to do with my career."
A good ask - "I am not sure what I want to do next. I am a fresh graduate with no professional experience and I am currently thinking AI/ML vs Blockchain. Money is tight and I really need to figure this out in a month or so."

How to take breaks while coding

Karan — Fri, 17 Aug 2018 18:29:17 +0000

I felt the need to write this post is to expand my reply on Brenda's post of "distractions while taking break". It is also a topic in the the book I am currently writing (more at the end of this post).

This is an interesting problem which almost all engineers struggle with regularly. How to take breaks and make them useful so that you are productive on a daily basis.

There are 2 most common questions that people ask -

Frequency of breaks - How many times should one take a break?
Length of the break - How long should they be?

My answers to both is "it depends". There is unfortunately no single effective schedule that someone can follow. The Pomodoro technique fails for most people in the long run because it has too much of a rigid structure. IMHO, it is not flexible enough for coding. But your mileage may vary.

Since coding is a creative endeavour, once you get "into the flow" its best to not take a break until you need to eat/pee/attending a meeting/do something urgent/or something else that forces an interruption. Forcibly breaking a state of flow causes irritation and grumpiness - try to not be in situations that encourage unintentional interruptions.

Being in the flow for long is unsustainable - the flow will end in a natural way at some point - and you should take a break at that point. And in this case, the break can be of any length - from 15 mins to a day or two.

One of the downsides of the flow is that one tends to ignore physical signs. Those are risky, being in touch with your body is crucial - especially while coding since most of the time you are inside your head. As soon as there is a physical feeling of sleepiness, discomfort, pain or exhaustion - you must take a break. No ifs, buts or maybes. Pushing yourself beyond what is physically tolerated by your body is a recipe for disaster in the long run.

What about day to day when you are not in flow all the time? It's the easiest to arrange breaks around your physical needs - when you feel hungry, need to refill your bottle of water, go to toilet etc. Its natural, doesn't feel like an unwanted interruption, and is an easy place to start your break.

But apart from the above two there is one more important question that most people don't think or talk about at all - What should you do while taking a break?

I have seen a lot of people browse their social apps on phone, watch videos, play video games, read books/blog posts on their laptops/phones etc. Its usually something which is on an electronic device. And even though its not work - its unconsciously equally draining.

One doesn't feel refreshed after staring at a screen for 15 mins. Your mind is still buzzing and there is no sense of peace, rest, unwind or calm - its still wound up and noisy. The break ends up not being a break, there is no experience of real downtime.

And this adds up over the days. It leads to a flash point where you just crash (usually on one of the weekend days), lie in bed for a day doing nothing to recover, and then the cycle starts again.

Electronic screens are also the main reason for sleep deprivation - we do not realize how much it affects our sleep - using flux/night shift helps alleviate a little - but it's never enough.

The one thing which I strongly urge practising software engineers to do is get away from their screens - for atleast couple of hours a day. Rest your eyes on something that is further than 10 meters for an extended period of time - you will realize how different it feels - just looking at something that is afar for an extended period of time. Who would have thought of that eh?

For your break, don't carry your phone or laptop and physically move to a different space like a balcony/play area/street/park etc. Let your eyes wander and see things. It doesn't matter what the thing is - could be trees, water, people or anything. And then let your mind wander along with your eye.

You will surprised at how effective this habit is.

PS - I am all about applying such mindfulness techniques as above to workplace in order to become a more productive engineer. I am writing a book (self.debug) about it and I think it will help you as you start your software engineering journey. You can download it here. It has a free option if you want to check it out - but its super encouraging as an author to see readers pay for it.

Photo by Luke Ow on Unsplash, Photo by Adrien Olichon on Unsplash

Being average in > 1 things is easier and more valuable than being excellent at 1 thing.

Karan — Sun, 12 Aug 2018 08:54:17 +0000

Note - This guideline is most useful for the bottom 99% of the practising software engineers. So if you are part of the remaining 1% - you can safely skip the this post.

There is a surprisingly easy hack that you can apply to increase your value generally in life. Pick up more skills. It sounds obvious when put on paper but there is one subtlety which makes it a “hack” in my opinion.

For this point we turn to the excellent Scott Adams’ book - “How to fail at almost everything and still win big”. Speaking about being successful, he says -

“… I tell them there’s a formula for it. You can manipulate your odds of success by how you choose to fill out the variables in the formula. The formula, roughly speaking, is that every skill you acquire doubles your odds of success.”

He goes on to mention that the level of proficiency for a skill is not mentioned because -

“… you can raise your market value by being merely good - not extraordinary - at more than one skill.”

“To put the success formula into its simplest form: Good + Good > Excellent”

This subtlety makes it very easy to execute. You don’t need to be extraordinary, you just have to be ordinary/average. Hence, if you are an average software engineer and you have any of the skills mentioned below -

Good at drawing
Public speaking
Managing people
Have a knack to pick up people’s emotions
An eye for design in product
Spot problems in operational processes
Shoot, edit and/or make videos
Make original music
Sing
Writing essays/blog posts
Or anything else

You are immediately more valuable to yourself and your organisation vs someone is who is a very good software engineer only. So if you are a software engineer who can think of product ideas and execute independently (remember you only have to be of an average skill in it) - you have more than doubled your value.

Leverage that skill.

This is a short excerpt from a book I am writing - self.debug. Its about using emotions and mindfulness to become a better software engineer. Please download it (has a free option!), and help make it better by providing feedback.

Photo by Alice Achterhof on Unsplash