How to get the job done 4

[TomKane]

Hello,

I'm not sure if this is the right forum to use, but I'll give it a try anyway. I'm working with someone who probably has the potential to be as good a programmer/support person as anyone I've ever worked with but they don't seem to be able to see this themselves.

What I was wondering was do you have any advice as to how you go about getting the job done - advice like 'never make assumptions - always investigate' anything like that.

Thanks,

 

[Gatorajc]

When you say getting this done. Are they not in IT and you think they should be or They are in IT and you think they are not living up to thier potential. I assume it is the latter but just want to be sure. AJ
I would lose my head if it wasn't attached.

 

[TomKane]

Gatorajc,

Yes, they are in IT.

Thanks,

 

[Guest_imported]

There's one I've always believed - you don't have to know the answer just where to look.

Make sure you know where all your manuals are and how to look up error codes.

Make a point of keeping some kind of notes of problems you've fixed and how you fixed them - a text document will do - a bit of discipline involved in keeping it up to date I'm afraid.

Is this what you're looking for?

 

[Gatorajc]

Maybe Im not reading you right but your trying to figure out a way to motivate someone else right or are you looking about general advice about getting a job done your self.

On a side note. I am also a strong believer in you do not have know the answer just be able to get it. I don't remember anything except the most general of things unless I do it everyday of course. AJ
I would lose my head if it wasn't attached.

 

[BeckahC]

If you are looking to encourage them, you could always do what people did for me... I was not working in IT at the time, yet I was developing a SQL Server DB and front end ASP app with help from a DBA.... What the DBA and my boss did (I wasn't very sure of my skills or anything like that and was always second guessing myself) was they offered me encouragement by complementing me on my work. When I completed a portion of the program and brought it it to the DBA for assistance in the one little part I did not feel I could do, he would comment on how great I did all the rest of it and showed me how and where to look up the answer and apply it to the program. When I brought it to my boss for approval and I tried to give most of the credit to the DBA for helping me get over a hurdle or two, he said I know he helped you, but I also know a lot of this is completely by you and you are doing great.... etc... so they would encourage me, and encourage me and I was worried about coming over "officially" to IT because I would have a new boss and be the little fish in the big sea, but they encouraged me.... now I am not so little a fish and I can hold my own with some of the "big fish", I know how to look things up (I did before, but didn't have the guts to really dive right in and make changes unsupervised) and I put the info to use, I am placed in charge of projects and deliver paperwork and such on my projects as outlined by the boss, etc... so yeah, now I just hear about what I did wrong or what needs to be improved, but them come review time they are right there complimenting me again!;-)

So basically, don't underestimate encouragement!

HTH! BeckahC

 

[TomKane]

Thanks everyone for your advice. I am looking to motivate someone (not myself) but before I just jump in with both feet I'm trying to get some kind of advice from you all before I try anything.

The problem is the person I'm talking about has done some extremely good work in the past and at times I see flashes of how good they are - unfortunately the problem seems to be when there is a problem they can't see beyond the surface - not knowing how to go about figuring out what's wrong - there have been instances where depite knowing there is a problem with a new exe it has been deployed anyway - then the users get on my case.

The cycle seems to be they do something wrong, as a result I become disappointed and as a result of that they become disheartened, etc. I've "cleared the air" and it works for a while, but then the game begins all over again.

I suppose what I'm looking to do is put together some "tips and tricks" things that someone should consider when facing IT type problems (thanks for that SpecialCase). I'm sure there is stuff I can learn out of this as well.

Thanks again.

 

[DonQuichote]

