|
Truth,
- Customers: Our credit card number was stolen, all of my personal information and passwords were comprised, how could you do this to me?
- Developers: Doing our best but mistakes happen, that's OK as long as you fix them and learn. For the last 30 years and 30 more years. You can trust us.
|
|
|
|
|
I'm fine by a mistake, once, or twice, or a few times. Everyone makes mistakes. Speaking for myself: when I see someone making mistakes, I remind myself of my own 10 year younger self who had no idea "what an instance of a class is."
Today, working as a Developer Advocate, I do stumble upon mistakes of others, but what I hate is the rigidity to not move forward, not learn.
Otherwise, as a few others suggested, mistakes a good learning.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Zero tolerance? Wow, we all need to meet those perfect people.
That would either be stuff that is far from the innovative edge, or you live in a utopian world where you are in complete control of your environment. Well, maybe you've figured a way to bend the space-time continuum 
Then there's the rest of us!
|
|
|
|
|
Those votes are from Linus and the seven dwarves. 
P.S. At this comment's time, the vote tally for 1%'er was 8.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
The only exception is when I'm in a mentoring situation, in which case I will point out the mistake, expect the "mentee" to correct it, and then review the correction with him/her.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
When I lead a team I try foster an environment of continual mentorship and growth.
It builds team cohesion and helps people better their craft. It's worth the investment in time, because it pays for itself on the back end.
Plus I agree with Einstein when he said that once we stop learning, that's when we start dying.
To some degree I think that applies to my teams.
Tomorrow I will be teaching a guy, whose sort of a colleague and sort of a client how to use my graphics library, and engage in generic programming in C++.
And in this case, I'm not even charging my regular consulting rate for it, because I do this kind of thing on reddit for free. It benefits me on the back end because more people use my library, and in this case specifically because the better he is at producing, the more I can rely on him in a team setting.
Now, obviously that doesn't work that way in a 9-5 setting, but variations of it can, and for me I see mentorship as part of my daily responsibilities, and I try to encourage the more experienced developers to do the same.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I inherited a project a very long time ago. It did not work, but it compiled without errors. Wait for it....
Turns out the first "developer" turned off all of the compiler warnings allowing it to compile. That's not a mistake - it's deliberate negligence at a personnel level.
Group level - not learning from village knowledge. Error handling. Nuff said. That's a group level error.
Hard coding an array to read in a file - newbie developer or someone who is stuck on stupid - that's a mistake. Maybe.
It's now all getting grey 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Then there are those who yell loudly at a co-worker for breaking the source line length limit. Or for using variable names for some concept that differs from how the the corresponding concept is named in a different module. Or some other really non-significant detail.
The next degree would be those who deliberately make their code more readable, e.g. by defining a constant 'ever' to two semicolons, so that an infinte loop can be coded a 'for (ever) {}'. I was once arrested for that one; an infinite loop is supposed to be coded as 'while (1) {}' (and note: 'while (true)' was not accepted coding style).
Lots of self-righteous programmers have their own ideas about how 'proper' code is supposed to look. Anything else is 'wrong', it is a 'mistake'. They do not distinguish between such 'mistakes' and those really causing the software to malfunction, fail, open itself to attacks, leads to drastically overall reduced performance, or whatever.
So the very minimal distinction is: Does the 'mistake' have any significant effect on what the custumer will see? Or are we just talking about interal matters about detail code design? To me, it seems as if co-workers are much more eager to spend energy and anger on those nitty-gritty code details of no significance. (Such as my use of 'for (ever)', which cause a lengthy discussion leading to all of my infinite loops being replace by 'while (1)' in the code base, the proper way of coding inifite loops!)
|
|
|
|
|
To follow up, what you mention falls under trivial - I don't consider formatting issues to be a mistake.
Declaring a global variable to access a non-threadsafe object because you're too lazy to code up a message handler lands somewhere between mistake and negligence. Said developer was *told* not to do it that way.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Since I know the players on my team (non-developers), I tend to do the work of those that are prone to making mistakes (there's always one) independently of them.
Sadly, the philosophy is "there's no I in team" when it works and everyone on the team is equally to blame when it doesn't.
|
|
|
|
|
At a particular project I was the integrator of other's work. One of the other let's be generous and call him a programmer gave me his code. It did not even compile! I stormed to his office angry and hot under the collar and threw the diskette this was a few years ago onto his desk and complained. I don't know why I took it so personally as I had no stake in the success of the project which as it turns out was a complete failure. It was just a job. Maybe professional pride got the better of me.
|
|
|
|
|
Piss and vinegar brother. If you don't give a crap, give me your keyboard.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Not my circus, not my monkeys. I'd have a whole lot more concern about the mistakes of other developers if I were working my own circus with my own monkeys. For that, I'd agree with the majority here; but as it is, if it doesn't touch my day-to-day, meh.
|
|
|
|
|
new consequence option: lose a finger for each unhandled production error
1 finger, you gonna learn quick
2 - ok, need the job for healthcare costs
3 - really, you didnt learn last time
4 - 😲 I got no other skills
5 - its fine I can go to 7, only need two index fingers for hunt and peck typing and any third for when needing to login.
|
|
|
|
|
I would add that just throwing an unmeaningful "something went wrong" message in a try catch block doesn't count as "handling the error" and the same consequences should result.
I just had to deal with an error message to the user that said "Item xxx is erroring out." 
|
|
|
|
|
Also gives us a chance to learn from other's mistakes.
|
|
|
|
|
Mistakes happen - how you deal with it is what matters. Learn from them, and put the learnings into place to prevent them from happening in the future.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
I have been in a situation where I could have helped another programmer struggling in an esoteric problem domain they were not familiar with ... that was my specialty ... in fact, I would have enjoyed mentoring them.
It was the manager who didn't bother to consult with me, who waited until a broken mess of code had to be fixed ... by me.
The programmer was a friendly young guy: I felt sorry he felt one-down about his work, and tried my best to cheer him up.
The manager who set up the young programmer to fail: I do not forgive him.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Everyone makes mistakes: as long as you learn from them, they are an invaluable teaching tool.
But if you do the same thing again, you are the tool.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
But ... That is what "Experience" is - the ability to recognize an error when you repeat it!
|
|
|
|
|
trønderen wrote: That is what "Experience" is - the ability to recognize an error when before you repeat it!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If you are not making the occasional mistake, something is off.
Our technologies are constantly evolving, and we should be trying to use some amount of (proven) techniques if it makes sense. But that means mistakes are possible as we learn.
Linters, code reviews and other such techniques can help with catching these.
|
|
|
|
|
Sometimes, a bug is just that, a bug.
People hit an edge case that's not handled correctly, or one in ten values is slightly off, whatever.
Sometimes, the mistake is that a (part of a) program won't run at all and it's obvious the programmer hasn't even tested (manually or otherwise) their code.
I'm a lot more forgiving to the former than to the latter.
The latter is just lazy and bad programming.
|
|
|
|
|
I work with one of those. Doesn't even compile the code before checking it in, much less tests it. And merges stuff unbidden.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
logically thinking through the code if will work and thinking of breaking things.
like being told, "you need null check on this"
me: uhm no, because to get to this section, it needs to pass a bunch of other stuff which would fail way before if null check here was an concern
vs - runs once, must be ok.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
