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

111–120 of 143 posts

Re: Write Junior Code

#111

Post by bauerd »

verttii wrote: post #94
bauerd wrote: post #7

Wish there was something similar to Elm, but designed with backend/networking/generality in mind, like Go. Take the Haskell core language without all the lang extensions, and accompany it with a solid stdlib. I want an FP ecosystem that's not rooted in research. Can have a more simplistic type system, etc. Basically a functional Go. Maybe an effect system, idk.

I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do. Btw you may want to keep an eye on this: https://wende.github.io/elchemy/ Honestly, I wish this would get more traction, it seems like an awesome intersection…

You cannot pitch Haskell to the average industry team. It's not so much about technical merit for me

Re: Write Junior Code

#112

Post by TeMPOraL »

nsomaru wrote: post #103
TeMPOraL wrote: post #93

Earlier quoted context omitted.

Viewing it from this lens, it still doesn't make sense to sacrifice productivity of people "with aptitude" for the sake of expanding your hiring pool to include people "without aptitude". Instead of bringing down everything to the lowest common denominator, one can try to assign different types of work to people with different levels of aptitude (or care). (Personally, I feel what makes "forever juniors" isn't aptitu…

> anti-intellectualism in the industry Could you expand upon this point?

A bit more here: https://news.ycombinator.com/item?id=21909816.

But the gist of it is: the industry prefers to work with dumbest tools possible and throw cheapest bodies they can get at a problem, instead of expecting people to keep learning, improving themselves, and applying these improvements to their work. This article is an example of that - it advocates discarding advanced tools given to the programmer by Haskell, in favor of writing dumb code that's easily digestible for beginners. Most of the advice about avoiding "clever code" is a form of that too.

I find it a penny-wise, pound-foolish approach, because when you do this trade-off, you're losing in two places. First of all, you handicap your skilled team members. But secondly, the cost (in terms of time, money and incidental complexity) of a project grows faster than linear with the number of people you get involved in it. It'll be O(n!) if you do it naively, O(n logn) if you arrange people into hierarchies, but the problems still grow faster than they're solved as you scale up.

The alternative approach I'm encouraging is to make responsible but full use of the power of the tools you have, and if this goes over the head of some new hire, then teach them until they understand and can make use of that power too. Embrace and encourage learning as a part of this job (actual, expected, and paid-for part). Push the industry upwards, instead of dragging it down.

Re: Write Junior Code

#113

Post by OJFord »

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…

> then Haskell may not be a good choice

Or a Haskell-illiterate hire, or two weeks' max acceptable 'ramping up time', may not be a good choice.

Re: Write Junior Code

#114

Post by monoideism »

edflsafoiewq wrote: post #85
monoideism wrote: post #80

Earlier quoted context omitted.

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

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

Yes, that's literally the definition of point-free style.

I was referring to labeling function parameters `a` and `b`.

Also, when I checked, that's actually not what the FGL library does. It labels type parameters with `a` and `b`. Labeling generics and type parameters with letters of the alphabet is pretty typical for a wide range of languages (ie, `T` in Java, etc.). Arguably, it's a bad idea, but it's by no means unique to Haskell.

Re: Write Junior Code

#115

Post by monoideism »

nmca wrote: post #107
edflsafoiewq wrote: post #85

Earlier quoted context omitted.

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

^^^^^ This is extremely insightful, and now ranks as the most accurate and succinct explanation I've seen of why point-free is terrible.

It's not extremely insightful. It's literally the definition of point-free style.

Also, Haskell doesn't have labeled/keyword function parameters, regardless of whether or not you use point-free style. Sometimes, people pass in a record to achieve a similar effect, but in general, passing in a ton of parameters goes against idiomatic Haskell style.

Re: Write Junior Code

#116

Post by sanderjd »

Rapzid wrote: post #84
TeMPOraL wrote: post #38

Earlier quoted context omitted.

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 "se…

This isn't forbidden knowledge, it's just not correct. People learn and grow with experience. Some projects can't afford to support many, or any, people in that growth stage. But lots of projects can afford it, and the investment in their growth makes sense. I think it is probably also true that some people never become competent enough for many projects, but in my experience that is diminishingly rare, whereas junior developers who are still developing their skills are extremely common (unsurprisingly, since more and more people enter the field constantly).

Re: Write Junior Code

#117

Post by tabtab »

TeMPOraL wrote: post #40

