Part 26 – Final Thoughts – Type Driven Development
This is a series of posts I’m writing about using types as another tool in software development, Continuous Delivery, & keeping LLM’s honest. They’re also a design & refactoring tool, a communication tool, and reduce how many tests you have to write.
There are trade offs to types. More to read, comprehend, & you’re often thinking in 2 modes: types + code. Watch Amanda Laucher & Paul Snively from Strangeloop conference “Types vs. Tests”, you’ll how far you can push the types to the limit of your understanding. As a team, you need to decide if it’s worth getting that understanding for the benefits, or “doing something simpler for now”. No shame deciding to be pragmatic & ship code. Learning types will be iterative. You/your team can gradually increase their skill, bredth of use over time, over many releases. It can also be a line in the sand for a target demographic; go read Dom Syme’s stance against Dependent Types in F#.
Types aren’t as popular as infrastructure, IDE’s, tests, or language features. Community is a part of programming, but a small part. Historically (90’s, 2000’s), languages that had better type systems were not adopted for a variety of reasons. That has been slowly changing since the 2010’s, but super slowly. Wonderful resources online to learn w/tight communities. Despite positive impacts to design + software quality, that does not translate to job opportunities or perceived importance to engineering leadership except for rare language communities.
Types have same issues that other programming quality initiatives have; not the norm. We’ve known for decades about positive impacts of code review, automated tests, Continous Delivery, & past 10 years we now finally have mounting evidence supporting what we knew. Yet companies & clients, either ignore the science, don’t know about it, or don’t know how to balance those standard quality practices w/getting actual work done. You’ll have to navigate politics, project & product management, design & UX, sales & marketing of the techniques & implementation details… WHILE doing you’re engineering job. This is especially hard w/types as they’re niche.
Finally, code is continually created, by your team, others, & library authors. Much of if not typed, or not typed to a strong degree. You’ll have to interface with this code. So learning not only “what’s good” for your domain/your code, but also “how best to safely integrate to this other code” will present additional aspects & challenges.
You’ll be confused why everyone hasn’t adopted sum types; that never goes away, a true mystery of the universe.
I say all of this not to dissuade you, but to prepare you. Not all tradeoffs are the same; some are better than others, and types in my experience are worth it. The “hard to learn” is a great problem because this job attracts nerds & we learn everyday. It can be hard and lonely, but it’s worth it.
Card decks ordering details to follow.
Leave a Reply