Ask HN: Started a job recently, great compensation but dreading work. Tips?

Figure out what you want out of this job.

- If there something you want to learn, focus on achieving that.

- If you are there for the money, invest in something outside of work you enjoy.

- If you think you can find a new job easily and this one doesn't matter in the grand scheme of things, then use it as a sandbox to test different things without risk (i.e. what'll happen if you push back on unreasonable deadlines? Is there a better way to handle it? Rinse, repeat).

I really like your sandbox idea.

Also OP should discuss concerns with their supervisor.

You can either leave or find a way to make your job fun. I've repeated "Be the change you want to see in the world" about a thousand times since I've started mentoring people, and it's really the only thing you as an engineer can do. Their architecture is a clusterfuck? Come up with ways to improve it and present to some slice of the company that will listen (e.g. director of engineering, C-levels if the company is small enough).

Ultimately, you can make almost any job tolerable just by putting in the legwork. If you're not comfortable doing that or you feel like there's nothing you can do, then it's time to leave. That's how I decided to leave my last job, I realized I couldn't make any more change for the better and so it was time to leave and do something else.

I will say atrocious code is one of the more fixable problems you can find yourself facing. It starts by being a great example and enforcing good practices on anything you get ownership of, but ultimately it will eventually involve a discussion with whoever's in charge to start setting larger organizational policy.

You said it's an interesting niche, and that's an important consideration, but remember that very few companies are "unique"; someone else is probably doing this, and jumping ship is an acceptable thing to do in any job. You are far more valuable to the company than they are to you.

You really have three paths:

1) Accept the fact that it is crappy and enjoy your paycheck. Just go to work, accept that your time there is a business transaction in exchange for the paycheck, then go home.

2) Invoke change - speak up, not just about the problems, but with solutions to improve the organization. Encourage discussion, retrospectives, and push on your leadership to make actions happen. If you are having trouble understanding people, tell them. Ask them to get a better mic. If the code is hard to work through, document it as you figure things out - you'll start to understand it, and if it really is convoluted for no reason, documentation and diagrams of it often will make people realize such things, in a way that just looking at code does not.

3) Leave. There is no shame in leaving a job that is not right for you. You aren't helping your employer or yourself by just being miserable every day. FWIW, I've never left an unhealthy job and then later wished I had stayed longer.

> Invoke change - speak up, not just about the problems, but with solutions to improve the organization.

This doesn't work in my experience. You're the new guy and no-one wants to give up whatever political power they've accumulated through things being such a clusterfuck. By doing this, you will step on someone's toes even if you have the best of intentions and didn't mean to; this will upset people who have more power than you do, and will do you in.

1) and 3) are valid options, but I wouldn't advise 2).

> The founder is also pushing for hard deadlines however development is slow because this clusterfuck of a database and architecture is just bonkers lmao

I have run across many a CTO, CEO and founder who had a timeline that would have been reasonable in another place, with better architecture or even a slight twist on what they suggest.

I would take this as an opportunity to learn to speak the language of management. If you can say that with better code things would be "faster" then you have a case to be made, and you should make it. Ask your founder out to coffee, most managers and executives are approachable. Keep in mind that your pitch should be soft. Dont say "our system sucks" say that your timelines would have been more easily achieved in past systems.

The best one off insight I can give you to management thinking is to suggest you read the orange juice test and make sure what ever your going to say is couched in that.

As for your coworker with the accent and the mic, say something! "I don't think I would be having so much trouble with your accent if the audio quality was better, do you have a different mic to try...". You would be surprised how many folks have these sorts of issues and DONT know it because no one says something.

Four months is a very short time, but can feel very long. You need at least six months to really understand a complex codebase. I'm in a similar situation as you, our code is terrible and ugly but after digging deep I've started to see some of the reasons why the code is the way it is. My approach has been to pick the most difficult problems that nobody else can fix, and fix them. It's painful but the payoff is pretty good.

> You need at least six months to really understand a complex codebase.

This might depend on the definition of 'complex', but I don't agree in all cases.

I'm in a project right now with one other team member - we hit the ground running with 'new' (to us) code. It's been just over 10 weeks, and we have a pretty deep understanding of what's there. Honestly, it's not terribly huge, but there were 6(?) other developers before us over the course of 4 years, and each one left things progressively worse.

In 2 months we have a better understanding of how the code fits together than everyone else who came before - which you can mostly tell via the commit log (and scant comments).

Now... I may be out of line saying they didn't "understand" things - they may have understood and just been too lazy to bother to not break things.

But 6 months is a long time. What you can learn in 1-2 months is just how bad things are, and what the most effective triage techniques can be.

What's helped in this case is that... I've come in as a contractor, and there is no one else to answer to (except the client). There is no one refusing commits because of code style conflicts. No one arguing about db schema changes, or asking for my time in meetings that have nothing to do with this project. So, in that respect, the 10 weeks has been fairly productive.

It's come down to experience, autonomy, lack of politics, and a focus on getting some architecture and tooling in place to allow for repeatable builds, tests and sample data. Not been smooth sailing by any means, and we're still uncovering bugs (big bugs) that date back 16 months or more.

I've been in other situations where fixing the difficult problems would a) uncover bigger issues that b) cause other folks to nix the whole effort, because it rocked too many boats, and my work was rolled back. Disheartening, and if you can't get buy-in, or at least free reign to fix something, it's time to move on.

I was in simmilar situation, even though not as frustrating. Started at a company as a test-automation engineer, but the QA team I was part of was dissolved soon after, and we were redistributed do various development teams.

So I changed to be backend-developer but after three months in that role, I didn't feel like I am really contributing. One of the things was, that didn't really feel that I had that much impact on things we were doing in the team, and I learned that the only part of the application I finally started to comprehend a bit will be handed over to a separate team. Secondly, I was only remotee out of 8 people, rest of them in a single office.

So I changed to the team on the other side of the hand-over. It is mostly remote (3/5 people in different offices), and I do participate much more.

Write one page with the absolute priorities to make your time at work better (both for you and the startup) and speak with the highest person in charge with recruitment, face to face behind closed doors. If the chat is constructive, you both will agree a plan and a timescale to make you happy and productive for the common goals.

No. You should say "Fuck it. I'm the leader of this circus." Get the point man's address and without asking, overnight him a microphone. Take charge in refactoring the code base to be whatever you want. Go out in a blaze of glory, getting fired for acting like you now own the place. Don't hold back at all, until they fire you. Literally don't hold back the tiniest bit. If you flinch for a moment, or accomodate them in any way, that's what you'll get fired for. Take no prisoners, OP. Scorched earth.

Architecture astronaut, lol. I'm stealing that one.

I'd figure out why the architecture was (over) designed that way first. You might like the answers you get!

It's a term of art in our industry and has been around for a while e.g.

https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

nunez is one of today's luck 10,000! https://xkcd.com/1053/

Do you think it is going to become better?

Or, ask yourself can you make it better so it's more enjoyable going forward?

I've had this experience a few times; horrible code base & practices, but I've managed to make it better (and tell my colleagues how to do better going forward) and it's been great ever since.

Quit. Seriously. Life is too short.

You should quit.