Ziad.dev | Blog

My Microsoft Internship

Tue, 01 Sep 2026 00:00:00 GMT

I wrapped up my Microsoft internship for Software Engineering on August 28th, as a rising fourth year in Redmond, Washington. Here are my thoughts.

As I am writing this, I find myself in a kind of stupor. I am not exactly sure what I should talk about, what I should emphasize, what I should ignore, etc. It has been a fairly long 3 month internship. I met a lot of people, but definitely could have met more. I made a lot of design decisions, and some of them could have been better. I learnt a lot about the methodology of designing software at scale, where security and privacy are core components.

I did a lot of things, yet I could’ve done a lot more, both in my work life and my personal life.

To give a fair description and review, given my indecisiveness about what to write and my laziness about writing a lot, I decided to divide my internship into three periods: early (around the first two weeks), middle (the bulk of the three months) and late (the last three weeks). Without further ado, let’s start.

I will probably write another blog on what I learnt, so wait for that.

Early Period

This is the first two weeks. I remember when I first arrived, the first thing I thought was that the Microsoft campus just feels like a university campus. There are a lot of buildings I can enter with my ID card, and it was great. The not so great part was that all the buildings were basically the same, sans some differences that correlated to the building’s age. I think I visited more than 20 Microsoft buildings, and after the first 5, there wasn’t really a lot to see.

Some buildings had very nice easter eggs, such as the Gundam figure below, which I really really liked as a Gundam figure collector (successfully collected one for now). Others were just a stack of cubicles, smaller than 64 square feet. So which building you get probably has a large effect on your experience — at least it did on mine.

After that, I met my manager and mentor, who I shall keep anonymous for now. First impression was that they were really nice, and I could feel that they wanted me to succeed. Second impression was that I am the first intern they had in at least half a decade, and the only intern they’re gonna have this cycle.

Of course, after realizing this, I set out to impress them, even staying a little past 5 PM to make sure I was ahead. I had a goal to make my first pull request within the first week, which I think helped me a lot in getting ahead of everything.

At this point, my task was just getting my local dev box ready and being able to run the application locally. These were fairly easy tasks, but also fairly time consuming — given that a lot of the services were using some sort of auth, you needed to follow a set of rules to make it work locally without breaking things.

I remember one Wednesday when I stayed a little late, my boss came up to tell me that I should take it easy and that he was impressed by my performance. I was a little touched by that, and I decided to try and follow his advice. Unfortunately, for the vast majority of my internship, I still stayed longer in the office, at least until 7 PM, because of my housing situation.

Housing situation

I ended up finding a posting on Discord (not the best, I know) that was suspiciously good. The rent was on the expensive side but still reasonable, and it was in Bellevue, 15 minutes by bus from Microsoft. The room was small with no overhead light, but it was fine for my purposes.

What was not so fine is that my landlord was running an illegal Airbnb business out of the other two rooms, basically forcing me to live with dozens of strangers for the duration of my internship. To say I was uncomfortable would be an understatement, and even after telling her about it, she didn’t relent. It is probably good context to know that I was not aware of this before renting, and it was not mentioned in my lease agreement.

So I wanted to spend as little time in the house as possible. I consider myself averagely-verted, hopefully that’s a word, but I still didn’t like meeting so many strangers, some of whom felt fairly dangerous. I ended up spending most of my time at the office, leaving at 9 PM on average. Add an hour or two in the gym, and I would be back home around 11, where I would just go to sleep and the cycle would repeat.

The first few weeks were terrible, but as humans naturally adapt to things, I did too, and it wasn’t so bad anymore. And it wasn’t all bad — staying in the office so late made me pick up a lot of good habits.

For one, maybe because I was still physically at work, I felt more comfortable allocating time to computer science and math. It gave me a lot of time to think about how I type, and to relearn typing the correct way. I felt encouraged to learn Rust, which I am very happy to be using. I now do the Leetcode of the day, which I look forward to every day, and I do mental math stuff too.

These were all things I wanted to get into but either didn’t have time for, felt too burnt out from coding all day to do, or just didn’t want to do. Now I have a number of good habits that I feel good about, and like a nice typeracer quote says,

You are what you repeat.

Middle Period

The bulk of my internship, and where I mostly worked on my project. For context, at Microsoft, interns are usually assigned a big project instead of small tasks, and they take ownership of it. Whether it actually gets deployed or not is a different matter, but that’s basically your whole thing as an intern. For policy reasons, since my project was checked in and merged into the codebase but not yet released, I can’t talk too much about it here.

This period was fairly cool, and full of design choices. I talked a lot with my mentor about different tradeoffs, implementations and customer privacy. If you don’t know, Microsoft prides itself on handling your data very privately, and it felt true — it took a lot of jumping through hoops, talking to legal and other teams, just to get access to data sources that are fairly trivial but are nonetheless customer data.

My project was hosted in 2 mono-repos that dozens of teams and hundreds of developers push code to, which was a little disorienting at times. God knows how many git rebases I had to do, and how many hours I spent waiting on builds and tests. But I picked up a lot of good habits for working on big software. It feels bureaucratic, and it is, but that’s one of those things bound to exist in big corporations, kind of similar to Ramsey’s number.

There were a lot of Microsoft-hosted events, and a lot of prizes I ended up winning. There was the interns hackathon and the interns puzzleday. I didn’t win either, but came fairly close! I met a few interns there, which was the bulk of the interns I met all summer. Not meeting more of them did fill me with a little regret, but since I was basically the only intern in my building, it wasn’t easy to do.

Picture of some of my winnings will be added on a later update.

I went kayaking for the first time with my intern cohort — the people who joined Microsoft at the same time as you. It was really fun, and it made me aware that even though I can lift many times my weight, my cardio was fairly awful. I did work on that later in the gym.

I made sure to explore Seattle, Redmond and Bellevue too. The aquarium, Mount Rainier and the Bellevue Botanical Garden were my favourite spots.

Picture of mount reiner will be added on a later iteration

The highlight, though, was getting to attend the Egypt vs Iran World Cup match. I never expected to watch Egypt play a World Cup game in person, let alone a short trip from my office, so the whole thing felt a little surreal. The crowd was the best part of it, and it was easily the most at home I felt all summer.

This was also when I was most consistent with my habits, and when I started feeling the benefits. Even though my housing situation still sucked, it is hard to deny that it helped me in a lot of ways.

It was around this point that I began hearing horror stories from other interns about their experiences, managers and mentors. I know it shouldn’t make me feel this way, but it made me more grateful, and more willing to take advantage of my circumstances.

Overall, I had a lot of fun and could feel my skills evolving.

Late Period

Around 3 weeks before the end. At this point I was done with my project and was deploying and testing it rigorously, and preparing the slides for the presentation I was gonna give to my VP.

My mentor, who was my main point of contact, went on vacation around then, which introduced some hurdles but ended up bringing me much closer to the rest of the team. Before he left, I was too dependent on him. After he left, I talked to a lot more people — we talked about powerlifting, life and kids (I don’t have any kids), and played a lot of ping pong. It was a fun time that I regret not getting to sooner, but better late than never.

This was also when I started realizing my time was almost up. I went out to explore a lot more buildings, even checking out Microsoft’s quantum computer, just so I knew I didn’t miss anything. I tried a lot of the famous spots in Bellevue, good Indian places and so on. The days were moving fast and it didn’t feel like enough, but I still enjoyed it. After all, this might be the last time I visit this campus, so I made sure to take a lot of pictures.

Rolling out my code was fine, if a lot more bureaucratic than it needs to be. I still picked up a lot of skills and learned a lot of new software along the way, even if it could have been faster and less stressful.

Review

Just like all things in life, it could’ve gone better and it could’ve gone worse. I could’ve met more interns and had fun with people my age, and I could’ve isolated myself even more because of the housing situation. But I feel satisfied with the experience, which is one of the reasons I am even writing this.

I feel grateful to everybody who made this possible. To God, to my parents, friends and teachers. To my mentor and managers, and my co-workers. I left Seattle on August 29th with few regrets, and I do feel lucky for that.

Making My Own Python Linter: Pyleft

Sun, 09 Aug 2026 00:00:00 GMT

I have a weird gripe with Pyright, arguably one of the most widely used type checkers in the Python ecosystem, so I decided to make my own.

Introducing Pyleft.

A good first question is why I dislike Pyright so much. It mostly comes down to three reasons:

No plugin system
Some of its warnings are extremely unpythonic
It is very slow

Let’s go through each of these briefly.

No Plugin System

