As someone working solo on a big project "developer" seems to fit better than just "programmer". In addition to programming I do UI/UX design, feature planning, testing, artwork, and even handle support email. As to "programmer" vs "coder", I can think of a couple of possible explanations. Some programmers are anal about efficiency. Clearly, "coder" is much more efficient than "programmer". Alternatively, given some of the "coders" I've known, it could just be that it's not as tricky to spell as "programmer".

Another vote for MonoGame here. I've been a fan of the XNA API since its beta days and the MonoGame team are doing a great job of extending it to multiple platforms. I'm probably the last person on the planet still actively developing an XNA product. :-) KoduGameLab One thing to keep in mind is that MonoGame is an API and Unity is a game engine. Unity will do a lot of things for you but it will also insist that you do things its way. You will also be stuck with its limitations. For instance, in Kodu I need to be able to support R-to-L languages (Hebrew, Arabic, etc.) None of the UI options in Unity do this well (or at all). Using XNA I was able to roll my own support from this. Yes, it was a pain but at least it was possible.

If you're looking to be able to use C# and DirectX for a Windows Store app the best solution would be to try MonoGame.

1. Exception Handling 2. Reliability 3. Availability 4. Performance 5. Security 0. Well documented, maintainable code. Inevitably you will get 1-5 wrong but without 0 you have little to no chance of fixing the problems.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan

I remember buying an 80387 coprocessor from a forsale posting on Usenet sometime in the late 80's. Does that count as "online"?

I like ConText [^] It's not only useful for general text file editing but also does syntax coloring for a wide variety of languages. And the price is right.

Kevin McFarlane wrote:

Paul Brower wrote: Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. That's right. And a surprising number of interviews ask you to write code at the interview.

I disagree. I think that having a candidate write code can be a good thing. What you have to understand is that it's just as important to see how they approach the problem as it is whether or not they get the right answer. Encouraging them to think out loud as they solve the problem helps. One of my standard questions is the task of writing an Insert function that adds a new node into a sorted singly linked list in the correct position. The problem requires some level of comfort dealing with pointers but should be solvable by anyone with a CS degree or even just a course in data structures. After they've written the function I then ask them how they would go about testing it and what test cases they would use. What I'm looking for here is a set of tests that at a minimum test for adding to a null list, adding the the beginning of a list, adding to the middle of a list and adding to the end of the list. I then have the candidate step through his/her code for each of these cases. I don't expect a candidate to always write perfect code but I do expect them to be able to understand their own code and to be able to see and address the problems they find. A failure on this test was a canidate who advocated test driven development. When ask to come up with a set of test cases for the problem he said he'd test it by writing some test code to throw random numbers at the list and then write some more code to validate that the list was still well formed. Of course he'd also visually inspect the first dozen or so passes to make sure his test code was correct. No amount of prompting could get him to manually set up the test cases so I did that for him. Walking his code through each of the test cases showed that 3 of the 4 cases failed. The process gave me the impression that this candidate hacked at code rather than designed code so despite a great resume he was a 'no hire' for my team. scoy

Thomas Eyde wrote:

I'd say, if you can't read and understand what they wrote (coded), the code is already in a bad state and no comments can save it.

The problem with reading code is what to do when it's wrong. Comments should focus on the intention of the code not the implementation. Hopefully the two will match up.