311–320 of 458 posts
Earlier quoted context omitted.
In my opinion, only the last one may be justified.
And my own darn fault for using platform Y from team X that would release a security update on a Friday. Yes, fix it. But if this isn't a one-off, get off of platform Y.
When he returned to the air field, Bob Hoover walked over to the man who had nearly caused his death and, according to the California Fullerton News-Tribune, said: “There isn’t a man alive who hasn’t made a mistake. But I’m positive you’ll never make this mistake again. That’s why I want to make sure that you’re the only one to refuel my plane tomorrow. I won’t let anyone else on the field touch it.”
In my experience, while someone might be extra careful not to repeat a mistake that has burned them in the past, making a serious mistake is often a sign that someone is careless, and more likely to make other, different mistakes in the future.
I think it's especially true in tech jobs where there is a lot learned on the job. I would be deeply skeptical of any tech company that takes a fire first attitude. That just tells me they 1) treat devs as disposable and 2) they get rid of everyone that has a chance to learn from their mistakes
As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned. It seems paranoia is a great indicator of experience, and over-confidence/arrogance is an excellent indicator of a lack of learning. Not to say those are the rules, as there are certainly arrogant engineers that are excellent but I'd rather work with the softer one personally.
I know as I have grown I have become softer, not harder, as I realize my humanness.
> One Friday afternoon (...) [Kevin:] what did you learn? / [OP:] I talked about the need for proper QA. About thoroughly testing my changes. About taking the time to make sure the job gets done right. Kevin sure sounds like a great guy. But there was a simpler lesson to be learned: never, ever push changes on a Friday.
I think this goes a little too far.
I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises.
Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday.
http://product.hubspot.com/blog/how-we-deploy-300-times-a-da...
https://github.com/blog/1241-deploying-at-github
https://www.wired.com/2013/04/linkedin-software-revolution/
https://www.facebook.com/notes/facebook-engineering/ship-ear...
Earlier quoted context omitted.
You are an asshole if all it takes to fire someone is some laugh. Everyone shoukd be able to laugh at everyone's code. It's just a code.
Laughing at someone's code is like laughing at someone's painting or their novel or really any other creative endeavor. It's not ok period.
Hell, every now and then I stumble across some idiocy in the code base and think "LOL, whoever did it this way is an idiot". git blame. "OH, hahaha, it was me, what an idiot past me was, amirite guys?" Everyone on the team takes levity about mistakes very seriously ;) It's healthy.
Mocking condescension on the other hand is a different thing entirely.
Earlier quoted context omitted.
In which case angrily confronting that person would further justify their ill will towards you and strengthen their resolve to sabotage you. How is that productive or tactful?
And becoming passive implies the message that you're a pushover to whom anything can be done because there will never be nefarious consequences. To those people the mindset is: If I do X I might gain something (or feels good) and no mater what I'll never suffer any retaliation for it. Why shouldn't I do it?
Giving into anger is the easy thing to do, but in doing so we become emotionally blinded to more practical courses of action which we may have realized if we had kept our cool.
Earlier quoted context omitted.
This doesn't jibe with my experience. As long as the person doesn't evaluate their mistakes in a vacuum they become more careful in general because they learn that things can bite you in the ass in totally unexpected ways. So I'd say it depends on your environment combined with the individual. Someone who is apathetic and/or lacks critical thinking skills will probably learn very little beyond avoiding that specific…
*jibe (jive is a dance, jibe is agree)
Shows the other meanings of the homophones - English huh!
Earlier quoted context omitted.
I wish that story ended with the developer of the trading software learning a lesson about user interfaces
This is a good point--I remember even the online game "Runescape" had a warning that would pop up if you tried to sell an item worth X for a very low price. It would seem to me (somebody who knows squat about stock trading) that a warning screen would be much more beneficial for stock trading software than it is for an online video game.
I'd imagine in the case of the stock trader, where quick reaction is valued, he'd have quickly entered whatever key combo is necessary to dismiss it the warning and made the same mistake.
Earlier quoted context omitted.
Aren't you interested to find out why they're making those mistakes?
Of course. I guess I can give some examples. One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else". Another developer constantly forgets to termina…
Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign people tickets, tag machines with their desired longevity and kill machines past their designated life span (or a default minimum), hold code reviews for new highly conditional methods and include drawing out truth tables and checking the desired behavior for each row.
Lots of teams either expect everyone to be be an ideal spherical engineer and stumble when that proves not to be, or expect nothing of anyone and are doomed to achieve that expectation. The middle path of expecting excellence but tolerating failure is a lot of work but has plentiful advantages. How much failure you have to tolerate and how complex the systems designed to provide that tolerance are depend on the makeup of your team and its size (the larger your team the closer to the mean you'll have to be, and with more individuals a wider variety of behaviors will be represented).
Earlier quoted context omitted.
Oh his behalf, I apologize. I literally started laughing at a junior's code once but in my defense, he had spent 3 years at Amazon.
I'm sorry, but you have no defense. Laughing at a junior developer'a code is completely inexcusable. Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.