Most mature tools in this space expose a plugin API mypy and pylint both do — mostly to accommodate use cases the tool doesn’t support yet. Unfortunately, according to this thread, Microsoft does not seem interested in supporting any plugin system in the future.

I have to admit that Pyright supports almost everything you want out of the box. But the modern consensus in linting is that no tool can anticipate every codebase’s conventions, and the escape hatch for that is plugins.

Unpythonic Warnings

Seeing is believing, so here is an example you can reproduce right now.

from abc import ABC, abstractmethod


class Pet(ABC):
    def __init__(self, name: str) -> None:
        self.name = name

    @abstractmethod
    def make_sound(self) -> str:
        raise NotImplementedError("Subclasses must implement this method!")


class Dog(Pet):
    def make_sound(self) -> str:
        return "Woof Woof"


class Cat(Pet):
    def make_sound(self) -> str:
        return "Meow Meow"

This code is valid Python and runs exactly as expected. If you’re not familiar with the pattern: it defines an abstract base class Pet that both Dog and Cat inherit from.

This way, we force Dog and Cat to abide by the contract defined by Pet, and we can write functions like def remove_animal(inventory, animal: Pet) instead of maintaining def remove_cat(), def remove_dog(), and so on for every pet we add.

If you run this through Pyright, you get a warning along the lines of reportMissingSuperCall. Pyright is complaining that Dog and Cat don’t explicitly write out the inherited method and delegate to the parent. In my opinion this is redundant, especially when the methods in question have many parameters or long names, it is pure boilerplate. And imagine a class with a hundred methods: now I’m writing two hundred lines of this.

def some_method(self, x, y):
    super().some_method(x, y)

The Pyright folks argue it prevents bugs. But the whole purpose of polymorphism is to abstract common behavior and share it without restating it at every subclass. The pattern Pyright pushes here is unpythonic, and it increases the programmer’s burden to work around the type checker rather than with it.

It Is Very Slow

To back this up, I benchmarked four checkers: pyrefly, ty, pyright, and mypy.

Concretely, I used pyrefly 0.60.0, ty 0.0.29, pyright 1.1.408, and mypy 1.19.1 across 53 popular open-source packages. Here’s how they compare head to head.

Small and medium packages (under 1s for the fastest checker — flask, requests, sentry-sdk): pyrefly and ty both finish in a fraction of a second, typically within 100ms of each other. Pyright and mypy take 2–20x longer on the same packages.

Large packages (1–5s for the fastest checker — pandas, tensorflow, homeassistant): pyrefly and ty stay in the same ballpark, usually finishing within a few seconds of each other. Pyright and mypy can take 10–50x longer. Pyright needs 144s for pandas, where pyrefly takes 1.9s and ty takes 1.5s.

Extra-large packages (scipy, numpy, sympy): these stress-test overload resolution and union handling. Both newer checkers stay under 5s on most of them, though individual packages can be outliers — ty takes 30.6s on numpy, likely a bug that will be fixed in a later release, while pyrefly takes 4.8s. Conversely, ty checks sympy in 1.6s against pyrefly’s 4.0s. Pyright can take over two minutes on these packages.

Pyright is essentially the slowest checker on every codebase I tested, which I think makes the point.

Introducing Pyleft

While learning Haskell, I came to appreciate how naturally functional programming fits linting and because I was fed up with Pyright, I ended up making Pyleft.

Pyleft is a Python linter written in Haskell. It parses Python source into an AST serialized as JSON, then runs a set of rules over that tree and reports diagnostics.

Why Haskell? A linter is, at its core, a pattern match over a tree. Algebraic data types describe an AST almost exactly, and every rule reduces to a pure function from that tree to a list of diagnostics. That buys a few things for free: rules have no shared mutable state, so they are trivially testable in isolation and embarrassingly parallel; they compose, so a rule set is just a list; and exhaustive pattern matching means the compiler tells me when I’ve forgotten to handle a node type instead of silently skipping it at runtime. Writing the first rule took maybe over an hour. Writing the fifth took twenty minutes.

Today Pyleft ships six rules:

bare-except
wildcard-import
mutable-defaults
unused-import
unused-local
shadow-builtins

Configuration lives in a pyleft.toml file, where you can pick a theme, disable individual rules, and set severity per rule — error, warning, or info.

Running it requires GHC, Cabal, and Python 3:

cabal run pyleft -- examples/

It accepts multiple paths, and a flag to control how deep it descends into directories.

Pyleft is early — six rules is not a replacement for anything, and it is BSD-3-Clause licensed and open to contributions. But the architecture is the point. Because every rule is a pure function over an AST, adding one is a matter of writing a function and registering it, which is exactly the extension story that made me want to build this in the first place. Getting that from a config file to a real plugin interface is the next thing I’m working on. I am also planning to add even more rules very soon.

If you want to try it, break it, or tell me my opinions about super() are wrong and that you have a gripe with Pyleft, the repo is here.

Where Should Secrets Live, and Why It Should Not Be in Your Config

Wed, 22 Jul 2026 00:00:00 GMT

Imagine you are one of the 212,230 AI ChatGPT Wrappers founded in 2025 about to make your grand debut to the world. You push your code, vercel deploys it for you while charging too much money to your bank account, and you sit happily, waiting for the profits to rake in, unaware of the disaster awaiting.

You sleep and have a good night’s sleep, wake up and OH MY God. Your bank account has a 6 figure number. You stand still, shocked and dancing with happiness. You finally made it and have become rich (upper middle class), and about to hit the floor dancing, until you notice the ’-’ sign.

You deflate almost visibly, but take a couple of deep breaths. No way that number is right, you mused. It must be a glitch with the bank, similar to the -99 billions glitch, you thought.

You call the bank, get elevated to the branch manager, and he breaks the news:

This is not a mistake.

he said

You got this charge from checks notes Open AI.

You, my friend, have made one of the worst mistakes a software developer could do. You exposed your api key, a secret, by accident, and now the whole world is using it.

This story is probably too long, and I had too much fun writing it, but it conveys a reality some people actually experienced, especially post the AI boom. A lot of people, new to the industry and intoxicated with a poorly explained tool, thought they could be the next Uber, but they did not realize that by unknowingly allowing AI to push and share their keys, they gave almost unlimited access to anybody on the internet.

You might ask a good question: will somebody really find it? My account on Github is followed by 5 people (4 are my friends and the rest is my other account), so even if I did this mistake, nobody will find it. Unfortunately for you, the latest studies say it is found within two minutes. It sounds crazy, but right now there are thousands if not millions of bots grepping things like .env .config .git *.prod and so on, waiting for the smallest mistake, and if you make one, trust me, they will capitalize on it.

So what can you do? A lot actually, but before we get to the tools, we need to talk about a distinction most of us (me included) never think about.

Secrets and Config Are Not the Same Thing

The thing most folks don’t get is that configuration and secrets are not the same kind of thing, even though we keep dumping them in the same file.

Configuration describes behavior: which port to listen on, which model to call, how many retries before giving up. It belongs in git, in code review, in bug reports, and on every developer’s machine. You actually want it shared.

A secret, on the other hand, grants authority: an API key, a database password, a signing key. It needs restricted access, its own rotation schedule, and ideally nobody ever sees it.

The moment you put both in one file, you have glued together two things with completely different lifecycles and audiences. Your teammate asks “can you send me your config so I can reproduce this bug?” and now you are one paste away from the story above. Or you rotate a database password and suddenly you are redeploying configuration, which makes no sense if you think about it. Changing a password shouldn’t touch the file that says what port you listen on.

Everyone Has This Problem, Even NixOS

You might think this is a beginner mistake, but the whole industry is built on top of it. The SecretSpec folks did a great writeup here where they audited all 445 NixOS modules in nixpkgs that handle a real secret, and classified where each secret value actually ends up:

Where the secret value ends up	Modules	Share
Merged into a config file at runtime	110	25%
Delivered as an environment variable	161	36%
Left in a dedicated file opened by the app	58	13%
Loaded through systemd credentials	53	12%
Inlined into a config in the world-readable `/nix/store`	42	9%
Passed as a command-line argument	19	4%

The interesting number is 110. A quarter of the modules retrieve a secret safely, and then have to copy it back into a config file at runtime, because that is the only interface the application accepts. They do it with envsubst, sed, jq, replace-secret, or hand-rolled scripts that stitch the config back together at startup. The result can be secure, but now every single module carries its own fragile, security-sensitive glue code just to combine two things that shouldn’t have been together to begin with.

