Hacker News Reader

Comment by OtherShrezzing | Hacker News Reader

> One interesting consequence of this is that engineers with bad taste are like broken compasses. If you’re in the right spot, a broken compass will still point north. It’s only when you start moving around that the broken compass will steer you wrong. Likewise, many engineers with bad taste can be quite effective in the particular niche where their preferences line up with what the project needs.

This paragraph really gets to the idea of why I think discussing someone’s taste is basically useless in an engineering context. This “predictably broken compass” person stands out like a sore thumb, and you can just hold a 20min behavioural interview to filter them out.

A far more dangerous engineer is the “partially broken compass”, which appears at first sight to be working because it spins around like you’d expect, but is actually 127degrees off at all times.

View on HN

Can you paint an example of a "partially broken compass" engineer?

OP may be talking about cargo culting, but it actually just triggered two examples in my mind:

1. Someone who has only ever written code by tutorial, and has no idea of the architecture, performance considerations or usability implications of the code they're writing.

2. Someone who has got to a point in their career LLM Coding and is unable to write code without it because they don't understand what they're doing.

The problem occurs when one of these people:

- Is required to be good at the things they are not yet

- Proceeds as they always have because they are unaware of their skill gap

- (Optionally) gets promoted while things are still _just_ working

IME you hit these silent inflection points as a system begins to scale beyond the experience of the people involved. They survive for a while (Coyote time / the compass is still pointing north) until something happens (the whole thing falls off a cliff / starts to go south).

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like

    func isEven(s string) bool {
        num, _ := strconv.Atoi(s)
        return num % 2 == 0
    }

becomes:

    func isEven(s string) (string, error) {
        f, err := strconv.ParseFloat(s, 64)

        if err != nil {
            return "invalid", err
        }
        num := int(f)
        if num%2 == 0 {
            return "even", nil
        }
        else if num % 2 != 0 {
            return "odd", nil
        }
        return "invalid", nil
    }

Which is.... technically correct, instead of

    func isEven(num int) bool {
        return num % 2 == 0
    }
    func isEvenSafe(s string) (bool, error) {
        num, err := strconv.Atoi(s)
        if err != nil {
            return false, err
        }
        return isEven(num), nil
    }

Also the ones that can’t understand abstraction and are happy copy-pasters. Or the ones familiar with some paradigms (ex OOP) that brings it everywhere.

There are a lot of ways to accumulate tech debt so fast you’d think you’re in a code casino.

I’ve definitely seen way too much code like the examples above. Another side effect to this is it tends to leak all over and can result in exponentially more code. What would’ve been a 2-line change at the API boundary, becomes ten lines of manual edgecasing every time it’s used in business logic and results in impossible states that need even further typing and handling. And don’t forget the tests that now need to cover invalid inputs everywhere, not just the API boundary.

Reply on news.ycombinator.com