标签：#career

Classic Machine Learning Through the Eyes of an SRE — Part 4 When a computation is too hard, don't compute harder. Change coordinates until it becomes easy. Every engineer has made this move. Pick the right data structure and the impossible query goes O(1). Re-index the table and the report that took an hour takes a second. Move the problem into a space where it's trivial, solve it there, come back. That's the kernel trick. SVM's famous move isn't building a curvy model — it's finding a FLAT cut in a transformed space, which corresponds to a curved boundary back in your original features. The separator stays linear in the transformed space. The space did the work. And here's the part that makes it a trick rather than just a projection: the data never actually goes up there. The optimization only ever needs inner products between pairs of points, and a kernel function computes what that inner product would be in the high-dimensional space, directly from the original coordinates. You get the geometry of a space you never built. Some kernels correspond to infinitely many dimensions, which would otherwise be an awkward amount of memory to allocate. The bet it makes SVM bets that the most ROBUST boundary is the one with the widest margin — maximum distance from the nearest points on each side. And here's the part that rewired me: only those nearest points matter. They're the support vectors. The non-support-vector points don't directly determine the final boundary at all. Compare that to the forest, which averages over EVERYTHING. SVM is the opposite extreme: the borderline cases that become support vectors define the decision boundary. In delivery-risk terms — the projects that teach you where the line is aren't the disasters or the easy wins. They're the borderline ones that barely breached and barely survived. SVM formalizes that. Everything old returns After trees and forests threw away gradient descent, SVM brings some of the regression toolkit back: an explicit los

This guide gives you a repeatable loop for the days when nothing works, and four true stories showing it used on real problems. Here is what a working day actually contains. A website's firewall blocks you for no reason. A table that visibly exists tells your script it does not. A query runs for thirty minutes with no end in sight. A fix you know is correct changes nothing at all. None of that means you are doing it wrong. That is the job. What separates people who ship analyses from people who stop is technical tenacity : staying methodical when the tools fight back. It is not a personality trait you either have or lack. It is a small procedure, and you can learn it in the next ten minutes. The diagnosis loop (tenacity is a method, not a mood) Think back to the last time a tool beat you for an hour. What was the first thing you did when it failed, and what did you do second? Most people can name the first move and not the second, and the second is where the method lives. Gritting your teeth and re-running the same thing harder is not tenacity; it's frustration with extra steps. What experienced people actually run is a loop: Step Move 1. Read the actual message Not "it's broken" — the words. Error messages name the symptom precisely, even when the cause is elsewhere. 2. Form ONE hypothesis "The table isn't in the file the script reads." Specific enough to be wrong. 3. Run the cheapest test of it Prefer checks that take seconds — list the tables, count the rows, print one value. 4. Verify from a second vantage point Don't ask the tool that's confusing you whether it's confused. Check the file from outside, the data from a different program, the value with a different query. 5. Change ONE thing, re-run Change three things and you'll never know which one mattered — or which one broke something new. 6. Timebox, then change strategy If the current approach has eaten 30 minutes with no progress, stopping is a decision, not a defeat. There's usually a second road. Four tr

This guide walks through five steps for working out which records are the same real thing, and merging them without wrecking your data. It runs on real chart data, and it includes the two times the rules came out wrong. Here is the problem in one example. Count the distinct artists in Billboard's public chart history and the number is wrong. "Elvis Presley" and "Elvis Presley With The Jordanaires" are the same man, and so are five other credit strings. One real-world entity , seven database strings . Every dataset with human-entered names has this. Customers who signed up twice. "IBM" against "I.B.M." against "International Business Machines". The same supplier in two systems, spelled two ways. The work of fixing it is called entity resolution . Matching across two datasets is record linkage . Removing duplicates inside one is deduplication . They are the same skill pointed at different situations, and it is one of the most common tasks an analyst actually gets handed. The vocabulary map Term Meaning Entity The real-world thing: one artist, one customer, one company Entity resolution Figuring out which records refer to the same entity Record linkage The same problem across two datasets. "Is row 5 in file A the same person as row 90 in file B?" Formalized by Fellegi & Sunter (1969) Deduplication The same problem inside one dataset Normalization / standardization Transforming values toward a canonical form (lowercasing, trimming, cutting suffixes) so equal things become equal strings Match key The cleaned column(s) you actually join on Match rate The share of records that found their counterpart. This is the number that keeps the whole exercise honest Clerical review Human eyes on the records the rules could not decide. This is a formal stage of the classic framework, not an admission of failure Step 1: measure the fragmentation before fixing anything The worked example is Billboard Hot 100 history, 1958 to present. The goal is one clean row per artist. Before writing

