Hacker News Reader

Comment by CuriouslyC | Hacker News Reader

That works better in comic books than software. As an example, I have a coworker who is pretty good in terms of domain knowledge, and can push out work pretty fast, but he does things like write migrations that insert rows of data one at a time in a loop, or adds three layers of almost do-nothing wrapper functions around business logic that doesn't need to be abstracted. He's made a lot of useful contributions but the stuff he's been heavily involved in is borderline indecipherable so the tech debt tradeoff has been pretty brutal.

View on HN

Manager here, I can tell you sometimes the things engineers care a lot about like algorithms and the fastest/correct ways to do things are not important.

Domain knowledge is typically far more valuable. The real world of business has tons of weird legal/finanical/workflows edgecases. I'll always hire a mid engineer with strong business domain knowledge over a very technical engineer with no strong businss domain knowledge. My firm only has one team that's an exception to this rule.

As a staff engineer at an org that heavily prioritizes domain knowledge and promotes for it and agreeableness heavily, I think that view is only true in the most black and white of cases. We have lots of developers working at 25% productivity because the flaming dumpster fire of tech debt we inherited is slowly turning into a flaming landfill fire as we pile shit on top of shit rather than fix things. I'm not sure why management hasn't made the connection between repeatedly missing deadlines and rampant unchecked tech debt, I've pointed it out many times. At this point I'm just glad I'm not on a team that's severely impacted, but I feel bad for the people who are going to be forced to crunch and will still come out looking like poor employees.

I sympathize as well, but I also know many many developers are extremely poor at judging what/how the code affects a given Firm's KPI's.

I've been in literally hundreds of conversations with engineers who want to refactor a given technical system and don't realize the code debt is really due to the fact human businesses run on endless edge cases and weird exceptions. They only account for the majority use cases, but the problem is the firm would get sued without complete coverage. So when they deal with the edge cases, the code looks like shit again, and then what was the point of the company spending money on the refactor ?

Application/Code Architecture in real world businesses is extremely tough given moving requirements, endless legal/financial edge cases, and subtly different but similar concepts across different business domains. It's gets even tougher when you have to make difficult decisions about cost centers and profit centers.

My firm has a super specialty team (extremely well paid) that goes in and refactors/clean's up codebase's that are identified as becoming less efficient. However even the average senior engineer lacks the experience and understanding to clean up code debt in most business codebases.

I’m really curious where you work, the team you mention in your last paragraph sounds like my dream job :D

Sorry can't say, but I doubt it's your dream job.

That team is expected to work any amount of hours, sleep in the office, and do whatever it takes to get the job done.

I work at such a firm with constantly changing legislative and organizational requirements, and while there is definitely a lot of moving target syndrome around business processing logic that this applies to, there are other things like a byzantine service architecture leading to people having to make web service calls rather than join across tables, a house of cards docker/kong setup that people are afraid to update because it's so difficult to debug, unit tests that take 10 minutes to run even in limited cases because of the poorly written migrations and other unrelated bad architecture/engineering choices. Those things could all be fixed with a very reasonable amount of effort for the productivity boost they'd give, but the technical leadership in the teams that owns those things is not super competent, so they're afraid to make any significant changes because they're not confident in their ability to solve problems that might arise as a result.

This reflects more poorly on your engineering leadership than your coworker imo. Where are the guardrails? Why aren't his migrations going through a pull request where you can review and say "this should be a batch insert?" If PRs are in place but nobody speaks up, why is the culture afraid of pointing these things out?

Oh, I totally agree, had I been the technical lead for that team I would have flagged a lot of that stuff. As it stands the lead for that team is also on the nice but incompetent spectrum to some degree, and since the code base they're working on is an inherited dumpster fire I get the sense people on that team have mostly given up on code quality.

I can’t speak for the GP but I am currently in a position where we have the PR, we make the comments, the fix happens (kind of), but then it all repeats the next time. It’s tiring for the (technical) PO and the senior dev doing most of the reviews (me). It does not seem tiring for the employee. He seems like he could enjoy doing this forever, often commenting about how much he’s learning.

Yeah this kind of stuff is always best solved with general eng guidelines.

I’ve been that guy many times. Having to do my PR 3 separate times over the course of a week because of feedback. IMO each solution worked fine, and the feedback was also fine.

The trouble with explicit guidelines is it’ll make clear that your high-clout engineers are always breaking them.

The reality is some peoples time matters more. And ideas aren’t always better, it’s about reducing the mental workload of one person at the expense of another person.

There was a comment on previous thread about how they beautifully offered the autistic guy his own somewhat independent projects and he excelled. This is unthinkable in many places. It’s common to have the one high clout senior guy who wants to maintain clout but doesn’t have the mental resources to offer autonomy of the underlings. One can dream, though.

Reply on news.ycombinator.com