I feel like you could say some similar things about flutter.
Write Junior Code
41–50 of 143 posts
Re: Write Junior Code
#42I have the opposite view. Sure, don't go overboard with power for your own sake . If it ends up a convoluted mess, it's your fault and you should refactor - proper application of powerful language concepts result in clean interfaces hiding complexity that rarely, if ever, needs to be touched again. From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don'…
One of the most enjoyable aspects of my career has been teaching and mentoring engineers with little experience. Everybody starts somewhere, and I would never want to suggest an organization I’m a part of ought to bar a healthy, tempered number of less experienced folk.
But, organizations aren’t charities, right? I might like mentoring, but that doesn’t mean it’s the best choice for a company to make. Fortunately, there are a plethora of incredibly bright and talented individuals who really can move the needle in your business in a short amount of time. You wouldn’t see it from number-of-years worked, but you’ll find out by investing your time and energy in them. With this attitude and managerial philosophy in mind, I find that you inevitably build stronger, more loyal, more flexible, and exceptionally competent teams this way.
Re: Write Junior Code
#43I have the opposite view. Sure, don't go overboard with power for your own sake . If it ends up a convoluted mess, it's your fault and you should refactor - proper application of powerful language concepts result in clean interfaces hiding complexity that rarely, if ever, needs to be touched again. From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don'…
One of the most enjoyable aspects of my career has been teaching and mentoring engineers with little experience. Everybody starts somewhere, and I would never want to suggest an organization I’m a part of ought to bar a healthy, tempered number of less experienced folk. But, organizations aren’t charities, right? I might like mentoring, but that doesn’t mean it’s the best choice for a company to make. Fortunately, th…
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 "clever" code - keeps popping up again and again. The extent to what's considered "clever" varies between jobs, languages and programming communities.
As an example, when my old Java job was grudgingly upgrading from Java 7 to Java 8, my boss took me to the side, and said to me: "I knew you'll be happy about the transition, but if you could, perhaps consider refraining from using lambda expressions; I know you understand them, but some of your colleagues do not".
I didn't comply; instead, I've explained lambdas to people in my project. It took few minutes, they understood it almost immediately, and we continued using full feature set of Java 8 just fine. The practice eventually spread around, and the other day I saw a particular developer my boss was worried about, going around the office full of excitement, telling everyone about the cool things he's just learned about Java 8 (namely, lambdas and streams API). Soon thereafter, everyone was using these features, and they've lost their status as "clever code".
So, to put my point another way, perhaps instead of worrying about the code being friendly to experienced developers, one should take the time to teach the new employees - just like you are doing.
Re: Write Junior Code
#44I think that it’s important to hire people who are comfortable with the whole language that you are using.
I also think that “junior code” could mean the opposite of what the author means. Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Lots of senior devs stick to a known (and canonical to them) subset of features that proved themselves in battle for them.
Re: Write Junior Code
#45I 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 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.
Good code isn't junior code. Good code isn't senior code. Good code is just what works best in a specific scenario. And it takes experience and details of a problem to decide what that is exactly. Dogmatic, rigid views just don't work well in this line of work.
Re: Write Junior Code
#46Perfectly 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?
Re: Write Junior Code
#47Earlier quoted context omitted.
One of the most enjoyable aspects of my career has been teaching and mentoring engineers with little experience. Everybody starts somewhere, and I would never want to suggest an organization I’m a part of ought to bar a healthy, tempered number of less experienced folk. But, organizations aren’t charities, right? I might like mentoring, but that doesn’t mean it’s the best choice for a company to make. Fortunately, th…
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…
Lambdas shouldn’t be considered clever. What did these people learn in school?
Re: Write Junior Code
#48This 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…
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?
Re: Write Junior Code
#49This 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…
> 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?
Re: Write Junior Code
#50This 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 parameters are left implicit. For a reader point-free is appalling and way too clever.
I would say junior Haskell should be unsophisticated. Leave out the higher order abstractions and write longer code which a reader at a lower level has a hope of deciphering.