Hacker News new | ask | show | jobs
by humanrebar 3360 days ago
I agree 95%. However, inevitably there will be a developer that will want to implement a trie for reasons. It's hard to be able to reason with her (or technical leadership when appealing the decision) when advocating for an off the shelf alternative if you can't explain why this isn't a brand new problem. On the flip side, one actually does need to create a new data structure on occasion, and obviously there we would want to be able to implement the common alternatives.

Anyway, it's complicated. Especially when hiring for technical leadership.
1 comments
vonmoltke 3360 days ago
If I need to convince another developer that a particular path is well-worn and that they are drifting towards NIH syndrome I have the benefit of time to develop an argument and resources with which to do so. I do not have 45 minutes, no resources, and just a whiteboard.

To pre-counter an expected objection, if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.

link
humanrebar 3360 days ago
> I have the benefit of time to develop an argument and resources with which to do so.

One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess.

Though I agree that no-google, closed-book, no-IDE whiteboard development is very unnatural.

> ...if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.

I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.

link
vonmoltke 3360 days ago
> One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess.

They certainly do, but significant, unchangeable decisions should not be made that way. If I think there is a better alternative to something expressed in one of these discussions, but do not have the details at hand to make the case, I will voice the alternative and compile the details later. Choices like that should not be made without documented rationale anyway.

> I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.

The solution is to fix the organizational dysfunction. Hiring to the dysfunction is a band-aid at best.

link