Stefan Heil’s Post

In software development, ownership isn’t about who commits the code. It’s about who stands behind the decisions inside it. Good engineers don’t just deliver features. They steward systems, they understand how they work, why they exist, and what trade-offs they embody. When AI begins to write parts of that code, something subtle shifts. We stay productive, but we lose context. We ship faster, but we stop asking why. That’s how ownership erodes: quietly, without intent, one delegated decision at a time. AI can generate code, but it can’t take responsibility. If we let it own our reasoning, we’re no longer engineers – we’re operators of someone else’s system.

“We should become experts at learning. We should recognize and accept that our discipline is a creative design discipline and has no meaningful relationship to production-engineering and instead focus on mastery of the skills of exploration, discovery, and learning. This is a practical application of a scientific style of reasoning. We also need to focus on improving our skills in managing complexity. We build systems that don’t fit into our heads. We build systems on a large scale with large groups of people working on them. We need to become expert at managing complexity to cope with this, both at the technical level and at the organizational level.” — Modern Software Engineering: Doing What Works to Build Better Software Faster by David Farley https://a.co/blKOuSA

📝 Traceability isn’t just for software engineering — it’s for life. In software engineering, every piece of work needs a clear lineage. Every feature we build traces back to a specific requirement, which in turn traces back to a core business need. It’s a verifiable, bi-directional chain. It doesn’t just ensure we’re building the right thing — it helps us understand the impact when a high-level goal changes. But how often do we apply that same rigor to our own lives? We keep executing on commitments and filling our calendars with tasks that have become orphan requirements — disconnected from the person we want to be. The chain is broken. 💡 What if you managed your life with true, bi-directional traceability? 🔹 Your core values and goals are your high-level requirements — your ultimate source of truth. 🔹 Your major commitments and projects are the features you implement. Each one should trace back to a core requirement. 🔹 Your moments of reflection are your test cases. Do they pass or fail? Does what you do actually fulfill what you want? And it works the other way, too. When a core goal changes — a new priority, a career shift, a shift in values — you can trace it down to see exactly which commitments and habits need refactoring. This idea of structured reflection is also the foundation of my journal: 📓 "From Junkie to Juicy: A 5-Week Rehab for Commitment Addicts." (Link to Amazon in 1st comment). A lighthearted but practical booklet to help you reconnect your obligations to what truly matters — one traceability check at a time. 💬 How do you run “test cases” on your own life to ensure you’re still on track? #SoftwareEngineering #Traceability #Leadership #PersonalDevelopment #GoalAlignment #ContinuousImprovement #Reflection #SystemsThinking

One of the most underrated skills in software engineering is understanding the problem statement. Anyone can write code. But not everyone can decode what needs to be built. Before a line of code is written, great engineers pause to ask: - What problem are we solving? - Who are we solving it for? - What does success look like? This ability to deeply understand product requirements separates Software Engineers from Software Developers. 🧠 Developers build what they’re told. ⚙️ Engineers build what’s needed. When understanding is missing, you don’t just lose time — you lose clarity, cohesion, and product direction. I’ve spent weeks building the wrong solution — not because of bad code, but because the problem wasn’t fully understood. In the end, the best engineers aren’t just problem solvers — They’re problem understanders. What’s your take — is “understanding the problem” a skill we undervalue in engineering teams today? #SoftwareEngineering #ProductDevelopment #TechLeadership #EngineeringCulture #ProblemSolving #SoftwareDesign #Developers #Learning

Software engineers are great at producing outputs — but often terrible at ensuring outcomes. I’ve been thinking a lot about that tension lately, so I want to share the following mantras with you: - Outputs ≠ Outcomes. Outputs are what you build. Outcomes are the effects you produce. - You can deliver tons of features (outputs) and still fail if users don’t adopt, if business metrics don’t change, or if value isn’t delivered.  - To manage outcomes, you need accountability beyond engineering: cross-functional ownership, meaningful metrics, and incentives aligned with impact — not just shipping. So here’s how I’d put it if I were rewriting that in “engineer speak”: Ship less, think more. Every feature, every line of code — question why it exists, not just how it works. Don’t get credit for building — get credit for changing something. What are some outcomes you care about in your teams? (E.g. retention, conversion, time saved, errors reduced, business impact). Would love to hear what you track — and whether your team still counts outputs as wins.

