|
COLORS
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
2nd and 4th are different
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
Flavor
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
MOSCOW
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
|
center - I'm not doing the 1B 1W etc thing tomorrow.
|
|
|
|
|
|
Excellent. 
|
|
|
|
|
Movie Quote Of The Day
Now, I'm about to do to you what Limp Bizkit did to music in the late 90s.
Which movie?
The MQOTD will return on August 08th 2016... Happy holidays everyone. 
|
|
|
|
|
Not another Justin Bieber quote please
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
Keep on rolling?
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
|
New Music in town
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
|
One night in Paris
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
What should i do when a junior developer comes to me saying: "There is a bug"?
He knows there is a bug since the system isn't performing as it should. But, he didn't debug to find out what or where is this bug exactly.
I feel like i'm doing there bugs here.
|
|
|
|
|
Say: "ok, tell me what's wrong and we try to find the bug".
First you are working together, then you're his mentor IMHO.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
I would better go for: "Try to find it out, when you get it, we try to solve it together"
on the first instance at least. If not success, then help to find it out
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I'm not fond of that method if not strictly needed. It's always better to find out together if feasible (meaning the other has no urgent work). It does not help, while solving something together is a strong way to pass knowledge and experience.
When I find some bug in parts of software I'm not working on I usually refer to my coworker/mentor, often before tackling it - it may not be a priority. Doing so:
* My coworker knows I found out a bug. If he stumbles upon it he may recognize it;
* My coworker may have already solved that bug in a fork or may have tried to solve a bug in the same part of software which then resulted in the current one.
Then we decide if, when and who will hunt for that bug or we put our heads together and at least try to find it. He has more experience than me so he may remember things I never saw.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
den2k88 wrote: It does not help, while solving something together is a strong way to pass knowledge and experience.
You didn't get me correctly.
I just said, I let him search (learn how to debug) (I still help if he ask me to) but we solve it together.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Where do you stop after that? Finding the bug, Fixing it or reporting result?
|
|
|
|
|
It depends on what I'm doing and the entity of the faulty behaviour. Usually I report I found the bug with as many details as possible, then await for instructions - the fix may take priority over my current occupation or viceversa. It could be put in the to-do list or treated as "quick fix and then let's rethink how that component works, as it is no more adequate", and that usually means the big task is postopioned of months or more.
So usually I report it and decide with him what to do next. Of course if I have time I do a little research on the bug. We don't have a single code base unfortunately - we have a handful of standard versions of the same software for different machines and then we have a plethora of hundreds of customized versions for each customer that asks for specific solutions, and all the versions of the customized software. This means that I may solve a bug on a software and still have it on several tens of other versions. So reportig the bug takes priority over any fix - since it allows both of us to fix it or look for it on every subsequent customizations we happen to stumble upon.
In the general cases I would stick to report first then decide how to solve the problem. It simply may be better to ignore the bug or change an entire component and structure instead of fixing it. Also the fix might involve many other subsystems and require a lot more effort than anticipated - it must be clear to every member in the team what to do and how to allocate time. Starting on a solo quest to fix a bug without alerting the other members first puts in danger of wasting valuable time and resources. Like in the army - you do not take unsolicited solo actions without at the very least informing your direct superior.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
There seems to be a subsection of developers who believe that if you can get it to compile, it's bug free - go over to QA and you'll see what I mean - so the first thing to do is invest some time in getting him familiar with the whole idea of debugging. Get him to do the work, with you watching and pointing, making comments, but letting him do the actual work.
It's a lot more time-consuming than fixing the bug yourself, but in the long term you end up with a better co-worker who can do the whole of his job instead of just the easy bit. And that saves you a huge amount of time in the long run. You may even get his everlasting gratitude ... or at least until Thursday ... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
