DEV Community: Shivam Shekhar

Breadth vs Depth in Engineering

Shivam Shekhar — Mon, 10 Oct 2022 15:23:20 +0000

All of us probably remember graph data structures, and the traversal methods (BFS and DFS). As an engineer, we can visualise the expertise and learnings in tech industry as a graph. Going forward with this assumption, should one approach this knowledge graph in a breadth-first or depth-first fashion?

Breadth is how many things you know about, whereas depth is how much you know about that thing. Depth helps you move fast in one direction, and breadth helps you determine the right direction to move in. Breadth gives you diverse perspectives, and thus wisdom. And, on a long time scale, wisdom is almost always more valuable than knowledge.

Our tech industry is weird this way that a person with very deep expertise in one specific thing is praised as an expert whereas a person with broad set of skills is called out as a jack of all trades but master of none. As an industry, we overvalue knowledge much more than wisdom. This might be because testing knowledge is relatively easier compared to wisdom.

Moving fast is as important as moving in the right direction. Early on in career, you should be optimising heavily on breadth. Why? I feel it’s more important to understand the questions and conversations around you. You can always go deeper to find the answers once you understand the questions. Going broad helps us identify these questions and core concepts in the deluge of languages, frameworks, and whatnot.

Focus on concepts. There are very few concepts. Different frameworks just make different choices at these conceptual levels on approaching different problems. Understanding things at a conceptual level will help you quickly pick up other adjacent frameworks and technologies when needed.

Without sufficient depth, you'll keep hitting walls where you get stuck. This is really critical and an indicator to go deeper. This is when focus needs to temporarily shift to being depth-heavy. Deeply familiarising yourself with the framework/tech being used gives you a stronger basis which is very useful to find patterns when we go outside of that framework.

With time, as you progress in our career you will hit many walls, go deeper into those blockers, and repeat. In the process, you've learnt 'n' number of things at a beginner or intermediate-level and also are at advanced-level in a few of these things. You evolve from just being a jack of all trades to also being expert in a few things.

Essentially, you've transitioned from a short, fat engineer to a T-shaped engineer who are much sought after. There is a good amount of breadth that you need to find the right direction to move into, and the sufficient amount of depth to move fast into the direction that you have chosen. Hope this is teeny bit helpful at least.

Inspirations

Why we moved from 32-bit to 64-bit processors?

Shivam Shekhar — Sun, 24 Apr 2022 07:20:24 +0000

When I had just entered college, I got my first laptop almost 7-8 years back. Surprisingly, it said 64-bit instead of 32-bit, which I had seen till then on the computers everywhere. Why did it say 64-bit? Almost all the computers gradually moved from 32-bit to 64-bit processors in the late 2000s and early 2010s. What exactly did change with this?

Let's start with how processors exactly work. Processors are a collection of billions of transistors placed on a silicon wafer. These transistors combine to build logic gates and even sophisticated computational logic. There are two main parts to CPU- control unit (CU); and arithmetic and logical unit (ALU). CU is like an orchestrator at the opera (orchestrating the execution of programs), and ALU is like vocalists and instrumentalists at the opera (carries out arithmetic and logical computations). To carry out any computation, the processor needs some data.

We already know there are two kinds of memories in our computers- primary memory (also called RAM or just 'memory') and secondary memory (also called storage). RAM holds data and programs that processors require for executing active programs, whereas the storage persists everything else that is not being actively used. Now, RAM has the entire Microsoft Excel program and required data, but all of it is not being processed simultaneously; the instructions currently being processed are stored in registers, a tiny memory unit embedded within the processor. Technically, registers are the smallest data holding elements.

When a computer or processor is marked as 32-bit or 64-bit, it is being talked about the size of registers in the processor. There are several kinds of registers; not going deeper into these, but some hold the address of data in memory, some hold instructions, and so on. In RAM, memory is typically marked by addresses from 0 - X (a 4GB ram has 2^32 bytes and requires 32 bits to store the address on a location, whereas an 8GB ram has 2^33 bytes so on).

A 32-bit register won't ever be able to access any location in RAM beyond 4GB because it cannot store its address. This is a constraint if we want to use 8 or 16GB RAM. This is primarily why manufacturers decided to move to a 64-bit register that adds support for the address of 64-bit, i.e., allows 2^64 bytes in RAM (~16-17 exabytes; FYI, 1 exabyte is roughly 1 billion GBs). Today, with a 64-bit register, we are using at max 42-48 bits of these 64 in computers.

Along with allowing more memory, this also allowed us to have 64-bit instructions. Since instructions are a part of the operating system, they also need to support 64-bit instructions, so almost all operating systems were rebuilt for a new generation of processors. You can run both 32-bit and 64-bit OS on a 64-bit processor but only run 32-bit OS on a 32-bit processor.

That's all for today. I hope this was a tiny bit helpful.

Why do array indexes mostly start at 0?

Shivam Shekhar — Tue, 19 Apr 2022 19:29:55 +0000

