3 ms·

> 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

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

medstrom 1y ago
Can you paint an example of a "partially broken compass" engineer?
- DavidPiper 1y ago
  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).
- maccard 1y ago
  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 }
  - skydhash 1y ago
    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.
  - Zanfa 1y ago
    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.

medstrom 1y ago

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

DavidPiper 1y ago
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).
maccard 1y ago
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 }
- skydhash 1y ago
  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.
- Zanfa 1y ago
  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.