Why a career in computer programming sucks, and a rebuttal.
In a followup posting of Half Sigma's, someone wrote a response that resonated with me, especially the part about a lack of people with a middle-ground attitude towards the profession.
In a followup posting of Half Sigma's, someone wrote a response that resonated with me, especially the part about a lack of people with a middle-ground attitude towards the profession.
- Current Mood:
busy
Profile
gregbo- gregbo
- gregbo's homepage
Page Summary
- jessiehl : (no subject) [+3]
- fauxklore : (no subject) [+9]
- fauxklore : (no subject) [+0]
- (Anonymous) : Omg what a load... [+0]
Comments
I don't understand his insistence that you're either a rock star or a poorly-treated grunt in the software world.
I think part of the apparent lack of middle ground is response bias. People bother to post and comment because they have strong opinions.
Possibly. I don't know offhand if there are more blogs, chats, etc. devoted to other careers than the computer industry. Statistically, you'd think their might be, but it might not be the case that a preponderance of such people would use the Internet to express their opinions. OTOH, I began to notice as early as the summer after my freshman year (1980) that there were people in CS with very strong opinions about things that didn't really strike me as being important at the time (such as emacs vs. vi).
I began to notice as early as the summer after my freshman year (1980) that there were people in CS with very strong opinions about things that didn't really strike me as being important at the time (such as emacs vs. vi).
I noticed this when I arrived at MIT, and these things still don't strike me as being important. :) I consider them to be essentially religious wars and more or less ignore them. The issue of whether the career path is a good one seems like a better subject for debate, but the stuff that's being said, as in many debates over worthwhile issues, seems simplistic at best and downright silly at times.
Non-programmers managing programmers is an interesting issue. As a former line manager, I'll make the observation that the skills needed for management are invariably very different than the skills needed for the worker bee tasks. The real problem is when management gets treated as a reward for being good at something other else.
Finally, I'll suggest that there is no such thing as a good or bad career field. (Well, OK, toxic waste cleanup is probably universally a bad job...) The real trick is to find something that suits you well. I have a great job - most of the time - but it's one that would drive at least 75% of the people in my company nuts, largely because I have to be able to deal competently with a lot of self-important people. I know that isn't easy for many people to find what's right for them, but it is worth the effort.
Having non-programmers manage programmers can be a problem. For example, if a programmer tells a boss that a problem is unsolvable, and that another approach needs to be taken, the boss may not understand (even if the boss is, or was, a programmer). But the entire project may fail if the boss doesn't understand the issue, or doesn't believe the programmer. (The problem might very well not be decidable.) Another issue is that some programmers do not have the type of social skills to communicate with non-programmers. A company may require this of their candidates, but this leads me back to my earlier point: developing those skills can come at the expense of other, arguably more critical skills.
Regarding finding out whether something suits one well, I'll have to think about that. How can you tell, especially if you're new to the field? Having problems in a job could just be a mismatch between an employee and a company (or a group within the company). If there was a history of that, perhaps that would be cause for concern. But in the case of software engineering today, there are lots of external factors that can interfere with really getting a good handle on whether someone is right for the field. (This is probably true of other fields, but I don't know if it's true of all fields.)
By LSATs, do you mean something other than the law school entrance test? Because that's not industry certification (in law, passing the bar exam would be the certification, I guess).
The IEEE Computer Society has a Certified Software Development Professional designation that looks interesting, that you have to pass a test to receive (and they're developing a Certified Software Development Associate test for entry-level people, as the other one requires a certain amount of professional experience). I think it would be cool if it became widely recognized in the industry, and the IEEE is a sufficiently influential organization for that to possibly be feasible.
Software's kind of a young field, and I think that contributes to the problems that you mention, such as conflicting expectations and a lack of established best practices for worker/manager skills and dynamics. I do agree that managers should have some technical knowledge in the field that they manage. Different fields seem to do it differently. Teachers are managed by principals, who have training in education. Lawyers are managed by the partners in their firm, who are senior lawyers. But doctors are often managed by hospital administrators who are not doctors, and academic scientists are managed by university administrators, with a department head drawn from the scientist ranks who is the link between the two. Perhaps the software industry should be studying how these fields make their different approaches work and figuring out what it could apply to itself.
A company may require this of their candidates, but this leads me back to my earlier point: developing those skills can come at the expense of other, arguably more critical skills.
I think that development of the different skillsets can be interleaved. For example, a computer science class could determine grades not only by psets and tests, but by performance in presentations, and similar things (or the department could go the MIT course 6 route and have a required class on communications skills in the EECS industries).
WRT the age of the software industry, other industries that aren't much older don't seem to have software's problems, such as aeronautical engineering. You never hear about shortages of aeronautical engineers and a need to import them from outside the US, for example. The combination of engineering education and professional licensing seems to produce an appropriately skilled workforce – enough for the US to have a commercial passenger airline industry, commercial air freight, military operations, etc.
The IEEE exams could be a step in the right direction. At present, there is a lot of controversy over such exams. For example, on NANOG a few years back, there was a long debate about the value of network engineering industry certifications, such as those one can get from Cisco.
I'll have to check out the course 6 communications skills class. When I was a student, I don't think any of the engineering departments had a required class like that.
1) the aging workforce
2) need for development of a cadre of space professionals with appropriate skills
3) how shortages of people with the right skills (including, by the way, software development)) are impacting the industry
One difference is, of course, that importing engineers from outside the U.S. is not a feasible solution, due to security requirements.
However, the fear of losing work to companies overseas does play into space policy decisions. I read enough of the business section of the newspapers to know that there is a lot of concern about keeping Boeing competitive vs. Airbus, say, so it isn't just the space side of things.
No certification in aerospace engineering either. Professional Engineer registration is common for civil engineers, who deal with public works areas, but more controversial in other fields of engineering and I don't know anybody within the aerospace industry who has bothered.
As for required communications skills classes, in my undergrad days in course 2, one or two lab write-ups in each lab class were graded by a prof from the writing program.
I don't know much about what kinds of software are written in the aerospace industry. From what I have seen on job postings, some it is real-time control. In commercial software, some people who do this design or develop phone software at places like Palm, Motorola, Apple, and now Google. Others design or develop switches, routers, etc. at places like Cisco or Juniper. I suppose robotics companies like iRobot compete for the labor pool as well.
Other people like
Re: communications skills classes, when I took 6.033, one of the design projects and one of the weekly writing assignments were graded by the writing program. The program seems to be a bit more formalized now. But the sort of thing I'm thinking of is where you might have to spend a considerable amount of time explaining what you do to people who have little if any technical background. Not just in writing, but also verbally, and in situations where the company's future might hinge on whether both parties understand each other.
I don't know what the aerospace industry is currently doing to encourage young software engineers to join it, but it seems to me that one obvious selling point is that, for national security reasons, your job is highly unlikely to be outsourced.
The issue is not usually perceived as competition with other industries as an absolute shortage and most of the discussions I've been in are focused on how to get young people to consider math / science careers in general. There is, of course, some competition with the IT world, particularly for more researchy type jobs, but there is some belief that a lot of software types are not willing to work in an environment that requires security clearances.
In terms of solutions, they tend to be things like funding for scholarships. There is also a lot of interest in encouraging more science / math awareness in K-12 as a long term solution.
And, alas, there is a lot of whining and wailing without any action.
I'd kind of like to study for it, but you have to have 9000 hours of experience before you can take it. I won't be there for a while. They're developing an "associate" version for entry-level people.
I disagree that you don't hear about shortages in other industries. I've read about shortages of aeronautical engineers. I don't know why software seems more prone to importing foreign workers than aero/astro - I have to wonder if it has something to do with more aero/astro jobs requiring security clearances.
The course 6 class is 6.UAT. It's a required 6-unit class. The description is, "Learn about different aspects of effective technical oral presentations by being exposed to different workplace communication skills. As preparation for the advanced undergraduate project (AUP), students develop research topics, identify a research supervisor, and prepare a short research proposal for written and oral presentation."
As this relates to software, people who do network engineering or operations may write software, depending on the specifics of their job. A popular, well-known example of such a person is Paul Vixie, who is involved in DNS (particularly root servers), anti-spam, and several other things. Such people deal quite often in open-source software, however. There isn't as much emphasis on software methodology in the open-source world as there is in the proprietary-source world. The IEEE software exams seem more oriented towards that, from what I saw.
OK, granted, you hear about shortages in other engineering fields. Maybe because I'm in the SFBA, the issue of software engineer shortages is brought much more to the forefront, since it's a major backbone of the SFBA economy. It's covered on all of the major news outlets, a bullet item on many US Congress members' agendas, etc. There was, however, an item that caught my eye:
"U.S. industry must appeal to the entrepreneurial streak in many of today’s students by offering entrepreneurial projects within their companies, said Dave Daniel, dean of the engineering school at the University of Illinois at Urbana-Champaign."
This may be significant to the engineering shortage. When I was an undergrad, some people started companies, but not many. It was much more expensive (in 1980s-adjusted currency). Even if you rule out the fact that there was no (commercial) Internet and a telecom industry that was just starting to deregulate, PCs weren't cheap, and there weren't many platforms to do much application development on them. There wasn't much of a gaming, document preparation, or home/small office computing industry, as there is now. Nowadays, everything is cheaper, and platforms are much more open (and becoming even more so), so it's easier to start a company. There seems to be more of an expectation among young people about the possible need to start a company (at least out here).
I read a bit about 6.UAT. It's much more involved than the undergrad theses of my day. Are students required to give presentations to people who have little or no technical background?
Edited at 2007-11-30 04:41 am (UTC)
I'll argue tat the boss not understanding the issue or not believing the programmer is a matter of a bad manager, not a manager who is not a programmer. One of the fundamentals of management is listening to what your folks tell you. And, yes, I know this is a frequent problem. I'd guess that less than 20% of bosses are anywhere near competent at this.
By the way, it gets even more complicated in environments where you have multiple bosses. The person who handles things like my time sheet and my performance reports and so on has very little to do with what I do day to day. My customer is my "real" boss. Now, he does fill out a "report card" annually, but that is designed to review the company, not me personally. Since I'm the only person from my company who works there regularly, however, it amounts to the same thing. Fortunately, my corporate boss cares mostly about how well I'm keping my customer happy, but that isn't a given.
As for finding what suits one well, I agree it's hard to tell. My best take on it is to think about what aspects of the job you do or don't like. Every job has a certain amount of pain in the ass routine and that sort of routine has to be something you can at least tolerate. Reviewing pages of budget documents is not my favorite chore, but it has to get done and I can take some satisfaction in finding something buried deep within that we need to respond to.
My impression is that most of the people I know who are unhappy at work are unhappy because of people issues, not because of the actual nature of their work. I can think of exceptions, though. I have a colleague who has an M.D. and went back to school to study engineering because he felt, during his residency, that most of what doctors do is not really helpful to their patients. I briefly dated a guy who, a year after law school, felt he was continually being asked to do sleazy things and was contemplating a change.
And, frankly, a lot of people are willing to sacrifice career satisfaction for money, but that's another subject.
I've been writing in many languages since '78, I was born to code, and have never taken more than a week to get up to speed on anything new. Cranked out functioning Java code the first day I ever used it while other people on my team, younger than I, were whining they wanted to go take a class.
Programming never changes, accomplishing the tasks is always the same, it's just the syntax and API's that change over time and anyone that's worth a damn can pick up a new language and be pretty fluent in less than a week unless they just don't have the aptitude for programming in the first place and were already struggling.
Anyone that knows assembler, C, C++, Pascal, Java, Basic, dBase, SQL, Perl, Python, etc. can quickly pick up PHP, RoR, or whatever as it's NOTHING NEW.
To answer the question:
"So what advantage does a 60-year-old .NET programmer have over a 27-year-old .NET programmer"
The 60 yo programmer probably knows the underlying architecture of the system having worked with it as it evolved while the 27 yo wasn't even born yet, and won't just throw up his hands in desperation when he gets stuck on something silly that he's seen happen for the last 20 years working in Windows and may know lots of potential workarounds.
That's why us older programmers tend to drive cars that cost as much as the 27 yo's salary and sit in offices with labels like CTO or Director while the 27 year olds are banging on our door whining for help.
However, those 27 yo's will end up being the 60 yo's he wrote about ;)
-IncrediBILL