FP has completely failed in a lot of businesses, in loud expensive ways. Where the devs thought they had all-in-one magic software beans, instead of great ideas that still need to be complemented with the same good sw delivery practices, archtre and social hygiene as before. /9
Conversation
Exp. industrial FPers become deeply suspicious of the fancy ideas and come to favour the most boring and sensible simplicity. About time! And what they are crying out for now is better tooling, doco, onboarding, usability, stability, same as everyone; not new abstractions. /10
4
2
24
I used to be in this camp - am finding that the slightly fancy types of squeal and servant are really valuable in terms of type safety from http to database. capturing the semantics of widely-used systems, like http and postgres rather than internal business logic is key.
1
4
Yeah I ran out of space for qualifiers like "mostly", "tends to", etc. I'm not trying to proclaim absolutes. I think if you put all the intermediate FP code next to all the experienced FP code, on average you would find a lot of fancy nonsense on the intermed side of the table
2
5
And to get that intuitive sense for when fancy things are/aren't appropriate you need to learn from your own mistakes... one way this can work out is if people do their experimenting at home and stick to the tried-and-true at work. But as a company you can't *expect* that.
1
3
So if a company has any smaller/less-critical/throwaway/etc. projects maybe it's overall prudent to explicitly declare those as "go wild and learn things" zones?
1
1
Businesses are 100% entitled to expect devs to be professional and unselfish in their tech choices. The onus is entirely on devs, we're not puppies
1
Yes, "do not use the business's codebase as your playground for experimentation" is eminently reasonable. What I'm suggesting is that businesses also have an interest in their employees leveling up their skills. And the two things are somewhat in conflict:
1
3
If they never use fancy features at work, they'll never gain the experience that lets them know when the feature *would* be profitable to use.
2
Hence the idea of distinguishing e.g. mission-critical vs. non-mission-critical projects, and explicitly accepting greater risk-via-experimentation in the latter in exchange for greater quality/productivity (via increased dev skills) in the former.
1
2
Yeah, I hate the idea that the only people who get to explore new ideas are those who have enough disposable free time to spend it experimenting with dev stuff in the off-hours. It isn't healthy to do this for many people, and is completely impossible for many others.
Privilege wrt free time is a good argument, I didn't think of that. But you're ultimately still spending someone else's money
1
Yup! And businesses should be willing to pay for that, and invest in the growth of their people, and the craft of programming. By doing that work in our off-hours we devalue the important work of developing new techniques and practices.
1
Show replies
To apply a bit of nuance, as long as the stakes are just "getting to explore new ideas or not" i.e. recreation in a sense, I don't think there's much issue *beyond* the basic "people have different amounts of free time" unfairness.
1
1
Where it becomes problematic is if they're *expected* to know those things without having been given the opportunity to learn them other than on their own.
2