Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Careless" employees

niniane.blogspot.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: "Careless" employees

#71

Post by shitgoose »

There are lots of software developers out there, that shouldn't be developing software in first place. They could be excellent farmers, musicians, athletes, but for whatever reason they decided to be software developers. And it doesn't matter how many scrums or code reviews you throw at them, they just won't get it. They will be producing miserable results making everyone around them miserable.

On the other hand, there still are a few decent, old school devs, who don't need hand-holding, constant poking and distraction of standup meetings and writing meaningless test cases that check if 2+2 is still 4. They just (1) understand the problem and (2) write code that solves it. As simple as that. Good old engineering, like these guys: http://www.youtube.com/watch?v=8kUQWuK1L4w. Or original SAS system - its reference manual was better quality then any statistics textbook. Unfortunately those days are gone now and we live in the kingdom of Scrums and Frameworks.

Re: "Careless" employees

#72

Post by lewaldman »

wpietri wrote: post #19

I agree 100%, and am especially excited to see automated testing as going from "impossible dream" (c. 1999) to "reasonable, broadly expected quality practice". It has been a long road. However, there's one obvious problem that isn't mentioned: hiring mercenaries half-way around the world who have never met you, don't care about you, don't care about your product, and don't care about your audience. I think it can be…

Did you gave a look on this: http://37signals.com/remote/

Re: "Careless" employees

#73

Post by flurdy »

mvgoogler wrote: post #59
mathattack wrote: post #7

Earlier quoted context omitted.

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?

> partially for inspecting the product, and partially for teaching and inculcating cultural norms Yes! I would go further and say that - without discounting their value for catching bugs - the _largest_ benefits of doing code reviews are cultural rather than technical.

You pair with people you like and do code reviews with people you don't like (misquoted from someone way smarter than me).

With large teams, especially if distributed or partially outsourced, code reviews can ensure code quality. But also be a total bottle neck if over-bureaucratic and some reviews are of low quality due to lack of context. Often combined with ivory tower architects as well.

In smaller, agile and especially collocated teams code reviews will flag issue unnecessarily late in the process. Just pair from the start instead to ensure no short cuts or dodgy code slips through, and automatically spread the knowledge. If you do not trust two of your developers combined then you do have a serious problem.

You can though in addition have small and short swarming/tripling/quadrupling sessions in front of 1 computer to look at especially important issues.

If you do neither code reviews nor pairing then you are in trouble.

Re: "Careless" employees

#74

Post by ShawnBird »

redthrowaway wrote: post #30
KiwiCoder wrote: post #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…

That code snippet is a matryoshka doll of brainfuck.

The first thing I thought of is, even in a hypothetical world without a Clear() method or any means of adding one, why use a for loop instead of a while loop? And if you are set on a for loop, why not simply set the first count to a variable? It is bad on multiple levels.

Re: "Careless" employees

#75

Post by binarysolo »

ianmcgowan wrote: post #53
binarysolo wrote: post #44

Does anyone have a resource for a full checklist of practices? I'm a processes guy but I'm curious what all is out there these days.

I don't think you can beat the joel test for simplicity. It's a bit dated perhaps, but still surprisingly relevant. http://www.joelonsoftware.com/articles/fog0000000043.html

Oh wow, I remember reading this years ago, but it's still surprisingly relevant (took the words from me :) ).

Re: "Careless" employees

#76

Post by redthrowaway »

ShawnBird wrote: post #74
redthrowaway wrote: post #30

Earlier quoted context omitted.

That code snippet is a matryoshka doll of brainfuck.

The first thing I thought of is, even in a hypothetical world without a Clear() method or any means of adding one, why use a for loop instead of a while loop? And if you are set on a for loop, why not simply set the first count to a variable? It is bad on multiple levels.
"I need to delete every item"

    for (i = 0; i
"Shit, that didn't work. Why isn't it deleting everything?

    for (i = 0; i
"Huh, it's removing every other item."

    for (i = 0; i
"Weird, it's removing an item, skipping an item, then removing the next one."

    for (i = 0; i
"Well shit, that seemed to work."

    for (i = 0; i
"Ship it."

Re: "Careless" employees

#77

Post by wpietri »

ctdonath wrote: post #66
wpietri wrote: post #19

I agree 100%, and am especially excited to see automated testing as going from "impossible dream" (c. 1999) to "reasonable, broadly expected quality practice". It has been a long road. However, there's one obvious problem that isn't mentioned: hiring mercenaries half-way around the world who have never met you, don't care about you, don't care about your product, and don't care about your audience. I think it can be…

Such a situation may enhance the issue the author addresses, but his point remains paramount: don't expect what you don't inspect. If anything, hiring "mercenaries half-way around the world" requires more of what he enumerates, which is the objectively practical form of, as you say, "do a lot to create real human connection".

Requiring unit tests is a great idea, and I am 100% behind using the techniques she describes, but it's not the real human connection I'm talking about.

One of the best distributed teams I know spends a week per month together despite the travel nightmare that entails. Another reasonably good remote project had the product manager spending 1-2 weeks every 6 weeks with the development team. Having developers participate in user tests is also great, as is finding some way for them or their friends to become actual users of the product.

If the developers don't give a shit about you or your users, you'll have to do a lot more inspecting than if they are personally fired up to make things work for people they care about.

Re: "Careless" employees

#78

Post by timr »

shalmanese wrote: post #48
timr wrote: post #33

Yeah, code review is great...until you find out that some of your reviewers are rubber-stamping the commits from their favorites, and a large percentage of the rest are doing a sub-standard job of reviewing, and pretty much everyone is just barely finding the time to do the (decidedly un-fun) chore of reviewing code, instead of writing code. So you're back to the root cause of the problem: you have to hire good peopl…

The solution is code meta-review! Just have reviewers review the quality of reviews until review quality is up.

Slashdot was the future.

Re: "Careless" employees

#79

Post by collyw »

Pxtl wrote: post #39
AndrewKemendo wrote: post #21

I think these are all fantastic things to implement but do you know how much pushback you get from engineers on this: Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?" In general folks HATE these, but I would love to hear other cases where people have found them successful. We are small enough that the conversation is ongoing so haven't needed to implement it. Wh…

I think the important point is that a boss needs to touch-base with each employee daily, and how you do it is up to you.

I prefer it when mine stay out of my road and let me get on with things. They have a pretty poor understanding of software engineering, but can code enough to think their input is helpful, when it usually isn't

Re: "Careless" employees

#80

Post by mathattack »

saraid216 wrote: post #68
philangist wrote: post #67

Earlier quoted context omitted.

Can you expand on what you mean by this? What cultural benefits are you talking about?

One of the huge benefits I've found from code reviews is that my reviewer will say, "Actually, we've faced that problem before and there's a solid and proved solution in our utils that handles it already, along with a couple other cases. How about you change it to use that instead?"

Yes - building on this, I see 4 quick benefits:

1 - Suggestions on where problems have been solved before. (Your point)

2 - Having people say, "Here's the style we use to make this easier to support in the future"

3 - Mentoring on tougher problems, and turning quick hacks into elegant solutions.

4 - QA. (This is the stated benefit, but falls below the other 3)

The key is not to turn code reviews into a bottleneck. If you just view the purpose as any 1 of the 4, you're likely to under-prioritize or over-formalize it.

Post reply on HN