4 ms·

"But generally how else are you going to gauge the compensation of any individual reliably other than market rate?" If you were a business owner, what would be

• Xylakant 7y ago
  Another thing that often gets forgotten is the cost of (long term) employees leaving. They take so much institutional knowledge with them. I'm currently watching a case unfold at a client where all people with intimate knowledge of a crucial component left - the cost of training up new people on that component will eclipse any reasonable increase in wage that they could have given to the team, not even accounting for the increase in bug-rate while the new folks figure out all the pitfalls that software tends to accumulate over time. Documentation helps, but people knowing their way around the code is better.
  • uk_programmer 7y ago
    I think us developer overstate how important we think this is. Unless time to market is a consideration then they will probably just accept throwing people at it and then get some poor souls to clean up afterwards.
    • kqr 7y ago
      That probably costs more, though. Software engineering is mainly knowledge work. This means the majority of work consists not of building stuff, but acquiring and organising knowledge. I've read somewhere that about 50% of the job is gathering information. When a person leaves after having spent two years at a company, it might look like you get to keep everything they've been working on, but this is far from true. If the 50% assumption is correct, a person leaving after two years means you throw a full year of work into the dump. This is a huge cost, but it's hidden.
      • uk_programmer 7y ago
        This is exactly what I am talking about. You are overestimating how important it is. The code is there and (presumably) in source control. It really isn't that difficult for someone to get the source, compile it and fire up the debugger and carry on where the previous person left off.
        • Xylakant 7y ago
          I’ve seen very few projects of more than moderate complexity where “check out code and compile it” is the complex part. Who’s consuming the code? Who are the stakeholders? How does this component integrate into the full picture of the application? How do I need to talk to that person that I really need to change something?
          • uk_programmer 7y ago
            I think you are missing the overall point that you are overestimating how important knowing that is.
        • kqr 7y ago
          And I'm saying that if you have only, or mainly, worked at projects where all information (including about failed historical approaches and why they failed) is encoded in the source code, you have been very lucky to the point where I have a hard time imagining that to be true. There is so much implicit knowledge that goes into the finals source artifact that is not spelled out.
          • uk_programmer 7y ago
            Sure Domain Knowledge is important. But again this can all be discovered as you go along. I had an interview at a this week for my next contract where they made redundant most of their employees as the business decided to just go with turnkey applications. They will get someone like me in for 3 to 6 months to do application maintenance on anything they can't replace. This will be stuff like implementing stuff from penetration-testing, upgrading the applications and documenting missing bits and pieces and letting the business know what needs doing and where. I don't need a pension being paid, no HR overhead (they can just ask me to leave whenever pretty much). I will be able to gleen enough from the business and their IT to piece the bits together. This is literally my bread and butter.
• uk_programmer 7y ago
  Probably more than whatever your competitor in the same market would be offering them i.e. above whatever the market rate is.