Hacker News Reader

Comment by smokel | Hacker News Reader

I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time.

Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the part of the process where most effort was saved.

Note that all this was used for a system that would be deployed only at one customer, and the feature would always be on. Yes, a boolean flag would have been a better solution for this.

My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated.

View on HN

Just raise it up early, often, and simply.

"Isn't this just a Boolean flag? If X else y?"

I've saved a great many man months by doing just this. Sometimes work just vanishes. And it's not just the juniors that do it, sometimes the senior / tech lead types just miss a crucial point to make the solution trivial.

But juniors are often used to wanting to make work, rather than solve a problem.

Just yesterday I was helping with an incident and we had outlined two possible solutions. The first was bad (do nothing, leave things in a somewhat bad state), the second was a ton of work (including restoring from snapshot). I was able to describe these solutions as a spectrum.

1. Do nothing, bad state remains 2. Surgically restore to world before bad state 3. Remove all bad state (even if it wasn't caused by the incident)

I'm omitting some details, but I think this strategy can be effective.

How configurable should X be? We have one customer who wants it to be configured like this. All other customers want it configured like that.

We can make X maximally configurable which would allow future customers to have a custom setup - how likely is that?

If it's not likely, here's an alternative...

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated.

I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

Seems cynical. In my experience, junior devs are just more susceptible to cargo-culting and getting excited about cool ways to apply the things they learned in undergrad. I haven't actually seen a lot of "resume-driven development" in my (relatively limited) time in the industry... just well-intentioned eager people with more knowledge than wisdom.

> just well-intentioned eager people with more knowledge than wisdom.

Yup. And that by definition is a junior colleague ;)

I like to describe my colleagues as the delta between how smart they are, and how smart they _think_ they are. “Junior” devs almost always fall in the “wide gap” spectrum but it is by no means restricted to any age group.

Dunning Kruger as a spectrum within the context of engineering?

That's genius. I'm going to borrow (read: steal) that.

Strongly disagree this is a junior dev thing. Most of the terribly complex abstractions are, in my experience creates by people who have enough seniority that others can't easily question them. There are good devs and bad devs, and there are junior and senior devs, but it's the first axis that determines code quality.

I’ve seen entire orgs paralysed by a single architecture astronaut who has been there since the beginning who nobody has found a way to route around. Simplicity as a cultural value is underrated, and fetishising complexity can kill a business.

Hmmm… well it certainly was for me. My code has gotten a lot simpler over time!

Well no doubt! Same. You can certainly get better at programming as you get more experience. I'm just saying: the axis that determines this stuff is skill, not seniority. They correlate but they're not the same thing.

junior devs are junior devs in part because they do not yet know that there is no guarantee that anyone else has been keeping track of their victories come review time.

solutions are only invisible due to a lack of sufficient documentation and communication.

boring solutions are part of the job. they can be fun if the goal is shifted from implementing to automating.

none of this to say you are wrong, but a junior dev that succeeds at such peacocking efforts is signaling the poor health of their surrounding team as much as their eagerness to impress. where was the manager or senior dev to say “great! have you considered a boolean?”

Nobody cares about invisible good solutions, because invisible solutions are simple - and developers are to one degree or another, rated on the degree of complexity they can deal with and how smart they can be. It is common here to understand the cleverness behind just doing the dumb thing, but it is not common in many places.

If you’re one of these people who are oozing with sarcasm then just be yourself. It’s a fun way to convey when something actually is ridiculous. Nothing wrong with that.

Just also make sure from time to time that you’re on the same side. Don’t hesitate to laugh at your own mistakes openly. Sprinkle in some sympathetic, honest remarks. Target the thing, the mistakes, never the person.

Bottom line: laugh together at the expense of human fallibility and not a particular person.

Are there no seniors on the team? Why aren't anyone helping and guiding your team to make a better product? Seniority isn't about technical skill, it's about being a multiplier and paving the road for others. If you're not, and you're letting the team in your eyes waste time, the whole team acts just as junior.

Touché! Both luckily and unfortunately, this incident was not on my team.

Even then, I find it increasingly hard to argue people out of the nonsense they pick up on blogs and conferences.

Especially for newer techniques that are not yet proven to be inefficient, such as using micro services in the wrong context, one has to resort to arguments by authority. Some junior and senior devs are not very susceptible to that.

For areas such as web development for user interfaces, or taking in enormous dependency trees with package managers, the problem is even worse. Here, an entire industry had standardised on suboptimal methods. One can argue that this is wrong, but there is no viable alternative.

In the latter case, guiding only one junior developer does not improve things. One has to educate the entire industry.

> the nonsense they pick up on blogs and conferences

Thanks for this bit. As I gain more experience, I grow less and less patient with many blogs and conference talks. Often authors are just very excited about a topic, and my general impression is that they tend to propose ideas that are not seriously battle-tested in production.

In game dev there was a saying like “you’re writing the game in C# so just write the game logic in C#” rather than making a run-time configurable / scriptable monolith

Reply on news.ycombinator.com