Hacker News Reader

Comment by sdeframond | Hacker News Reader

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.

View on HN

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.

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.

> 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.

Your argument is "I once saw someone do stupid FP, and it is all I have seen. Therefore, I believe all FP is stupid."

And this article is - Oh so you don't like FP do you? Have all the side effects in the world! You don't worship at the church of monad? I guess no "pure" functions for you then! bwa hahah

> 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.

OK, I'll give an example.

Every so often I encounter some dev that is not familiar with SQL. So instead of writing a single SQL and relatively "simple" SQL request that does the job db-side (say with a few joins and coalesce but no sub-query), they write several requests then process the result in python.

The argument ? "SQL is complicated, it is simpler to just do it in Python."

Is it though ? I guess it depends on the request and the exact processing we are talking about but in many cases I suspect it is because that person is not familiar with SQL.

What "simple" means is not so simple to define. Sometimes it means "easy for me".

> 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.

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.

Absolutely not true.

Case in point, a ledger, like a spreadsheet but simpler, hasnt 'crumbled' in a hundred years despite being as basic as it gets.

Simple is good when it's fit for purpose.

Sounds like your idea of simple is just bad code that is unfit for its purpose. Theyre not the same thing.

> a ledger, like a spreadsheet but simpler, hasnt 'crumbled' in a hundred years despite being as basic as it gets.

Yet, for many reasons, your bank does not run your account with a spreadsheet.

> Sounds like your idea of simple is just bad code that is unfit for its purpose

Not quite. Simple is good. Do simple. But some things cannot be achieved with familiar tools. Sometime it is simpler to use an abstraction that is difficult to grasp, initially, than to write piles of code "the way we are used to" because we are afraid of "making others think".

Please make me think, but only if it is worth it.

The problem has nothing to do with the code being simple, but with it being unfit for purpose. You're conflating two separate issues.

Reply on news.ycombinator.com