Green lumber fallacy in software engineering (2022) | Hacker News Reader

Green lumber fallacy in software engineering (2022)

chrisbehan.ca

11 pointsmooreds17 comments

Yes, we know this. The question remains: how should we interview and hire people in order to end up with the best possible software?

I don't think current employment law allows, but as a software candidate I'd much rather assess the company/team fit on a trial basis as well. (Am neither a lawyer nor HR)

I wonder what some solutions might be?

I have no idea how well this idea might stand up, but I loved how I was hired in a kitchen forever ago.

Someone mentioned me to the boss. I get called in for an interview. We chat for 15 minutes. I’m then “hired” for six weeks full paid work, but by default after those six weeks I was done. No more hours scheduled. Unless he said he wanted me to stay on and I said I wanted to stay on.

What I liked is the subtle change in expectations caused by the default to be that you don’t stay hired after some trial/training period. What I did was check in on how they felt about me and got a good feel for if I needed to keep looking for jobs or not. And if I liked working there.

I guess you could describe it as a very short contract with the idea that there’s a full time role meant to be filled.

I can imagine many ways in which this can be exploited or gets ridiculous with how many months of training some companies need. I think it’s their own loss being so inflexible or untrusting or acting in bad faith.

The article also ended by suggesting trial work periods.

I believe software engineering basically has these in the form of "internships". At least, at a lot of UK companies, internships lead to jobs (often after graduation).

Not the same for senior role of course, but I don't think I've come across any SW company that does trial periods for senior engineers... If I have, I either wasn't aware or don't remember them.

licensing and accreditation is an option.

make a society of software developers, akin to the bar association and so on, and have developers enter the society to show a certain bar of skill.

Thought this was going to be interesting. Turned out to be the same thing that's been said time and time again without a new take nor any realistic suggestions of what to do.

Memorizing algorithms doesn’t really make sense to me. Even the trivial ones have edge cases that you might forget of you try to implement it from memory. You aren’t going to ship it before double-checking a textbook or Wikipedia, right? And who wants the naive implementation anyway? Look up the definition to have a really 100% solid description of the steps, so that you can use that as the starting point for optimization (assuming a tuned library doesn’t already exist).

It feels like a strange feedback loop or something. People memorize algorithms to pass interviews, instructors help students memorize them to help them get jobs, then once they get into the jobs they start asking interviewees about the questions to check if they were paying attention in class, or something.

> January 13, 2022

Ah, the good old days, before ChatGPT aced all such interview questions.

Do people still use these interview questions? My most recent interview was more of a "How good has your German become since last time we worked together?" situation.

> Other commodity traders, more well-versed in the theory of commodity trading, scoffed at Joe’s lack of what they believed to be “essential knowledge”. But while these academic style traders (many of whom went bust) obsessed over semantics and theories of what caused lumber prices to change, Joe did what he does best: trade lumber. It appears that knowing the origin of the term “green lumber” is irrelevant to becoming a successful green lumber trader, no matter how much theoreticians want to believe otherwise.

Uhmmm... I'd describe what happened there as lucky. I find the argument that understanding what you're trading is unnecessary pretty difficult to take seriously.

{Personal experience} many many years when beginning SWE, I used to think the same. I didn't want to admit but it meant I didn't have to learn DSA. There was plenty of evidence to back me up with the same thinking as this article. Life happened and I had to painfully spend time and slowly learn it. Comparing the person before & after, the difference in my software building skills were very tangible. Sadly I cannot point it out and say "I'm wiser and I know how not to make a mess in the codebase, because I learned such & such algorithm and data structures" yet I can fully imagine how the previous person would've been lost in the jungle.

{Less of personal experience but more of a anecdotal observation} I see the same pattern in hiring. Those who know DSA, build systems that cost less overal.

So maybe it's better not to throw DSA right out out the window, but also not stick to either ends of the spectrum?

I can't find any proper reference to this Joe Siegel guy on the web. Anyone?

The primary reference comes from the book Antifragile (2012), by Nassim Nicholas Taleb: https://en.wikipedia.org/wiki/Antifragile_(book)

> These test-like interviews mistake the trees (data structures and algorithms) for the forest (building software).

Who would want someone who knew nothing about trees in a forester's job?

The oil industry? (Only half joking)

Only half laughing :)

If they were the guy responsible for maintaining the hydraulics on the logging machinery, who gives a shit if they know anything about trees.

Logging isn't forestry.

Reply on news.ycombinator.com