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

11–20 of 143 posts

Re: Write Junior Code

#11

Post by ljm »

> 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're still able to explain why they pulled in a shit ton of libraries to do their work.

Asking that person what the new requirements are is doomed to fail because they moved the goal posts. Give them a junior and let them learn.

Re: Write Junior Code

#12

Post by bauerd »

thraxil wrote: post #10
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.

Elixir is pretty great if you're not super hung up on type systems.

I should have added that I'd also prefer mandatory typing and natively compiled code.

Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like

Re: Write Junior Code

#13

Post by rubber_duck »

thanatropism wrote: post #6
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…

One would expect that a language like Haskell abstracts away the need for junior programmers. In the same way that digital computers abstract away the need for pencil-and-paper calculators.

I've never seen a scenario like this and even with the ideal case of current abstraction frameworks there is always tedious grunt work that juniors get to cut their teeth on - doing minor adjustments to fine-tune requirements, adding minor functionality, etc. Stuff where you don't want to waste time and focus of senior devs.

The only scenarios I saw where juniors were not needed is overly complex systems where the barrier to entry was so high you needed a huge amount of upfront knowledge to do anything. Those were not good projects to work on.

Re: Write Junior Code

#14

Post by Multicomp »

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

Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile!

2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure.

Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why?

Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth.

Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash.

On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs).

For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.

Re: Write Junior Code

#15

Post by Syzygies »

One should code in Haskell as if it were a small language like Scheme (or Standard ML, or early OCaml, or..). It's a wonderful language for that. The deep stuff isn't actually necessary.

Re: Write Junior Code

#16

Post by huffmsa »

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.

Re: Write Junior Code

#17

Post by hinkley »

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…

It's like when you're a kid and you think adults have everything figured out.

When you pull on the thread, you find that a lot of successful developers don't really have that clear a picture of what it is they did and how they did it. It gets covered with bluster and bluffs. Impugning the other person for not 'getting it' and getting defensive about the 'documentation' they wrote and how everything you need is in the code.

Fifteen years ago we were still talking about 'cave trolls', the people who work in isolation, and often on their own schedule. Most of those people still exist. They've just had makeovers.

Re: Write Junior Code

#18

Post by gridspy »

hinkley wrote: post #17
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…

It's like when you're a kid and you think adults have everything figured out. When you pull on the thread, you find that a lot of successful developers don't really have that clear a picture of what it is they did and how they did it. It gets covered with bluster and bluffs. Impugning the other person for not 'getting it' and getting defensive about the 'documentation' they wrote and how everything you need is in the…

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.

Re: Write Junior Code

#19

Post by unique_username »

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.

You are basically describing ocaml

Re: Write Junior Code

#20

Post by m45t3r »

29athrowaway wrote: post #9

What I try to do in my projects is to allow complex code (if it serves a purpose), but only in libraries and try to make it as self-contained and well documented as possible. Application code should be simple.

I concur. We use Clojure, and the actual application logic is boring and simple. This is good because it is easy to navigate in code from any project (even from other teams).

Complexity is all at our common libraries. So most programmers don't even need to understand our abstractions, they just work. Of course, sometimes our abstractions are not enough so you need to get your hands dirty. However I would say it works well 99% of the time.

Post reply on HN