Hacker News Reader

Comment by seanalltogether | Hacker News Reader

You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.

View on HN

It isn’t just younger developers doing this, nor even inexperienced ones. I’ve seen a ton of experienced people do this to themselves and their teams, mostly it seems to be able to pad their resume, but some honestly believe newest and shiniest is best.

Juniors with tons of experience aren't very uncommon.

The way i've seen it is Junior/Senior as a label of wisdom/engineering acumen and experience (not just a title) is not directly correlated to years of experience. Some people just have the same year of experience/level repeated 3-5 years. Some "Junior" with 1 YoE can come away with learnings some seniors never get in their careers. Not wholly their own fault, but it's a fact.

I cannot grok this. Are you saying that “juniors with tons of experience are very common?”

Do you mean that there are seniors with a lack of experience? I believe yes I was also making that same point.

Ageism in the industry also encourages seniors to appear to be plugged in with the newest shiniest thing, so we kind of do it to ourselves with our hiring practices.

We need to divorce seniority from talent.

“Juniors with tons of experience are common” means that people with many years of experience who are nonetheless at the level of a junior engineer are common.

This phrase is divorcing seniority from talent, albeit perhaps not in the way experienced engineers might prefer.

Seniority from skill, most likely, talent wouldn't change over time

As the adage goes: Some senior developers have 20 years of experience, and some have one year repeated 20 times.

If someone has only used a handheld wood sander, they will be ecstatic when someone shows them a powered belt sander.

But someone who has used a palm sander, orbital sander, belt sander, disc sander, and so on will be able to see a new type of sander in the context of existing tools and know what’s right for what job.

Your average junior will be in the first scenario. However, it’s possible to be experienced yet still be stuck in the first scenario.

> A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.

This is an organizational problem.

Right. At my new job, the framework-level choices come from people like 4 levels above me. Problematic for a lot of reasons, but juniors slapping frameworks onto things is not one of them.

I’m actually kind of struggling to imagine a scenario where a junior developer has the agency to slap entire frameworks onto existing systems. Maybe a late stage startup? Coding practices, definitely.

Enterprise.

We are currently going under modernisation converting Perl to Python. It's what it is, but I've encountered developers coming along and wanting to throw bulky frameworks at when all you require is to process the output result of a vendor issued binary.

There have been novel ideas but just unpractical for the causes.

It's madness getting through to them when all you require is a replica of the current system and not a rewritten feature set not related to the scripts at hand.

Coding practices are another tool with trade-offs involved in their use. Mental load is sometimes another word for learning. So I like to hear it from juniors because whatever is ultimately decided, it's an opportunity for them to have a real discussion around trade-offs and the benefits versus the costs of a particular approach which is invaluable for them.

Using the latest framework improves their future job prospects. Whatever company they work for will lay them off in a split second and won't provide anywhere near the comp increases that a new job would. So why should they care about the long term of a project?

Companies have no loyalty to employees which means employees have no loyalty to companies.

> So why should they care about the long term of a project?

Because your future networking potential—and therefore future job prospects—depends on being liked by your peers, who may not choose the same moment of departure as you would. Follow standards and work towards long-term maintainability not because you see yourself at the same company in 2 years but because your coworkers might see themselves there and you want them to like you and feel good about recommending you to their network.

The co-workers that matter the most for networking are the ones playing the same game. They will move to new companies more quickly and try to rise up the ranks more quickly. They will know how to write a good referral because they want to maximize their chances of referral bonuses. They will have the ear of the EMs and Directors because they know that maximizes their own career options.

Saying you're right about which referrals matter (which I don't accept, but I'll play along): you're presuming that not only are these people playing the same game but they're willing to help along someone else who they know has no interests but their own at heart.

Why?

Why would they want to help you along? They burn capital referring you, they burn even more when you make a mess of things. When you leave a burning husk behind everywhere you go your own network of people who trust you is minimal, so you're not an asset to have around them. Why would they want to help you instead of finding people to con who can actually be an asset to them? In this entirely self-centered world you've put together, what's in it for them?

> you're presuming that not only are these people playing the same game but they're willing to help along someone else who they know has no interests but their own at heart.

Referring people for no other reason than that you know them works great, since it will implicitly happen in reverse too. See e.g. the Freemasons.

> They burn capital referring you? They burn capital referring you, they burn even more when you make a mess of things.

They burn capital if hiring you seems like a failure, they win if it seems like a success. That means your incentives are aligned. No-one gets dinged for hiring someone who implemented a couple of buzzwords, left after a couple of years for a higher position elsewhere (or got promoted into management), and then the project they were on failed a few years further down the line for unrelated reasons. Quite the opposite.

Personal pride? I flat out don't respect a developer who refuses to do anything right because of nebulous hatred of any and all employers. No they don't care about you, no that isn't a good reason to go full apathetic.

