[convolvatron]

I find the opposite to be true about junior/senior. junior programmers accepts all kinds of awful things because they assume there is a good reason. senior programmers are pretty deeply aware that the whole jenga pile is suspect.

[dietrichepp]

I see junior programmers come in and have one of two reactions to the code base, or both reactions at the same time:

- “This code is awful, it’s full of all sorts of hacks, spaghetti code, bad practices, etc.”

- “This code must be fine, because the people working on it are smart, and if I think there’s something wrong, it must be because I don’t know the reasons for it.”

The problem is that junior programmers don’t have a good intuitive sense to figure out which of those reactions is the correct one. Sometimes you get junior programmers who are rightly horrified about the state your code is in, and want to fix it. Sometimes you get junior programmers who think the code is awful just because it doesn’t look like the good code they saw when they were in school, or because they don’t know what good production code looks like (which is often in flux).

The responsibility of the senior developer is to protect the junior developer’s opinions about the code like they’re a flickering candle that could get blown out at any moment. The junior developer will either hold onto those opinions and try changing the code, or will decide that they’re wrong—and the key skill you want to cultivate is the ability to make the correct decision.

It’s easy for a senior developer to simply tell the junior developers what the correct answer is, which is in this metaphor, means taking the candle away.

[rxhernandez]

I was lucky to learn this a decade ago when I was an intern; except it came from the electrical engineering side of the department (a department who produced products that were seen as the gold standard for that part of the medical device industry)

Manager (who was a world class electrical engineer): "why did you reuse this?"

Friend (who was also an intern): "I assumed ${staffEngineer} knew what they were doing and it would be fine to just place it in this design"

Manager: "never assume that anyone knows what they're doing here or at any other organization."

[lanstin]

Ha that last is the truest advice ever. I trust some people to end up at good decisions, but in the flux, there are many silly things tried, thought, and proposed. Don't even trust your past self too much.

[Ygg2]

That's a great way to have infinite Not Invented Here (NIH) syndrome.

[diffxx]

I think Not Invented Here syndrome is generally foolish and quite arrogant, but Not _Implemented_ Here syndrome can be a reasonable default. You rarely truly understand something unless you've implemented it yourself. You can draw inspiration from other sources of knowledge and in the process of implementation, you may decide that the source is better than what you would come up with. You might also discover that you can improve on the source, at least in some dimension. Your implementation could be as simple as a wrapper around the api of an existing library (or a DSL for using it). But after you've written the wrappers, you may find that it isn't too bad to just implement the darn thing yourself (probably don't do this with crypto!). I find it is generally a mistake to just bring in dependencies and directly build on top of them because then you become vulnerable to bit rot and vulnerabilities (or just needless complexity the use cases of other library users that are irrelevant to you) introduced upstream no matter how conscientious the upstream authors are.

[Ygg2]

> Not invented here (NIH) is the tendency to avoid using or buying products, research, standards, or knowledge from external origins.

It doesn't have to be actually invented, you can just build everything yourself.

Point is take that mindset ("Never assume anyone else in this organization knows anything"), quickly becomes never trust anyone else, and degenerates to - we'll need to rewrite the gluons (luckily people give up after they spend all their free time).

I prefer the Chesterton's fence. If you don't know what it does you can't remove it.

> I find it is generally a mistake to just bring in dependencies

I don't agree.

It's a pick your poison situation. Use dependency and have a centralized source of mistakes or distribute mistakes, e.g. billions of xml parsers suffering the same issue.

In my experience cautious use of dependencies is preferred, but I would take a well known devil. Over a homebrewed one.

[diffxx]

Every failed project I've ever been a part of has been a direct result of poor choice of dependencies. My experience is surely not universal, but nor is it rare.

[layer8]

Only if you’re unaware that “anyone” also includes yourself.

[Ygg2]

People always think they are the one exception.

[lamontcg]

That is more cargo cult behavior than NIH

[thomascgalvin]

What really makes someone a senior engineer is having made enough bad choices to realize which bad choice they're about to make.

And it's pretty much always a bad choice. It might be a little bad - like if you're using PostgreSQL, you'll need TestContainers for your integration tests, which can slow the build - or it can be a lot bad - like if you're using Oracle, a horde of demonic spirits now know your True Name and are laying plans to extract the most value for their Dark Lord - but there's always tradeoffs.

Senior engineers are just better able to list and weigh those tradeoffs, and maybe hedge against some of the badness through careful architecture.

[b3morales]

Agree, and the inverse problem is also prevalent, as we all know: someone without experience looks at a system, declares it to be shit while ignoring all the edge cases and design constraints that went into it, and insists they can do better by starting from scratch.

[richbell]

At a company I worked at, one of the VPs secured his son a "Senior Developer" role fresh out of a boot camp. His son was assigned to a high-visibility project that had been in development for several months and immediately started trashing it for using SQL instead of NoSQL, amongst many other reasons. He drew up some fancy diagrams and managed to convince people that the only way for the project to 'scale' was to do a rewrite from scratch with a new shiny tech stack. Several months later and they were still struggling to deliver a "Hello World".

[Ygg2]

Those who don't understand system's history/structure/constraints are doomed to re-implement it... Badly.

See: C++/Java OOP implementation.

[deterministic]

My experience as well. Junior programmers tends to just copy whatever is “hot” at the moment. Without having the experience needed to truly evaluate their choices.

And when the ship sinks under their feet they somethings don’t accept or realise that the ship is sinking because of choices they made. However the smart ones will learn and make better choices in the future.

[worik]

> junior programmers accepts all kinds of awful things...senior programmers are pretty deeply aware that the whole jenga pile is suspect.

Interesting.

How does that fit into the success of Node.js?

Even the author of Node.js accepts that it is dreadful. Yet it underpins so much current technology. Even in the Rust world.

[layer8]

Senior programmers are a minority, due to the software industry’s growth trajectory.

[convolvatron]

I didn't imply there was some well-built, useful and simple reality we could all just switch to. its all broken to some degree. not at all surprised that something inherently flawed could be useful.