
Ask HN: Started a job recently, great compensation but dreading work. Tips? - throwawayfinito
The code is just atrocious.<p>It&#x27;s obviously been written by people who are architecture astronauts and it hurts daily to work on simple features that would take me 20 minutes in any other setting.<p>I&#x27;m dreading work, and this has never happened to me before. I&#x27;m usually excited about work and knocking things out.<p>The pointman I&#x27;m speaking with as I get onboarded with the systems has a very thick accent and a very poor microphone, it&#x27;s very hard for me to understand, nevermind the mic physically hurting my ears haha<p>The founder is also pushing for hard deadlines however development is slow because this clusterfuck of a database and architecture is just bonkers lmao<p>The pay is excellent and in a very interesting niche, but man I am just dreading getting up to work here. I don&#x27;t know what to do.<p>Should I quit? It&#x27;s only been 4 months.<p>How can I mitigate these feelings and improve the situation?
======
tbirrell
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).

~~~
matt_the_bass
I really like your sandbox idea.

Also OP should discuss concerns with their supervisor.

------
nameless912
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.

------
codingdave
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.

~~~
adetrest
> 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).

------
zer00eyz
> 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.

------
potta_coffee
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.

~~~
lowercased
> 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.

------
a-saleh
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.

------
DrNuke
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.

------
logicallee
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.

------
nunez
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!

~~~
mattmanser
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...](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-
astronauts-scare-you/)

~~~
cottonseed
nunez is one of today's luck 10,000!
[https://xkcd.com/1053/](https://xkcd.com/1053/)

------
hector_ka
Do you think it is going to become better?

~~~
Rjevski
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.

------
mbrodersen
Quit. Seriously. Life is too short.

------
ibash
You should quit.

