Hacker News Reader

Comment by daenz | Hacker News Reader

Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing <highly problematic, confusing code> because it's so terse. It's been a point of friction, actually, because I have been trying to get other engineers to help on the software they have been contributing to, but it is nearly indecipherable without the original author's help.

Very frustrating.

View on HN

> Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic

I think it happens because most measures of code quality are quite fuzzy, but brevity (which is valuable, other things being equal) is relatively objective. "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"

I think another place people can end up here is if they don't know what the compiler is doing under the hood, it's easy to assume the shortest code will perform the fastest or something like that. "Presumably this cool trick avoids these extra steps" type of things.

Before I had written much assembly, I used to think ifs to avoid assignments was smart. Turns out avoiding branching is better for both testability and performance.

A similar thing I've noticed a trend of recently in frontend react codebases is overuse of memoization. It seems as though people don't realize how it works and that it is often _less_ performant than just doing some low cost computation on each render (like a comparison or basic math).

> "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"

This is something that comes with experience though, and I think a lot of people don't truly grok this until they are trying to maintain their own terse/clever code written months/years earlier. Nothing is quite as humbling as doing `git blame` on some crappy code only to see your own name there.

Yeah, it's certainly a phase I went through.

Amen to that too. That's probably the most complicated part of being a manager or tech lead. You have those amazing junior-almost-senior engineers that could be way more productive and yet deliver better code, purely by "doing less", but the over-engineering gets in the way. You know they could be top-contributors, so you don't want them to leave. But at the same time it's very tiring!

I noticed that they put a lot of their self-worth in the sophistication of their code, so it's difficult to criticise without making them feel bad. You need alternative methods of getting them to "see the light" and write code that's more understandable and maintainable by others.

What alternative methods have you found to get them to "see the light"? I've found myself wishing they'd do therapy, but that doesn't help and can't be expressed.

Mostly public feedback (for only the good things, of course). Put their "good" code on code samples, documentation, code guidelines, tell the team "look everyone please do it like person X did here". It will surprise them in a positive way.

Also on PRs try to point to their own work as sample of how to do things better. This doesn't hurt the ego much, because the role model is themselves.

Also, I feel like most of the time this is an impostor-syndrome/perfectionism issue that also happens with other workers too, so HR can give tips on how to deal with those issues in a more sensible way and tell you what you can or can't say.

i was debugging some very terse, elegant, and dense code. i added a bunch of logging throughout to understand what was going wrong.

someone then removed all of my logging because it was ugly.

and then had to put it all back in when another bug was coming from the same terse beautiful code.

That hurt me to read! Have you communicated this to your manager? Might be worthwhile to have a decision "from the top" that is essentially: all logging is good, so long as it doesn't hurt performance or contain PII/PHI.

Logging is like a lamp in the dark, you need it.

three things i find to be true of every web app i work on:

1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second.

2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project and plan accordingly. never trust any suggestion that you can 'ignore performance for now'.

3. the UI may be more important than logging

Logging at the boundaries or seems is especially helpful.

Can you elaborate on what you mean by a boundary? You mean logging the interface between two services or modules?

Boundaries between anything. I recently was dealing with an issue in a Jenkins pipeline, where I didn't realise that state was being serialized to string form between job stages until I explicitly logged it out. The thing that was a list in the previous stage was suddenly a string, but then Groovy would happily accept the join method on a string because it's still an iterable. Auuugh.

Both these above are great answers. It's a bit of an art.

I love how poetic this sounds.

Should've put it into a branch and added an one-line comment to that effect to the master.

A better approach is usually to write test covering all edge cases.

I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly complicated code that’s making my life a living hell’.

In fact, I think a third-party auditor would be a valuable service for dev teams to utilize at least once a year. Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’. The business value here is you can root-cause velocity issues that can come from decent people who need to be reigned in (not necessarily fired).

I’m literally prepared to pay to have these people objectively assessed.

