Hacker News Reader

Comment by H8crilA | Hacker News Reader

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then that's probably what you should deliver. Then watch it blow up, or maybe it will actually be good enough.

View on HN

The fastest way to cap your career growth is to think about yourself as someone whose role is to take a spec and provide a technical solution inside that box.

Upper management values – and pays accordingly – people who go beyond that. Learn some finance, learn to mentor others, learn to talk with a customer and understand what they're really after. You'll gain trust and find that you're being pulled into things far earlier in the development pipeline, which often puts you in a place to build better products.

Upper management won't value you constantly disagreeing with them on risk/reward tradeoffs like "how finished does the code need to be" or "how many bugs are OK for now." Maybe they say "yes, but if we don't get it done by the deadline, we might lose $LARGE_NUMBER in business because..." After that point, there's a difference between seen as usefully raising a concern and being stubborn and annoying.

Or, possibly upper management is just clueless to the cost of the bugs that are shipping. But you still probably won't get far if you just say "this is too buggy" and can't show them why they're wrong and you're right about it harming the business. Maybe you can persuade them if you go get some data. Maybe not.

Ultimately, if the kind of software they want doesn't line up with the kind of software you want to build, don't expect to get rewarded for constantly complaining about it. You're probably better off finding a place where you align better in terms of what type of software they want to ship.

It's the fastest way to learn to understand your career limits, stop worrying and start to love what is possible to love in that job

>Upper management values – and pays accordingly – people who go beyond that

They love when many do that while they pay accordingly only to the very few in order to entice the others.

Oh, playing the ladder can be rewarding. But you don't achieve that by saying "our code will be piss if we ship too quickly" if a decision has already been made without you. Don't be clueless, you must get your seat at the table first.

ive had issues with management paying me accordingly. lucky me in obsessed with mentoring

> If they decide to sacrifice quality for speed that's their problem/decision. [...] Then watch it blow up, or maybe it will actually be good enough.

You apparently have never been sued for your managers decisions.

Here is how that was for me:

My manager released something I worked on, despite me saying that it would need a few more months of work. Apparently that would have made this unprofitable, so he disregarded my advice and they released it anyways. I joined the company when this project was already a Year late. So it was not surprising that this project was close to costing more than the customer would pay.

Except for a few interns, I was the newest dev in the company, so I didn't push super hard for more work on this project. However I was the most experienced dev on the team, so I should have pushed more.

Or should have at least got it in writing that they decided against my recommendation.

When it eventually crashed and caused a 30 minutes outage I was fired.

Why? Because it was my code that was the problem of course. Never mind the fact that I told them it is not ready and that the error wasn't even code that I WROTE. Some intern wrote that part. I wasn't a lead or manager and had nothing to do with it.

They then tried to sue me for more money then they ever paid me. 30 minutes of factory outage can be very expensive which they of course tried to recuperate out of my bank account.

I was very lucky that I had a good lawyer. Actually I could only afford a very junior lawyer, but he was sick on the day of trial and asked his professor to go instead. I was probably super lucky with that one.

https://en.wikipedia.org/wiki/Arete

Because you eat shit later when it blows up or makes your life more difficult.

Also, not having agency about how you spend your energy eats away at the soul. That's more subjective, but I'll do a way better job with way less effort if I am a primary decision maker of what work I'm doing instead of an intake machine.

I'm honest about delivery dates, but I do deeply care about getting a project across the line on time. Not just because it gets me cooler, more demanding projects with larger compensation, also for its own sake. It's fun to win, especially when the timeline isn't arbitrary and you can pull it off.

There's a saying when I was in the military: "If it affects you, it's your problem".

If your code blows up, it will come back to haunt you. Now you get to fix your code, except it involves a bunch of other teams. Maybe that's what you want, but most likely not.

This _should_ be true, but isn't always, if you're at a company (or just have a manager) who will let the mess/blame fall onto your shoulders.

That being said, if you're at said company/have said manager, you should get a new job. I hear the market is hot.

True, but the "be good enough" will probably be updated on what "good enough" is after you deliver your first impossible project. It'll eventually catch up, but that's just how bad executives and bad companies manage.

If your team fails because you have incompetent leadership, then YOU are the one who suffers.

Upper management doesn't go around looking at what individual people are doing. They just see Team X as a whole keeps having problems, so Team X is literally sitting around and doing nothing.

There's no need to talk to people and communicate. Just fire them. There's no other possible reason they're having problems other than lazy engineers not doing anything.

This advice is soo very wrong. As a programmer you need to think first. The code you write is gonna affect your life maintaining it. So it does affect you or some other developer maintaining it. By actually caring you make things easier for you and your peers and that helps you grow your career.

Whenever someone writes a comment like GP's, it's safe to assume they are not involved in long term maintenance of a system. Or they're like my current team, reveling in the paid OT their shoddy work lets them justify (which is now unpaid for them, but paid for me, watch your contract terms people!).

If you're the kind of developer/programmer that cares about their work, then your company probably doesn't know how lucky they are.

You care if you work in security, and ops but perhaps to a lesser extent.

Reply on news.ycombinator.com