28 ms·

Write Junior Code

173 points by bibyte 7y ago

rantwasp 7y ago
talking about haskell, i always get a laugh out of: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
throwaway8291 7y ago
Or become senior and apply for that Haskell job in five years.
choeger 7y ago
While you do it, find a business case for the language development. PL papers in the <Funny Title>:<Actual Description> format make a good read but a production language also needs more mundane input and work.
crimsonalucard 7y ago
I'm kind of having this problem. I'm a senior engineer but junior Haskell programmer. Can't find any jobs willing to hire me as a junior haskell programmer so I just stick with the popular languages.
zzzeek 7y ago
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 of transparency to everyone else at that employer. My general impression of functional languages with Haskell at the top, is that these languages are inherently not for "junior" programmers of any stripe. 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. A "junior" programmer would be doing it in PHP, C#, or Python. Just the kind of motivation one would need to learn Haskell and actually be functional at it would take you out of the realm of the vast majority of "junior" programmers. This is based on my own experience of working alongside many other programmers, many of whom were probably not necessarily "junior" however they were the kind of programmers that went home at 5 pm. These people could get a lot done but only in a language that did not require intensive conceptual visualization. Even in Python, parts of code that I would write that would get too clever / recursive / FP-ish would be lost on everyone else and I'd be stuck having to save everyone from that little clump every time something had to change with it.
- thanatropism 7y ago
  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.
  - rubber_duck 7y ago
    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.
  - sukilot 7y ago
    Close, but more it abstracts away the need for non-PhD programmers (or non-"could have gotten a PhD if they wanted to" programmers), and once you get a research professor on board, it abstracts away the need for mere PhD programmers too.
- reikonomusha 7y ago
  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 corners of the Python world, professional, open source, and otherwise. One example I like to cite is: What I’d you want to tee a stream in Python to two different substreams? Stack Overflow it and you see cargo culted duck-typed classes that don’t derive from any clear specification.
  - dr_zoidberg 7y ago
    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.tee https://docs.python.org/2/library/itertools.html#itertools.t...
bauerd 7y ago
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.
- thrower123 7y ago
  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#.
  - Multicomp 7y ago
    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#.
29athrowaway 7y ago
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.
- m45t3r 7y ago
  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.
ljm 7y ago
> 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.
- huffmsa 7y ago
  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.
  - sukilot 7y ago
    No one learns Haskell quickly. "the fundamentals of how to write software" are very different in Haskell from other languages, even other functional or functional-ish languages.
  - jpindar 7y ago
    Where are the job ads for someone like that?
- hinkley 7y ago
  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.
Syzygies 7y ago
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.
- verttii 7y ago
  True, but the problem is that any production ready library you come across uses some pretty advanced type magic that you have to learn to understand. At least to some extent. Servant, the currently dominant API library/framework alone is already based on type level programming.
ummonk 7y ago
>Let us grow Haskell in industry by writing simpler code and making room for the less experienced. >Let’s not delete all of our fancy code - it serves a purpose! Let’s make it a small part of our codebase, preferably hidden in libraries with nice simple interfaces. Says something about the Haskell culture that this isn't already standard practice, regardless of the need to train junior programmers.
- sukilot 7y ago
  It says something about the Haskell language -- that it has near infinite power for abstraction and Don't Repeat Yourself-ism. Most Haskell code is fancy because if anything else had a large amount of mass, it could be abstracted to higher-level Haskell. Haskell programs have size approximately "log(size of program in another language) ^ k" because anything repetitive can get squeezed out.
userbinator 7y ago
Almost every other language has a problem that it's already so dumbed-down to the point employees get treated as disposable/replaceable. There's a reason obscure languages pay very very well, but if you dumb them down, it's not hard to see what will happen to that advantage... (I don't work in Haskell. Now I have mixed feelings about it.)
- sukilot 7y ago
  There are more $200K+/yr new-college-grad C++ and Java jobs at FAANG than all $200K+/yr Haskell jobs in the world.
hestefisk 7y ago
Do Haskell programming jobs really pay better than, say, a Java programming job?
- Sevii 7y ago
  Maybe working on the one internal system Facebook has written in Haskell. https://engineering.fb.com/security/fighting-spam-with-haskell/ https://engineering.fb.com/security/fighting-spam-with-haske... Otherwise, I don't think many jobs pay more than Java engineer at FAANG.
