15 entries tagged "software engineering" — 4 posts, 11 links.
A senior data engineer's decade of candid career lessons — job mobility, technology stacks, management dynamics, and data-engineering-specific realities — delivered in a deliberately irreverent tone.
The value isn't novelty; it's calibration. The framing strips out the polish that makes most career advice easy to agree with and harder to actually use.
Loose title, useful theme. Senior engineering is less about cleverness and more about judgment, communication, taste, scope control, and knowing where complexity will hurt later.
Keeping this because it fits the thread running through the site: the work is technical, but the leverage often comes from deciding what not to build and how to make the consequences visible.
This belongs next to any local inference or training work because cross-platform ML is usually where clean notebooks meet real machines.
The useful lesson is not only PyTorch-specific. Runtime packaging, hardware backends, and dependency friction are product risks when your users are expected to run models outside your exact environment.
Evan Miller's statistics pages are useful because they speak to programmers who need decision math, not notation theater. This one is especially good as a quick reference for formulas that show up in experiments and product metrics.
Worth keeping near the statistics posts because it encourages the right instinct: make the uncertainty explicit before turning a number into a decision.
This is worth keeping because good code reading starts before opening the first file. Git history can show what changed, where the pressure points are, and which parts of the system have been touched recently.
It maps nicely to agent work too. Before asking an assistant to edit a repo, make it understand the recent shape of the work.
This is one of the better engineering-process essays because it grounds motivation in visible progress. Break a large project into pieces that can produce real feedback, then sprint toward demos instead of disappearing into perfect architecture.
It maps cleanly onto product-minded engineering: a demo is not only morale, it is an early reality check.
This overlaps with the coding-assistant posts on the site, but it is still worth keeping as an outside practitioner account: small steps, screenshots, AGENTS.md, undo discipline, and refactoring agent-generated blobs.
The caveat is that advice like this should become process, not vibes. If an assistant can break the project quickly, the workflow has to make rollback and review cheap.
This belongs in the queue because database performance is often where application assumptions meet physical reality. Indexes, query plans, and access patterns are product concerns when latency becomes user-visible.
It is also a reminder that "the database is slow" is rarely a useful diagnosis. The question is what the query asked the database to do.
This is one of the React links that still earns a place because it explains the runtime model instead of another surface API. Understanding React as a way to describe, schedule, and reconcile UI work ages better than memorizing patterns.
Useful for the site's TypeScript and React writing because it turns framework behavior into architecture vocabulary.
This is an evergreen frontend architecture piece because it names the hard parts of UI work: state, latency, consistency, environment, and synchronization. Those problems do not disappear when the framework changes.
It fits the product-minded engineering theme because UI quality is usually system quality made visible.
This is a useful frontend architecture link because it pushes beyond taste and asks what tradeoffs teams inherit when React becomes the default answer.
It belongs next to the React runtime links, not against them. Better engineering judgment comes from understanding both why a tool works and where it costs too much.