--- > There are two driving passions in my work. One is the love of creating beautiful, elegant code — making Open Source libraries and APIs that focus on clear design and reusability. The other passion is building quick, pragmatic solutions for real users (who may not even be developers). The latter usually in a setting of building a product, where the product is not the code. Here, speed and iteration matter more than beautiful code or reusability, because success hinges on shipping something people want. ... Early on, I realized that creating reusable code and directly solving problems for users are often at odds. --- > Back then, me and a friend tried to replace it by writing my own bulletin board software, [Pocoo](https://web.archive.org/web/20070502223619/http://flying.circus.pocoo.org/). Working in isolation, without users, led me down a path of over-engineering. While we learned a lot and ended up creating popular Open Source libraries (like Jinja, Werkzeug and Pygments), Pocoo never became a solid product. - [View Highlight](https://read.readwise.io/read/01jxjd2d8ga5gdrnb9p9hbym1r) --- > I have shown Flamework's code to multiple engineers over the years and it usually creates such a visceral response. It blind sights one by seemingly disregarding all rules of good software engineering. > That makes Flamework serve as a fascinating Rorschach test for engineers. Are you [looking at it](https://github.com/exflickr/flamework) with admiration for the focus on some critical issues like scale, the built-in observability and debugging tools. Or are you judging it, and its creators, for manually constructing SQL queries, using global variables, not using classes and looking like messy PHP4 code? Is it a pragmatic tool, intentionally designed to iterate quickly at scale, or is it a naive mess made by unskilled developers? - [View Highlight](https://read.readwise.io/read/01jxjd6t4ycbf33htps26779mv) --- > At the end of the day, where you stand on “shitty code” depends on your primary goal: > • Are you shipping a product and racing to meet user needs? > • Or are you building a reusable library or framework meant to stand the test of time? > Both mindsets are valid, but they rarely coexist harmoniously in a single codebase. - [View Highlight](https://read.readwise.io/read/01jxjd7be0q5xqvz00xy5517cy) ---