Hacker News Reader

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.

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.

Lambdas shouldn’t be considered clever. What did these people learn in school?

I fully agree with this. I haven't really seen code that is 1) actually useful but 2) so clever that you can't quickly explain why or how it works (or just let the person reading it figure it out or ask stackoverflow...). So I don't really even know what people mean by clever code.

In my experience, a big danger is when someone higher in the company hierarchy is a former developer who no longer writes code.

Such person will perceive the new language features or libraries as "too clever, and not really necessary", will voice their opinion loudly, and you can't make them learn and find out that it's actually simple and useful. (And, yes, lambdas in Java 8 were an example of that.)

Find good examples that you can defend well, and overwhelm them with practical and relevant examples.

In my opinion, Java wouldn't need to use lambdas as often if it had a more powerful object model. You'd define methods instead of pass lambda's as parameters. Lambda's are often a band-aid for a weak object model.

For example, if I want to define an "on click" GUI event handler for a given button, the more natural approach would be to define an "onClick" method for that button's object. But you can't do that in Java in a simple way the way you could in say SmallTalk. Thus, one typically has to send a lambda to a "listener" object, which is unnatural.

I think the two things you described are essentially identical. Defining a onClick method on an object is equivalent to giving the onClick method a function with implementation in it. +/- whatever shenanigans your object system plays with methods.

Java does indeed have a very weak object model, though it improves slowly over time. But rejecting to use those improvements because it's "clever code" is arguably just dumb.

I agree there is or can be a lot of overlap between OOP and aspects of functional. With some diligent language factoring, I suspect they can be blurred to be one in the same. That way one doesn't have to learn two different sets of rules and syntax. But, I'm not sure Java can fix such cleanly without breaking backward compatibility.

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

Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger.

Part of it is the fad-driven nature of our industry that whips around what's "in" technology like the tail of a captured fish. Until Fad Cops clamp down on nonsense and excess, it's a young person's game.

Many companies stick with COBOL not because it's better, but because it's stable, like Latin, because it's a "dead language". Nobody comes along and gums it up with spaghetti "Design Patterns" or 7 layers of microservices because "the big boys are doing it!".

Warren Buffett has said part of his success is due to his ability to say "no" when everyone else is saying "yes". He willingly lets others be the guinea pig.

As far as functional programming, it takes a different mindset than imperative programming, and for many there is a relatively long learning curve until they match or exceed their imperative productivity. If programming is a dead-end career, per above, that curve may not be economical.

I personally find functional harder to debug because it's harder to "x-ray the pipes" of intermediate steps, and have not got over that difficulty yet. I personally find it easier to break up imperative code into smaller intermediate steps or parts, subject to inspection via debuggers or Write() statements. Somebody once said: "Functional makes it easier to express what you want, but imperative makes it easier to see what you actually have." That rang so true for me.

There is something to that, but it applies at the (predicted) end of one's career. But what I'm writing about applies at the beginning - the idea that being forever stuck at a level of skill only a tiny bit higher than what an average developer enters their first job with.

EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming experience is limited to typical for Lisp, Clojure and Erlang, and not e.g. Haskell. With functional code, you just hook up in some place in the pipeline and start leaking what's coming in and out of there to the outside world (stdout, REPL, debugger). Because it's functional, you can be sure you're not missing any hidden state. You can keep replying the calls manually, perhaps tweaking inputs, to identify the problem. After finding and fixing a bug, it's relatively trivial to turn your debugging work into a regression test.

It seems to me that your complaint is less about functional code and more about point-free style, which is arguably a bit more difficult to hook into, but only because debugging tools aren't really optimized for it.

One has to write code intended for a variety of readers having different skill levels. In practice you have to "dumb it down" to a degree.

To a degree. Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you.

I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption that excavators are evil because a random construction worker won't know how to operate one.

It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to say. Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. We can't re-code the world.

> Either way, they probably won't change this pattern, and thus one should code for a lower common denominator.

Why? Unless they get push back from the HR/upper management, it's the tech team that makes this decision, in big part by setting expectations and minimum accepted competence level. It's thus the technical team that can change this pattern, by not making itself to code to the lowest common denominator, by setting standards, by embracing perpetual learning as part of the job.

Setting an appropriately high bar for both ourselves and our future teammates is part of the job too. Our non-technical bosses ain't gonna to do this for us - how could they? They don't have the necessary technical expertise; they depend on us to provide it.

There is the theory that 5 highly skilled developers can do the job of 10 average developers, but in practice this often doesn't pan out. I'm not saying it never works, but it just doesn't seem to be a sure-shot strategy.

Part of the reason is that "soft skills" such as getting along with the team, writing well, understanding likely user behavior and the domain, making smart trade-offs, etc. also matter, and often times the technically "elite" lack these. Software development should be viewed as making tools for humans, not really for machines, and understanding humans is part of this.

Regarding your debugging edit: If one wants to spread the use of functional, perhaps finding a making a good guide and tutorial on debugging it would be helpful. I seem to be applying my imperative debugging thinking to it, and it doesn't fit well. I need to overhaul my debugging mind, not just my code mind.

> And if you do hire juniors, accept that they'll need more than few weeks to get up to speed.

I get the impression that most companies would rather complain about shortage of talent for months instead of hiring someone who'll spend a few weeks learning.