Hacker News Reader

Comment by extragood | Hacker News Reader

This article hits on some very good points.

I'd like to add another from the perspective of the hiring manager, now that I've had a few years experience in that role.

It's been my experience that people generally produce their best work after the first year. It takes a while to get to know any business: what its strengths and weaknesses are, and it's only with that understanding that someone can identify areas to make meaningful contributions.

If someone's tenure is consistently around their one year mark, it's unlikely that they've really ever expressed their full potential in a professional setting. They leave before things get really good.

Hiring is an investment - less what the candidate can do today, but what they can contribute over a more substantial period, given the right encouragement.

View on HN

> Hiring is an investment

I think this is why many employees are frustrated when they find out that new hires get paid substantially more than them. Which encourages jumping ship, to get a similar wage bump. I've said this before, I don't understand why wage renormalization isn't a standard practice and why it is considered controversial. When investing you don't just buy investments and then when they are working out and have good future potential buy new riskier investments for higher premiums. You should generally continue to add to what has been working. You should have a balanced profile too. You do need some risk (new hires) but you shouldn't spend all your money on new risky things when what's been working continues too. And just like you want to rebalance your profile frequently, to ensure you're not too leveraged, you too need to renormalize wages. People are frustrated because management is not in fact treating hiring like an investment.

Where I work we would generally pay the new hire and the existing employee about the same. I.e. there's no such thing as a new hire gets paid more than the existing employee of a similar "level". It's more likely to be the opposite. That said you usually aren't going to be able to hire someone away from their current job by offering them less.

The person jumping ship every year to get small raise is eventually going to run into the problem of not having accomplished anything worthwhile in their career. It's arguably better early on in your career to work for less but do things that are more interesting and have better learning opportunities. One might argue it's always a better choice.

As a manager I would like people to stay, and they mostly do, and I am going to try my darnedest to make sure they are compensated well for their contribution (including the fact that they are more effective by knowing the code base and the product). It is pretty tricky though with the competition constantly trying to recruit way from you and their deep pockets, ensuring people don't burn out or get bored etc. Lots of factors I can't control.

I definitely agree and can sympathize with this sentiment. But to the last part, there are market forces involved. Obviously the value of an employee isn't infinite, but if demand is high, then the wage should reflect that. It is becoming more costly to do computer science. But we're paying for brain power, not machines (something that other engineering jobs have to account for and can too be quite costly. Similarly, having out of date machinery is often a cause for low progress as well as employees jumping ship).

But I do want to know, as a manger do you consider things like yearly wage audits and renormalization. To me this is an important aspect that resolves issues like pay discrepancies, wage bias, etc. I think it also builds high trust with employees because it is a clear signal that you understand that things fall through the gaps but that you are attempting to resolve them.

I don't have to worry [too much] about this as a manager since it's part of our company culture. We pay everyone (in the same geography) the same for the same level. The level is primarily determined by a peer review process. I just have to make sure the process is actually working and deal with some weird situations that it doesn't account for properly. It's not perfect (nothing is) but it mostly works.

What’s to not understand? It’s cheaper. At least on a short term basis. Most people just take the lower pay and maybe complain a bit. A few leave for a pay bump. Still cheaper than giving everyone that pay bump.

> It's been my experience that people generally produce their best work after the first year. It takes a while to get to know any business: what its strengths and weaknesses are, and it's only with that understanding that someone can identify areas to make meaningful contributions.

My experience matches this, but I would add that the company shares some of the blame. It often takes a full year for the rest of the team, department, or company to fully integrate the new person and tailor their assigned tasks to their individual strengths and weaknesses.

I remember struggling to contribute at a company for several months for no reason other than the people I was supposed to be working with would forget to invite me to key meetings. Teams can get very comfortable working with each other and are naturally resistant to bringing in new people. It takes time to break down those barriers.

I worked somewhere for 3 months and did pretty much nothing for all of it. Then I quit because I hated feeling useless – most stressful job I've ever had. I don't think I'm well-suited for $BigCorp jobs.

