why blame the programmers??

[Egg 3141592654]

I, being the ONE programmer on our team, know your pain. There are three main reasons why people love to pick off programmers.
1. Code isn't physical, aka nobody can see you fix it, and nobody except for programmers can fix it.
2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)
3. Strength in numbers, It is easy to blame 1 or 2 people then a whole mechanical section, or electrical section.

It is really too bad programmers are placed in this situation, i mean, they're just as important as any other section of a team.

[ideasrule]

Originally Posted by Foster

Great,what did you do to fix the lag? We had a lag problem at FLR and ended up pulling the vision code.

That lag problem was because the code was, contrary to my expectations, saving files to the cRIO. The cRIO filled up and the robot became extremely laggy.

Another lag problem we had at the Waterloo regionals was because we used a pool noddle to fix the camera in place, and the pool noddle was pushing against the camera's reset button.

[billbo911]

Three thoughts:

1) Without good mechanics, programming doesn't mean squat.

2) Without decent programming, even incredible mechanics means nothing.

3) Why fix blame? Find the problem and work together on a solution!

[NorviewsVeteran]

Originally Posted by billbo911

3) Why fix blame? Find the problem and work together on a solution!

We would, but the programmers have to fix the code first.

[davidthefat]

Originally Posted by Egg 3141592654

2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)

Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... Sometimes I feel like I am the only programmer...

[ideasrule]

Originally Posted by davidthefat

Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... Sometimes I feel like I am the only programmer...

Yeah, programming anything in teleop is really simple. The hard part is always autonomous, especially if you're planning to use vision.

[RandomStyuff]

I guess I'm lucky then. In my team there is full understanding by all teams of the other teams. The mechanical is easy to understand, and the programmers understand the mechanical. A quick course on the electrical was given by me to all team members just before the start of the season (electrical is in programming team's turf here, although it's pretty much a cooperative thing).

The thing that makes my team slightly special is the understanding of programming: my school is called Aleh High School of Sciences, and as you can guess from the name, it's a pretty geeky school, where around half the students study computer science. As weird as it may seem, this year all of the 12th graders in my team except for one (our connectivity manager) major in Advanced Computer Science which includes in it a couple of university level courses. Next year, the two leaders of the Mechanical team are also Advanced Computer Science students, and the management will again be made up of almost exclusively Advanced CS students, with the only blacksheep being a girl who is doing the normal Computer Science course (cause she couldn't fit the advanced one into her schedule without taking out Chemistry or Physics)

The end result is a team which not only understands what code is, but can actually read it. This year when both my number two and I were gone for a few days during the season, a 12th grader from the Mechanical team came and took over temporarily in making sure the code is done. Our Mechanical manager even sat with me and helped me debug some code during a free hour once.

That doesn't always help though: we have a running joke that I'm probably to blame for (seeing as at the start of the season I was sure our programming team could do anything we wanted (which isn't too far from truth, we got the Innovation in Control award for some pretty awesome algorithms we implemented with our camera and and other impressive things like rewriting half of the WPI-libs stuff, including the low-level, and writing our own accumulator, to be able to get 3 gyros working on the robot.)). Every problem that comes up our Mechanical team's manager shouts "They'll fix it in software."
The climax came three hours before the shipping, when we discovered our scale was mis-calibrated, and that we were 7 kg overweight. Our mechanical team manager again shouted that we'll fix it in software (technically, if you write all the unused 0s into 1s there needs to be a positive charge, therefore the electrons leave for the battery, saving you the weight of an electron for each one.... sadly, the maximum you'd be able to save is about as equal to 1/10,000th of an atom... some bored kid did the math).

[efoote868]

[sarcasm]The key to success is knowing who to blame for your failures.[/sarcasm]



If its the first time after the programmers touched the robot, it very well could be the programmer's fault.

If its the first time after the programmers touched the robot and its the first regional competition, it probably is the "programmer's fault", but its also the "team's fault" for not letting the programmers have access to a fully completed robot during the build season.

If its during the tenth match at competition and everything was working fine for all the other matches, and if the code didn't change between then, there is a high probability that it is NOT a programming fault, and it is electrical / mechanical.


I remember back in 2008 we had a solenoid that wouldn't work properly. We went from both ends of the spectrum - mechanical (replacing the solenoid) and programming (printf's in code to verify everything was as expected), followed the wires and met in the middle. Seating PWM cables in spikes are a real pain, this one jiggled out so it was only contacting two pins out of three. The spike would blink green-orange, but never go red.

[Mrs.Drake343]

Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.

[exprg:melonhead]

programmers get blamed only because it's so easy to say that what you are working on is flawless. for me, the first to blame is electronics whether it's right or wrong! if you don't understand it, it's easy to believe there is something wrong with it. simple as that.

[thefro526]

People tend to blame things they don't understand... Most non-programmers don't understand programming, therefore they blame it for any problems they can't solve.

Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

[Mark McLeod]

Originally Posted by Mrs.Drake343

Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.

I assume you do the same to your mechanical crew of course?
I'm firmly of the opinion that mechanical engineers and build crew should be shot at the end of week 5...
Only pit crew should touch the robot for maintenance purposes after that...

That never happens though.

[exprg:melonhead]

Originally Posted by thefro526

Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

thank you Fro! it amazes me that things that happen behind the curtain of building the robot can be taken for granted. my team just assumes that the robot will function properly. if they push the joystick forward, they expect the robot to move in that direction. i personally believe that the code is half of the robot. like you say, without it, you can't move. but to go from the other end, i take the electrical and mechanics for granted as well. generally, if we have the idea, i expect them to build it, and as soon as they do, i code it before we run the bot again. so i guess i'm kinda inversely guilty

[FRC4ME]

Well, the programmers get blamed more often because, objectively, code error are responsible for more problems than mechanical errors.

But that's not really the programmers' faults. A recurring theme I've heard (and experienced) is that the builders will spend five weeks, six days, and twenty-three hours building the robot, then turn it over to the programmers and say: "alright, now download the code. What do you mean it doesn't work? You had six weeks to work on it!"

Unfortunately it doesn't quite work that way.

[PingPongPerson]

At least on my team, it's becuase when the programmers are testing the drive, they usually smash the robot into a wall at least 5 times.