I would do this auditing job, no joke. A kind of "code-smell" service, that can yield problematic areas, along with a report of engineers that could use additional guidance/training/reigning-in would be super valuable from a manager's perspective. And because it's a neutral party, they can feel good that there's no politics.

One challenging bit about this service would definitely be quantifying improvements. Since the problem is somewhat hidden by nature, you would almost need testimonials from other engineers on the team.

Another way to remove finger-pointing is to identify features that should be reasonably easy to implement, but for whatever reason don’t get done in time, or worse, don’t get done well (end results being bad).

If a team was tasked to make a simple landing page for example, and it was oddly hard or time consuming for an average team member, it would be good to dig into why. If the answer is ‘you should see the boilerplate involved, or the deploy process ...’, then you can make a neutral analysis as to the cause.

Testimonials aren't a bad thing though. I think every dev should have their code read and evaluated by at least one other person, although getting as many people as possible to read it would be best. If code legibility to help team members understand, debug, and improve upon the code is essential, the best metric to use for code quality would be their collective feedback on said code.

> Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’.

This sounds like it'd reduce psychological safety on the team, to have someone without the project context come in and criticize your engineers. The morale decline of such a choice could outweigh the benefits.

It’s a suggestion. Generally, code complexity is created by someone that is actually pretty knowledgeable and competent. A straight confrontation won’t easily neutralize such a person in a discussion. They will know how to defend. If they also have peers they are close with, those friends will also negligently condone it with a simple ‘I don’t see anything wrong with that implementation’.

It’s a tough one, so I don’t even know where to begin other than an independent arbiter. Anyhow, I agree with you that it is a delicate matter from an emotional perspective (even though the underlying can be a reasonably objective matter).

The same goes for junior writers who think that complex sentences and words are a sign of superiority, and later discover that the real (and bigger) challenge is writing clearly.

"I would have written a shorter letter, but I did not have the time." – Blaise Pascal

Along the same lines, I recently reviewed a junior engineer's design document and pointed out to them a diagram showing the actors, their roles and interactions would have saved two pages of dense, complex text, and made the solution clearer.

"A picture is worth a thousand words.."

I think there's an element of pridefulness too, in having the ability to manage dense and intricate stuff at all. They're very smart, and it makes them feel good to be able exercise that and juggle and retain so much context at once. And they don't realize how fragile that juggling is, that it's going to take a ton of effort for them or other people to come back to it.

I think this is more prevalent for some languages/stacks than others, too; there's definitely a cultural aspect fostered the language owners or whoever the leaders are.

> Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation

I've noticed this too. One thing I've had mild success with is the concept that a particular programming document (especially in functional programming) is really a series of mini-documents. Each mini-document has function-level comments, a signature, body, and returns that tell part of the story of what that function does. The minute that the collective of those fail me and I find myself reverse engineering code, then we have failed the team and cost the company money.

Some complicated things must be done, especially at the size and scale of our products, but complex things are painted with a fine veneer of interfaces and documentation.

I think another exercise that can help is putting junior engineers front and center to architecture. Whether it's exposing them to review, the review process of a Senior engineers design, or putting them front and center to design implications. I've seen having to figure out the difference between a controller and a service cause some really positive abstract thinking that puts people on the order of thinking for the group rather than their own merits.

Sounds like the style in which most Wikipedia articles are written.

I worked with a guy very much in that vein. He had enough years of experience to call himself senior, but it was clear his actual skill level was halfway between junior and senior at best. He wrote the most clever, fancy, opinionated code I've seen in a while, and he wrote a lot of it. I weep for the programmers that will come along in a year or so that have to figure it out.

Sounds to me like you have a bored engineer, and their energy is misdirected :)

Does that matter. A team with a senior/junior separation should have in place a system of peer review where a code not understandable to a peer will not get merged upstream. There would be a CI system with a linter that forbids abusing syntax for writing dense/obscure code. If a code requires documentation there should be in place a doc-coverage tool which forbids new undocumented code from being merged upstream.

If these systems are not in place, and a senior developer can get away with writing overly complex code, then that is the fault of management, not the developer.

Reply on news.ycombinator.com