News for hackers. Stuff that matters.
Re:Coders Automating Their Own Job by hinkley on Tuesday October 02, 2018 @05:08PM (#18125714)
I've had very good luck changing the behavior of junior developers and moderate luck changing the behavior of mid level developers that are hungry for a promotion. I can count on my fingers (couldn't say if that's one hand or two) how many senior devs I've gotten to come around.

If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating.

By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.

Re:Coders Automating Their Own Job by pvarangot on Tuesday October 02, 2018 @05:30PM (#18125876)
I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.
Re:Coders Automating Their Own Job by hinkley on Tuesday October 02, 2018 @05:57PM (#18126058)
Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed.

Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts.

The problem with doing something right the first time is nobody appreciates how hard it was.

Re:Coders Automating Their Own Job by drawkbox on Tuesday October 02, 2018 @10:56PM (#18127332)
> The problem with doing something right the first time is nobody appreciates how hard it was.

Sometimes if you do put in quality and do it right in development it costs you in time and then by perception.

When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally.

The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones.

Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product.

I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready.

[1] https://developer.valvesoftware.com/wiki/Valve_Time