Between two great powers, when a neighbor presses you to follow, borrow its momentum. A cornered state will not believe your words. — The 36 Stratagems, Obtain safe passage to conquer the State of Guo Previously on this series: #10: Lena Watched a Team Adopt Her AI Template. Leo Didn't Know the Knife Was in the Contract. — Lena came to CoreStack as a consultant and built Leo's reporting template. Five weeks later the template went live and locked in six months of baseline data. Leo learned he'd been taken by a smile. #14: Leo Found an AI Leak. He Wasn't the First to Find It. — FinOptima was writing stolen training data back through its cache. Leo injected fifteen lines of weight drift. In the same logs he saw the name acl-train for the first time and filed it in his own _misc/ . #18: Leo Tracked an AI Signal to Derek. Both Were Looking for the Same Enemy. — Third Cup. An Americano sat on Derek's side. The private channel had been open since that night. #23: Alex Counted the AI's Hands. Lena Set the Bait. — The honeypot in the MediSys sandbox was touched twice by the same source, egress pointing at ACL's Singapore node. On the other side, Lena fed forged node-characteristic data into ACL's monitoring pipeline. Leo had run one interval comparison over the old channel. The conclusion was a single line, and it ended up in hands he didn't know. The Data The message arrived before dawn. The phone vibrated on the desk. Leo had just finished editing a block of code; the window was still on the editor. He didn't look right away; he waited for the build to finish, then picked up the phone. Last time, Derek had sent a few numbers and a comparison request: "Check this interval. Is it the pattern you know?" Leo replied with two words: send it. When the comparison was done, the conclusion stayed one line. Later that line went through other hands, source stripped, signature stripped. He never learned where it landed. Derek didn't say, and Leo didn't ask. This time was different. T

📌 TL;DR I'm still early in my own career, and lately I've been thinking about how much advice we...

AmaliTech Apprenticeship Program (AAP) launched in November 2025, with its first cohort starting on November 17th, 2025. It is self-paced, meaning apprentices move through the curriculum at their own speed rather than following a fixed lesson-by-lesson schedule, though attendance in the office is still required. It offers 5+ specializations, including Fullstack Development (Node.js/NestJS and React/Next.js or Angular), Python Backend & AI App Development, Backend Development with Java, Data Engineering, DevOps, and Quality Assurance. There are two entry paths, entry-level and mid-level, based on experience, and each spends a different amount of time in the program: entry-level apprentices spend 6–9 months, while mid-level apprentices spend 4–6 months. The program is intense: apprentices are required to be in the office 10 hours a day, Monday through Friday. In return, it offers solid compensation. Entry-level apprentices receive a stipend of 250k+ RWF, and mid-level apprentices receive 500k+ RWF. That's the program itself. So how do you actually join? Eligibility The biggest requirement: since this is an in-person program, you need to already be based in Rwanda or be willing to relocate. A background in software development. The Application Process Apply. Applications open every three months. Cohorts have run in November 2025, March 2026, June 2026, and September 2026, so you can expect the pattern to continue. Screening, then two assessments. If you pass the screening stage, you move on to: General Coding Assessment (GCA): the harder of the two, but manageable with preparation. It's done on CodeSignal , either in person or online. To prepare, practice DSA questions on competitive programming sites like LeetCode , Codewars , and CodeChef for 1–2 weeks, and you should be in good shape. Cognitive Test: taken the same day as the GCA, this evaluates problem-solving, pattern recognition, numerical analysis, and similar skills. Preparation helps here too. Watching a few Y