And this isn’t a Nix thing. The same workaround shows up everywhere as an entrypoint script in your Dockerfile, a Helm template, an init container, or that one CI step doing string interpolation into a yaml file that everyone is scared to touch. If you have ever written one of these, you already paid the price for an application that only accepts secrets through its config.

(Also, 42 of those modules can end up inlining secrets into /nix/store, which is world-readable. That one is just a straight-up leak.)

`password_file` >>>>> Password in Your Config

If you write applications, the fix is honestly simple: stop adding passwords and tokens to your config schema. Let secrets come in through their own door.

Say you started with this:

# config.yaml -- please do not do this
database:
  host: db.internal
  port: 5432
  password: hunter2 # <-- this whole file is now a secret

One field turned the entire file radioactive. Now nobody can commit it, share it, or paste it in a bug report. Instead, accept a reference to the secret:

# config.yaml -- commit me.
database:
  host: db.internal
  port: 5432
  password_file: /run/secrets/db_password

And in code, the change is honestly tiny:

password = config["database"]["password"]                     # before
password = Path(config["database"]["password_file"]).read_text().strip()  # after

You have a couple of options for that door, roughly in order of how nice they are:

A password_file / token_file setting: the config points at a file, the file has restricted permissions, and the config itself stays boring and shareable.
systemd credentials: on Linux, LoadCredential= hands your service a file that only it can read, and the secret never touches the environment.
A narrowly scoped environment variable: the classic. Fine, but be aware env vars are inherited by every child process you spawn, and they love showing up in crash dumps and debug logs.
An external secret provider: the app asks Vault (or a keyring, or a cloud secret manager) directly at startup.

None of these are magically safe. Files still need correct permissions, env vars leak to children, and command-line arguments are visible to anyone running ps, which is probably why only 4% of those NixOS modules pass secrets that way. But what the separation does guarantee is that nobody has to build a second, secret-filled version of your config ever again.

AI Loves Shoving Secrets Into Your Config (Especially with Pydantic)

Remember our friend from the intro who let AI push his keys? The problamatic part is that AI doesn’t just leak secrets, it happily writes them straight into your config for you. Ask any AI assistant to “add settings to my FastAPI app” and I can almost guarantee it gives you this:

from pydantic_settings import BaseSettings, SettingsConfigDict

class Settings(BaseSettings):
    app_name: str = "myapp"
    debug: bool = False
    database_url: str = "postgresql://admin:hunter2@localhost/db"
    openai_api_key: str = ""

    model_config = SettingsConfigDict(env_file=".env")

This looks clean, it type-checks, and it is exactly the disease from earlier. To be fair, it isn’t really the AI’s fault: it was trained on a million tutorials and quickstarts that all do this, so of course it repeats them with full confidence. But there is so much wrong packed into this innocent looking class:

Config and secrets are fused into one class again, so the whole thing is radioactive.
There is a default value with credentials in it, sitting in a .py file that is 100% going to git.
Everything hangs off one .env file, which gravitates toward being committed “just this once, so it works on your machine”.
Worst of all: pydantic models have a lovely repr. The first time you print(settings) while debugging, or an exception handler logs it, your OpenAI key is in plaintext in your logs. Bots grep logs too.

The good news is that pydantic already has the tools to do this right, the tutorials just never use them. SecretStr masks the value everywhere and makes you unwrap it on purpose. Splitting the class in two separates config from secrets, same idea as this whole article. And secrets_dir is pydantic’s built-in version of the password_file pattern: each field gets read from a file named after it, which happens to be exactly the format Docker secrets and systemd credentials hand you.

from pydantic import SecretStr
from pydantic_settings import BaseSettings, SettingsConfigDict

class AppConfig(BaseSettings):
    # boring, shareable, commit the defaults proudly
    app_name: str = "myapp"
    debug: bool = False
    database_host: str = "localhost"

class Secrets(BaseSettings):
    # reads openai_api_key from /run/secrets/openai_api_key
    model_config = SettingsConfigDict(secrets_dir="/run/secrets")

    database_password: SecretStr
    openai_api_key: SecretStr

Now print(secrets) gives you openai_api_key=SecretStr('**********'), and the only way to get the real value is an explicit secrets.openai_api_key.get_secret_value() at the exact call site that needs it. AppConfig is shareable configuration, Secrets has its own door, and it is the same amount of code.

One more practical tip: if you are letting an AI write your code, put this rule in its context. A line in your CLAUDE.md or AGENTS.md like “never put secrets in config classes or defaults; use SecretStr and a separate Secrets settings class” fixes the pattern at the source, instead of you catching it in review every time.

So Where Should the Secrets Actually Live

So we kicked secrets out of the config. They still need a home, and the annoying part is that the right home is different in every environment:

Your laptop: use your OS keyring (macOS Keychain, GNOME Keyring / KWallet). It is encrypted, it is already there, and it beats a plaintext .env sitting in your home directory. If you use 1Password, op run -- ./myapp will inject secrets straight from your vault into the process and nothing ever hits disk.
CI: use the platform’s secret store (GitHub Actions secrets, GitLab CI variables). They are masked in logs and scoped to the repo.
Production: this is where actual vaults shine. Vault / OpenBao, AWS Secrets Manager, GCP Secret Manager. You get access control, audit logs of who read what and when, and rotation without redeploying anything.

The problem is that now you have three environments with three different lookup mechanisms, and you end up writing glue for each one. This used to be the point where you either build a mini secrets platform or give up and go back to the .env file.

This is exactly the gap SecretSpec fills. You commit a secretspec.toml that declares what your app needs, and never the values:

[project]
name = "myapp"

[profiles.production]
DATABASE_URL = { description = "Postgres connection string" }
OPENAI_API_KEY = { description = "The key from our story earlier" }

Then every environment resolves the same declaration from whatever provider it wants: your laptop uses the keyring, CI uses env variables, production uses Vault or 1Password. Running it is one command:

secretspec run -- ./myapp

There are also SDKs (Python, Rust, Go, Node, and more) if you want the app to resolve secrets directly instead of receiving them as env vars. Your config declares what it needs, each environment decides where the value lives, and you never write the glue yourself.

What to Do if You Already Leaked One

Because statistically, some of you reading this already have:

Rotate the key. Now. Not after reading this article. Deleting the commit or force-pushing does nothing, remember the two minutes thing? The bots already have it, and the only way to actually kill a leaked key is to revoke it.
Turn on push protection. GitHub’s secret scanning push protection will straight up refuse the push if it spots a known key format. It is free and it has saved me from myself.
Add a scanner to pre-commit. gitleaks or trufflehog will catch a secret before it ever enters your history, which matters because git history is forever.
Set spending limits. If your OpenAI key does leak, a 50 dollar hard cap is a much better morning than our friend from the intro had.

Final Thoughts

The .gitignore advice everyone gives you isn’t wrong, it is just the last line of defense. The real fix is structural. If a quarter of NixOS modules have to write custom glue because applications refuse to separate them, the least we can do in our own apps is not add to the pile.

And seriously, go rotate that key.

What I think about the World Getting Its First Trillionaire

Sun, 14 Jun 2026 00:00:00 GMT

With the iconic SpaceX IPO, the world has gotten its first trillionaire, in other words a 1 with 12 zeroes next to it. Public opinion obviously is mixed about it, and I wanted to give my two cents on the matter: I don’t think this is necessarily a bad thing, I actually think this changes very little and here is why.

My opinion might come as stupid, especially now with income inequality being at all time high, but I have my reasons to stand by it. But first, I want us to take a moment to imagine what a trillion actually means, since humans are apparently really bad at imagining big numbers. This will make sense at the end of the blog.

let’s start with a fun one I calculated based on the measurement of a standard one dollar bill. If you have a trillion dollars in one dollar bills, and aligned them in a single line, you could cover the equator at least 3,891 times.

If you can’t visualize that, maybe you have seen the news about the new Nasa trip to the moon and the preparations it is taking, and you would know that going to the moon is especially hard because it is far. Well, with that same line you could cover that trip and back more than 200 times.

if you like thinking in time instead of distance, here is a popular one: You would need to spend 1 million dollars a day every day from 712 BC until our year just to spend all of the trillion dollars.

The point I am trying to make is that a trillion dollars is a stupid amount of money, but the fact that Elon Musk has finally attained it, in my opinion, doesn’t mean much for the average joe, including me. Let’s first break some misconceptions. In our capitalistic-based society, the total amount of wealth is not fixed, thus someone getting richer does not inherently make everybody poorer. Sure, it might increase income disparity, but it doesn’t make your purchasing power weaker bar something crazy going on.

