1,182 karma · joined November 22, 2008
When teaching kids a few years older, your world really opens up in terms of tools you can use - I think a motivated 13 year old should be able to grasp any one of a number of different programming languages and/or different paradigms.
One of the issues with teaching younger students has to do with the immediacy of results:
Something like "Scratch" has a simplified programming model (visual drag-and-drop programming to create interactive animations), but gives immediate results that you can see on the screen right away, and it's impossible to create a syntax error.
When you teach a "friendly" programming language like Basic or Python, there's still a decent amount of background material before you actually create something visually cool. So, while a 9 year old might get bored and start to loose attention, I would expect a 13 year old to have the patience and persistence to know that the cool stuff (ie, making a simple video game) is on the horizon. He/She will continue to plow through the boilerplate.
When you go to Java or C, it requires all the more motivation, because the background information is that much more difficult to ignore. Syntax is much trickier. API's are less friendly to new coders. It takes more time and focus to create the result you're looking for, especially if it's graphical.
That was my thought process that eventually led me to choose Scratch as the way to introduce the students to programming in our computer programming club.
Why do you think that's true? Is that just a gut feeling, or is it based on some logic that you did not include here?
To be clear, it is far from obvious to me that what you say is true. It seems to me that change from within could potential work, despite the events of the last ten years.
If anyone has experience teaching kids this age programming, or if you know of any resources available, please let me know. This is a new experience for me.
This is unprecedented because it's simply not true. The best statistic I could find for this is 11%. Even 11% seems like a very high number based on my personal experience. As an American who has lived in different parts of America my whole life (and currently living in a high-tourist city with people from all over the US), I can say that most people in most parts of the US do not believe that the rapture will happen within their lifetime.
http://www.publicpolicypolling.com/pdf/PPP_Release_US_0602.p...
I work with back-end systems; most of my experience is with C, C++, and Java. I can work with most technology stacks, though - it's the application that interests me.
I have experience with telemetry and data analysis for avionics and medical devices. I feel at home with large data sets.
I'd be happy to work remote or travel to your site.
You can see my resume here: http://ctbaldwin.com/resume.pdf
Some handsets can't be fully powered down without removing the battery; for instance, some Nokia models will wake up when turned off if an alarm is set.
I'm not so sure that this is still a common practice for modern phones.
If the problem is really serious, it could be a medical problem called Raynaud's Syndrome.
Jeff Bezos - From Amazon.com to Blue Origin
Richard Branson - From Virgin Records to Virgin Galactic
Robert Bigelow - From Budget Suites to Bigelow Aerospace
Elon Musk - From PayPal to SpaceX
I'm hoping that this is just the beginning of a trend of successful businesspeople investing in humanities' future in space.
However, it sounds like the organization in question was not deploying to Windows - from the article:
...it seemed to me that most of your development happens on Windows (though it’s almost needless to say that you deploy to Linux)
I won't judge you for using Windows over Unix (even though I prefer Unix), but I will judge the choice of using Windows for development when you are targeting Unix. I have had this experience, and it was a Management decision - not an Engineering decision, and it resulted in significantly less productive work environment. Given two opportunities that are otherwise equal, I would definitely choose the company that develops on the same platform that they deploy on (assuming we're talking about Unix or Windows - there are obvious exceptions in the embedded world).
One caveat: It is common for an organization to use both Windows and Linux for different tasks. In that case, the choice of development environment is more complicated.
Either way, I'd say that the candidate should have asked up front during the interview, "Why are you using Windows for development, and could I use Mac/Linux instead?", instead of judging them based on what seems like a lack of information. They may have a good reason. If they don't, your decision is that much easier.
1. Desktop computers are any land animal
2. Laptops are birds
3. Virtual machines and servers are any water dwelling creature
I try to progress through the alphabet. For example, "Buck" is an old, now defunct computer - "Gila" has only recently been retired.
To the OP and anyone else interested in the North Side of Chicago: I don't think you can go wrong anyplace near the lake between Downtown and Irving Park Rd. It's all beautiful; plenty of grocery stores and Dunkin Donuts'.
Holy Shnikes, that's a tough one to parse! I wasn't sure what you were saying here, so I'm gonna break it down, working from the end of the sentence:
1. I'd be lying if I said I don't doubt you are not incorrect
2. I'd be lying if I said I don't doubt you are CORRECT
3. I'd be lying if I said I don't think you are INCORRECT
4. I'd be lying if I said I think you are CORRECT
5. I think you are INCORRECT
The idea is that each of the previous statements are saying basically the same thing; I'm just cancelling negatives each time. Anyway, am I correct to assume that you think that the GP is incorrect?
It seems unreasonable to expect others to provide sources when you don't source your own information.
1. You have to figure out what you need to build.
2. Engineer the solution in such a way that changes in the requirements result in relatively minor changes to the code.