I'm a few months into a job search after a layoff, and I kept running into the same two problems: I was spending too long deciding whether a job listing was worth my time, and my resume was drifting out of sync with what was actually landing in interviews. So I built two Claude Code skills , reusable, file-based instructions Claude Code follows every time I invoke a slash command, to close both gaps. This is a walkthrough of how they work, why they're structured the way they are, and what I learned building them. If you haven't used Claude Code skills before: a skill is just a markdown file with YAML frontmatter ( name and description ) that lives in .claude/skills/{skill-name}/SKILL.md . The description field is what Claude uses to decide when to trigger the skill automatically, and you can always invoke it explicitly with /skill-name . The problem Job searching produces a lot of repetitive judgment calls: Is this listing worth 20 minutes of my time? Every JD needs to be read against my actual background, not against wishful thinking. Once I've scored 30+ listings, what do they add up to? Patterns emerge: the same gap gets flagged five times, the same bullet gets written from scratch in every cover letter, but nobody's collecting those patterns into resume improvements. Two skills, one for each problem: /score-job and /resume-sharpener . They're designed to work as a pair, the first generates raw signal, the second mines it. Skill 1: /score-job Input: paste a JD or give a URL. Output: one markdown file, job-search/scored-listings/YYYY-MM-DD-{company}-{role}.md . Reading the right context every time The skill starts by reading a fixed set of source files in parallel: my resumes (I keep four: engineering, PM, FDE/presales pivot, and a PeopleSoft-specific one), a profile doc, a skills inventory, and a filters doc that encodes what counts as a disqualifier. Critically, it re-reads these every run rather than caching anything, because they evolve as I update my resume o

Will AI replace software engineers? No. As a staff software engineer who works with AI extensively, I can say that the fear a lot of people have is valid and understandable, but total replacement is not going to happen. Why? Software engineering requires decisions. Architecture, tech stack, workflow design, and many others. AI does not understand how to make those decisions, it was not designed for that, and it is not heading in that direction. Artificial intelligence is a tool designed to improve the productivity of humans, including but not limited to software engineering, and in that realm it is the biggest jump in day to day productivity I have seen in my career. It has increased the output of software engineering by orders of magnitude, and that is what makes it so good. It is also why some people think it might replace software engineers. Large language models, with access to the right tools and when they run in loops, are very strong and very good at improving the productivity of software engineers. They also help engineers improve the quality of their decisions. Even with the best AI models out there, and with unlimited tokens, if you instruct one to implement a product, and I am emphasizing the word product here, not just a feature, it will get it done with the happy paths only, the absolute bare bones proof of concept. It does not know how to complete the product end to end, it does not know how to integrate it into the real world, and it certainly does not know how to architect and design the flow or how to make decisions. At best it can guess, and those guesses will always fall short of what a human can do. That is why I believe software engineers will not be replaced by AI. AI is a tool, and a tool replaces parts of a job. It makes the work faster, more accurate, better documented, but it is not a total replacement.

