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.
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.
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.