Technical Practices: No Enums

Quality-wise of this post; not gonna lie - Probably will be low. It's 7am and I'm low on posts. This isn't a bubbling pressing issue on my mind. I don't need to stream my thoughts to work through something... What I do…

Beneficial Results - Simpler Code

Simpler code. Don't we all wish the code we deal with could be simple? Simple is hard. Simple is challenging. Simple is complex. A short letter is much harder to write than a long one. Why do you think my blog posts are so damn wordy? I don&…

Refactoring: Where to start

I've had a lot of discussions around applying the MicroObject technical practices [https://quinngil.com/uobjects] to legacy code. "These practices are clearly great for new code, but how can we work them into our existing code?" Even if it's not your definition of…

Thoughts: Testing Without Mocks

James Shore [https://twitter.com/jamesshore] has a post, Testing Without Mocks [https://www.jamesshore.com/Blog/Testing-Without-Mocks.html], that I've recently been introduced to. Skimming through the introduction of the post, it looks like the goals of this align well with what MicroObjects give us in terms…

Technical Practice: Objects avoid Primitive Obsession

I have a GitHub project FluentTypes [https://github.com/Fyzxs/FluentTypes] which I've written about before [https://quinngil.com/2018/03/11/uobjects-fluent-types/]. The goal is to avoid the problems of Primitive Obsession. We want to represent what we're thinking. After working in MicroObjects style and…

Refactoring Legacy Code: Remove future proofing

The legacy code I'm playing with at work had some nice future proofing. It wasn't quite big design up front, but it was some future proofing. I got some out, but there's still a whole level of abstraction that's pending removal. I&…