Hacker News new | ask | show | jobs
by clktmr 2350 days ago
Wherever I worked, these kind of checks did always more harm than good. You force a bunch of tools on your developers which they hate, only to have your whole codebase littered with "disable linter X" comments. In a good review process the developers can negotiate the conventions by themselves, which leads to acceptance among the team.
5 comments

Well if the team doesn't like the linter tool they should be able to change it. That's a political problem and nothing to do with linters.

My experience is that linters (that people like) saves you from having to constantly discuss formatting, minor problems at the PR stage which is otherwise a huge time sink.

In one of the teams I best worked with, payment was done per closed task. There were no salaries. Just bounties per closed tasks.

If you didn't respect the Quality Gates, your branch wouldn't be merged => you wouldn't be paid.

It was one of the best experiences in my work life so far. Clear rules, no chaos, no meetings, no negotiation. Just tasks and money :)

I can think of a few ways of how this could backfire / be gamed or abused, but all in all, seeing how everything else is just as susceptible to abuse and gaming, it still sounds awesome to me.
Yeah, I get your point.

But everything was upside down with that team, not just payment. They had a completely different philosophy when it came to software development.

For instance we were encouraged to just close tasks. It didn't matter what we did as long as the build and code reviewer were happy.

Part of the philosophy was that if developers can abuse and break the project, the project is not good enough and must be toughened. Then, developers were encouraged to find other loopholes.

This methodology worked wonders for small projects, libraries. It didn't go well for big projects, obviously.

This sounds identical to the agency I was reading about.They pay devs for closed tasks. I.e.: a class needs to written that does x. The reward is $100.A senior dev will do it half an hour, while a junior will spend a few hours,which bases work-reward process self balancing based on experience.The owner of the shop had some very detailed blog posts on this,which attracted tons of discussions.Shame I can't recall the guy's name..
I think you're talking about https://www.yegor256.com/

It was fun work back in the day of Teamed.io. But nowadays, with Zerocracy, it's turned a bit too strange even for my taste, after having worked about 2 years with Teamed.

Yes, that's the one! Will need to get on his blog at some point, he's got some unorthodox,yet interesting ideas.
If the project isn't a huge bureaucratic nightmare, you can fix those loopholes as they come up. You might even give a small bounty for people who report loopholes. (But make that bounty mostly bragging rights, not money.)
How did you deal with holidays and illness?
I have to say, I did not encountered such situation. Teams I was in used linter and equivalent tools and the "disable linter" directive was basically never used.

The rules to be used were negotiated among developers. In one team, the use of linter cut down on the uneven random unforcement of the unofficial rules that was going on rampant (and subsequent frustration of involved people).

That's just a matter of methodology and/or discipline.

Depends on the team: if the team is democratic, then they should reach an agreement beforehand and respect it. If it's a dictatorship, then just punish them for not respecting the rules.

If the devs just agree to break the rules and disable them, they should be punished somehow. "Punished" is a big word maybe, but that's the idea :)

> In a good review process the developers can negotiate the conventions by themselves, which leads to acceptance among the team.

You don't want to spend the first half of every review going through and finding errant formatting mistakes. Automate what you can.