reikonomusha 7y ago
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 amount of time to learn, then Haskell may not be a good choice for production code from a sociological POV. I haven’t used Haskell professionally so I can’t actually weigh in on the veracity of the prominence of difficult-to-learn code. I do know about using another “weird” language though: Common Lisp. We at Rigetti took a bet with Common Lisp and it passes the “senior-written idiomatic code can be junior-learned and modified” smoke test with flying colors. Every group of interns and every new grad that has become involved in the tens of thousands of lines of code has been able to contribute substantially in less than two weeks.
- sukilot 7y ago
  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.
  - reikonomusha 7y ago
    No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in production code. A few prominent macros we do use: - A macro to define a string lexer (aka tokenizer) for a programming language - A macro to define peephole optimizations of linear instruction code - A macro to define friendly looking bindings to Fortran functions - A macro to generate highly optimized complex double precision matrix arithmetic code for inner loops We do use “standard” macros, mostly from the ALEXANDRIA library. But these are idiomatic and have been used since at least the 80s. (Some of these are macros that On Lisp defines from scratch.)
    - eru 7y ago
      That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros? (Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)
lesserknowndan 7y ago
This post probably also applies to <insert name of programming language here>.
TeMPOraL 7y ago
I 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't hire juniors. Or at least, not the absolute beginners. And if you do hire juniors, accept that they'll need more than few weeks to get up to speed. Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Learning is part of the job. And yet it seems to me that more and more people think that what they've learned prior to their first job is all they'll ever need to understand, and anything beyond it is "clever code" that needs to be expunged. (Of course, keeping everything dumbed down makes sense if you're interested in penny-wise, pound-foolish optimization on the hiring side of the company, or otherwise like to have developers be replaceable cogs. But it's not in the best interest of the developer, and arguably it isn't in the product end-user's best interest either.)
- reikonomusha 7y ago
  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.
  - TeMPOraL 7y ago
    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.
heyflyguy 7y ago
I feel like you could say some similar things about flutter.
pizlonator 7y ago
I 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.
- np_tedious 7y ago
  > Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme that fits the bill, very simple types, very few advanced combinators and symbols, etc. It definitely could be better, but it suffers from a lack of fanciness rather than an excess. I've peeked at some expert solutions posted online and they are neat and super impressive... but by and large they confuse the shit out of me. I have a hard time picturing being overly ambitious as a common beginner flaw in this space.
  - pizlonator 7y ago
    Different folks take different paths. In any language, you will find folks who start out by kinda overshooting before they learn to tone it down. It’s not that all Juniors are this way. Maybe some get it right or maybe they even act too skidding. But I think of it as a Junior trait to sometimes overshoot on complexity.
smadurange 7y ago
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 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.
- didibus 7y ago
  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.
- elbear 7y ago
  I think the point of this article escapes anyone who doesn't know Haskell or a language with a similar type system. I don't want this to sound elitist, because it's not my goal, so I will clarify. In most languages, the abstraction ladder is short. You have built-in types and user defined types. Those user-defined types are almost always product types (think of structs in Go, or classes in OOP languages). Haskell also has sum types, which allow you to express things like: data TrafficLight = Green | Yellow | Red Other languages have interfaces and Haskell has type classes which work in the same way. Then come advanced type-level features: data kinds, type families, generalised algebraic data types and many others. Here's the table of contents of a book that deals with type-level programming in Haskell: https://thinkingwithtypes.com/ https://thinkingwithtypes.com/ These concepts allow you to encode more logic at the type level. But they come with the cost of needing to understand them. You can make a choice to write Haskell without these advanced type features. Maybe you lose some type safety or maybe you repeat yourself more. But the upside is that you use fewer concepts that need to be understand by someone who needs to work on the codebase. These are the juniors the author is referring to. I'm a junior as well in this regard, because I don't know all these type-level features, even though I've used Haskell professionally.
dreamcompiler 7y ago
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?
- war1025 7y ago
  Which is, perhaps, why basically no one uses Haskell in production.
