Hacker News Reader

Comment by rosser | Hacker News Reader

Right, because your growth as an engineer trumps the company's concerns over having a stable code base.

I can't count the number of times I've had to give some variation on this speech to junior engineers of one stripe or another: The company does not exist to give you cool things to hack on. The company exists to provide a product or service to its customers, from whom it collects revenue, in order to repay its investors, pay its employees and suppliers, and hopefully also make a profit. To the extent playing with cool, new, whiz-bang furthers those goals, it will happen, but whiz-bang is neither necessary nor sufficient for those goals. In fact, whiz-bang for its own sake can often be inimical to those goals.

Also, nice false dichotomy.

View on HN

I don't agree with the comment you replied to for a variety of other reasons but your reply is really out there. You could say exactly the same thing about any job benefits including a salary. Whether it's "essential" to the company on paper doesn't mean much.

We're blessed to work in an area where it's possible to grow your own skills while staying within the same company. If a company can provide this to its engineers, it's a win-win - employee skills improves, they want to stay longer, etc. And let's not forget humans, not AIs, are at the helm of those companies.

An employer is legally required to pay you for your time.

They aren't anything whatsoever to let you build things that they're somehow going to depend on using NewHotness-0.1.3.

EDIT: Look, I'm not saying growth and exploration are bad things. I'd never have learned the tools and technologies that have fed me for years now, or been able to expand those skills in ways that have made me tremendously valuable to the people who've decided to pay me nontrivial sums of money in exchange for my knowledge, skills, and time, if I hadn't been, as you say, "blessed" with opportunities to try new things.

But there's a difference between acting like you're blessed, which to my mind entails exploration with respect for the needs of the folks who are paying you to explore, and gratitude for the opportunity to do so — and acting like you're entitled, which ignores those things, and treats it as an exercise in résumé-padding.

Yes? That's not really relevant. You can just as well say "The company does not exist to give you money. It exists to provide a product to its customers."

When you're getting a salary you're standing in the way of the company making that money they're giving you. It's very counter-productive (and illegal, as you mentioned), but if you find this silly maybe you understand why I find your original reply silly.

But the company doesn't exist to give you money. That you, specifically, get paid for your specific services is incidental to the company's purpose, which is, indeed, serving the needs of its customers. Your job is to facilitate that, not to play with cool new tech.

You aren't "standing in the way" of them making the money they pay you; they're making a choice, with every paycheck, that your time is worth more to them than what they're spending to keep you there. You upset that balance by introducing instability into the stack because it's new and shiny at the ultimate risk of making that exchange no longer worthwhile.

>Right, because your growth as an engineer trumps the company's concerns over having a stable code base.

When a good engineer can easily move to dozens of other companies, yes, it does. If I felt like my growth had stagnated and my employer wasn't willing to work with me, I'd move on.

And I'd submit that a "good" engineer is, by definition, the kind that understands when it's appropriate to use new technologies, and when it's not — and "Look, shiny!" isn't, IMO, a good enough reason.

And pushing — let alone threatening to move on — to use new tools when they aren't appropriate? Please, go be someone else's problem.

It looks like you two are in violent agreement.

Here's the problem: Everything, no exceptions, starts out as "Look, shiny!". Usually, you need to play with it to find out if you even have a use case to justify spending the resources to do a formal evaluation. Reading the docs is a poor substitute for deploying it.

Now what the article talks about is "shiny!" being pushed into production. No, no no no no. Never do that. There's no excuse for just dropping new untested shit into prod where customers can trip over errors - I think everyone can agree?

But if hypothetical you is preventing your hypothetical engineers from indulging their curiosity and trying out new things to see if there's even a business case to be made for production use ("But there's no time" counts here), you're hamstringing the engineers and hamstringing your business.

Yeah, this is a good summary. There should be room for experimentation in isolated, non-production environments if the engineer in question is trusted and can propose a hypothesis better than "I think this will make my resume better". That stuff shouldn't be rushed out to prod without thorough vetting both internally and externally, which, much to the dismay of junior engineers (and not-so-junior engineers with bad judgment), often means letting a tool age a little bit before you bet the company on its stability. Unless the tool truly revolutionizes your particular line of business, and let me pre-emptively state that there's a 99.99% chance that it doesn't even if you think it does, there is no harm in letting other people be the guinea pigs.

> in violent agreement.

Violent agreements are lovely when they're sorted out by the market: at the moment, the best engineering talent I know would not be caught dead working on (just as an example) PHP.

There's simply no need to let your skills and salary stagnate when you can get paid more for working with the state of the art elsewhere.

Demand is simply too high, and like anything, there's tradeoffs: you can get anyone to do anything for enough money. But "great talent," "cheap," "low autonomy," "fossilized tools," will require some compromise.

Why are you so angry? No snark, honestly just wondering what experiences has led to this in a managerial aspect

That's your choice. But as a professional, you should do the best for your employer or customer while they are paying your salary, and that means adopting the right tools for the job, not your resume.

> The company does not exist to give you cool things to hack on.

Until you start losing employees to competitors who do offer cool technologies to work on. Your patronizing tone about how "junior" engineers just don't understand business is unwarranted. ALL engineers, not just "juniors", need to stay relevant in their field. Some of us actually enjoy what we do, too. Keep using antiquated technologies and watch your talent pool dwindle and your product gradually become obsolete.

I think a lot of engineers would consider it a selling point if the company gave them an opportunity to explore new technologies, so long as they are working on business goals in parallel.

I like to call this Resume Driven Development.

I'll just consider myself happy I don't work with a manager like you, then.

The company doesn't exist for me to hack on cool new things. Of course not. But what you fail to understand is that I'm a very intelligent person who is not planning on spending the rest of my life doing shitty simple e-commerce UIs, or whatever it is that you do. It's easy to think nothing but the goals of the company matter, especially if you're an awful founder, but the world just doesn't work that way. We all need to move on when the company likely dies, and I don't want four years of "I had no choice but to work with crap" on my resume when this happens, just because I had an asshole boss who hated other people who did smart things around him.

Reply on news.ycombinator.com