“…Rather than dismissing this challenge as “a bad fit for functional programming”, it is what led to a better solution…”
There’s something very interesting going on here.
When I used to do Agile Technical Coaching, I didn’t have the answers to everything, but I realized that other teams were using these same techniques to do most anything. Being a technical guy who knows business, they gave me all kinds of weird teams. With each of them, if I got lost we would simply agree to figure out what other folks were doing. It was possible, even if it wasn’t completely obvious right now.
That always worked. And it always led to fast, high-performing teams.
I found the same thing happening when I started programming in pure FP in F#. Many times I wouldn’t know how to do it, but I would know that it’s possible. And probably better. When I first started and got into a spot like this, I’d code up a class with mutable stuff in it. I’d end up writing C#-in-F#. It sucked, but it sucked in a way I was used to.
Then I started learning how to pick apart the functional code smells. Every time when I did this I would end up with some really cool, brief code that did something useful in a small number of lines. Every. Time. Sometimes the code simply disappeared: I realized what I thought was a program was just a few lines of O/S batch code. No code = no bugs. I tell people that I love F#. I love it because it teaches me to be a better programmer. (Of course it has nothing to do with the language itself. It’s because it’s a hybrid OO/FP language)
“…rather than dismissing it … it is what led to a better solution….”
Having faith that it could be done better, combined with some simple rules, led to some really cool solutions and knowlege. I wonder how many programmers and teams never realize this. Do most coders and teams get the dang thing working, then walk away or go to the next feature? If you spend a few years coding in this fashion, are you teaching yourself to become a better or worse programmer?
“…Rather than dismissing this challenge as “a bad fit for functional programming”, it is what led to a better solution…”
There’s something very interesting going on here.
When I used to do Agile Technical Coaching, I didn’t have the answers to everything, but I realized that other teams were using these same techniques to do most anything. Being a technical guy who knows business, they gave me all kinds of weird teams. With each of them, if I got lost we would simply agree to figure out what other folks were doing. It was possible, even if it wasn’t completely obvious right now.
That always worked. And it always led to fast, high-performing teams.
I found the same thing happening when I started programming in pure FP in F#. Many times I wouldn’t know how to do it, but I would know that it’s possible. And probably better. When I first started and got into a spot like this, I’d code up a class with mutable stuff in it. I’d end up writing C#-in-F#. It sucked, but it sucked in a way I was used to.
Then I started learning how to pick apart the functional code smells. Every time when I did this I would end up with some really cool, brief code that did something useful in a small number of lines. Every. Time. Sometimes the code simply disappeared: I realized what I thought was a program was just a few lines of O/S batch code. No code = no bugs. I tell people that I love F#. I love it because it teaches me to be a better programmer. (Of course it has nothing to do with the language itself. It’s because it’s a hybrid OO/FP language)
“…rather than dismissing it … it is what led to a better solution….”
Having faith that it could be done better, combined with some simple rules, led to some really cool solutions and knowlege. I wonder how many programmers and teams never realize this. Do most coders and teams get the dang thing working, then walk away or go to the next feature? If you spend a few years coding in this fashion, are you teaching yourself to become a better or worse programmer?