Thorentis 7y ago
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.
tus88 7y ago
Wow but he continues to recommend using Haskell at all...
emodendroket 7y ago
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?
3fe9a03ccd14ca5 7y ago
> The project can’t really grow anymore. Maybe the original employee left, and now they have a legacy Haskell codebase that they can’t deal with. This is the litmus test for a good language, in my opinion. Not the way it makes you “feel” when writing it, but how easily it can add in new people to the project and get them running. This is why — even with all of its shortcomings — I prefer Go to almost every language now.
mendelmaleh 7y ago
I'm having a similar experience with Golang, 90% of job postings are senior level, everybody wants 3+ years experience in the field, etc.
ehnto 7y ago
This is why I advocate for popular frameworks in commercial projects, even though I don't prefer writing in them myself. Sure, it's easy to find people who know {Language}, but everyone has their own idioms, and they will need to spend time learning yours. A framework has the benefit of having existing documentation you didn't have to write, an existing community of people solving problems the framework may have, and most importantly a slew of idioms that are literally codified and documented. Do things "The {Framework} Way" and when you onboard someone familiar in {Framework} you should only have to help them with the domain space knowledge and any novelties of your specific implementation. You still get to use advanced concepts, but hiring and onboarding is significantly simplified. For personal projects, I never use frameworks, it's not nearly as fun as writing greenfields code. But in a commercial project, long term viability of the project should probably come before fun.
golergka 7y ago
That's why as much as I love Haskell as a language and a way of doing things, I will not choose it to implement anything in my place of work.
modernerd 7y ago
“Why not write Go instead?” was the response from an audience member after a talk at Haskell eXchange 2019 that encouraged simple use of Haskell. They had a good point — if a primary goal in your team is to make code accessible for juniors and maintainable for new hires without weeks or months of ramp-up, and you need to ban Haskell language features, extensions, and libraries to achieve that, perhaps there are better choices than Haskell? And if the Haskell community needs a repeated rallying cry to “write simple Haskell”, maybe it's a sign that a new Haskell standard should be created that defines what “simple“ Haskell code means. Juniors could then feel assured that learning the 2050 Haskell standard [or whatever] would be enough to help them get a job as a Haskell junior. And companies would have a target to move their codebases towards that's consistent across the industry.
Cthulhu_ 7y ago
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/ 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
mark_l_watson 7y ago
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.
zackmorris 7y ago
Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that starting from first principles allows one to end up with an elegant solution, regardless of whatever errata is present in a language. A good framework is the elucidation of an idea with the edge cases covered so that you don't have to reinvent the wheel. It should give you the tools you need to integrate with your code and then get out of the way. Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development. Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something. What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm. Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it. This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.
ofrzeta 7y ago
The same goes for Scala in my opinion. A company using Scala should restrict themselves to a easily comprehensible subset of Scala.
pearapps 7y ago
If code written by a "Senior" Engineer is unreadable/unworkable by someone with less experience - that is 100% on the writer. Don't enable ego-fueled programming, best to either do as the article suggests or bring in some actual more senior engineers who have already learned that code is read 10x more than written, and should be optimized thusly.

173 points by bibyte 7y ago

talking about haskell, i always get a laugh out of: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

throwaway8291 7y ago

Or become senior and apply for that Haskell job in five years.

choeger 7y ago

While you do it, find a business case for the language development. PL papers in the <Funny Title>:<Actual Description> format make a good read but a production language also needs more mundane input and work.

crimsonalucard 7y ago

I'm kind of having this problem. I'm a senior engineer but junior Haskell programmer. Can't find any jobs willing to hire me as a junior haskell programmer so I just stick with the popular languages.

zzzeek 7y ago

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 of transparency to everyone else at that employer. My general impression of functional languages with Haskell at the top, is that these languages are inherently not for "junior" programmers of any stripe. 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. A "junior" programmer would be doing it in PHP, C#, or Python. Just the kind of motivation one would need to learn Haskell and actually be functional at it would take you out of the realm of the vast majority of "junior" programmers. This is based on my own experience of working alongside many other programmers, many of whom were probably not necessarily "junior" however they were the kind of programmers that went home at 5 pm. These people could get a lot done but only in a language that did not require intensive conceptual visualization. Even in Python, parts of code that I would write that would get too clever / recursive / FP-ish would be lost on everyone else and I'd be stuck having to save everyone from that little clump every time something had to change with it.

thanatropism 7y ago
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.
- rubber_duck 7y ago
  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.
- sukilot 7y ago
  Close, but more it abstracts away the need for non-PhD programmers (or non-"could have gotten a PhD if they wanted to" programmers), and once you get a research professor on board, it abstracts away the need for mere PhD programmers too.
reikonomusha 7y ago
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 corners of the Python world, professional, open source, and otherwise. One example I like to cite is: What I’d you want to tee a stream in Python to two different substreams? Stack Overflow it and you see cargo culted duck-typed classes that don’t derive from any clear specification.
- dr_zoidberg 7y ago
  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.tee https://docs.python.org/2/library/itertools.html#itertools.t...

bauerd 7y ago

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.

thrower123 7y ago
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#.
- Multicomp 7y ago
  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#.

29athrowaway 7y ago

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.

m45t3r 7y ago
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.

ljm 7y ago

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