In most of my other roles, I think I've often become a valuable contributor being able to "pull their own weight" within 1 to 3 months. On a number of occasions I think joining with a "fresh mind" who will say "you guys are doing what?! lol that's crazy, $this is so much better!" has been a real advantage, sometimes even in the first week. I'm not trying to paint myself as some sort of rock-star developer or anything, but in small teams people can get kind of stuck in a sort of an acceptance of the suckage they have, even when it's not needed. One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference.

I do think longer tenures are an advantage because people will have to live with their choices. I have a former co-worker who brags about what he did when he worked for us as being brilliant to this day, but we literally threw it all away because none of it actually worked well; it was complete garbage. But he never stayed long enough to have to deal with any of that.

>> One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference

bytebase.com could be what you are looking for.

Disclaimer: I am one of the authors.

This was like 8 years ago and I no longer work there; all that was really needed was a "versions" table and a "for file := os.ReadDir("migrations")". Even that basic version was already a huge improvement.

When I joined we didn't even have a CI, and everyone was committing to master, usually with undescriptive expletive-laden commit messages.

> It's been my experience that people generally produce their best work after the first year.

This is a strange sentiment based on my experience.

I leave most jobs after a year because they get boring. I've never not shipped a fairly important project in the first 6 months of employment. After a year nearly every place I've been at has been struggling to find that next thing for me to do since I've finished all the projects they had in the backlog when hiring.

My experience is that at most orgs the one year mark is when coasting begins and I personally find coasting incredibly boring.

You wrote it now you have to support the decisions you made and if you know you are going to have to deal with something in the future you will take the time to account for it but if you never see past a year you will never learn what really worked

Shipping is important, but what’s just as important is learning the impact of what exactly you shipped and how you shipped it. In software this is often done by operating and modifying the system in a series of experiments over time, including observing the relationship between the product and the organization that produces and maintains it, gaining insight into the delivery of software at scale.

For many of us, what we learn in meaningful stretches at companies, is a kind of capital that we leverage to gain access to opportunities that take our career in the direction we want to go.

If I may speculate, perhaps you are overqualified for the jobs you describe. Or, perhaps you love creating new things but not maintaining and augmenting existing things (which is fine, but just like short stints, is a quality that many hiring managers, especially at established companies, view as a negative. You could be an amazing serial startup 0 to 1 person though).

Of course it's easy. Creating features is the easy part of SWE. Supporting your features over years of changing requirements and refactorings is the hard part.

I wonder what would be your take on my stints (non-tech Ops guy here, based out of Asia/Europe for reference). I have changed jobs 5 times in 6 years:

# Company 1: First stint after university at a Bank. Management development program. Left after 4 months to join a startup backed by renowned European VC/accelerator. 4 months

#Company 2: Technically an internship here which was supposed to be full-time after 6 months. 3 months in, co-founder who was also my hiring manager died - startup was on the verge of sinking. 5 months.

#Company 3: Ops role with plenty of ownership at Food-delivery company (think Doordash for Europe). Left after 1 year due to personal reasons (had to move back to Asia due to medical reasons in my family) Good impact here though.

#Company 4: Asian unicorn. Impactful role, scaled a new business vertical to $xM ARR fwiw. Left after 3 years to change industry.

#Company 5: Booming startup that ultimately did not succeed. Very short time but still made some strides. 3 months. Laid off along with 75% of the company.

Now, what's your take if you were to look at my resume?

As you can see, I had just 1 long stint so far (3 years). My only saving grace is that my projects were at least somewhat notable. Especially in the current climate where entire teams can be laid off and many orgs are downsizing, I feel insecure that another short stint < 1-2 years would be a red flag to recruiters and Hiring Manager - circumstances notwithstanding.

Most companies do not invest in their employees and are more than happy to fire them at will. It's a two way street and employees have just responded in kind to how most companies treat employees. Obviously there are exceptions to that rule and that is usually where you see people staying longer.

"first year" it definitely varies by company, projects and experience level.

Reply on news.ycombinator.com