Am I the only one who thinks the people who put this together knew exactly what they were doing? - tongue firmly in cheek, and a comedy routine that, IMO, sort-of works (not exactly 'comedy gold', but a nice play on the whole geek chic thing that made me chuckle in a couple of places). Alas, and somewhat unsurprisingly, corporate American HQ failed to get the joke.
Teaching sales staff C/C++ is way to deep. Teach them coding concepts but not an actual language.
I should have been clearer in the original posting: I also want the sales staff to be able to use the tool they're sellling. It's a high-performance reversible debugging engine that uses gdb as the frontend (over the gdb remote serial protocol, so no GPL issues). So they're going to have to use gdb (I'm thinking via Eclipse or some other graphical frontend).
I guess we could teach them Pascal or some other higher-level compiled language that is supported by gdb. But there are more and better resources out there for C (e.g. I'm not aware of a graphical frontend for gdb with Pascal). Given all that, and given that we're not trying to turn them into useful programmers but just give them a taste of the problems the tool addresses, I sitll think C is the right choice.
a good programmer can program in any language
No, a good programmer can learn any language: in practice we all specialise in some languages (personally I've found I could always do what I need pretty effectively in either C or Python, but I don't get to do much coding these days). But all that is beside the point: regardless of how many languages you know, you need to pick the right one for the job. I acknowledge that it's highly unusual for C to be the right language for an introduction to programming, in this case I think it is.
I should have been clearer about the objcetive here in my original posting: we're absolutely not trying to turn sales people into engineers, and nor are we trying to find an alternative to good presales support from engineering - the nature of what we sell means engineers are always going to be heavily involved in the process. All I want to do here is to remove a little bit of the mystery from the salespeople's minds of what it is they're trying to sell. (Actually my original draft of the posting said just that but I cut it in the interest of brevity - guess I cut too far.)
Put it this way: a sales person doesn't need to understand what it is they're trying to sell, but it sure as hell helps if they do. Note that I'm talking about how it works, but what it does. i.e. this only matters as we sell a fairly "hard-core" development tool (it's effectively a fancy debugger for compiled languages on Linux). If we were selling almost any other kind of software then I wouldn't dream of teaching the sales team to code. (Actually, that's not quite true: I think everyone should be taught at least some programming (e.g at school), but that's really a whole other topic!)
I totally agree that proper understanding of the code is essential, and all too often people go after the symptoms rather than the cause. But as with most tools, bidirectional/reversible debuggers can be used in good ways and bad. Analytical tools such as this can be of huge help in understanding code (finding out who calls what, when is a prequisite to figuring out why), particularly when working with very large code-bases most of which have been written by someone else.
Slashdot Mirror
Am I the only one who thinks the people who put this together knew exactly what they were doing? - tongue firmly in cheek, and a comedy routine that, IMO, sort-of works (not exactly 'comedy gold', but a nice play on the whole geek chic thing that made me chuckle in a couple of places). Alas, and somewhat unsurprisingly, corporate American HQ failed to get the joke.
Teaching sales staff C/C++ is way to deep. Teach them coding concepts but not an actual language.
I should have been clearer in the original posting: I also want the sales staff to be able to use the tool they're sellling. It's a high-performance reversible debugging engine that uses gdb as the frontend (over the gdb remote serial protocol, so no GPL issues). So they're going to have to use gdb (I'm thinking via Eclipse or some other graphical frontend).
I guess we could teach them Pascal or some other higher-level compiled language that is supported by gdb. But there are more and better resources out there for C (e.g. I'm not aware of a graphical frontend for gdb with Pascal). Given all that, and given that we're not trying to turn them into useful programmers but just give them a taste of the problems the tool addresses, I sitll think C is the right choice.
a good programmer can program in any language
No, a good programmer can learn any language: in practice we all specialise in some languages (personally I've found I could always do what I need pretty effectively in either C or Python, but I don't get to do much coding these days). But all that is beside the point: regardless of how many languages you know, you need to pick the right one for the job. I acknowledge that it's highly unusual for C to be the right language for an introduction to programming, in this case I think it is.
Put it this way: a sales person doesn't need to understand what it is they're trying to sell, but it sure as hell helps if they do. Note that I'm talking about how it works, but what it does. i.e. this only matters as we sell a fairly "hard-core" development tool (it's effectively a fancy debugger for compiled languages on Linux). If we were selling almost any other kind of software then I wouldn't dream of teaching the sales team to code. (Actually, that's not quite true: I think everyone should be taught at least some programming (e.g at school), but that's really a whole other topic!)
I totally agree that proper understanding of the code is essential, and all too often people go after the symptoms rather than the cause. But as with most tools, bidirectional/reversible debuggers can be used in good ways and bad. Analytical tools such as this can be of huge help in understanding code (finding out who calls what, when is a prequisite to figuring out why), particularly when working with very large code-bases most of which have been written by someone else.