News for hackers. Stuff that matters.
Re:Ask HN: How do you evaluate a job offer and the company o... by Flammy on Tuesday March 28, 2017 @03:27PM (#13979821)
I'm curious what type and size of companies and industries you primarily work with?
Re:Ask HN: How do you evaluate a job offer and the company o... by wayn3 on Tuesday March 28, 2017 @03:50PM (#13980033)
The average customer is a manager of a small team between 6 and 15 people inside a company of 150-300.

For some reason, there are a lot of managers who have budget but are denied headcount by HR, which forces them to work with contractors. Don't ask me why that is. A lot of processes in old corporations make very little sense in the way you would expect common sense to play out.

Re:Ask HN: How do you evaluate a job offer and the company o... by nameless912 on Tuesday March 28, 2017 @05:32PM (#13980914)
This policy makes sense in the context of veteran employees: if a department is given a block allocation of funds instead of a headcount, it becomes much more lucrative to get rid of a senior employee and hire two individually somewhat less efficient, but together more productive, new guys than to keep the one experienced guy on. Headcounts protect the old guard and allow managers to say "I will keep x people on my software team" rather than "I will spend x dollars, so you're all getting a pay cut/fired".
Re:Ask HN: How do you evaluate a job offer and the company o... by wayn3 on Wednesday March 29, 2017 @10:02AM (#13986263)
Do people still actually believe that two warm bodies outperform one senior engineer who has worked on this particular software for years and therefore knows his way around it?
Re:Ask HN: How do you evaluate a job offer and the company o... by PeterisP on Tuesday April 04, 2017 @03:43PM (#14036465)
It depends on the situation. There are cases where a senior engineer outperforms three or more warm bodies and cases where two warm bodies would be much more preferable, it depends on the content of that job.

And I have witnessed a case where simply removing "one senior engineer who has worked on this particular software for years and therefore knows his way around it" was a key part of finally getting that software on track, as he was providing literally negative value.

Also, relying on particular single people who "know their way around" some code is an organizational smell - if you have such a dependency then that's a management problem/business risk that needs to be fixed. You do need shared ownership and people who can replace each other, and (except for the very short term) a better engineer will be more productive than a worse engineer who has been stuck on maintaining that code for years.