Comment by busterarm | Hacker News Reader

Comment by busterarm | Hacker News Reader

Parent Full thread

I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

No thanks.

Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical records and the app that I came into had tons of dead code paths that leaked HIPAA-regulated data all over the place.

None of the API routes were 100% functional, so I spent my first few weeks cleaning that up and making it bulletproof. Then I fixed their broken homebrewed SAML IdP. None of that work that I did was appreciated as they only wanted (but wouldn't say that they wanted) new frontend features to show off to the client to inflate the quality of their work.

More importantly, they were using Rails4, but implemented everything by watching a Rails2-era Railscast and would get frustrated with me for not doing the same, a.k.a "the rails way" (I was, just modern Rails and not their broken bullshit). And that was the CTO...

> They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

Very well said and it happens in lots of areas where companies seem to wish for "big outcomes but all for free".

You will see this in security all the time.

"We have to make sure this thing is bullet proof."

"Ok it's going to take a month to harden and audit our the network and infrastructure and add monitoring and we'll be in good shape."

"Uhh ... no we didn't quite mean it like that ... can't you like install a plugin in half an hour that does the same thing?"

(made up conversation but you get the point)

I'm in the midst of maintaining/fixing one of those and I find it a great opportunity if you A) want to learn outside your comfort zone, B) enjoy figuring out problems that aren't just technical (talking to people, design, organization), C) want to get out of a coding-grind lifestyle.

Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improvements for both revenue and end-user experience.

If you're senior dev level and want more of a challenge that's not just throwing more code at the wall, these sorts of scenarios are something to seek out.

Sometimes. I'm actually fully on board with what you said, but the situations I found and was describing are usually environments where they just expect someone to put their head down and code.

When I say "not willing to make organizational commitments..." I specifically mean they don't give you access to people -- stakeholders don't want to be bothered by the devs. It's far too common.

What you're describing though is a great situation -- I love those engagements.

That sounds really fun. I've done greenfield Rails projects and I've learned that what I really like and find rewarding is this kind of slow reorganization of something that already exists. It's like remodeling a house--maybe it was well built initially (and maybe not!), but you get to spend a lot of time inside of someone else's mind. You know, when they had good days and things just clicked, when shit was on fire and they just had to make it work. The results of seeing meaningful improvements to something like that is just fantastic, to the point where you're now excited to add on to the codebase.

> They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

Well yeah, churn and burn is my company's motto. At least we pay well.

Reply on news.ycombinator.com