Holy Dev Newsletter July 2024

👓 Balancing Old Tricks with New Feats: AI-Powered Conversion From Enzyme to React Testing Library at Slack - Slack Engineering [experience, ai]
A fascinating story of migrating a huge codebase from one testing framework to a rather different one. AST transformations proved too complex, and they stopped at ~ 45% eyes code. LLM was at first not very good: "Despite our best efforts, we encountered significant variation and inconsistency. Conversion success rates fluctuated between 40-60%. The outcomes ranged from remarkably effective conversions to disappointingly inadequate ones, depending largely on the complexity of the task. " Prompt engineering seemed to only perplex it. The solution: provide more context and guidance (the corresponding DOM tree, partially converted code from the AST approach) => the integration of both AST and AI technologies, helped us achieve the remarkable 80% conversion success rate. Especially the partially converted code and suggestions generated by the initial AST-based codemod "yielded remarkable results," successfully minimized hallucinations and nonsensical conversions.

👓 Questionable Advice: “My boss says we don’t need any engineering managers. Is he right?” [way-of-working, management]
An interesting question: why do we need engineering managers? (Thank you, Anton!) The author argues that hierarchy has not been invented to oppress people (though it is sometimes used that way) but that it is an emerging property of self-organizing systems, which is "is absolutely critical to the adaptability, resiliency, and scalability of complex systems." Especially, "Hierarchy minimizes the costs of coordination and reduces the amount of information that any given part of the system has to keep track of." Applying this to engineering organizations, "we can say that a manager’s job is to coordinate between teams and help their team perform better." They build relationships and wider context that makes them better at their job, while it allows engineers to focus on their job. Also, management labor consists of frequent context switching (meetings and stuff), which would kill any "maker." "If you’re trying to hold your tech leads responsible for building healthy engineering teams, tools, and processes, you are asking them to do two calendarily incompatible jobs with only one calendar. The likeliest scenario is that they will focus on the outcomes they feel comfortable owning (the technical ones), while you pile up organizational debt in the background."

👓 sans-IO: The secret to effective Rust for network services [rust, opinion, architecture]
A fascinating article arguing for the "sans-IO" approach to writing code and libraries. It's about pushing I/O (even reading current time) to the outskirts of your system. The core of your code becomes I/O-less, written as side-effect free, pure state machines. It is wrapped by a side effecting shell of "event loops", that bridge between the pure core and perform the actual side effects. The article discusses the advantages (such as not having to deal with the sync vs. async dichotomy, and better testability) and also some disadvantages of this approach.