Hacker News Reader

Comment by purple-again | Hacker News Reader

Cash Rules Everything Around You. The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.

I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.

View on HN

What a toxic environment, it sounds like you did that developer a favor in the long run by saving him from having to work with you.

A developer took the time to review the existing code, and point out things that could be improved upon. That's part of our job. Even if you don't want to make any changes, or he's wrong about some of the feedback, you should be grateful to him/her.

How much revenue your code is earning says nothing about the quality of the code. That you feel the need to mention it says something about your ego.

> How much revenue your code is earning says nothing about the quality of the code.

It does say something. In this case, it might be saying that, for this particular application, the quality of code is simply not that important.

Or perhaps that figure could be doubled with leaner code that's quicker to work with and understand.

No it doesn't. It's a variable that doesn't enter the equation at all.

Maybe the technical debt should be reduced, saving the company money down the road by reduced maintenance costs and reduced issues as development continues.

Maybe the code is feature complete and there's no reason to change what works. It has technical debt, but perhaps the business calculation is that there's not enough benefit to cleaning it up (and in fact messing with working code may introduce issues.)

Either way you look at it, how much revenue it produces doesn't enter into the calculation.

Now you might say the revenue is so low that the code brings little value to the company and so the technical debt doesn't matter. But again that's looking at the wrong thing. Even if it brings in zero revenue, as long as development is ongoing because it brings some other form of value to the company, then the technical debt matters. The right things to look at are the costs involved in cleaning up the technical debt, vs the costs of continuing on while ignoring it. It's all about weighing costs and not about revenue.

Revenue is actually the only calculation - it is a business.

So they need profit, which is negatively impacted by costs.

No, it's profit = revenue - costs.

But it doesn't matter to this particular decision which is weighing one cost (technical debt) against another cost (fixing said debt.) There is no revenue in the calculation at all to consider, just costs.

It’s possible that this code has bugs that have yet to be detected. It’s a fact that quality is important if it can generate losses. Style may not be particularly important, but reliability is.

> How much revenue your code is earning says nothing about the quality of the code.

It says everything it needs to say. Revenue pays developer salaries.

>Cash Rules Everything Around You

No, believe it or not some people prefer dignity.

>The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.

Whether it had $300,000 or 10M revenue, doesn't change the fact that it might had 300 things wrong.

Not to mention that a single thing done wrong could still result on some large embarrassing outage, customer data exposure or deletion, etc, and result in costs/fines worse then those $300,000.

("Yeah, I've made millions out of this web service, who cares that I store customer credit card details in plain text").

>I have dozens of applications in production

Any specific names, so we can avoid them?

("Yeah, I've made millions out of this web service, who cares that I store customer credit card details in plain text").

The European Union. If you have any of their residents in that database, then you have about 3 weeks to fix that...

Unless they don't audit you.

In which case you can continue not to care.

From my own experience talking with CEOs, I really think that will continue to be the case. If you're asking them to accept a large concrete loss now to prevent a hypothetical even large loss at some point in the future, they won't care.

> No, believe it or not some people prefer dignity.

Nobody ever ran a successful business on dignity.

You'd be surprised.

It might be true that nobody ever made a hugely profitable business on dignity.

But it's absolutely false that that aren't businesses that are successful with dignity.

So, depends on your definition of success.

If it is "supports me and my workers and can even moderately grow and produce good stuff for my customers" then many did.

If it is "I want to eat the world like Uber" perhaps no one die.

s/no one die/no one did/

"Dignity and an empty sack is worth the sack." - Ferengi Rule of Acquisition #109

Yvon Chouinard built his billion dollar business Patagonia with dignity. One of the best things I learned from reading his book, Let My People Go Surfing: The Education of a Reluctant Businessman, was to grow sustainably and only when necessary. It surprised me because it seems to be the exact opposite advice of mainstream startup culture, exponential growth.

You fired for someone finding bugs in your code?

This is beyond ridiculous and you're creating a hostile environment for your developers. It'll come back and bite you in the future.

He was fired for doing an unsolicited code review, which the grandparent did not ask for nor deemed necessary. Plus the wording implies the grandparent felt attacked - as the thread earlier mentioned, you shouldn't barge in and go all Steve Jobs and yell THIS IS WRONG! THIS SHOULD BE FIXED! right off the bat.

I do understand it though, and when you're fresh in a project it's easy to go for the low hanging fruit like that. But, be subtle about it, ask if it's welcome, that kinda thing.

What the hell is an unsolicited code review?

When you start work with a new codebase you spend some time to get acquainted with it. It only makes sense to take notes of bugs or possible improvements when you do it. A pair of fresh eyes will always find improvements to be made.

This so much.

If you expect me to take on a project without looking at the previous code then you're simply a fool.

I really wish companies let you have a look at the codebase before you started. Like, sign an NDA and give you 15 minutes to look at it.

It would've made me reconsider the job I currently have. Upon saying that, I am enjoying the challenge of trying to eliminate as much tech debt as possible.

I see your point, and I agree that it's good to be nice to people.

But being in leadership and spending time around a few hundred coders over the hears has taught me the value of someone who does this.

I hope this wasn't the reason the person was fired, because it's a missed opportunity for management: someone with that kind of drive and commitment to quality is valuable to have - and hard to find. I can count with my hands the number of developers with that kind of drive I've found.

With no further context - meaning: I'm making a lot of assumptions here - I think I'd've helped them schedule time to evaluate these opportunities for improvement (how much do they cost to fix? how much will they cost if not fixed? How can we prevent this from getting in new code? etc.), and when the numbers are right - schedule time for fixing them, too.

If non-agreeableness was their sole defect - it could've been worked on over time. That's what leaders are there for: to help their collaborators grow.

Grandparent?

Parent = the comment that this comment replies to.

Grandparent = the parent of the parent.

Often abbreviated as "GP".

Thank you!Neverheard of it referred to that way before but it totally makes sense!

Why many of us do this: It's often easier to refer to previous posts relatively rather than to cite usernames. For "OP", others will know to simply look (or think) back up to the top (or thereabouts). For "parent", it's usually the comment above the one that is being replied to. So parent to your post is what I'm referencing, but I'm now replying to you (and have taken no notice of the usernames because it's easier to focus on the content).

One also often sees the same line of argument continued by other posters, so while the conversation is consistent with two (or more) sides being explored, the posters change. I really like this about HN - it really is a group conversation most of the time.

'unsolicited code review'???

dafuq is that? The more eyes on a piece of code, the better.

Sounds like he lucked out by you firing him.

"dozens of applications in production"

is that dozens of apps supporting one business, or dozens of businesses?

Plus 2000 lines > $300K - I think you beat Pieter "Think of the Frameworks" Levels - https://twitter.com/levelsio/status/938707166508154880?lang=...

Reply on news.ycombinator.com