Most of This Money Doesn’t Really Exist

and for the second point, which is the meat of this article: most of the SpaceX money is purely virtual. Elon Musk attaining this status was by multiplying the shares of SpaceX that he owns by their current price, but this does not mean that Elon Musk has a trillion dollars at his disposal.

if we go for the extreme example, where Elon wakes up one day and decides to sell all of his shares, at some point, there are not gonna be enough buyers, and SpaceX’s price will drop to 0 before he is even done. This is called liquidity, and it is a real constraint that people seem to forget about when they talk about billionaires’ net worths.

in fact, reports say that less than 0.1% of Musk’s net worth is actual cash. That is around 850 million dollars in liquid money, which sounds like a lot until you remember we are comparing it to a trillion. Over 95% of his wealth is stock, shares in Tesla, SpaceX, xAI, and other ventures. It is not sitting in a bank account somewhere. It is not money he can wire to someone tomorrow.

”Why Doesn’t He Just End World Hunger?”

this is probably the most common criticism I see online, and I get why people say it. The UN estimates that ending world hunger would cost somewhere around 45 billion dollars a year. Some estimates go as high as 330 billion dollars total to end it by 2030. When you see a headline that says someone is worth a trillion dollars, the obvious reaction is “well, why doesn’t he just fix it then?”

But the problem is exactly what I described above. That trillion is not money. It is a valuation. Musk cannot write a check for 45 dollars billion without selling a massive chunk of his companies, which would tank their stock prices, which would make him worth less, which means he would need to sell even more shares to cover the difference. It is a spiral. The money people think he has is not the money he actually has.

I am not saying billionaires shouldn’t contribute more. I am saying the framing of “he could end world hunger and chooses not to” is misleading because it treats a stock valuation like a bank balance, and those are two very different things.

He Built These Companies

the last thing I want to say is about ownership, and I think this is a selfish part of me talking. Elon Musk owns roughly 42% of SpaceX equity. He also controls about 82% of the voting power through a dual-class share structure. Some people look at that and think it is unfair or excessive.

I actually think it is fair, as much as I dislike the man. He founded SpaceX. He put his own money into it when nobody believed reusable rockets were possible. He almost went bankrupt doing it. The company exists because of decisions he made and risks he took when the odds were against him. I think it is completely reasonable for a founder to want to keep ownership and control over something they built from nothing.

this doesn’t mean founders are above criticism, or that everything Musk does is right. But the idea that someone should give up ownership of a company they created just because it became very valuable feels off to me. You don’t hear people complain when a small business owner owns 100% of their shop. The principle doesn’t change just because the numbers got bigger in my opinion.

So What Do I Actually Think?

I think the world getting its first trillionaire is mostly a symbolic milestone. The money is largely virtual. It doesn’t change what you or I can buy at the grocery store. The money was always there, it just got offloaded to the public and we got suprised. Even more so, the guy who has it can’t even spend most of it without destroying the value in the process.

If anything, I think the conversation we should be having is about tax policy, capital gains structures, and how we fund public goods, not about whether one person’s stock portfolio hit a number with twelve zeroes. Now that we have hit this symblic landmark, I think it is a sign and imperative to us to improve our taxing system for the betterment of all of us.

What Math Says About Consistency vs. Clutch Moments

Mon, 20 Apr 2026 00:00:00 GMT

Would you rather be the coworker who is lazy all year, barely does anything, but when your team needed him the most, he clutches?

Would you rather be the coworker who puts in the work, the hours every day, every hour, but never really shines or goes extremely beyond expectation?

I think many of us have probably asked that question before, and all the implications behind it.

“What looks good for a manager?”

“What will bring me a promotion faster?”

“Who do my colleagues need more?”

Those are all fair questions that I will not get into here. Rather, I want to use mathematics, specifically integration, to argue that one of these is better.

The Proof

We want to show that overall consistency matters more.

Let $f(x)$ be a function mapping time to some arbitrary metric of performance on an interval $[0,T]$ where $T > 0$ . For example, person $A$ could have performance $50$ at time $20$ . The exact units do not matter. We only care about the total contribution over time.

Now define two functions $f_1(x)$ and $f_2(x)$ .

Let $f_2(x)=1$ for all $x\in[0,T]$ . This is the consistent worker: always contributing, maybe not flashy, but always there.

Now let $E=\{a_1,\dots,a_n\}$ be a finite set of times where the other worker has those rare “clutch” moments, and define

f_1(x)= \begin{cases} M, & x\in E,\\ 0, & x\notin E, \end{cases}

where $M>0$ is very large, as much as you want actually. So semantically, $f_1$ represents the worker who is mostly doing nothing, but at finitely many moments does something extreme.

It should be clear that the area under the graph represents the total accumulated contribution over time. How can we concretely calculate the area? We integrate.

We will use the definition of the Riemann integral with partitions.

For any partition $P$ of $[0,T]$ , the lower sum satisfies

L(f_1,P)=0,

since every subinterval contains points not in $E$ , where $f_1=0$ .

For the upper sum, only the subintervals containing one of the points $a_1,\dots,a_n$ contribute anything. Since there are only finitely many such points, we can choose a partition $P$ so that the total length of all subintervals containing them is less than $\varepsilon/M$ . Then

U(f_1,P)\le M\cdot \frac{\varepsilon}{M}=\varepsilon.

So for every $\varepsilon>0$ , there exists a partition $P$ such that

U(f_1,P)-L(f_1,P)<\varepsilon.

Hence $f_1$ is Riemann integrable, and in fact

\int_0^T f_1(x)\,dx=0.

Since the supremum of all lower sums is just 0, which is the defintion of the intgeral.

On the other hand, for $f_2(x)=1$ , every subinterval has infimum and supremum both equal to $1$ . So for every partition $P$ ,

L(f_2,P)=U(f_2,P)=T,

and therefore

\int_0^T f_2(x)\,dx=T.

So even if $f_1$ reaches a much higher peak than $f_2$ , its total contribution is still

0,

while the steady worker contributes

T.

That is the point.

The clutch worker might win if all you care about is the maximum value of the function. But if you care about the total accumulation over time, which is what the integral measures, then consistency wins.

So What?

A few rare moments of excellence can look impressive.

But isolated spikes do not build area or trust.

The person who shows up every day, even without some insane peak, is the one whose contribution actually accumulates, at least mathmatically.

Feelin' Functional

Tue, 24 Mar 2026 00:00:00 GMT

For a fair amount of time, I have been interested in functional programming, especially because of Lean, theorem proving, and formal languages in general.

But I did not really get into it for a long time, and the reason was pretty simple.

Functional programming looks intimidating.

No mutation, almost no side effects, no classes, and some of the craziest type signatures you will ever see. Stuff like this does not exactly make you feel welcome:

type Enumerate<N extends number, Acc extends number[] = []> = Acc["length"] extends N
  ? Acc[number]
  : Enumerate<N, [...Acc, Acc["length"]]>

type IntRange<F extends number, T extends number> = Exclude<Enumerate<T>, Enumerate<F>>

type T = IntRange<20, 300>

And even for simple problems, the way you think changes a lot.

Take reversing a list. In Python, I would probably do something like this:

def reverseString(s: list[str]) -> None:
    if len(s) == 0 or len(s) == 1:
        return

    start = 0
    end = len(s) - 1

    while start < end:
        s[start], s[end] = s[end], s[start]
        start += 1
        end -= 1

That is efficient, straightforward, and honestly just makes sense.

But now imagine you cannot mutate start or end. You also cannot mutate s. Now what? Think about it for a moment.

def reverseString(s: List[str]) -> list[str]:
  if not s:
    return []
  return reverseString(s[1:]) + s[:1]

and now for haskell

reverseString :: [a] -> [a]
reverseString [] = []
reverseString [x] = [x]
reverseString (x:xs) = reverseString xs ++ [x]

And a better version is that runs on O(n)

reverseList :: [a] -> [a]
reverseList xs = go [] xs
  where
    go acc [] = acc
    go acc (x:xs) = go (x:acc) xs

That shift is what made functional programming interesting to me. You stop thinking about mutating your way to the answer and start thinking more in transformations.

That is where Haskell really started clicking for me.

Why I like Haskell

At first, Haskell looked kind of ridiculous to me. The syntax was unfamiliar, the type signatures looked absurd, and everyone on the internet talked about monads like that was supposed to make things less confusing.

But after using it more, I started realizing that a lot of what felt scary was really just precision.

