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

101–110 of 143 posts

Re: Write Junior Code

#101

Post by clarry »

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)

Re: Write Junior Code

#102

Post by tobyhinloopen »

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?

Re: Write Junior Code

#103

Post by nsomaru »

TeMPOraL wrote: post #93
Rapzid wrote: post #84

Earlier quoted context omitted.

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

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?

Re: Write Junior Code

#104

Post by TrackerFF »

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…

I think a problem might be that the jr. devs don't even get the chance to look at the code, because they're not getting hired based on their lack of experience (ref. the laundry list of advanced requirements).

It reminds me of the Manager - HR pipeline, where HR people get a description of technical stuff to input in their job listings, and then proceed to gatekeep applicants away from the positions, because they don't match x % of their technical laundry list.

Re: Write Junior Code

#105

Post by mikojan »

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…

> How many people change their IQ?

Literally all of them. However, if someone never progresses to "senior" they might've just lost interest in software development. People in general are remarkable at learning about subjects arousing their curiosity. This is an important fact, too, because environments can be designed specifically to foster just that. Not everything will be working for everybody, of course, and some might never develop an interest in that field again. But that's okay, too.

Re: Write Junior Code

#106

Post by kortilla »

michaelmrose wrote: post #89
Eikon wrote: post #51

Earlier quoted context omitted.

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

If this is truly a profitable choice why are you assuming anyone will do it?

Because there are companies doing boring work that have huge developer infrastructure in place to help cheaper juniors do the mundane stuff (i.e. all of the big tech companies).

Re: Write Junior Code

#107

Post by nmca »

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

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

Re: Write Junior Code

#108

Post by ukoki »

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…

> If there's someone on the team who can't understand a particular piece of code, he should just ask and learn. There's no reason to weigh someone down just to make an inexperienced, incompetent programmer or unwilling to learn something happy.

Writing simple code isn't about allowing juniors to be "lazy". Simple code is a business decision. The easier it is to contribute to a codebase:

* the more of your existing staff are able to contribute

* the easier it is to hire people able to contribute

* the cheaper your staffing costs

* the quicker it is for new staff to contribute

* the more resistant you are to staff turnover

* the more resistant you are to changes in the relative popularity of programming languages and libraries

* the cheaper it is to pay off technical debt (because rewrites are easier)

Lowest-common denominator code should be the rule, not the exception. There is definitely a place for "fancy" code, but it should be very carefully considered.

Re: Write Junior Code

#109

Post by Cthulhu_ »

I have a page saved with a load of quotes, some of which are about this very subject. Here's a selection, from http://quotes.cat-v.org/programming/:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style

Re: Write Junior Code

#110

Post by mark_l_watson »

I enjoy Haskell and I use it for some of my own projects, but I rarely use it professionally. I also use a simpler style of writing Haskell: I try to make as much of my code as possible be pure, with no IO or touching the real world. I try to isolate impure code as much as possible.

Using a subset of Haskell makes coding fun and productive, but when I have to read and use other people’s code, it takes time to understand what they are doing.

I have made peace with using Haskell in a simple way, enjoy it, but frankly spend most of my time using Lisp languages like Hy, Common Lisp, and Racket. I have been using Lisp languages for 35 years and part time Haskell for about 7 years, so it is understandable why I have an easier time with Lisp.

Post reply on HN