Live data from Hacker News

"Careless" employees

niniane.blogspot.com

1–10 of 83 posts

Re: "Careless" employees

#3
This post hit home for me. I've personally implemented code review strategies which directly and immediately led to much improved code quality and generally better product. But management doesn't see code quality. They see deadlines. The insignificant time it takes for code review is the first thing that gets nixed by non-technical management even when the time required for bug fixes, last-minute changes due to their own indecisiveness, and slow development due to giving employees second-rate hardware far eclipse the marginal time it takes to make sure we're deploying halfway decent code to production. And then they bitch at the engineers that they're underpaying/overworking when shit stops working. But let's not hire more developers and improve salaries for the people we have. No, that's not what we need. What we need is more charismatic biz-dev bros with poly-sci degrees. Surely that will fix things! (/rant)

Re: "Careless" employees

#5
Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"

Re: "Careless" employees

#6
Long story short, I get put on performance review, threat of termination. Boss gives me exacting standards for project to complete by X date, reviews everything I do and I have to write a progress report every 2 days that's reviewed (usually). Boss asks, "why did your performance improve so much?"

I'd never even seen a project plan before a few months ago...

Re: "Careless" employees

#7
post #3

This post hit home for me. I've personally implemented code review strategies which directly and immediately led to much improved code quality and generally better product. But management doesn't see code quality. They see deadlines. The insignificant time it takes for code review is the first thing that gets nixed by non-technical management even when the time required for bug fixes, last-minute changes due to their…

It seems like code reviews are partially for inspecting the product, and partially for teaching and inculcating cultural norms.

Are the managers who don't like this just non-technical? Or are they just not being presented the value in a clear enough way?

Re: "Careless" employees

#8
post #5

Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"

I don't think he's using the word "flaunt" correctly. It struck me as off -- sure enough, the definition agrees with me.

"Flaunt: to parade or display... conspicuously. The use of 'flaunt' to mean 'to ignore or treat with disdain' is strongly objected to by many usage guides.'"

http://dictionary.reference.com/browse/Flaunt

Re: "Careless" employees

#9
Systems, systems, systems. Spot on.

Just as in manufacturing, you cannot produce quality by blaming the individual worker. Japanese manufacturers learned this from W. Edwards Deming (http://en.wikipedia.org/wiki/W._Edwards_Deming) and it continues to be true to this day, but for some reason the natural human instinct is to blame the individuals instead of the systems.

Improve your individuals and you can improve your quality maybe twofold, threefold at best. You might chance upon a "rockstar," but probably not.

Worse, blame your individuals and you lose productivity, lose trust, lose culture, instill fear, and break ties. Negative reinforcement brings unpredictable negative consequences.

Improve your systems, your culture, your process, your communication, and everything surrounding the production of your product, and you can improve your quality tenfold or more, and more importantly, be better prepared for a 100x or 1000x growth.

Blame your systems and they can only get better.

I can't think of a time when it's incorrect to think from a systems-first perspective.

Re: "Careless" employees

#10
Code review ranks just behind design review in value (cost/time savings). In fact code reviews are so beneficial that if I was working on a solo project I would either pay for them to be done or review the code myself after a suitable cooling off period, depending on what I was working on.

On the other hand, I have also witnessed sloppy, lazy code reviews that catch nothing except the occasional typo. This amounts to an unjustifiable waste of time. Fortunately, it is easy to tell a good code reviews from bad by tracking defect discovery and digging into review comments as needed.

One thing that code review catches that nothing else does is code that is poorly written but functional (i.e. passing tests).

The example I always trot out is

    for ( int i=0 ; i 
This code works according to spec, passes all the tests, but is bordering on unmaintainable. At best it's a WTF.

(Written up here: http://cvmountain.com/2011/09/whats-wrong-with-this-code-rea...)

Post reply on HN