i'm working on a platform where i link up smart hackers with smart companies. if that interests you, retweet and go join the waitlist: talent.lowlevel.tv/waitlist

Send me better thumbnails for old vids and I’ll give you 100% of the additional income if they perform better than the old ones

I'm really tired of "architects" who have not made contact with the system in a year and spend all their time in meetings and on draw.io The hardest technical decisions should constantly be bubbling up to your desk. Poor software architects spend their time drawing low-dimensionality diagrams of their systems imaging these strawmen to be the system itself. One must not forget: The map is not the terriotry. If you're stuck at the top of the tower staring at your map all day you have failed as an architect. If you're not connecting with your developers, if you haven't seen any of the code recently, you've failed as an architect. You've disconnected from the reality of the system and are un-fit to make decisions. You have become an expensive obstrution and should be removed immedietly.

If you find yourself daunted by the idea of pivoting to a different framework something has gone wrong! Vast amounts of content out there downplays the importance of separating business logic from the frameworks, libraries and third party systems that support it. A sure-fire way to ensure progress on a project will grind to a halt in the long-term is to make framework logic is inseparable from what the software *actually does* Good software leaves space for an evolution in the technology that supports it. "Although we cannot predict when changes in the technical or domain landscape will occur, or which changes will persist, we know change is inevitable. Consequently, we should architect our systems knowing the technical landscape will change" (Ford, Parsons and Kua, 2017, "How Is Long-term Planning Possible", para. 8). If you haven't had your technological decisions come back to bite you, forcing you to pivot, you haven't stuck with a project long enough. Cheaper and faster supporting technology is constantly becoming available to you, if you're not able to use the tools others will out-compete you. References 👇

I've got an article in my head: "In Defense of Abstractions". The right abstraction, found at the right time, can save you weeks of work. It's often worth putting the time in.

A test suite must feel good to use in order to be used and therefore be useful. Many test suites are untrustworthy and slow to run. They generally don't expand upon it and when they rarely do write tests they do so bitterly. To be useful a test suite should be: * Fully automated * Self-Checking * Repeatable * Independent (Meszaros, 2007, p. 26-27) If you're tests require manual work you'll skip some. If your tests are flaky or randomly fail you won't trust them and you won't run them. If you can't run an individual test the suite will feel like a slog to use and you won't run it as often as you should. "With these four goals satisfied, one click of a button (or keyboard shortcut) is all it should take to get the valuable feedback the tests provide" (Meszaros, 2007, p. 27). References 👇

In today's digital age, software plays a critical role in nearly every aspect of our lives. By focusing on the production of quality software, software engineers contribute to building a more reliable, safe and rich technological landscape for a global society. "Engineering seeks quality; software engineering is the production of quality software" (Meyer, 2000, p. 3). Software engineers should apply rigorous principles, methodologies, and tools to craft well-designed, efficient, secure, and maintainable code. We should collaborate closely with stakeholders to understand the requirements and ensure we solve actual problems for end-users. Beyond just writing code, software engineering encompasses the entire software development life-cycle. From initial planning and design, to implementation, testing, deployment, and ongoing maintenance, software engineers should work diligently to produce software that meets the highest standards of quality. References 👇

The most common failing and time-waster I see in software development is building something before you know what you're building. As Gerard Meszaros (2007) puts it, "if our customer cannot define the tests before we have built the software, we have every reason to be worried!" (p. 4. footnote 1). In general it is true that there's at least some small piece of a project that can be formally specified. There's always something the customer wants and can articulate. However, getting to it is difficult more often than not. That is not to say that there isn't something meaningful to be gained in the exploration of building the *wrong* thing initially. Quite often through the process of building something we will discover something that makes us change course. It is very difficult to imagine a product holistically, it is only once customers start using the product they requested intimately do they understand that in fact *they wanted something different*. This is one of the reasons benefits of shipping releases often and iteratively as is one of the intentions of Agile. It allows us to immediate feedback from our customers, either directly or through data, allowing us to course correct as early as possible, when it's as cheap as possible to do so. Hence, it is crucial that as developers we strong arm the customer into defining one piece of the puzzle at a time as formally as possible. We should then write the tests that imply to us we have done what the customer has asked. We should then make those tests pass and we should ship a release to the customer as soon as technically possible. #Testing References 👇

Software engineers have long recognized the value of immutability in their code. Immutability simplifies reasoning about code and reduces the potential for bugs. "If you've lived all your programming life with mutation as an ever-present possibility, you may not realize how much easier immutability makes everything" (Seemann, 2024, "Conclusion", para. 1). However, achieving full immutability is not always practical. "One of the most common compromises in regard to immutability is to segregate the application, or the services within the application, into mutable and immutable components" (Martin, 2018, p. 68). This allows developers to reap the benefits of immutability where it matters most while still allowing for necessary mutations in other parts of the system. The tension between the mathematical purity of immutability and the practical needs of software development has long been recognized. In as Bertrand Meyer says in his book Object Oriented Software Construction, "The problem is that if we allow functions to change things as well as commands, we lose many of the simple mathematical properties that enable us to reason about our software. [...] This immutability is the principal difference between the worlds of mathematics and computer software. [...] Some approaches to programming seek to retain the immutability of mathematics: Lisp in its so-called 'pure' form. [...] But they have not caught on for practical software development, suggesting that change is a fundamental property of software" (2000, p. 750). Despite these challenges, the benefits of immutability are becoming increasingly clear. "Many of us in the software industry are starting to take notice of the benefits of immutability in software architecture. [...] The claim (which many of us believe based on informal empirical evidence) is that immutability leads to programs that are easier to reason about and harder to screw up" (Fowler, 2013, pp. 8). As software systems become increasingly complex, the value of immutability in reducing cognitive load and improving reliability will only continue to grow. By embracing immutability where possible and carefully managing mutations where necessary, developers can create more robust and maintainable software systems. x.com/ploeh/status/180091504… References 👇

Times are changing, with the rise of machine learning and "big data". "Computer scientists, by nature, don't respect data. They have traditionally been taught that the algorithm was the thing, and that data was just meat to be passed through a sausage grinder" (Skiena, 2017, p. 2). Many CS programs have historically placed far more emphasis on clever algorithmic techniques than on the quality and curation of datasets. The result? A generation of computer scientists who see data as secondary - just fodder to feed the machine. Lost is the deep understanding that good data is the lifeblood of any successful real-world system. As the old adage goes, garbage in, garbage out. References 👇