One of my favorite things about Haskell is the type system. I genuinely love it. The types are not just there to reject your code. They help you write it.

Something like this already tells you a lot:

safeHead :: [a] -> Maybe a
safeHead [] = Nothing
safeHead (x:_) = Just x

Just from the type, you already know this function might fail, and that failure is handled explicitly. I really like that. It makes the code feel honest. It kinda reminded me of units in Physics where the units/types guide me to the asnwer.

I also love typed holes. Being able to put a _ somewhere and let GHC tell me what type belongs there is so nice.

addOne :: Int -> Int
addOne x = _

That sounds tiny, but it genuinely changes the experience of writing code. Instead of guessing what should go there, I can let the compiler guide me a bit. It feels less like fighting the language and more like working with it.

Monads

Monads also get made to sound way scarier than they actually are.

I do not think of them as some magical functional programming thing you need a PhD to understand. I just think of them as a clean way to deal with context.

For example, Maybe handles failure:

safeDiv :: Int -> Int -> Maybe Int
safeDiv _ 0 = Nothing
safeDiv x y = Just (x `div` y)

And IO handles side effects:

main :: IO ()
main = do
  putStrLn "What is your name?"
  name <- getLine
  putStrLn ("Hello, " ++ name)

What I like is that all of this is explicit. If something can fail, I can see it in the type. If something does IO, I can see it in the type. Nothing is pretending to be pure when it is not.

Pure functions are just nice

Another thing I like a lot is the emphasis on purity.

In many languages, effects are everywhere by default. Printing, reading input, mutating state, throwing exceptions, all of it gets mixed into the actual logic of the program. In Haskell, there is a much sharper separation between the pure part of your code and the effectful part.

I have grown to really appreciate that.

Pure functions are easier to trust. Same input, same output. No hidden state, no random mutation somewhere else, no weird behavior because things happened in the wrong order. That makes code easier to test, easier to reason about, and easier to revisit later.

Even a tiny function like this feels very clean:

squareAll :: [Int] -> [Int]
squareAll xs = map (\x -> x * x) xs

It takes data in, transforms it, and gives data back. That is it. No hidden state. No surprises.

I think that discipline is one of the reasons functional programming feels so clean when it is done well.

Why it stuck with me

What I like most about functional programming is that it changed how I think even outside of Haskell.

I now care a lot more about smaller functions, less mutation, clearer data flow, and fewer hidden effects. I think more about types, composition, and modeling a problem well instead of just making something work.

So even when I am writing Python or TypeScript, I still feel that influence: I am definitely using zip, filter and map more from now on.

Functional programming definitely looked intimidating to me at first, and honestly I think that feeling is fair. But once I got over that initial wall, I started finding it not just useful, but actually really fun.

And that is pretty much why I like it.

Review of CMSC 23700: Computer Graphics

Tue, 10 Mar 2026 00:00:00 GMT

As the winter quarter is about to wrap up, I feel the need to talk about one of my favorite classes this quarter — and honestly, one of my favorite classes overall: Computer Graphics.

What is Computer Graphics?

I do not think I can begin this article with anything other than defining computer graphics first. What exactly is computer graphics?

Funnily enough, when we tried to define it on the first day of the quarter, our professor gave us an answer generated by Gemini and said it was good. So, to pay my respects to her and show my gratitude, I will do the same.

The answer I got from Gemini Pro was:

Computer graphics is a subfield of computer science focused on generating, manipulating, and displaying images and visual content using computers. It is the technology that bridges the gap between raw data and the visual information you see on a screen.

That seems pretty accurate to me. Unlike a film camera, for example, where the goal is to capture an image and store it on a piece of film through a chemical process, computer graphics tries to recreate images from a more fundamental form: math.

Why is it useful?

Computer graphics, as a field, is interesting to think about today. Not because it is not widely used — it absolutely is. It shows up everywhere: games, medicine, movies, scientific visualization, simulation, and much more. The interesting question is different: why do we still need to push it further when we already have so much?

If we look at high-end games like God of War Ragnarök or Elden Ring, it is obvious that we have already come a very long way. With enough time, budget, and computing power, we can create visuals that look incredibly close to reality. So why keep going?

The answer is resources. A common theme in this class was that rendering graphics is extremely computationally expensive. A modern 4K display, for example, contains about 8.3 million pixels per frame. If you want to render that at 60 frames per second, you are already talking about nearly 500 million pixel updates every second - and that is before considering lighting, shading, geometry, textures, physics, and post-processing.

That gives us a hard limit on what we can do. Better algorithms, better data structures, and better rendering techniques all make a huge difference. If we can make graphics more efficient while also improving quality, the possibilities become much larger. That is one reason computer graphics still feels so exciting: there is always more to invent and optimize.

What I did in the class

The class was project-based, with four main projects and a final project. That structure made it one of the most rewarding courses I have taken, because instead of only learning theory, we built a graphics pipeline piece by piece and saw how the ideas connected in practice.

Project 1: Rasterization

This project focused on rasterization by turning lines and triangles into pixels on the screen. It was a great introduction to how much precision and detail goes into even simple rendering.

Project 2: 3D Rasterization Pipeline

This project extended rasterization into 3D with transforms, projection, and depth. It made the graphics pipeline feel much more real and much easier to understand.

Project 3: Mesh Editing

This project focused on mesh editing and geometry processing rather than just rendering. I liked how it shifted the focus from pixels to structure, surfaces, and topology.

Project 4: Rigging and Skinning

This project introduced rigging and skinning by connecting a skeleton to a mesh for animation. It was one of the most fun projects and showed how hard natural movement is to get right.

Final Project: Animation and Deformation

For the final project, we explored animation more deeply by building a system that combined Python with the Blender API to render animated deformations. The goal was not just to move an object from one place to another, but to create smoother, more expressive motion and shape changes using more advanced geometric tools.

We had a fair amount of freedom in choosing which algorithms we should implement. I personally used B-splines and free-form deformation (FFD) as core techniques. B-splines were useful for producing smooth curves and trajectories, which made animation feel much more natural than simple linear interpolation. FFD, on the other hand, gave us a flexible way to deform geometry by embedding it in a control lattice and manipulating that structure instead of editing every vertex individually. Using Python and the Blender API also made the project feel very practical, since it connected the theory from class to a real graphics toolchain and an actual rendering workflow.

A tiny example of the kind of code that made the project feel real is that even something as simple as evaluating a smooth path already looks very graphics-heavy:

import bpy
import numpy as np
from scipy.interpolate import BSpline

control_points = np.array([0.0, 1.2, 2.0, 2.8, 4.0])
knots = [0, 0, 0, 1, 2, 3, 3, 3]
curve = BSpline(knots, control_points, k=2)

frame = 20
x = curve(frame / 10.0)

bpy.data.objects["Lantern"].location.x = float(x)

Final Thoughts

Overall, CMSC 23700 was one of the most enjoyable and rewarding classes I have taken. It combined theory, programming, and visual feedback in a way that made every project feel engaging. Few classes let you write code and then immediately see whether your understanding is correct, and that made the learning process especially satisfying.

More than anything, the class made me appreciate how much math, design, and engineering sit behind every rendered image. Graphics is one of those fields where beautiful results come from deeply technical ideas, and I think that is a large part of why I enjoyed it so much.

My Final Project Submission.

I was inspired by Chinese New Year while making this. I am proud by how it looks like, espically because I started with almost nothing all the way till I rendered it. Hope you enjoy.

Play

Making Food for 15 people: Ramadan Edition

Sat, 21 Feb 2026 00:00:00 GMT

It was Friday when my dear friend Gasser told me that he wanted my help cooking Iftar for tomorrow, Saturday.

I agreed, not because I found the idea appealing, but rather because I found it enjoyable to spend time with Gasser (no homo). So I woke up and left my home at 11, heading to Gasser’s apartment. Then I saw the humongous amount of ingredients they had, along with my friend David.

That is when I found out we were not making food for 5, 8, or even 10 people. We were making food for 15 hungry, fasting people while, of course, fasting ourselves.

And so we started.

First thing we did was organize the chaos. Not even in a serious way, just “you do this, I do that, don’t touch my cutting board” type of organizing.

We ended up making macarona béchamel, chicken, and a Middle Eastern-style salad. David also made konafa. And honestly we kind of shared everything else. Nobody had one job the whole time. You’d start on pasta then somehow end up washing dishes or cutting onions.

Macarona béchamel

This one took most of the effort.

We boiled a ridiculous amount of pasta, drained it, and then moved to the sauces. The meat sauce was straightforward: onions, ground beef, garlic, spices, tomato sauce, and patience.

