|
Pawel Krakowiak wrote: ... web app ... modal dialog ...
Hopefully not using showModalDialog? That's been disabled in Chrome[^], and deprecated in Firefox[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Sorry, but I'm with Pete on this one. Public shaming is never going to work out well.
|
|
|
|
|
Why not? I did not mean real shaming (there was a winking emoticon), rather something like described here[^]. It's a joke. 
|
|
|
|
|
Any developer introduces bugs. It is the direct consequence of writing code. There is no point in shaming, even playfully - just point it out and correct it, or ask the one who introduced it to fix it (maybe there was some good reason and you yourself break something trying to fix it).
One thing that must be clear is that any relevant change must be tagged in the comments and in the changelog, so that it is backtrackable. I work duo with a colleague, and when I change some established code I never remove it, just comment out the prevoius lines, insert my own and tag with "[NAMEOFTHEMODIFICATION] xx/mm/yyyy Denis: I did this because...". The same does he (ok, not really, but if it's not tagged it's him  )
|
|
|
|
|
|
|
Pawel Krakowiak wrote: I feel that whoever breaks stuff should be publicly shamed
(for example in the CI server's website, but of course my client doesn't have
CI...) and responsible for fixing it.
Let's see. Two weeks ago I fixed a few security issues in C code written in 1994 by someone I don't know who worked for a company that exists no more. As much as I would like to find the original coder and make him fix the bug, somehow I feel that won't work.
|
|
|
|
|
Is this not the path of progress?
One person creates something useful; which the stakeholders want to expand functionality for. This then gets worked upon by new team members who will not have the same knowledge levels as the creator - they add new features, and also "inject" bugs. These bugs need to be worked upon - and unfortunately (or fortunately?) in this case, it is the creator himself assigned to fix them
Not just software, but automobiles, airplanes, bridges, etc. - would have had the same path towards their current state, isn't it?
|
|
|
|
|
Message Closed
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Kamen Nik wrote: debugging and fixing bugs shouldn't be done by people who developed an application
It's good to be KING!! (See Mel Brook's History of the World Part I[^])
This terrible logic would seem to create sub-human RULERS who think everything they produce is perfect.
(In an exercise of self-control, I will not mention anything toilet-related here.)
Blithely they roll on.
Ignorance of our own failures is the most beautifully ugly thing. 
|
|
|
|
|
Pawel Krakowiak wrote: I feel that whoever breaks stuff should be publicly shamed
Impossible! Everyone breaks something once in a while and when everyone is publicly shamed there is no public to watch the shaming and thus no one is publicly shamed.
Now let me find that post where your colleague said the same about your code...
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
That's 'caused'.
There.
Now it's fixed.
|
|
|
|
|
I'm not a native English speaker, so I'd appreciate if you could elaborate. Perhaps the word choice is incorrect in the first place. Maybe one can't "cause" a bug. I guess I should have said "introduced".
|
|
|
|
|
Sorry Pawel, I was just joking about the slight spelling mistake in your heading. It was a bug. 'Caused' is a good word to use. And I see you fixed it!
|
|
|
|
|
<OldWarStory>
When I graduated from college, I went to work for the same company I'd worked for as an intern. My boss was pretty overbearing and judgmental. We wrote a data acquisition system for a customer, and were doing some on-site debugging. On the first day, I fixed an issue we found. A couple days later, the issue started happening again, and my boss starts yelling at me. I looked at the code, and my fix was gone. The original code had been restored. Come to find out, my boss didn't like how I'd done something else and restored an earlier version of the entire source file, without regard to any changes.
The remaining two days of the trip, and the 8-hour drive home, were spent in utter silence on my part. During the drive home he tried to half-way apologize, but the damage was done.
</OldWarStory>
Software Zen: delete this;
|
|
|
|
|
You have my deepest sympathies.
Some years back, my department was afflicted with a manager who thought he could and should "fix the inefficiencies" in other people's code. The responsibility for dealing with problems he created invariably wound up on those hapless "other people's" desks...mine included. The ill will he generated that way was thick enough to be carved into entrée portions and served with hollandaise sauce.
Needless to say, the manager was never taken to task by his superiors for his arrogant interference in things he knew next to nothing about. However, the problem went away when he met an untimely demise: run over by an SUV, right in our very own parking lot. And they say there's no justice in this world!
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Well this is a matter of the tension between 'get her done' and teaching. The solution my currant company has come up with is using a web based code review system. When I get someone else bug, I fix it, but then I make sure they are on the code review so they can see the fix. If they are someone I know well, I will talk with them about what and why I did it. This allows me to get her done for the business while still making it a teaching opportunity.
Mind you, if the other developer does not care, I totally agree with the other poster that said you need to take that to your manager, that IS why they are there
|
|
|
|
|
Maybe you can take this negative and turn it into a positive. A true team really doesn't need a manager or to be publicly shamed, they're able to communicate among themselves and tackle issues together. Play dumb and ask the guy that wrote the code to help you. Point out the error and ask for his input. Get an understanding of what he did and hopefully he gets an understanding of what you did.
|
|
|
|
|
When it comes to breaking builds, our culture is that the one who broke it is quick to at least say they investigate it, lest their inbox fills up with "friendly reminders" from all the others.
As for bugs: We tend to use "You were the last to touch it!", the the age-old unwritten rule that has governed many a playground over the millennia.
I'm not necessarily for shaming someone who trips and falls (as others have said, we all do from time to time), but if that someone then refuses to fix their mess, or tries to get away from fixing it, that's a whole different ballgame.
|
|
|
|
|
Happy me. Found another bug caused by the same developer during the same changes, but in a different place. I fixed the last bug...
|
|
|
|
|
Be happy.
I frequently get entire half-finished apps that need to be resuscitated; trying to figure out what works properly; what doesn't; what's missing.
At least you know what it's "supposed" to do.
|
|
|
|
|
There are several ways to look at this
Maybe you are the best person to fix the bug and prevent it from happening again.
Maybe you did a bad job. No supporting documentation, no comments etc..., basically no knowledge transfer which is often the case.
Ego meshed in with the code.
...
...
Regards,
Ousmane
|
|
|
|
|
This used to be roughly half of what I would do on a regular basis. My nickname used to be "the cleaner", as in the guy who cleans up the bodies to make it look like nothing ever happened. The better you get at coding, the more you are called in to "fix it". Think of it as a vote of confidence in your abilities to get the job done.
|
|
|
|
|
Maybe your team could do with code reviews and release testing? IE get script buy-off by the team, promote to test server, have the test team run regression and new functionality tests, get test buy-off, move to production.
PS Since you didn't name names, I don't see a problem with complaining about co-workers. It might even shame the developer into doing better in the future if (s)he reads about it here. If you have good code tracking, people should know who did it anyway. However, it makes sense to assign it to you, the modifier proved incompetent and since you built it, you are more likely to fix it properly.
|
|
|
|
|
I am not sure about what is correct/incorrect in this particular case. But, I feel you should get recognized for that work you did; either writing some new code or fixing bugs created by others.
Here's a story. You might already know it.
There was a farmer who had a horse and a goat…..One day, the horse became ill and he called the veterinarian, who said: - Well, your horse has a virus. He must take this medicine for three days. I’ll come back on the 3rd day and if he’s not better, we’re going to have to put him down.
Nearby, the goat listened closely to their conversation. The next day, they gave him the medicine and left. The goat approached the horse and said: - Be strong, my friend.
Get up or else they’re going to put you to sleep!
On the second day, they gave him the medicine and left. The goat came back and said:
- Come on buddy, get up or else you’re going to die! Come on, I’ll help you get up.
Let’s go! One, two, three…
On the third day, they came to give him the medicine and the vet said:
- Unfortunately, we’re going to have to put him down tomorrow. Otherwise, the virus might spread and infect the other horses. After they left, the goat approached the horse and said:
- Listen pal, it’s now or never! Get up, come on! Have courage! Come on! Get up! Get up!
That’s it, slowly! Great! Come on, one, two, three… Good, good. Now faster, come on…… Fantastic! Run, run more! Yes! Yay! Yes! You did it, you’re a champion!!!
All of a sudden, the owner came back, saw the horse running in the field and began shouting:
- It’s a miracle! My horse is cured. We must have a grand** **party. Let’s kill the goat!!!!*
***
The Lesson:* this often happens in the workplace & life in general . Nobody truly knows which employee or people actually deserves the merit of success & are in fact contributing towards success , or who’s actually contributing the necessary support to make things happen. Be grateful.
Remember………
*** LEARNING TO LIVE WITHOUT RECOGNITION IS A SKILL!!!! ***
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