Hmm, maybe some good pair programming might help (see

http://www.extremeprogramming.org/rules/pair.html).

I think there are some useful ideas in the book 'eXtreme Programming explained' (

http://www.amazon.com/exec/obidos/ASIN/0201616416/armatiesA)

Best regards

 

[Gatorajc]

Assuming they are skilled and KNEW there were problems with the program. How big are the problems actual functionality or just minor ones? I will go under the assumption they are minor ones. With these factors I would think he was bored. As you probably know getting bugs out of programs could be quite boring. It is just one of those things you have to do. I do not know how your department structure is or if you have the resources but have someone else QA thier work and have them QA someone elses work. Looking at some elses code you get a different perspective.

Also it looks like your being taken advantage of. If this is a cycle you have to put your foot down. People take advantage of soft bosses. (Something I HATE because I work so much better for someone laid back.)

Good Luck AJ
I would lose my head if it wasn't attached.

 

[TomKane]

The problem I was referring to stopped about two thirds of our users being able to get access to the application (MDAC problem).

You could say I was extremely disappointed particularly as it was known that it didn't work on all PC's it just wasn't known why.

But I still think that if I could get the person to tackle problems rather than sweep them under the rug or whatever - that it could well have a chance at breaking the cycle.

 

[BeckahC]

Perhaps if you speak with them and ask them what the problem is? It sounds like you do have an open line of communication, but maybe s/he is just frustrated or bored (as previously suggested) and is overlooking things while still trying to be productive?

Obviously if s/he is taking advantage than it neds to stop. If they just need a little work on their programming or more specifically their debugging techniques, perhaps there is a class available, or books or something that might be of assistance?

Maybe it is just my positive nature, but I wouldn't assume the negative (that this person is purposely overlooking or slacking off) unless you are absolutely sure that they are not just unsure of themselves or their abilities or maybe need a little extra assistance or training.

I have known some great programmers who just completely sucked at, say, error handling, or debugging, or setting up an aesthetic front end app (but the app works fine, just hard on the eyes), etc... Everyone has a weakness.

(Maybe I am just a softy, but that's JMO) BeckahC

 

[TomKane]

Thanks everyone for your input - I think the problem is primarily two things:

1) That they are unsure of their abilities.
2) That testing is a chore/punishment.

I put together a list of things that I think are important (I used some of the stuff from this thread) what do you think?

Thanks again...


Never make assumptions. A bit aspirational perhaps, but you should never assume something works the way it does without checking it out first. Checking could mean looking at the code, looking at the manual, testing, or asking someone (that could mean users). The more you know about a problem to begin with, the better equipped you are to deal with it.

You don't have to know the answer, only where to look. Make sure you know where all your manuals are and how to look up error codes. The System Administration manual has a list of EFAM error codes, The Application manual has a list of Application errors. There should be a 'Status Codes' help file in your Pervasive documention menu.

Make a point of keeping some kind of notes of problems you've fixed and how you fixed them - a text document will do (I think you made a start on one some time back) - a bit of discipline involved in keeping it up to date however.

There are 1000's of entries in our call logging system at this stage - it couldn't hurt to do a search on it every now and then to see if an error code you may be getting turns up in there - even if the detail is a bit sparse - you should be able to figure out who raised/resolved the issue and ask them.

If in doubt, that is, if you are unsure whether or not to go ahead with deploying a new enhancement into the production system then don't do it. At the very least explain your concern to someone and get a second opinion.

Testing is everything - always test - it can be dangerous to assume that even a small mod will be OK to go in - if there are system test cases in place then you should use them

I didn't tell you this one - but try to manipulate the new procedures where possible - I bought you an extra week for testing of your current project (sign offs) and when you did get around to doing the system testing you found a bug. If you can take advantage of a "loop-hole" then you should.

 

[Gatorajc]

I think its definitly the second one, it is a chore but like doing the dishes and cutting the lawn at home it has to be done.

I like your list. Gave me some ideas. Im really bad about commenting and notes. AJ
I would lose my head if it wasn't attached.

 

[CajunCenturion]

I think should try to teach Problem Solving Skills and to develop of methodology that everyone should adopt in the determination of problems. The biggest weakness of people in our profession is that we do not have good problem solving skills, and when you get right down to it - every program we write is to solve some sort of problem.

Nothing can be more satisfying and motivating to a person than be behind the solution to a problem. I try to approach every programming task as a problem solving task.

First - define the problem - and this is not as easy as it sounds. We need to have good diagnostic capabilities. We have to distinguish between symptions and problems. For example, lets say I have a problem with a "Stack Overflow Error" - Is the Stack Overflow my problem? NO - its the sympton of a runaway recursion.

So, help your staff distinguish between symptons and problems. That will almost always result in you having a list of symptoms. That's okay. Now do thru each sympton, and make a list of every possible cause that can lead to that symptom. Now that you have a list of causes, start eliminating them, either thru logic, or direct testing.

I think that developing Problem Solving Skills, and practicing these skills will lead to better quality solutions. And treating the staff as the company problem solvers can lead to internal satisfaction and accomplishment. Don't let your staff write a program to build an e-commerce site. Let your staff write a program to solve the companies problem of not being able to expand is selling capacity. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[xandroid]

I only skimmed the other replys. I think they are all barking up the wrong tree.

Here is some advice. Look up what the Socratic Method is. Basically it is teaching by asking questions and not by telling. It's strenght is that you try by asking the right questions to let people discover things for themselves, to work out the solution with their own intuition and not anyone elses. Then there is a great sense of ownership with the solution or answer and certainly strong buy-in because after all it was their idea. Now you must learn how to do this without giving too easy of clues. You must learn this for it requires you to be able to recognized one approach or angle isn't working, the person isn't relating to it and you must find another path there, another approach from a different angle, and when you become skilled enough and perceptive enough you will begin to see what angle that might be more readily.

Now that's not all. The is another thing you must learn about people, especially in the work setting. I'll just leave you with this "Tell me how they are measured and I will tell you what they will do" What's their incentives.
A manager or supervisior must set the incentives properly.

But remember this too. Just because you might think another person should be something doesn't mean that person wants to be that. What's wrong with asking the person what they could be if they could be anything they wanted to be. Then with that done you'll have some insight on what you might be able to do in reality. If you study The Theory of Constraints, you can learn how to construct completely logical current and future realities.

Good Luck

Andy

440-327-3093

 

[CajunCenturion]

I think they are all barking up the wrong tree. Pretty strong statement from someone who only skimmed the replies.

With respect to the original question, one thing that I would not do, especially when trying to build up the members of my staff, is to be critical of them without giving the ideas due and proper consideration.

ALL of the ideas presented, including yours Andy, have merit and when used properly and together, will achieve the best results. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[TomKane]

I'd almost forgotten I'd posted this thread. I think the intention was good but the reality didn't work out the way I'd hoped. My list of stuff was considered condescending and largely ignored. If anything things got worse. I don't work with that person anymore - we work on separate projects for the same system.

Andy, I will look at The Theory of Constraints and what the Socratic Method is. For my own benefit if nothing else.

 

[CajunCenturion]

The Socratic Method is a teaching method, where the teacher asks the questions, usually leading questions, to bring the student down a pre-determined path. As you might guess, this teching technique has been around for a very, very long time, named for its initial user. When it works, the "teacher" already has a general idea of where you're going, and is asking the kinds of question so that the student, thru the answers (and the thought process to arrive at those answers), brings him/herself down that path. Although it can be very effective in the classroom for certain types of subjects, those generaly of a subjective nature, it can often fail in the business environment for several reasons. It takes time, it put pressure on the student, it can establish an student-teacher relationship, and can very easily come off as condescending and/or patronizing. The key point is that it is a teaching method, it is not a management method, or supervisory techniquie. Teaching is part of the job and so this technique is good to have in your bag of tricks, but only use it when its appropriate for the situation.

The Theory of Constraints is a Project Management tool which deals with the Time value of money as it relates to projects that have built-in uncertaintaies, and having to balance schecdule, budget, and functional requirements (sounds like a software project to me). Rather then try and write a thesis here to explain it, I suggest the following reading:

http://www.goldratt.com/tocpmwp1.htm

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[TomKane]

Thanks for that