Hacker News Reader

Comment by marktangotango | Hacker News Reader

After working for about 8 years at 2 different companies, I started a new job. When I came on board I found the dev team to be highly dysfunctional, and repeating a lot of mistakes I'd spent the past few years working through. An example is: using Java Hibernat/JPA ORM to build intricate object hierarchies that resulted in massive amounts of data loaded at runtime, causing out of memory exceptions and constant gc pauses. On a 32 bit jvm you only get something 1.5GB of usable heap (even if the jvm/os allow you allocate more), when a user logs on and 500MB of data is loaded, well, you can only accommade 3 concurrent users.

So I went in, tried to communicate this, and talked about at my previous job we had used views and stored procedures to not load the entire object graph when only a subset was needed. Crickets. No one cared.

It was very disheartening. Really made me doubt myself, and my ability to communicate.

View on HN

You were "the new one" here and wanted to tell people they did something that sucked terribly. Most people don't want to hear that and act accordingly. Not easy at all.

Still, this is the strategy with the best chances. The existing team may be too invested in the current concepts, and as a new member, if you don't speak up early, your possibilities to change something vanish with every day you say nothing.

Can you explain why the new person's influence fades so quickly? The new team member who says "I know how to fix all of your problems" on day one looks like an arrogant jerk.

The team member who starts to fit in and then says to the right people "It looks like our system has a memory management problem. I've got a lot of experience with this type of issue. Can I help out with designing a solution?" is far more likely to get into a constructive dialog and may move things forward.

If the OP wasn't brought in with the goal of saving a project that was in dire straits, then trying to fix what you think are the biggest problems immediately isn't going to go over well.

I think you are pretty much right. As technical as our industry is, we are all humans; emotions, anxiety etc, comes into play when dealing with another person. Approaching it in the right manner will reduce the barrier.

You can't step on people's toes, and organizational cruft doesn't go away overnight. If changing their culture is an ambition you take seriously, it's going to take you a few years, and you'll be a manager at the end of those years. Because changing culture is a job for a manager, not a team mate.

I can't tell if you're blaming the technology stack or just how they were using it. I've been writing large-scale webapps using Hibernate (then Hibernate 2, then JPA) for over 12 years and there are right ways and wrong ways to do it.

Now imagine that you have 20 years of industry experience.

Reply on news.ycombinator.com