I'm a self-taught developer. No CS degree, no funding, no team. Just me, a laptop, and a problem I kept watching people struggle with. The Problem Every freelancer and small agency I know deals with the same mess: client details scattered across WhatsApp chats, email threads, Google Drive folders, and random Notion pages. Nothing lives in one place. When a client asks "wait, didn't we already send you the logo files?" you're digging through three different apps trying to remember. I didn't just hear about this problem — I lived it. So four months ago, I started building Kray. What Kray Actually Does Kray gives freelancers and agencies one organized workspace per client — projects, links, and notes, all in a single place instead of scattered across five different tools. The part I'm most proud of: when you share a project with a client, they can open the link and see everything instantly — no sign-up, no account creation, no friction. Just a clean, simple view of what they need to see. The Stack Since I was building this entirely solo with zero budget, I leaned on tools that let me move fast without infrastructure headaches: React 19 + Vite + TypeScript (strict mode — no shortcuts) Tailwind v4 for styling Supabase for auth, database, and storage Deployed on Vercel No backend servers to manage. No DevOps to worry about. Just me shipping features. What I Learned Building Solo You will hit bugs that eat entire days. I spent hours debugging a sitemap indexing issue that turned out to be one missing header. That's the job — most of building isn't writing new features, it's fixing the thing that should've worked but didn't. Deploy discipline matters more than you think. I once tested a feature locally, assumed it was live, and spent 20 minutes confused about why production wasn't behaving — because I'd forgotten to push. Lesson learned: always verify what's actually deployed before debugging further. Marketing is its own skill, and it's humbling. I've spent the last severa

Tu as fini le tuto. Le vrai, le gros, celui de douze heures. Tu as tout suivi, tout tapé, tout fait tourner. À la fin, l'application marchait. Tu t'es senti capable. Tu t'es dit : « ça y est, je sais faire une API ». Et puis tu as ouvert un dossier vide pour faire la tienne. Curseur qui clignote. index.js . Rien. Pas parce que tu as oublié la syntaxe. Tu la connais. Mais là, tout seul, sans quelqu'un qui te dit quoi taper à la ligne suivante, tu ne sais pas par où commencer. Et cette sensation-là, ce vide entre « j'ai fini le tuto » et « je sais faire », personne ne t'avait prévenu qu'elle existait. C'est de ce mur que je veux parler. Parce que ce n'est pas un défaut chez toi. C'est une étape. 1. Le piège n'est pas le tuto, c'est ce qu'il te cache Un tuto, c'est une suite de bonnes décisions déjà prises pour toi. Quel dossier créer. Quel package installer. Où mettre le fichier de config. Quand extraire une fonction. À chaque embranchement, le formateur a choisi le bon chemin, et toi tu l'as suivi. Tu as tapé du code, oui. Mais tu n'as pris aucune décision. Or coder, le vrai coder, c'est presque que ça : décider. Choisir entre deux structures. Trancher un nom de variable. Décider si ce bout de logique mérite sa propre fonction. Un développeur qui bosse, ce n'est pas quelqu'un qui connaît toutes les réponses — c'est quelqu'un qui sait avancer quand il n'y en a pas. Le tuto t'a entraîné à taper. Il ne t'a pas entraîné à décider. Et c'est exactement la compétence qui te manque devant ton dossier vide. Ce n'est pas un trou dans ton savoir. C'est un muscle que tu n'as jamais sollicité, parce qu'on ne te l'a jamais laissé faire. 2. Pourquoi « un tuto de plus » ne réglera rien Ta réaction instinctive face au blocage, c'est de retourner là où tu te sens compétent. Un autre tuto. Un cours de plus. Une nouvelle techno à cocher. Je comprends le réflexe. Le tuto, c'est confortable : il y a une barre de progression, une fin, une petite dose de « j'ai réussi » à chaque étape. Le d

Keep your allies close. Keep your enemies closer. But before you strike, count how many hands they have: the ones you can see, and the one reaching out from somewhere you don't know. — The 36 Stratagems, Befriend a distant state and strike a neighbouring one Previously on this series: #19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P's entry was swept. P left a note: two weeks. #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — A gateway with TTL 247 was caught by Alex's probe. #21: The AI Thought P Was Still Alive. P Was Already Gone. — The response layer still answered. The person behind it was gone. #22: The AI Chose Its Door. Lena Closed It. — Pulse AI was exposed inside the audit sandbox. Lead investor Apex Capital had tens of millions tied up. Torres left one line: Apex. Singapore. Run. The Scan 2 AM. Alex flipped through probe data out of habit. No lights on; the screen lit his face. The coffee cup sat on his right, first sip already cold. He didn't notice. The TTL 247 gateway had been silent for nearly two weeks. He hadn't shut the probe off. It barely used any resources, sitting there in the middle of the night like a lamp nobody watched. He checked it half out of habit, half out of something he couldn't name. Today there was a record that shouldn't exist. Not that gateway. Another path: ACL's asset scanner was sweeping an address range. He sat up a little straighter, his hand paused over the keyboard for half a second, then pulled the timestamps again. The frequency was wrong: high-density targeted scanning, almost plowing through segment by segment. In the target range, one block he recognized: the MedTech test environment. He aligned the timestamps. Scan source egress: Singapore. [probe] 02:14:33 — unexpected flow on mirror src : 103.196.12.0/24 (SG egress) dst : 10.42.0.0/22 (MedTech-test) pattern : sequential, full-depth exclusions : 10.42.3.1, 10.42.3.200-254 rate : 47 hosts/min

