Fawad H Syed

💻 Analyst & Software Engineer Interested in Artificial Intelligence, analytics, and building useful technology. Follow me for thoughts on: • Artificial Intelligence • Data and analytics • Software development • Technology trends 🤝 Tech professionals — let us connect. I follow back. Geneva, Switzerland 🇨🇭 🔗 fawadhs.dev #AI #Data #Technology

While building an art auction platform, I realized the importance of persistent storage. The backend uploaded and converted images into various formats and sizes for different devices, generating originals, thumbnails, previews, WebP, zoom images, and mobile versions. This process showed that storing large binaries in the database isn't scalable. Using dedicated storage separates media from transactional data, simplifies CDN delivery and caching, supports async workflows, and keeps backups manageable. The database handles metadata, while storage efficiently manages the media workload.

As a developer, have you ever asked: Why does every major app store images in S3 instead of a database?

P50 is the median, indicating typical system performance with balanced responses. P75 indicates performance beyond average load, highlighting potential workload issues. P90 reveals increased operational pressure and inefficiencies, such as slow queries or delays, affecting some users. P95 captures stress points where bottlenecks are critical, often used for Service-Level Objectives (SLOs) to ensure reliability under realistic traffic. P99 highlights tail latency, exposing architectural failures such as queue saturation or dependency issues that can make the system unreliable despite good average performance. P99.9 concerns rare failures and extreme delays, critical at large scale, affecting millions of interactions. Percentiles reveal the distribution, unlike averages, which mask delays and failures. Mature engineering focuses on optimizing for consistency and stability during stress, measuring resilience by how systems perform at their worst, not just their best.

Go excels in its testing model, which aligns with its system design approach. Interfaces act as small, explicit contracts, enabling dependencies to be injected rather than imported and patched at runtime. This reduces indirection in unit tests and simplifies behavior isolation without needing databases, Redis, or network calls. Interestingly, this simplicity influences service architecture. In Go, if testing is hard, the abstraction is often too tightly coupled. Testing becomes a feedback loop for better design, not just a validation step.

Writing tests in Go after coming from TypeScript is an eye-opener. In TypeScript, mocking is a fight. You need Sinon stubs, spies, esmock to intercept ES module imports, and half the time you're wrestling the tooling more than testing the logic. In Go, you define an interface. You write a mock struct that satisfies it. You swap it in. Done. Today I wrote tests for the user endpoint that checks auth enforcement, cache hits vs misses, and verifies the cache gets bypassed when disabled. Used testify/mock for call tracking (AssertNumberOfCalls, AssertNotCalled) which is basically Go's version of Sinon spies. The test authenticator generates real JWTs with a test secret. Mock stores return controlled data. No database, no Redis, no network. Pure unit tests. Interfaces in Go aren't just a language feature, they're the entire testing strategy.

@sudox7 Using two pointers shifts your approach to the problem. Instead of analyzing each pair one by one, you utilize the array's order to determine your next step. This method improves efficiency because both pointers advance, avoiding redundant checks of the same values.

two pointers is one of those tricks that feels like cheating once you see it. O(n²) becomes O(n) by never going backwards. one pointer starts at the front. one at the back. they walk toward each other. array never scanned twice.

void * is a generic pointer to an object, but void ** is not a generic “pointer to any pointer.” If void **c = &b; were allowed, then through c you could assign a different void * value into b, silently changing an int * object via the wrong pointer type. 
 Example: void **c = &b; *c = &some_double; would store a double * into b, which is declared int *. The extra level of indirection makes this unsafe, so C only permits the void * conversion at the object-pointer level, not covariantly through T **.

This is the part of pure C I never understood. Why isn't void** compatible with int**? void* is compatible with int*, sizeof(void*) == sizeof(int*). So the covariant compatibility of void* across several levels of indirection makes perfect sense to me. Am I missing anything?

@milan_milanovic Hi there, greetings from Geneva Switzerland. Software and data engineer here.

Software engineers, let's connect!