Most underrated software engineering skill almost no one talks about is pragmatism. Not hype. Not personal bias. Not emotional attachment to a stack. Pragmatism. The ability to make decisions based on context, constraints, and customer value — not ego or excitement. Because at the end of the day: You’re not building for your portfolio. You’re building for a real user with a real problem and a real deadline. That tech you’re using… was it a pragmatic decision? Or did you pick it because: - It’s trending on X? - Someone you admire mentioned it? - You’re afraid of being seen as “basic” or “behind”? We don’t talk about this enough: - A boring stack that solves a problem beats an over-engineered stack that impresses no one. - Simple and shipped is more valuable than complex and unfinished. - The right solution is rarely the loudest one — it’s the one that respects the problem. Some engineers want to feel powerful. Others want to be useful. And the industry always rewards the second group. You don't need the most advanced architecture. You need the one that fits. Real engineering isn’t “What’s the coolest way to do this?” It’s “What’s the smartest way to do this for this situation?” Be honest: have you ever used a complex tool for a problem that didn’t need it? #softwareengineering #systemdesign #productthinking #careerdevelopment #techleadership #buildinpublic #engineeringmindset

Unpopular opinion: There’s no such thing as universal “best practices” in software engineering. I've watched countless teams slow themselves down by following "best practices" religiously without questioning whether those practices fit their specific situation. What works brilliantly at FAANG scale can cripple a startup. Practices that empower a 5 person team often collapse under a 50 person organization. Even celebrated design patterns become anti-patterns when applied without thought. The truth? There are no universal best practices, only good practices in the right context. The Real Problem "Best practices" have become intellectual shortcuts. We treat them as immutable laws instead of what they actually are: solutions that worked well for specific problems, in specific contexts, at specific points in time. But context changes. Team sizes evolve. Requirements shift. Technology advances. Yet we keep cargo-culting practices that may no longer serve us. A Better Approach: As engineers, our core skill isn't memorizing rules, it's making informed trade-offs. Before adopting any "best practice," ask: Best for whom? (A 10-person startup or a 10,000-person enterprise?) Best for when? (Early-stage exploration or mature, stable systems?) Best for what trade-off? (Speed vs. reliability? Flexibility vs. consistency?) Question the context. Understand the trade-offs. Adapt the practice to your situation or abandon it entirely if it doesn't fit. Because the best engineers aren't the ones who follow all the rules. They're the ones who know when to break them.

💡 Great Code Is About What You Write Today Unfortunately, in software engineering, it’s not about how good your code was a year ago. It’s about how well you write it today. This field doesn’t reward what you knew; it rewards what you can apply right now. The tools we use, the patterns we follow, even the way we think about performance and design; all of it keeps changing. You can’t rely on being the person who once wrote clean, scalable code. You have to be the person who still does. Here’s what I’ve learned over the years: 🔄 Good engineers update themselves as often as they update their code. 🧠 Keep learning — not just new frameworks, but new ways to think. 🧩 Refactor your mindset — what worked before might not be the best today. 🗣️ Seek feedback — even senior engineers benefit from code reviews. ✍️ Write for readability — clarity always outlives cleverness. The truth is, your old code isn’t a legacy; it’s a reminder of how much you’ve grown. What matters most is the quality of what you ship now. #SoftwareEngineering #Developers #CleanCode #ContinuousLearning #EngineeringMindset #TechLeadership

I read yet another great post from Kent Beck about measuring software engineering (you know where to find the link). That got my mind meandering on the subject of metrics. I have created and used "The Four Types of Metrics" as a tool to analyse what an organisation is seeing through numbers. I just now realised that it is actually a four-field: Bird and Frog perspectives on the vertical axis. Internal and External on the horizontal axis. 1. Continuous Learning, measuring the gain and lack of little traits. Worth measuring to understand and fill knowledge gaps. 2. Delivery Performance, as in, can we build it right? 3. Product Success, as in, is it a viable, lovable, feasible and usable thing to build? 4. Hypothesis-Based Development, as in, do we know whether yesterday's work is moving the right metrics in the right direction? Most of the software engineering metrics are highly concentrated on delivery performance. The DORA metrics and the most common SRE numbers — SLI, SLO, and Error Budget — are primarily focused on delivery performance. There are often some metrics that could be hypothesis metrics, but the feedback loop is too loose to trigger any flywheel effect. The truth is that the meaningful metrics are the ones teaching us about the user and the business, but they are so essentially linked to the particular product and dependent on timely feedback loops — hard to measure and custom — that we often give up on measuring them.

Software engineering has never been just about writing code. It’s about building systems that: ✅ Solve real problems ✅ Scale with demand ✅ Evolve over their entire lifecycle With the rise of LLMs, we’re entering a new chapter: 🔹 Most code will be generated by AI. Engineers will spend less time typing and more time guiding — providing context, direction, and critical feedback. 🔹 Language and framework expertise will matter less. What will matter more is the ability to design robust architectures and ensure security, scalability, and efficiency. 🔹 Specialists will give way to generalists. Engineers will need broader perspectives, combining technical and product thinking. 🔹 The engineer–product gap will shrink. Engineers will sit closer to the problem space, shaping solutions alongside product teams. LLMs probably won’t replace engineers — but they will certainly redefine what engineering means. The future belongs to those who adapt, think systemically, and connect technology to real-world impact. https://lnkd.in/ddeGdeEZ