Chief Delphi - why blame the programmers??

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - why blame the programmers?? (http://www.chiefdelphi.com/forums/showthread.php?t=84922)

Re: why blame the programmers??

Quote:

Originally Posted by tsa256 (Post 947556)

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

Ditto. It's so much easier to combine the two.

Although 60% of the time it is electrical, so I can't really complain too much.

Re: why blame the programmers??

Programmers in this competition are not real programmers in its true form. I would consider them electrical engineers as they are typically responsible for developing/interfacing the software and control systems to the hardware, which is typically built by the rest of the team. They are really the most critical member of the team. Without them the hunk of metal and plastic does nothing.

Like the real world, this person (usually only one) has the least amount of time to do their job because the hardware team went way over schedule to do the build.

Some helpful hints to keep the electrical engineer happy:
1. Don't ask the electrical engineer while they are programing DID YOU GET IT WORKING yet. It gets real frustrating after you get that question every two minutes from every team member. You will know it is working when you see it working.

2. Don't ask what are you doing when it looks like we are doing nothing. More than likely we are compiling or downloading the program to the robot. Or we are in deep logical thought on the best way to program and one question might just ruin that thought.

3. Don't take the robot from us while we are programming to make a tweak say it will only take two minutes, keep it for three hours, then ask us at the end of the day why it wasn't done.

4. If you want to learn how to program don't ask for someone to teach you in week 6 of the build.

5. Don't blame the electrical engineer/programmer for all the robot's issue. Just remember when you are pointing the finger you have three more pointing back at you. From my experience that is about the correct ratio of blame. Typically we only get 20% of the time to do 80% of the work. We get blamed for 80% of the problems when only about 20% of them are the programmers fault. Good old 80/20 rule.

Kidding aside,

If you are one of the electrical engineers, find a way to program and test without the hardware. If you don't have a spare robot the best method is to do a bench setup. Find a large table, get all the electrical components, tape them down and wire them up. For this setup use the smaller motors and attach a tape flag to the shaft so you can visually see the direction they are turning. Start programing.

Good Luck.

Re: why blame the programmers??

As programmer I often get blamed with a lot of the errors on the robot. I find myself remembering what was said in Billy Joel's song Vienna "You know when your wrong but you don't always know when your right". I don't mind getting told that I messed up, because I probably did. What irks me is when I ask someone to check a system on the robot because I think it is electrical or mechanical and the rest of the team refuses to take five seconds to check, as well as prevent me from taking 5 seconds to stand up and look. That is without a doubt my biggest pet peeve of being a programmer. If you tell me I screwed up I'm more than happy to check, but that means that you should be nice enough to check when I say you screwed up. XD

Rant achieved.

Re: why blame the programmers??

If the code worked once, it will always work unless it has been changed, or something physical has changed on the robot - in which case it's mechanical problem, not programming....

Re: why blame the programmers??

Code:

import time

time_code_was_changed = time.time()



if robot.is_changed() and robot.time_was_changed() > time_code_was_changed:

    print("Mechanical")

else:

    print("Programming")

Re: why blame the programmers??

Quote:

Originally Posted by riptide (Post 1005603)

Like the real world, this person (usually only one) has the least amount of time to do their job because the hardware team went way over schedule to do the build.

Technically, if you are actually doing it like an actual control engineer would do things you have plenty of time. In all seriouness you shouldn't need the hardware to program the software. You do need the hardware to actually verify the programing is right but that should come after the robot is built.

Quote:

Originally Posted by wireties (Post 947621)

And because the mechanical guys can't get it through their head that the robot itself is part of the servo feedback. The software can't be fully tested w/o working hardware - the gyro does not work while the robot is shaking itself apart - etc, etc, etc Classic comment: It works perfectly on the stand but not on the ground!! It has to be a software problem. Hehehe...

Once again. You should be able to figure out if the robot is going to shake itself apart long before it was actually built. Its a bad design process because you are risking having the robot rip itself apart to pieces. I always wonder why this sort of behavior gets by in a competition that is mentored by engineers. There isn't a single field of engineering that doesn't actually design their control systems like this.

Re: why blame the programmers??

Quote:

Originally Posted by iv1777 (Post 1007122)

If the code worked once, it will always work unless it has been changed, or something physical has changed on the robot - in which case it's mechanical problem, not programming....

That's a personal favorite of mine: The robot was working two hours ago, no code was changed, and now it's stopped: Clearly programming. At the '09 competition our feeding mechanism stopped working at times during the competition, and the coach kept coming back to me to "fix the code". On day three, we found a weld that was spaced 1" farther apart at the top of the robot than it should have been, completely stopping the part from functioning. Funny how that worked out.

Re: why blame the programmers??

This reminds me of one of my first days in my job right out of college....

My lead went up to me and said half serious and half jokingly, "The most important thing to do at the start of a new project is to determine to whom to assign blame when things go wrong. Unfortunately this will have to be you!"

So really programmers you need to get on the act early and get the team to assign blame to mechanical earlier!!!!

Other great sayings.. "Don't worry we'll take care of this" "We" being the "Royal We' meaning X teamate will take care of it not me!

In all seriousness he was the best boss/mentor I could have had coming right out of college.

Re: why blame the programmers??

i say if the programers are getting blamed they send the blame too the build team or electrical instead

Re: why blame the programmers??

That doesn't work, they say we're trying to blame them for our flaws and tell us to fix our code.

Re: why blame the programmers??

the only people who blame the programmers are electrical. when they screw up the wiring.

Re: why blame the programmers??

I've determined that all problems are mechanical. The programming is only an abstract idea without hardware and the hardware implements the programming, so everything is the fault of the hardware.

Re: why blame the programmers??

Today, I greased the gearboxes and tightened the chains on our robot because one side was slightly faster than the other, which is obviously a programming issue.

:rolleyes:

Re: why blame the programmers??

Why do all the electronics accuse the programmers.
Electronics are just looking at the diagram and plugging the cables in.
That's all they do ..:yikes:

Re: why blame the programmers??

Quote:

Originally Posted by cilginbilgin (Post 1008586)

Why do all the electronics accuse the programmers.
Electronics are just looking at the diagram and plugging the cables in.
That's all they do ..:yikes:

Electricity is a confounded thing you know. Especially since not everything conform to the same standards. Like how a set of wires provided for one sensor has a completely different arrangement and color meaning compared to another.