Nice explanation. Small clarification: dup2() doesn’t copy files; it redirects fd 1 (stdout) to the same open file description. int fd = open("file.txt", O_WRONLY|O_CREAT, 0644); dup2(fd, STDOUT_FILENO); execvp("ls", args); The ls command doesn't know that stdout has changed; it just writes to fd 1 normally. The key point is that file descriptors persist across exec() calls unless marked with FD_CLOEXEC.

when you type ls > file.txt in bash, this is what's actually happening bash calls fork() and in the child before exec it opens file dot txt then calls dup2() to copy that file descriptor onto fd 1 which is stdout ls has no idea anything changed and writes to fd 1 like always but fd 1 now points to your file there is no special redirect syscall dup2 is the whole mechanism

Start with a full spec. Not giant enterprise documents, but it should include goals, constraints, architecture, interfaces, acceptance criteria, and edge cases before I begin prompting. AI agents tend to amplify ambiguity, so if the guidance is vague, they may confidently optimize for the wrong objectives, leading to more time spent steering rather than building. While I still iterate regularly, it’s mainly on tasks and implementation rather than redefining the entire product each time. Small, incremental adjustments work well for prototypes and exploration, but production systems greatly benefit from a clear, comprehensive spec from the start.

Honest question for anyone using AI coding agents daily: Do you write a full spec before prompting, or do you iterate in small steps and correct as you go? I am just not organized enough to do a proper spec-driven workflow

Bun moving parts to Rust indicates that when a project grows large, ecosystem depth outweighs language elegance. Rust offers stronger memory safety, better concurrency tools, mature libraries, and a larger contributor base, with advantages that compound at scale. Zig remains an interesting low-level language with excellent C interoperability, explicit memory model, and minimal abstraction. However, Bun revealed that being a great systems language isn't enough; widespread adoption, tooling maturity, and ecosystem support are also crucial. Rust currently has this; Zig does not.

Now that Bun is moving off Zig ... will we ever hear about that language again? Bun was the only thing I'd ever heard of using it, and it's moving to Rust. Hard to imagine anyone being eager to build on Zig at this point. Am I missing something?

@Adriksh ungetc() doesn’t “undo typing” — it only pushes a byte back into the stdio stream buffer so the next read gets it again. The example is valid, though the C standard only guarantees one character of pushback. Commonly used for lexer/parser lookahead.

In C, you can literally undo an input read. ungetc() pushes a character back into the stream so the next read sees it again like nothing happened.

I was not reiterating the memory overhead point; instead, I was clarifying that the comparison combines two different abstractions: a fixed-size primitive in C versus an arbitrary-precision object in Python. I also mentioned NumPy because it's the practical way to achieve C-like contiguous integer storage in Python applications.

@fawadhsdev @sudox7 what value did you add other than repeating the tweet?

something that bothers me every time I think about it: a Python integer takes 28 bytes of memory. a C int takes 4. it's not a Python bug. it's the price of dynamic typing. every Python object carries a reference count, a type pointer, and size metadata. a million integers in Python costs 28MB same in C costs 4MB.

@Gift_O_Nwankwo Exactly 💪

@fawadhsdev Don't outsource the building, even if you could. The shaping, the failing, the learning that's where the meaning hides. And meaning is the only souvenir that never fades.

What’s the fun in anything if you don’t build it, shape it, and go through the process yourself? The process is where the meaning is.

LLMs are already decent junior engineers. Agents are junior engineers with terminal access. Production systems still require a high level of engineering discipline.

@LewisCTech We already have most of this: ESM + JSDoc typings + checkJs + import maps. The web ecosystem refuses to stop rebuilding webpack with extra steps.

The web people should invent a thing where you can download typescript packages from npm as a single file where all the exports have jsdoc type annotations so you can do no buld with static type checking.

Hot take: bigger context windows may be slowing progress toward real AI intelligence. Memory governance and causal retrieval matter more than dumping millions of tokens into a model.

Long-term reasoning failure is often a temporal reasoning failure.

Most AI memory systems largely rely on semantic similarity, vector proximity, and keyword overlap for retrieval. However, human recall operates differently. Humans access contextually relevant experiences, causally useful analogies, and strategically applicable lessons, not just similar text. This fundamental difference could shape the development of the next generation of AI agents.

Forgetfulness is a feature, not a bug.

Reflection converts memory from archival storage into behavioral optimization.