Hacker News Reader

Comment by ericb | Hacker News Reader

> praised by management for the amount of work they produced

Management literally can't tell the difference, sometimes even if it is a former dev. There are many ways to ship code faster.

-Don't test

-Don't worry about sanitizing inputs--extra effort slows you down.

-Optimize for writing, not maintaining

-Take a tech-debt loan. Bolt your feature somewhere convenient it doesn't belong.

-Put on blinders. Your n+1 query problem is Tomorrow's Problem

-Avoid refactors

-Choose the first architecture you think of, not the one that is simpler, more flexible or more useful

-DRY code takes too long to write--you'd have to read more code to do that! That's bottom performer thinking!

-Securing credentials is hard. Hardcode them!

Remember, if you want to be a top performer and have breathless articles written about you, ship many commits, fast! Also, this is a virtuous circle--if any of these become "problems" you'll get to ship more commits!

View on HN

> Don't worry about sanitizing inputs--extra effort slows you down.

I feel like many people downplay how important this is. I've wasted way too much time because of this. Doing code archeology to understand why data persisted to database many years ago breaks some seemingly unrelated feature for a customer is definitely not my favourite part of the job. Working on a validator that someone was "too busy to add" in the first place is also not fun (and a waste of time - because original author could probably do this in matter of minutes; whereas someone fixing things post-factum need to reverse engineer what is going on; check whether some funny data wasn't persisted already and potentially handle it).

To phrase my frustration in more constructive way: it's always a good idea to put explicit constraints on what you accept (What characters are allowed in text-like id - only alphanum? Only ASCII? What happens with whitespace? How long can it be?). Otherwise it's likely you will find some "implicit" constraint down the road; ie. other piece of code breaking down.

Oh, lord. I don't usually have to think about sanitizing data coming from my own database, but of course any long-running database can have all sorts of crap in it. What a nightmare.

> Avoid refactors

On the contrary, small refactors are a great way to boost commit count! Management once tried to boost productivity by rewarding commits. Our team basically started manually committing automatic refactorings. We won by a landslide, but I don't think the company did. I got a nice prize out of it though.

Hah! That's some top performer thinking! I tip my hat to your team!

What differentiates highly productive developers is their ability to ship more complete functionality from the same input as other developers. Inputs can be tickets, requirements, or even notes from a meeting. Commits and pull requests are production steps, but don't tell the whole story - they do give you some level of indication.

the converse is also true, occasionally. depending on the business model, some engineers are too comfortable with a slow, methodical process. often, just getting something to work, despite accrued tech debt, helps a team iterate toward a better solution. if requirements or the rest of the realized architecture was perfectly understood from the beginning, then slow and methodical is the minimal risk implementation. but in the real world, that’s rarely the case. what i’m saying is that true talent is able to intuit when one approach is preferred over the other.

Comments without capitalization are optimized for writing once at the expense of many readers.

Fair.

Don't forget to not waste time on documentation!

Everybody knows code self-documents by definition. /s

What if every commit has to be reviewed by a certified code reviewer before it is accepted? That is how Google does it. Means you can't skip tests etc. Not sure why not more organizations do it, like wouldn't banks etc benefit a lot from it?

Wonder to what extent that solves the problem. Quite often your code reviewer's interest/world view aligns with yours: "Right we need to ship this feature asap so let's worry about tests later" or "More commits boost your performance review so these 50 1-liner commits I get it."

It reminds me of a similar problem in academia: the LPU (Least Publishable Unit) phenomenon where people tend to break a work into multiple smaller pieces to get more paper counts. It's so widespread that lots of paper reviewers are doing them too. So you don't get punished.

depends entirely on the team culture.

In my experience, its the sloppy Engineers that create problems that get the most credit. They are called upon to be 'heros' again and again, to fix their crap they shipped with 1000 issues.

Yes, I've seen that a few times. What non-technical management sees is an engineer at the center of efforts to fix an issue in the midst of a crisis. What they don't see is that the work done by competent engineers doesn't blow up and become a visible crisis.

IMO this is a big red flag that something is wrong with both the technical and non-technical culture. Technical management isn't happening, at least not effectively, and non-technical management is getting too far into the weeds on technical details of production issues.

> -Don't test

In an environment that rewards commits, unit tests can be a source of many little commits.

Tests are fiddly to get working and could expose problems! Maybe in a new commit and PR later?

Plus tests are so slow to run, booooooring. How can you get anything done if you're staring at red text all day?

They're not fiddly if you do assertion-free testing

^^^ It will only work where no one else is reviewing your code

I'm not so sure.

When you disagree in a code review with the "top performer with all the commits" it gets escalated to management, who sides with the "top performer" because they are a "top performer."

Reply on news.ycombinator.com