If your son's interested in games, definitely use that to your advantage. I got into software development because of my love of games. My first language was Dark Basic, a Basic derivative for game prototyping. I loved it. Get him a physical book. Online tutorials are great and all but physical media can really help you focus. He can take it to school and reed it in his down time, he can pick it up if the internet goes out, he can read it on the toilet, whatever lol. Unity, as someone else mentioned, is a pretty good choice though it may be a bit complex for someone just starting out. Gamemaker would teach your son more about game development, than it would programming but it's not a bad choice. I always recommended to my friends growing up that they try to make a text based game as their first goal; that way you don't have to learn any graphics, sound, controller, etc apis. It's just simple logic and prints to a console. Could be a number guessing game, or a full blow text-based rpg. I'd recommend anything with console support (which is just about every language.) Python has console support, he could take that project and use pygame to turn it into something more later on. C# has console support and it's used to back Unity programming, so it would be relevant for him to learn. If he's interested in animations, flash is still a thing I hear lol. Those are my recommendations.

All I can think of is this episode of a flash cartoon that no-one's probably ever seen: https://www.youtube.com/watch?v=UNzvnByj8vk[^]

Marc Clifton wrote:

Of course. And the irony is that I get put into a cubicle with three other people, each from a different nationality, we never talked, English wasn't a particular strong suit for them. The concept of "getting to know the team" is a crock of sh*t in the majority of cases because the company does nothing to foster this.

Wow, what kind of crap jobs are you working lol? I guess you mostly work in corporate settings, yuck. If you could take a hit to the salary, I'd recommend a startup. Lots of freedom, everyone's close on the team, and (depending on your startup) they don't care if you work from home 3 out of 5 days a week.

Marc Clifton wrote:

This watered-down politically correct BS we have to live with today simply means that people can't say what they really think

I said "get over it" not because being racist is "wrong," it's just pointless and unhealthy. You're stressing yourself out because these people calling you have an accent... There's no *benefit* to being a little racist, so try not to let it get to you.

I make 45k in a Lead role on the east coast. West coast is where all the high salary gigs are. Though I am still making a startup salary.

1. + "I'm disgusted with this dehumanizing industry." == irony. Employers want you on site because being there in person allows the team to get to know you. You've been doing this 33 years and haven't figured that out? *You* are the one who doesn't want to be around other people while you work. Who's dehumanizing the industry here? 2. That's a little racist; though I find my self not returning calls to recruiters that I can't understand. The US is the melting pot, people have accents. You should get over it. :P 3. Because the people with Ruby on Rails experience are rarer than those with .NET experience... simple supply and demand here... 4. I make 45k as a Lead Android developer so I don't really want to hear your complaints on 75k/90k. That number also means different things in different parts of the country. EX. 75k in sanfrancisco would be practically unlivable. Here in North Carolina, it would be a decent salary. Last. Don't use Monster if you want an IT job. Use Dice. (Or craigslist if you want a startup but from the looks of things, you probably couldn't handle a startup salary.)

"My payoff: A raise to a salary that is only $12K less than average for an engineer with a third of my experience, instead of $24k less." D: A 12k pay bump? Man, I make 20k less than the low average for entry level programming. And I'm the team Lead! Wish I could do a project for a 12k bump, but it's kinda hard with a startup. XD

+1 Completely agree. My first day at my current job was my first day as a software developer (at least professionally.) I had to start a project entirely from scratch, by my self, using some technology I didn't even know at the time, and try to keep up with the other platform's team that had 2 developers, one of which worked at fidelity for 20+ years, with a head-start and a similar project to pull code from.... I was panicing for a little over a month. XD Eventually I calmed down and took it one feature at a time, focusing on small tasks instead of stressing the bigger picture. It's now a solid product. :)

1 & 2 : Looks like you've got some work to do. Try not to freak out and just focus on what they *really* want for a workable prototype (they want everything done; you need to decide what's critical.) 3 : Prioritize the list. Work on getting a solid prototype out first, cutting features that the buggy version may have already had. All they are going to care about is seeing progress. If you don't have *something* to show them every now and then, due to you trying to tackle the whole project at once, then they are going to wonder if you're doing anything at all. 4 : This is why you need to have *something* to show him. He doesn't understand the scope or complexity of what you're doing so try to appease him by showing off what you have working and explain how it's *better* than the previous version (in simple terms; ex. "Fixed some bugs, it's a lot faster, and look at this new feature.") 5 : That's programming though, solving problems. Research the business til you understand it or you'll never be able to provide a decent solution. Find someone nice in the company to explain it to you if you can. 6 : We're here, you also have stack overflow, or you could make a blog and try to get people collaborating in the comments. Obviously, not everything you do can be shared outside the company, but if you abstract the problem, then you should be fine.