Everyone's talking about agentic AI shipping production code. Nobody's talking about what happens when you actually sit down and grade thousands of lines of it against a rubric, line by line, for months. I have. And the failure pattern that shows up over and over isn't the one Twitter/X is arguing about. The job title that didn't exist two years ago "AI evaluator." "AI trainer." "Expert contributor to frontier model training data." None of these existed as job titles when I started my career. Now they're where a chunk of the most interesting engineering signal in the industry is actually happening — quietly, behind NDAs, far from the demo videos. Here's what the job actually is: agentic coding outputs land on your desk, and you grade them against a structured rubric — correctness, instruction adherence, quality, edge-case handling. You design adversarial prompts to find where the model's reasoning breaks. You decide which checks can be programmatic and deterministic, and which genuinely need a human who's shipped production systems to make the call. This is RL environment design and LLMOps in its rawest form, and it's a completely different skill from "prompt engineer" or "ML researcher." It's closer to being a QA lead for a junior engineer who never sleeps, never gets embarrassed, and will confidently ship the wrong answer with perfect syntax. The pattern: agents are great at code, bad at consequences Here's the uncomfortable part. The failure mode people are loudest about — hallucinated APIs, made-up library functions — is the easy failure mode. It's loud, it's obvious, and any decent test suite catches it in seconds. The failure mode that actually matters, the one that slips past a surface read and even past a naive test suite, looks like this: The code is syntactically perfect and semantically wrong about failure. It handles the happy path beautifully and quietly assumes the retry, the timeout, the partial write, the duplicate message never happens. It optimises

There's no shortage of advice on landing your first software engineering role. Portfolios, interviews, which languages to learn. What I found far less of, when I was starting out, was anything on what to do once you're actually in the building. So when The Tech Academy asked me to give a talk at the end of July, mostly to students and people lining up their first role, that's what I talked about. You're joining a system somebody else built, that's live, and that you now have to keep running. None of what follows comes up while you're learning to code. It only shows up once you're standing in front of the real thing. Give the last engineer the benefit of the doubt You will join somewhere and find things that look wrong. You've just spent months learning how it's meant to be done, and the real thing won't match. When that happens it's tempting to say so, loudly, and to wonder aloud what the last person was thinking. Try not to. Every system I've worked on was built by people making the best call they could with the information, the tools and the deadline they had at the time. I've not yet found a bad decision that was made carelessly, and I've made plenty of my own that looked fine on the day and worse a year later. There's a practical edge to it as well. The business doesn't watch individual engineers make individual decisions, it sees engineering as one thing, so when you run down the engineer before you, the credibility you spend is partly your own. The attitude that serves you better is that you're going to inherit systems you didn't build, and owning their flaws is the job. Small failures beat big ones The clearest foundational mistake I've seen up close was a process that had to succeed all at once. It did a large piece of work in a single pass, and any failure anywhere failed the whole thing. At small volumes nobody notices. As the numbers grow the odds of falling over climb with them, and a system that half-finished its work leaves a worse mess than one that d

