[smadurange]

I think one should write the code that's most suitable for a specific scenario. Senior vs junior has nothing to do with this (at least not in a categorical way). I have met many who call themselves seniors who really just aren't as good as they think they are.

The best engineer I've worked with sometimes wrote simpler code and sometimes wrote highly sophisticated code. If there's someone on the team who can't understand a particular piece of code, he should just ask and learn. There's no reason to weigh someone down just to make an inexperienced, incompetent programmer or unwilling to learn something happy.

Good code isn't junior code. Good code isn't senior code. Good code is just what works best in a specific scenario. And it takes experience and details of a problem to decide what that is exactly. Dogmatic, rigid views just don't work well in this line of work.

[didibus]

Agreed, I'm not a huge fan of junior/senior. What we should be talking about is inexpert/expert, which doesn't always map 1:1 with how long you've been working, or practicing. Though obviously, the longer, the more likely you learned and became more knowledgeable. But some people spend 10 years doing the same thing over and over, and that's not broadening and deepening their skills the slightest.

So in my opinion, there is two type of unreadable code, there is the code that's just plain bad, convoluted, overly complicated, like a Rube Goldberg machine. That one is often written by inexpert programmers, sometimes they are juniors, and sometimes they're senior as well. And then there is code that you personally can't read, but which is great code, simple, coherent, to the point, etc. You just haven't learned the vocabulary and grammar to understand it.

[ukoki]

> If there's someone on the team who can't understand a particular piece of code, he should just ask and learn. There's no reason to weigh someone down just to make an inexperienced, incompetent programmer or unwilling to learn something happy.

Writing simple code isn't about allowing juniors to be "lazy". Simple code is a business decision. The easier it is to contribute to a codebase:

* the more of your existing staff are able to contribute

* the easier it is to hire people able to contribute

* the cheaper your staffing costs

* the quicker it is for new staff to contribute

* the more resistant you are to staff turnover

* the more resistant you are to changes in the relative popularity of programming languages and libraries

* the cheaper it is to pay off technical debt (because rewrites are easier)

Lowest-common denominator code should be the rule, not the exception. There is definitely a place for "fancy" code, but it should be very carefully considered.

[elbear]

I think the point of this article escapes anyone who doesn't know Haskell or a language with a similar type system. I don't want this to sound elitist, because it's not my goal, so I will clarify.

In most languages, the abstraction ladder is short. You have built-in types and user defined types. Those user-defined types are almost always product types (think of structs in Go, or classes in OOP languages). Haskell also has sum types, which allow you to express things like:

  data TrafficLight = Green | Yellow | Red

Other languages have interfaces and Haskell has type classes which work in the same way.

Then come advanced type-level features: data kinds, type families, generalised algebraic data types and many others. Here's the table of contents of a book that deals with type-level programming in Haskell: https://thinkingwithtypes.com/

These concepts allow you to encode more logic at the type level. But they come with the cost of needing to understand them.

You can make a choice to write Haskell without these advanced type features. Maybe you lose some type safety or maybe you repeat yourself more. But the upside is that you use fewer concepts that need to be understand by someone who needs to work on the codebase.

These are the juniors the author is referring to. I'm a junior as well in this regard, because I don't know all these type-level features, even though I've used Haskell professionally.