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

61–70 of 143 posts

Re: Write Junior Code

#61

Post by BurningFrog »

gravypod wrote: post #48
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…

If no one hires junior developers then how will we make new developers? If no one writers code that junior developers can understand, then how can we hire junior developers?

The suggestion was to not hire junior for certain projects, where that makes sense.

This does not at all imply that no one should ever hire them. So get up from that slippery slope and start walking again!

Re: Write Junior Code

#62

Post by gridspy »

hinkley wrote: post #25
gridspy wrote: post #18

Earlier quoted context omitted.

I've been through that stage (grumpy defensive programmer). On the other side is a deep humbleness when as a programmer you realise you know nothing, you never really knew. You just knew how to research and fix the problem really fast.

Yeah it makes the interview cycle pretty damned awkward though.

If you are supremely confident that you've solved many problems with "no experience" you know you can solve many more.

It helps with bringing the interviewer with you also. It's actually important to stay humble and think out loud. Don't aim to have all the answers. Aim to find the answers "as a team" and give them a positive preview of how working with you is pleasant.

I've aced every interview, perhaps because I only interview for roles I am intellectually curious about and I do a lot of research beforehand "for fun."

Re: Write Junior Code

#63

Post by emodendroket »

I don't know much about Haskell but I'd say in any language you shouldn't write code to show off your erudition. Doing that kind of thing in production code is hardly the mark of a truly senior engineer. If the code is the best way to solve the problem, though, why is it so inscrutable in this language?

Re: Write Junior Code

#64

Post by dr_zoidberg »

reikonomusha wrote: post #37
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…

Python has a sort of opposite problem. It’s so easy to write code that it can be difficult for engineers to know whether the code they’re writing is good or bad. And while bog-standard imperative code is easy to read, it gets hairy when people are slinging dicts and stashing things away in object attributes at runtime. It’s easy to say “well, no true Scotsman would write code like that!” except it appears in all corn…

That's not a problem really. Good code is easy to read and mantainable.

Regarding the tee operator: it's a solved problem, you have ot import it from itertools[0], which should be where any experienced python programmer would strt.

[0] https://docs.python.org/2/library/itertools.html#itertools.t...

Re: Write Junior Code

#65

Post by emodendroket »

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…

I don't know Haskell but I have worked in Scala. It's an adjustment to express yourself in functional idioms, but the payoff is that it's easier to reason about, test, and debug (not to mention parallelize) side effect-free pure functions. I often reach into this bag of tools even when working in other languages.

Re: Write Junior Code

#66

Post by nicoburns »

nine_k wrote: post #54
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…

Not hiring junior developers makes sense when you are still unfolding, and have a really small engineering team ( As you grow, you will see that not all work is equally important, and you want your more senior guys work on harder problems. And you will also note a number of good, smart developers applying to you who do not yet have the experience of a senior engineer, but could quickly grow. Then you can start hiring…

I'm currently working for a company whose first 4 technical hires (other than the CTO, who wasn't always involved in day-to-day development) were juniors. This was a terrible idea, as there are basic architectural mistakes baked into the codebase all over the place, and lots of issues with data integrity and things that only work most of the time. They'd have been better off with a single senior.

Agree that it makes sense to hire juniors once you've grown though.

Re: Write Junior Code

#67

Post by nicoburns »

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.

Re: Write Junior Code

#68

Post by reikonomusha »

dr_zoidberg wrote: post #64
reikonomusha wrote: post #37

Earlier quoted context omitted.

Python has a sort of opposite problem. It’s so easy to write code that it can be difficult for engineers to know whether the code they’re writing is good or bad. And while bog-standard imperative code is easy to read, it gets hairy when people are slinging dicts and stashing things away in object attributes at runtime. It’s easy to say “well, no true Scotsman would write code like that!” except it appears in all corn…

That's not a problem really. Good code is easy to read and mantainable. Regarding the tee operator: it's a solved problem, you have ot import it from itertools[0], which should be where any experienced python programmer would strt. [0] https://docs.python.org/2/library/itertools.html#itertools.t...

I mean something like an IO stream. Something like

    s = tee(stdout, myOutFile)

Re: Write Junior Code

#69

Post by didibus »

smadurange wrote: post #45

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 underst…

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.

Re: Write Junior Code

#70

Post by monoideism »

SaxonRobber wrote: post #50
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…

Part of the trouble with Haskell is the prevalence of syntactic sugar. It is incredibly easy to make code that is tiny and indecipherable because it relies upon functions which are compositions of higher-ordered functions with monads and obscure operators that no other language has. And on top of that Haskell is lazily evaluated, which complicates it further. And don’t even start with point-free style, a style where…

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

Post reply on HN