Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How you ever quit because the engineering culture is too messed up?

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 24 posts

Ask HN: How you ever quit because the engineering culture is too messed up?

#1

Post by throwaway98988 »

I work with nice people but my technical ideas are constantly shot down because either 1) "that's not how we do things there", 2) "there are more important things to worry about", or 3) "I'm not sure I like it".

I realize different organizations need different people/experiences but I see some obvious errors in management infrastructure and I'm trying to be not-pushy as much as possible while fully realizing there are good reasons for everything.

To my eyes, the things I'm proposing are simple and work almost everywhere else but they are still controversial, it seems.

How much should you be swimming against the current before calling it quits because we can't change anything? It's a general question, thus why I haven't given concrete examples for my situation.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#2

Post by thestepafter »

Yes, I have done this. Mostly because my work depended on certain technical architecture being setup but there was an unwillingness by management to do so. This was primarily because other people at the company refused to admit they didn’t have the expertise to set it up and instead did their best to cause my project to drag for months. I eventually left and completed a project that dragged for over 2 years in less than 3 months for another company.

It was overall a very frustrating and stressful part of my life that I would have done everything in my power to not be involved in if I could have predicted the future.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#3

Post by tacostakohashi »

This can be frustrating for sure. Your question / post is a little light on details, so I am reading between the lines a bit here, but to some extent you'll find this everywhere, and dealing with it can be a useful skill.

Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here?

I would suggest trying to find ways to be productive yourself that don't involve changing what other people do.

Don't try to sell "ideas" and "proposals", lead by example, and if it works out people will follow.

For example, if people want to use subversion and do their development on trunk, but you want to use git with feature branches... then just do that for your local development, create and switch branches locally all you want, and then push to subversion when you're done.

If there's some dumb JIRA workflow, copy and paste the details to a text file, work on the thing, take your notes in the text file, paste it back to JIRA when you're done. You will probably find you can isolate yourself from most kinds of silliness quite well, and if you're productive doing so then others will follow.

As for your specific question, I think it's worth trying to improve things for at least a year, or maybe two, before you consider leaving. In that time, you'll probably find there are things you can change, learn that other things are actually not as easy to change as you might think, and generally build some useful experience in turning around a challenging situation.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#4

Post by throwaway98988 »

tacostakohashi wrote: post #3

This can be frustrating for sure. Your question / post is a little light on details, so I am reading between the lines a bit here, but to some extent you'll find this everywhere, and dealing with it can be a useful skill. Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here? I would suggest trying to find ways to b…

There's a certain disdain for metrics so we're not tracking a lot of things proactively (think latency/rate, for example). That means every new change is based on a feeling of how it'll impact the systems. We also don't have a dev/test environment so changes to production are what I'd call, "faith based". There's a lot of apply to production, revert cycles. Or worse: no changes at all for fear of breaking things.

But there are more mundane things like not using a code linter because $linter enforces some rule that someone doesn't like, so discussions stall. There are literally hundreds of JIRA tickets about some proposed idea that fails to reach consensus.

I think isolating myself from the craziness is a good idea but I'm having trouble with how it would be received. Say I push a code change that fixes a bunch of things that $linter complained about, including stylistic changes. Now that has to be reviewed by someone and...? Should I just keep pushing the envelope like that? Someone will probably contribute some piece of code full of violations and then... I fix it and cause an incident with teammates?

One possible outcome is to just accept things and let go. I see this a lot in people that have been here for many years. They are also not people I would aspire to be so... I kind of have to accept defeat but that's demoralizing. I'm coming to a point where I'm asking myself where I could be and I don't have a good answer. Should I stick around and keep trying to change things? Back to the swimming against the current question.

Thanks for all the feedback.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#5

Post by throwaway98988 »

thestepafter wrote: post #2

Yes, I have done this. Mostly because my work depended on certain technical architecture being setup but there was an unwillingness by management to do so. This was primarily because other people at the company refused to admit they didn’t have the expertise to set it up and instead did their best to cause my project to drag for months. I eventually left and completed a project that dragged for over 2 years in less t…

That's exactly one of the problems that I have. Somehow people are okay with things taking 2 years rather than 3 months though so there isn't a lot of pressure to change.

I'm at a point where I don't know if sticking around can have a positive influence on my career, maybe I'll learn to be more zen? How will that help if I change jobs? Or, will I become used to bad engineering and sabotage myself in the future? These are the kind of questions I'm having.

Assuming I have a good set of skills and enough experience, when faced with a challenging situation like this, I should try to be a positive force and bring improvements. However, I'm failing at that constantly and I just think it could have a negative impact on myself (burnout is a fact at this point).

Really trying to find the silver lining in all of this.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#7

Post by tacostakohashi »

throwaway98988 wrote: post #4
tacostakohashi wrote: post #3

