I don't know.

On the one hand, this stance seems common sense: why overcomplicate things? Let's just do what's commonly understood and move on.

On the other hand, writing code that the most junior in your team can understand leads to mediocre code. In the end, it crumbles under its own weight.

Most of what we master now was difficult to understand first. Should abandon generics because "it's difficult" ? Should we ditch static typing because "we're not used to it" ?

Maybe.

Or, maybe, this is the right tool that can take us to the next step. So we pause and think at this new approach to understand it then master it.

▲

darepublic 10 hours ago | parent | next [-]

I don't really believe this but ok. I worked at a functional / typescript heavy shop where when I had parsed what a complicated set of steps was doing discovered multiple redundant queries and a library that was parsing strings into code. But damn some of those functional paradigms chef kiss /s. Imo my dumbass code , besides being demonstrably more performance was way less of a liability.

	▲	yobbo an hour ago \| parent \| next [-]
		Your argument is "I once saw someone do stupid FP, and it is all I have seen. Therefore, I believe all FP is stupid."
	▲	sdeframond 9 hours ago \| parent \| prev \| next [-]
		Sure, replace functional/generics/static typing with your poison of choice. Just remember that, at some point, the "dumbass" thing was pushing sticks into clay tablets. Functional programming may not be the future. But dismissing other's code because it is not done "the way we are used to" is stupid.
	▲	BoiledCabbage 5 hours ago \| parent \| prev [-]
		> I worked at a functional / typescript heavy shop where when I had parsed what a complicated set of steps was doing discovered multiple redundant queries and a library that was parsing strings into code. But damn some of those functional paradigms chef kiss /s And I've worked at a place where the imperative code was crap. Should we abandon all imperative code because I had that experience? People can write bad code in any paradigm - that's not what decides how we should code. Nobody says we should throw away all imperative code because of one poorly implemented code base. But for some reason I see that targeted at FP all the time.

▲

jjav 7 hours ago | parent | prev | next [-]

> On the other hand, writing code that the most junior in your team can understand leads to mediocre code.

Disagree on a couple levels. First, while the overall architecture of the system might be complex, there shouldn't be any one single function that isn't readily readable by a junior new hire. Complexity is in the system, there should be no complexity in small sections of code.

Second, the ultimate level of mastery is to be able to build simplicity. Any newbie can write a convoluted mess that nobody can understand.

▲

cyberpunk 8 hours ago | parent | prev [-]

> On the other hand, writing code that the most junior in your team can understand leads to mediocre code.

Sorry but this is absolutely false in almost all regular corporate software jobs.

As i get greyer, I find myself spending much more time planning before I write any code now; what I would previously have run into headfirst and solved with a bunch of advanced language features and complicated logic usually now ends up being implemented in much less and simpler code.

This is the sign of a senior developer, in my book.

Writing code anyone finds hard to understand is a marker of inexperience to me.

	▲	sdeframond 8 hours ago \| parent [-]
		If the problem can be solved efficiently with simple, write simple code by all means. Heck, if it can be solved with a spreadsheet, please use a spreadsheet. Even your boss can read it. But, at some point, spreadsheets crumble and become unmaintainable. And so does "basic" code. Should people keep on using spreadsheets ? Depends.