Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Thinning of the Programmer Gene Pool

By -ryan in Culture
Sun Dec 10, 2000 at 12:20:39 PM EST
Tags: Software (all tags)
Software

Maybe you've heard the jokes about what MCSE stands for, and maybe they're true. Underneath those jokes though, lies a picture of the current tech and (more specifically) programmer gene pool.

Every field has its MVP's and its slackers, but in the past few years I believe I have seen a serious watering-down of the programmer gene pool. Never before have I seen such a disproportionate amount of bad programmers to good ones, and it's affecting not only our reputation but our quality of life.


Since the boom of the Internet there has been a large increase in the demand for tech-savvy individuals, including programmers, network and hardware administrators. Most of this demand seems to be in IT departments and dot-coms but other areas have seen growth as well. A lot of software is being written and the quality doesn't seem to be getting better.

When I speak of 'quality', I am referring to quality on the level that a programmer might see it. Quality of the code. I've worked for fast moving dot-coms and slow old-economy firms, and this statement applies for both: most programmers seem to have a weak grasp of good programming practices and write unmaintainable, undesigned code. When I say undesigned, I am not being an OOP purist here (though I tend to be in certain circles). I am speaking in the terms that we all learned in computer science in high school or college: understand the problem, choose your data/data structures, and apply the right algorithms. That's not even touching the realm of real OOA/D, just "thinking before you speak", so to say. Or as Ice Cube would have put it: "You betta check yo' self befo' you wreck yo' self".

I don't think this is just a problem of compressed software deadlines and bad managament. Has anybody read "Code Complete"? How about the simple programming practices of intuitive variable naming, or writing loosly coupled and cohesive functions? I am not arguing good programming practices for the sake of good programming practices. I believe that the effect of these inept programmers are missed deadlines, the late nights we spend hacking at their spaghetti code, and the many IT depts that wind up with in house software that is buggy and completely beyond refactoring.

How often do you look at code and say to yourself "who in the hell wrote this crap?" How often do you look at a database schema and shake your head in disbelief?

What this really reminds me of is something my dad told me about the energy industry. He is a director for the largest off-shore contractor in the world. They build platforms and refineries and such, and just like the oil industry they go through cycles. Over a few years they grow and grow and grow; they hire anyone they can because they need people. Eventually every idiot gets a job. Ever wonder where the neigborhood idiot works? It might just be an oil company. At some point, there is a shake out and lots of people are let go, usually the half-competent ones are left behind... in bad cases everyone gets laid off.

I have a feeling that something like this might eventually be what it takes to thin the ranks or at least better the ratio of good programmers to bad ones. In the meantime how do fellow software engineers (without hire/fire power) avoid having to clean up after firefighter style programmers? I think I'm at my wits end. If you read a story in the paper about a software engineer going postal it just might be me...

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by -ryan