huffmsa 7y ago
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.
- sukilot 7y ago
  No one learns Haskell quickly. "the fundamentals of how to write software" are very different in Haskell from other languages, even other functional or functional-ish languages.
- jpindar 7y ago
  Where are the job ads for someone like that?
hinkley 7y ago
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.

Syzygies 7y ago

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.

verttii 7y ago
True, but the problem is that any production ready library you come across uses some pretty advanced type magic that you have to learn to understand. At least to some extent. Servant, the currently dominant API library/framework alone is already based on type level programming.

ummonk 7y ago

>Let us grow Haskell in industry by writing simpler code and making room for the less experienced. >Let’s not delete all of our fancy code - it serves a purpose! Let’s make it a small part of our codebase, preferably hidden in libraries with nice simple interfaces. Says something about the Haskell culture that this isn't already standard practice, regardless of the need to train junior programmers.

sukilot 7y ago
It says something about the Haskell language -- that it has near infinite power for abstraction and Don't Repeat Yourself-ism. Most Haskell code is fancy because if anything else had a large amount of mass, it could be abstracted to higher-level Haskell. Haskell programs have size approximately "log(size of program in another language) ^ k" because anything repetitive can get squeezed out.

userbinator 7y ago

Almost every other language has a problem that it's already so dumbed-down to the point employees get treated as disposable/replaceable. There's a reason obscure languages pay very very well, but if you dumb them down, it's not hard to see what will happen to that advantage... (I don't work in Haskell. Now I have mixed feelings about it.)

sukilot 7y ago
There are more $200K+/yr new-college-grad C++ and Java jobs at FAANG than all $200K+/yr Haskell jobs in the world.

hestefisk 7y ago

Do Haskell programming jobs really pay better than, say, a Java programming job?

Sevii 7y ago
Maybe working on the one internal system Facebook has written in Haskell. https://engineering.fb.com/security/fighting-spam-with-haskell/ https://engineering.fb.com/security/fighting-spam-with-haske... Otherwise, I don't think many jobs pay more than Java engineer at FAANG.

reikonomusha 7y ago

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 amount of time to learn, then Haskell may not be a good choice for production code from a sociological POV. I haven’t used Haskell professionally so I can’t actually weigh in on the veracity of the prominence of difficult-to-learn code. I do know about using another “weird” language though: Common Lisp. We at Rigetti took a bet with Common Lisp and it passes the “senior-written idiomatic code can be junior-learned and modified” smoke test with flying colors. Every group of interns and every new grad that has become involved in the tens of thousands of lines of code has been able to contribute substantially in less than two weeks.

sukilot 7y ago
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.
- reikonomusha 7y ago
  No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in production code. A few prominent macros we do use: - A macro to define a string lexer (aka tokenizer) for a programming language - A macro to define peephole optimizations of linear instruction code - A macro to define friendly looking bindings to Fortran functions - A macro to generate highly optimized complex double precision matrix arithmetic code for inner loops We do use “standard” macros, mostly from the ALEXANDRIA library. But these are idiomatic and have been used since at least the 80s. (Some of these are macros that On Lisp defines from scratch.)
  - eru 7y ago
    That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros? (Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)

lesserknowndan 7y ago

This post probably also applies to <insert name of programming language here>.

TeMPOraL 7y ago

I 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't hire juniors. Or at least, not the absolute beginners. And if you do hire juniors, accept that they'll need more than few weeks to get up to speed. Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Learning is part of the job. And yet it seems to me that more and more people think that what they've learned prior to their first job is all they'll ever need to understand, and anything beyond it is "clever code" that needs to be expunged. (Of course, keeping everything dumbed down makes sense if you're interested in penny-wise, pound-foolish optimization on the hiring side of the company, or otherwise like to have developers be replaceable cogs. But it's not in the best interest of the developer, and arguably it isn't in the product end-user's best interest either.)

reikonomusha 7y ago
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.
- TeMPOraL 7y ago
  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.

heyflyguy 7y ago

I feel like you could say some similar things about flutter.

pizlonator 7y ago

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

np_tedious 7y ago
> Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme that fits the bill, very simple types, very few advanced combinators and symbols, etc. It definitely could be better, but it suffers from a lack of fanciness rather than an excess. I've peeked at some expert solutions posted online and they are neat and super impressive... but by and large they confuse the shit out of me. I have a hard time picturing being overly ambitious as a common beginner flaw in this space.
- pizlonator 7y ago
  Different folks take different paths. In any language, you will find folks who start out by kinda overshooting before they learn to tone it down. It’s not that all Juniors are this way. Maybe some get it right or maybe they even act too skidding. But I think of it as a Junior trait to sometimes overshoot on complexity.

