Hacker News Reader

Comment by uk_programmer | Hacker News Reader

I am a contractor and I would expect to be paid the market rate for my skillset. The market rate for a .NET developer in the UK is about £350-400 a day (outside of London) in the UK. An Angular JS developer gets between £450 and £500. Thus at the moment (despite not being fond of it) I am (re-)learning Angular JS in my spare time so I can go for these higher paid roles. The same is generally true for the salaried market.

I appreciate there is a bit of a difference with a team of people. But generally how else are you going to gauge the compensation of any individual reliably other than market rate?

View on HN

I’m a (sort-of) contractor. My rates and selection of projects strongly takes the team dynamic at the clients place into account. Sure, I do have a rate that I aim for, but as long as a certain minimum is met, I’m likely to choose a place with a sane team and healthy social interactions over a dysfunctional hell hole. And places that pay everyone a reasonable wage at least tend to have that more often than other places.

This approach has shown to substantially improve my quality of life.

That is fine, I am mostly the same.

> And places that pay everyone a reasonable wage at least tend to have that more often than other places.

I've seen almost no evidence of this other than at the real extremes. Maybe it is differences in the UK market vs elsewhere but typically you won't find a big difference in rate between one contract and another in roughly the same locale with everything else being equal.

"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 the correct referral market rate if the people whose compensation you are gauging is a tight knit team with years of experience on your specific business and customer needs?

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.

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.

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.

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.

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?

I think you are missing the overall point that you are overestimating how important knowing that is.

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.

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.

"But again this can all be discovered as you go along."

How are you going to discover that from just the sources without any institutional knowledge? It sounds to me this applies only to a specific niche you've managed to find. I.e. you get only those gigs where institutional knowledge is not paramount as the employers who need deep domain knowledge are not even trying to hire you. I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others.

The business stake holders are going to be there. Sure at some point it might be just too much work but typically there is somewhere in between where you can piece it together.

> I don't mean this in a deragoratory sense - it sounds to me you provide great value to your employers - but just in that you work in a specific market segment and what is true in your segment might not hold in others.

I've worked in many different sectors. Normally fintech though.

I'm sure there are lots of production codebases like that. But there are lots of codebases that actually require the institutional knowledge to use and modify - for example a decades old CAD application. So your example is not a universal rule.

I find it incredibly frustrating and tbh it saddens me when I say a generality in this case being "developers overestimate their worth to the business" and people chime in with all the exceptions that they think disproves it. Obviously there are exceptions to the rule.

However unless building the tech is the business you are seen just as a cost to the business in most circumstances.

Probably more than whatever your competitor in the same market would be offering them i.e. above whatever the market rate is.

Market rate for .NET contractors here in Stockholm is ~£570 a day (~£71/h). I wonder why market rates are higher here, despite standing still for many years.

Interesting that is above London pay rates even though having a look at the price of living it is only 20% more expensive. Probably just less .NET devs over there. Might have to apply for roles in Stockholm :)

Reply on news.ycombinator.com