It’s been a busy month, some top quality conferences – Code Mesh, Build Stuff, FuncBy and NDC London – all cramped into the space of 4 weeks. It has been a blast, lots of talks and valuable takeaways, and it was great to hang out with old friends and meet new ones. As soon as I find time I’ll put together some posts with my key takeaways from the conferences.
During these conferences, Kevlin Henney’s numerous talks have left a lasting impression on me. In his “Seven Ineffective Coding Habits of Many Programmers” talk at Build Stuff, he described the lack of visual honesty in code such as these:
public int howNotToLayoutMethodHeader(int firstArgument,
and on what visual honesty means, he presented a number of quotes from Daniel Higginbotham’s excellent Clean Up Your Mess website:
“To answer the question “What is clean design?” most succinctly: a clean design is one that supports visual thinking so people can meet their information needs with a minimum of conscious effort.”
“You convey information by the way you arrange a design’s elements in relation to each other. This information is understood immediately, if not consciously, by the people viewing your design.”
“This is great if the visual relationships are obvious and accurate, but if they’re not, your audience is going to get confused. They’ll have to examine your work carefully, going back and forth between the different parts to make sure they understand.”
The quotes talk about laying out information so that their visual relationships are obvious and accurate.
So if you layout your method arguments in such a way that their visual relationships are not accurate and you do that purposefully, then you’re in fact being dishonest.
As I sat there, I finally understood why F# pipes are so awesome. I always knew it makes cleaner and more readable code, it’s intuitive, but I haven’t been able to find the words to explain why – the trouble with being able to understand something with minimum conscious effort is that your conscious mind can’t explain how it understood it.
Not anymore, now I finally understand it.
When we’re reading a piece of regular English text, we’re reading from left-to-right, then top-to-bottom. This convention controls the flow of information we receive as we read, so when we’re laying out information for people to consume, we lay them out in the order of left-to-right, then top-to-bottom.
But what about code?
When it comes to writing nested function calls, somehow this flow of information has been reversed!
With F#’s pipes (which has been adopted in both Elm and Elixir by the way), we have finally managed to restore some sanity and present sequence of function calls in a way that matches the way we consume any other textual information.
Visual honesty right before your eyes!
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong