The "convoluted code" gauge is a double-edged sword. You could also be working at a company with developers who have no experience with the benefits of functional programming. In this scenario it's those who write nested loops, branching if-statements, and mutating side-effects that are in charge and you're the bad developer for using fold and map. You could be seen as an elitist who likes to write clever, obfuscated code that nobody else can comprehend.
Not all positive contributions are worthwhile. One could simply blend in and add one more level of nesting, one more conditional, and mutate a few things here n there. After all, everyone knows what a for-loop is, right? Staying productive is important!
Well... until your most productive hours are spent chasing down errors you and your team designed.
There is a lot of value in conforming to however the existing code base is written. Some of the worst (in terms of time/money spent maintaining) code I've seen is code that sticks out for being different, even if it's arguably faster / more modern / uses better practices. Some C++ examples because that's in my wheelhouse:
1. Entire code base is "C with classes" or OO, but That One Guy on the team insists on sprinkling functional programming constructs all over the place. Now there's a huge overhead for the rest of the team who need to switch gears every time they encounter that code.
2. That One Guy who insists on doing everything with macros in a code base that otherwise makes very light use of the preprocessor.
3. Company standardized on using the C++ constructor to initialize classes, but That One Guy writes a seperate init() method on each of his classes and leaves the constructors empty.
4. (iOS/Objective-C example) Entire code base uses old-school delegate callbacks but That One Guy needs to write all his stuff using the arguably better block style.
It could be even as silly as:
5. Entire code base uses camelCase for variables and function names, but That One Guy insists on using_underbar_style. Now every time you have to call something or pass a variable around you have that tiny bit of overhead double checking which style needs to be used.
Functional programming does have some useful syntax and principles that can make code easier to reason about. But a much bigger red flag is if a developer is so fixated on a certain programming philosophy or methodology that they don't pay attention to writing simple, good code.
> that they don't pay attention to writing simple, good code.
Amen. If you have a complex problem to solve, and the style is between obfuscated FP and complex OO, the choice is already a bad one. If the code can't be written very clearly, probably the problem is posed wrong, or shouldn't be solved because the maintenance costs will be too high anyway.
The negative contribution developers I find are those that don't challenge the formulation of the problem. This takes some confidence to rather challenge a manager with a better design, rather than actually write a complex solution to a problem to get a pat on the head.
So the most dangerous developers in my book are those that like the pats on the head they get from solving complex problems by writing complex solutions.
> The negative contribution developers I find are those that don't challenge the formulation of the problem.
Couldn't agree more. Furthermore, sometimes the best code is no code at all. If the code has 0 lines, it will not contain bugs, and will not take time for bug fixing and maintenance.
Functional programming is nice, though I tend to find a procedural code easier to read than it's functional counter part. There is a place and time for mutation of state and their are other times when just simply duplicating data for clarity is much more straight forward.
To be fair, many debugging tool chains are crap with folds and maps instead of loops. And code is rarely written in anger, but often debugged that way.
Debugging can bring out the worst in the best of us.
Luckily I don't often have to debug code from functional programmers. The errors are usually mitigated by design and often easier to spot or reason about than in a function with a dozen branches mutating the object behind a pointer.
The reason I call it a double-edged sword is because the majority will determine what is normal or acceptable. If you come to their office expecting to reveal the shadows on the wall you may very well find yourself looking for another office elsewhere.
The harrowing difficulty is in bridging the gaps between each other and our differing approaches to developing software.
You can write functional code with dozens of branches too. In my opinion this is because functional programmers are usually enthusiasts and good programmers. If all programmers start to write functional code you will hate it too.
Are you suggesting that all functional code is readable/more readable? It has its merits for sure, but I have seen many functional monstrosities... some that have even caused plenty of negative work themselves!
What I am suggesting is that the majority of people at a company will decide what styles of programming are "convoluted." According to the article the programmers who write convoluted code are the ones having a negative impact. The double edged sword is the allegory of Plato's Cave: you might actually be bringing the team great ideas about how to improve their code but it will be useless if they can't see the shadows on the wall for what they are.
While I may be biased and find that functional programming styles are better I realize it takes all kinds to make a working system together with other engineers. The difficulty is in communicating these ideas and pulling the team together to see the merit rather than the shadows.
Not all positive contributions are worthwhile. One could simply blend in and add one more level of nesting, one more conditional, and mutate a few things here n there. After all, everyone knows what a for-loop is, right? Staying productive is important!
Well... until your most productive hours are spent chasing down errors you and your team designed.