标签 · Career Advice — Glean

Recent picks

5picks · chronological

09-16

The Product-Minded Software Engineer: 9 Traits and How to Grow Them

The author breaks "product-minded" down into observable behaviors: these engineers do not take a spec and start coding, they ask why first, challenge requirements, and evaluate product and engineering tradeoffs together. Nine traits are listed, including digging into business and user data, building relationships with non-engineers, applying a minimum-lovable-product lens to edge cases, and following user behavior metrics for weeks after launch before drawing conclusions. Product instinct, the author argues, compounds across repeated project cycles of questioning, proposing, validating fast, and debriefing gaps. Written for engineers on user-facing teams who work with PMs; it closes with six concrete habits to build the muscle.

blog.pragmaticengineer.com · 12 min · Career Advice · Product Management · Software Engineering

09-16

20 Things I've Learned in my 20 Years as a Software Engineer

A Simple Thread co-founder distills 20 years of engineering into 20 opinions, prefaced by an honest account of his context: small teams and startups first, then consulting inside large companies, then growing his own firm from 2 to 25 people. The list runs against received wisdom: building the right thing is harder than building it well; the best code is code you never write; every system eventually rots, so aim for continuous improvement rather than elegance; the 10x programmer is a myth and the real win is keeping 0.1x programmers off the team; data outlives your codebase; interviews predict almost nothing about teammates; prefer durable "shark" technologies to fashionable ones. Aimed at working engineers who want to sanity-check their own judgment, with the caveat that all advice is contextual.

www.simplethread.com · 14 min · Career Advice · Engineering Culture · Essay

09-15

How to ask good questions about software

Julia Evans argues that asking good questions is a trainable software engineering skill, not a personality trait. Her core technique: state what you already understand, then ask 'is that right?'. She rewrites vague questions ('how do SQL joins work?') into questions with factual answers — is joining N and M rows O(NM) or O(NlogN)+O(MlogM), does MySQL always sort join columns first. She shows the rkt-dev mailing list question where she first wrote down how rkt and Docker store container images differently, then asked why; and the term dictionary she built for Hadoop, Scalding, Hive, Impala and HDFS when joining a data team. She also covers choosing whom to ask (a 5-minute answer that saves you 2 hours is a good trade; the most senior person is not always the right target), stopping an explanation to ask what a term like optimistic locking means, and reading the Etsy Debriefing Facilitation Guide for questions that surface hidden assumptions. She is explicit that asking dumb questions is fine, and criticizes ESR's 'How To Ask Questions The Smart Way' for putting an unreasonable burden on askers. Aimed at engineers ramping up on unfamiliar systems.

jvns.ca · 13 min · Career Advice · Software Engineering · Technical Communication

08-11

What Is an AI Engineer?

A concise role introduction to AI engineering, drawing on Latent Space's 'The Rise of the AI Engineer.' It draws the line at the API boundary: AI Engineers orchestrate models to build applications, while ML Engineers build the model APIs themselves. The post argues newcomers don't need linear algebra or pretraining experience; instead they need strong software fundamentals, evaluation frameworks, and feedback loops. It also distinguishes AI Engineers from AI-assisted developers who merely use tools like Copilot. Web developers are presented as well suited for the transition, and TypeScript is called a fast-growing fit. The article is accessible but conceptual, with a promotional block for the author's AI Hero skills system.

www.aihero.dev · 4 min · AI Engineering · Career Advice · LLM

06-29

how to be good at research

A thread by @itsreallyvivek arguing that research skill is a stack of trainable sub-skills, not a gift. Core moves: pick problems you genuinely want to exist (Schulman), upgrade inputs by reading old papers and skipping summaries, write everything down to expose hidden gaps (Graham, Feynman, Darwin), tighten the experimental loop with scripted tooling (Karpathy), stare directly at failure cases instead of loss curves (Andrew Ng), deliberately wander across subfields to find your unfair advantage, and cultivate collaborators who will tell you an idea is bad. The post synthesizes concrete tactics from Hamming, Sutton, Shannon, and others, emphasizing falsifiable forecasts, reproducible tooling, and reading raw data over third-hand threads. Actionable for research engineers and PhD students tired of surface imitation.

x.com · 10 min · AI Engineering · Career Advice · Experiment Design