[bigiain]

Put in an amount of effort that you consider professional at work (by which I mean, put in enough effort that you're proud of yourself, even if you're less productive than you'd consider ideal for someone specialising in what they need). Use React on side projects. Look for better opportunities, and be more picky and curious about the actual work you'll be doing. You owe them no more loyalty or accommodation than they've shown you by misleadingly recruiting you.

Chalk it all up to career learning... Try not to get too personally invested or discouraged.

[throwawaysbdi]

It's difficult to be proud of anything I'm doing :). Whenever I propose a design for something, I'm told to do it the fastest way which is usually a bad hack.

I'm amazed the code works at all. The stack traces are more than twenty deep sometimes. I can't stand to look at it for more than 20 minutes without a break.

I need to be more careful next time I'm looking for a job

[bigiain]

Not "proud of what you're doing", but "proud of how you're conducting yourself". Make sure you can walk out at 5pm holding your head high thinking "All things considered, I gave them good value for what they paid me today".

Also consider that "the fastest way which is usually a bad hack" is sometime the correct pragmatic approach for a legacy codebase that's in the process of being replaced. Giving them the benefit of the doubt, think about whether the elegant design is really necessary if there's a ground-up rewrite about to happen.

Even if it's demonstrably true that they've been "claiming" a rewrite is "just about to start" for a _long_ time, sometime's that's just as frustrating a thing for management as it os for the coders - management may well honestly have always believed this rewrite was supposed to have started 12-18 months ago, and that it genuinely is only weeks away from starting... Just like they believed last month and six months ago... I've _been_ "that manager" before (and I'm sure I will be again).

[pagade]

Below link helped me to carry on while I was still there: https://www.joelonsoftware.com/2001/12/25/getting-things-don...

[wpietri]

> Whenever I propose a design for something, I'm told to do it the fastest way which is usually a bad hack.

And why do you agree?

One of the differences between professionals and other workers is that professionals are experts in how to do their work. If I tell my doctor to just write me a prescription because I said so, she'll just scoff. I can make requests, but she decides what will happen and how.

Especially if you're already likely to quit this job, then you don't have much to lose by insisting on using best practices. Sure, you have to honor their desire to do things reasonably quickly. But you don't have to keep digging the hole deeper if you feel it is professionally negligent to do so.

[bigiain]

Even doctors understand that sometimes it's necessary to meet unrealistic deadline by doing quick and dirty hacks.

When you or I break our collar bone, the doctor will immobilise it in a sling for 4-8 weeks while it heals.

If you're chasing a motorcycle world championship though, they'll go in and screw it back together with titanium support and get you back to top-level performance in 2 days: http://www.autosport.com/news/report.php/id/108388

Sometimes you need to cut your code open, jam in some temporary scaffolding or duct tape, then stitch it back closed again - promising yourself you'll go back in and take the kludged fix back out when deadlines and circumstances are less critical...

[wpietri]

You write this like I don't know that. I of course do, because like most people here I have written a lot of production code.

This person is in a place where they have spent years piling kludge on kludge. They never go back and fix anything, which is why they have such a mess. And here there was no emergency mentioned; he was describing their normal practice. It's duct tape all the way down.

At some point you have to draw the line and say, "No, from now on, we'll treat normal circumstances like normal circumstances, and save the duct tape for real emergencies." I am suggesting he start drawing the line. Either they'll give in or they'll negotiate his exit, and either outcome is good for him. As the Agile people say, "Either change your organization or change your organization."

[reitanqild]

The stack traces are more than twenty deep sometimes.

Haven't counted but I think this is totally not unusual when I work on Java which I consider a modern stack.

[throwawaysbdi]

I should clarify that's over 20 deep of our code , not counting all the framework stuff.

[db48x]

The depth of the stack is not a very good metric for code quality.

[masor]

Why is everyone quibbling with him about that. He just wants to express his opinion that the codebase is very bad in a more colorful way than by simply calling it doubleplusbad. Let's just take his word for it and move on.

[reitanqild]

Because we are trying to tell OP in a nice way something we think he will benefit a mot from rather than just what he seems to be wanting?

[throwawaysbdi]

It's bad in a lot of specific ways but I'm trying not to out myself since it's a fairly small company.

The overarching problem is trying to reinvent the wheel because the management thinks we can do things better than the language designers.

The end result is a buggy and generally bad reimplementation of core libraries. ORM, math, dates, full text search. There's a half-baked custom version of everything.

[macca321]

Add regression tests, replace with your own code. or quit.

[datavirtue]

Welcome to the real world. If you want to write elegant code using the tools of your choice I suggest building your own product or service on your time. The business NEVER cares about tools, languages, or best practices. Expecting the business to value this stuff will cause you to burn out and be unhappy. They employ you to add value. So add value.

[p0nce]

The problem is the business thinking he is buying value when he's really getting in debt.