Noel Rappin Writes Here

If you’ve been reading this newsletter for a while, you’ve may have noticed there are two patterns I talk about all the time: We’re doing something because everybody does it but we don’t know why. We’re doing something, but we don’t really believe in it so we’re doing it halfway and not getting any benefit. Object-Oriented Design often hits both those patterns – teams use OO languages for various reasons without thinking about what OO can do for them, and then teams don’t use OO design or programming tools in a way that can help them achieve their goals.

A long time ago, I studied research on what makes successful engineering teams. (Not programmers, other engineering fields). I don’t remember a lot of it, but one phrase stands out: “preserving ambiguity”. Successful teams don’t make decisions that aren’t needed, and they don’t get themselves locked in too early. One fact about the beginning of a project is that you know less about the project than you ever will. And yet teams are often asked to provide estimates, do architecture, and make long-ranging plans at the beginning of the project when it is guaranteed that some of the assumptions will be wrong.

Previously on Locally Sourced: I wrote about building a small feature in Hotwire. Also, I have two, count ‘em, two, books for sale. Modern Front End Development For Rails (ebook) (amazon) and Modern CSS with Tailwind (ebook) (amazon). I have this idea that teams get in trouble when they do something that they are “supposed to do” without understanding what problem they are trying to solve and what tradeoffs they are willing to make to solve it.

Previously on Locally Sourced: The Tailwind book is out. Buy it in ebook or at Amazon. Modern Front-End Development For Rails is in final layout and headed to the printer. This post will make a lot more sense if you’re familiar with Hotwire If, for example, you bought a book about it… Simplicity is Not Simple To the extent that I have a guiding principle of software development it’s this Alan Kay quote:

Previously on Locally Sourced: About a year ago, I started this newsletter with a bunch of posts that I originally called XP 2020 and later called Entropy Essays – you can find all the posts here. I got bogged down and never got to the punchline… There’s a common thread in the story of how testing, object design, and pair programming have been adapted since XP and Agile became buzzwords. I think estimating fits here as well.

After writing about one kind of contrived sample code, I want to write about a different kind: the kind that is part of an interview process. A disclaimer right up top: I do occasionally evaluate coding samples for Root, but I did not design the current coding problem, nor did I design the metric that is used to evaluate solutions. Nothing I say here should be taken to imply anything about Root’s interview process.

You don’t need me to tell you that 2020 was a weird year, and that definitely showed up in my reading list. For a long time mid-year, I really shied away from anything that was dark or challenging. Still, I somehow managed to read books this year, and I managed to put together a list. Eventually, I mean it is April 2021, which is a little late for a Best Of 2020 list.

Previously on Locally Sourced: I said this one would be about interview code, which it isn’t. Next time. Meantime, the live home of this newsletter is https://buttondown.email/noelrap, where you can subscribe for free, or for money if that’s feasible for you and you are so inclined. Thanks, and tell your friends! People have been asking me quite a bit recently whether I would choose Hotwire or React for a project and what role each has in the web ecosystem.

I’ve been going back and forth about what to put in this newsletter about Modern Front-End Development For Rails. On the one hand, it’s a big deal for me, and it’d be great for me if people bought it. On the other hand, you’ve likely heard me talking about it for a year and you’ve probably made up your mind. (If you haven’t, would you consider buying a book?) I did realize I had a weird, niche topic about the book that I wanted to talk about.

If you are reading this, then I did at least one thing right. I’ve moved this newsletter to new provider called Buttondown. Ideally, this will not affect you at all. (You may have gotten a request to re-confirm your email, if so, that was my mistake.) For me, it gives me the ability to write in Markdown, with code syntax coloring, an API that I might use at some point, and somewhat better financial terms for what is, let’s face it, a tiny email list.