"Careless" employees

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.

What I have done in other cases is the "walk-around" to speak to people individually rather than in a massive group meeting - and that seems to have been well received.

So basically you want to implement Enterprise QA processes for a tiny team so as to make up for incompetence and bad hiring decisions. Sorry, I don't buy it.

I feel like we're not getting the whole story. For example, what do you do when you follow all these best practices, but end up with a product that no one wants?

I am going to approach this a bit from the other side. And I'll make it personal, rather than asking a series of indirect questions.

More than once, I've ended up in a position where I've put considerable effort into fixing what are often frankly the shortcomings of other co-workers. Co-workers who sometimes may be observed to be very busy discussing their weekends, or the latest movie, etc.

I've fixed conditions that come about as the employees responsible continue to be rewarded, promoted, etc. -- in short, considered "acceptable".

I tried to do what I felt and what I had been taught was "the right thing".

IN HINDSIGHT: When you find yourself persistently in such conditions, when the problem is not a one-off, GET THE FUCK OUT. Unless you can very demonstratively take control of the situation -- of the conditions -- and steer it in a better direction, you are caught in a system that will chew you up at the least and most likely, sooner or later, spit you out.

As a relatively unempowered employee, the single solution to bad management and counter-productive compensation, is to GET THE FUCK OUT.

Anything that prevents your mobility, e.g. employer-provided health insurance, a non-liquid mortgage -- I won't, I refuse to, add "a family" to this list. But otherwise, any such thing becomes an anti-pattern.

One perspective on what is wrong with U.S. society these days: So many people locked into anti-patterns.

I definitely agree with all of the sentiments in the blog post. With the exception of daily scrum (we do twice weekly), we try to follow all of these habits. There always seem to be two things which we run into though; superficial code reviews and haphazard integration.

On the code review side, I find that most engineers look for trivial crap that could normally be picked up by running lint. It's nice to have similar lint-y style, but for me, the most important things to look for are whether the code is going to break with unexpected input (ie. is the logic sound and are the unit tests good enough), and did the engineer write in an idiomatic style which would be easy for other engineers to understand. I don't mind comments like "maybe use this other variable name", however using recognizable patterns which allow other engineers to easily follow the logic is much more important. Often it seems like people get lazy during reviews and write really superficial comments instead of taking the time to really get down and dirty in another person's code. And why would they? They've got their own code to write.

The other thing I feel like I'm always up against, particularly with younger engineers (sorry younger engineers!) is not thinking through all of the integration points when your code needs to work with other code which is being developed concurrently. One engineer will say something like "Oh, just call function X", which when you do, doesn't provide the functionality which the other engineer was claiming it had. That, or there was some additional step which one engineer wasn't being explicit about and there was an assumption that you were going to take care of it. There's nothing worse than finding this out on the last day of the sprint when you're trying to button everything up.