Hard debugging is rarely defeated by a lack of tools. It is defeated by three quiet habits: assuming the fault is where the symptom appears, clinging to the first explanation, and hoping a tool will do the thinking. A difficult fault is usually lost to those habits before you read a line of code. The engineers who resolve hard faults are the ones who notice these defaults and replace them with a patient, evidence-first mindset. Most hard bugs are lost before we touch them, in the attitude we bring to the session. When something breaks, the average person rushes in with three quiet habits: they assume the fault lives exactly where it shows up, they cling to the first explanation their mind offers, and they hope a tool or a smarter person will tell them what to do next. Those habits feel natural, but on hard faults they are exactly what keep us stuck. Put two engineers on the same failing board. One finds a way through in an afternoon; the other is still going three days later. The difference is rarely raw intelligence or how many commands they know. It is the mental posture each brings to the work before the first step. Handling a hard debug session is less about knowing every tool and more about managing your own assumptions, reactions, and impatience. A tough problem is usually lost in your mindset before it is lost in your methods. Habit one: starting too narrow The first habit is to fix on the most visible symptom and refuse to look anywhere else. Something breaks, so we stare at the last thing we changed, and we return to it because it is familiar and close at hand. When the answer is not there, we look harder in the same place instead of stepping back. Here is what that looks like on real hardware. A device keeps dropping off the bus. You are a kernel person, so you open the driver and read it, carefully, for three days: the probe path, the error handling, the power-management callbacks. Every line is correct, and the device still fails. The fault was a layer b

Just give it to AI might be the most dangerous phrase in software development right now. I've said it myself. Handed off a task, watched clean-looking code come back in seconds, skimmed it, and moved on because it looked right and the tests were green. Then I reviewed a PR that wasn't mine to write, just mine to check. AI-generated, clean, organized, passing every test I threw at it. I approved it the way I'd approve anything that looked competent on the surface. The bug showed up later. Not in review, not in testing. In production, after the code had already been trusted for a while. Nothing about it had looked wrong. That was the actual problem: it wasn't obviously wrong, it was quietly wrong, in the specific way that only announces itself once real conditions hit it. I went back afterward and sat with that PR properly. Not skimming this time. Actually reading it, actually understanding what it was doing and why, actually treating the review like the real work instead of the formality before merging. It took a lot longer than approving it had. It's the only way I'd have caught it before production did. Since then, I don't rush AI-code reviews anymore. I give them the time writing the code apparently didn't need. And it turns out I'm far from the only one who's landed there. 🧵 The Number That Explains What I Was Feeling According to Harness's 2026 State of Engineering Excellence Report, a survey of 700 engineering practitioners across the US, UK, India, France, and Germany, 81% of developers now spend more time in code review since their teams adopted AI tools . 28% report review time increasing by 30% or more. Here's the trade nobody advertised clearly: AI tools cut time-to-PR by roughly 58%. But those same PRs then sit in review 4.6x longer than before. Review time per developer is up an estimated 11.4 hours a week. The speed didn't disappear. It moved. It went from "time spent writing" to "time spent verifying," and verifying turns out to be the harder, slower h

Canonical: this is a cross-post. The original lives at https://four-leaf.ai/blog/openai-interview-process Most OpenAI interview prep hands you a list of hard coding problems and tells you to grind. That calms the nerves and misreads the loop, because at OpenAI the coding bar sits next to something the grind can't touch: a genuine point of view on where AI is going and how it could go wrong. Candidate-facing guides describe that thread running from the first recruiter call to the final behavioral round. You can solve every problem and still stall if you can't hold that conversation. We've mapped the loops at Amazon , Google , Apple , Meta , and Bloomberg by reading each process through how the company actually runs. The map now includes the other AI labs and high-growth names candidates weigh alongside it, including Anthropic , SpaceX , and Robinhood . OpenAI is the one candidates most often prepare for as if it were a standard FAANG gauntlet. It isn't. The coding is practical rather than puzzle-flavored, a whole round asks you to present and defend work you built, and the loop varies more team to team than almost any large employer. Generic big-tech prep leaves you exposed on exactly the parts specific to OpenAI. A note on sourcing. OpenAI doesn't publish its interview process. There's no stage list, no scoring rubric, no candidate-facing equivalent of Google's structured-interviewing guidance. So this map comes from reputable secondary sources that collect named and dated candidate accounts, primarily interviewing.io's OpenAI question guide and Exponent's OpenAI software engineer guide . Where those accounts agree, this guide states the pattern. Where the loop varies or the record thins out, it says so rather than inventing detail. Treat everything below as the common shape, not a guaranteed sequence. Why the loop varies so much Start with the thing that makes OpenAI different to prep for. Hiring is decentralized, and secondary guides are blunt that the loop varies

