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

121–130 of 143 posts

Re: Write Junior Code

#121

Post by TeMPOraL »

tabtab wrote: post #119
TeMPOraL wrote: post #118

Earlier quoted context omitted.

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.

To a degree. Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you.

I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption that excavators are evil because a random construction worker won't know how to operate one.

Re: Write Junior Code

#122

Post by TeMPOraL »

tabtab wrote: post #120
TeMPOraL wrote: post #43

Earlier quoted context omitted.

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…

I think the two things you described are essentially identical. Defining a onClick method on an object is equivalent to giving the onClick method a function with implementation in it. +/- whatever shenanigans your object system plays with methods.

Java does indeed have a very weak object model, though it improves slowly over time. But rejecting to use those improvements because it's "clever code" is arguably just dumb.

Re: Write Junior Code

#123

Post by Viliam1234 »

clarry wrote: post #100
TeMPOraL wrote: post #43

Earlier quoted context omitted.

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…

I fully agree with this. I haven't really seen code that is 1) actually useful but 2) so clever that you can't quickly explain why or how it works (or just let the person reading it figure it out or ask stackoverflow...). So I don't really even know what people mean by clever code.

In my experience, a big danger is when someone higher in the company hierarchy is a former developer who no longer writes code.

Such person will perceive the new language features or libraries as "too clever, and not really necessary", will voice their opinion loudly, and you can't make them learn and find out that it's actually simple and useful. (And, yes, lambdas in Java 8 were an example of that.)

Re: Write Junior Code

#124

Post by reikonomusha »

weavie wrote: post #96
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…

As someone who works with a ton of Common Lisp and a bit of Haskell, sure Common Lisp may seem easier to read at a surface level but my god am I a lot more hesitant to make any changes to our code base. Unintended side effects are everywhere. It takes a lot of discipline to write good Common Lisp code. With Haskell, some of the code may be a bit harder to read at first, but I always have the type signatures to help m…

I think good mentorship, good code review, and good tests are critical to anything, including Common Lisp. We are very strict about that and we’ve had excellent results. Non-sense and language game-playing is quickly and earnestly called out, and everybody lives a better developer life.

I’ve been on Lisp teams where that wasn’t the case and it was a free-for-all with macros and other things. That was a disaster and the code base was a gigantic Rube Goldberg contraption. But bad hygiene is possible in any environment, though Lisp has the capacity to amplify it.

Re: Write Junior Code

#125

Post by zzzeek »

clarry wrote: post #101
zzzeek wrote: post #5

To be clear, one of the reasons I decided to focus on Python in the early 2000's was this reason, that I wanted to work within a computing language that was as accessible as possible to the widest variety of programmers, thus helping to ensure that the code I write would be maintainable by others, the libraries I create would be in high demand, and whatever code I write for employers would be maintain a high degree o…

> That is, if you are a programmer writing Haskell code that actually works and does something useful, by definition you are nothing like a "junior" programmer. So what do you call someone writing useful code in Haskell for their functional programming course during their second year of CS? (That is my little sister right now)

Well I was in CS about 30 years ago at this point so I am talking out of my old crusty butt but I recall that while we did fancy FP things in lisp and APL or whatever, the software we wrote was still on a very small scale compared to what you work on once you get into a job and inherit a huge codebase. I think the term "does something useful" is the point of contention on this. We wrote things like, take a document and word wrap all the paragraphs. That is useful. But that's not really a real-world enterprise level assignment.

Again, that's the crusty old perpsective informing me on this, your sister could be building out a self-driving car platform for all I know in Haskell, good on them !

Re: Write Junior Code

#126

Post by tabtab »

TeMPOraL wrote: post #122
tabtab wrote: post #120

Earlier quoted context omitted.

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…

I think the two things you described are essentially identical. Defining a onClick method on an object is equivalent to giving the onClick method a function with implementation in it. +/- whatever shenanigans your object system plays with methods. Java does indeed have a very weak object model, though it improves slowly over time. But rejecting to use those improvements because it's "clever code" is arguably just dum…

I agree there is or can be a lot of overlap between OOP and aspects of functional. With some diligent language factoring, I suspect they can be blurred to be one in the same. That way one doesn't have to learn two different sets of rules and syntax. But, I'm not sure Java can fix such cleanly without breaking backward compatibility.

Re: Write Junior Code

#127

Post by tabtab »

TeMPOraL wrote: post #121
tabtab wrote: post #119

Earlier quoted context omitted.

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.

To a degree . Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you. I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption th…

It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to say. Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. We can't re-code the world.

Re: Write Junior Code

#128

Post by zozbot234 »

rashkov wrote: post #22
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.

Have a look at OCaml, and also at its new spinoff, ReasonML. I think it may be what you’re looking for - compile-to-native systems language, great type system with 20 years of development behind it, and functional without being dogmatic and pure about it by easily allowing imperative mutable code as well.

ReasonML is more like 'Ocaml with a different syntax' than an actual spinoff.

Re: Write Junior Code

#129

Post by zozbot234 »

nicoburns wrote: post #67
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.

Rust gets pretty close to this.

Rust is for GC-free code, and it shows in how it deals with closures, higher-order functions, etc. Very different from Haskell or even something like F#/Ocaml/Kotlin and the like.

Re: Write Junior Code

#130

Post by TeMPOraL »

tabtab wrote: post #127
TeMPOraL wrote: post #121

Earlier quoted context omitted.

To a degree . Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you. I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption th…

It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to…

> Either way, they probably won't change this pattern, and thus one should code for a lower common denominator.

Why? Unless they get push back from the HR/upper management, it's the tech team that makes this decision, in big part by setting expectations and minimum accepted competence level. It's thus the technical team that can change this pattern, by not making itself to code to the lowest common denominator, by setting standards, by embracing perpetual learning as part of the job.

Setting an appropriately high bar for both ourselves and our future teammates is part of the job too. Our non-technical bosses ain't gonna to do this for us - how could they? They don't have the necessary technical expertise; they depend on us to provide it.

Post reply on HN