smadurange 7y ago

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

didibus 7y ago
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.
elbear 7y ago
I think the point of this article escapes anyone who doesn't know Haskell or a language with a similar type system. I don't want this to sound elitist, because it's not my goal, so I will clarify. In most languages, the abstraction ladder is short. You have built-in types and user defined types. Those user-defined types are almost always product types (think of structs in Go, or classes in OOP languages). Haskell also has sum types, which allow you to express things like: data TrafficLight = Green | Yellow | Red Other languages have interfaces and Haskell has type classes which work in the same way. Then come advanced type-level features: data kinds, type families, generalised algebraic data types and many others. Here's the table of contents of a book that deals with type-level programming in Haskell: https://thinkingwithtypes.com/ https://thinkingwithtypes.com/ These concepts allow you to encode more logic at the type level. But they come with the cost of needing to understand them. You can make a choice to write Haskell without these advanced type features. Maybe you lose some type safety or maybe you repeat yourself more. But the upside is that you use fewer concepts that need to be understand by someone who needs to work on the codebase. These are the juniors the author is referring to. I'm a junior as well in this regard, because I don't know all these type-level features, even though I've used Haskell professionally.

dreamcompiler 7y ago

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?

war1025 7y ago
Which is, perhaps, why basically no one uses Haskell in production.

Thorentis 7y ago

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.

tus88 7y ago

Wow but he continues to recommend using Haskell at all...

emodendroket 7y ago

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?

3fe9a03ccd14ca5 7y ago

> The project can’t really grow anymore. Maybe the original employee left, and now they have a legacy Haskell codebase that they can’t deal with. This is the litmus test for a good language, in my opinion. Not the way it makes you “feel” when writing it, but how easily it can add in new people to the project and get them running. This is why — even with all of its shortcomings — I prefer Go to almost every language now.

mendelmaleh 7y ago

I'm having a similar experience with Golang, 90% of job postings are senior level, everybody wants 3+ years experience in the field, etc.

ehnto 7y ago

This is why I advocate for popular frameworks in commercial projects, even though I don't prefer writing in them myself. Sure, it's easy to find people who know {Language}, but everyone has their own idioms, and they will need to spend time learning yours. A framework has the benefit of having existing documentation you didn't have to write, an existing community of people solving problems the framework may have, and most importantly a slew of idioms that are literally codified and documented. Do things "The {Framework} Way" and when you onboard someone familiar in {Framework} you should only have to help them with the domain space knowledge and any novelties of your specific implementation. You still get to use advanced concepts, but hiring and onboarding is significantly simplified. For personal projects, I never use frameworks, it's not nearly as fun as writing greenfields code. But in a commercial project, long term viability of the project should probably come before fun.

golergka 7y ago

That's why as much as I love Haskell as a language and a way of doing things, I will not choose it to implement anything in my place of work.

modernerd 7y ago

“Why not write Go instead?” was the response from an audience member after a talk at Haskell eXchange 2019 that encouraged simple use of Haskell. They had a good point — if a primary goal in your team is to make code accessible for juniors and maintainable for new hires without weeks or months of ramp-up, and you need to ban Haskell language features, extensions, and libraries to achieve that, perhaps there are better choices than Haskell? And if the Haskell community needs a repeated rallying cry to “write simple Haskell”, maybe it's a sign that a new Haskell standard should be created that defines what “simple“ Haskell code means. Juniors could then feel assured that learning the 2050 Haskell standard [or whatever] would be enough to help them get a job as a Haskell junior. And companies would have a target to move their codebases towards that's consistent across the industry.

Cthulhu_ 7y ago

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

mark_l_watson 7y ago

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.

zackmorris 7y ago

Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that starting from first principles allows one to end up with an elegant solution, regardless of whatever errata is present in a language. A good framework is the elucidation of an idea with the edge cases covered so that you don't have to reinvent the wheel. It should give you the tools you need to integrate with your code and then get out of the way. Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development. Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something. What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm. Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it. This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.

ofrzeta 7y ago

The same goes for Scala in my opinion. A company using Scala should restrict themselves to a easily comprehensible subset of Scala.

pearapps 7y ago

If code written by a "Senior" Engineer is unreadable/unworkable by someone with less experience - that is 100% on the writer. Don't enable ego-fueled programming, best to either do as the article suggests or bring in some actual more senior engineers who have already learned that code is read 10x more than written, and should be optimized thusly.