The silliest part, of course, is the entire subject is subjective; there is no metric for wether Hungarian notation is good or bad. There is no performance difference in prefixing your variables. Each person's ideas of what's more maintainable is different. It's like the curly brace placement debate all over again. XD

You have to take what I said in context. This is about UI objects. I'd say the majority of developers working with UIs are not working on third party libraries. I also can't think of any good reason to directly use a third party library's UI variable, as anything of this nature is typically scoped (why would you have a public variable for a text box that your library is responsible for when you could keep write acces to yourself and provide read access via a getter in the off chance the party using your library needs it?) I suppose if you're using someone's library of custom UI views you may find issue here, sure, but that's not often done; such code is not likely to change the data type of the variables anyway as they are abstracted to suit the needs of everyone (ex. a third party library that has a pull down to refresh list view for android is not likely to suddenly change the list view to a scroll view.) There are of course exceptions to all generalized statements like the ones I made, but honestly, in context, do you see renaming a UI variable as being an issue? UI objects are typically obfuscated in libraries and within your own code, you can easily rename the variable.

I guess I'm going to have to disagree with everyone here. What happened to verbosity being a good thing in software development? Prefixing variables referencing UI objects makes your code more self documenting. I know that txtFirstName is an editable text box and firstName is most likely just a string. If you remove ui prefixes, all bets are off. You no longer have any indication as to what a variable's type/implementation is without either scrolling up to its declaration or hovering over the variable in a compatible IDE. The argument that changing the type of the variable is difficult is largely not the case anymore. The modern IDE has *at least* find and replace, and most have a right click -> Refactor -> Rename option. Should we really sacrifice self documentation for the off chance that a text box reference will be changed to a label?

10 months and counting, though this is my first programming job. ^^

Sounds like a good deal on *your* end but he could be a terrible developer, the game could just not be what you want, or you could lose money because it's not profitable. Why are you using elance for game development anyways? Why not be a part of the process? Get a team of free monkeys from gamedev.net to make you a prototype at least. There's a sub-forum for posting projects and hiring developers. You'll at least know if your idea makes anyone excited before you dish out 4k.

Does it run if you hit the green arrow at the top? If so, just right click your project and export it Export -> Java --> Runnable Jar

Fair enough. Thank you for your input. ^^

So it seems that the fact that one candidate comes from a corporate background and one comes from a startup background is largely unimportant to you; you care more about how the individual fits into the team. But what about that initial step, before you meet the individuals. How do you weed out potential applicants? Do you take into account the type of company a person has worked for during this process?

It depends on what you want. You could, for instance, let the user draw the curve, extrapolate control points from the drawn curve (aka x,y positions that the mouse went through), and then use them to calculate a smooth curve. Or you could have the user draw a line, then click a point on that line to create a control point and allow them to move that point. I've seen both.

Our lead programmer worked at Fidelity, so I trust he wasn't just blowing hot air. XD I'm sure it can be stressful anywhere. I programmed for 6 hours in a car ride the weekend before launch, which was unpleasant to say the least (it gave me motion sickness and a bad headache). I'm sure others have worse stories.

So in your case, do you actively try to keep your team balanced? Say you feel your team is slowing down, so you decide to hire someone new. If you had two identical candidates, one with startup experience and one with corporate experience, would you be more inclined to hire the startup candidate to benefit your team's speed, or does it not really come to mind?

Right, but does this actually come to mind in the hiring process or does HR just see X years of experience. I'm curious as to whether anyone has treated a candidate differently based off of the type of company he/she worked for.