I guess their is creating their IT policy. Maybe the CIO gets kickbacks.
First, if I were a student at CMU, I would complain about having a corporate trojan installed on my machine. How long before somebody reverse engineers the protocol for this 'client security agent' and turns this software into a backdoor on unsuspecting student's machines.
Second, if I were a professor, I'd ask why the IT department can't set up a faculty network separate from the student body. Do some bandwidth shaping here. Give the faculty network a separate, dedicated amount of bandwidth. (I'm imagining they do this already, but I'm answering some the responses here.)
Third, if I were a high enough ranking member of CMU's IT department, I'd be asking why we want to touch all those student computers anyway. I really don't want the department to be saddled with the help desk issues resulting from this bastard 'client security agent' malware anyway. Quarantine the non-conforming students. If these students are willing to sign waviers, put them on a separate network, firewalled from the conforming students. It's up to them to firewall their machine. Block the obvious P2P traffic (or do some intelligent bandwidth shaping). Students who wish to conform get put on the other network. Plus, by a good anti-virus solution for everybody (like Avira or NOD32). Once again, anyone who doesn't conform to this policy gets put on the quarantined network, plus they sign the waiver stating they understand the risks.
Fourth, hire me as CMU's CIO.... (Forget it, Michigan is in the toilet as a state anyway...)
You can still write good code without having a CS background. Sure, if you designing an operating system, designing a compiler, or delving into some low-level code, more engineering know-how is required. However, I've found my Math/CS background only to be mildly useful when writing database apps...
Here are some things you can do to become a better programmer...
Mentorship
Find someone (preferable a group of people) you can talk shop with. Nobody loves solving someone elses problems, but most programmers like to discuss best practices. Pick apart other people's code. It could be an open source project or maybe just the source code to some guy's game you found online. Maintaining code allows you to see other people's mistakes. Writing good code is hard, writing maintainable code is even harder. You can learn a lot about design by being on the other end of the development process (i.e. maintanance). Sometimes mentorship is just reading good code.
Read, read, read...
All the coding in the world will get you only so far. You need to consult the wisdom of experts. Some other good books are:
Object-Oriented Software Engineering:
Practical Software Development using UML and Java
by Timothy Lethbridge and Robert Laganiere
2nd edition website for book
They even have a DVD with an entire semester's worth of lectures (based on the book) available for $50 online.
Applying UML and Patterns
by Craig Larman
3rd edition sample chapters here
There's a series of videos (about 3 hours in length) that describe many of the details in the book.
The above books will introduce you to many of the existing methodologies in software engineering. It's not so important what methodology you choose; what is important is how you implement it. While many people may disagree with me on this. Engineering methods can be taught, problem solving skills can be acquired, and math skills can be learned. You might not be the next Edsger Dijkstra, but you can learn to write very good code on schedule and under budget. It may be hard to write code at home when you've been writing code at work all day, but try working through a project from beginning to end with perfect documentation (yes, make use cases...) utilizing all the right tools (i.e. version control, bug tracking, make tools). Doing this will make you a better programmer. Learn to take a few minutes each day and write out what your going to do. I often start writing code for the day by opening up notepad and figuring out what I'm going to do in psuedo-code. After, I just flesh out the notes and spend the rest of my time testing. Some guys like to do this on paper. Many professional organizations start out a days worth of coding drawing UML (or some close approximation to it) on a white board. The key is to plan before you code. Don't just jump in front of your IDE.
As far as training materials go, I'd wholeheartedly recommend any of the CBT courses by LinuxCBT.com. Also, the Cisco series of CBT courses from CBTNuggets are good too. Lastly, Todd Lammle has a CCNA DVD series at lammle.com. They're all excellent. Other books, like 'Linux Systems Administration' and the 'The Practice of Systems and Network Administration' are excellent places to start. Finally, creating your own lab or administrating your own server are good learning experiences too.
The best job/internship you could get is where you would become a junior member of a development team. This development team would follow the unified process (or some development methodology). They would use version control and bug tracking software. You would learn by seeing others work. It would be best if you were actually mentored by senior programmers (but in my humble experience this rarely happens). At worst, you learn a lot just by looking at senior programmer's code.
If I were looking to bring in an intern, my first job for you would be to create end user documentation and comment existing code. Even this would require supervision, but you'd be exposed to a lot this way. Eventually, I might have you fix a few bugs. That's probably the best way for you to learn.
Are you studying math? If so, where? You might be able to find a internship as a programmer. Many big software companies hire math graduates for programming positions.
Also, there is an alternate option. It's not as good as the first, but it's probably easier to find. On the downside, you don't want to get stuck in these types of jobs. Find any place that would hire you as a programmer. Even if it's building small in-house apps. At first, your work is going to really suck (that's a technical term folks). However, over time, if you start to research on your own, you learn some best practices and develop some skills in software design. Plus, hopefully, you'll be able to land a gig in a development shop as mentioned above.
Unless you're working with embedded systems, you're probably going to need to know SQL. Most programming jobs deal with databases. If you want to work on the embedded systems side, you'll need to learn C/C++ and you probably need an EE or Computer Engineering degree. Finding an entry level job is THE hardest part. What you need to do is get some experience writing a database driven application. You're going to need know what a Join (in SQL) is. I'd say about half the jobs (and almost every job with a tech test) will ask you a simple SQL question (usually including a query on multiple tables, thus the join).
I hate to be so pedantic, but I don't think Einstein had a PhD while he was working as a patent clerk. I believe the reason he became a patent clerk, is because he couldn't get into graduate school and had problems finding work.
Keeping any sufficiently complex code base 'clean' is like battling entropy. Eventually any code base given enough changes becomes 'messy'.
I've found the best code is planned code. Code is best, when it's created by following a methodology. It's best when the code has been written in requirements and design documents and merely typed into source code. Code is best when it's been written twice. Code is often at it's worst when it's adversely affected by scope creep, programmers stumbling over a new architecture, or poor management.
Reading code is hard. Ever try to 'debug' a mathematical proof. Sure natural language is too ambiguous for most math.* That's why logic was invented (see the chapter on Leibnitz). Going from symbolism to natural language is hard, understanding context is even harder. Just ask anyone doing research in NLP.
*I'm not a logician, but as a side note, I've always found Raymond Smullyan's books on formal logic to be the 'prettiest' math books around. He has a naturally recursive mind.
Employers After you get your first job, the words 'Summa Cum Laude' are only for bragging rights. It MIGHT help you get recruited by a top company, but frankly I'm not so sure of that. I did menial IT work in college. While the experience wasn't the best, it helped when I got out. Employers were much more eager to hire a kid with some real work experience than someone with a 4.0 GPA and no experience.
Grad Schools I doubt grad schools will overlook the fact you repeated classes (although I could be wrong). Many graduate school admission committees will look at your GPA in different ways. They'll examine you in-major GPA, your GPA for your final 2 years, etc. Secondly, most grad schools in CS look very highly on good grades in classes like Combinatorics, Algebra, Set Theory/Logic, Number Theory, (i.e. pure discrete math). If you really think your grades need a boost, try taking a couple of math classes and get a minor (or major) in math. Finally, good grades in a MS program or some research experience can easily draw attention away from those bad grades. Don't waste your time repeating classes, unless you really didn't understand the material (and you can proceed without it).
Other options (get an MS) There are very reputable professional MS programs out there. If you don't get accepted anywhere you like, you can always take that money and go to grad school. Many good schools have room in professional programs for people who can pay.
You can learn how to create good documentation by learning to create DOCUMENTATION. Essentially, what you're asking here is how to be a good technical writer. One of the best ways to do this is to learn about the software engineering process. You won't necessarily have to learn how to program, but you will probably end up learning a little UML (Unified Modeling Language).
In the Unified Process (and many other software engineering methodologies) a technical writer/architect/project manager will create documentation to describe the problem and a potential solution (i.e. the design for a piece of software) to programmers, customers, and upper management. In fact 'working the documentation process' is a sound part of software engineering. One of the methods implored is to create a set of 'use cases'. A use case is a description of the actions on a system/piece of software. Often use cases (documented actions on the system) provide a great template for a user manual.
Didn't Linus Pauling have his security clearance revoked because of his communist affiliations.
Re:It's nice for little things.
on
Rails Recipes
·
· Score: 1
Most of the web application scaling problems come from issues related to session management and load balancing or taxing use of the database. Maybe I've been fortunate, but if you can overcome those problems, you usually can server farm your way out of any performance issues. What other problems have people run into?
How many RoR shops are out there? Sheesh, I see more companies still developing sites with Perl. I'm not trying to knock RoR, I just see a lot of talk and no real action. In fact, I've seen more Python code in production use as well.
If a bunch of chemical engineers wanted to start a new "energy" provider, could they do it? Rather, is the field so regulated as to artificially force (or keep) big players in the market?
It depends. I think both technical and non-technical managers can be successful, but it depends on the company. A small start-up badly needs technical managers. Not only will the managers have their hands in everything, but the key to a start-up's success is innovation. Large companies thrive on politics. So a political savvy management guru often is the better choice. Big companies don't innovate, they try to maximize share holder's profits. Since the goals are different, the managerial requirements are often different as well.
Peter Drucker (a management guru; author of several good books on management) has written repeatedly that the most important asset a manager can have is integrity. He argues integrity and character are the building blocks of any good manager. It's not organization, motivational skills, or the ability to politick.
Incidentally, I think what happened with your company is that you got bought out because you innovated so well. The technical guru worked well in a geek-friendly small company, but probably rubbed the MBAs the wrong way. They wanted to see a ROI fast, not make long-term money by creating a quality product. I don't think the large corporate MBA-think is evil, it's just not a place I'd prefer to spend my days.
I know this is just an example, but no 30k employee costs just 30k. There's health benefits, office equipment, and a general 'drain' on other resources like accounting, HR, IT, etc.
You'd need a lot of common reusable libraries. Networking, sound, and input are hardly trivial subsystems. Only a big company could afford to roll out their own API. Heck, that's what made DirectX so attractive. I'm sure OSS or even commercial toolkits exist, but it's still collection of lesser used tools to add to a project. Adding too many different tools (especially if they aren't bundled together in a single API) to a project is a known factor in project failure (i.e. you supposed to factor that stuff into a equation to determine the likelihood of success; see McConnell's books).
Foriegn newspapers tend to provide a lot of coverage of US politics. In fact, in some cases, the US government gets more coverage that the domestic government. I didn't even feel like I was in a foriegn country when I was in Toronto.
If you want to get good coverage of world politics in the US, watch the BBC or read the Economist!
They're trying to solve management problems with a development methodology. In other words, let's take all the common sense (and politicking) out of project management and reduce it to a set of mechanical rules which are to be interpreted like an axiomatic system. It sounds like a good idea but it just won't cut it in the real world. The real world phenomena of good project management is so complex it can't be described by a simple set of rules.
Frankly, what all of these Agile/XP/Scrum/RUP/supervoodoo methodology arguments have been about is that software engineering project management is as "COMPLEX" as software engineering. Perhaps even more so. It's all about problem solving. The problem it's rarely done right. Motivating people, figuring out how they work, and keeping them productive is hard work. Ironically, if you can intelligently have an argument about the finer points of Agile methodologies, you're probably not the problem. It's the managers who give 'peanut butter' manifestos I'm worried about.
It's not a news article, it's more of an overview for programmers. Actually, it's pretty well written, just not a 'headline'. Incidentally, I hadn't heard about the KDE/GNOME stuff until recently. I only ran across Qt when I was looking for an OSS (or just free) RAD tool.
A list of fallacies about the future of engineering/IT and they're rebuttal:
Foriegn students are smarter. First, would you like to compare the average student at IIT to CalTech or MIT? Don't compare some engineering student at IIT to a liberal arts student at Yale (I think we all know how they turn out).
There aren't enough skilled Americans. What skill sets? He's not even identifying any specific skills. It's not like I use analysis or quantum mechanics at my job on a daily basis. I think we've all hit the nail on the head by saying corporations are just too cheap. They want 'skilled' workers (their wording not mine) to be as cheap as the non-skilled workers. Wow, there's great economic insight from the Department of Commerce! Okay so every CS department isn't teaching Lisp/Scheme to incoming students, I doubt that's what he's talking about. Oh, and don't whine about american students not having math skills. The average math major has studied so much math the only place they could use it is as an actuary or quantitative finance (another kind of actuary). Frankly, that's a couple of college courses for the mean student at best.
Americans are lazy. So let me get this straight a brainless poly-sci grad from some Ivy who has no formal training (and probably no managerial experience in the private sector) has become the IT czar for the Commerce department. Yeah, he's really qualified to make such broad sweeping generalizations. However, I'd like to point out that someone in a 3rd world country is less likely to waste (have the oportunity to spend) their one shot at higher education on a Women Studies degree. How many Nobel Laureates does the US produce compared to the rest of the world? So it's not like our best can't compete. I guess those hordes of Chemistry students from India and China aren't flocking to basic research. In other words, there's no point in studying Chemistry, Physics, or Math unless you want to do into research (industrial or academic) for a living.
As a final note, I really wish Robert Cresanti would hold a open forum so I could reply to his assertions in person. Someone needs to set the record straight.
Slashdot Mirror
First, if I were a student at CMU, I would complain about having a corporate trojan installed on my machine. How long before somebody reverse engineers the protocol for this 'client security agent' and turns this software into a backdoor on unsuspecting student's machines.
Second, if I were a professor, I'd ask why the IT department can't set up a faculty network separate from the student body. Do some bandwidth shaping here. Give the faculty network a separate, dedicated amount of bandwidth. (I'm imagining they do this already, but I'm answering some the responses here.)
Third, if I were a high enough ranking member of CMU's IT department, I'd be asking why we want to touch all those student computers anyway. I really don't want the department to be saddled with the help desk issues resulting from this bastard 'client security agent' malware anyway. Quarantine the non-conforming students. If these students are willing to sign waviers, put them on a separate network, firewalled from the conforming students. It's up to them to firewall their machine. Block the obvious P2P traffic (or do some intelligent bandwidth shaping). Students who wish to conform get put on the other network. Plus, by a good anti-virus solution for everybody (like Avira or NOD32). Once again, anyone who doesn't conform to this policy gets put on the quarantined network, plus they sign the waiver stating they understand the risks.
Fourth, hire me as CMU's CIO.... (Forget it, Michigan is in the toilet as a state anyway...)
You can still write good code without having a CS background. Sure, if you designing an operating system, designing a compiler, or delving into some low-level code, more engineering know-how is required. However, I've found my Math/CS background only to be mildly useful when writing database apps...
Here are some things you can do to become a better programmer...
Mentorship
Find someone (preferable a group of people) you can talk shop with. Nobody loves solving someone elses problems, but most programmers like to discuss best practices. Pick apart other people's code. It could be an open source project or maybe just the source code to some guy's game you found online. Maintaining code allows you to see other people's mistakes. Writing good code is hard, writing maintainable code is even harder. You can learn a lot about design by being on the other end of the development process (i.e. maintanance). Sometimes mentorship is just reading good code.
Read, read, read...
All the coding in the world will get you only so far. You need to consult the wisdom of experts. Some other good books are:
Object-Oriented Software Engineering: Practical Software Development using UML and Java by Timothy Lethbridge and Robert Laganiere
2nd edition
website for book
They even have a DVD with an entire semester's worth of lectures (based on the book) available for $50 online.
Applying UML and Patterns
by Craig Larman
3rd edition
sample chapters here
There's a series of videos (about 3 hours in length) that describe many of the details in the book.
Anything by Martin Fowler
Martin Fowler's website
You may wish to also check out:
A seminar on the Object Oriented Design with a focus on the Unified Process (or something close to it)
Methodology, methodology, methodology
The above books will introduce you to many of the existing methodologies in software engineering. It's not so important what methodology you choose; what is important is how you implement it. While many people may disagree with me on this. Engineering methods can be taught, problem solving skills can be acquired, and math skills can be learned. You might not be the next Edsger Dijkstra, but you can learn to write very good code on schedule and under budget. It may be hard to write code at home when you've been writing code at work all day, but try working through a project from beginning to end with perfect documentation (yes, make use cases...) utilizing all the right tools (i.e. version control, bug tracking, make tools). Doing this will make you a better programmer. Learn to take a few minutes each day and write out what your going to do. I often start writing code for the day by opening up notepad and figuring out what I'm going to do in psuedo-code. After, I just flesh out the notes and spend the rest of my time testing. Some guys like to do this on paper. Many professional organizations start out a days worth of coding drawing UML (or some close approximation to it) on a white board. The key is to plan before you code. Don't just jump in front of your IDE.
As far as training materials go, I'd wholeheartedly recommend any of the CBT courses by LinuxCBT.com. Also, the Cisco series of CBT courses from CBTNuggets are good too. Lastly, Todd Lammle has a CCNA DVD series at lammle.com. They're all excellent. Other books, like 'Linux Systems Administration' and the 'The Practice of Systems and Network Administration' are excellent places to start. Finally, creating your own lab or administrating your own server are good learning experiences too.
The best job/internship you could get is where you would become a junior member of a development team. This development team would follow the unified process (or some development methodology). They would use version control and bug tracking software. You would learn by seeing others work. It would be best if you were actually mentored by senior programmers (but in my humble experience this rarely happens). At worst, you learn a lot just by looking at senior programmer's code.
If I were looking to bring in an intern, my first job for you would be to create end user documentation and comment existing code. Even this would require supervision, but you'd be exposed to a lot this way. Eventually, I might have you fix a few bugs. That's probably the best way for you to learn.
Are you studying math? If so, where? You might be able to find a internship as a programmer. Many big software companies hire math graduates for programming positions.
Also, there is an alternate option. It's not as good as the first, but it's probably easier to find. On the downside, you don't want to get stuck in these types of jobs. Find any place that would hire you as a programmer. Even if it's building small in-house apps. At first, your work is going to really suck (that's a technical term folks). However, over time, if you start to research on your own, you learn some best practices and develop some skills in software design. Plus, hopefully, you'll be able to land a gig in a development shop as mentioned above.
Unless you're working with embedded systems, you're probably going to need to know SQL. Most programming jobs deal with databases. If you want to work on the embedded systems side, you'll need to learn C/C++ and you probably need an EE or Computer Engineering degree. Finding an entry level job is THE hardest part. What you need to do is get some experience writing a database driven application. You're going to need know what a Join (in SQL) is. I'd say about half the jobs (and almost every job with a tech test) will ask you a simple SQL question (usually including a query on multiple tables, thus the join).
I hate to be so pedantic, but I don't think Einstein had a PhD while he was working as a patent clerk. I believe the reason he became a patent clerk, is because he couldn't get into graduate school and had problems finding work.
Keeping any sufficiently complex code base 'clean' is like battling entropy. Eventually any code base given enough changes becomes 'messy'.
I've found the best code is planned code. Code is best, when it's created by following a methodology. It's best when the code has been written in requirements and design documents and merely typed into source code. Code is best when it's been written twice. Code is often at it's worst when it's adversely affected by scope creep, programmers stumbling over a new architecture, or poor management.
Reading code is hard. Ever try to 'debug' a mathematical proof. Sure natural language is too ambiguous for most math.* That's why logic was invented (see the chapter on Leibnitz). Going from symbolism to natural language is hard, understanding context is even harder. Just ask anyone doing research in NLP.
*I'm not a logician, but as a side note, I've always found Raymond Smullyan's books on formal logic to be the 'prettiest' math books around. He has a naturally recursive mind.
I know this is somewhat off-topic, but reading about the simulated rat brain brought up this question.
Does anyone know of any research projects (at academic institutions) for large scale knowledge bases? How about practical large scale AI, like 'HAL'?
I wouldn't repeat the classes if I were you.
Employers
After you get your first job, the words 'Summa Cum Laude' are only for bragging rights. It MIGHT help you get recruited by a top company, but frankly I'm not so sure of that. I did menial IT work in college. While the experience wasn't the best, it helped when I got out. Employers were much more eager to hire a kid with some real work experience than someone with a 4.0 GPA and no experience.
Grad Schools
I doubt grad schools will overlook the fact you repeated classes (although I could be wrong). Many graduate school admission committees will look at your GPA in different ways. They'll examine you in-major GPA, your GPA for your final 2 years, etc. Secondly, most grad schools in CS look very highly on good grades in classes like Combinatorics, Algebra, Set Theory/Logic, Number Theory, (i.e. pure discrete math). If you really think your grades need a boost, try taking a couple of math classes and get a minor (or major) in math. Finally, good grades in a MS program or some research experience can easily draw attention away from those bad grades. Don't waste your time repeating classes, unless you really didn't understand the material (and you can proceed without it).
Other options (get an MS)
There are very reputable professional MS programs out there. If you don't get accepted anywhere you like, you can always take that money and go to grad school. Many good schools have room in professional programs for people who can pay.
You can learn how to create good documentation by learning to create DOCUMENTATION. Essentially, what you're asking here is how to be a good technical writer. One of the best ways to do this is to learn about the software engineering process. You won't necessarily have to learn how to program, but you will probably end up learning a little UML (Unified Modeling Language).
In the Unified Process (and many other software engineering methodologies) a technical writer/architect/project manager will create documentation to describe the problem and a potential solution (i.e. the design for a piece of software) to programmers, customers, and upper management. In fact 'working the documentation process' is a sound part of software engineering. One of the methods implored is to create a set of 'use cases'. A use case is a description of the actions on a system/piece of software. Often use cases (documented actions on the system) provide a great template for a user manual.
Books on how to write use cases:
Writing Effective Use Cases
by Alistair Cockburn
Use Case Modeling
by Kurt Bittner, Ian Spence
A book on how to create requirements documents (i.e. creating documentation):
Managing Software Requirements: A Use Case Approach
by Dean Leffingwell, Don Widrig
A book on the Unified Process and Software Engineering (from Analysis to Code):
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
by Craig Larman
Didn't Linus Pauling have his security clearance revoked because of his communist affiliations.
Most of the web application scaling problems come from issues related to session management and load balancing or taxing use of the database. Maybe I've been fortunate, but if you can overcome those problems, you usually can server farm your way out of any performance issues. What other problems have people run into?
How many RoR shops are out there? Sheesh, I see more companies still developing sites with Perl. I'm not trying to knock RoR, I just see a lot of talk and no real action. In fact, I've seen more Python code in production use as well.
If a bunch of chemical engineers wanted to start a new "energy" provider, could they do it? Rather, is the field so regulated as to artificially force (or keep) big players in the market?
Maybe if parents monitored their kid's browsing habits, or parents prevented their kids from meeting strangers we wouldn't have such a huge problem.
It depends. I think both technical and non-technical managers can be successful, but it depends on the company. A small start-up badly needs technical managers. Not only will the managers have their hands in everything, but the key to a start-up's success is innovation. Large companies thrive on politics. So a political savvy management guru often is the better choice. Big companies don't innovate, they try to maximize share holder's profits. Since the goals are different, the managerial requirements are often different as well.
Peter Drucker (a management guru; author of several good books on management) has written repeatedly that the most important asset a manager can have is integrity. He argues integrity and character are the building blocks of any good manager. It's not organization, motivational skills, or the ability to politick.
Incidentally, I think what happened with your company is that you got bought out because you innovated so well. The technical guru worked well in a geek-friendly small company, but probably rubbed the MBAs the wrong way. They wanted to see a ROI fast, not make long-term money by creating a quality product. I don't think the large corporate MBA-think is evil, it's just not a place I'd prefer to spend my days.
What kind of time travel are they talking about here? Isn't that for all intensive purposes impossible. I'll take quantum teleportation instead.
I know this is just an example, but no 30k employee costs just 30k. There's health benefits, office equipment, and a general 'drain' on other resources like accounting, HR, IT, etc.
You'd need a lot of common reusable libraries. Networking, sound, and input are hardly trivial subsystems. Only a big company could afford to roll out their own API. Heck, that's what made DirectX so attractive. I'm sure OSS or even commercial toolkits exist, but it's still collection of lesser used tools to add to a project. Adding too many different tools (especially if they aren't bundled together in a single API) to a project is a known factor in project failure (i.e. you supposed to factor that stuff into a equation to determine the likelihood of success; see McConnell's books).
Of course, NWN2 probably has a higher number of linux users among it's user base than say HL2, Madden, or WoW.
Foriegn newspapers tend to provide a lot of coverage of US politics. In fact, in some cases, the US government gets more coverage that the domestic government. I didn't even feel like I was in a foriegn country when I was in Toronto.
If you want to get good coverage of world politics in the US, watch the BBC or read the Economist!
They're trying to solve management problems with a development methodology. In other words, let's take all the common sense (and politicking) out of project management and reduce it to a set of mechanical rules which are to be interpreted like an axiomatic system. It sounds like a good idea but it just won't cut it in the real world. The real world phenomena of good project management is so complex it can't be described by a simple set of rules. Frankly, what all of these Agile/XP/Scrum/RUP/supervoodoo methodology arguments have been about is that software engineering project management is as "COMPLEX" as software engineering. Perhaps even more so. It's all about problem solving. The problem it's rarely done right. Motivating people, figuring out how they work, and keeping them productive is hard work. Ironically, if you can intelligently have an argument about the finer points of Agile methodologies, you're probably not the problem. It's the managers who give 'peanut butter' manifestos I'm worried about.
It's not a news article, it's more of an overview for programmers. Actually, it's pretty well written, just not a 'headline'. Incidentally, I hadn't heard about the KDE/GNOME stuff until recently. I only ran across Qt when I was looking for an OSS (or just free) RAD tool.
Do you think Hillary Clinton is a pagan or an atheist?
A list of fallacies about the future of engineering/IT and they're rebuttal:
Foriegn students are smarter.
First, would you like to compare the average student at IIT to CalTech or MIT? Don't compare some engineering student at IIT to a liberal arts student at Yale (I think we all know how they turn out).
There aren't enough skilled Americans.
What skill sets? He's not even identifying any specific skills. It's not like I use analysis or quantum mechanics at my job on a daily basis. I think we've all hit the nail on the head by saying corporations are just too cheap. They want 'skilled' workers (their wording not mine) to be as cheap as the non-skilled workers. Wow, there's great economic insight from the Department of Commerce! Okay so every CS department isn't teaching Lisp/Scheme to incoming students, I doubt that's what he's talking about. Oh, and don't whine about american students not having math skills. The average math major has studied so much math the only place they could use it is as an actuary or quantitative finance (another kind of actuary). Frankly, that's a couple of college courses for the mean student at best.
Americans are lazy.
So let me get this straight a brainless poly-sci grad from some Ivy who has no formal training (and probably no managerial experience in the private sector) has become the IT czar for the Commerce department. Yeah, he's really qualified to make such broad sweeping generalizations. However, I'd like to point out that someone in a 3rd world country is less likely to waste (have the oportunity to spend) their one shot at higher education on a Women Studies degree. How many Nobel Laureates does the US produce compared to the rest of the world? So it's not like our best can't compete. I guess those hordes of Chemistry students from India and China aren't flocking to basic research. In other words, there's no point in studying Chemistry, Physics, or Math unless you want to do into research (industrial or academic) for a living.
As a final note, I really wish Robert Cresanti would hold a open forum so I could reply to his assertions in person. Someone needs to set the record straight.