Then the béchamel. Which is basically you standing there whisking while your arm slowly gives up on you. Butter, flour, milk, salt, pepper, a little nutmeg. We made a lot of it, because for 15 people “a lot” is still somehow not enough.

We layered everything in big trays: pasta → meat → pasta → béchamel on top and bottom, cheese above it and then into the oven.

When it finally came out and the top was golden, that’s when it felt real. Like okay, we might actually feed everyone.

Chicken

Chicken was more forgiving. Season it well, don’t undercook it, and you’re good.

My usual ingredients are garlic, lemon, spices, oil. Cooked it in batches. The smell was torture while fasting, but it kept us going.

Salad

The salad was basically us chopping nonstop.

Cucumbers, tomatoes, onions, parsley. Lemon juice, olive oil, salt, pepper, sumac. Simple but it works every time, especially with heavy food like béchamel.

Konafa

David handled the konafa. I’m not even going to pretend I helped much with that one. He took it seriously. Syrup, cheese, the whole thing. It came out looking way too good for a student apartment kitchen.

Right before iftar

The last hour was the most stressful part. Everything is almost ready but not exactly ready, and you keep checking the clock like it’s going to change something.

Trays coming in and out of the oven, people texting “I’m on my way,” someone asking where the plates are, someone else looking for foil.

Then Maghrib hit.

And the first bite was insane. Like your body remembers food exists and immediately forgives the whole day. People ate fast. The macarona béchamel got demolished. Chicken went right after. The salad actually held its own. And the konafa… didn’t last. After that it was the usual: sitting around, talking, feeling full, acting like we’re not about to face the dishes.

But yeah. Cooking for 15 while fasting is not a small thing.

We survived.

Ranking Zero-Calorie Drinks

Thu, 19 Feb 2026 00:00:00 GMT

I really like zero-calorie drinks, and I am not totally sure why. If I had to guess, it is because my parents banned them when I was younger because of the caffeine. That logic never fully made sense to me, since plenty of non-zero-calorie drinks also have caffeine. The ban just made them feel “special,” and now I clearly over-correct.

There is a good Arabic saying for this:

الممنوع مرغوب
What is banned is wanted

With that out of the way, here is my ranking.

7) Cherry Cola

I tried to like it. I really did. I just hate cherries, so this was never going to work.

6) Monster

This is controversial because people love this stuff, but I do not get it. The caffeine level feels like it should be illegal. It makes my stomach feel weird, and whenever I drink it, my whole day feels off.

5) Celsius

It tastes good at first, but it is still too much caffeine for me. Also, it has that “fake sweet” taste, but at least it is not aggressively sugary.

4) Coca-Cola Zero Sugar

Classic. The best part is the consistency: I always know exactly what I am getting.

3) Pepsi

Same idea as Coke, but it has an extra kick for some reason. Something about it flips a switch in my brain in a very specific way (I am not addicted).

2) 7UP

The hidden goat. It actually tastes refreshing, not heavy, and not ridiculously sweet.

1) Dr Pepper Zero Sugar

The undisputed GOAT. Maybe it is because it is the most “American” drink on this list and I did not have it until I came to the US, but it has a unique taste that nothing else here comes close to.

My Neovim + LSP Setup (Lazy.nvim + Nix/Home Manager)

Tue, 17 Feb 2026 00:00:00 GMT

I don’t use VSCode / other GUI stuff for lots of reasons. Mainly because I feel like they force AI on my throat, and I’ll end up too dependent on those AI tools for coding (not that I hate AI or anything).

For that reason, I use my own neovim setup on my trusty Ghostty terminal.

I’ll enumerate my Neovim setup here, which is focused on LSP defaults and reproducibility via Nix/Home Manager. I will not go too deeply on Nix/Home Manager as it will probably be an info overload, but stay tuned for another post about that.

Now, I am using lazy.nvim as a plugin, but you could use anything you like. I mainly use it for its lazy, ironic I know, approach.

Layout

init.lua — entrypoint
lua/custom/plugins/ — plugin specs
lua/custom/configs/ — actual configuration (LSP, cmp, treesitter, keymaps, settings)
lua/custom/util/ — helpers (notably lspconfig.lua)
spell/ — custom spell additions

Home Manager deploys everything into ~/.config/nvim as symlinks to the Nix store (/nix/store/...home-manager-files/...), so the config is declarative and reproducible.

LSP

My LSP config is split into:

configs/lsp.lua — server setup, diagnostics, and common defaults
util/lspconfig.lua — helper glue for lspconfig patterns

I use LSPs for all the languages I code with including

Python
Go
Rust
Nix
Lua
C/C++
HTML/CSS
LaTeX
Markdown
TypeScript
React

They have been a real help for my dev journey, so I highly recommend understanding LSPs and how to use them.

Completion

Completion is configured in:

configs/cmp.lua
plugins/cmp.lua

Notably, I also have a plugins/coq.lua entry — I’ve experimented with both completion stacks.

Treesitter

Treesitter config lives in configs/treesitter.lua, with extra niceties like rainbow delimiters (plugins/rainbow-delimeters.lua) for better readability in nested code.

Daily-driver plugins

A few highlights from lua/custom/plugins/:

Telescope (fuzzy finding)
Gitsigns (git hunks/blame)
Trouble (diagnostics list)
Neo-tree / Nvim-tree (file explorer)
Bufferline (buffer UX)
Harpoon (fast file jumps)
Nvterm (terminal)
Zen Mode (focus)

Language extras

I keep language-specific setup in plugin files:

Go: plugins/go.lua
Rust: plugins/rustaceanvim.lua
Typst: plugins/typst.lua
Debugging: plugins/dap.lua

Reproducibility notes

Config is deployed via Home Manager, so rolling back/upgrading is easy
Language servers/tools are best installed through Nix (system, home, or devShell) so Neovim stays predictable

Wanna Check It Out?

This is all on my GitHub here. Make sure to star it to not miss any updates.

Here is what my setup looks like

Adios!

Powerlifting, and Why I Am Still Doing It

Mon, 16 Feb 2026 00:00:00 GMT

I keep thinking I will never be good at powerlifting.

Not in the fake-humble way. I mean it in the way where I watch someone move a weight like it is nothing, and I am still fighting the same rep I fought months ago. I still miss commands sometimes. I still doubt my technique mid-set. I still have days where the bar feels heavier than it should.

But I still do it.

Because powerlifting gave me something I did not expect: a community. UChicago Barbell became this place where you can be new, awkward, inconsistent, and still be taken seriously. People will spot you, hype you up, and then roast you after. You walk in tired, you leave feeling like you belong somewhere. That matters more than plates.

I am grateful for that. Truly.

Also, I love the simple honesty of it. The bar does not care about your schedule, your ego, or your mood. You either lift it, or you do not. Then you come back, eat, sleep, and try again. It is humbling in a way that feels clean.

Current Numbers

These are my best lifts right now:

Bench: 205
Squat: 225
Deadlift: 315

So yeah, I still powerlift. Maybe I never become “good.” But I already got what I came for.

Python for Oracle Cloud Infrastructure (OCI)

Mon, 16 Feb 2026 00:00:00 GMT

I use Python with OCI because I want infra work to feel repeatable instead of “console clicking until it works.” The OCI console and CLI are fine, but Python is where I can package the boring parts: inventory, guardrails, and a clean summary.

My mental loop is simple:

ASK: what is true right now?
PLAN: what exactly am I about to touch?
APPLY: do the smallest change possible
VERIFY: confirm reality changed
RECORD: print results so I have receipts

Your infra work is reproducible, you won’t have to interact with a legacy site written in Cobol.

Setup (the normal way)

Locally, I just reuse the same config the OCI CLI uses (~/.oci/config). That keeps things clean: no custom auth hacks, no mystery environment variables.

import oci
cfg = oci.config.from_file()

When code runs inside OCI (on a compute instance), I typically switch to instance principals so I am not shipping user keys around:

import oci
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
compute = oci.core.ComputeClient({}, signer=signer)

One small script I actually keep around

This is the kind of thing I mean by “Python controls infra.” It is not a framework. It is a tiny tool that:

lists instances in a compartment
filters by a tag
prints the plan
optionally stops them (with a hard limit)

import oci

cfg = oci.config.from_file()
cpt = "ocid1.compartment.oc1..REDACTED"

compute = oci.core.ComputeClient(cfg)
inst = oci.pagination.list_call_get_all_results(
    compute.list_instances, compartment_id=cpt
).data

