5 ms·

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

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.

aaomidi 9y ago
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.
- Cthulhu_ 9y ago
  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.
  - toomanybeersies 9y ago
    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.
    - aaomidi 9y ago
      This so much. If you expect me to take on a project without looking at the previous code then you're simply a fool.
      - toomanybeersies 9y ago
        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.
  - iajrz 9y ago
    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.
  - nickthemagicman 9y ago
    Grandparent?
    - majewsky 9y ago
      Parent = the comment that this comment replies to. Grandparent = the parent of the parent.
      - mfoy_ 9y ago
        Often abbreviated as "GP".
      - deleted 9y ago
        [deleted]
      - nickthemagicman 9y ago
        Thank you!Neverheard of it referred to that way before but it totally makes sense!
    - coatmatter 9y ago
      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).
      - kaybe 9y ago
        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.
  - deleted 9y ago
    [deleted]
  - holtalanm 9y ago
    'unsolicited code review'??? dafuq is that? The more eyes on a piece of code, the better.
eloff 9y ago
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.
- balfirevic 9y ago
  > 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.
  - alex_hitchins 9y ago
    Or perhaps that figure could be doubled with leaner code that's quicker to work with and understand.
  - eloff 9y ago
    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.
coldtea 9y ago
>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?
- neffy 9y ago
  ("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...
  - coldtea 9y ago
    Unless they don't audit you. In which case you can continue not to care.
    - blowski 9y ago
      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.
- AnIdiotOnTheNet 9y ago
  > No, believe it or not some people prefer dignity. Nobody ever ran a successful business on dignity.
  - coldtea 9y ago
lifeisstillgood 9y ago
"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=en https://twitter.com/levelsio/status/938707166508154880?lang=...
radarthreat 9y ago
Sounds like he lucked out by you firing him.

aaomidi 9y ago

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.

Cthulhu_ 9y ago
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.
- toomanybeersies 9y ago
  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.
  - aaomidi 9y ago
    This so much. If you expect me to take on a project without looking at the previous code then you're simply a fool.
    - toomanybeersies 9y ago
      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.
- iajrz 9y ago
  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.
- nickthemagicman 9y ago
  Grandparent?
  - majewsky 9y ago
    Parent = the comment that this comment replies to. Grandparent = the parent of the parent.
    - mfoy_ 9y ago
      Often abbreviated as "GP".
    - deleted 9y ago
      [deleted]
    - nickthemagicman 9y ago
      Thank you!Neverheard of it referred to that way before but it totally makes sense!
  - coatmatter 9y ago
    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).
    - kaybe 9y ago
      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.
- deleted 9y ago
  [deleted]
- holtalanm 9y ago
  'unsolicited code review'??? dafuq is that? The more eyes on a piece of code, the better.

eloff 9y ago

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.

balfirevic 9y ago
> 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.
- alex_hitchins 9y ago
  Or perhaps that figure could be doubled with leaner code that's quicker to work with and understand.
- eloff 9y ago
  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.

coldtea 9y ago

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

neffy 9y ago
("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...
- coldtea 9y ago
  Unless they don't audit you. In which case you can continue not to care.
  - blowski 9y ago
    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.
AnIdiotOnTheNet 9y ago
> No, believe it or not some people prefer dignity. Nobody ever ran a successful business on dignity.
- coldtea 9y ago

lifeisstillgood 9y ago

"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=en https://twitter.com/levelsio/status/938707166508154880?lang=...

radarthreat 9y ago

Sounds like he lucked out by you firing him.