Functional programming, building spaceships & the value of writing

Welcome to the first issue of Growing the Stack! For the past few months, I’ve been looking for a new home to share articles, projects, podcasts, or other things that leave an impression on me.

I considered adding them to my blog, but I’d rather keep that for original, long-form content. Twitter on the other hand feels like shouting into an abyss. After further consideration, I think a newsletter will be the perfect fit.

Growing the Stack addresses anyone interested in programming, design, or other related topics. It tries to bundle content that inspires, content that triggers you to consider and try out new ideas.

I’m aiming for quality over quantity: three links, every two weeks. I’ve never curated a newsletter before, so I’m very excited to see how this is going to pan out 😀

Enjoy the first three links of Growing the Stack! This week we’ve got two technical articles, and one about creating a writing culture in your company.

Building blocks

Functional programming fascinates me. In many cases, a functional solution feels like a better solution to day-to-day programming problems, but it’s hard to fully apply them in an object oriented language.

That said, keeping some core FP ideas in mind will help you write cleaner code in any environment. Steven Vandevelde explains a few basic concepts accompanied by beautiful illustrations to visualize it all with Lego blocks.

This is a more visual approach to the topic of purely-typed functional programming. What does it mean to have a “functional” programming language? What are types? What makes a functional-programming language “pure”? These are the questions we will answer here, with a focus on simplicity.

Akin’s Laws of Spacecraft Design

Dave Akins wrote 42 laws you should abide by when building spacecrafts. I’m not planning to build a spaceship any time soon, but apparently there are a lot of similarities with web development. A few examples:

  • Engineering is done with numbers. Analysis without numbers is only an opinion.
  • Design is based on requirements. There’s no justification for designing something one bit “better“ than the requirements dictate.
  • Don’t do nuthin’ dumb.
  • Space is a completely unforgiving environment. If you screw up the engineering, somebody dies

Well, that last one is absolutely not applicable to the average web developer, but it’s a good one to keep it this in mind next time something goes wrong in production.

Writing is Thinking

Steven Sinofsky started a Twitter thread about a company’s writing culture. In this article, he annotates that thread with further articulation.

The biggest thing about writing down strategic choices is that they serve to build a corporate history (over a year or two, not really thinking about decades). Why decisions are made is rather important because companies, like people, can make the same mistakes over time without history.

This paragraph resonated hard with me, not related to company strategies, but to code. I’ve been working on a few larger projects the past year, the kinds that require decisions which aren’t clear “rights or wrongs”, but benefits and tradeoffs.

It’s important to be able to look back at those decisions. They can be critical for the future of the project; “Why did we create this abstraction? Can’t we just refactor it to something simpler?" A written account could answer that question that in a heartbeat. Or maybe you need to make a similar decision in a different project: your documentation would allow you to hop back in to the decision-making process instead of starting from scratch.