This can be frustrating for sure. Your question / post is a little light on details, so I am reading between the lines a bit here, but to some extent you'll find this everywhere, and dealing with it can be a useful skill. Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here? I would suggest trying to find ways to b…

There's a certain disdain for metrics so we're not tracking a lot of things proactively (think latency/rate, for example). That means every new change is based on a feeling of how it'll impact the systems. We also don't have a dev/test environment so changes to production are what I'd call, "faith based". There's a lot of apply to production, revert cycles. Or worse: no changes at all for fear of breaking things. But…

If you think it's valuable to track latency, that seems like something you could just do. Grab the logfiles process them in your home directory, produce some graphs, keep the data over time and track changes. Ideally it would be done centrally, but as a starting point just do it yourself.

Not having a dev / test / qa environment is inexcusable, why do you not have that? Why can't you just set one up yourself? Possibly on your own workstation or some VMs, just find a way to do it.

Linter warnings are of highly variable quality. Don't bother about anything stylistic - tabs vs spaces, camel case vs underscores - those things never caused anyone's software to not work. Ask yourself "could this break something in production?".

If the answer is yes, then create a code change to fix one instance of the problem and submit it for review (not every instance of every problem, just one instance of one specific problem that could affect production). People will ask why it's a problem, you can explain it, and if you've selected a good example of a non-trivial problem, they'll accept it and merge it. Then, go and find the other instances of the same problem after you have set the precedent, and there will be less resistance. Then, start working on other problems, rinse and repeat.

Doing this will educate people along the way, and will work better than some big shock-and-awe change that touches a lot of things at once. Go easy on criticizing other people's work during code review, they're often emotionally attached to their code at that point since it's the last step in something they've been working on for weeks and want to move on from. Again, only raise things in other peoples code that could break things in production.

As for accepting things and letting go, I'd say it's more a question of picking your battles. Don't accept everything and let go. Try to improve things to the extent you can while you are there, even if that isn't forever.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#8

Post by bediger4000 »

I quit one job in 1995 when they decided to abandon SunOS/Solaris work in favor of Windows NT. Someone at Microsoft had sold this company on the idea that if their developers used Windows NT (3.5? 3.11? can't remember) they'd be 5 times more productive. This was obviously untrue, and I didn't want to get caught between the hammer of management and the anvil of Windows NT.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#9

Post by kenha »

tacostakohashi wrote: post #3

This can be frustrating for sure. Your question / post is a little light on details, so I am reading between the lines a bit here, but to some extent you'll find this everywhere, and dealing with it can be a useful skill. Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here? I would suggest trying to find ways to b…

+1 to the approach of leading by example. I sometimes phrase it as, "Focus on what you can change, rather than what you cannot."

It is difficult to be in that environment that doesn't have a good engineering culture. It, however, should not stop you from doing what you believe is right.

If you are relatively new to the company, in order to bring influence, it might be worth it to build trust before "rocking the boat." Trust could be built through leading by example, or sometimes just take the time and understand why the process exists in the first place. Once people trust you, it may be easier to sell/propose new ideas to the team.

As an anecdote, I've worked in a startup in the past that allows engineers to push and deploy code to production without any form of code review or a single line of tests written. (Even senior engineers/tech leads do not always have tests to go with their commits.) This created a code base that contains quite a bit of spaghetti code, occasional build breakage, as well as a lack of knowledge sharing on different components (Even if you are on the same team working in a similar area of the code base.)

Rather than changing the process to mandate PR, I started creating a Pull Request (PR) for every single change that I made, made sure I have sufficient test coverage and added my teammates to it. If my teammate happened to leave a comment/feedback, I'll thank them on Slack, and let them know the feedback is useful.

Since then, while there are still changes that went out without any reviews, I've seen more reviews coming my way (2-3 in 3 months versus 3-5 in a week), and I always do my best to leave feedback/comment on the PRs asap. It wasn't perfect, but hopefully, these baby steps laid the foundation to lead to an eventual change.

John Wooden (Ex-UCLA coach) has a well-known quote, "Make each day your masterpiece." Rather than focusing on what I cannot change (Other people + process), I did what I can to make it better (My "masterpiece" given the circumstances), and I hope what I did may have changed how my teammates looked at PR.

Re: Ask HN: How you ever quit because the engineering culture is too messed up?

#10

Post by muzani »

Life's too short to work for bad companies. Cultures rarely change though, so if you can't change some of their habits it never will. And generally bad cultures will scare away top talent.

But generally, first thing is to check whether your ideas would actually help.

Some ideas sound great and are supported by great people, but they kill flow, e.g. scheduling, stand ups, TDD, and other project management practices.

Some ideas have a lot of overhead, and every project has a balance between how much should be hacked, vs time saved in the long term.

And sometimes it's just that it's challenging someone's authority. Or because they feel they are already the best and doing things the best way. If this is the case, then you could consider leaving.

Post reply on HN