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.
Conversation
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.
2
2
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.
When I've helped run events I've always been very vocal about who I give my free labor to.
Community members,individuals? Always.
Companies? Not all companies are equal, so maybe.
In general, only if our interests align, and only if I want to, because *I'm volunteering here*.
1
1
For the same token, I'm very happy to contribute to "commercial" conferences that generate value for the community instead of capturing it all for themselves, and which are themselves community members in good standing.
1
1
Show replies