targets = [i for i in inst if (i.freeform_tags or {}).get("env") == "staging"][:5]
print("PLAN:", [t.display_name for t in targets])

DRY = True
if not DRY:
    for t in targets:
        compute.instance_action(t.id, "STOP")
        print("STOP requested:", t.display_name)

That is the whole vibe: selection is explicit, limit is enforced, dry-run is the default.

The guardrails that matter:

Dry-run first: print what you will touch before you touch it.
Hard limits: scripts should have a brake pedal.
Target by tags/compartments: never “whatever matches this name.”
Verify: do not assume an API call means the system is now correct.
Summaries over spam: I want “5 succeeded, 1 failed” with names, not 400 lines.

Why this works for me

OCI is not the hard part. The hard part is doing the same actions repeatedly without slowly inventing new mistakes. Python lets me take the steps I already trust and make them consistent: ask, plan, apply, verify, and keep receipts.

What I miss in My Campus Job

Mon, 16 Feb 2026 00:00:00 GMT

If you know me personally, you might now that I work at University of Chicago Computer Science Instructional Laboratory (CSIL). Do I like working there? Absolutely. I feel like I did well, learnt a lot, accomplished more and made CSIL better for the staff and users. I play a huge role in almost all deployments, debugging any problem and try to help everyone, even if they don’t ask for it. I became the person people depend on a lot.

Why you might ask?

Because I like CSIL. I like its people and the meaning it has. But as I was talking to a friend of mine today (who also works there), I realized that I am the person people go to when they need something. And that’s it.

A quick answer. A fix. A hand with a task. Something unstuck. I get the message, I respond fast, I do the thing.

And then the moment passes, and I am back to being invisible. It kinda feels like the Genie from Aladdin, not in ability for sure but in loneliness.

When I was talking to my friend about that, he said it is because I am not csil material. This actually ddd hurt more than I thought because I know it is True. Afterall, I am not excluded in an obvious way. No one is rude. No one is hostile. It is more like: I exist as one of the services I maintain. I get pulled into the conversation for utility and done. That is it.

I do not even know if this is on them or on me, which makes it harder.

Maybe they already have their people. Maybe I joined late and everyone has history. Maybe I come off too intense, or too quiet, or too something. Maybe I am imagining it. Maybe I am not. The worst part is not knowing, because not knowing turns every interaction into self-doubt. And that could be because I am not csil material.

It does feel bad. I put so many hours in this place, most of my second and third year in college was spent on this. Many nights were spent making sure thinks work good, better, best. I definitely have missed on a lot of things (school clubs, organization, relationships, other jobs, etc) to be the best version of me at CSIL.

And now, about two years later, I wonder if this was all for nothing. Like sure, I learned a lot, things I otherwise would’ve not been exposed to. I learned how to work in a team, how to lead team(s), how to teach, and more from CSIL. I learned so much that I can’t imagine a version of me without CSIL. It is that deep. But I came to CSIL for the community, and it seems that I have nothing of that. I am sure after I graduate, I will not be remembered here, which makes me wonder if there is even a reason to stay.

And the thing is, I do want to belong. Not in a dramatic way. Just in a normal way. To feel like my presence is wanted even when I am not solving something.

Instead, I feel stuck in this role: the “ask him when you need help” person. the “ask him when you want something deployed”

It is a clean role. It might even be flattering on paper. But it is lonely in practice. Because if the only time people notice you is when they need something, you start asking yourself a bad question: if I stop being useful, do I not exist in CSIL?

I do not have a neat conclusion for this. I am still in it.

Right now, I am thinking of the sunk-cost fallacy which states

a cognitive bias causing people to continue an endeavor—such as a failing project, bad relationship, or poor investment—solely because of resources already invested (time, money, or effort)that cannot be recovered.

Maybe the reason I am not leaving CSIL is because I have put my (arguably) best years of college in it, I invested too much to leave. But maybe I should.

Nesbitt's Inequality and I

Sun, 15 Feb 2026 00:00:00 GMT

For some unknown reason, I really really like Nesbitt’s inequality, and I want to share (and know) why.

What Is It?

Nesbitt’s inequality states that for all $a,b,c>0$ ,

\frac{a}{b+c}+\frac{b}{c+a}+\frac{c}{a+b}\ge \frac{3}{2}.

This is actually pretty interesting if you think about it. No matter what positive numbers you choose, how different they are, big small, medium, the equation will alwasy be greater than or equal $\frac{3}{2}$ .

Intuition

First time that I saw this, I thought something wrong with it, like surely you can break it somehow.

So I tested it mentally with some numbers.

If $a=b=c$ , then each term is $\frac{a}{a+a}=\frac12$ , so the sum is $\frac32$ . Okay.
If $a=100$ , $b=c=1$ , then

\frac{100}{1+1}+\frac{1}{1+100}+\frac{1}{100+1} =50+\frac{1}{101}+\frac{1}{101} >50.

Still $\ge \frac32$ . Not even close.

At this point it stops being “maybe it’s false” and turns into “why does it refuse to go below $\frac32$ ?”
That’s the part I love: it feels like there’s some invisible floor.

Each Term is “Half Plus Something”

Here’s a little rewrite that makes Nesbitt feel less like black magic.

Notice that

\frac{a}{b+c} =\frac{a}{(a+b+c)-a}.

Let $s=a+b+c$ . Then each term is $\frac{a}{s-a}$ . If $a$ is big, then $s-a$ is small, so that term explodes. If $a$ is small, then $s-a$ is basically $s$ , so the term shrinks.

So the terms “trade off” with each other: one getting huge forces the others to be small, but not too small in total. There’s always enough leftover mass in the cycle to keep the sum from dipping.

Proof

This is the cleanest proof I know, and it’s basically one inequality wearing a trench coat.

We use Cauchy–Schwarz:

\frac{x_1^2}{y_1}+\frac{x_2^2}{y_2}+\frac{x_3^2}{y_3} \ge \frac{(x_1+x_2+x_3)^2}{y_1+y_2+y_3} \quad\text{for } y_i>0.

Now set

x_1=a,\;x_2=b,\;x_3=c, \qquad y_1=a(b+c),\;y_2=b(c+a),\;y_3=c(a+b).

Then

\frac{x_1^2}{y_1}=\frac{a^2}{a(b+c)}=\frac{a}{b+c},

and similarly for the others. So the left-hand side becomes exactly our Nesbitt expression:

\frac{a}{b+c}+\frac{b}{c+a}+\frac{c}{a+b} \ge \frac{(a+b+c)^2}{a(b+c)+b(c+a)+c(a+b)}.

Now simplify the denominator:

a(b+c)+b(c+a)+c(a+b) =ab+ac+bc+ab+ac+bc =2(ab+bc+ca).

So we have

\frac{a}{b+c}+\frac{b}{c+a}+\frac{c}{a+b} \ge \frac{(a+b+c)^2}{2(ab+bc+ca)}.

Now the only thing left is to show

\frac{(a+b+c)^2}{2(ab+bc+ca)}\ge \frac32.

Cross-multiply (everything is positive so it’s safe):

2(a+b+c)^2 \ge 3\cdot 2(ab+bc+ca) \quad\Longleftrightarrow\quad (a+b+c)^2 \ge 3(ab+bc+ca).

Expand the left:

a^2+b^2+c^2+2(ab+bc+ca)\ge 3(ab+bc+ca).

\Longleftrightarrow\quad a^2+b^2+c^2 \ge ab+bc+ca.

And that last inequality is always true, because

a^2+b^2+c^2-ab-bc-ca =\frac12\big((a-b)^2+(b-c)^2+(c-a)^2\big)\ge 0.

And we’re done:

\frac{a}{b+c}+\frac{b}{c+a}+\frac{c}{a+b}\ge \frac32.

When Do We Get Equality?

Equality happens exactly when $a=b=c$ .

You can kind of feel it:

If one of them is bigger, one term jumps up.
If one is smaller, the other terms “cover” for it.
The only way to sit exactly on the floor $\frac32$ is to make everything perfectly balanced.

So the minimum is not some weird corner case. It’s the most symmetric case possible.

Why I Think I Like It

Nesbitt’s inequality is one of those results that looks like it’s about fractions, but it’s really about balance.

It says: no matter how you distribute “weight” among $a,b,c$ , the cyclic structure refuses to let the total collapse. Symmetry is the minimum, chaos only pushes the sum upward.

And I don’t know, there’s something comforting about an inequality that’s basically saying:

you can try to ruin it, but it only gets bigger.

