Hacker News Reader

Comment by ThalesX | Hacker News Reader

Sorry next developer, I'm on a tight deadline, used to love this craft, now I just do what the product people tell me to get a nice paycheck.

View on HN

Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.

There are cases where the tradeoffs don't involve the actual codebase. For instance, there are certainly many developers who are 3x faster than the average developer simply as the result of having enough experience and/or skill to know which tools and/or approaches are optimal for a large subset of the kinds of problems they encounter in their typical work, such as a developer familiar with a particular ecosystem accomplishing some task in 10 minutes by knowing which library and which function to use, and how, whereas another might take hours (or days) to accomplish the same task since they have to figure out what tools are even available to solve an issue and how to use them, or worse (sometimes), rolling their own solution where a library implementing the functionality already exists. The tradeoff here is simply that it will be harder to find such developers, and they'll generally want higher compensation, but their work will not degrade the quality of the codebase, quite the opposite.

My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best.

"Fast must be cutting corners and not just actually better at programming" is a weird fallacy to hang your hat on.

> the majority of developers I ever encounter at work are usually slow because they're bad engineers

hm, something about this that I just can't put my thumb on

It's a bit elitist[1]. They're saying we should expect 3x better performance from engineers. We should also expect them to write good code at this pace. The only reason we don't have these things is that most engineers are simply bad engineers. Only people the author perceives as good enough should ever be used as a metric of normal productivity. Presumably the author puts themselves in this group of good engineers.

   1. https://en.wikipedia.org/wiki/Elitism

"Majority of people who drown cannot swim."

I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team.

The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way.

He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.

Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.

There is always a cost to everything.

> There is always a cost to everything.

There's a huge cost to having engineers who are bad at understanding and solving problems. The cost of having people who are good at understanding and solving problems is supposed to be that you pay them more, but that's not how employment incentive structures work in practice because information asymmetry and stigma around talking about salaries.

While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!

I agree (unless they also pay you three times as much, in which case fair enough).

Sounds like they're looking for a person who'll work 3x faster than the rest of the team by taking shortcuts and slowing everyone else down.

"You'll get to work on a codebase for whom the entire development mindset has been 3x-speed-at-all-costs."

Yeah..... pass.

I like those offers, they self-identify as places to avoid

Sorry future me, I'm on a tight deadline. If I spent an extra two hours making this better now, you wouldn't have to spend two days fixing these problems. You're probably still on a tight deadline.

"I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams

The craft is not the code, but the product.

You can have beautiful code and garbage product, and great code and a garbage product.

If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.

That’s not a great way to look at it. You can be passionate about the craft and not passionate about the product. You can usually find interesting problems relating to craftsmanship even when doing things you’re not thrilled to do.

Let’s be honest: sometimes you’re not “changing the world” like many founders like to think, just building yet another shopping cart.

If you lose love for your craft there’s no product that’ll cure it.

Well said. I am certainly not in this game because I love building forms. Mastering my tools of choice grants me satisfaction. It's hard to find a place working on a product that is truly interesting, but fortunately at least, finding a place working with tools I like is easier.

But you're trying to build a damn good shopping cart, which is the product.

The code analogy here would be nerding out on how to use a hammer in spectacular ways, but not really do anything interesting with it.

You can still really love your tools, but you shouldn't focus on them as much as what you're building with them.

> The craft is not the code, but the product.

These two are not disjoint, but instead quite related.

> Your job is to deliver good product, not good code.

If your job is software engineering, then "good code" is what facilitates "good product." It boils down to maximizing the "abilities":

- Understandability

- Applicability

- Testability

- Maintainability

- Flexibility

- Durability

Yup, good code helps to deliver a good product, but you should not focus on the code, rather focus on how the code influences the product.

Better to have hacky code that delivers value than to deliver nothing.

This is a false dichotomy IMHO.

"Hacky code" is most often a result of those responsible for delivery having gaps in their understanding of the product need.

When engineers have a deep understanding of what is needed, there is rarely a need for hacks. Of course, the obvious exception to this is when libraries and/or external services mandate them.

It's true that the product should take priority over the code, but there's a limit to by how much. If the code is bad enough, its low performance, bugginess, and slow feature development will eventually be reflected in the product.

Performance and bugs are product features, not code features.

Who cares if it slows down feature development if you never have to change it. If it does impact the product, it then becomes part of the product value you're delivering. This is the time you should be investing in better code.

Can’t it be both?

It absolutely can!

I'm not saying that you should disregard your code, just that it's not what you should put at the top of your list.

You can build amazing products with amazing code, and they will often raise each other up.

A great example is Redis, that codebase taught me how to write C code, and I also use Redis everywhere.

Reply on news.ycombinator.com