Display: Sort:
Thinning of the Programmer Gene Pool | 56 comments (56 topical, editorial, 0 hidden)
MCSE (3.14 / 14) (#1)
by enterfornone on Sun Dec 10, 2000 at 04:54:07 AM EST

MCSE isn't a programming certification. That would be MCSD. I'm not sure who they must consult.

--
efn 26/m/syd
Will sponsor new accounts for porn.
Not only in industry, but academia as well (3.25 / 12) (#2)
by discoflamingo13 on Sun Dec 10, 2000 at 05:42:44 AM EST

This is definitely a topic I would like to hear elaborated on. Right now I'm in my undergrad (Comp Sci and Math), and the majority of the people in my classes act like they're waiting for the degree that says "okay- this person works well with computers." Ignoring abstraction, OOP, and any other sort of theory, most of them just want to jump right into the (ostensibly horrible) coding and (quite possibly) large salaries. This kind of talk often crops up among some of the law school and MBA people I know, but how widespread has it gone?


The more I watch, the more I learn ---
If you set yourself on fire, the world will pay to watch you burn.
--- Course of Empire

CS doesn't garantue good programmers (3.66 / 3) (#9)
by bram on Sun Dec 10, 2000 at 11:57:25 AM EST

Hey,

I'm a third year CS student (from the Netherlands), and I must say that having done CS at the University doesn't garantue good programming. They tell you about it but at the university I'm doing they do are starting to do less and less about making good code.

They used to have an indoors programming language that was ideal to teach abstraction and good programming (called Elan), but they decided to dump that for a functional program (also indoors called Clean), C and Java. Though the last 2 are much more used in practice they don't always are the best to teach in, certainly not when the teach do not spend A SINGLE MINUTE on writing readable and maintainable code.

Just wanted to get this of my chest.

[ Parent ]
Software Engineering Course (4.33 / 3) (#10)
by _Quinn on Sun Dec 10, 2000 at 12:14:52 PM EST

   At my college, the introductory courses introduce good design practice in piecemeal -- how to make good classes, how to deal with abstraction -- and the higher level classes more-or-less ignore it. It's kind of sad, but at the same time, what can you do in a say, a compiler course? It's much more important that the code demonstrate an understanding of say, symbol tables and how they're used, then it demonstrate an understanding of good engineering practices (e.g. a symbol table with no upper bound on size, with reasonable big-O complexity, etc) -- because my college teaches computer -emphasis- science, that is, the theory. It certainly helps the student if they design things well in classes where the later labs build on earlier ones, but frequently, it's not known ahead of time if they will or not, and (extra) credit isn't given for good design.

   The professors in the department who teach lab courses want to teach or require a software engineering class, but we don't have any professors with any free time -- and finding another, even if we had the money, would be very difficult, given today's job market.

   My point? I think as computer science and software (etc) advance as fields that you'll start to see a greater differentiation between the code monkey and the engineer and the theoretician, like you have in say, electronics. (That is, electricians/technicians, electrical engineers, physicists.) It seems that in many coding jobs, there's an expectation that the coder be an engineer and an electrician. That's not easy -- that's why so many people can't do it.

-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]
students ignoring concepts (5.00 / 1) (#31)
by cpfeifer on Sun Dec 10, 2000 at 11:34:08 PM EST

Ignoring abstraction, OOP, and any other sort of theory, most of them just want to jump right into the (ostensibly horrible) coding and (quite possibly) large salaries.
I think I might've been one of those people. I knew what OO and abstraction were as concepts in school, but they didn't really hit home until I got a job and started working on a large system (which was a case study in how not to build an OO system), and now I understand completely! If I had it to do all over again, I would've tried to get an internship/coop to try and solidify my "book learning" while I was studying it. In college I didn't have enough time to reflect on what I was learning, and sometimes it was tough to see how all the pieces fit together.
--- "What's the point of waking up in the morning if you don't try to match the enourmousness of the known forces in the world with something powerful in your own life?" - Don Delillo, "Underworld"
[ Parent ]
Bad vs. experienced programmers (3.44 / 9) (#3)
by evvk on Sun Dec 10, 2000 at 06:18:06 AM EST

The author spoke about every idiot getting a job from a company. This reminds me of an anonymous mobile phone company, call it big N. It seems that almost everyone here, who has gotten decent grade from a first programming course can get a job there. How could such a person know anything about programming?! Programming skills are about experience. Big N's, like many consumer product companies, products _are_ buggy. Of course programmers are not the only to accuse: marketing, deadlines, people who design the software, etc. I've never been in the industry so I can't say much of the above. However, I know how bad programmers, who are in the industry perhaps only for the money (that is a bad thing!), can be. The industry's will is also reflected in what is taught: C++ first. That certainly isn't an ideal first language (or a good language at all :-P).

Another thing that I've noticed is that many long-time experienced hobbyist programmers (that includes me, although I don't claim that I'm good, I'm just better than most :-) have chosen not to study computer science or -engineering and go to the software industry. Instead they have chosen to study more "challenging" fields such as mathematics, physics and signal processing. At least I don't find software interesting anymore. Coding used to be nice in the goold old times, doing what you please: nice little programs, perhaps directly hack the hardware, but I just don't want to do that for work with all the API hell, deadlines, stupid standards and all.

(The following would also apply to a previous article "Programmers who just don't get it".) Despite that, I have a few free (that is the only practical way to distribute software for *nix) software projects (I wanted the software!) and I sometimes receive patches. I often must ask people to rewrite them, because they just aren't up to my standards. Also, I'm a bit nazi on what features I accept, to keep it simple and manageable. Many other projects seem to accept almost everything. When one looks at the software found at, say, freshmeat, much of it actually is crap, won't compile, gives lots of warnings, the code is a horrible spaghetti to modify (in addition to that there might be no sense of coding standards) and new features are despite being added all the time. Comments and documentation? I could use them too, but that's uninteresting :-).

Most definitely (none / 0) (#44)
by -ryan on Mon Dec 11, 2000 at 03:55:11 PM EST

Most definitely. This affects Open Source too.

[ Parent ]
A sense of balance (4.40 / 10) (#4)
by BoredByPolitics on Sun Dec 10, 2000 at 06:54:10 AM EST

I'm fortunate to have followed an enlightening path during my career. Started off as a Pascal programmer, work dried up for a while so moved into Software Support for a couple of weeks (ended up staying for 10 years), then went back into programming a much wiser person!

This wasn't all with the same company, so I got to see different styles of handling the coding standards problem.

When I went back into programming I was somewhat anal about readability of code (including choosing descriptive variable names, even if they took, gosh, 5 extra seconds to type), mainly due to the frustrations I'd experienced in support with sloppy coding. Over the last couple of years I've relaxed into a more balanced style - I'll use a throwaway variable name for a small loop, where before every variable name had to be meaningful - however, having also had to deal with some very crap code too, I'm always thoughtful of the person who's going to maintain my code after me. I don't want them cursing me the way I've cursed some of my predecessors!

My point is (eventually) that we're always going to see varing styles of coding, it's only as you gain more experience that your coding style becomes more considerate.

--

--
"Every contract has a sanity clause", "Sanity clause! Sanity clause! You can't fool me, there's no such thing as Sanity Claus"

coding standards in a previous life (4.00 / 18) (#5)
by TuxNugget on Sun Dec 10, 2000 at 06:57:52 AM EST

I was once involved in a coding project that involved about 4 people. It was the first project I had ever helped manage from a technical lead, and it produced some academic research software that is used in a human-subject-research laboratory environment.

I brought to the project a cohesive vision about the project structure. The project would use a perl client-server as a back end coupled to a front-end web interface. I would take responsibility for the back end, and provide a copy of the language that the front end would use to communicate to the back end. Summer student workers provided the front end. One was very good with perl, the other ok, one was going to provide a real-time interface as a java applet, and the last designed buttons and other GUI elements and did some of the testing. All of these guys were fairly weird, one had a nose ring, the other an earring, and the third had painted all of his fingernails and toenails black.

To make a long story short, the project was mostly successful. One of the front-end perl coders wrote a lot of spaghetti, and would have all these bugs that could be traced to global variables used by local subroutines. The perl directive "use strict 'vars';" would fix this, and I made a point of showing the programmer how this directive let you write cleaner code. His coding improved, but he eventually left the project for a real job. The java programmer never finished anything, even when we threatened to fire him. The other perl programmer was fairly good, and getting better for all this experience.

When I left the project, the good perl programmer had taken a staff position at the university laboratory that developed the project, and was left with complete responsibility to maintain the code. Having to do all that maintanence himself clearly made him a better perl programmer, but also embittered him to changes or even having others add new modules (since he might have to debug them after they leave). Yes, there were bugs even in my code, and it "wasn't worth a shit".

As I listented to the problems, I began to realize that many of my 'bugs' were not bugs at all, but simply involved a clash of visions about the scope and nature of the project. I had pictured something very broad and extensible, which required a certain kind of structure. He wanted something that he could make a living off of for 4-5 years maintaining. He preferred stability over extensibility, and also seemed to connect his job stability to his ability to monopolize knowledge about how the code really worked. That involved taking apart some of the structure and groundwork I had created.

Thats ok, I guess. I am wondering how familiar this sounds to you, and how much of your gripe comes from maintaining the code written by poor coders and how much comes from people who just share a different view about project scope and management.

Spot on! (4.50 / 2) (#6)
by BoredByPolitics on Sun Dec 10, 2000 at 07:25:38 AM EST

Thats ok, I guess. I am wondering how familiar this sounds to you, and how much of your gripe comes from maintaining the code written by poor coders and how much comes from people who just share a different view about project scope and management.

Extremely - I come up against this on a very regular basis. The company I currently work for doesn't own the majority of code it writes - it's owned by the customer.

This has an interesting effect on the maintainability of the code. It's easier to make the code hard to maintain, and therefore (supposedly) ensure our future employment, than to simply provide a better service than the customer could get elsewhere (or find inhouse).

Of course, my company's methods will be self defeating in the long run, I just hope I manage to find a new job before that happens (yes, I have tried to do something about it, but my head hurts too much from all the wall bashing it's gone through).

--

--
"Every contract has a sanity clause", "Sanity clause! Sanity clause! You can't fool me, there's no such thing as Sanity Claus"
[ Parent ]

academic crap (2.66 / 12) (#7)
by maketo on Sun Dec 10, 2000 at 11:22:21 AM EST

While I agree that higher education makes one a better person owning a broader spectrum of tools that help fight world problems, in the case of BS Cmpt Sci I must disagree. There is a huge difference between what your professor teaches you about software design in a software design class with the obligatory example of disigning a store or warehouse or cashier system, and something you build in real life. To me cmpt sci boils down to one thing - understanding how your machine works. Once you are able to follow and predict your code the way your machine does, you are very well equipped to design and code anything. This is, in my humble opinion, a big error on behalf on educational institutions -> they do not teach your "eager to get my diploma and buy that damn BMW" cmpt sci grad to care for and connect to the object of their study. This said, if it were up to me - all should start their cmpt sci education with asm/c and hardware courses and then move up to OOD/OOP issues, networking et cetera. But should this happen, the university will shortly face a real shortage of potential graduates! Take my word for it. I myself have mostly no respect for 99% of the rest of my computer science "colleagues" here at the university. Call me self-content but I believe I speak for any geek outhere who spent nights coding things they love as opposed to his "colleague" who wrote the obligatory school code and got by with a degree.
agents, bugs, nanites....see the connection?
CS isn't about programming (4.12 / 8) (#11)
by fluffy grue on Sun Dec 10, 2000 at 12:46:01 PM EST

The big misconception held by nearly everyone seeking a CS degree nowadays is that CS isn't about programming. It's about the science of computation (hence the name 'Computer Science'), NOT about how to program things. Granted, there's a lot of programming involved in solving computation problems, but programming is a tool for CS (which, in turn, leads to better understandings of the tools involved), rather than CS being a way to learn programming.

Computer Science isn't about real-world programming or writing CGI scripts or programming games or learning how to hack or any of the other things I see kids coming into the NMSU CS department with expectations of learning. It's about algorithmic complexity and correctness, the mechanics of how computation occurs, the equivalence between code and algorithms, and the like.

Real-world programmers can benefit from a strong, theoretical CS education, if they're able to approach problems from different perspectives and actually use the theoretical basis in CS.

As evidence, the vast majority of CS dissertations have little to no programming involved. The vast majority of CS classes have only moderate levels of programming involved - except for the programming classes, most CS classes only use programming as a tool to solve problems which can't be reasonably done by hand.

CS isn't about programming.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Dissertations hmmmm (3.00 / 2) (#13)
by maketo on Sun Dec 10, 2000 at 02:37:33 PM EST

The gross number of dissertations are just theoretical excursions - most of them never, ever get to see the light of practical implementation. I have read a number of them - you would be amazed to see what people spend their time on. While I agree that computer science is not about sitting down and coding up a 100,000 line of code - I also would like to point out that many a software you use today started out as just that. While it is nice to sit down and theoretisize about software complexity and the wickedness of software design, you cannot circumvent one essential issue - if you do not understand how your machine works and if you have not coded huge pieces of software, you will never be able to theoretisize about the faults of the process or even about the problem itself. So, many of the issues you pointed out have to do with math and strong mathematical education, rather with computer science (can anyone really tell me what the science part in the computer science is?), I agree people can benefit from a strong theoretical education in the field. I also think that many a problem arises simply from incomplete and false designs, but also from bad and sloppy coding. Looking at coding as a tool is an invention of academics who never really learned how to do it, or never really had the inclination to. I myself am a Cmpt Sci major and will be getting my degree in three months. I also want to go into MSc/PhD. but I also believe computer science is as much about coding as it is about developing and observing a system of interrelated components and commenting on it.
agents, bugs, nanites....see the connection?
[ Parent ]
From a PhD student (5.00 / 3) (#14)
by fluffy grue on Sun Dec 10, 2000 at 03:08:45 PM EST

I'm a PhD student in computer science. I'm an oddity in that I know how to code, enjoy doing it, and do it well. However, I'm not in CS for the money, I'm into CS because I'm into CS - the theory is just cool. I can also apply the theory to the practice and vice-versa; I'm an ambidextrous thinker in that regard.

The science part in computer science: You have a thoery about something. You try it out, experimentally. If it works, it works. If not, it doesn't, and you try something else. Computational algorithms to do different things aren't derived from mathematical truths, since derived algorithms tend to REALLY suck (for example, derived sorting takes factorial time!). So CS is definitely not just about applying mathematics - there's a lot of creativity involved.

You don't just derive things from other truths and plug them in. You have to guess a lot, try out a hypothesis, and just keep on relying on intuition and the like until you get something that does, in fact, work. Mathematics is used in the proof of it working as stated, and programming is used in the demonstration of it working, but the algorithm itself is neither mathematics nor programming. It's very much like chemistry - most of your work goes on paper as theoretical stuff of what should happen, mathematics is used to justify the "should," and only then do you go into the lab to prove that it does happen.

Also, I take major offense to your statement that "Looking at coding as a tool is an invention of academics who never really learned how to do it, or never really had the inclination to." That is just wrong on so many levels that I'm not even going to try to discuss that unless you can come up with something better than a generalized ad-hominem attack.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Apples and Oranges (none / 0) (#45)
by -ryan on Mon Dec 11, 2000 at 04:04:05 PM EST

Computer Science is as much about computers as Astronomy is about Telescopes. Instead, I believe it should be referred to as computational theory.

Contrast the difference in course work for a Comp Sci major and an EE major.

[ Parent ]

I disagree somewhat with your rebuttal (3.60 / 5) (#16)
by 0xdeadbeef on Sun Dec 10, 2000 at 04:29:15 PM EST

Don't you think it is a bit disingenuous to present CS as strictly dealing with the abstract? Most of CS would more properly be called applied CS, as it focuses mainly on techniques for dealing with real world issues. You're into computer graphics, which is itself based on the underlying assumption that there is hardware generating an image. There is a lot of theory involved, but the theory itself exists as only a tool to solve the original problem: how can I make images with a computer?

It serves to further the ignorant ideas of the previous poster to present CS as existing in some kind of ivory tower seperated from the realities of programming. CS isn't programming, but it is an important part of it. Part of learning how to program well is learning the hows and whys of what you're doing, and this is were the confusion lies. A programmer who doesn't know at least some theory isn't worth a lick of spit for doing anything more complex than writing scripts and data entry screens.

The other part of programming is honing the skills that allow one to write programs that are extendable, understandable, and correct, while striking a balance between those attributes and the need to be efficient and to meet deadlines. This aspect more properly falls under the guise of "Software Engineering", though I believe that software engineering, as it is currently understood and taught, does little more to teach these skills than drone into the heads of students that they need to have them.

People see a failing in the CS degree for not teaching the latter half programming. That may be a valid criticism, but when they suggest that one is better off by not having the degree, or that people with CS degrees as a rule are incompetent, they are only showing their own willful stupidity. A degree is a piece of paper. The competence of a person depends inate ability, on how much effort they put into their own self-improvement, and on the quality of their instruction.

There is no better place for one who values self-improvement than at a university (or college, technical school, what have you). No corporation is going to be more intellectually stimulating than a good school, and no corporation is going to provide better instruction, on theory or on practicality. I really value my education, not so much for what it taught me, but for the opportunity to spend those years working on interesting problems, both of the assignments and those I tackled for my own enjoyment. While I was learning the first part of programming I had plenty of time to practice the second part. You cannot do that in a corporate environment, where deadlines rule and worse is better seems to be the prevailing philosophy.

[ Parent ]
I agree with you somewhat (none / 0) (#20)
by fluffy grue on Sun Dec 10, 2000 at 07:18:04 PM EST

Software engineering and computer science are completely different things. Most people who want to go into the real world of programming want to be software engineers, not computer scientists, and so they really should get a software engineering degree, not a CS degree. I don't believe I said anything which contradicts that. :)

As far as how graphics go: computer graphics are more about algorithms than hardware. In fact, most graphics research is totally detached from the underlying hardware, except for research into the hardware itself. Research into speedups are about reducing algorithmic complexity and overhead, not about getting uber-framerates. Yes, the research is about how to get the computer to display something, but it's in terms of the algorithms and methodologies used, NOT in terms of the code implementing the algorithms. There's a huge distinction there, and that's what I was attempting to draw in my rebuttal.

Did you know that in academic computer graphics research, "realtime" and "interactive" mean "doesn't take more than a few seconds per frame"? Hardly what the mainstream means by "realtime." Also, my own engine is more about having a testbed for generalized algorithms, not having anything particularly high-performance, and from what I've seen, this is the norm within graphics research circles.

Basically, except where we're both using the term "computer science," we're talking about different things. You're talking about software engineering, not CS, and real-world programming is engineering.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Another analogy (none / 0) (#21)
by fluffy grue on Sun Dec 10, 2000 at 07:23:55 PM EST

Not to apply increased kinetic energy through fisticuffs against an expired equine, but consider the analogy of physics vs. mechanical engineering. They both deal with the same thing, but different aspects of them. A mechanical engineer designs and implements a bridge, while a physicist determines properties of bridges as a whole. Similarly, a software engineer designs and implements software, while a computer scientist determins properties of software as a whole. It's not that one is "better" than the other, they're just different, orthogonal... A physicist needs some knowledge in mechanical engineering and vice-versa, and a computer scientist needs some knowledge in software engineering and vice-versa. They're related, but different - cousin disciplines, if you will.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Hmm... (3.00 / 3) (#17)
by 0xdeadbeef on Sun Dec 10, 2000 at 05:00:41 PM EST

How do you feel about not using computers at all, but a pseudo-code that is evaulated without a computer? It certainly forces one to learn how to trace code, but i's even more abstract than using a real high level language. This is exactly what Georgia Tech does for its intro CS course.

[ Parent ]
It sounds OK (3.00 / 1) (#18)
by maketo on Sun Dec 10, 2000 at 06:27:39 PM EST

but why avoid the very same machine you are trying to mimic through the pseudo-code when you can use it to teach people the way that machine works? I myself understood many a thing after I sat down with my Turbo Debugger and my Turbo Pascal code....I still also believe that people should be taught asm as their first language. I also still maintain that if a university decides to start up with asm - not many a student will get their degree. And we all know that universitiy is not about education, it is about making money.
agents, bugs, nanites....see the connection?
[ Parent ]
Machines are all different, algorithms are eternal (4.00 / 3) (#19)
by 0xdeadbeef on Sun Dec 10, 2000 at 07:14:54 PM EST

Believe me, that's exactly how I felt while taking the class back in '93. Having experience with BASIC, TI-85 programming, and Turbo Pascal, I found it annoying as hell. But afterwards I thought it was a pretty darn good idea. It's an excellent weed-out course, as it does a good job separating those who want to program from those with dollar signs in the their eyes. But aside from that, it has a great deal of value for teaching purposes.

Even though the pseudo-code has a specific syntax, the class really drives home the distinction between "algorithm" and "program". A programming language has all sorts of issues that are inconsequential to the algorithms it is used to implemenent, and so do compilers. The pseudo-code gets rid of all that. And since there is no way to execute the code, it forces the student to really understand what their code is doing. There is no "programming by evolution", whereby students tweak, compile, test, repeat until it works, without understanding what the tweaks do.

At one point they started making the engineering majors take the class. In general, EEs absolutely hated it, and did nothing but complain. The weird thing was that IE majors tended to do pretty well, better than the average CS, at least in my experience as a TA. I attribute that to an appreciation for abstraction, which EEs seem to lack, as they are focused on physical hardware. You sound more like an EE.

I think it would be absolutely foolish to start with assembly programming. If you're going to take the low-level approach, I'd start with Turing machines, and build on from there, à la The Diamond Age. Assembly language is bad for the same reasons as any programming language, and it carries all the baggage of whatever architecture you are using. Besides, do you really want to teach recursion with assembly? Does a student really need to understand calling conventions, and how to implement a stack, that early in the game? When they start dealing with pointers, should they implement a heap as well? Why mix all those issues of varrying complexity, when you can start with abstractions and fill in the gaps as the students become more advanced?

I believe anyone can learn to program, given sufficient motiviation to learn, regardless of their aptitude and eventual skill level. Scaring people with unneeded complexity at the beginning is hardly a productive way to teach.

[ Parent ]

You are mostly right (4.00 / 1) (#53)
by GreenCrackBaby on Tue Dec 12, 2000 at 06:17:18 PM EST

This said, if it were up to me - all should start their cmpt sci education with asm/c and hardware courses and then move up to OOD/OOP issues, networking et cetera. But should this happen, the university will shortly face a real shortage of potential graduates!

If my experiences are anything to go on, this statement is an accurate predicition. My university did do things this way. It was quite humorous actually...1st year we had ~500 students (most your typical "geek"). We had to learn ASM, and lots of logic/math. Second year we had 110. More logic, much more math. Third year we had 50. Almost all those geek guys dropped out in favour of the faster and more catering tech colleges.

On the plus side, I feel like I am a very good programmer as a result. It's amazing how much of the theory I learned (that I hated to learn) I've actually used now.

[ Parent ]

I almost object. (4.25 / 12) (#8)
by Pseudonymous Coward on Sun Dec 10, 2000 at 11:42:55 AM EST

Let me preface my comment with a bit of background information: I'm the senior engineer and manager for a small team of (mostly web) programmers at a large financial institution. We develop software under constantly less-than-ideal conditions: time pressure, cost pressure, vague business requirements and so forth. This isn't unusual for engineers in a nontechnical industry, but it does compound the common problem of management understanding what can and can't be done under those contstraints.

In the meantime how do fellow software engineers (without hire/fire power) avoid having to clean up after firefighter style programmers?

I'm a software engineer with hire/fire power, so maybe my commentary isn't quite from the perspective you're after. Nonetheless, I have to comment about this.

My entire team is firefighter style programmers. Maybe this is regional, but where I come from, firefighters -- people in hats and asbestos suits -- are considered competent under pressure, able to act in teams or individually for the common good, and generally worth every penny they're paid.

When a request comes in, it's like an alarm going off in the station house: everyone slides down the pole and suits up, excited about being able to use our skills to help someone else. Does that mean that, in the thick of things, corners are cut and quality suffers?

I am speaking in the terms that we all learned in computer science in high school or college: understand the problem, choose your data/data structures, and apply the right algorithms.

The people on my team aren't all superstars, cranking out top notch code no matter what. Everyone has strengths and weaknesses, but from the perspective of your lament, these folks are downright bad-ass. If you don't know the basics of your work -- be it fire suppression or short-cycle software development -- the end result of your effort is going to depend almost entirely on the luck of the draw.

The point I'm trying to make is that you shouldn't equate so-called "firefighters" with the inept programmers you're worrying about. We all have to face the demons of maintaining Someone Else's Code at some point, and all you can do is say "this sure sucks," with a shrug of your shoulders as you dig in. I've personally had to live through this (a certain VB app *shudder* with variable names like X, Y, Z comes to mind). Being competent implies bearing a certain amount of load for those who aren't -- end users, managers, or programmers.

You can't expect to live in an ivory tower of perfect code and pleasant engineering and design all the time. The real world will obstinately refuse to conform to your expectations.

While I sympathize... (3.66 / 3) (#35)
by porkchop_d_clown on Mon Dec 11, 2000 at 07:05:50 AM EST

I really have to come down against celebrating "firefighter" programmers. While I have certainly spent a good portion of my career in that mode, programming is not like real firefighting in one particular way: Forest fires are often acts of God. Software bugs are always caused by human error.

In other words, if the orginal programmers had done their job correctly, you wouldn't need to be a "firefighter".



People who think "clown" is an insult have never met any.
[ Parent ]
Now, that's a good point. (3.00 / 1) (#56)
by Pseudonymous Coward on Tue Dec 12, 2000 at 09:47:52 PM EST

Forest fires are often acts of God. Software bugs are always caused by human error.

You've got a solid, valuable point here. Forest fires are random, uncontrollable occurrances.

But I live in a city, you see. A city is the sort of place where fires are caused by any of carelessness, maliciousness, neglect, and ignorance.

Those same characteristics happen to describe Other People's Code under certain circumstances. Being able to handle those issues with dispatch is something to be celebrated indeed. The ability to react to adverse situations with competency is something I consider to be a positive attribute.

The "firefighter" programmers I work with are solid, reliable people under almost any circumstance. My point in the larger post above was to differentiate them from merely incompetent and unprepared programmers, who are the people who leave the unmaintainable messes we all love to hate.

[ Parent ]

I object to your almost objection. (4.00 / 2) (#46)
by -ryan on Mon Dec 11, 2000 at 04:28:50 PM EST

small team of (mostly web) programmers at a large financial institution

Welcome to the club.

My entire team is firefighter style programmers. Maybe this is regional, but where I come from, firefighters -- people in hats and asbestos suits -- are considered competent under pressure, able to act in teams or individually for the common good, and generally worth every penny they're paid.

I figured eventually that this analogy would get picked apart. I have nothing against fire fighters. I have alot of respect for them, as well as all other public servents that put their lives at risk for us. The reason I use the term fire fighter is because I couldn't think of a better term for someone that rushes to a problem and starts spraying (code). In my experince real fire fighters are more methodical with the way they approach danger. I wish certain programmers would take the extra few seconds (remember I'm not asking for a 500pg risk analysis) to understand exactly how they are going to attack a beast before doing so and employ decent coding practices. Maybe these gung-ho individuals react more like a rookie firefighter than say a fire chief. I suppose there is no replacement for experience.

I do not expect to live in an ivory tower. The examples I gave (in the rant) were just simple little things a programmer can do to make a world of difference. If time is your enemy there is always eXtreme Programming. I really don't feel that there is any excuse for unmaintainable code. I feel I've worked on enough projects to be able to say that.

[ Parent ]

What I did... (3.66 / 6) (#12)
by Carnage4Life on Sun Dec 10, 2000 at 01:32:56 PM EST

I have a feeling that something like this might eventually be what it takes to thin the ranks or at least better the ratio of good programmers to bad ones. In the meantime how do fellow software engineers (without hire/fire power) avoid having to clean up after firefighter style programmers?

While working on this project I had to deal with a bunch of style issues with a team of people that were primarily very good programmers. Basically my solution involved trying to catch style issues as quickly as possible by regularly viewing other people's code and offering suggestions as to why things should be changed when I noticed anything that was a problem. I found out that most of the problematic code was changed if I could convince the developer that using my suggestions would lead to less bugs without unduly harming performance. Listed below are a couple of issues that we faced and some I won while others I didn't. They are C++ based so if you don't know the language they might seem like Greek (substitute a language you don't know for Greek if you happen to know it) to you.
  1. Writing your own data structures from scratch (Hashtable, LinkedList) when the STL already exists.

    This was solved by providing a link to documentation of the STL and pointing out that there was already an efficient library data structures and algorithms provided in the language.


  2. Using char* instead of std::string and even worse using char** for out parameters instead of std::string&

    Simply pointing out that a lot of the bugs and security holes in C programming are related to char* related problems and also the flexibility of the string type was all it took.


  3. Overloading the array index operator '[]' but making it return a copy instead of a reference to the actual object.

    This problem was especially annoying because it meant that to get a pointer to an object inside one of his homespun data structures was impossible. So to alter an object I had to remove it and reinsert it. Even worse I had to remember to do

    my_type* obj = his_data_structure[0];
    obj->do_something();
    delete obj; /* delete since it's a copy */


    to avoid memory leaks. This was completely counter-intuitive to how the '[]' is used in general practice. He mentioned that he did this because he didn't want people altering the objects while in the data structure but realized it introduced memory leaks and inefficiencies involved in creating unnecessary copies once I mentioned it.


  4. Creating accessor functions ('get' methods) that obtained two values at once to save a function call.

    Which meant he had lots of functions that looked like this char* getName(int* id_number). This meant that if I wanted to get just the name of the class I had to create a dummy variable to pass to the function since it didn't check for a NULL and would attempt to store the id_number in whatever was passed in.

    He simply assumed that anyone who wanted to get the name of the object would always want the ID number which proved to be false when I started using his objects. Thankfully he realized that trying to second guess the people that would use your API was a bad idea and promised to change it next time we






Extra points for the Spiderman picture! (3.00 / 3) (#23)
by pb on Sun Dec 10, 2000 at 08:27:59 PM EST

I agree with you on almost all the points here, but maybe that's because you're writing in C++. :)

The STL (or at least the implementation of it I've used) *is* actually surprisingly fast, and provides some nice functionality. Of course the templates come in handy, and having resizable arrays (Vectors) as a class is a little easier than doing the resizing yourself.

I haven't messed with the String type much, but I always found myself converting back to a char* for one library call or another. And I absolutely love using a char** for parameters. Really, once you've figured out how to do decent memory allocation/deallocation in C, using a char** is no problem. Just curious, how would you do something like strtok() to parse a String in C++?

Writing your own class that overloads a well-known operator and making it do something non-intuitive is evil. I can understand how a first-time programmer could end up doing that, but [] in C returns a reference by design, and once you have that, it's trivial to copy the memory yourself! If you want to make it read-only, then write a function that just returns a copy when given an element number.

That final example is just strange. I wouldn't write it that way, but if I did...

Could you make that parameter a default argument, and check for NULL? Then you could ignore it entirely. And if you wanted an id_number, you could discard the return value. Although it would look very weird calling getName(Id_num) just to get an id number, and not a name!

char* getName(int* id_number = NULL) {
if (id_number) (*id_number) = id;
return name;
}
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
I agree with everything you two have said ... (4.00 / 2) (#37)
by vrai on Mon Dec 11, 2000 at 09:50:27 AM EST

... except the use of strtok (). It is quite patently the work of satan, I quote the strtok man page:

BUGS
Never use this function. This function modifies its first argument. The identity of the delimiting character is lost. This function cannot be used on constant strings.

I (like many other programmers I've spoken to) wrote a little class that did essentially the same thing but with added functionality and less string mangling.

Until recently I used char * religiously, but once learned the STL is fast and flexible. The only downside is that with VC++ you have to disable the debug tokens warning lest you get twenty million 'Debug token truncated' messages.



[ Parent ]
Really? (3.00 / 2) (#39)
by pb on Mon Dec 11, 2000 at 01:39:39 PM EST

I know what strtok() does, and the only thing I did to modify it was to dynamically allocate an argument list for it. If I didn't want the string I pass modified, well, I guess I'd copy it, but generally I just want it tokenized.

I suppose I could try to write a class in C++, but I'm pretty happy with just having a simple wrapper in C. (I also get back the number of arguments, whee!)

So I guess you had to rewrite the whole function to use the STL? (feel free to e-mail me!)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
strtok() considered harmful. (Or something.) (4.00 / 1) (#43)
by Morn on Mon Dec 11, 2000 at 03:26:40 PM EST

Just curious, how would you do something like strtok() to parse a String in C++?

You mean a 'string'? ('Strings' are Java things :-)

like this, I believe:

ostringstream tok(theStringIWantToTokenise);
string putMyTokensInHere;


while(tok) {
tok >> putMyTokensInHere;
doProcessingOn(putMyTokensInHere);
}

Erm, it'll only work if you want to use whitespace as your delimiter though. If you want to use something else, you'll have to use tok.get(buffer, length, delimiter) instead of tok >> putMyTokensInHere;, where buffer is a char buffer, and length is it's length. Much less clean, IMHO (but more clean than strtok).

If you really want something nasty like strtok(), do a find on the string and replace the delimiter with a \0, call .c_str() and add the offset you got from subtracting the result of the previous find call from .begin() :-).

Note that ostringstreams aren't supported by GCC in current release versions, but you can use an ostrstream instead, if you get the C-style string out of your string (with string::c_str())

Pedants also note that I've left the std:: off deliberately.

[ Parent ]

Powerful + Abusable == Harmful (2.00 / 2) (#50)
by pb on Mon Dec 11, 2000 at 08:59:07 PM EST

What's the difference between an ostringstream and an ostrstream?

I figured that it would probably involve a .c_str() somewhere in there...

I actually need to get back into trying to program C++; I find the STL to be rather interesting, and I'm hoping I can use it to my advantage. Maybe I'll go back to trying to write the Great American Othello Game again, or reimplement one of my C projects to use STL data types, or redesign it with classes, or something...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Re: Powerful + Abusable == Harmful (4.00 / 1) (#55)
by Morn on Tue Dec 12, 2000 at 07:03:52 PM EST

An ostringstream uses a c++ string object internally, an ostrstream uses a C style nul-terminated string [and has a maximum length corresponding to its buffer size]. Yes - to use an ostrstream with a C++ string, you need to use .c_str()).

I might have these the wrong way round, and, thinking of it again, I think I should have used istringstream in my last example. I'd need to check the docs.

I don't think ostrstream and istrstream are in the standard any more (but I imagine most compilers will continue to support it, for compatibility).

[ Parent ]

StringTokenizer in C++ (4.00 / 1) (#54)
by Carnage4Life on Tue Dec 12, 2000 at 06:18:01 PM EST

The local C++ guru showed me a quick way to implement a StringTokenizer class similar to Java's in C++.


#include <iostream>
#include <string>

class tokenizer {
string s, delim;
string::size_type pos;
public:
tokenizer( string xs, string xdelim ) : s(xs), delim
(xdelim),pos(0) {
pos = s.find_first_not_of(delim,pos);
}
bool has_more_tokens() { return pos!=string::npos; }
string next_token() {
string::size_type end_pos = s.find_first_of
(delim,pos);
string token = s.substr( pos, end_pos-pos );
pos = s.find_first_not_of(delim,end_pos);
return token;
}
};

int main() {
string test = " Tokenize me, \n baby! ";
string delim = "\n\t ";
tokenizer t( test, delim );
while( t.has_more_tokens() )
cout << t.next_token() << endl;
return 0;
}




[ Parent ]
Overoladed frustration (3.00 / 1) (#41)
by aphrael on Mon Dec 11, 2000 at 02:35:53 PM EST

Overloading the array index operator '[]' but making it return a copy instead of a reference to the actual object.

While I agree with the point you're making here, I'd like to note that there can be a problem in the other direction. One of the things that's nice about the STL containers is that they can provide the *appearance* of array indexing while actually using some other storage mechanism (binary trees, etc) behind the scenes.

This means that once in a while you can find that the order objects get rearranged for you (Even in arrays this happens --- if the array is dynamically resizable, for example). If you have a pointer to that object, and a questionable implementation of the container, you may find that the object moved while you didn't expect it to, the pointer became invalid, and BOOM.

Creating accessor functions ('get' methods) that obtained two values at once to save a function call.

Wouldn't it be more clear to create a struct which contained the two value types he wanted, and then return *that*? I'll admit, i've been guilty of this mistake, usually when making quick bug-fix modifications to existing code, and it isn't that uncommon in interface-driven programming, but I can see why it would be frustrating ...

[ Parent ]

Hashtable (4.00 / 1) (#42)
by Morn on Mon Dec 11, 2000 at 03:10:19 PM EST

Writing your own data structures from scratch (Hashtable, LinkedList) when the STL already exists.

Not that I want to be pedantic or anything, but there isn't a hashtable in the STL (there is in SGI's STL library [as used by GCC, I think], but it's an "SGI extension")

[ Parent ]

I still do not agree, then some (3.00 / 5) (#15)
by maketo on Sun Dec 10, 2000 at 03:54:37 PM EST

There have been numerous documented cases of academics hired to implement different systems, many of which ended in failure, both financial and professional wise. As a person who is still struggling in BSc but who has read a ton of papers in CS - I certainly agree with some points you make. It was not an ad hominem attack - many of the professors at my university are contributing to the theoretical aspcets of the science, yet I believe only one or two actually build ___working___ systems. Now, maybe to you answering the question "does something compute" is the essential one, however when it comes down to __building software__ , the question is usually not if something computes but much more down to earth one. You will never convince me that the "software engineer" (besides the broader intellectual base) has any whatsoever advantage over your average Joe Hacker - Machine Lover. We are not talking about the theory behind genetic algorithms here or the distributed agent frameworks or whatever, we are talking about software that at first sight has a perfect theoretical background, say, Microsoft Word. Or Linux. Or AutoCAD. Or Oracle. All of these are systems that are thought to be very well understood, the domains are explained, yet you find them disfunctional at many a point in time. So, PhD. tell me why? Is it because of the wickedness of the problem? Or because of inadequate tools? Or because we simply do not have the right process in place? The last one would be a managerial issue, thus not even in the domain of computer science? Or is it? What new theory could you invent to apply on a text processor such as Microsoft Word to make it better or bug free? You know, computer science lately reminds me of the North American way of practising psychology - trying to survey and questionairre everything and then statistically average it over the sample so that we can all fall within the same model. It too falls within the domain of "science" - a psychologist builds a theory, surveys the sample, has a control group and then statistically displays the results. Sometimes the theory is confirmed, sometimes not. In absolute terms this, however, means nothing. Just as your focused PhD on "FIle cache system focused on Mobile Computing" does not mean squat until it sees light within an operating system that millions will run. This does not mean, research should not exist. It just means that theory and practice need to be closer together. In their abstract thinking, many a person tends to forget the details of the system - something that, however boring for your average high-level academic, needs to be addressed. Right now, a chemist has a tube that has known specified values, the biologist has a microscope and the physicist has well-defined laws. Mathematician has theorems and proofs. What does the computer "scientist" have? A toolbox of routines that are supposed to work according to specs but we dont really know if they really will, and a description of a problem that cannot be understood until solved. I will be a PhD one day and I will not resent the statement that coding as a tool is invented by academics who dont know how to code or are afraid of it. After all what works on paper might not at all show to work in code. That is, if you are even able to implement it.
agents, bugs, nanites....see the connection?
Was this in response to me? (4.00 / 1) (#22)
by fluffy grue on Sun Dec 10, 2000 at 07:32:55 PM EST

Scoop has lately been misparenting posted comments on occasion, I've seen. Oh well, its code isn't provably-correct, so... ;) So this response is assuming that as a precondition.

Anyway. I have a hard time following your reasoning/rambling. You're saying that software engineering products written by academics have been shown to end in failure? Well, I've never said that academics were good software engineers, or anything of the sort. I've been saying the opposite, in fact.

Also, Microsoft Word has no perfect theoretical background, nor does Linux nor AutoCAD.

You also seem to be resorting to hostile ad-hominem attacks. I never said I was a PhD, I said I was a PhD student (and yet you called me "PhD" in a very condescending manner).

The line I originally called an ad-hominem attack was, in fact, an ad-hominem attack. You were saying that it's an excuse made by academics for not knowing how to program. It's not an excuse, it's a simple statement that CS isn't about programming, it's about the science of computation, much as how physics and mechanical engineering are related but not even close to the same field.

Never once have I said that CS is about building software. Just as physics is not about building bridges, CS is certainly not about building software. If you cannot see the distinction, then why are you, yourself, on the track towards a PhD?

Finally (obAdHominem), it'd be a lot easier to follow you if you were to use paragraphs, rather than long rambles of incomprehensible sentences.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

I dont understand (2.00 / 1) (#24)
by maketo on Sun Dec 10, 2000 at 08:56:14 PM EST

Well 1. Linux, Microsoft Word, AutoCAD do have perfect theroethical background - the features they implement are well understandable - there is no rocket science about how to implement an undo or redo operation or something you see in the menu. Same goes for Linux or many other systems built routinely.

Sorry - I do not write many papers so paragraphs are not my main point - I believe that you should be able to follow my "rambling" without "decorations".

I didnt call you a PhD. in a derogatory fashion, it was something along the lines of "So, PhD, tell me". I meant this as "so, my friend, tell me".

You never said academics were good software engineers. Well, I believe that many a PhD thesis should and maybe does end up as mainstream technique used in conventional software engineering at one point or the other. Excuse me, dumb programmer, for believing that a computer scientist should be actually able to build the "perfect" working system, not just "ramble" about it in papers. While I find great amusement reading papers/thesis addressing some highly specialized part of the field (that usually noone cares for anyways) - I ask you, what is then the point of educating your average Joe BSc Cmpt Sci? To program? To "engineer software"? To go on an MSc/PhD path? Tell me, according to you, who should implement software systems? So far, many a revolutionary theory in Cmpt Sci did not even come from Computer Ssientists - look at the field of AI e.g. - we are talking psychologists, physicists, neurologists, biologists....What exactly does a computer scientist do? How about a grad in Computer Science? In my "Software Engineering" Track at the University here, they __do__ teach you programming languages - they are, after all a tool to express your __theoretical__ invention. So, we covered that. Now, they also teach you a class or two on hardware architectures, a class or two on math and logic and then, a class or two on "software engineering". The openning line of your average Joe Software Engeineering Prof. is "Well, the problem is wicked, you dont know it 100% until you solve it, but in order to solve it, you have to know it", or "There are really no rules about building systems, just patterns you apply and that people learned from experience and were nice enough to document them". So, friend, what am I intended to do with my degree after I get out? Obviously, CS is not about coding (that was an ad hominem attack on my side) but "ordinary programming" is not about CS....I am confused.

What do you call Dennis Ritchie? Or Stroustrup? Or Thompson? Coderz? heh Or are they Computer Scientists? All I see is that the world is running Unix ever since it was __coded__. Some dumb fsck had to do that to. But hey, you can always write a paper on something and proclaim yourself to be "above the coder and programmer, even soft engineer filth", you are a scientist ("you" here does not mean you personally, but "you all"). Here I am, in all my ignorance, sitting on a piece of metal and writing messages when instead I could be sitting on the phone and having a meta-conversation with Inoshiro in a pseudo-code, that too is computation!
agents, bugs, nanites....see the connection?
[ Parent ]
Dude, chill :) (4.00 / 1) (#25)
by fluffy grue on Sun Dec 10, 2000 at 09:15:42 PM EST

Well 1. Linux, Microsoft Word, AutoCAD do have perfect theroethical background - the features they implement are well understandable - there is no rocket science about how to implement an undo or redo operation or something you see in the menu. Same goes for Linux or many other systems built routinely.
We're talking about different aspects having a theoretical background here. What you are calling "theoretical background" I call "features"; by theoretical background I mean using proven algorithms that implement an exploration of a specific purpose (i.e. "in theory, this will do such-and-such"). Linux, Word, and AutoCAD are all practical-world-oriented systems, not research projects, and there is an inherent difference there.

Sorry - I do not write many papers so paragraphs are not my main point - I believe that you should be able to follow my "rambling" without "decorations".
Unfortunately, that's not how language works for many people, myself included - I need things to be broken up into chunks or else I have a very hard time processing the sheer mass of information. Making paragraphs isn't that hard - every few sentences after you've finished making a point, type <p>.

You never said academics were good software engineers.
Nor did I ever say they couldn't be. I never said that software engineering and research is an either-or proposition, and if my words indicated I thought that way, I apologize, but I even went so far as to say that I myself am an "ambidextrous thinker," i.e. think about things in terms of both the theory and the practice.

Well, I believe that many a PhD thesis should and maybe does end up as mainstream technique used in conventional software engineering at one point or the other.
Did I ever say anything to contradict this point? I don't believe I did. Just as research in physics leads to advances in, say, mechanical engineering, research in computer science leads to advances in software engineering. I believe I did explicitly say that they do feed off of each other, but that doesn't mean they're the same thing!

I ask you, what is then the point of educating your average Joe BSc Cmpt Sci? To program? To "engineer software"? To go on an MSc/PhD path?
Replace "computer science" with "physics," "to program" with "to build bridges," and "engineer software" with "to be an architect," and you'll see how that question makes no sense. There is no one point to getting a CS degree, just as there is no one point to getting a physics degree, but to get a CS degree with the intention of becoming a software engineer is like getting a physics degree with the intention of becoming an architect.

What exactly does a computer scientist do? How about a grad in Computer Science? In my "Software Engineering" Track at the University here, they __do__ teach you programming languages - they are, after all a tool to express your __theoretical__ invention.
Yes, and programming languages are a tool which is useful for both CS and software engineering. And, again, CS and software engineering feed off of one another.

So, friend, what am I intended to do with my degree after I get out? Obviously, CS is not about coding (that was an ad hominem attack on my side) but "ordinary programming" is not about CS....I am confused.
Once again, you have apparently failed to grasp my point: that CS is to physics as software engineering is to mechanical engineering. They are orthogonal realms which just happen to have a lot of interdisciplinary cross-polination.

What do you call Dennis Ritchie? Or Stroustrup? Or Thompson? Coderz? heh Or are they Computer Scientists?
Ritchie - software engineer who happens to make stuff useful for computer scientists. Stroustrup - computer scientist who happens to make stuff useful for software engineers. Thompson - who do you refer to? I don't immediately recognize the person based on the last name. Coderz - as in demoscene coders? People who program as a hobby without any discipline who could eventually become a software engineer, computer scientist, goat farmer, or anything else.

See, one of the things in this "debate" is that you're filling in WAY too much stuff based on things I haven't said. None of your arguments have directly contradicted any of mine.

And I never said computer scientists are above software engineers. I have, in fact, said that this is NOT the case, and that they are, once again, ORTHOGONAL DISCIPLINES. Basically, you're ranting at someone who I'm not, and unless you decide to have a conversation with me (and not J. Random Academic), this conversation will not go anywhere useful.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Just one more thing? (3.00 / 1) (#26)
by maketo on Sun Dec 10, 2000 at 09:24:17 PM EST

If I may, the parallel between physics and mechanical engineering and CS and software engineering sounds great, but in all Universities I know physics and mechalical engineering are different degrees, different departments and often, different buildings. In CS its all in one. Hmmm.
agents, bugs, nanites....see the connection?
[ Parent ]
Exactly (none / 0) (#28)
by fluffy grue on Sun Dec 10, 2000 at 10:05:16 PM EST

Although I didn't say this, one of the things I've been hoping for is that universities realize that software engineering and computer science are different things. In fact, I had a conversation with the CS department head here along those lines recently, and he was in agreement - there needs to be a separate software engineering degree, since they really ARE different disciplines. However, most universities *do* have separate "computer engineering" which usually has a large amount of software engineering curriculum (the EE department here offers a computer engineering degree and lots of software engineering courses, for example).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Yes! (none / 0) (#29)
by Dacta on Sun Dec 10, 2000 at 10:30:02 PM EST

I think we are beginning to see this happening.

At a different campus of the university I went to, they are now offering a "Business IT" degree, which concentrates on writing software in VB and things like that (as I understand it)

Now it is easy to scoff at that, but I think it is about time we realized that people don't need to know the therortical basis of a sort alogrithm to display data from a database.. A lot of modern programming is just putting pre-written components together, and people who do this don't need the scientific background.

Unfortunatly, this leads to another problem: Educating people about the difference between a business programmer (a contruction worker), a software engineer (a mechanical engineer) and a computer scientist (a physicist).



[ Parent ]
NMSU kinda has this (none / 0) (#30)
by fluffy grue on Sun Dec 10, 2000 at 11:07:52 PM EST

NMSU has had, for quite some time, a 'Business Computing Systems' degree, run by the accounting/business/whatever department where they do what you described as a "business IT" department. That's still a level of difference from general software engineering, however, and the big problem isn't a lack of curriculum (again, NMSU offers CS, CE, and BCS, which cover all the bases) but a lack of understanding on the students' parts as to what the three things are, not to mention that the general advisors around here are pretty clueless. The Arts and Sciences advising office literally doesn't even know what "CS" stands for, when they are "advising" someone for computer science they think that CS110 is required for CS majors (it's a general-education class, the CS equivalent of "music appreciation"), and it's fairly obvious that none of the advisors know about the BCS or CE degrees which are much more apropos for the students who come in saying, "I want to learn how to write stuff in Visual Basic so I can make lots of money."

A lot of the CS freshmen here are always saying how they "don't get pointers" and wonder why they have to put up with so much "bullshit" (algorithms classes) to get their degree, and most seniors graduate without even absorbing any of the information (and they get pissed off that they weren't required to take a C class, since the curriculum here assumes that either you know C or you'll take the initiative to take C on your own without it being a requirement). We have two weedout classes, CS273 (where you build a lego robot and control it with a 68HC11 microcontroller) and CS372 (a hardcore algorithms class), and rather than students realizing that CS isn't for them after those classes, they just keep on repeating those classes until they manage to squirm their way through. Fortunately, after CS372 a lot of students do switch to BCS, but then this unfairly gives BCS majors a reputation of "failed CS wannabes."

For most real-world programming jobs, the BCS degree is probably the way to go. BCS students learn VB, COBOL, Access, and other real-world programming stuff, without having to care two bits about how any of it works. Which is fine.

FWIW, one major problem with the CE degree is that, since it's in the EE department, it's way too low-level - I get the impression that they learn more about the hardware than the software, and that the software engineering courses are just a stopgap way of differentiating CE from EE.


--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Software Engineering Degree Desperately Needed (3.00 / 1) (#49)
by sigwinch on Mon Dec 11, 2000 at 08:19:17 PM EST

FWIW, one major problem with the CE degree is that, since it's in the EE department, it's way too low-level - I get the impression that they learn more about the hardware than the software, and that the software engineering courses are just a stopgap way of differentiating CE from EE.

Dead accurate. The CE degrees that I have seen (well, the one I earned anyway) are just EE with emphasis on the practical design issues of computing hardware. The theories of computation and information, as well as the art of software design, are given superficial coverage. Since it is basically a EE degree, you have to take all the heavy-duty physics-based courses: circuits, electromagnetism, physical chemistry, physics, thermodynamics, mechanics, microcircuit design, power systems, and so forth. There are a few foundation courses like calculus, differential equations, and linear algebra that are useful for software engineering, but the tortorous physical science regimen drives many software people away screaming. (To the amusement of the real EEs.) A lot of them run straight to the waiting arms of the CS department, which is often a dissapointment if they wanted to be engineers.

I think it is high time for a software engineering (SE) degree. If you look at electronics, there are several levels of study: technician, engineer, and physicist. Technicians have a shallow (but competent) grasp of theory, and are expert at grabbing hardware with their bare hands and making it do useful things. Engineers have a thorough understanding of theory, and are skilled in using that knowledge to design useful systems. More importantly, engineers have a rigorous approach to doing their work: documentation, communication, requirements analysis, revision control, juggling resources, planning schedules, and so forth. The physicist develops and refines the theory through inspiration and experiment.

For software, the technician corresponds to the sysadmin/grunt programmer. They can assemble pieces and fix problems, and maybe design simple systems, but that's about it. The software engineer corresponds to the EE, and uses their knowledge of computer science, system design, and project management to design software systems. (But the lucky SE gets to fabricate their system with a compiler -- EEs pay $1000/lot to have their circuit boards fabbed, unless they're designing chips in which case it is more like $100k.) The software equivalent of the physicist is the true computer scientist -- the mathematician specializing in information theory and computation.

In the current sad state of affairs, the only thing offered by many universities is the "computer science" degree, which has too little relation to reality. And it's not just the lack of software engineering courses either -- engineering cannot be taught at a chalkboard alone. You have to learn how to approach a project, why requirements analysis is important, how to organize your thoughts and communicate them to your colleagues, why esprit de corps is important, and how to maintain enthusiasm over a long project. Without those things, you are just an overeducated technician. The only way to learn these things is by practice, preferably under the guidance of a master. But so few computer science programs have a continuing series of team projects, of ever increasing difficulty, culminating in an ambitious final project.

Not that EE degrees are infinitely better, though. Many new EE graduates are incapable of soldering or applying Ohm's law. They just slog through the program by sheer force of will. I don't expect total mastery of the mechanical aspects, but how can someone be a EE if they cannot join two wires together?! If it was up to me, each new EE enrollee would be handed a soldering iron as they step onto campus and given a new project every month. "This is my soldering iron. There are many like it, but this one is mine." The new SE students would get Unix accounts, and a new software project every month, with appropriately vague requiremens. "This is my CVS repository. There are many like it, but this one is mine."

(Dangit, Scoop ate my &nbsp;s during preview. And then it ate my attempt to preview &nbsp;. And I was following the teachings of the Prophets Strunk and White and putting the proper two spaces after the end of every sentence. [sigh] Looks like this place could use some software engineers. 8^) Failing that, at least give us some big-ass blinking gifs.)

--
I don't want the world, I just want your half.
[ Parent ]

Ironic (none / 0) (#51)
by Dacta on Tue Dec 12, 2000 at 07:14:58 AM EST

I did a year of a "Bachelor of Computer Systems Engineering" - it was exactly how you described your CE degree, and I hated it.

I shifted to a computer science degree because (a) I liked it more, and (b) there were more girls. (Yes, I am serious about point "b")



[ Parent ]
dotdot (none / 0) (#32)
by ameoba on Mon Dec 11, 2000 at 03:11:34 AM EST

Umm... Maybe it's just me, but does somebody really need to go to University to learn how to make VB frontends for databases? I could see it being a minor/specialization of a Business degree, perhaps. But getting your bachelors in 'Business IT'... unless it covers much more than you let on, it's associates material...

Unless you concider a BS-BasketWeaving legit...

[ Parent ]
And then it expands (none / 0) (#33)
by Nickus on Mon Dec 11, 2000 at 03:57:12 AM EST

The problem with people putting togheter pre-written components is that in the beginning it is easy. They take a few components and write a few line of code. And then their manager sees it and says "Hmm.. but if we could have this feature too". And suddenly Joe With-Business-Education-Instead-of-Computer adds another feature and another feature and one day you will have a very bloated program without design.



Due to budget cuts, light at end of tunnel will be out. --Unknown
[ Parent ]
Be Fair (3.50 / 4) (#27)
by Khedak on Sun Dec 10, 2000 at 09:43:21 PM EST

Yes, it is companies' fault for not paying better programmers (and IT workers in general) more money than their slacker peers, but it's also your fault for not making your skills well-known. ButI wouldn't say the reason your slacker peers get treated the same as you is due to the boss being too stupid to know the difference. That sounds a little bit too much like we're trying to rant. After all, if you really think you're all that you'd better have the work record to back it up. All this talk about "thinning the ranks" and the "gene pool" makes you sound not only elitist, but like a some kind of eugenics proponent.

If you want to do more than vent about the idiot programmers who cause you grief, then maybe you should provide a little more support for your claims. After all, perspective is everything: Perhaps some programmers thought you were the idiot when you started. Or has your skill remained the same throughout your career?

The big problem is that (4.00 / 1) (#34)
by porkchop_d_clown on Mon Dec 11, 2000 at 06:59:22 AM EST

It is extremely hard for managers to tell good programmers from bad ones. Unless you can actually read code, (and your good at it) evaluating a team of programmers becomes a matter of measuring the whole team's ability to meet deadlines - and by looking at soft factors such as how late people stay at the office, etcetera.

But since the quality of a person's code is unrelated (or even inversely related) to how late they stay at the office debugging it, and since most coding teams seem to consist of one or two actual programmers who carry the rest, the managers have no clue. And I say this as someone who has done management of programmers. Time after time I've worked with and respected some very intelligent and articulate individuals, only to lose all respect for them when I finally had a chance to see their work.



People who think "clown" is an insult have never met any.
[ Parent ]
bad code (3.00 / 1) (#48)
by depsypher on Mon Dec 11, 2000 at 04:44:53 PM EST

Its not that programmers are not paid enough, if anything it's the opposite. The astronomical salaries are drawing in plenty of people who couldn't care less what good code looks like. I'd say most techies love what they do, but there is a substantial number that just love the .com lifestyle. Hopefully they go get jobs in marketing, cause its a lot easier to ignore a bad biz-dev plan than it is to ignore bad code.

[ Parent ]
Orthogonal problems? (2.33 / 3) (#36)
by slaytanic killer on Mon Dec 11, 2000 at 09:24:18 AM EST

I am told that when most people "rant," there is something going on in their lives that makes them angry. I don't know what is true in your case; maybe you are just demanding about code and intelligence in general. But whatever the case is, just make sure you are doing what you're passionate about. If you don't feel motivated to proactively change things, or to indulgently read shitty code and implement it correctly in your own mind, then it seems to me that you are not doing what you want to do.

Or if you enjoy this & like the rage of writing a rant, I wish you fun.

The victim of success.. (4.00 / 4) (#38)
by B'Trey on Mon Dec 11, 2000 at 10:02:57 AM EST

What you're seeing is the result of our own successes. Programmers used to be geeks. That is, they entered the field because they loved it, and usually had an aptitude for it. This didn't mean that they were all great coders, or that they always followed good programming discipline. But it did mean that they usually cared about what they were doing and at least had a desire to do good work.

Today, computer technology is THE field. Every high school kid who walks into the guidance counselors office gets handed a stack of brochures on the wonderful opportunities in the world of computer programming. Thus you end up with programmers who's motivation is to get paid, not to write code.

This is why (2.00 / 1) (#40)
by aphrael on Mon Dec 11, 2000 at 02:30:30 PM EST

i'm hoping the economic downturn hits the tech industry hard, and a lot of the people who don't enjoy programming, don't think like programmers, and aren't any good at it *simply go away*.

But maybe that's wishful thinking ...

[ Parent ]

If so... (3.00 / 1) (#47)
by -ryan on Mon Dec 11, 2000 at 04:38:04 PM EST

This is the only thing that has kept me from becoming a CS teacher. I'd love to go teach high-school kids how to program but I guess I'm to materialistic to give up these things until I can make just as much working as a teacher.

Shame on me.

I love to write code and I love to teach people how to write code. Alot of people don't listen though. They (usually fresh out of school) say "just write the code man!". They think I'm a fool or a bigot or something.

Ya know, just a few years ago most programmers didnt make shit. It wouldn't take much to put us back there.

[ Parent ]

Enforced standards and certifications (3.00 / 3) (#52)
by amokscience on Tue Dec 12, 2000 at 12:37:32 PM EST

No not MSCE standards and certifications. I'm talking about the kind that are required to hold the title of "engineer". Check up on your states laws regarding this (yes laws). It takes more than just a degree to get this title, it required years of experience, testing, and peer review. In fact, in my state the title of "Software Engineer" can't be grante until the same process is passed.

Until programmers can be *trained* in the same fashions as engineers the pool of programmers will become more diluted with chaff. Most programmers today coming out of high school and college know tons about programming and dick about good style, techniques, and processes. Programming projects with hard deadlines and which grade 90% on functionality don't help. FIX the High school and college education system and you'll see a higher baseline standard for entry level programmers. MAKE them read "Code Complete", program in large groups, MAINTAIN other previous classes code, have PEER REVIEW, take not one but 3 or 4 software engineering classes. Makes sense, but you know what every CS department is saying? We teach science, not programming. (ARGH!!!!)

Even with certifications, however, there will always be crappy programmers since demand is so high. If I were you I'd keep looking for a job where your philosophy is respected and adhered to (or at least where you can stand it). Not like demand would be low for those skills ;P

Thinning of the Programmer Gene Pool | 56 comments (56 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!