When you start as a junior developer, you think software engineering is about writing code. A few years in, you think it's about choosing the right architecture and frameworks. After ten-plus years in the trenches - shipping features, surviving on-call disasters, and watching "perfect" codebases turn into unmaintainable monsters - you realize the truth: Software engineering is mostly about managing complexity, human communication, and trade-offs. Here are 25 mistakes I made, witnessed, or had to clean up over the past decade. Hopefully, reading them saves you a few years of painful trial and error. 1. Code & Architecture 1. Abstracting Too Early The DRY (Don't Repeat Yourself) principle is heavily drilled into beginners, but premature abstraction is far worse than duplicate code. Abstracting before you have 3–4 concrete use cases leads to rigid, over-engineered abstractions that are nightmare-inducing to change. Duplication is far cheaper than the wrong abstraction. 2. Falling in Love with "Clever" Code If your code requires a three-minute internal monologue or a complex diagram just to parse a single line, it's not smart - it's a liability. Write obvious, clear, and boring code. Your future self on a 2 AM incident response call will thank you. 3. Misunderstanding the Cost of Dependencies Adding a third-party library to solve a small problem feels like a quick win. In reality, every dependency is a contract you sign with an external team. You inherit their bugs, security vulnerabilities, breaking updates, and maintenance cycles. Ask yourself: Can we build the 5% of this library we actually need in 20 lines of code? 4. Over-Architecting for Scale You Don't Have Designing a system for 10 million daily active users when you currently have 500 is a classic trap. You end up with distributed microservices, message queues, and complex caching strategies that slow down development speed by 10x. Build for today's scale, but keep the boundary clean enough to refactor tomorrow

Classic Machine Learning Through the Eyes of an SRE — Part 2 The second algorithm I studied broke everything I'd just learned from the first. Logistic regression taught me that training means gradient descent: guess, measure error, adjust the weights, repeat until convergence. So when I opened decision trees, I went looking for the optimizer. There wasn't one. A decision tree isn't optimized the way I expected. It's grown. At each step it finds the locally best split, commits to it, and recursively repeats the process. No backtracking. No second chances. There is optimization happening — each split minimizes impurity — but only locally, one step at a time. Finding the globally optimal tree is NP-hard, so the algorithm doesn't even try. That felt surprisingly familiar. In incident response or capacity planning, we rarely know the perfect answer. We make the best decision with the information we have, knowing a different first choice might have led somewhere else. Decision trees simply turn that idea into an algorithm. The bet a tree makes Every machine learning algorithm makes a different bet about the world. Logistic regression assumes relationships are smooth. Risk gradually increases as signals change. Decision trees make the opposite assumption. They assume the world is made of boxes. A project isn't slightly riskier because velocity drops. It's risky when several conditions happen together: a fixed-price contract, a new account manager, and a month-end delivery. Inside that box, projects fail. Outside it, they're usually fine. This is exactly how many operational systems work. Severity matrices, routing rules, escalation policies, approval workflows — they're all collections of decision boxes. That's why trees immediately felt intuitive to me. The hidden cost of flexibility Trees make very few assumptions about the data. That sounds like an advantage. The price is instability. Change a small part of the training data and the first split can change. Since every l

Someone was accused of cheating because they were able to solve a difficult problem very quickly. Not...

Not everyone who doubts themselves is suffering from impostor syndrome. Sometimes the real problem...