Notes on AI, engineering and tech careers.
What I have actually seen work: building software, leading a team, and mentoring engineers through job hunts and promotions. No listicles.
27
Articles90K+
Readers on LinkedInLatest posts
27 posts · page 1 of 3
The Habits That Make an Engineer Worth Routing Work Through
Every team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Fourteen Questions Worth Answering Before You Change Jobs
The typical job change starts with one specific bad month, and within a fortnight the applications are out. Sometimes that is right, and often it produces a lateral move into a different set of problems discovered around month four. Fourteen heuristics for the whole arc: deciding, choosing, not being talked into or out of it, and leaving well.
A Job Search Is a Pipeline, Not a Performance
Most people run a job search as a series of hopeful individual events, which fails for a structural reason: the response rate on cold applications is low enough that any single one is close to noise. The people who find work reliably are running a pipeline instead. Thirteen heuristics for the mechanics, which are the part you actually control.
Sixteen Things That Break a Backend, and What Prevents Each
Backend engineering is taught as frameworks and turns out to be almost entirely about what happens when the database is slow, when the same request arrives twice, or when a downstream service stops answering without saying so. None of it is deep, all of it is invisible until it happens to you at an unpleasant hour. Sixteen situations and their usual answers.
Fifteen Problem Shapes and the Move That Solves Each
The usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
Choosing a Data Structure Is Choosing What to Make Cheap
Most people learn data structures as a list of things to implement, forget nearly all of it, and go back to using an array for everything. Implementation is the least transferable part: you will implement a hash map approximately never and choose between one and something else roughly every second week. Twelve pairings for making that choice.
What to Do When You Are Stuck Learning to Code
There has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
Thirteen Web Development Habits That Outlast the Framework
The web moves faster than any curriculum written about it, so every list of what to learn is stale by the time it reaches you. What survives is the set of situations that keep recurring: a slow page, a form that lets something through, state stored in two places that has started to disagree with itself. Thirteen of those, with the move that usually works.
The Defaults I Would Learn First as a Software Engineer
Every roadmap for learning software engineering is the same technology list in a different order, and it tells you nothing about what to do when you are sitting in front of an unclear requirement on a Wednesday afternoon. Fourteen situations you will keep meeting, paired with the move that is usually right, from prototyping a vague requirement to blaming the system rather than the person.
Microservices Practices That Actually Keep Them Workable
Most microservices advice describes how to run them well and skips the decision that causes the most damage, which is splitting too early. The practices that matter once you genuinely need services: boundaries drawn around business capability, data ownership, failure handling, idempotency, events over synchronous calls, tracing and contract testing.
Engineering Newsletters and Blogs Worth Your Inbox
Most engineers subscribe to fifteen newsletters, read none, and feel vaguely behind, because a full inbox produces guilt rather than learning. A shorter list sorted by what you would actually read each one for, why company engineering blogs beat most newsletters, and the weekly routine that makes any of it stick.
Browse writing by topic
Every tag has its own page.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com
Follow along
New writing, resources and project ideas land here first.