I really like React. It's far and away the best UI framework I've worked with. There's so much to say about why that is, but one of the biggest reasons, and simplest in some ways, is just the power of components. Components are a great design structure and a great code organization structure. They're intuitive and surprisingly powerful due to how they can be nested and reused.

Welcome to the NEW new blog! I went to CodeMash again this year for the first time in 9 years (I couldn't believe it had been that long), and I thought I might write a blog post about it. But then one thing led to another and I ended up rewriting my blog instead. So here's a quick post about the new tech stack behind this blog, why I switched, and how it went.

CodeMash 2024 was Jan 11th and 12th this year, and this marked the first time I've gone since 2015 when I did a talk called "The Cartography of Testing". That's 9 years! I couldn't believe it had been that long. It was great to be back and see old friends, meet some new people, and oh also there were sessions ;)

This is my list of favorite tech books that are timeless in nature because they deal with the "art of programming", as opposed to more traditional technical books that deal with specific syntax or frameworks or tools. I found all of these very valuable because they expanded my programming horizons and, I hope, made me a better developer.

This is a dumb metaphor, probably, and I'm sure I'm not the first person to think of this. But I was using it to explain what I'm discussing with my co-workers all day (on the phone, working from home, what with quarantine and all).

I've been learning Piano and jazz theory, it is going slowly, but it is very fun. I bought a giant book of blank Staff Paper so I can take notes on things I'm learning, write out exercises, and hopefully start doing some transcriptions, and maybe other stuff too, I don't know where this journey may take me yet.

I have become a keyboard nerd, apparently. Not that I wasn't already, I guess, but I've just taken it to a different level.

Programming involves a lot of research, though we don't always recognize it as such and that can cause problems.

Some of the key code design principles I keep coming back to are the Tell Don't Ask principle, the Law of Demeter, and also Sandi Metz's idea of Blind Trust. But I also find that these are hard to put into practice! To help with that, I like to play a little game I call The Ignorance Game, which I'd like to describe in a bit. But first, let's review these principles.

I know I'm not going to stun anyone with this, but, when it comes to class design and C#, not everything should be public.

I fell in love with functional programming when I learned F#. We program in C# at work, but I use F# any chance I get on little side utilities and things. In F# the REPL is a pretty big deal. F#'s REPL is called fsi (F# Interactive). REPL stands for Read, Evaluate, Print Loop. It's just an interactive shell where you type in F#. When Rosyln came out C# got C# Interactive too, and it's built into VS but I never think to use it for some reason. But I do reach for fsi a lot when I'm writing F#, and from what I can gather that seems pretty typical in the F# community and the functional programming world at large too.

I'd like to pose a ridiculously giant question to you: how do you take a team of programmers and client reps and designers and clients and a contract and deadlines and build a quality product? Or more simply, how do you build a quality app?

Welcome to my new blog! I've had a blog on blogger since April 4, 2007. That's almost 11 years! That's a long time! After all that time, I thought I was due for a change, and I thought it would be fun to build that change myself. Turns out it was fun! I learned a lot of stuff that I probably should have already known but didn't. So let's get meta and blog about the development of this blog!