It's not hatred. It's self-interest. The very heart of capitalism. A rational response to incentive structures.

You're the one sacrificing your own self-interest for pride and are upset that others refuse to do so.

edit: And I get it, I don't optimize my own career like this, focusing more on what I enjoy to work on at the moment. But I don't begrudge people who do optimize nor do I claim to be better than them. If anything they are acting in a much more rational and organized way to their goals than I am.

"More rational" is subjective. There are values and incentives, other than money and specific kinds of self-interest, that can bring satisfaction and joy.

And why should someone be respected if they are intentionally making others lives more difficult like that. That's just hypocritical.

Moving to a new framework that will look good on everyone's CV isn't making people's lives more difficult, quite the opposite.

It's not hatred but indifference towards the employer. That indifference is mutual. I'm not saying that I agree with it, but I get it.

There's a tradeoff here too. If your codebase was started in Java 6, I dearly hope you won't continue to write code in that style anymore for new code.

How about Fortran 77"

Six-foot-four-tran? (I’m sorry.)

haha damn it I didn't see that typo.

Not to gatekeep, but I question whether this is even a legacy project, or just "not greenfield."

Legacy projects are usually have shoestring budgets for any changes. After all, they are legacy for a reason: likely nobody has touched the system in a while. I can't think of a single legacy client I have that would be okay with a company wasting their hours on adding a new framework. It can be hard enough to convince them to let us add tests or upgrade from PHP 5.6

It's not limited to shiny new frameworks. Following naming conventions, design choices, etc, can take work, especially if you see something that isn't "best practice". Heck, sometimes you need to refactor something and the best thing you can do is reimplement any bugs you found (obviously with documentation and discussion to try to surface the why)

I used to work for a company where the American devs indented with 4 spaces, and the German devs indented with 2 spaces. When they finally decided to standardize the code style across the company, they couldn't agree on indentation. So, they compromised and everyone started indenting with 3 spaces. I swear I'm not making this up. I worked on one codebase that lived through that transition, and some source files would have all 3 indentation styles scattered throughout.

Probably the best argument for tabs I've seen so far.

> breaking the standards of the project lead to higher mental load to maintain that code over the long term.

Nah. Over the long term the lava layer pattern is the only way to stop the mental load of the project from growing indefinitely. You will ultimately have to keep up with modern development practices, because keeping everything on standards from 2010 will ultimately be even worse, and the longer you leave your migrations the more painful they will be.

As long as all the layers are actually being replaced. A bit of each pattern in each layer makes for a mess.

You don't and can't fully replace each layer, at least not in order - you should expect to have three or four ways of doing things in the codebase, that's just the reality of large old codebases. It still beats having your whole codebase be stuck on the oldest of those three or four ways.

> forced to adopt the coding style and practices of that legacy project

Let's keep going with this SQL-injection prone legacy framework, with zero automated tests for the entire codebase!

I've hit that, for real. Sometimes you really do need to move mountains to change legacy.

"checkout project, reformat all source files, commit"

lol I love when people do this and it and now whenever I `git blame` their name shows up.

FWIW, git now has options to ignore such commits. In a big codebase each big codemod sha should be added to the blame ignore file .git-blame-ignore-revs. It's supported by GitHub out of the box

https://www.stefanjudis.com/today-i-learned/how-to-exclude-c...

Agreed, this is quite annoying, but there is a workaround. You can tell blame to ignore commits like this, through a config option blame.ignoreRevsFile or similar CLI option. Not the most convenient perhaps, but it’s something. I believe GitHub also supports this, though you may have to request it to be enabled in your repository.

Given this, I tend to prefer a single, formatting-only commit when introducing formatting standards to an existing codebase. Otherwise, it’s difficult to take advantage of QOL features like auto formatting in your editor, or other formatting tools which tend to operate on entire files. Then PRs end up being mixed with formatting changes, which adds friction to the review process.

Sure. Of course you can't commit to the main branch and your commit will never pass code review (which is a requirement for merging), let alone the automated tests in CI that apply formatting and fail if anything is not formatted as it should be.

These safeguards save so much time that there should be no excuse for not having them.

Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".

I've had innocents' IDEs do this to them. Fortunately it results in pull request rejected, not commit to master.

Just to be clear, the argument for this has nothing to do with how the code looks and has everything to do with how you can swallow a pill, once, and in exchange you get clean rebases forever. You can hide the commit from blame consideration.

I've seen changes like this drag out over a year because the product had so many permutations that thoroughly testing any change was an exercise in futility. I've also seen changes like this fail to happen just due to a lack of cultural desire to make things happen.

The first one is more forgivable - sometimes that's just the problem space. But neither of them are conducive to fulfilling working environments.

Reply on news.ycombinator.com