Bjarne Stroustrup On Educating Software Developers 538
jammag writes "Bjarne Stroustrup, creator of C++ and a professor at Texas A&M, weighs in on the problems in today's CS programs. In particular, Java (there's too much of it), the quality of graduates (companies aren't happy), and the need to balance the theoretical and the practical (long overdue). Not pulling punches, Stroustrup even talks about high schools — 'High schools could teach students to work hard at something (just about anything), to search out information as needed, and learn to express their ideas in writing and orally.' He finishes by giving advice to working developers: 'Serious programming is a team sport, brush up on your social skills. The sloppy fat geek computer genius semi-buried in a pile of pizza boxes and cola cans is a mythical creature, best buried deep, never to be seen again.'" Read on for more choice quotes from the quotable professor.
I have even had questions from strangers in airplanes: "You're a professor? In software? Have you got any students? Here's my card."
The US industry could absorb more good developers than there are currently students enrolled in IT-related programs — but not all of those programs and all of those students would qualify as "good" in this context.
The companies are complaining because they are hurting. They can't produce quality products as cheaply, as reliably, and as quickly as they would like. They correctly see a shortage of good developers as a part of the problem. What they generally don't see is that inserting a good developer into a culture designed to constrain semi-skilled programmers from doing harm is pointless because the rules/culture will constrain the new developer from doing anything significantly new and better.
The contemporary Math, Physics, and Biology books I have seen are far, far more conceptually challenging than what we present to CS and engineering students in the area of programming.
I think the ultimate aim is to make programming more of an engineering discipline, more mathematical or scientific; "craft" and "art" are both needed, but there ought to be a scientifically based core on which people can base their craft and art. Software design and implementation is more than a craft; there is more math, science, and engineering to know and apply than is customary for fields we call "crafts." Incidentally, I find it appalling that you can become a programmer with less training than it takes to become a plumber.
The companies not happy with grads is pure BS. (Score:5, Insightful)
Unless you finish that sentence..
Companies are not happy with the fresh coders because the good ones wont accept the low salaries they offer.
Sorry but Programming is HARD. you gotta pay a lot for a good programmer. That will not change.
I am sick of corporations and companies making up this raging BS story about a lack of candidates. RAISE YOUR SALARIES AND THOSE CANDIDATES WILL APPEAR.
Good point (Score:4, Insightful)
Re:Better English education as well. (Score:3, Insightful)
/unpedant
Quote is also a noun. I'm sure you meant to say, "Read on for more choice quotes from the professor."
Stroustrup on Java is like Bill Gates on Linux (Score:5, Insightful)
Bjarne Stroustrup, creator of C++ [...] weighs in on [...] Java (there's too much of it)
Oh, gee, now THAT is a surprise!
Re:He sure thinks a lot of himself (Score:4, Insightful)
Someone can learn the basics of a lot of programming languages, but not know the fundamentals well. What a university should provide is a solid foundation. My education included chip design, compiler design, assembler, and other low-level topics that I never use on a daily basis. But studying them at the university level definitely makes me a better programmer.
Re:Sales Pitch For His Product (Score:1, Insightful)
Re:Is coding really a team sport? (Score:5, Insightful)
Coding can be a hobby, in which case sure, you can do it alone (though for significant project, it gets rough, with all of the cross cutting concerns... someone who's extremely good at algorythms may totally suck at designing a public API... fairly common in CS-heavy companies that do a lot of backend stuff).
I'm guessing though, they were referring to coding in the real world (for a living), in which case, for anything significant (no, the ecommerce website someone makes as a freelance isn't significant), you'll need to be a good teamplayer. People who are good at making functional GUIs often suck at backend programming, and vice sera. People good in architectures often miss the details. Computer scientists often cannot understand project managers and architects. Thus, it becomes a team sport (like you'd have goalers, offense, defense, etc). Being able to work as part of that team is almost as possible (sometimes moreso) than just being good at your specialty.
Conflicting goals (Score:5, Insightful)
I think the ultimate aim is to make programming more of an engineering discipline, more mathematical or scientific; "craft" and "art" are both needed, but there ought to be a scientifically based core on which people can base their craft and art.
We all know that we get to choose two of the three, problem is companies want all three without any consessions.
Also, imposing rigor on software design increases time and in certain situations cost, while increasing reliability. While we are definitely heading in the right direction as a field; there is a long way to go before we ever get to any kind of discipline that is both as rigorous as other science or engineering disciplines and usable on the scale that people currently expect software to be at. Real customers by and large can't (although some cases won't) pay for rigorous development. Hell, the mentality has been creeping into consumer electronics as long as I've been alive. The current market drives us towards fast and cheap and only towards reliable if the customer is pissed.
PHBs take note, please? (Score:5, Insightful)
What they generally don't see is that inserting a good developer into a culture designed to constrain semi-skilled programmers from doing harm is pointless because the rules/culture will constrain the new developer from doing anything significantly new and better.
I almost stood up and cheered when I read this, until I realized that nobody who can change things is reading, and besides I would have disturbed the other cubicle rats.
Re:Back To Reality (Score:5, Insightful)
Re:The companies not happy with grads is pure BS. (Score:5, Insightful)
I've never known this to be the case. When I managed developers, I paid market rates which I am sure you would say are low. I never had a single offer turned down for salary considerations. I had a range of programmers from good to excellent. Expectation of higher salaries was not correlated with skills or performance at all.
You are right: programming _is_ hard. But salary is only useful as a motivator up to a point. Beyond that, what good programmers want is respect, appreciation, and freedom to do great things. They want to work on stuff that they feel good about. They also want to work with other smart people who they can learn from and build great stuff with. Those are decent starting points anyway.
So your general idea is right: that complaining companies are full of it, but I don't think it's because of money. It's because they have lousy uninspiring development environments.
Cheers.
The problem with C++ (Score:3, Insightful)
The real problem with C++ is that it keeps changing all the time. I learned C++ around 1995, shortly after learning C, and it was pretty simple and straightforward. Sure, there was the template annoyance, but nobody used them so it didn't really matter. Now it's some strange bastardized beast with lots of syntax that's not even remotely derived from its C roots. What was wrong with simply having an object oriented version of C? I know it can still be used that way, but it seems to be more and more difficult to only code that way using C++, because you're going to have to use libraries at some point or another.
Re:Dreaming... (Score:3, Insightful)
It took forever (a decade or more at least) to handle crashes in a microsoft OS which had thousands of talented people working on it.
Maybe it is because they had other priorities. Consumer software sales depend far more on features than reliability.
Re:He sure thinks a lot of himself (Score:5, Insightful)
Most of these topics can easily be researched and learned without a university.
Yes, they can be researched - but, let's face it: most people either think it's beyond them, think they'll never need to know it, or are just too lazy. The ones who would research it themselves are likely to be the ones who are good anyway.
Re:The companies not happy with grads is pure BS. (Score:3, Insightful)
Paying people more doesn't make them suddenly skilled. All it does is suck talent away from your competitors, it's zero sum. It might also encourage more people to enter the field, but if education is poor, why would they be any more skilled than previously?
I'd agree with Stroustroup. The number of people out there who truly understand computers and software development is too small, because new developers have to re-learn the lessons all over again due to poor or non-existant teaching.
Re:Is coding really a team sport? (Score:5, Insightful)
The problem is, you're lumping all development into some generic activity called "coding." That ignores the simple fact that being an expert in C++ does not make you expert at UI design. Being an expert at UI design doesn't make you a SQL whiz. Being a SQL whiz does not make you an expert at designing flexible & scalable application systems with many moving parts.
See the pattern? To make any practically-useful system today, you MUST work with other people who are expert in areas you're very likely not an expert in. You can create the best data model in existence for your company's payroll system, but if you don't have a clear understanding of the business rules, a good architecture, and a solid UI (and I've seen very few people in software engineering who are experts at all of the pieces that go into creating a good piece of software), the resulting product will be an unusable piece of crap that doesn't meet requirements.
Stroustrop's point of the single genius programmer is valid. The model you describe supposes that a single person can possibly learn and be expert in all of the disparate knowledge areas that are required to make a working piece of software, and in any group, the people who are capable of that level of insight & knowledge will *always* be the statistical outliers. Instead of punishing the majority of people for not being born with genius-level intellect, teach them how to be good at their chosen area of expertise, and how to relate to the people they have to work with to get things done. You don't have to engage in XP or some other "pair programming" methodology to realize value from being able to communicate clearly and work with your architect, QA / Reliability engineers, your customers, your project manager, and other developers who are working on separate subsystems.
Re:too much Java ... (Score:3, Insightful)
Everyone is way better off with C (for systems stuff), Java (for "enterprisy" stuff), Python (for frontends) and sh (for quick and dirty hacks) than with any C++(*).
What do these languages have in common?
* C
* Java
* JavaScript
They each have the same highly successful syntax. Except for small adaptations for the different levels of systems vs application vs scripting these languages are interchangeable and each has a certain C-style simpleness and elegance to it.
There are all sorts of different competitor languages... Objective C, Ruby, Smalltalk, D, Pascal, etc. The languages that have been widely successful even since before time began (1970) have been variations of the Algol/C/Java/Javascript style syntax. For whatever reasons, it is what programmers choose. Maybe it just fits better with how our brain actually works rather than how we think our brain should work. Who knows.
But in any event, I suggest that C, Java, Javascript are the trifecta. Python is a dead end, the Pascal of its generation.
Re:Back To Reality (Score:5, Insightful)
Re:Dreaming... (Score:5, Insightful)
The companies that complain about the lack of "good" developers are the ones paying their developers crap and looking to offshore/cut costs. If you want good developers you're going to have to pay them.
I work at a company that pays at least 10% more than the going rate at other companies in the state and interviews 2-3 / week. It takes 3 weeks on average to find a developer they're willing to make an offer to. Two of the companies that are complaining are Google and Microsoft, both of whom give good salaries and great benefits when compared with the average job.
I've worked at several companies that paid decent amounts of money, and between 50% and 75% of the developers are crap. In my experience, good developers are hard to find at any price.
Re:He sure thinks a lot of himself (Score:3, Insightful)
Programming languages? Ha ha ha ha. I don't think my university bothered to teach any programming languages outside the first couple of intro courses (even then it was geared more at fundamentals). In some classes we were expected to learn whatever language the class required on our own and be able to use by the time the first assignment was due. Most classes didn't even care what you coded in as long as a TA knew it (if you wanted partial credit). Granted most of my classmates had aspiration higher than being code monkeys for the rest of their lives.
Re:Back To Reality (Score:4, Insightful)
What is it exactly that you think an engineering approach actually is? Some sort of formulaic fill in the blank? Engineering is coming up with ways to apply tools (physics, chemistry, math) to solve problems. Engineering curriculums teach engineers to think in such a way that they can do so. Any good engineering is an art form.
Re:On High Schools doing more... (Score:5, Insightful)
You don't need the latest and greatest to learn how to code. Infact, the more I see of computers and teenagers the more I think I had it better being limited to machines that didn't have a 1/10th of a meg of RAM and no Internet. Today there are just far too many distractions on a PC to get kids away from the task at hand. To be honest, if I were teaching coding I would go with the 2004 text about whatever language that normally can be found in the bargin bin for 5 bucks, a bunch of P-II 350s, a 10 dollar flash drive for each student and whatever freeware IDE I could find for the chosen language. No other software on the PC and no network connections either, thankyouverymuch.
This would keep the students mind on the task in front of him. When I first got my Vic 20 with no media storage and no game cartridges I had to sit down and learn how to make the machine do what I want it to. I found that it was a very gratifying thing to do. If I would have had MySpace and EverQuest I doubt I would have ever have gotten as far.
BTW: Get off my lawn!
Re:Dreaming... (Score:5, Insightful)
From an engineering standpoint: There is no reason for software to break, and yet it does, a lot of the time.
Nonsense. Software, like any other engineered system, will break when subjected to forces in excess of what it was designed to tolerate.
Would you argue that a building must NEVER fall down? I hope not.
Re:He sure thinks a lot of himself (Score:3, Insightful)
And what makes you think that it will be different if they do study? They will be on full auto mode, study the bare minimum and get the degree.
In the case of CS there really isn't a difference between self-taught and degree holders, and the "good" degree holders likely knew most everything before starting the degree.
My fellow CS students could be classified in two groups: OMG-I-think-I-Have-An-Algorithm-In-My-Program, and I-Write-Artificial-Neural-Networks-For-Fun.
Re:Is coding really a team sport? (Score:5, Insightful)
I know about extreme programming, and I've really enjoyed some team programming sessions, but when it comes down to it, I think one reason some people hold a much deeper level of knowledge than their peers is that they spend extreme amounts of time alone.
...
People who are fascinated with math and coding tend to have fewer peers who can understand what they are doing. Is this a bad thing? ... I guess the challenge is to guide young people to seek out their peers (those who are fascinated with the same things), and to make friends without making everything into a competition. ... There is a place for ambition, but that instinct can be a hinderance.
I think you've misunderstood was Bjarne was talking about. Most software projects have a dozen or more developers requiring close collaboration and the ability to cope with egos and positive/negative emotions. Also, just the ability to communicate your information to someone who needs it. Damn straight modern programming is a team sport! Are you working on tiny apps in a small closet hidden somewhere inside a small company? 'Cause for the rest of us, our day is filled with interacting with people. I'm very introverted, but I do need social skills to deal with the people I work with every day -- which causes me extra stress, but I digress. Software development in big companies and FOSS projects is a team effort, and for successful projects, the humans working on those teams need to work together smoothly.
Eventually, you start talking about what Bjarne was talking about at AT&T: social skills doesn't mean your hosting dinner parties and chatting up girls. It means being able to share and communicate your idea to another very smart person, and then being able to listen and learn from that other very smart person. I think you shifted into that point at the end of your post: the idea that introverted smart people need to find other smart people they can talk with.
Social skills in this context doesn't mean being the life of the party or tossing a football with non-geeks. Social skills means being able to tell the prima donna that his code has a bug in it. It means being able to explain to others why a design or architecture is bad. It's coping with hurt feelings: yours and theirs. The basic social skills of working in a modern business environment.
Programming has evolved waaaay beyond the lone programmer in his little corner office working his own hours. A programmer is expected to talk to end users and tease out their real requirements; it requires them to be able to stand up and argue for something in a room full of managers; it requires having the ability to tell another programmer his coding style is awful, but you want to help him to get better.
That's what Bjarne meant by social skills and team programming.
Re:The companies not happy with grads is pure BS. (Score:3, Insightful)
Not contradicting your ideas. But complementing:
>> Beyond that, what good programmers want is respect, appreciation, and freedom to do great things
Most companies do not have many cute projects to do, just "the same dirty work" they have to. Of course a very good manager can disguise that as a awesome project, but just for a while.
>> they also want to work with other smart people who they can learn from and build great stuff with
The real smart programmers (also, the pedantic ones) soon will be feeling they do not have more people around to learn from. From that point it is just money what drives the future.
A nice place is really useful, but not for retaining people. From my experience, too few people really thinks about it: When people get an big$ offer, rarely do a "future workplace environment" investigation.
BTW, I would add another factor: current firm prestige and reputation (nobody will quit from google to yahoo for a 10% rise at this time.)
regards,
Re:The problem with C++ (Score:5, Insightful)
I know it can still be used that way, but it seems to be more and more difficult to only code that way using C++, because you're going to have to use libraries at some point or another.
Yeah, those damned templated libraries with their: performance [stanford.edu], type safety [psu.edu], design patterns [wikipedia.org], generic programming principles [stepanovpapers.com]. I can't imagine why Java wasn't happy with containers of Objects and added Generics. C# definitely shouldn't have followed suit. All you need is void*, size_t, and int (*)(void *, void *), right?
Re:Dreaming... (Score:4, Insightful)
The general and fundamental problem that both Microsoft and Google are having(along with everyone else) is that no one wants to be the person who has to train the newbies.
No one, not even CS folks who have generally been spending at least some of their free time practicing what they're learning, comes out of uni knowing much of anything about anything. You have to train your graduates, and you have to accept that that's going to cost you some money you probably won't immediately recoup. They might even bugger off somewhere else when they've finally been trained up, and you'll have spent all that money for nothing.
Someone still has to do it, and no one wants to. Look around at job ads in any field that doesn't have a massive shortage of staff, see how many positions you'll see for "graduate ______" or "junior ________" or "assistant _________". Better training in high school and University will help, but expecting 22 year olds to be great at anything is probably a bit unrealistic and both Google and Microsoft might find it worth their while to expend some of their vast pool of knowledge in doing some of that training themselves.
Re:Back To Reality (Score:2, Insightful)
Strostrup is the problem (Score:5, Insightful)
It's amusing seeing Strostrup whining that schools are teaching Java instead of his C++. The problem with C++ is Strostrup. He's in denial about many of the fundamental problems of C++. He's publicly stated that there's nothing major wrong with C++. If that was the case, we wouldn't need Java and C#, which are, after all, attempts to improve on C++.
Down at the bottom, the fundamental problem with C and C++ is the "pointer=array" concept. That was OK for 1978, but it didn't scale well. It's the cause of most of the buffer overflows in the world. C and C++ don't even have syntax for properly talking about the size of an array parameter. That's just broken. C and C++ need something like conformant array syntax for parameters and in other contexts where one needs to talk about the size of an array.
The second fundamental problem with C and C++ is that the programmer must obsess on "who owns what", and the language not only doesn't provide help with this, it doesn't even have syntax for talking about it. There's no distinction between a pointer that "owns" an object and one that just "uses" it. Yet if the programmer doesn't carefully make that distinction, the program will have either memory leaks or dangling pointers.
The trend in C++, since templates went in, is to try to wallpaper over the problems with the underlying model. It never quite works; the mold always seeps through the wallpaper. Container classes almost, but not quite, succeed at encapsulation. There's almost always some place where a raw pointer has to be allowed to leak out. The standards committee has gone off on a "generic programming" tangent, with emphasis on weird template features used by few and used correctly by fewer. Just because you can abuse the C++ template system as a term-rewriting engine doesn't mean you should do that in production code. This results in a whole new class of incredibly obscure compile-time bugs. The standards committee has been thrashing for over a decade in this area; in the 1990s, the new version was to be "C++9x"; now it's "C++0x", and since we're close to 2009 already, "C++1x" looks like the reality.
C++ is the only major language to have hiding ("abstraction") without memory safety. No previous language had it, and no later language repeats that mistake.
Back around 2001, I made an effort [animats.com] to do something about it, but the political hassle was more than I had time for.
Re:Mythical Creature... (Score:5, Insightful)
Never a good fit for the real world? What about all those games written in C++? Do you really think Valve's Source engine would be as good if it were written in Java?
On the other hand, I agree with you that average to less-than-average programmers will never grasp the more advanced pieces of C++. I think the solution is to teach them better, the solution is not to dump C++ in favor of $other_language. (C++ isn't right for all situations, but I think all CS programs should at least teach it.)
Re:On High Schools doing more... (Score:3, Insightful)
Well, if you want to motivate a child, perhaps you do have to have the latest and greatest, or at least something with some cool factor. If you were a child today, you wouldn't feel an urge to play with a TRS-80 Model II (or BBC Micro in my case) because it is now old obsolete technology. You certainly wouldn't ask your parents to buy one for Christmas. So, you are unlikely to learn to program it. One of the major reasons so many people grew up liking to program from the late 70s to early 90s was because all the "latest and greatest" home and school computing devices had simple accessible programming languages pre-installed, and in many cases the manuals that came with them taught basic programming. And it was the coolest, latest, greatest thing. Children getting a PC now face a tytanny of choice, wondering "what's a good language to learn", while having to dodge the armies of angry geeks arguing furiously for and against each of them, before they start. And the chances are, whatever language they get hold of, it's most popular manual linked from its homepage will not teach you how to write Galaxians, but how to write a Pet Store's inventory management software. How many eleven year olds are going to shout "way cool!" to that? Today, if you want fun motivating programming for children, you have to a lot more to hunt it out than you did in the 80s.
Frankly, the recent trend of middle-aged geeks moaning about kids of today not wanting to download kits to reprogram their mobile phones that have such powerful processors (but just muck around making game levels in LittleBigPlanet), is rather like our grandparents moaning that we didn't want to play with Meccano, but just mucked about with that infantile brainless Lego...
Re:On High Schools doing more... (Score:3, Insightful)
Better Idea: Why learn to write code on a PC?
Many of the projects I did in school were micro-controller based. We designed little gadgets that tried to detect if a room was empty and turned out the lights. It had to "talk" to sensors and lights.
I think the standard undergrad "programming 101" entry level class project was to write a controller for a snack food vending machine. Inputs were the various butons and output opended dors and rotated a try and give out change.
I've heard others did ATM machines.
Just don't use PCs theyare far to complex and have huge APIs. Start the beginners on little 8-bit devices
Re:Mythical Creature... (Score:3, Insightful)
Too damn bad.... (Score:5, Insightful)
That the companies that are complaining about the poor training that new students are getting are not willing to hire older programmers who got exactly the kind training Bjarne is pushing for. Yeah, got exactly what he wants to put back into schools today, then we have tested it and developed it over decades of developing and shipping products. And there are hundreds of thousands of us out of work in the US.
I've taught programming classes and have had the experience of having companies call asking for the names of students who did well in my classes. I have also had the experience of trying to apply for those jobs. I have told the companies that I will work for an entry level salary and since they trust me to do the training and evaluation of the students you would think was qualified...
The best response was to be ignored, the worst was being laughed at.
Fuck 'em all,
Stonewolf
Here we go again with the myth (Score:3, Insightful)
The old "there a shortage of skilled labor" myth.
First off, all we have is the anecdotal exposition of one person.
See my other posts on the skills shortage. I've posted this before:
http://www.cs.ucdavis.edu/~matloff/itaa.real.html [ucdavis.edu] [ucdavis.edu]
http://www.fastcompany.com/magazine/85/essay.html [fastcompany.com] [fastcompany.com]
http://www.upenn.edu/researchatpenn/article.php?708&bus [upenn.edu] [upenn.edu]
http://techtoil.org/wiki/doku.php?id=articles:shortage_myth [techtoil.org] [techtoil.org]
All companies want are disposable interchangeable people who will work for nothing. This concept is doomed.
What, exactly, Bjarne, is the definition of a qualified developer? Developer of what? Software for what?
The entire concept of a "software engineer" or "developer" is meaningless. Take for example the statement "I am an Engineer". That statement is so broad to be meaningless. What type? Electrical? OK, what type? AC or DC? Electronic? Computer? Servo systems? Architectural electrical? Power grids?
Do you get my point?
Ok, now to developer. Database applications. Financial systems. HR. Medical systems. Commercial systems. Academic records. I've had a5-6 IT and development jobs and each domain was unique requiring becoming a psuedo expert in a few short months. Expecting a "one size fits all" approach to work is a recipe for failure.
So before we prescribe a solution, we need to determine what exactly we are trying to solve.
Re:On High Schools doing more... (Score:3, Insightful)
Re:Strostrup is the problem (Score:2, Insightful)
Also, if you really want managed memory,, there are GC implementations for C++.
Re:Strostrup is the problem (Score:3, Insightful)
C++ is designed for programming at a lower level than Java, C#, Perl, Python, or other bytecode languages. The object-oriented facilities enable large-scale application development by a team of programmers, but fundamentally it is a low-level language like 'C', from which it is derived.
If you were writing a video game, you might care if the garbage collector could start running whenever you instantiated an object.
C++ has facilities such as exception handling and RTTI, but in practice they aren't used with the same abandon as they are in Java and C#. Maybe that's because C++ programmers are always cognizant about how much operations cost, and they often figure they can design roughly equivalent error handling and safe downcasts on an ad hoc basis, with better performance. Ditto for automated array bounds checking, which could be accomplished in C++ (like many other things) via templated classes, but which usually isn't bothered with. True, this requires more vigilance on the part of the development team.
Management of heap-allocated objects to avoid memory leaks and other disasters can be accomplished using smart pointers, which are covered in many intermediate-level C++ books.
Perhaps Stroustrup is lamenting a situation where CS grads steeply trained in Java or C# may not come away with a good mental model of the (virtual) machine on which their code is running; they just know that they don't have to worry too much about memory leaks, array indexing errors, bad casts, etc. I happen to agree that a near-exclusive diet (perhaps with one semester of assembly language) of these bytecode languages would be poor training for a computer scientist. This would be like a doctor who was thoroughly trained in the latest techniques and procedures, but who lacked a grasp of the fundamentals of chemistry and biology.
Re:Back To Reality (Score:5, Insightful)
University isn't vocational training, and it certainly isn't vocational training for the specific tool set that you happen to use. If you mean that it would be reasonable to offer a Windows programming elective, great. But mandating a class in operating Visual Studio makes about as much sense as mandating a course in Ruby on Rails or the iPhone SDK.
Re:The companies not happy with grads is pure BS. (Score:1, Insightful)
>Companies are not happy with the fresh coders because the good ones wont accept the low salaries they offer.
Software developers make about 70 to 80k on average, and it's not unheard of for them to be on the lower end of 6 figures. Some engineering disciplines pay more, but that's none too shabby either.
I think the real problems are these.
1. It takes more than 4 years at a university to become a decent software developer. Grad school doesn't help because it is focussed on computer science and not software engineering.
2. Not everyone who goes into computer science is really cut out for it. That it pays well actually hurts the quality of graduates in some cases because it attracts people who have no natural gifts in or passion for computer science, but just want in for the money. People who just don't care, don't take the painstaking effort it takes to write clean code.
3. And I think this is the most serious problem of all. Management. Managers at most companies are "business" people with way too much authority and way too little knowledge. Why should someone without a computer science degree be allowed to "manage" developers is beyond me.
The places I've seen that do development right don't put developers subordinate to managers. Developers manage themselves, and tech leads do most of the middle tier management work. You need people who are developers, or who primarily have an engineering background making important decisions about the schedule and development practices. How is a guy who went to business school supposed to make decisions about development practices anyway?
Certainly, there is a place for people who went to business school. At companies that don't develop software.
Re:Mythical Creature... (Score:3, Insightful)
If interfaces actually did something, I'd agree with you. But they don't. Implementable interfaces which could be used by any class that needed them would be beautiful. Java interfaces are essentially documentation, not code.
Re:The companies not happy with grads is pure BS. (Score:4, Insightful)
3. No professional organization. This is a huge one. To the outside world, no one knows what a good software developer does. Just as most of us know nothing of what makes a good lawyer. We treat lawyers like a black box. Here's what I need done... now go. This is how businesses treat software. It is professional organizations that mantain the quality of people. They take care of ensuring people are trained properly and things work as follows. You don't need to know anything about accounting. However, if you're a business and need some complex accounting done, you get a CA not just some guy with a few accounting degrees. It is also why most professional organizations employ themselves. CAs join firms like PWC, KPMG... Lawyers do their own thing. Software developers work for a business. Which yes... makes you just another worker bee.
The problem is that nerds are far too Libertarian, with a capital L. Forming a professional association to them would be tantamount to forming a union, and that would be sacrilege!
Such a tool... (Score:5, Insightful)
I have to say after reading this article -- Stroustrup is a tool. It is just that simple. Nothing more than a pundit at this point. He had a stroke of genius in programming and now is an expert in everything related to programming.
He thinks companies aren't happy with their graduates? Well, I say companies have terrible hiring practices, terrible mentorship programs, and ridiculous expectations.
Balance the theoretical and the practical? Wow. Brilliant observation. Great, Bjarne. Please give us more sweeping Karate-Kid style one-liners.
High schools should teach students to work hard? Great, Bjarne. Thanks again for that. Search out information as needed? Another stroke of brilliance. Express ideas in writing and verbally? WOW. PINCH ME. Such genius can only be dreamed of.
Then, the article closes with him trying to be edgy and go out "with a bang". Sloppy, fat geeks. Nice. This guy is a douchebag. Pure and simple.
Here is my own contribution to douchbaggery... I think we should take aging, isolated, self-important pundits out into a remote area and bury them neck deep in the dirt.
Re:Back To Reality (Score:1, Insightful)
I think that what Stroustrup is arguing is that the creative aspect is based on a core technical (engineer/mathematician) understanding of the problem at hand. I do agree with you about the need for creativity, it is very important. However, I think that without a solid foundation, it's hard to have "creative flashes" in programming and still produce sound and solid code that is reusable.
Re:Dreaming... (Score:5, Insightful)
There is a reason the programmer stereotype is the geek with poor social skills, because most bright people with strong social skills are going to quickly jump to the business side of the company where they can make more money and climb faster. Its a form of natural selection.
Developing software is really not that great a career, when compared to the other modern careers in business(though its obviously better than factory worker and ditch digger). It does draw some good people who enjoy developing software or maybe don't have the temperament for other professions(translation: geeks who would suck at business, marketing, law and medicine). There are some geeks that score big in software which are the exception to the rule but that happens at about the same frequency as people scoring big in professional sports or acting at least since the dot com bubble burst.
Problem #1, software development isn't a career path that will last you until retirement or if it does the entire second half of your career will suck. In most companies programming is a career for 20 somethings, maybe 30 somethings, 40 somethings if you stretch it. You better hope you land hit on a lucrative startup in your prime so you can get your FU money and retire young. Once you hit your 40's and 50's you are either going to be forced to switch to self employment or to management otherwise your career advancement is going level off and you hope it doesn't start going down. Fifty and sixty year old programmers are something of an oddity and usually discriminated against because the stereotype is you need to be young to be a programmer. The exception is maybe if you have a PhD and can jump to research. Jumping to management or self employment mid career is fine for some people but it requires a radically different skill set and temperament to manage people, business, customers, budgets and schedules and not code. A lot of coders wont succeed in the transition.
Problem #2, most programming jobs don't really pay that well though again its better than factory work :) You will need to be a superstar and create products that you own and control or you aren't going to make big money. If you are a programmer stuck in a large organization the executives, marketing people and salesmen are going to be the ones getting rich and climbing fast. There is a reason so many climbers seek MBA's, even if its dubious MBA's have real value in the world (especially after witnessing the recent meltdown induced largely by MBA's, George W. Bush included in that number).
As a programmer will probably do OK money wise, but you will probable have an opportunity to work long hours on tough projects, and do some painful death marches to get products out the door. If the product fails then you hope you survive the layoffs that ensue. If it succeeds you discover the people above you in the food chain have taken most of the profits, and throw crumbs to the programmers unless they are superstars. If you are lucky you get a small raise or a few options(since options are accounted now they aren't as widely available as they used to be especially on the lower rungs of the food chain). You then just get to start over on the next product and repeat. It can easily be a treadmill to nowhere unless you get in to a high risk startup that succeeds. If you do you still have to work hard or get lucky to get a big piece of the action which requires some pretty serious social and business skills and a strong ability to watch your back, because everyone else in the startup is trying to get a bigger piece of the action too... probably at your expense.
Its just a guess but most really bright people, especially ones with good social skills, are going to be smart enough to angle for the business side of the company because they know thats generally where the money is, especially these days, because CxO's and directors almost always rake in millions a year whether they succeeded or not. Most programmers will never see that kind of money.
Re:Back To Reality (Score:3, Insightful)
There's always going to be a tension between process and creativity.
Re:Mythical Creature... (Score:3, Insightful)
Wake me up when there's a mainstream language that has syntactic sugar for interface delegation to a class member to provide for the lack of implementation inheritance (so that I can do what C++ MI lets me do with interfaces in comparable number of lines of code).
In case I didn't make myself sufficiently clear, here [codegear.com] is a description of the feature for a language that actually implements it. It's not a mainstream one, though.
Re:Mythical Creature... (Score:4, Insightful)
Rubbish!
You are clearly speaking as somebody who has not yet grasped what interfaces give you. An interface is an indicator that a class provides a particular service, many classes can provide the same service in different ways, all would implement the interface.
So you have an interface called 'Dateable' which defines a method 'setDate(Date date)'. Your Appointment class and your MissleLaunch class both implement this interface. Then your cool little date chooser widget just takes a 'Dateable' as a parameter somewhere (either constructor or setter). It 'interfaces' with the dependent class via the type safe interface type without needing to know whether it is scheduling a trip to the dentist or the end of civilisation as we know it! *That* is what interfaces give you, far more than just 'documentation'.
People get lead down the wrong path because someone will say... "Java doesn't have multiple inheritance, but instead it has interfaces", but this is like saying... "I don't have a hammer, but instead I have an apple". Two concepts, two jobs. Java doesn't have multiple inheritance because some of the end-case rules are a bit strange, and god knows, even single inheritance is badly abused by poor programmers. Sun seem to have taken the line of not giving people the rope with which to hang themselves (even if a small percentage would use the rope responsibly), operator overloading is not in Java for the same reason.
We can argue whether this was a good approach (there are are strong arguments from both camps!), but interfaces are *certainly not* 'essentially documentation'.
Learning languages and CS education (Score:3, Insightful)
I'm of the opinion that the language is almost immaterial. Within a few semesters a student should be exposed to multiple languages anyway, so grinding that axe is missing the point entirely. Team issues, though ... I'll get to that in a minute.
It's not just the quality of CS grads and it has nothing to do with what language they're taught. The quality of grads in general is usually pretty low. The fact that it hasn't improved despite generations of languages isn't surprising: Basic business training is not nearly as difficult as CS, and we have millenia of experience in that domain, and yet those guys come out pretty damn green too.
I think this is largely because the teaching paradigm is almost entirely memorize-and-regurgitate. This is a fine way to teach multiplication tables but it's not very applicable to most real-world skills. Generally speaking it's far more valuable to know where to find information than to have memorized the information itself; this not only expands your ultimate capabilities, it makes you less error prone. Yet when was the last time you saw information retrieval as a college-level course? The only time I have seen that was when my wife was working on her masters in library science.
The value of looking things up is taught in (physical) engineering (mis-remembering physical constants makes bridges fall down) but it seems wholly ignored in most college-level disciplines. I credit Google for improving the tendency for people to look things up rather than memorizing them, kind of contrary to what you might have read in The Atlantic last summer. Information retrieval is an incredibly valuable skill. It's why skilled programmers used to have bookshelves of reference material. (In some respects I miss that, it was always fun to guess how a person thought by looking at the books he had on his shelf.)
As Stroustrup says this problem is compounded by the fact that students, even at the college level, are treated as singletons. How many jobs have you held where you were the only one doing everything? I've been there and done that, but most of the time we work in teams, and it's quite rare to find courses teaching people how to work together effectively as teams.
I'm not talking about just splitting something up into tasks done by multiple people, but rather the concept of layered skills on a team: mentoring or apprenticeship.
There is a reason why trade skills have been taught using apprenticeship for millennia (it's not just a way of limiting the influx of competition). It's because learning your trade solving real problems working with people who know how to do that kind of thing is far more enlightening that trying to bend your mind around abstract examples written on a white board sitting in a room with three hundred other people.
Brooks' team design from The Mythical Man-Month has (mostly) withstood the test of time; it should be something that is put in practice in the classroom, not just discussed for a few days in the abstract.
High-quality education needs both hands-on in a team and white-board theory! And yet it is beyond rare to see students of various levels (e.g. grad students and freshmen) mixed up on a classroom project. Instead we have them build toys, individually. They puzzle through building toys then we kick them out into the workaday world having never done anything more complicated than that.
The whole of our educational system is designed incorrectly, segmented and stepped rather than mixing and a continuum. It puts far too much load on teachers because you just can't have much one-on-one time when you're the only one the students can rely on; in a one-room school, for instance, it was common to have more-ski
Re:Mythical Creature... (Score:2, Insightful)
I agree that C++ GUI code (like Valve's Source engine) are better than the old C GUI libraries. C++ is a good fit for describing class hierarchies of GUI widgets. It's not all bad, but not all good, either.
While C++ works well for trees, consider graphs. Two classes, not just one (Nodes and Edges, rather than just Nodes). If there is a C++ database containing a graph, and you want to manipulate that graph, how do you do it? In C++, your life becomes harder than it should be at that point (do you attach void pointers to allow kludged extensions to database objects, or inherit from them directly and do copy-in/copy-out?). The only reasonable C++ graph library I've seen is the Boost Graph Library. If you care for a life of pain, make this the basis of your next big EDA project. Alternatively, if you store those graphs in a DataDraw [sourceforge.net] database, your code is hugely simplified, while running far faster.
I do EDA coding for a living. Life as an EDA programmer is basically all about manipulating graphs. C++ and EDA have never worked out well together, but nor has Java, C#, or any other mainstream language. You need dynamic extension, like Python, but raw-speed, like C. Today, that means DataDraw.