Write Junior Code • Hacker News Board

Re: Write Junior Code

#141

Post by np_tedious » Tue, Dec 31, 2019, 5:48 PM UTC

pizlonator wrote: post #44

I think that it’s important to hire people who are comfortable with the whole language that you are using. I also think that “junior code” could mean the opposite of what the author means. Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Lots of senior devs stick to a known (and canonical to them) subset of features that proved themselves in b…

> Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people.

Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme that fits the bill, very simple types, very few advanced combinators and symbols, etc.

It definitely could be better, but it suffers from a lack of fanciness rather than an excess. I've peeked at some expert solutions posted online and they are neat and super impressive... but by and large they confuse the shit out of me.

I have a hard time picturing being overly ambitious as a common beginner flaw in this space.

Re: Write Junior Code

#142

Post by pizlonator » Wed, Jan 01, 2020, 8:29 AM UTC

np_tedious wrote: post #141

pizlonator wrote: post #44

I think that it’s important to hire people who are comfortable with the whole language that you are using. I also think that “junior code” could mean the opposite of what the author means. Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Lots of senior devs stick to a known (and canonical to them) subset of features that proved themselves in b…

> Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme t…

Different folks take different paths. In any language, you will find folks who start out by kinda overshooting before they learn to tone it down.

It’s not that all Juniors are this way. Maybe some get it right or maybe they even act too skidding. But I think of it as a Junior trait to sometimes overshoot on complexity.

Re: Write Junior Code

#143

Post by crimsonalucard » Wed, Jan 01, 2020, 4:41 PM UTC

3fe9a03ccd14ca5 wrote: post #76

monoideism wrote: post #70

Earlier quoted context omitted.

> For a reader point-free is appalling and way too clever. I used to believe this, but as I started to read more and more Haskell, I realized that I just had to get used to that style of writing Haskell. I now read it fine, in general. Learning to read point-free is a learnable skill. Tons of non standard sigils, on the other hand, is a bane.

> I realized that I just had to get used to that style of writing Haskell. I now read it fine, in general. The question of course is how true is this for the general engineering community ? Reminds me in some ways of survivor bias: those that stick successfully with Haskell tend to see the shortcomings perhaps as virtues.

I think it's true in general. Point free style is just different from other programming styles it's not particularly unreadable.

Haskell definitely has issues, but I agree with the parent on his opinion on point free style.