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

51–60 of 83 posts

Re: "Careless" employees

#51

Post by cja23 »

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've done daily stand-ups under the Scrum methodology that the whole team liked and found successful. In my experience, it goes best if the emphasis is strongly focused on getting the team members to communicate to each other and to the team as a whole. If everyone is just standing around waiting for their turn to deliver status to the boss, the stand-up is a poor use of time since, as you suggest, the boss could just do the walk-around and collect that status one-on-one. When I've been "scrum master", I make sure the boss/customer/product owner stays quiet in the stand-ups and nudge the team culture towards using the time for the team to talk to itself, synchronize everyone's knowledge and expectations, and build coherence and comraderie, ideally ignoring the extra people in the room.

It's definitely work to build and maintain that kind of culture, but I've had many people tell me it makes them want to come to work in the morning because they enjoy starting off this way. It also helps that I try very hard to make sure this is the one and only recurring "meeting" they have.

Re: "Careless" employees

#52

Post by thirdtruck »

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 love our daily stand-ups.

That said, we often have to take things "offline" because they spur plenty of larger cross-dev, cross-functional discussions. Also, I've made a point of documenting my daily work effort, so I have plenty to report.

I hypothesize that one's enjoyment of daily stand-ups is a function of (a) the team's general openness to communication, and (b) the degree to which one's daily report reflects positively of their effort.

Re: "Careless" employees

#53

Post by ianmcgowan »

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

Re: "Careless" employees

#54

Post by collyw »

jeremyjh wrote: post #47
collyw wrote: 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 know which way is more productive for me. How do you know this? It frankly doesn't sound like you have worked on an application of similar scope that has good test coverage. I went the first decade of my career without writing tests and said the exact same things you are saying. I do agree that learning how to write effective tests is difficult and that you cannot do it by reading the web tutorials and the scant c…

How do I know this?

Because I have on numerous occasions tried to get tests set up, and every time another feature request / data model change comes up before I get anywhere close to building all the related objects required for the tests I want to run. (I agree it is integration tests I need rather than low level stuff that proves the framework works as expected).

The majority of the bugs I see I would not have written a test for anyway, as they are usually subtle interactions between the objects and a variation that were not anticipated in the feature request.

The design is constantly changing, as I work for a DNA sequencing centre and the technology is constantly advancing. A few bugs would have been caught by automatic testing, but not so many considering the time it seems to take me to get them put together.

It is different working for a big corporate entity that has the resources to devote to these things, but in our case we don't.

Re: "Careless" employees

#55

Post by thirdtruck »

Pxtl wrote: post #40
penguindev wrote: post #32

Earlier quoted context omitted.

Yep. I don't think doing an 'art review' is going to turn many amateur painters into a picasso. Code reviews also suck up time of your most senior people. Personally, I'd rather just have some fucking TESTERS. (manual or automatic script writers).

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.

Re: "Careless" employees

#56

Post by 0xdeadbeefbabe »

pvnick wrote: 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…

The word "non-technical" seems generous. How about newb or non-functioning or subhuman? Systems are great, but as you point out it's really the people that matter.

Re: "Careless" employees

#57

Post by thirdtruck »

calinet6 wrote: post #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 yo…

Agreed.

We're feeling a lot of pressure at my workplace, especially for a team of new hires that only formed less than 90 days ago. We've barely had a chance to get a handle on this legacy codebase or form habits, never mind start cranking out new features right away.

I don't expect a factory to produce maximum widgets halfway through its own construction process.

Re: "Careless" employees

#58

Post by chris_mahan »

thirdtruck wrote: post #50
chris_mahan wrote: post #45

Earlier quoted context omitted.

You need to read "Good Boss Dead Boss".

This book? http://www.amazon.com/Great-Boss-Dead-Ray-Immelman/dp/097403...

Yes sorry. (Can't believe I didn't remember the title. I'm reading it right now and it's sitting on my desk. FacePalm)

Re: "Careless" employees

#59

Post by mvgoogler »

mathattack wrote: post #7
pvnick wrote: 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?

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

Re: "Careless" employees

#60

Post by jrochkind1 »

collyw wrote: post #41
16s wrote: 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 have projects where I can't manage to get any kind of automated tests in, because it's just too hard to figure out how to do it, way too time consuming. And indeed they don't have tests.

I have other projects where I manage to get good automated test coverage.

Having this experience, I know for sure which projects are more enjoyable to work on,of a higher quality, with fewer bugs, better architecture and more developer productivity -- the well-tested ones every time.

If you write tests from the start, it tends to effect the architecture of the project -- creating a testable architecture, but also generally a better more maintainable architecture. So the projects where testing is 'too expensive' are often those that were started without tests. Also, certainly, some environments/frameworks/platforms support testing better than others. And I think it's true that some domains are better suited for testing than others -- sadly, in my experience, typical web apps are actually among the hardest things to test well.

I have sympathy for not having figured out how to test in an economical and maintainble way. Sometimes that's me. But at this point I am confident from my own experience, that when I can figure out how to test in an economical and maintainable way, it leads to better software and less frustration.

(I suppose there could be a correlation fallacy here, where the 'less problematic' (in some ways) projects are the ones I manage to test on, and it's because they are 'less problematic' that they are higher quality, not because they are tested. All I can say is my experience leads me to believe in tests, even though I still don't use them in every project, because in some projects I can't figure out how to do so economically.)

Post reply on HN