DEV Community: Rohan Taneja

CS—Explained in a blog

Rohan Taneja — Sat, 15 Feb 2025 12:27:38 +0000

Just as I promised in the title, this is a single blog that I planned to write and explain everything that I've learned about CS until now. Without much jargon, let's dive right into it.

CPU—The brain box

Every computer starts with a CPU—a tiny piece of silicon filled with billions of transistors. These transistors act like switches, flipping between on (1) and off (0). When you combine these switches, you create binary code—the fundamental language of computers.

Imagine a transistor as a simple LED:

if (voltage > threshold) {
    LED = ON;  // 1
} else {
    LED = OFF; // 0
}

This is the simplest form of binary logic. Multiply that by billions, and you have a CPU crunching numbers at gigahertz speeds.

Bits, Bytes, and Binary

A bit is the smallest unit of data—a 0 or a 1. When you group eight bits together, you get a byte. For example, the binary number 01000001 equals 65 in decimal, which is the ASCII code for the uppercase letter 'A'.
Here’s a quick Python snippet:

# Convert binary to integer
binary_value = '01000001'
integer_value = int(binary_value, 2)
print(integer_value)  # Output: 65

# Convert integer to character
char_value = chr(integer_value)
print(char_value)  # Output: A

For easier reading, we often use hexadecimal. Four binary bits map directly to one hex digit. For example, the byte above is 0x41 in hexadecimal.

Logic Gates

Logic gates form the foundation of computation. Consider the AND gate, which only outputs true if both inputs are true:

// Pseudo-code for an AND gate
bool andGate(bool a, bool b) {
    return a && b;
}

For instance, if both a and b are 1:

andGate(1, 1)  // returns 1 (true)

This basic logic is expanded across millions of gates in a CPU, enabling everything from arithmetic to complex decision-making.

OS and Character Encoding

When you press a key, the operating system translates that physical action into digital information. For example, the ASCII code for 'A' is 65, stored as 01000001 in binary.
Here’s a simple C example:

#include <stdio.h>

int main() {
    char c = 'A';
    printf("ASCII value of %c is %d\n", c, c);
    return 0;
}

The OS (be it Windows, Linux, or macOS) manages these translations, handling everything from input devices to file systems.

RAM and Machine Cycles

The CPU is powerful, but it needs fast, temporary storage—this is where RAM comes in. Think of RAM as a whiteboard where the CPU writes data temporarily.
A simple machine cycle involves:

Fetch: Retrieve the next instruction from memory.
Decode: Translate the instruction into signals.
Execute: Perform the operation.
Store: Write the result back to memory. Here’s a pseudo-code example of a loop simulating a simple cycle:

while (instruction != STOP) {
    instruction = fetch(memory, programCounter);
    decoded = decode(instruction);
    result = execute(decoded);
    store(memory, programCounter, result);
    programCounter++;
}

Modern CPUs run billions of these cycles per second, and multiple cores mean several processes run concurrently.

Translating Human Ideas to Machine Actions

We never write binary by hand. Programming languages like Python, C, and Go let us express ideas in human-readable form. For example, a simple loop in Python:

for i in range(5):
    print(f"Loop iteration {i}")

The interpreter or compiler then translates this into machine code the CPU can execute. This abstraction lets us focus on solving problems rather than managing every transistor.

Data Structures

Data structures are essential for managing and retrieving data. Let’s look at a few examples:

Arrays:
Contiguous blocks of memory. In C:

int arr[5] = {1, 2, 3, 4, 5};
printf("%d", arr[2]);  // Output: 3

Linked Lists:
Nodes connected by pointers:

struct Node {
    int data;
    struct Node* next;
};

Hash Maps:
Key-value pairs for fast lookup. In Python:

phone_book = {"Alice": "555-1234", "Bob": "555-5678"}
print(phone_book["Alice"])  # Output: 555-1234

These structures help optimize data access, making programs more efficient.

Step-by-Step Problem Solving with Algorithms

Algorithms are a recipe for solving problems. Consider binary search on a sorted array:

def binary_search(arr, target):
    low = 0
    high = len(arr) - 1
    while low <= high:
        mid = (low + high) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            low = mid + 1
        else:
            high = mid - 1
    return -1

This algorithm runs in O(log n) time, making it much faster than a linear search for large datasets. I keep a keen eye on Big O notation to evaluate performance, whether I'm dealing with recursion or iterative solutions.

Object-Oriented Programming

OOP helps in structuring code with classes and objects. Here’s a simple example in Python:

class Dog:
    def __init__(self, name):
        self.name = name

    def bark(self):
        print(f"{self.name} says woof!")

dog1 = Dog("Rex")
dog1.bark()  # Output: Rex says woof!

This method of organizing code lets me reuse and extend functionality easily, using concepts like inheritance and polymorphism.

Machine Learning

Sometimes, we need computers to learn from data instead of following strict instructions. Machine learning involves training models on large datasets. For instance, a simple neural network might adjust weights based on input data to classify images:

