Live data from Hacker News

"Careless" employees

niniane.blogspot.com

61–70 of 83 posts

Re: "Careless" employees

#61
post #40

Earlier quoted context omitted.

You'd be surprised. A crucial part of learning to be an artist is open critiques. It is the one moment when lovey-dovey artists suddenly turn into the same kind of nitpicky curmudgeons as us coders. Where do you think great artists come from?

As a professional developer who started college in an art major, I can verify this from personal experience.

It's funny, the similarities between a critique and a team code-review didn't occur to me until penguindev's comment. But they really are a lot alike.

Re: "Careless" employees

#62
I know that these points are often touted as best practices. I agree with most.

I have _never_ seen useful (daily especially!) standup meetings.

That very well might be a cultural problem or an issue with the people I work with etc., but even after giving the idea a couple of chances: 'Daily standups' make me cringe inside.

Re: "Careless" employees

#63
post #41
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?"

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta tester…

> I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta testers to tell me when things go wrong.

And I'm sure you can see that if you were in a position where you had thousands of external paying customers relying on your service (who will possibly leave and stop paying if it breaks) that you might appreciate having unit tests and other automation to help you worry less when it comes time to push the big green launch button.

Re: "Careless" employees

#64
post #63
post #41

Earlier quoted context omitted.

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta tester…

> I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta testers to tell me when things go wrong. And I'm sure you can see that if you were in a position where you had thousands of external paying customers relying on your service (who will possibly leave and stop paying if it breaks) that you might appreciate having unit tests and othe…

Yes, for sure I can see that. Like I say my app is in a constant beta state.

Re: "Careless" employees

#65
post #20

Earlier quoted context omitted.

I find that one of the causes for wildly different levels of code review (and value derived from them) is a lack of training. There is a real lack of materials for explaining how to do a code review, how to do deal with the human aspect of giving feedback, what is/is not valuable to talk about (arguing over tabs vs spaces should not happen in a code review). Most of my experiences have involved a trial-by-fire proces…

I agree - and your comment gives me an idea for a series of posts on this exact subject.

Great - would love to read :)

http://exercism.io/help/how-to-nitpick is a good resource as well.

Re: "Careless" employees

#66
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".

Re: "Careless" employees

#67

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.

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

Re: "Careless" employees

#68

Earlier quoted context omitted.

> 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.

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?"

Re: "Careless" employees

#69

Earlier quoted context omitted.

> 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.

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

Additionally, just knowing that code reviews are going to happen often results in developers putting in more effort to submit quality code.

Re: "Careless" employees

#70
Building automated test is like getting a flywheel going. Sure it might be difficult to start, but once it's gets going, it will take you very far with little incremental effort.
Post reply on HN