How to Be Pragmatic as an Engineer

The article defines pragmatism in engineering as focusing on what works in the specific case, not just what is theoretically correct. It stresses that production software lives under budget, changing requirements, team knowledge, legacy code, hardware limits, people factors, regulation, and time pressure.

It then argues for simpler solutions, explicit trade-offs, and avoiding premature optimization. The author recommends using proven tech, asking better questions at the start of a project, building proofs of concept when useful, reducing scope without reducing value, delivering iteratively, and aiming for good enough rather than perfection.

Reading notes

#

• Pragmatism means choosing the best solution possible within real-world constraints.
• Engineering work is shaped by budget, requirements changes, team expertise, legacy code, hardware constraints, people, regulation, and time pressure.
• A technically correct solution can still be a bad decision if users do not need it.
• The article uses an image-upload feature as an example of overbuilding something that users did not end up using.
• Simpler solutions should come first, with later optimization only if it is actually needed.
• Every engineering decision is a trade-off, so the same approach can fit one case and fail in another.
• The article recommends explaining pros and cons instead of saying a request is impossible.
• Premature optimization is presented as a recurring mistake.
• The author highlights KISS and YAGNI as guiding principles.
• Boring, proven technology is preferred over shiny new tools when the goal is to ship useful products.
• Asking good questions before starting work can prevent building the wrong thing.
• The article points to a Notion template with 35+ product, business, and technical questions for technical decisions.