# Pseudo-code for a single training iteration in a neural network
predicted = model.forward(input_data)
loss = compute_loss(predicted, target)
model.backward(loss)
model.update_weights()

This iterative process helps the model improve over time. I find it fascinating to see how computers can learn to recognize patterns without explicitly programmed rules.

The Internet and Databases

When you type a URL, a series of protocols kicks in to fetch the web page. Your browser sends an HTTP request over the TCP/IP network, and the server responds with HTML, CSS, and JavaScript. Databases store the underlying data. Consider a SQL query that retrieves user details:

SELECT username, email FROM users WHERE id = 1;

Proper input sanitization is crucial here to prevent SQL injection attacks. The internet and databases work together to bring content to your screen, connecting data across the globe.

Every day, I’m learning more and tweaking my understanding, so I can not only be a better DevRel but also share these insights with you in a fun and digestible way. Whether you’re a seasoned developer or just starting out, I hope this helps make computer science a bit more approachable and a lot less intimidating.

Feel free to share your thoughts, ask questions, or drop a comment below. Let’s keep coding smart and learning every day!

Before I sign off, here's another meme—I really like this one xD

Insider Realities of Site Reliability Engineering: Lessons from a DevRel Perspective

Rohan Taneja — Fri, 14 Feb 2025 08:14:27 +0000

Hey everyone, I’m Rohan from Zenduty. I’m not an SRE myself, but I get to work with some of the smartest, most resilient folks in the biz—and trust me, their behind-the-scenes stories are as eye-opening as they are entertaining.

Today, I'm sharing some honest confessions from the SRE world. Think of it as a backstage pass into the wild, sometimes wacky, always technical reality of keeping systems up and running. Grab your coffee, lean in, and let’s dive into these truths.

1. The thrill (and chill) of outages

No one actually wants an outage. But if you ask an SRE, you might catch them with a knowing smile. There’s something oddly exhilarating about that heart-pounding moment when your dashboard lights up with a critical alert—be it from Splunk, Datadog, or Prometheus.

It's like being on a high-stakes treasure hunt where every log entry could lead to the next breakthrough. Sure, the adrenaline rush isn’t all sunshine and rainbows, but it fuels that relentless drive to fix things fast. And hey, who wouldn’t want a little excitement every now and then? (Don’t worry, we’re not celebrating chaos; we’re celebrating the art of recovery.)

2. Envying the Code-Only Life

Ever glance over at a developer, deep in thought, coding away with no alert buzzing in the background? There's a part of us SREs that can’t help but envy that uninterrupted flow. While developers enjoy uninterrupted creativity, we’re on constant alert—our lives punctuated by 3am calls and unexpected escalations.

It’s a trade-off: the satisfaction of keeping critical systems reliable versus the luxury of quiet, focused coding time. If only we could swap places for a day… but then, who’d be there to save the day when things go wrong?

3. The "Human Error" Dilemma

We geek out over complex architectures—think distributed systems, Kubernetes clusters, and seamless integrations with tools like Grafana and AWS CloudWatch. But here’s the kicker: no matter how advanced your system is, a single human mistake can turn everything upside down.

A misconfigured pipeline or a fat-finger typo can spark a chain reaction that leaves you scrambling. It’s a humbling reminder that, at the end of the day, our systems are only as reliable as the people who manage them. That’s why we champion rigorous change reviews and robust rollback strategies—because even the best-laid plans can go awry when humans are involved.

4. Skipping the Big Drills

Most teams are great at running drills for minor issues—a misrouted alert here, a small config error there. But when it comes to simulating real disasters, many of us tend to hit the snooze button.

Sure, a fire drill for a tiny glitch is comforting, but how often do we really prepare for a full-blown data center outage or a network partition? It’s easy to say, “That’ll never happen,” until it does. The reality is, true disaster readiness—comprehensive, multi-region failovers and coordinated crisis management—is the game changer. We need to invest more time in these big drills, not just the small stuff.

5. Change: The Necessary Evil

Change is the double-edged sword of our digital world. On one side, it’s the lifeblood of innovation; on the other, it’s the root cause of most outages. Every new code push or configuration update is a gamble. As SREs, you become the reluctant gatekeepers, demanding thorough testing, rigorous reviews, and robust rollback plans.

Data from our own experiences shows that outages drop dramatically—up to 70-90%—when there’s a pause on deployments, like during planned maintenance. We might grumble about all the extra red tape, but deep down, we know that a little caution goes a long way in keeping systems reliable.

These realities might sound like confessions, but they’re the very truths that shape our approach to reliability. At Zenduty, we strive to support SRE teams with tools and practices that make these challenges manageable—transforming every outage into an opportunity to learn, improve, and innovate.

What do you think? Which of these truths resonates with you? Drop your thoughts in the comments or share your own SRE experiences. Let’s keep pushing the boundaries of reliability together!

Thanks for reading and happy monitoring!