What's stopping someone from sending a link, then entering a bunch of fake salaries (by clearing cookies), to find out co-worker's salary (not one of the ones you entered, though they may all appear legit).
I guess one way of combating this is that when you receive an invitation, ask your other coworkers if they received them as well, and ask them to participate. That way, at least the initial wrongdoer wouldn't be able to peg the salary to the person.
Programming "to the metal" is a VERY different experience and one that can be satisfying much in the same way that baking your own bread (flour, water, yeast..) can be.
Now the Gameduino abstracts a lot so maybe it's bad comparison; one is not doing opcode/cycle counting to time refresh rates of NTSC signals!
One of the draws of arduino for me is that it by its very nature invites frankenstein type arrangements of hardware.
Just because this thing is old school tech, doesn't mean the peripherals people connect to it will be. Accelerometers are very popular in the arduino world. It wont be long before somebody manages to get their pets to interact with it somehow as well, that seems a strong meme in arduinoland.
Yes you can interface all these things to a PC as well, but there are many layers of abstraction imposed on you. And you don't get to fashion your own casing out of things you find lying around.
The entertainment value possible in consumer hardware that is produced with no profit motive whatsoever is pretty epic.
I imagine the potential of the arduino analog inputs means you could create some pretty novel interfaces for the games (i.e. beyond joystick and buttons)
Not using a debugger is like giving up a knife and using a spoon to eat your steak. Yeah, you can do it, but why would you? Debuggers are invaluable when you encounter difficult bugs, especially ones related to threading issues. Being able to freeze/run threads at will comes in handy. Setting hardware breakpoints to see when particular memory locations are changing is also useful. Maybe you're just not using the debugger to its full potential?
There is absolutely no point single stepping through code, setting up breakpoints, inspecting variables etc, when you could instead just insert an extra log statement to see what is going wrong.
If your logging is good, often solving a bug is just a case of looking in a production log and seeing where things went wrong.
The other fact is that the majority of bugs I've seen in my own code have been caused when under load, and it's not feasible to run a debugger on a production system.
I've tried debuggers a fair amount, and they end up being completely useless to me.
I assume that statement refers to the amount of noise in question?
Sure, print statements are my normal tool, but often I'm working on transforming one data structure into another (compiler-style) and I'm encountering an error "somewhere" down in the middle. After the first few megabytes of logging output get generated, you start to really lose the thread of what's going on.
It depends on what you're doing. If you're a CRUD programmer, yeah, I can see how they'd be useless; that's a good deal of my job too and I don't use them then. But when I'm actually doing something interesting and twisty I often need them, if only to set some conditional breakpoints somewhere so I can get into the middle of a complicated process instead of trying to reconstruct the state later.
Also they are great for learning libraries by stepping through them.
Logging changes the timing of code making it nearly useless for debugging problems of a concurrent nature. It also falls down when systems cannot afford the overhead of printing all trace data (see: video games), or when embedded platforms have no reasonable TTY to send log data to.
A debugger is just a tool and to dismiss a tool as being pointless for all people is ridiculous. Being familiar with all the tools at your disposal as a software developer is never a bad thing.
Not all developers work on the same sorts of problems in the same way with the same type of time pressure.
Debugging helps you work with code you don't understand. So, the longer you work with the same code the less useful it becomes. However, plenty of coders move from project to project patch up a few problems and then move on.
I would say that logging is fine sometimes, perhaps most of the times but being able to hotswap new code, do a deep inspection of an object (and perhaps some further new evaluation of code that you hadn't previously thought of) comes in very very handy.
Debugging is just another tool. It's not the most valuable tool, but it's also not the least valuable.
At work we rely heavily on logging and trace statements. There isn't even a functioning debugger for our UI language implementation.
I'd say not having a debugger is more like programming on paper. When you have a problem, you might end up thinking about it a little more because you can't rely on that one other tool.
"Not using a debugger is like giving up a knife and using a spoon to eat your steak."
I think it's more like never being taught how to use a knife, and thus eating the steak with your bare-hands, as you've always done. Hands work fine, why learn something new? I have no formal training in programming and it never really occurred to me to use a debugger. I still don't entirely understand what they do for you that you can't do by adding print/trace statements. That said I mostly use scripting languages and don't need to read too much code written by other people...
The debugger, after your brain, is probably the most powerful tool in your arsenal.
They allow you to evaluate state and often see things you'd miss otherwise.
Plus they can do what prints can do, but even easier. I can use tracepoints to print anything at any point in code, including the callstack. The nice thing though is I can turn the tracepoints on and off while never pausing/breaking the code.
Additionally I can attach a debugger to a running process.
Plus with more modern features, like historical debugging), I can go back to predefined instances of time (like a past exception that was thrown) and examine the callstack then.
And the other thing you can do interactively is (a) change the value of variables, (b) change the code, and (c) change the instruction pointer. I regularly do (a) & (c) -- (b) less so. It's a huge time saver when you step over function foo() and realize, hey it didn't set ABC. So then just set the IP back to foo(), but this time step into it.
When I would consult I would often find and fix bugs in a day or two with oode that I'd only seen for the first time, while others had been looking for weeks in code they had helped build. I'd look at their debugging techniques and it was obivous that they were often just not at all efficient.
