Ciao!
Have you ever had the chance to watch someone horse riding? Lately, I've been doing so while having breakfast at one of my favourite spots in the outskirts of Krakow. In particular, I've been trying to deconstruct how the rider signals to the horse to stop and to go. Being it a school, I'm used to see both amateurs and experts. They both manage to ride their horses. But, as you can imagine, only the experienced ones make it seem easy and natural.
I'm sure you have a similar experience with software. Maybe it's the name of a variable, the use of an idiom or the architecture. But you would be able to tell apart good code from bad code. The former speaks clearly to you, while the latter requires investigative work.
When you are done with palaeontology, then it's your turn to write some code. You are tasked with communicating to the computer what to do. Unfortunately, the feedback loop is not as short as what I see at breakfast. When the rider makes a mistake, the horse would let them know instantly. A mistake in software, I don't like to call them bugs, can be more problematic.
Have you ever had a conversation with the Elm compiler? I highly recommend it, not only it produces the best error messages you have ever worked with. Also, it can help writing software that is correct by design. Give the post a read even if you are not using Elm, the same pattern can be used in other languages too.
Elm Tricks from Production–Declarative, Bug-Free User Interfaces with Custom Types - How to use custom types to keep the interface declarative and avoid bugs.
If you ever spent days trying to understand that piece of code nobody has ever had the courage to touch, then you would know how naming abstractions too early can be problematic. Some other times, it's us walking right into the trap: we are in the zone crafting one of the best solutions ever but we drop out of the creative flow just to spend hours seeking the perfect word in the English dictionary. There is a better way, let me tell you how.
Naming Things Made Easy - Naming things belongs to the editing phase not the writing one. Doing it too early is unproductive and dangerous. Here's why and how to fix it easily.
Do you use spaces or tabs? I swear, out of all the things I miss in life, talking about indentation or the ordering of imports is not one of them. Let's just avoid that conversation altogether.
Haskell: Automatic Code Formatting (with Ormolu)
# Show commits more recent
# than a specific date.
git log --since "2 weeks ago"
# Show commits older
# than a specific date.
git log --until "2 weeks ago"
# Stash with a descriptive
# message.
git stash push -m "some message"
# list the stash entries
git stash list
# remove all stash entries
git stash clear
# stash including untracked files
git stash --include-untracked
# Stash including untracked and
# and ignored files.
git stash --all
I've never done any PHP in my career. But it turns out, when communicating you also need to deal with dialects. Or else some people could get really angry. From If PHP Were British:
PHP developers in Britain have been grumpy about this ever since. What was he thinking? And more importantly, how do we undo this travesty? How do we developers ensure the traditions of the British Empire continue to be upheld, even in the digital age?
So what's the thing with horses? Is it about the hips? No. Really. Hit reply and let me know! What's your theory?
The best part of email is that interaction is personal and one button away. So please reply with your thoughts, let's learn from each other.
Thanks for spending some time reading with me. Talk to you soon.
Yours truly,
Riccardo.