|
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...
|
|
|
|
|
|
I think to respond to this interesting scenario, we'd need to know more about what the "culture" of your work-place is: how "hierarchic" is the social system, how "flexible" are the assigned roles ... are there any formal norms (job descriptions, etc.) that apply here. Is there some formal task the employee who finds a bug they can't deal with is supposed to do, like log a bug-report, or bring it up in some code-review ?
And, is it part of your role/task/jog to "foster relationships," teach, mentor, or provide technical back-up ? Is there any screening when hiring for debugging skills, or any promise made/implied to new employees they will be trained in how to debug ?
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Junior developer: This is a bug
Senior developer: And?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
In the past my approach was to gently pointy the newbie in the right direction by asking the question they should be asking themself. What does the log file say? Have you identified the assembly / class / method where the problem is? What happens when you step through?
veni bibi saltavi
|
|
|
|
|
Nice way
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.
|
|
|
|
|
He: There is a bug.
You: Well then how about fixing it?
He: How am I going to fix it?
You: Grit, spit and a whole lotta duct tape? I have heard it just works.
You have just been Sharapova'd.
|
|
|
|
|
I may have an opportunity to get involved in a supporting role in an IOS project, and I am curious what hardware-software I should ask them to provide. It appears, at this time, they do not want to do cross-platform development.
In my case, a constraint would be that I'd have to work on a large monitor due to my vision limitations.
I've looked into Swift far enough to see that working in it would not be a problem, although, I assure you, I assume there would be a steep learning curve getting "oriented" and "up to speed" on dealing with OS functions, control, ui behaviors, etc.
thanks for your advice, and opinions !
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
I'm using Xamarin.
So C# to code up IOS apps - with my Shiny new previously mentioned iMac,
Code on a desktop PC - compile etc on the iMac.
Bryce
|
|
|
|
|
You got an iMac? Why didn't you mention it?
veni bibi saltavi
|
|
|
|
|
The poor devil - everyone in the office is feeling sorry for him, the damn thing forces a reboot more often than Windows!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
they know what the score is 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