I have the opposite view. Sure, don't go overboard with power for your own sake . If it ends up a convoluted mess, it's your fault and you should refactor - proper application of powerful language concepts result in clean interfaces hiding complexity that rarely, if ever, needs to be touched again. From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don'…

Re: Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time.

Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger.

Part of it is the fad-driven nature of our industry that whips around what's "in" technology like the tail of a captured fish. Until Fad Cops clamp down on nonsense and excess, it's a young person's game.

Many companies stick with COBOL not because it's better, but because it's stable, like Latin, because it's a "dead language". Nobody comes along and gums it up with spaghetti "Design Patterns" or 7 layers of microservices because "the big boys are doing it!".

Warren Buffett has said part of his success is due to his ability to say "no" when everyone else is saying "yes". He willingly lets others be the guinea pig.

As far as functional programming, it takes a different mindset than imperative programming, and for many there is a relatively long learning curve until they match or exceed their imperative productivity. If programming is a dead-end career, per above, that curve may not be economical.

I personally find functional harder to debug because it's harder to "x-ray the pipes" of intermediate steps, and have not got over that difficulty yet. I personally find it easier to break up imperative code into smaller intermediate steps or parts, subject to inspection via debuggers or Write() statements. Somebody once said: "Functional makes it easier to express what you want, but imperative makes it easier to see what you actually have." That rang so true for me.

Re: Write Junior Code

#118

Post by TeMPOraL »

tabtab wrote: post #117
TeMPOraL wrote: post #40

I have the opposite view. Sure, don't go overboard with power for your own sake . If it ends up a convoluted mess, it's your fault and you should refactor - proper application of powerful language concepts result in clean interfaces hiding complexity that rarely, if ever, needs to be touched again. From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don'…

Re: Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger. Part of it is…

There is something to that, but it applies at the (predicted) end of one's career. But what I'm writing about applies at the beginning - the idea that being forever stuck at a level of skill only a tiny bit higher than what an average developer enters their first job with.

EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming experience is limited to typical for Lisp, Clojure and Erlang, and not e.g. Haskell. With functional code, you just hook up in some place in the pipeline and start leaking what's coming in and out of there to the outside world (stdout, REPL, debugger). Because it's functional, you can be sure you're not missing any hidden state. You can keep replying the calls manually, perhaps tweaking inputs, to identify the problem. After finding and fixing a bug, it's relatively trivial to turn your debugging work into a regression test.

It seems to me that your complaint is less about functional code and more about point-free style, which is arguably a bit more difficult to hook into, but only because debugging tools aren't really optimized for it.

Re: Write Junior Code

#119

Post by tabtab »

TeMPOraL wrote: post #118
tabtab wrote: post #117

Earlier quoted context omitted.

Re: Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger. Part of it is…

There is something to that, but it applies at the (predicted) end of one's career. But what I'm writing about applies at the beginning - the idea that being forever stuck at a level of skill only a tiny bit higher than what an average developer enters their first job with. EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming e…

One has to write code intended for a variety of readers having different skill levels. In practice you have to "dumb it down" to a degree.

Re: Write Junior Code

#120

Post by tabtab »

TeMPOraL wrote: post #43
reikonomusha wrote: post #42

Earlier quoted context omitted.

One of the most enjoyable aspects of my career has been teaching and mentoring engineers with little experience. Everybody starts somewhere, and I would never want to suggest an organization I’m a part of ought to bar a healthy, tempered number of less experienced folk. But, organizations aren’t charities, right? I might like mentoring, but that doesn’t mean it’s the best choice for a company to make. Fortunately, th…

Well, sure. My main point isn't that you shouldn't train hires (you can't really expect to not train new hires). It's that I don't think it's worth it to sacrifice your team's internal productivity for the sake of speeding up the onboarding process and/or making it cheaper - which is what IMO the article is essentially suggesting. The article is about Haskell, but this advice - make code newbie-friendly, avoid "cleve…

In my opinion, Java wouldn't need to use lambdas as often if it had a more powerful object model. You'd define methods instead of pass lambda's as parameters. Lambda's are often a band-aid for a weak object model.

For example, if I want to define an "on click" GUI event handler for a given button, the more natural approach would be to define an "onClick" method for that button's object. But you can't do that in Java in a simple way the way you could in say SmallTalk. Thus, one typically has to send a lambda to a "listener" object, which is unnatural.

Post reply on HN