<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Engineering on Kianoosh's Blog</title><link>https://kianoosh.dev/tags/software-engineering/</link><description>Recent content in Software Engineering on Kianoosh's Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Fri, 13 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kianoosh.dev/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>TypeScript: The Illusion of Structure</title><link>https://kianoosh.dev/posts/2026-02-13-typescript-the-illusion-of-structure/</link><pubDate>Fri, 13 Feb 2026 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2026-02-13-typescript-the-illusion-of-structure/</guid><description>&lt;p>It’s been around seven years since I started coding with JavaScript, and for the last two years I’ve been working almost exclusively with TypeScript for backend development. Sometimes relationships just don’t work out — and I’m starting to feel that JavaScript and TypeScript are simply not a good fit for backend systems when projects become serious and complex 🔒&lt;/p>
&lt;p>As soon as you try to do anything non-trivial with your ORM, things start getting messy — and it doesn’t really matter whether you’re using TypeORM or Prisma. The moment you need “ORM magic” like sharing transactions across repositories, handling nested soft deletes, or coordinating complex lifecycle behavior, you find yourself fighting the abstractions rather than benefiting from them.&lt;/p></description></item><item><title>Software Modularity: Trivial Concept, Yet Still Rarely Done Right!</title><link>https://kianoosh.dev/posts/2026-01-07-software-modularity-trivial-concept-yet-still-rarely-done-right/</link><pubDate>Wed, 07 Jan 2026 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2026-01-07-software-modularity-trivial-concept-yet-still-rarely-done-right/</guid><description>&lt;p>If you&amp;rsquo;ve ever read any software engineering blog or book, you&amp;rsquo;ve probably seen the word &lt;strong>&amp;ldquo;Modularity&amp;rdquo;&lt;/strong> mentioned many times. But ask most engineers what modularity really means, what benefits it brings, and how to actually break a system into modules — and you&amp;rsquo;ll often get vague or unclear answers.&lt;/p>
&lt;p>To find clear and timeless answers, we need to go back to the 1960s and 70s, when these ideas were first introduced and refined. In his famous 1972 paper (over 8,000 citations and still cited 250+ times in 2025!), David Parnas tackled a problem that was unsolved until then: &lt;strong>the criteria for decomposing software into modules.&lt;/strong>&lt;/p></description></item><item><title>Engineering for Exabytes: Lessons from IBM COS</title><link>https://kianoosh.dev/posts/2025-12-29-engineering-for-exabytes-lessons-from-ibm-cos/</link><pubDate>Mon, 29 Dec 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-12-29-engineering-for-exabytes-lessons-from-ibm-cos/</guid><description>&lt;h2 id="beyond-standard-storage">Beyond Standard Storage&lt;/h2>
&lt;p>After &lt;a href="https://kianoosh.dev/posts/2025-12-28-open-source-is-not-enough-the-post-minio-era">my last post&lt;/a> on the MinIO shift, I started going down the rabbit hole. We often take object storage for granted, but when you step back and ask, &lt;em>&amp;ldquo;How do you actually manage data at an Exabyte scale?&amp;rdquo;&lt;/em>, the answers get fascinating.&lt;/p>
&lt;p>How do you design a system that reaches 15-nines of durability without bankrupting the company on hardware?&lt;/p>
&lt;p>I recently found an IBM Redpaper on their Cloud Object Storage (COS) that peels back the layers. It explains the engineering choices required to operate at that magnitude.&lt;/p></description></item><item><title>Open Source is Not Enough: The Post-MinIO Era</title><link>https://kianoosh.dev/posts/2025-12-28-open-source-is-not-enough-the-post-minio-era/</link><pubDate>Sun, 28 Dec 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-12-28-open-source-is-not-enough-the-post-minio-era/</guid><description>&lt;h2 id="the-end-of-the-default-choice">The End of the &amp;ldquo;Default&amp;rdquo; Choice&lt;/h2>
&lt;p>For years, MinIO has been the reflex choice for S3-compatible object storage in Kubernetes setups, SaaS platforms, and data lakes. It was the standard we all reached for.&lt;/p>
&lt;p>However, recently (December 3, 2025), the landscape shifted. MinIO officially moved into &lt;strong>maintenance mode&lt;/strong>. This means no new features and, critically, community pull requests are no longer being merged. The development focus has shifted entirely to their commercial offerings.&lt;/p></description></item><item><title>The Maintenance Cliff: LLMs and the Learning Loop</title><link>https://kianoosh.dev/posts/2025-12-25-the-maintenance-cliff-llms-and-the-learning-loop/</link><pubDate>Thu, 25 Dec 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-12-25-the-maintenance-cliff-llms-and-the-learning-loop/</guid><description>&lt;h2 id="the-assembly-line-fallacy">The Assembly Line Fallacy&lt;/h2>
&lt;p>In our industry, there is a persistent temptation to treat software engineering like an assembly line. We constantly aim to abstract work into higher-level languages, reusable components, and &amp;ldquo;black box&amp;rdquo; services to increase velocity.&lt;/p>
&lt;p>In a recent article on MartinFowler.com, &lt;strong>Unmesh Joshi&lt;/strong> critiques this tendency. He argues that this efficiency-obsessed approach clashes with the most fundamental property of our work: &lt;strong>learning&lt;/strong>.&lt;/p>
&lt;p>When we rely entirely on readymade solutions without understanding the &amp;ldquo;why&amp;rdquo; and &amp;ldquo;how&amp;rdquo; underneath, we treat code as a static asset rather than a dynamic expression of knowledge.&lt;/p></description></item><item><title>Discipline Under Pressure: Shipping Without Messing Up</title><link>https://kianoosh.dev/posts/2025-08-20-discipline-under-pressure-shipping-without-messing-up/</link><pubDate>Wed, 20 Aug 2025 00:00:00 +0000</pubDate><guid>https://kianoosh.dev/posts/2025-08-20-discipline-under-pressure-shipping-without-messing-up/</guid><description>&lt;p>&lt;img src="https://kianoosh.dev/images/squid-game-umbrella-cookie-1536x913.jpg" alt="squid game umbrella cookie">&lt;/p>
&lt;h2 id="the-reality-of-urgency-in-startups">The Reality of Urgency in Startups&lt;/h2>
&lt;p>It’s crucial for every senior software engineer, technical leader, or anyone accountable for delivering technical solutions to know how to handle urgent tasks wisely. Let’s call this person a &lt;em>leader&lt;/em> — and today, that’s you.&lt;/p>
&lt;p>In some industries, or at certain stages of a company’s lifecycle, urgent requirements hit technical teams constantly. I currently work as a technical lead at a startup (&lt;a href="https://www.linkedin.com/company/donetech/">Done&lt;/a>), where the rules of the game seem to change every other week.&lt;/p></description></item></channel></rss>