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

51–60 of 143 posts

Re: Write Junior Code

#51

Post by Eikon »

mcqueenjordan wrote: post #49
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…

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

Re: Write Junior Code

#53

Post by Thorentis »

Not specific to Haskell but, I think code in general is becoming more complex than it needs to be without any added benefit other than adding an extra buzzword to the list of things you know.

In a non-functional programming language for instance, I firmly place lambdas in this category. I was working on a legacy Java 7 application the other day, and Netbeans was configured for using lang spec Java 8 (which I later switched over to 7). Every time I wrote an anonymous function, it could give me a yellow underlined hint saying I should convert this to a lambda. Why? Why should I do that? It doesn't make it more readable, it saves only a few characters of space (our target platform had more than enough disk space for this to be irrelevant), and it makes the code more difficult to skim. And it's an extra thing a junior may not know about that they get bogged down trying to understand. Given, it's a simple concept and isn't hard to understand. But this applies to all sorts of other silly syntactic sugar the internet has decided is cutting edge tech, that is making our code bases less readable.

Re: Write Junior Code

#54

Post by nine_k »

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…

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 junior engineers, and nurture them.

[Edit: grammar]

Re: Write Junior Code

#56

Post by jpindar »

huffmsa wrote: post #16
ljm wrote: post #11

> Employee writes a ton of really fancy Haskell, delivers fantastically and in about 1000 lines of code. Everyone is very impressed. The project grows in scope. > > Boss: It’s time to hire another Haskeller. What are the job requirements? The job requirements should be the same as the ones the original engineer was hired for. Then they can mentor the newbie. After all, they're not an expert if they've done this, they…

That's the thing a lot of devs who hire don't get. You don't necessarily need someone who knows the language inside and out on day one. What you need is someone smart and who can demonstrate that they can learn new languages quickly. They understand the fundamentals of how to write software. Language specific abstractions are just muscle memory.

Where are the job ads for someone like that?

Re: Write Junior Code

#57

Post by jgodbout »

sukilot wrote: post #29
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…

Do you use On Lisp (hi, 'pg!) type stuff, with heavy macros? I don't believe a new hire can learn an On Lisp -esque custom embedded language in 2 weeks.

Fixing your Lisp: (let ((pg! "Paul Graham!")) `(hi ,pg!))

Re: Write Junior Code

#58

Post by jgodbout »

jgodbout wrote: post #57
sukilot wrote: post #29

Earlier quoted context omitted.

Do you use On Lisp (hi, 'pg!) type stuff, with heavy macros? I don't believe a new hire can learn an On Lisp -esque custom embedded language in 2 weeks.

Fixing your Lisp: (let ((pg! "Paul Graham!")) `(hi ,pg!))

Or, really `(hi ,pg!) but please capture that pg!

Re: Write Junior Code

#59

Post by tylorr »

thrower123 wrote: post #8
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 keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world. The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.

The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.

Re: Write Junior Code

#60

Post by war1025 »

dreamcompiler wrote: post #46

Perfectly fine advice if you're solving a routine problem with well-understood solutions with no special reliability, productivity, or security requirements. Terrible advice if you're pushing the envelope. If you're using Haskell with half its functionality verboten, why use Haskell?

Which is, perhaps, why basically no one uses Haskell in production.
Post reply on HN