Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Green Lumber Fallacy in Software Engineering

chrisbehan.ca

Post reply on HN
Print view View original

201–210 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#201

Post by bradlys »

tubby12345 wrote: post #144
YZF wrote: post #141

Earlier quoted context omitted.

I can assure you, 100% without a doubt, that this is where the vast majority of developers are. Including people working on the most cutting edge software. The only reason the people you interview(?) can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems. Or sure, some of us do competitive coding and such where these things do show up. There's absolutely no…

>I can assure you, 100% without a doubt, that this is where the vast majority of developers are. cool? then that majority doesn't generate the same value as those that do and so they shouldn't get paid as such? i already asserted that? >Including people working on the most cutting edge software. ctrl+f to doubt that you know what people working on cutting edge software do. i, on the other hand, do have some experienc…

The entitlement here is huge. Jesus Christ.

Bro - I’ve made a 7 figure TC, delivered 8+ value, and I still don’t think LC is worth a damn. It has little to no impact on day to day.

But - ok - you know - think that algorithms in software are literally the end all be all. You have some arbitrary standard where I need to remember how to implement fusion trees on the fly. It’s utterly ridiculous.

99%+ of software eng (even the super duper highly paid shit - remember I’m the dude who was making more than a million/yr) is boring ass pipes and glue. You don’t need advanced DS&A. In fact - if I saw some of the shit that I know gets advanced runtimes and gets some good performance metrics - I’d probably rip that shit out because it’s not maintainable by enough people and performance doesn’t fucking matter 99% of the time. Sure - that 1% is interesting but it’s like once a year you go, “huh, might need to crack out the ol’ stopwatch!”

Gatekeeping like a motherfucker. Holy shit.

Re: Green Lumber Fallacy in Software Engineering

#204

Post by joshuamorton »

disgruntledphd2 wrote: post #193
joshuamorton wrote: post #185

Earlier quoted context omitted.

This is such a funny thing to read, because I see new L6 and 7 tech managers hired (above me) all the time. They're often middle aged people with kids. They don't bemoan this stuff (and yes, while they have fewer of them, they still need to solve a whiteboard problem or two to get hired)

But you're seeing the outcome of a selection process. You might feel differently if you saw the top of the funnel.

In what way? If you mean that there might be management wizards who are just fantastic but we skip, perhaps. But that isn't the point I was making, just that despite what people think, these interviews don't actually filter out experienced people with families and kids. Those kinds of people get hired regularly.

Re: Green Lumber Fallacy in Software Engineering

#205

Post by lifeisstillgood »

capitalsigma wrote: post #178
lifeisstillgood wrote: post #25

Earlier quoted context omitted.

Interesting interview questions might be - download this OSS project - explain to me where / how this API works, how deep does the call stack go. What tests exist for it? - write me the spec for that call. discuss.

Why would you ask someone to do something absolutely trivial?

Why is it trivial to take a unfamiliar code base and dive into it, hunting down calls, working through the stack to understand what / how a particular function works. This is a hugely important part of familiarising oneself with a codebase - it leads to many useful discussions. Who should you talk to if there is problem in a function halfway down. If I want to add a parameter to the top function, what might have to change down the stack?

I am not sure why thats trivial

Re: Green Lumber Fallacy in Software Engineering

#206

Post by bryanrasmussen »

tubby12345 wrote: post #127
YZF wrote: post #118

Earlier quoted context omitted.

When it comes up do you need to code it up in 20 minutes or is looking the algorithm up in a textbook ok? If all you want to test that sort of knowledge just ask the knowledge question. I don't need to memorize Floyd-Warshal and be able to code it on demand to be able to recognize when it's needed and look it up. I'm sure I remembered it back in school, haven't used it since, but if the day comes I'll look it up...

Quoted post unavailable.

>this is the "i'll quit smoking when i get cancer" philosophy applied to software dev.

This may probably be the worst logical analogy I've ever read on HN.

