Comment by mywittyname | Hacker News Reader

Comment by mywittyname | Hacker News Reader

Parent Full thread

I left a job which paid in the 95+ percentile of my area for one that paid right about the median wage (maybe a little less). My reason: I like to own the software I write. We had an influx of people on our team who began to rewrite sections of stuff I wrote a long time ago for no real reason. Basically, some of them didn't like promise chains and decided to rewrite every one they encountered. Things finally bubbled over when I ended up in merge hell where I'd have the codebase drastically change while I was on my branch and I'd be reimplimenting the same feature every time I tried to submit a merge request, but all of these changes amounted to largely meaningless "refactoring."

It's kind of petty on my part, but I'm not the type that wins arguments. So I decided, despite loving the people I worked with, that I was not in the right job. Now I design and develop software mostly individually and I'm infinitely happier. Someone who is competitive and enjoys confrontation would thrive in that role though.

Point is, people have lots of different reasons for changing jobs. And something that makes one group happy may make another miserable. I also hate traveling to conferences, but that's the nature of the job sometimes.

I mainly write embedded software rather than web stuff. I will say that the hardest to read and maintain embedded code I've ever had to work with was structured to use asynchronous chains of callback functions. It can get bad enough that you just can't fix a bug without dousing it with gasoline and lighting it up. Not to say that such patterns can't be used effectively, but maybe your former co-workers had some previous emotional trauma!

Promise chains are usually totally fine and readable, it's when callbacks are passed around without promises or bad abstractions occur that async code is problematic.

More often than not I would not touch code written with promises because it doesn't matter anyways since code using it can still use async/await + sometimes it makes some patterns easier to deal with (f.e. using a dependency written with callbacks and calling resolve from within the callback function)

I would've changed your code from promise chains to await statements (after warning you, of course) because they just look awful. And I would then have expected you to buy me a beer for getting rid of all that ugly code.

So you would've spent company time rewriting working code to match your personal aesthetics?

Sounds like parent didn't have a reasonable structure in place to generate consensus amongst the org about stylistic preferences vs tech debt, and where developer priorities should lie.

There's some ego in both of your comments as well. Async is nicer looking that promise chains, but there risk in changing working code, no? Growing with an org means letting go of your old code but joining an org requires empathy and understanding for the old timers and their code babies as well!

I assume you are looking at things for a living. And from your corporate tone, so are your coworkers.

We all want to look at good things. Promise chains were bad things. When I see bad things, I am willing to make the change. So should you. And we should ask before we change. GP was caught off-guard. That is not what we want.

We good?

We good

> corporate tone

oof, maybe not wrong though.

I don't look at things for a living, I trade time for money with the expectation that my time has a multiplier on revenue, profit, and team health/productivity. I guess I've seen enough legacy code at this point that I don't have any desire to change it just because there's something better, changing stuff that works has to be a reasonable balance between tech debt/maintenance/quality of life things, vs features/uptime/performance. Of all those things, features make the most money right? So why would I want to spend time refactoring things when I could make measurable, incremental improvements somewhere else? Spend all day in the same system? Sure. Drive by refactorings? Absolutely not.

Refactoring a large JS codebase is like painting the proverbial Forth Bridge. By the time you've finished, fashions have changed and it's time to rewrite it all again.

You don't sound fun to work with.

It is exactly what I did with bluebird before async was even part of the language back in 2013, and when async finally arrived all we did was a simple regex replace. So yeah, I am pretty consistent at what I do and everyone who disagrees is just cringe.

Async/await isn't exactly a fad that is going away anytime soon. If refusing to refactor outdated pieces of code is your idea of "fun" then I feel sorry for your coworkers.

What does 'outdated' actually mean here? It's a sign of lazy or fashion-driven thinking. If there's a good reason for refactoring a pice of code, it should be possible to articulate that reason without reference to the date it was written.

I mean, fair enough, everyone has their personal opinions on style. But these battles can end up with the losing side leaving the company. This was a net loss on both sides: I lost income & a job I otherwise enjoyed while the team lost the key AWS expert that took months to originally fill.

Ironically, a team is probably more likely to lose competent people in such a scenario because they are the ones with many opportunities. A former manager of mine was more than happy to fast track my hiring to my current role.

And your boss at 121 time askes so exactly what have you delivered.

Git activity is the most praised metric at my company. Refactoring and commenting is highly rewarded. The utility of this metric is dubious.

If that is the game they want to play, you could refactor comments to get the highest value/effort ratio.

My Sympathies id start looking for a new Job

Ah like the place I worked at where some one spent 10 person years of effort to replace a perl system with the corporate standard Oracle one.

No value to the share holders but they ticked the boxes for probation managed a teem of eight or more and a budget of "1 million pounds"

Sorry I meant promotion here.

I had some time to think about this comment, and I really like it. It demonstrates the issue underlying issue I was getting at with my original comment, but didn't express because it would not have come across as believable. I've encountered a lot in my career and has been the impetus for my last three job changes.

Hearing this tells me three things: you don't respect my work, you're publicly demonstrating that you're better than me, and that you're entitled to something from me for putting me in my place. Microaggressions like these are difficult to work with, no matter how much you're paid.

I'm sure you're a great developer, you've probably been promoted a lot, lead a big team and are generally well liked (at least on the surface). However, there are lots of developers and engineers that have been put down their entire lives and never really developed the social skills to stand up for themselves. Somehow, even over the internet, people like you can hone in on this and leverage it.

Why didn't code review catch this? If the review worked the way it's supposed to then you'd be one of the reviewers as you were the original author.

Our setup was you needed one person to approve a merge request. These guys were buddies and would fast-track approvals. Also at that point, there were ~10 contributors to the code base, so things moved quickly.

Other product within the company had a more formal code ownership structure, but this project was only two years old. So there were no owners, other than for infrastructure.

No tech-debt JIRA ticket - no big refacroring. JIRA tickets gets assigned during planning and are usually talked through in the team and agree upon. Problem solved.

Reply on news.ycombinator.com