The work that programmers do is not physical. Management have a hard time seeing the result of our work.

What always ends up happening because of this is that managers start to manage time spent instead of value outputted. Since the work done is all very vague for them, the best programmer is the one that finish their projects the fastest.

We do our own estimates and our subconscious is trying to "win" that race. Sometimes, we even get bonuses based on this. So we end up stamping time estimates that would only happen in a perfect world. Management use those estimates as hard deadlines. If you do not meet the deadline, it's your fault.

So you start to work crunch time at the end of months.

Since the work is virtual, nobody but the programmer cares about the quality of the work. Management pushes you to finish as quickly as possible.

You then start to work for free one or two extra hours a day every day to fix those things in the code that bring you shame.

The things management won't give you extra time to correct. You know this glaring security hole is going to end your career, even if management doesn't want you to correct it. So you correct it anyway.

You want better tools to insure the quality of your projects but since programmers have to build their own tools from scratch, management won't grant you time to build them.

You use some time out of your weekend to build them.

Nobody wants to use a dull blade so your sharpen your tools on your own time.

A few projects done the road, you work 20 extra hours a week without even noticing anything has changed.

... now imagine a new hire trying to compete without putting any extra time. On his first meeting, he gets asked why he takes double the time to finish projects. He quickly end up doing the same as everyone else. Everyone is working for free because everyone else is.

It's a vicious circle that's very hard to break. Most of the time you only notice it when you are a new hire... and nobody listens to new hire. Heck, what management would allow the situation to get back to normal? They are getting so much free work.

I've read this narrative that only the programmer cares about the quality of the work many times. I find, however, that sometimes the programmer cares more about showing off how clever they are then building a quality and simple system that is delivered in a reasonable time frame.

Hacker News has this narrative that programmers are always right and always smarter than "management" or any other non-programmer. That's not reality though. Programming isn't some special discipline where everyone is great. There are a lot of poor programmers out there like I describe above. Management often ends up not believing people because of this, just like in other professions.

Developers need to share the responsibility of the situation, it's not all just "bad managers". Developers need to start caring more about the people they build products for rather then simply their wallet and personal "fun".

Of course this is but an anecdote from my point of view based on the workplaces that I experienced.

What I've lived through a lot of time is teams of senior programmers led by junior managers. Sometimes they are fresh out of school and have never led any team. Heck, sometimes senior programmers turn into code monkeys because they are hired as nothing more than glorified trophies. IT teams having to answer directly to sales department managers, etc.

Teams of juniors or intermediates are way more likely to make mistakes such as the one you describe. I've seen my share and I do agree that they exist. People migrating entire projects to the language-du-jour and creating a bad situation for everyone because they didn't master that language and ended up refactoring stable solutions into shaky messes.

In a perfect world, we would have a team of strong senior programmers leading a few juniors under a strong management team.

> If you're writing a web application, shouldnt you take care to make sure its secure and well written? Just because nobody had to pick hair out of a windshield doesnt mean a hacked webapp doesnt ruin just as many lives.

No. In fact, where I work (massive multistore ecommerce), this attitude is actively discouraged. They don't want developers spending valuable time worrying about what a malicious actor would do or how it can be protected against. That would be an inappropriate use of company time on non-revenue-generating activities. We HAVE to spend all our time feverishly implementing whatever features business put in for development this quarter to bump conversions and average order volume. If we focus on endpoint security, we aren't adding features, and so we might miss the revenue budget and then stuff REALLY hits the fan.

> An example: if im rebuilding the idler and pitman assembly on a fourteen ton truck, theres no hustle. there is no competition to do it "the fastest." You do it right, because if that assembly fails in a turn you could cause a pretty horrible accident.

In this scenario, you don't have to be in the situation of some company in some other country figuring out a way to sell people a machine that'll rebuild the idler 50% faster. In the SaaS & ecommerce landscape, being beaten to market or having a competitor that can iterate faster than you means you're dead.

> In the SaaS & ecommerce landscape, being beaten to market or having a competitor that can iterate faster than you means you're dead.

I understand how common this sentiment is, and maybe in some markets it really is true, but for the most part I just don't buy it that SaaS and eCommerce are zero-sum games.

I'm going against the grain here, but there are a lot of counterexamples -- look at all the time tracking apps, or all the fitness trackers, or all the file transfer software, or all the credit card processors. I'm pretty sure the number of actual zero-sum markets pales in comparison to the number that people believe exist.

Most SaaS software arent that unique. They solve the same problem other companies are trying to solve. Once you use MailChimp, you arent going to use Constant Contact too. Once you use Stripe, there isnt much reason to use Braintree, etc. Thus when a competitor gains a customer, it usually means one less customer for you.

> I understand how common this sentiment is, and maybe in some markets it really is true, but for the most part I just don't buy it that SaaS and eCommerce are zero-sum games.

I don't disagree with you, but it is shareholders & executives that determine how developer time is to be spent, not developers.

Office work is much different and programming is certainly different than a hands on job as you describe. It is far too often that the 'move fast and break things' ideology is pushed to meet deadlines or be the first to market, even if the product is broken.

Also, more similar to what you are familiar with, dealership mechanics and jiffy lube style shops are closer to the hustle mentality than your professional role. They are bound by time constraints because normal consumers will only pay so much for your time and there are standard limits to charge for a particular job. If you take longer than the standard time you can charge for, then the loss is yours.

All the flat rate monkeys working on consumer vehicles are working to slap things together as fast as possible (without doing such a terrible job that it comes back) so they can log the book hours and move on to the next job (presuming the shop is busy enough for there to perpetually be a next job).

I take it you work in a relatively high margin part of the industry. The skilled trades is just as much of a rat race in the low margin shops where the vast majority of people start their careers.

It varies from one company to another.

Responsible managers (and, by extension, companies) don't encourage this kind of behaviour, precisely because when it goes south, it tends to blow up in your face, badly, especially in heavily-regulated fields where legal responsibility is involved.

Irresponsible managers (and, again, companies) encourage this kind of behaviour because they think it better aligns with their business goals somehow.

That's the thing, quantity of 'acceptable' quality of work is valued over how high that quality might be. The minimum time is taken to proof and bugfix, because failures are addressed after they've already come up in order to pump out more product in shorter time. It's velocity, and high enough velocity overcomes any setback that affects a companies pocketbook. Entry level and middle management is burned out but quickly turned over and refilled with fresh meat from each graduating class, those that suffer through and keep up their velocity move up, eventually reaching a point in their career where they don't have to worry about their own output but rather the output of those under them. Your immediate manager in your garage will surely understand the value of your work, but your CEO is only concerned with getting to the absolute minimum time a truck is sitting in your garage idle rather than moving product on the highway, and your manager is probably fighting him on keeping or raising minimum time every quarter.

"sure its secure and well written?" There's no money in that, so why bother. Unfortunately.

Tradespeople will unionize and collectively bargain. Technology types generally don't do this.

> Technology types generally don't do this.

And the rationale isn't too different from this: https://www.youtube.com/watch?v=ONKkoiszVSs&t=409

I find it funny that people seem to think unions are these "shadow" type of organisations where no one has any say in how it should be run.

Unions are made up by people of a certain field/study...