Ok, we're using C++ in Leetcode...and that's it?

Sun, 15 Feb 2026 00:00:00 GMT

I learned C++ and… I barely use it.

Not because I dislike it. Actually, I like C++. I like how explicit it is. I like the control and freedom it gives me.

But if I’m being honest, my C++ usage today is basically:

LeetCode. And that’s it.

Meanwhile, languages like Python and Go somehow keep showing up in my real life.
Python is the “just get it done” language, usually where I want to automate something, write a script or simply don’t have that much time.
Go is the “this should be a service” language—clean tooling, simple deployment, straightforward concurrency.

C++? It’s the language I learned and leetcode with it when I want something from the Algorithm library.

Why this happens (I think)

There is no good package manager in C++. I used vc, cmake, pixie and more, nothing actually feels good or “native”. This result in a severe complexity cap on my projects, for someone like me that enjoys using new tools all the time I don’t really blame C++ as a language for that but I absolutely blame the committee tasked with maintaining it.

Counterpoint

Some folks could counter that C++ never needed a good manager “because it is a tool you need for speed, low latency, so most code will be code that you (or your company) wrote which is easy to import and use” and that might be true actually. But it still does not change my experience with the language. I am not a trader for a reason, not because I don’t want to make money but because I like playing with new tools, and C++ definitely does not make that easy for me.

The weird part

C++ is the one that took the most effort to learn, and the first language I learnt purely from books, rather than video tutorials. I am far from a professional, but I probably can have a good knack at it. Unfortunately, that could be why I treat it like it needs a “big reason” to exist.

And most days, I don’t have that big reason—so I default back to what’s convenient, usually python.

Going forward

I think I will try using C++ to write good algorithms and visualize them with Pythons. I’ve been thinking of doing Kirchhoff’s theorem visualizer a while ago, so maybe C++ for the actual logic and Python to nicely visualize it, We will see.

6 Reasons Why I Love Nix

Sat, 14 Feb 2026 00:00:00 GMT

I found out about Nix from a good friend of mine. First time I heard about was thinking why would someone put so much trouble for little beneift but now that I have been running it for a year, I can’t imagine my dev life without it. Here are 6 reasons why.

What is Nix?

Nix is an OS, a package manager and build system that treats your software environment as code. In this blog, we will use the latter two in a way that allows you to describe exactly what you need (packages, versions, tools), and Nix builds it in isolated, reproducible paths, so the same config produces the same environment across machines.

1) Reproducibility that actually stays reproducible

Pin nixpkgs and your environment stops drifting: today, next month, and on a totally different machine. You can actually use this feature for your projects and rid yourself of dependency hell.

2) No more dependency errors.

Nix installs packages into isolated paths, so versions can coexist without stepping on each other. Upgrading one thing does not quietly break three others.

3) One config rebuilds my whole setup (homelab included)

This is the part I love: I can take a blank machine and rebuild it from config: packages, services, users, settings. Same approach for laptops, servers, and homelab nodes.

warning I did notice though that it does use a surprising amount of storage, so I’d recommend using Nix for this purpose only if you have enough space in your computer.

4) Dev shells that do not pollute the system

nix develop / nix-shell gives me project-specific environments (exact language versions, system libs, tooling). Exit the shell and my base system is untouched.

5) Rollbacks that feel like a superpower

On NixOS, if an upgrade or config change goes sideways, I can reboot into the previous generation and I am instantly back.

6) Less fragile infra (and better for teams)

Shared configs make onboarding: clone repo → enter shell → run. Plus caching/binary caches mean fewer rebuilds and fewer “it broke because something updated overnight” surprises.

Example

Nix optionally uses something called flakes to make sure your inputs (soruces) are consistent and right now is the modern nix setup. While I might explain how to kickstart nix in another blog, here is a little example of a flake.nix file to investigate.

{
  description = "Reproducible dev shell (Node + Python + Go)";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };
      in
      {
        devShells.default = pkgs.mkShell {
          packages = with pkgs; [
            nodejs_20
            pnpm
            python312
            python312Packages.pip
            go_1_22
            git
          ];

          shellHook = ''
            echo "Entered Nix dev shell"
            echo "node: $(node --version)"
            echo "pnpm: $(pnpm --version)"
            echo "python: $(python --version)"
            echo "go: $(go version)"
          '';
        };
      });
}

How uv Changed Python Coding for Me

Sat, 14 Feb 2026 00:00:00 GMT

Python used to come with this annoying warm-up ritual: make a venv, install stuff, discover something conflicts, and then somehow it works on this machine but not the next one. uv basically removed that entire category of pain. It makes Python feel fast, predictable, and honestly more serious as a day-to-day dev tool.

1) I start projects correctly by default

Before uv, spinning up a python script was directly proportional to how many packages it uses. Now I can spin up a clean project in seconds, so I actually keep things organized.

Something like this, for example, feel way clear than using plain Python workflow.

uv init
uv add requests rich # Adds new deps
uv sync # Installs previously defined deps
uv run python -c "import requests, rich; print('ready')"

2) Pyproject for Deps >>>>> requirements.txt

If you have ever used a requirements.txt, you know it kinda sucks. Mostly because people (me included) do pip freeze and dump everything in there, and now you have zero clue what you actually chose vs what got pulled in indirectly.

uv is not the only tool that fixes this, but I genuinely love how it keeps pyproject.toml clean and intentional. Every time I add a dependency or tweak config, it updates the file for me. So when I come back to a project months later (or I am reviewing someone else’s), I can instantly tell what I meant to install and what version range I wanted: no archaeology, no guessing, no “why is this even here?”

3) I do not “activate venvs” anymore

I used to keep multiple terminals open just to avoid activating the wrong environment. Now I just run commands through uv and it always uses the right project context.

uv run python app.py
uv run pytest -q
uv run ruff check .

4) Way faster than similar tool

It is way faster than pip, but, even better, it is way faster than other tools that promise the same functionality. I have used

poetry
pipenv
pixi
pipx

Nothing actually compares to uv in terms of speed.

Final Thoughts

I can’t imagine python development with out a tool like uv to be completely honest. It has everything that I needed, and I don’t forsee leaving it anytime soon.

Hello World

Thu, 12 Feb 2026 00:00:00 GMT

This is my first post.

Ziad.dev | Blog

My Microsoft Internship

Early Period

Housing situation

Middle Period

Late Period

Review

Making My Own Python Linter: Pyleft

No Plugin System

Unpythonic Warnings

It Is Very Slow

Introducing Pyleft

Where Should Secrets Live, and Why It Should Not Be in Your Config

Secrets and Config Are Not the Same Thing

Everyone Has This Problem, Even NixOS

password_file >>>>> Password in Your Config

AI Loves Shoving Secrets Into Your Config (Especially with Pydantic)

So Where Should the Secrets Actually Live

What to Do if You Already Leaked One

Final Thoughts

What I think about the World Getting Its First Trillionaire

Most of This Money Doesn’t Really Exist

”Why Doesn’t He Just End World Hunger?”

He Built These Companies

So What Do I Actually Think?

What Math Says About Consistency vs. Clutch Moments

The Proof

So What?

Feelin' Functional

Why I like Haskell

Monads

Pure functions are just nice

Why it stuck with me

Review of CMSC 23700: Computer Graphics

What is Computer Graphics?

Why is it useful?

What I did in the class

Project 1: Rasterization

Project 2: 3D Rasterization Pipeline

Project 3: Mesh Editing

Project 4: Rigging and Skinning

Final Project: Animation and Deformation

Final Thoughts

My Final Project Submission.

Making Food for 15 people: Ramadan Edition

Macarona béchamel

Chicken

Salad

Konafa

Right before iftar

Ranking Zero-Calorie Drinks

7) Cherry Cola

6) Monster

5) Celsius

4) Coca-Cola Zero Sugar

3) Pepsi

2) 7UP

1) Dr Pepper Zero Sugar

My Neovim + LSP Setup (Lazy.nvim + Nix/Home Manager)

Layout

LSP

Completion

Treesitter

Daily-driver plugins

Language extras

Reproducibility notes

Wanna Check It Out?

Powerlifting, and Why I Am Still Doing It

Current Numbers

Python for Oracle Cloud Infrastructure (OCI)

Setup (the normal way)

One small script I actually keep around

The guardrails that matter:

Why this works for me

What I miss in My Campus Job

Nesbitt's Inequality and I

What Is It?

Intuition

Each Term is “Half Plus Something”

Proof

`password_file` >>>>> Password in Your Config