Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write Junior Code

parsonsmatt.org

Post reply on HN
Print view View original

81–90 of 143 posts

Re: Write Junior Code

#81

Post by square_usual »

didibus wrote: post #71
reikonomusha wrote: post #28

This might be a little bit of a “hot-take”, but if idiomatic code written by a competent senior engineer remains inscrutable and unmodifiable after around 2 weeks of training an engineer who is at the beginning of their professional career, then that language is probably a bad choice to use in production. If lenses, MTL, fancy concurrency are “the way” to do things in Haskell, and those require an extraordinary amoun…

Now, I'm not particularly a fan of Haskell, but I think it is disingenuous to compare it apple to apple. Most junior devs had multiple years of training in imperative OOP languages prior to joining a company. So if they join a place that uses C#, and they don't know C#, but they already know how every single feature and concept of C# works, well ya, they'll be proficient in two weeks. Similarly, had they'd been thoug…

GP's comment talks about how Lisp passes the two week test. Not really apples to apples with Haskell, to be sure, but it still is significantly different from C#.

Re: Write Junior Code

#82

Post by monoideism »

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 don’t think Haskell will ever be a language used by the general software development community.

For the record, my primary languages now is OCaml (and to a much lesser extent, functional Scala). But I like reading Haskell code. There are a lot of good ideas there (and no, my Scala/OCaml isn’t loaded down with custom sigils).

Re: Write Junior Code

#84

Post by Rapzid »

TeMPOraL wrote: post #38
reikonomusha wrote: post #28

This might be a little bit of a “hot-take”, but if idiomatic code written by a competent senior engineer remains inscrutable and unmodifiable after around 2 weeks of training an engineer who is at the beginning of their professional career, then that language is probably a bad choice to use in production. If lenses, MTL, fancy concurrency are “the way” to do things in Haskell, and those require an extraordinary amoun…

Or, just don't hire junior developers :). This reminds me of what my boss from my second-ever job told me when he tasked me with starting a new project: "I know I promised you you'll get to choose your own tech stack, but you're going to write it in PHP; I know you'd like something better, perhaps Ruby, but when it comes to hiring developers to help you, I'll have to pay a Ruby developer $X, and I can get PHP develop…

"Junior" might as well be an IQ classification.. How many people change their IQ?

The reality is something nobody really talks about.. When a company doesn't want to hire a "junior" it doesn't mean they don't want to hire somebody without X amount of experience in a tech stack or without X amount of experience in the industry.. They don't want to hire people bellow a certain aptitude.

Many "juniors" will never be "senior". Even if they get the title and salary. We all know "seniors" in salary and title only.

Some people are inexperienced "seniors" year one.

Re: Write Junior Code

#85

Post by edflsafoiewq »

monoideism wrote: post #80
millstone wrote: post #72

Earlier quoted context omitted.

There's definitely a vein of deliberate unreadability. Types and parameters are often labelled positionally instead of given meaningful names. For example the graph library fgl uses typenames 'a' and 'b' instead of useful names like 'NodeLabel' and 'EdgeLabel'.

OK, those are poor stylistic practices, but they’re orthogonal to point-free style.

It is related. In point-free style the "omitted" parameters have to be distinguished positionally; they have no names at all, not even 'a' or 'b'.

Re: Write Junior Code

#86

Post by ehnto »

This is why I advocate for popular frameworks in commercial projects, even though I don't prefer writing in them myself. Sure, it's easy to find people who know {Language}, but everyone has their own idioms, and they will need to spend time learning yours.

A framework has the benefit of having existing documentation you didn't have to write, an existing community of people solving problems the framework may have, and most importantly a slew of idioms that are literally codified and documented.

Do things "The {Framework} Way" and when you onboard someone familiar in {Framework} you should only have to help them with the domain space knowledge and any novelties of your specific implementation. You still get to use advanced concepts, but hiring and onboarding is significantly simplified.

For personal projects, I never use frameworks, it's not nearly as fun as writing greenfields code. But in a commercial project, long term viability of the project should probably come before fun.

Re: Write Junior Code

#87

Post by reikonomusha »

eru wrote: post #79
reikonomusha wrote: post #33

Earlier quoted context omitted.

No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in production code. A few prominent macros we do use: - A macro to define a string lexer (aka tokenizer) for a programming language - A macro to define peephole optimizations of linear instruction code - A macro to define friendly looking bindings to Fortran function…

That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros? (Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)

It’s true that in a lazy functional language you can get by with fewer syntactic extensions for common programming patterns, but it doesn’t, at the end of the day, actually solve the problem of syntactic extension or code generation.

Re: Write Junior Code

#88

Post by reikonomusha »

didibus wrote: post #71
reikonomusha wrote: post #28

This might be a little bit of a “hot-take”, but if idiomatic code written by a competent senior engineer remains inscrutable and unmodifiable after around 2 weeks of training an engineer who is at the beginning of their professional career, then that language is probably a bad choice to use in production. If lenses, MTL, fancy concurrency are “the way” to do things in Haskell, and those require an extraordinary amoun…

Now, I'm not particularly a fan of Haskell, but I think it is disingenuous to compare it apple to apple. Most junior devs had multiple years of training in imperative OOP languages prior to joining a company. So if they join a place that uses C#, and they don't know C#, but they already know how every single feature and concept of C# works, well ya, they'll be proficient in two weeks. Similarly, had they'd been thoug…

I agree that if our educational institutions changed with respect to what’s taught around programming fundamentals, advanced Haskell would be easier to digest more quickly for someone just coming out of school. My point is sort of that that’s not the case, which potentially makes Haskell a tougher sell for the graduates of today.

Re: Write Junior Code

#89

Post by michaelmrose »

Eikon wrote: post #51
mcqueenjordan wrote: post #49

Earlier quoted context omitted.

> Or, just don't hire junior developers :). 1. You miss a lot of great talent this way. 2. Growing and developing juniors is part of what makes a "senior." 3. This isn't sustainable advice -- if noone is hiring juniors, then where are the new seniors coming from?

> 3. This isn't sustainable advice -- if noone is hiring juniors, then where are the new seniors coming from? Well, as much as it is short sighted, the really is that letting some other company spend money training juniors is money you don’t have to spend.

If this is truly a profitable choice why are you assuming anyone will do it?

Re: Write Junior Code

#90

Post by qafy »

reikonomusha wrote: post #28

This might be a little bit of a “hot-take”, but if idiomatic code written by a competent senior engineer remains inscrutable and unmodifiable after around 2 weeks of training an engineer who is at the beginning of their professional career, then that language is probably a bad choice to use in production. If lenses, MTL, fancy concurrency are “the way” to do things in Haskell, and those require an extraordinary amoun…

Pragmatism is priceless in large scale production systems. I just recently started a new job as a front-end engineer where we use Go for all our backend services. I have never used Go before, and likely won't much in the future either, but I absolutely love how absolutely dead simple it is. You've got conditionals, loops, structs, slices (arrays), and functions, and that is about it. Even though I don't write Go code I can still read, understand, and reason about all our systems. The same cannot be said about your average junior or front-end dev trying to understand Haskell or Lisp or other obscure high level languages.
Post reply on HN