[bbcbasic]

I like your definition because it is timeless and rings true. The same definition will apply in 10 or 20 years time when there are new fads in development processes, programming languages etc.

I would add that the senior engineer has a mature approach to selecting/recommending tools and frameworks, based on what is most valuable for the business and the team, rather than was is cool, good for their career or whatever.

[CaRDiaK]

"selecting/recommending tools and frameworks, based on what is most valuable for the business and the team" This is so true, I would say it extends to style amongst other things also. Having worked seniors on teams who had to seemingly make problems "worthy" of their skill and time served. For example working on a large OO Monoliths where a senior started to add lots of "clever" functional code. When I started the question the reasoning behind it I got a lot of instant defensive flack off them because "it's a better way" and "I'm arguing against correctness" they didn't seem to want to understand that we had 50 mid level to junior devs who also had to support this who would require a lot of help to read or follow it, thus slowing the entire team. They didn't seem to care for the reasoning of it being better "for the team" to just carry on with the agreed OO standard.

It's not that I thought they were wrong in what they had to say, just there is an appropriate time and a place and being able to make that call is just as if not more important than the style of functionality being added. I find such seniors can be toxic at times. In essence there is more to being a senior than just being a great coder.

[merb]

> For example working on a large OO Monoliths where a senior started to add lots of "clever" functional code.

Adding a simplier design with functional code is a good thing. If there is a mid level developer that can't follow the current state of the art, than he is not a good mid level developers. Also "good" junior developers have mostly zero problems in understanding more functional code. I mean you don't need to understand Applicative Functors to use map/flatMap.

I mean there is a line which you should not cross too fast when introducing functional stuff, however most people just don't even try to understand the simple stuff even that it is way more simple than most while/for loops.

[Nemcue]

You need to realize most mid- and junior programmers simply aren't good.

[marcosdumay]

And that means they aren't good, not that the person using good practices isn't good.

If it is a business requirement that good developers must be slowed down for bad ones to catch up, then do it by encapsulation and mentoring. Not by decreeing that good developers must act exactly like bad ones.

[tukelully]

It appears worth noting to the people arguing for functional programming over OO in response to this, that this is about toxicity within the team and maturity of the developer. Not programming style in so much as I can read.

It should also be mentioned that responses similar to the examples have approx. no substance, detract from the quality of the conversation, provides no value to the team, and will likely only decrease mutual trust and respect.

[marktangotango]

Yes I have lived this recently, two devs competing for most clever code in an oo codebase, it was a spaghetti lava layer mess of styles, and one was the lead. Horrible experience.

[jscn]

Even better when they both leave and you inherit responsibility for the project!

[kikkak]

Do you work at my company? This is what I experienced last year on a project being run by another team's lead developer. The system that was so poisoned with needless functional abstractions that the codebase was barely comprehensible (monoids, kleislis, higher-kinded types, dynamic types(!)). It's utter fucking rubbish. He practically mounts an invisible pulpit when he talks about why these abstractions and constructs are the "right way" and "the future." I don't know how he got "lead" in front of his title. Pretty much every junior in our group is more productive than he is.

The only consolation is that the system in question hasn't entered production yet, and probably won't for at least a year at the rate it's progressing.

[barrkel]

If you're working on code that is logically shaped like a transformation or a stream, functional is so far superior to an OO approach it's not even funny. One person can accomplish what 10 people would struggle in OO to do if the solution is structured properly, because of the composability and modular testability benefits.