Live data from Hacker News

Great developers are raised, not hired

sizovs.net

291–300 of 341 posts

Re: Great developers are raised, not hired

#291

Earlier quoted context omitted.

2 vs 15 depend on the person. If you're a single? none. Married couple with no child? none. Married couple wanting more children? yes, it matters. Parents who want their kids to enjoy life? yes, it matters. Parents who need to take care both in-laws and kids? absolutely, it matters a lot. 2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 10…

2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 100-200k left. Certainly not enough for retirement. In Seattle (USA), I suppose it depends on the area of your chosen. That was kind of the point of my replies. I live in metro Atlanta. Not exactly small town America. We just bought a house in the burbs two years ago - 5 bedrooms, 3-1/2 bath…

Majority of the hi-tech companies here are SaaS product companies that use AWS/GCP. But the scale isn't there.

I'm referring to million sctive users of messaging app.

Re: Great developers are raised, not hired

#292
post #155

We're in a labor market in which CS students are focused on drilling for the FAANG-style whiteboard tests. And many will tell you their strategy is to go to Google for 2 years of experience and resume-building, and then leaving rather than grind away and play the promotion game there. And everyone has known for 20 years that you have to job-hop to grow your salary in this industry. And most employees would be naive t…

We're in a labor market in which loyalty has and should have disappeared a long time ago. I used to have a nice stable job (7+ years), very happy with my 'arrangement' but then wall street rankings started a process involving layoffs.

I didn't get affected by the layoffs but after about 5 rounds where some of my friends/acquaintances got the boot, I saw the writing on the wall and actively started looking outside. Because it's way more comfortable to be laid off when you have an offer in hand. That's when I realized how underpaid I was. Since then, I made it a professional goal for myself to switch jobs every 2-3 years so that I don't leave money on the table, as the only loyalty I have is to myself and to my family.

Every company, after a while, will start paying you less if you don't climb the corporate ladder to go into management. They will pay you as less as possible considering the risk of you leaving, slowly transition you into working on the old stuff while the new hires will get the green projects. Ok, I'm generalizing but nobody can deny that newcomers are always treated better.

But mentoring transcends companies. I still have great professional relationships with past direct reports working in other places and more often than not they still ask for advice when it comes to their overall careers.

Re: Great developers are raised, not hired

#293
post #286

Earlier quoted context omitted.

Simple. How much would it cost you to pay someone to replace them at market rates and then add the amount it would cost you to give them time to ramp up on the institutional knowledge and codebase.

Well, not really. The phrase was specifically about how much value they bring to the company. Market rates have no meaning in this context. E.g. how is "if a team works on a product that no customer seems to use/purchase/pay for, what is the value that team brings to the company" connected to market value? I would say it isn't.

You’re taking the use of that word too literally. I meant it as what perceived impact would the addition/omission of an engineer of that level have on a company? The stuff that factors into determining annual budgets.

Re: Great developers are raised, not hired

#294

Earlier quoted context omitted.

2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 100-200k left. Certainly not enough for retirement. In Seattle (USA), I suppose it depends on the area of your chosen. That was kind of the point of my replies. I live in metro Atlanta. Not exactly small town America. We just bought a house in the burbs two years ago - 5 bedrooms, 3-1/2 bath…

Majority of the hi-tech companies here are SaaS product companies that use AWS/GCP. But the scale isn't there. I'm referring to million sctive users of messaging app.

Why is that the only definition of complex? Most complexities in business comes from process complexities or even business complexities. I once worked with a software as a service company that provided software for the car repair industry. We had to translate these rules for both the repair shop and the car owner.

https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...

There is more to it than this.

Did we have millions of users? No. The rules were complicated, and most processing happened once a month. There is a central exchange that both sides go through.

I’ve had three jobs in healthcare. While the scale of users weren’t anything crazy. The business requirements were complex.

Re: Great developers are raised, not hired

#295

Earlier quoted context omitted.

> Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that. That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.

With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level. You pay them market when they need to be trained, you pay them market when they move up the skill food chain.

He is a loss in short term. He is supposed to be a net gain in long term.

If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.

Re: Great developers are raised, not hired

#296

Earlier quoted context omitted.

Usually, the teaching/mentoring is not free either. So you can a) hire someone who needs training and then train them, or you can b) hire someone who is productive since day 1. The people in a) cannot expect the same salary as b). Otherwise, there would be no point in incurring the costs of training them. Unfortunately, once you train them, someone can snatch them as people in b). You incur the loss, someone else ben…

Your outlook is causing you to lose.

You assume too much.

I take the world how it is; including human behavior. On the other hand, you assume someone owes you a training and a then immediately a wage that is the same as someone's who came with all the skills needed.

Re: Great developers are raised, not hired

#297
post #255

Earlier quoted context omitted.

You have it backwards. We are not trying to have cheap labor. We are trying to have more labor. However, the experienced people are limited resource, so the next step is to find inexperienced ones and train them. However, that doesn't work that way so easily. If you train someone for 6-12 months (during that time the trainee not only isn't making you any money, but other people, who otherwise would, are not either),…

Ok. Keep blaming the employees for your retention problems. It's definitely not your fault. I'm sure it will work out.

I don't blame anyone, just filter out the too selfish ones early. If they can't go for win-win of both sides, they can try their moves elsewhere.

Re: Great developers are raised, not hired

#298

I officially mentored someone at my previous company and helped him move from a support tech role into a software dev position. It was incredibly rewarding. But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someon…

2. If great people don't have growth path at your company, they'll grow by going elsewhere.

Re: Great developers are raised, not hired

#299

I officially mentored someone at my previous company and helped him move from a support tech role into a software dev position. It was incredibly rewarding. But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someon…

People choose where to work, and money is only a small part of that decision.

Invest in an employee, give them meaningful and interesting work, and the resources to grow, and you will generate a lot of value that doesn't show up on the books: loyalty.

From the financial perspective, it is almost always cheaper to get more out of a current employee than to go into the market and find someone new.

IMO there are two types of companies: those that know how to develop talent, and those that only know how to import it. The former are often the ones that have a long bright future and create a big impact on the world.

> by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.

This only holds true in a zero-sum game, which the economy is not. Improving the skills of employees actually makes the entire pond bigger.

Re: Great developers are raised, not hired

#300

Earlier quoted context omitted.

With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level. You pay them market when they need to be trained, you pay them market when they move up the skill food chain.

He is a loss in short term. He is supposed to be a net gain in long term. If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.

Again, if an entry level dev is a loss then don't hire entry level devs; your company does not adequately utilize them.
Post reply on HN