The suggestion is that when you need an algorithm (cancer) you will look it up (quit smoking); the initial problems that make the analogy rather clunky - the algorithm is something you want whereas cancer is something you don't, and looking up the algorithm is something you start to do whereas quitting smoking is something you stop (smoking)

But of course there are other things that make the analogy inelegant - the longer you smoke the worse the cancer gets, but not looking up the algorithm for years does not make the algorithm any harder (here there is some room to quibble since unfamiliarity with the algorithm for some years may make implementing it more difficult but that is a different level of surety than the smoking worsens cancer level of surety, and at any rate difficulty to implement is not exactly the same as harder)

Finally the extreme nature of the analogy seems more likely to cloud judgement than otherwise.

I'm not saying you're not good at what you do, just saying you are not getting a job in this philosophy department with that level of argumentation buster!

Re: Green Lumber Fallacy in Software Engineering

#207

Post by marcus_holmes »

tubby12345 wrote: post #124
vp8989 wrote: post #116

Its shocking to me how people don't get bored of rehashing this same, tired opinion over and over and over again and discussing it with hundreds of comments. There is a blog post like this every other day on the front page of HN and it always generates the exact same discussion.

I have said this before: it's group therapy for entitled devs that feel they're entitled to oversized salaries just because they have tenure. Young grads accept the process as is. People that are either happy with their comp or comfortable putting in the work do not lament the process - they just accept it and proceed. Only devs that have been doing it a while, whose salaries have plateaued, that either never learned…

> I have never seen members of those communities complain as much as developers do.

Other professions have guilds (not called that, but effectively that) who qualify membership and enforce various rules and standards on their members.

Maybe one day we'll have a Guild of Software Developers that provides this service and we won't need to deal with shitty interview tests. But until that day, maybe we shouldn't be comparing ourselves to professions that do have this and therefore don't face the same problems.

Re: Green Lumber Fallacy in Software Engineering

#208

Post by lithos »

erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

Trial periods and take home assignments also exclude vast swathes of society. Anyone who can’t have an uncertain job, who doesn’t have lots of extra time, is currently employed (compared to a college student getting their first job), and can’t have periods without insurance (for trial periods).

Even if that’s a feature you’re looking to “force” into your recruiting program, you’re probably better off getting a “trust fund baby” work force by targeting overseas volunteer work.

Re: Green Lumber Fallacy in Software Engineering

#209

Post by lodovic »

capitalsigma wrote: post #178
lifeisstillgood wrote: post #25

Earlier quoted context omitted.

Interesting interview questions might be - download this OSS project - explain to me where / how this API works, how deep does the call stack go. What tests exist for it? - write me the spec for that call. discuss.

Why would you ask someone to do something absolutely trivial?

You could see it as a modern FizzBuzz. Many candidates will fail at such a triviality.

Re: Green Lumber Fallacy in Software Engineering

#210

Post by disgruntledphd2 »

joshuamorton wrote: post #204
disgruntledphd2 wrote: post #193

Earlier quoted context omitted.

But you're seeing the outcome of a selection process. You might feel differently if you saw the top of the funnel.

In what way? If you mean that there might be management wizards who are just fantastic but we skip, perhaps. But that isn't the point I was making, just that despite what people think, these interviews don't actually filter out experienced people with families and kids. Those kinds of people get hired regularly.

Well you don't actually know that, because you don't know what the top of the funnel looks like.

Consider a world where every L6+ manager candidate has a family and kids. However, only 5% of these can make time to do the LC stuff (revising most likely if they've been managing for a while).

So your company will end up filtering out 95% of candidates immediately, but people in the company will say that there's no problem as all of the successful candidates have a family and kids, so it can't be biased.

Don't get me wrong, I'm a fan of technical screening for managers, but I'm making the point that you can't look at the output of a funnel and conclude that everything's fine, you need to look at the complete funnel to understand this.

Post reply on HN