Have you ever wondered why array indexes start at 0 in most languages? I did. The road to satisfy this curiosity led to a few revelations and fundamentals that we tend to forget a lot of times. Let's start by defining an array.

Array is typically a contiguous area within the computer memory. In most languages, the variable that we use to refer to this array is inherently a pointer. A pointer that stores the starting address of the contiguous portion of memory.

Let's take an example, say there's an integer array arr of 5 numbers in a language where every integer occupies 2 bytes of memory. Say, this array's contiguous area starts at byte address 44 and continues until 54 (requiring 10 bytes, i.e. 5 integers of 2 bytes each).

Within this, when referring to arr[i] we are essentially looking up the memory location in a shorthand way.

arr[i] points to a location = Start Address + Data size * Index
arr[0] points to a location = 44 + 2*0 = 44
arr[1] points to a location = 44 + 2*1 = 46
arr[2] points to a location = 44 + 2*2 = 48
arr[3] points to a location = 44 + 2*3 = 50
arr[4] points to a location = 44 + 2*4 = 52

What difference would it have made had it started at 1 instead of 0?

arr[i] points to a location = Start Address + Data size * (Index - 1)
arr[1] points to a location = 44 + 2*(1-1) = 44
arr[2] points to a location = 44 + 2*(2-1) = 46
arr[3] points to a location = 44 + 2*(3-1) = 48
arr[4] points to a location = 44 + 2*(4-1) = 50
arr[5] points to a location = 44 + 2*(5-1) = 52

We would need to subtract 1 from every index we are accessing if we start indexing at 1. Looking keenly, we are offsetting from starting index to get every element. Using 0 as the index then means using an exact offset from starting point as the index whereas when using 1, we would have to compute the offset itself.

Why use 0 then? Using 0 allows us one less computation for accessing elements. Does this matter that much? Not today, but probably it mattered in the early days of computing to have algorithms in the most efficient way. Maybe, it was an efficiency hack for ancient computers.

Not just this, it also makes mathematical sense to use 0-based indexing. I would not dive much deeper here, but leave it to Dijkstra to take home this point using conventions of representing a sequence of natural numbers.

The simple choice of 0-based indexing simplifies a lot of mathematics on arrays for programmers and allows for some elegant implementations of some concepts like hash tables, consistent hashing, and binary heaps.

Nevertheless, more than a decision of computational efficiency or mathematical accuracy, it is a matter of linguistic choice. With some tweaks in the implementation of the array, you can make any arbitrary indexing work.

Should I be a designer or a developer or .... ?

Shivam Shekhar — Tue, 28 Dec 2021 13:51:03 +0000

Whether to be a designer or a frontend developer or a cybersecurity expert or a blockchain developer or something else? There are so many domains within tech and this is such a difficult choice. Just like a grand buffet. I have gone through this dilemma myself and discovered a few things the hard way.

First and foremost, it's your choice to make. Stop asking people what would be the most optimal choice as per the market. Now, you'll say- but how do I choose the best option? There is no single method to figure this out. You need to fit your persona in what you want to do.

What follows is a way that worked for me, may not work for everyone. This is not a sureshot way, but it helped me and a lot of people I know in figuring out what they wanna do. There will always be a road that we took and another road not taken.

Evaluate yourself. Start with a few why questions and then move to a bunch of what questions. These questions would help you narrow down this infinite list to a few probables.
For example- Why do you want to be in tech? What are your strongest traits? What are the weakest ones? What is important to you? That's not all, you can think of even more questions to ask to yourself. (SWOT is a good framework for this, but focus on SW, and not that much on OT for now.)

Try broadly understanding all the domains that you can think of at first. You'll find a few of them interesting and others not. Then, dive a bit deeper into the things that you thought are interesting, try understanding what kinds of problems people are solving with it or any adjacent areas or sub-domains.
For example- If you're interested in machine learning, you can look at problems like risk assessment, fraud detection, recommendation engines etc or sub-domains like computer vision or predictive modeling. (This is where O of the SWOT framework kick in)

Combine your self-evaluation and domain understanding to further narrow down this list basis whatever parameters you want. Find out what works for you, and what doesn't. You can use anything- how good it makes you feel, how well does it pay, does it fit in with my strengths, does it give me learning opportunities and whatnot (You can now complete the SWOT analysis you made for yourself).

Start the journey. Understand what is expected from a typical entry-level job in your chosen domain. You can use the Internet to understand this or you can talk to people (but don't ask for a roadmap) or even better, you can do both. Prepare yourself. Learning by doing is what I'd recommend.
For example- Continuing with the above ML example, find datasets and slice and dice through them. Go to websites hosting ML problem statements.

Don't wait to be perfect. Start looking for internships or jobs as soon as you feel you know a few things that you can work with. Keep learning on the job. You won't be perfect at day 1 or at day 365. It's a long-term game.

Grit is the only thing you need to keep doing better. You'll be a bit better every passing day and over a sufficiently long time, the incremental gains would accumulate to a lot. Just remember this- even a 1% improvement every day translates to an exponential change.