Critical developer skills in 5 minutes or less.
Half my own learning journey, half experiment to improve software education. These posts attempt to extract best practices from, and connect readers to, leading software literature.
The Great Rewriting in Rust is a good overview of why Rust is a compelling and growing language. However, I have a small quibble with how it refers to F#. The article states F#, Dart, Swift, or Kotlin either, which seem to be more interested in replacing the null keyword with optionals, thereby solving Sir Hoare’s mistake. Sir Hoare’s mistake refers to null. I can’t speak to Dart, Swift, and Kotlin, but I know F# rather well.
Continuous Integration (CI) is a hot buzzword. I’ve had a general sense of it for a while, but Refactoring chapter two brought its place into sharp focus, mainly through Preparatory Refactoring.
Looking for value objects among entity members is one of my favorite lessons from Domain Driven Design. Here’s a quick overview.
Agile and DevOps have pushed faster and more frequent releases. Techniques like integration test, feature flags, canary tests, and monitors evolved to maintain service reliability without slowing that pace. But some code paths are so critical that they cannot fail even once. This is where Scientist comes in.
This post is mostly a self-reminder to think more on a few logging ideas I encountered. I figured others might benefit from them too.
I previously wrote on statistical and mutation testing for UIs. After additional thought, I don’t think UI mutation testing is feasible, at least in the traditional sense. Structure-based generative testing still could be. Lack of Deterministic Errors for Mutation Mutation testing is a tool to measure completeness. It tells us how well our other tests detect possible errors in our code. Mutation testing frameworks measure test suite completeness by crawling the code and injecting breaking changes.
A friend has been struggling with under-documented projects (*cough* zoo software). This raised the question, what makes good documentation? And what is a good documentation system? Here’s my opinion backed with some sources.
Small teaching is an engaging and practical condensation of learning research into an accessible read. The book is oriented toward teachers, but is meaningful for anyone who wants to learn more effectively or understand how to share ideas.
Choosing the right amount of process is an art. Too much process is smothering and too little is a mess. However, I think incremental, stable, and additive processes naturally start simple and mature progressively with our demands.
“No ideal process, or set of processes, exists” “Software processes must be selected, adapted, and applied as appropriate for each project and each organizational context.” (SWEBOK Ch 1.1 intro). No one likes to hear “that’s just how we do it”. Process without understanding leads to frustrating lack of results. Understanding factors of good process is critical for effective work across projects and for continued improvement. My working hypothesis is that effective processes are incremental, stable, and additive.