Every time one of us points out something like what you've mentioned here, people come out of the woodwork to denounce that person as "racist", or "xenophobic" or some other such crapola. I don't know if that's true; you're just talking about what you've seen. If we don't discuss anecdotal evidence, how are we going to learn anything about the current state of affairs?
Since you're interested in our actual experiences with foreign labor, let me weigh in with some things I've noticed over the years (these are generalizations based on people I've known, and YMMV):
Japanese people are smart as hell and really easy to work and get along with. I met one guy whose hair was three feet long, who wore it in an antique samurai-like style, chop sticks through the hair and everything. He was so smart it was scary, like some kind of weird zen coding machine. Interesting guy, with good taste in music.
Chinese people from the mainland and Taiwan for whatever reason seem to go to grad school first; most I've met had Masters degrees and were great to work with. Very open minded, too, easy to have a technical discussion with.
Guys I've met from Mexico and South America seem to be pretty sharp. They're more formal about software engineering than some of the other people I've worked with. One very nice guy from South America (I think Peru? But I don't remember) was absolutely into unit testing, and he was great to work with.
Russians generally don't seem to do the H1-B thing; they generally move here permanantly. They're pretty smart and seem to be real no-bullshit kinds of people, which I like. Most seem to not be CS grads, but rather from a physics or engineering background; a couple I've met were actually ex-hackers, but that can't be the norm (?). Note: I did meet one Russian who was totally insane and with whom I ended up basically waging a psychological war, but he was a real weirdo -- an anomaly. Most have been really cool.
I've had mixed experiences with Indians. A few have been brilliant, and very easy to get along with, but many others have been really poor programmers, and (much worse) some have been mean and arrogant, even to the point of making obnoxious jokes in their native tongue about Americans while standing *right in front of us*, and laughing at us. Very unkind, and amazing to me that anyone would behave that way as an adult! Very hurtful also. No other group has ever acted like this (except the one psycho russian I mentioned).
Overall, out of all the groups of foreign people I've worked with, I've had bad experiences only with Indians (and one Russian) so far. I don't know if that means anything, but FWIW, that's what I've encountered.
For purposes of this conversation, I'm specifically considering people with at least a B.A. in computer science from an actual, accredited college; this is the very LEAST level of ability that compares with that of an engineer, because engineers generally have at least a B.S.M.E (or EE, or CE, etc).
What shall we call a well-trained, qualified computer programmer?
Traditionally, a degreed programmer should be called a "computer scientist" if he's in academia, but that generally implies at LEAST a Master's degree (more often, a Ph.D). Programmers who work in the field, as opposed to academia, were called "Programmer", "Programmer/Analyst" or "Systems Analyst" depending on how much experience they had. Generally, the chain of events was, a person would graduate college to become a "Programmer", then get promoted to "Programmer/Analyst", then finally, to "Systems Analyst" although sometimes, the middle term would be skipped. Where I work, the process has been replaced by "Programmer/Analyst", "Senior Programmer/Analyst" , and "Associate Programmer/Analyst". Unfortunately, my chances of making it to "Associate" have been pretty much shot; my employer is no longer holding exams for that position apparently. So I'm fucked, but that's a whole other conversation.
Along came the guys who decided it would be a good idea to apply engineering principles to systems analysis. Don't get me wrong, this was a good idea. Many of the principles of "Software Engineering" are sound. However, calling it engineering was a mistake. There's nothing physical being produced; there is no actual product being built. Engineering, typically, dealt with physical processes. Software Engineering should have been called "systems analysis" which would have been much more descriptive.
My thinking is, if you're doing software engineering you're a programmer, programmer/analyst, or systems analyst. These are the traditional terms we've used for the job, for decades. Why piss off the engineers? They're having a rough enough time anyway, what with all their jobs being outsourced. Their title is all they have left in many cases. Let's go back to our traditions; let's call ourselves analysts, as we should have been all along.
Thanks! It's true, most shops like mine are run by ex-programmers; my boss used to do mainframe work. Sadly, I don't think most businesses will catch on; there was a great quote whose source I forget, which goes something like this:
"Human beings learn lessons, but then forget them almost immediately; this causes them to have to go through all the pain of learning the lesson over and over again, forever."
Kind of like Sisyphus pushing the stone up the hill, isn't it? Ah, well...;)
Most software that is written is not produced for sale, but rather as internal systems used within a business -- most programmers are doing applications work for corporations and/or government entities, NOT writing the next MS Word. Therefore, outsourcing will continue whether you charge tariffs or not, because software like this will be conveniently exempt from the tariffs. The tariff question will just be a big noisy show to distract us all from whatever weirdness Congress is up to, and the IT industry will die anyway.
I know exactly what you mean about having to pay the bills... My "secret shame" is that I have to program in VB and ASP during the day, even though I wish I was using something a little more C++ like. I like what I can do with VB, and the job pays the bills, but sometimes, when I get home at night, I'm so bummed out I just flop down on my couch and watch freaky short films on the independent film channel until my mind turns off. I'm kind of a melancholy sort these days... Now that I think of it, maybe this explains why I'm focusing on C++ and software engineering at home; perhaps it's a subconscious reaction to the virtual lobotomy I'm enduring all day...
But, still, you have to admit, if you want to write code that *anyone* will be able to run, you can't use Java (although you *can* get away with Perl/TK, if the program's small enough). You almost *have* to use C++, because it produces files that are small and fast enough for the slow machines a lot of people still use. That kind of appeals to me, you know? But so far, yeah, I've only been writing small stuff for my own internal use. I'll work up to releasing something, if I ever build something I'm sufficiently confident in, but I'm kind of a reclusive sort, so it might be a while.;)
Anyway, you're pretty cool. I haven't tried any inline assembler yet; do you have any tips? I'm not entirely clear on how it would work on a Linux system; I'd use the syntax from the GNU assembler, right? I've been wondering about that a lot; because gcc turns the C++ into GNU assembler before linking it, doesn't it? So using inline assembler would mostly just give you the ability to specify how something was done. I've been thinking, what if you coded your stuff first as C/C++, and used gcc to turn it into an intermediate assembler file; then, tweak the assembler, cut out the actual code section you're interested in, and re-insert it back into your other code?
Windows, an SUV? Hmm... No, more like a Yugo with a metric ton of extra cargo compartments bolted onto its sheet-metal hood, so that it looks kind of like a mushroom with little wheels.
I wonder what Linux would be? Maybe a '69 VW Beetle with a Baja kit, a 2400cc motor, fuel injection, off-road tires/suspension, and a roll cage? Bajas are so cool...
Well, you've got a solid point here. But I could counter that there ARE plenty of companies designing for the corporate space, so corporate code isn't hobbyist code. But, then, corporate stuff is generally composed of third-party add-ins, and modified distributions. Maybe a better way to think about this is, Linux is really split into two worlds:
The first world is that of the home user, the guy who wants to use Linux instead of Windows at home, for any of a dozen great reasons. This guy isn't going to care particularly that Linux was built by hobbyists -- in fact, that's probably a selling point, because he's probably a hobbyist himself. At least, he's open minded enough to try Linux, so he's probably open minded enough to not care about the hobbyist thing.
The other world is that of Big Business, but they're not going to be buying off the shelf Linux distros, or downloading their Linux, they're going to be going to a vendor and having something custom set up for them. The situation is completely different, so in my view the hobbyist stigma shouldn't really matter (although I recognize that it probably will, suits being suits -- today I had someone email me a request for a flowchart, to be sent as a fax, because she supposedly didn't know how to use email). I mean, a lot of their stuff is NOT hobbyist code, and I know that Linux is growing in that space very quickly. Companies like IBM are throwing their weight behind Linux, to make it sufficiently corporatized for Big Business to feel comfortable adopting it. I'm not complaining about that at all. I think it's a Good Thing, because enough of that tech trickles down to us and enriches the hobbyist community as well. But I see it as a separate thing from the hobbyist core of Linux. Another realm, you know?
Anyway, getting back to the original point I was trying to make, in the hobbyist space, C++ is a godsend because of all the things it gives a small-scale developer (e.g. a free IDE that can be run even on slow equipment, great performance, object orientation, etc). And, this results in home users having MORE features and functionality than they would if all the development was being done by the suits. And, the more people who are building things for Linux, the more likely something really cool is going to come out. So that's my point of view, basically. "Professional" tools for Linux are a whole other realm.
Some of us really DO have to use C or C++. Specifically, if we don't have a lot of money (I definitely don't) we can't afford a particularly fast machine. For example, I use a Pentium 167MMX laptop with 96MB of Ram and 4GB of disk at home. I would like to do GUI development with a decent system (and no, I don't mean using Emacs); I would like my programs to run quickly on my little machine. I would like my programs to run on the similar machines owned by other financially strapped people. These, then, are my constraints.
Java isn't really an option. It runs like molasses on my machinery. Just starting up an app takes a little while; it's annoying. So that's not cool, right from the get go.
All of the IDEs for Java either cost buttloads of money, require buttloads of ram and power, or both. Example? Forte, which recommends 512MB ram and a relatively modern processor, won't even start up on my little box in under five minutes, and there's no guarantee *anything* will work. It's a testament to Linux's stability that the machine crawls to a halt but doesn't crash when I suicidally try this out, but still -- the IDE doesn't work. I could code using Vi, and Java's command line compiler, and hand-code every single form element... But that would be hellish.
So, look at it from my point of view: why should I go through all this trouble when I can just use the QT designer and KDevelop? This is a C++ IDE that seems to run very well on my machines. Furthermore, the C++ code it generates will in turn run very well. Result: I don't have to spend a few thousand bucks on a new machine, I can use my beloved existing machine. AND, as a side benefit, other financially challenged people in the same boat as me will be able to use what I create.
I know you'll say "Use Perl and Tk" but I like C++'s approach to object oriented development and classes better than I like Perl's. And, I like the libraries I can get for C++. CPAN's great, but... I genuinely *like* C++.
So, you see, some people really DO have a good reason to use C++, and it isn't just grandstanding or showboating. Honest. It's the desire to not have to throw your beloved computer, which you've had for a while and really, genuinely feel attached to, in the trash. And, I think C++ is kinda fun. I'm getting back into it after five years off (doing Java, Perl, and now Microsoft stuff like VB and ASP). I'm reading Swan to refresh my memory; it's a pretty cool book, by the way.
Yes, but you can use exception-handling in C++ just as in Java (in fact, Java's exception handling scheme looks just like the one in C++ -- which I think came first) to CATCH those exceptions. Also, you can use better libraries and STL to work with input strings and such -- there's no rule that says you have to use unsafe constructs.
You can write code in C++ that is *just as safe* as the code you can write with Java. Of course... It'll run a hell of a lot faster.;)
Well, hang on a second now. You're making an unfair generalization about Linux coders. In fact, it's not a very nice generalization at all, and not very accurate.
In my experience, the people writing code as a hobby are professional coders or sysadmins during the day, who want/need an open source outlet for their talents at night. Most people I've heard about who contribute to Linux are pretty ordinary-looking, totally straightlaced, normal programmer/analyst types. I'm sure there are people like the "hack who lives in his mother's basement living off of bawlz and pizza" you describe, but I haven't met/encountered very many (those I have run into have been pretty much just shell scripters for some reason -- nothing against shell scripters, it may be a coincidence). For the record, I (for example) am a 32 year old, middle-of-the-road, jeans-and-polo-shirt-wearing senior programmer/analyst with short hair and no piercings (ok, ok, I do have some tattoos, but I'm ex military), I have my own car and a two bedroom apartment, I don't eat Bawls and pizza, I eat mostly vegetarian and spring water, and I don't speak in l33t. I guarantee that no suit-wearing executive would even take notice of me, much less find any reason not to trust me. And, having gone to a bunch of Linux conventions on and off, most of the people I see who are on the programming side are similar to me, with minor variations here and there (for some reason I see a lot of LOTR-type beards, especially among the sysadmin crowd; weird). Ok?
So let's get this out of the way right now: by "hobbyist programmer" I'm basically referring to the people I've noticed doing Linux work: totally normal, senior-programmer/analyst types on their free time with an itch to scratch.
What YOU're describing seems to have been taken straight out of some Microsoft flunky's FUD manual. So, please, refrain from insulting a whole class of people, ok? It isn't nice.
Ok, having gotten that ugly duty out of the way, let me point out that the hobbyists are still the main audience of Linux, they're still the core developers of new things for Linux, and they're still very important. Also, as I mentioned in my last post, they do things very differently from the way Big Business does them.
Piercings, tattoos and wild hair? Puh-LEASE. I don't even wear an earring.
By the way, in all fairness to your point of view and mine, I should add the following note:
I think that as a matter of basic philosophy, obviously, applications software designed for businesses will continue to be developed differently from desktop applications that target individuals. It always has been and always will be.
Businesses writing Linux software for other businesses (or for internal use) will probably end up using Java/J2EE because they'll want to use EJB, servlets, JBoss, and other similar technologies. If they didn't want to use Java, they likely wouldn't be using Linux -- they'd be using Windows and.NET. So there's that.
People writing software for individuals will probably keep using their favorite tools (notably, C/C++, because the compiler and libraries are Free Software, for one thing, and because they work better on older equipment, which many Linux users use).
The little gnome who wrote the article I was complaining about attacked people writing software in C++. Since most Linux business software is java based, that implies that he was attacking the people who write for home Linux users, which is what I responded to in my post. SO, business and business's needs are kind of beside the point. We're talking about hobbyists, which produce the majority of the code used by home users (like myself) and also generally use the code themselves.
I hope that frames things a little more clearly. Anyway, I still disagree with you. I think your way of looking at Linux is way, way, too corporate.
gilesjuk said, " But if you take an existing wheel and improve it then it's much easier and you get a higher quality result. Plenty of open sourse mail systems, fork one and improve/adapt it."
Sure. That's one option. But you don't *have* to do that, you could try to roll your own, too. If you never roll your own, how will you know whether you could have done a better job? I think there's room for both approaches, and what ends up working well, will succeed. It's darwinism applied to programming. Tons of mutation, many totally new species, the best ones survive and continue to mutate. Besides, as I said, it's kicks, and probably healthier for you than watching television or downloading pr0n.
Most of the things that are a part of Linux are in fact built by hobbyists. You can't get around that, it's a fact and it's not going to change. Programmers nourish Linux by building their personal interests into code and sharing it freely with each other. If it weren't for this drive, there would BE no Linux, and we'd all be using FreeBSD, ok? So let's not pretend that Linux's hobbyist heritage is a Bad Thing. That's thing number one.
Which brings us to thing number two, which is that Big Business, which loves free and cheap things, has discovered Linux, but it isn't comfortable with the wacky bunch of granolas it perceives as running the show. So, Big Business being Big Business, it is trying to say that the fundamental character of Linux is a "problem". The programmers building Linux are so "unprofessional"! So, Big Business would like to change that, and reform Linux into what you're calling "a professional quality OS with professional quality apps".
What you (and Big Business) don't seem to understand is that the REASON Linux is superior to Windows is that it was built by hobbyists, who are doing this stuff for fun instead of money. So, they spend more time with their pet project, tweaking it, fiddling with it, making it better and improving it... They're not constrained by the bullshit deadlines and ridiculous schedules you see in "professional" shops, so they can actually take their time and do a good job. I might add that they don't have a bunch of suits breathing down their necks, which tends to make things a little smoother.
Now, sure, Linux is going to start to fragment a little. Some companies are going to start trying to turn out "professional" versions of Linux, to please people like you who are uncomfortable with all us commie hobbyists, and there's nothing wrong with that. Other groups, probably including Debian and Slackware, are going to keep Linux's hobbyist nature alive. And, that'll be cool too. There'll probably be a lot of bleed-over between the two groups because most things built into Linux will probably continue to be GPL'ed.
And, do you know what's going to happen?
All your talk of professional code aside, there will still be hobbyists, and most of the more interesting things produced will be produced by them. As always, their work will then be ripped off and copied by the "professionals", as stage two of the "three systems of man". Watch, you'll see.
I'm starting to ramble here, so let's get back on track: I think you should re-evaluate your way of looking at Linux. Linux does not exist so that it can be sold to Big Business. Linux exists for the hobbyists who built it originally, and who continue to build it. There are companies that are trying to make money in this area, and God bless them, they deserve all the success they can get. But don't try to make out like taking over corporate computing is Linux's prime mission. It's not. It's just the dream of people who want to make money using Linux as their product. Not that there's anything wrong with that, but let's keep it in perspective.
Linux's (or should I say "GNU/Linux") prime mission, whether you like it or not, is to offer the world a FREE alternative to the commercial operating systems most people are stuck using. All this business stuff is a side issue, and though I really do hope Red Hat, SuSE, et al succeed and get what they want, I don't for a second agree with you that this is central to Linux's success as an O/S.
So there we are. 'Course, neither one of us is going to come over to the other's point of view. But that's ok too. It takes all kinds to make a world.
bnenning said: "Duh. And if your needs include security, then consider the drawbacks of C/C++ in that regard."
Sure. Then go right ahead and program in C/C++, keeping in mind that you've got to be careful with your input data, strings, etc. As long as you're careful you should be fine. Note that I'm not saying you should do web scripting in C/C++ -- most people do that in PhP or Perl. But by the same token, if I'm writing a desktop application for Linux, I'm going to use C++. Again, use the tool you think is most appropriate.
Then he said: "The difference being that a buggy Java app is far less likely to result in an exploit."
Blah, blah blah. Don't you ever get tired of the religious war thing? But, since you brought it up, a Google search for java related exploits returned 206,000 results. Hmm...
Finally, he said: "This is how stuff like Windows gets produced. Security just can't be bolted on as an afterthought."
Ad hominem gets you nowhere with me, kid. Besides, you're full of shit. Windows was produced in a purely mercantile and corporate way, building and bolting code onto old code, and expanding a weak code base with more and more code, rushed unbelieveably to meet unrealistic deadlines and so on. I don't see how you can draw an analogy between harried, overworked windows coders and totally free, happy, open source developers who are coding for kicks, and thus can take as much time as they like. False analogy, ad hominem... Feh. Nice try though.
gilesjuk said, "Why reinvent the wheel? plenty of clients out there."
Because the wheel is there, and can be reinvented. The new wheel might be better than the old one (you'll never know until you try, right?), and might be a lot of fun to invent. Besides, if no one reinvented the wheel, we'd still all be riding in horse buggies with wooden wheels, wouldn't we? But, instead, we're driving fuel-efficient high-tech cars with CD players and air conditioning...
Reinvent the wheel! It's a gas, and might make you some money besides.
While I have to give him credit for managing part of the Bastille project, which I've used at home and which I think is extremely useful, his philosophy of programming is pretty simplistic and dumb, IMHO.
He thinks we should all be using languages like Perl and Java, unless we're doing something His Highness considers elite enough to *require* the use of a lower-level language like C or C++. He thinks that all the people developing for Linux who have chosen to use C/C++ instead of his pet languages (again, Perl and Java) are somehow irresponsible. He categorizes them all as "macho" types, who are using the language just to pretend they're cool. And, he compares programmers to jet pilots... I mean, God, Almighty, I think there's a little bit of a difference between someone who flies five hundred miles an hour and can take out a small town with a single "oopsie", and a guy writing a printer driver, don't you?
God, what an ego! Who does this guy think he is? And, how old is he, 22? His picture looks pretty damn young to me (actually, looking at his picture, the thought that crossed my mind was "Oh my God, he's a hobbit -- this guy's from the Shire"). What hubris! What arrogance!
I don't know about you guys, but I'm pretty damn tired of hearing Java jockeys go on and on about how "safe" and "secure" their pet language is, and how bad the tools the rest of us use are. These annoying people pursue their "one true tool" approach like a religious crusade, consistently make asses out of themselves, and waste time annoying the rest of us with their blather.
Before I kill off this rant, I'd like to make a couple of points:
1. There's NOTHING wrong with using C or C++. In fact, using C or C++ virtually ENSURES that your stuff is going to work on a wide variety of computers (yes, even the older ones without much RAM). For some of us, this is an important consideration. Another consideration is, gcc is GPL'ed, so no one can ever "take it away". Java is still proprietary. And, Perl is a scripting language, which is not fully object oriented; so some projects will naturally be easier to manage long-term via C++. What's my point? USE THE TOOL THAT MATCHES YOUR NEEDS, NOT THE TOOL SOME ARROGANT KID OFFICIOUSLY ORDERS YOU TO USE.
2. People choose C/C++/whatever for their own reasons. Many people know more about C++ and are familiar with the libraries available on Linux; they find this very convenient and pleasant. There is NOTHING wrong with using the tool you're good at using.
3. Most people developing for Linux are HOBBYISTS. This means, they use the tools they enjoy using. And there's NOTHING wrong with this, either. Different people, using different tools and following their own muses, make life interesting.
4. Buffer overruns and other bugs can be avoided if you're just a little careful with your code, and don't cut corners. It's just as easy to write buggy Java as it is to write buggy C++ (yes, Java fanatics, it is! Look at all the crashing applets and java apps around the web and THEN tell me how great your pet tool is...).
Ok, that's enough ranting for now...
In general, I'd say people should use the tools they enjoy using, and write the kind of stuff they like to write -- then, spend some time vetting your code before they release it. Lord knows, hardly anyone's getting PAID to write software anymore, we might as well enjoy the work...
I think I agree with you here... Besides, regardless of what mall outlets do, most true geeks buy their stuff from online catalogs, where they have a better selection, and better prices. Or, barring that, they pick up a giant quasi-catalog-magazine like Computer Shopper. And, then there are the computer shows -- oh, my, those computer shows...
As a currently very happy employee myself, I can tell you what specific conditions exist at my job that make me happy. Most of these conditions are a function of the job being A) unionized, and therefore solid with good benefits and a living wage, and B) in government, so there is a well-thought out bureaucracy in place to keep things running smoothly. BUT, the specific happiness inducing effects shouldn't be too hard to replicate in private industry -- IF the bosses want them to be. So, as a public service message from moi, here are the factors which lead to happiness:
1. Pay your employees a living wage, and AT LEAST give them medical and dental. Note that this doesn't mean you have to make them rich! But if you're not paying them at LEAST in the 40K range, they're going to be too busy worrying about getting their rent money together, to worry about YOUR work. In places like NYC or Boston, better make that 60K or your employees will be living in cardboard boxes.
2. Don't breathe down your employees' necks. Where I work, the bosses leave you alone as long as you produce. So, if your employees aren't missing deadlines, leave them alone and let them do their stuff. When managing programmers (as with herding cats) less == more. Just tell them to keep you posted on their progress, at least once a week (say, Friday before COB). If you need to find out how something is doing, ask casually (this is good because it shows interest and lets the programmer know he's not forgotten). The trick is to LET the programmers produce instead of trying to force it. You'll find they come to YOU to tell you how things are going, because people like to talk about what they're doing. And they'll like you more (this does matter).
3. Don't be anal about when programmers come and go. We're not the most precise people when it comes to getting up in the morning, or going home at night. We may get in a half hour late and leave two hours late at night -- you get a free hour and a half, and we barely notice. But if you enforce business hours, we get pissed and come in and leave on a much more exact schedule.
4. Casual dress code. This means, generally, something comfortable but tasteful, like jeans and a polo shirt. Don't enforce the whole "dockers and sky blue shirt" thing (god, that is SO over), or (worse) suits. If you're uncomfortable, you're worried about stretching your shirt collar, not coding that loop. This doesn't mean you have to let them walk in in a kilt and a see-through rubber shirt, either. But, let them be comfy.
5. Cubicle decoration (within the limits of good taste) should be encouraged. A cluttered, chaotic cubicle is a happy, productive cubicle. A pile of paper on a desk is a sign of activity. Don't sweat stuff like this.
6. Coffee. Lots of coffee. Don't skimp on the sugar and half-and-half, either, or no one will drink the coffee and that's like no coffee. Any old coffee pot will do as long as the coffee is a reasonable, good brand and when people notice the pot is empty, they can set a new one on to brew. I can't stress the importance of caffeine and sugar to programmers enough. They WILL find ways of acquiring it; if you don't supply it, they'll be taking breaks to make coffee runs. Which do you prefer; three minutes to fill the mug at the office coffee pot, or fifteen minutes to walk a block to the Starbucks, with you playing Spy Games to figure out who's going where and when?
7. When nothing serious is going on, let the programmers do pilot projects that will eventually be good for the department. You can direct this a little; if you know, say, that you're going to be using some specific set of email tools, mention it to a programmer who isn't too busy and ask him to fiddle around with it and see what he can make it do. Then, keep the source code around for when the project ramps up. Remember: idle hands are the devil's playthings.
That's about all you have to do, really, to keep people happy. Leave them alone, let them do their thing, keep up the supply of interesting things to do, don't push them unless you really have to, feed them lots of coffee, and let them dress comfortably.
The Eric Conspiracy said: "...They are taking some report builder supplied by the accounting software vendor and using it to customize an end-of-month discrepancy report for the accounts recievable department."
What? I've never seen any report-builder. We've WRITTEN a few, but we're not using any canned stuff. I think you're managing a bunch of guys doing VBA, which makes you seem like you're in no position to discuss what makes good code. Where I work, we basically build client-server and distributed web applications, usually involving large databases. I can't imagine the sort of stuff you're talking about being the norm -- how depressing that would be! I guess people always tend to assume their experience is the norm, like thieves assuming everyone is a thief.
">>FIRST there is the CODE. Gack!! I wouldn't want to use any software you wrote. First there is a need, an itch to scratch, a requirement for something. Then there is a project plan, THEN there is a team, and FINALLY there is code. CODE is the LAST part of the project, not the first."
Now, now, there's no reason to become snotty.
If you're going to be totally anal about this, yes, ok, first there is a need, blah, blah, and blah. We're not talking about the PROCESS here, we're talking about the SKILLS REQUIRED. My point, and you're either deliberately trying to dodge it or being a schmuck, was that the central thing in any project is the code. If the code isn't good, the project won't be, no matter how many pretty Gantt charts you've put together, or how well you're able to talk the talk. So, first, comes the QUALITY OF THE CODE. There, does that make it clearer for you? I've inserted three words. Sheesh. Now, don't be so thick; it ruins the conversation.
As far as other professionals becoming programmers go, well, I will admit that an engineer can pick up a language, and the rigor of his original training will make it easier for him to adapt. BUT he STILL doesn't know any of the theoretical background of computer science, and he'll still fail when his application has to do something difficult. Sorry; it's a basic truth. Computer scientists don't build bridges, and engineers shouldn't think they can just wade into a complex CS project because they're arrogant about their undergrad degrees being "tough". An engineer can LEARN all the advanced CS stuff, but then, a CS guy can study engineering, too. The point is that you can't really do it until you learn it. "It" would take at least a couple of years, by the way. Not impossible! But not as likely as you would like to imply, either.
You're off base about the math, too: generally, engineers take calculus I, II, and III, linear algebra, and differential equations (I know what I'm talking about: I initially studied Mechanical Engineering, before I changed my major to computer science in my junior year, so I've had about three years of each degree program). They may also take a lab math course, practical app stuff. CS majors take calculus I, II, and III, often take linear algebra, and always take discrete mathematics.
Now, differential equations does not prove useful in CS. But the discrete mathematics course a CS major takes DOES prove useful -- and it's something engineers generally don't have. So, all that calculus and such the engineers have doesn't do them any good, does it? Because the one thing they DO need, they don't have.
Besides, did you miss the paragraph where I told you about the courses a CS major gets that lends him an advantage? You're just dodging my points. Can an engineer read a book on programming and learn how to program? Sure. Will he be as good as a CS major of the same intelligence and ability level? Not necessarily.
And, that is no less true than it was the LAST time I said it.
Look, you're apparently some kind of project manager, right? You seem to be saying that's what you are. So you know bupkiss about the coursework I'm describing to you -- you're a PHB, really, and all you know is what you've been tol
Slashdot Mirror
Every time one of us points out something like what you've mentioned here, people come out of the woodwork to denounce that person as "racist", or "xenophobic" or some other such crapola. I don't know if that's true; you're just talking about what you've seen. If we don't discuss anecdotal evidence, how are we going to learn anything about the current state of affairs?
Since you're interested in our actual experiences with foreign labor, let me weigh in with some things I've noticed over the years (these are generalizations based on people I've known, and YMMV):
Japanese people are smart as hell and really easy to work and get along with. I met one guy whose hair was three feet long, who wore it in an antique samurai-like style, chop sticks through the hair and everything. He was so smart it was scary, like some kind of weird zen coding machine. Interesting guy, with good taste in music.
Chinese people from the mainland and Taiwan for whatever reason seem to go to grad school first; most I've met had Masters degrees and were great to work with. Very open minded, too, easy to have a technical discussion with.
Guys I've met from Mexico and South America seem to be pretty sharp. They're more formal about software engineering than some of the other people I've worked with. One very nice guy from South America (I think Peru? But I don't remember) was absolutely into unit testing, and he was great to work with.
Russians generally don't seem to do the H1-B thing; they generally move here permanantly. They're pretty smart and seem to be real no-bullshit kinds of people, which I like. Most seem to not be CS grads, but rather from a physics or engineering background; a couple I've met were actually ex-hackers, but that can't be the norm (?). Note: I did meet one Russian who was totally insane and with whom I ended up basically waging a psychological war, but he was a real weirdo -- an anomaly. Most have been really cool.
I've had mixed experiences with Indians. A few have been brilliant, and very easy to get along with, but many others have been really poor programmers, and (much worse) some have been mean and arrogant, even to the point of making obnoxious jokes in their native tongue about Americans while standing *right in front of us*, and laughing at us. Very unkind, and amazing to me that anyone would behave that way as an adult! Very hurtful also. No other group has ever acted like this (except the one psycho russian I mentioned).
Overall, out of all the groups of foreign people I've worked with, I've had bad experiences only with Indians (and one Russian) so far. I don't know if that means anything, but FWIW, that's what I've encountered.
Anyway, again, YMMV; this is just my experience.
For purposes of this conversation, I'm specifically considering people with at least a B.A. in computer science from an actual, accredited college; this is the very LEAST level of ability that compares with that of an engineer, because engineers generally have at least a B.S.M.E (or EE, or CE, etc).
What shall we call a well-trained, qualified computer programmer?
Traditionally, a degreed programmer should be called a "computer scientist" if he's in academia, but that generally implies at LEAST a Master's degree (more often, a Ph.D). Programmers who work in the field, as opposed to academia, were called "Programmer", "Programmer/Analyst" or "Systems Analyst" depending on how much experience they had. Generally, the chain of events was, a person would graduate college to become a "Programmer", then get promoted to "Programmer/Analyst", then finally, to "Systems Analyst" although sometimes, the middle term would be skipped. Where I work, the process has been replaced by "Programmer/Analyst", "Senior Programmer/Analyst" , and "Associate Programmer/Analyst". Unfortunately, my chances of making it to "Associate" have been pretty much shot; my employer is no longer holding exams for that position apparently. So I'm fucked, but that's a whole other conversation.
Along came the guys who decided it would be a good idea to apply engineering principles to systems analysis. Don't get me wrong, this was a good idea. Many of the principles of "Software Engineering" are sound. However, calling it engineering was a mistake. There's nothing physical being produced; there is no actual product being built. Engineering, typically, dealt with physical processes. Software Engineering should have been called "systems analysis" which would have been much more descriptive.
My thinking is, if you're doing software engineering you're a programmer, programmer/analyst, or systems analyst. These are the traditional terms we've used for the job, for decades. Why piss off the engineers? They're having a rough enough time anyway, what with all their jobs being outsourced. Their title is all they have left in many cases. Let's go back to our traditions; let's call ourselves analysts, as we should have been all along.
Just my opinion; for what it's worth.
Thanks! It's true, most shops like mine are run by ex-programmers; my boss used to do mainframe work. Sadly, I don't think most businesses will catch on; there was a great quote whose source I forget, which goes something like this:
;)
"Human beings learn lessons, but then forget them almost immediately; this causes them to have to go through all the pain of learning the lesson over and over again, forever."
Kind of like Sisyphus pushing the stone up the hill, isn't it? Ah, well...
Phil
Most software that is written is not produced for sale, but rather as internal systems used within a business -- most programmers are doing applications work for corporations and/or government entities, NOT writing the next MS Word. Therefore, outsourcing will continue whether you charge tariffs or not, because software like this will be conveniently exempt from the tariffs. The tariff question will just be a big noisy show to distract us all from whatever weirdness Congress is up to, and the IT industry will die anyway.
Thanks! Cool assembler story.
Have a great weekend!
I know exactly what you mean about having to pay the bills... My "secret shame" is that I have to program in VB and ASP during the day, even though I wish I was using something a little more C++ like. I like what I can do with VB, and the job pays the bills, but sometimes, when I get home at night, I'm so bummed out I just flop down on my couch and watch freaky short films on the independent film channel until my mind turns off. I'm kind of a melancholy sort these days... Now that I think of it, maybe this explains why I'm focusing on C++ and software engineering at home; perhaps it's a subconscious reaction to the virtual lobotomy I'm enduring all day...
;)
But, still, you have to admit, if you want to write code that *anyone* will be able to run, you can't use Java (although you *can* get away with Perl/TK, if the program's small enough). You almost *have* to use C++, because it produces files that are small and fast enough for the slow machines a lot of people still use. That kind of appeals to me, you know? But so far, yeah, I've only been writing small stuff for my own internal use. I'll work up to releasing something, if I ever build something I'm sufficiently confident in, but I'm kind of a reclusive sort, so it might be a while.
Anyway, you're pretty cool. I haven't tried any inline assembler yet; do you have any tips? I'm not entirely clear on how it would work on a Linux system; I'd use the syntax from the GNU assembler, right? I've been wondering about that a lot; because gcc turns the C++ into GNU assembler before linking it, doesn't it? So using inline assembler would mostly just give you the ability to specify how something was done. I've been thinking, what if you coded your stuff first as C/C++, and used gcc to turn it into an intermediate assembler file; then, tweak the assembler, cut out the actual code section you're interested in, and re-insert it back into your other code?
Windows, an SUV? Hmm... No, more like a Yugo with a metric ton of extra cargo compartments bolted onto its sheet-metal hood, so that it looks kind of like a mushroom with little wheels.
I wonder what Linux would be? Maybe a '69 VW Beetle with a Baja kit, a 2400cc motor, fuel injection, off-road tires/suspension, and a roll cage? Bajas are so cool...
Well, you've got a solid point here. But I could counter that there ARE plenty of companies designing for the corporate space, so corporate code isn't hobbyist code. But, then, corporate stuff is generally composed of third-party add-ins, and modified distributions. Maybe a better way to think about this is, Linux is really split into two worlds:
The first world is that of the home user, the guy who wants to use Linux instead of Windows at home, for any of a dozen great reasons. This guy isn't going to care particularly that Linux was built by hobbyists -- in fact, that's probably a selling point, because he's probably a hobbyist himself. At least, he's open minded enough to try Linux, so he's probably open minded enough to not care about the hobbyist thing.
The other world is that of Big Business, but they're not going to be buying off the shelf Linux distros, or downloading their Linux, they're going to be going to a vendor and having something custom set up for them. The situation is completely different, so in my view the hobbyist stigma shouldn't really matter (although I recognize that it probably will, suits being suits -- today I had someone email me a request for a flowchart, to be sent as a fax, because she supposedly didn't know how to use email). I mean, a lot of their stuff is NOT hobbyist code, and I know that Linux is growing in that space very quickly. Companies like IBM are throwing their weight behind Linux, to make it sufficiently corporatized for Big Business to feel comfortable adopting it. I'm not complaining about that at all. I think it's a Good Thing, because enough of that tech trickles down to us and enriches the hobbyist community as well. But I see it as a separate thing from the hobbyist core of Linux. Another realm, you know?
Anyway, getting back to the original point I was trying to make, in the hobbyist space, C++ is a godsend because of all the things it gives a small-scale developer (e.g. a free IDE that can be run even on slow equipment, great performance, object orientation, etc). And, this results in home users having MORE features and functionality than they would if all the development was being done by the suits. And, the more people who are building things for Linux, the more likely something really cool is going to come out. So that's my point of view, basically. "Professional" tools for Linux are a whole other realm.
Well, hang on a second.
Some of us really DO have to use C or C++. Specifically, if we don't have a lot of money (I definitely don't) we can't afford a particularly fast machine. For example, I use a Pentium 167MMX laptop with 96MB of Ram and 4GB of disk at home. I would like to do GUI development with a decent system (and no, I don't mean using Emacs); I would like my programs to run quickly on my little machine. I would like my programs to run on the similar machines owned by other financially strapped people. These, then, are my constraints.
Java isn't really an option. It runs like molasses on my machinery. Just starting up an app takes a little while; it's annoying. So that's not cool, right from the get go.
All of the IDEs for Java either cost buttloads of money, require buttloads of ram and power, or both. Example? Forte, which recommends 512MB ram and a relatively modern processor, won't even start up on my little box in under five minutes, and there's no guarantee *anything* will work. It's a testament to Linux's stability that the machine crawls to a halt but doesn't crash when I suicidally try this out, but still -- the IDE doesn't work. I could code using Vi, and Java's command line compiler, and hand-code every single form element... But that would be hellish.
So, look at it from my point of view: why should I go through all this trouble when I can just use the QT designer and KDevelop? This is a C++ IDE that seems to run very well on my machines. Furthermore, the C++ code it generates will in turn run very well. Result: I don't have to spend a few thousand bucks on a new machine, I can use my beloved existing machine. AND, as a side benefit, other financially challenged people in the same boat as me will be able to use what I create.
I know you'll say "Use Perl and Tk" but I like C++'s approach to object oriented development and classes better than I like Perl's. And, I like the libraries I can get for C++. CPAN's great, but... I genuinely *like* C++.
So, you see, some people really DO have a good reason to use C++, and it isn't just grandstanding or showboating. Honest. It's the desire to not have to throw your beloved computer, which you've had for a while and really, genuinely feel attached to, in the trash. And, I think C++ is kinda fun. I'm getting back into it after five years off (doing Java, Perl, and now Microsoft stuff like VB and ASP). I'm reading Swan to refresh my memory; it's a pretty cool book, by the way.
Yes, but you can use exception-handling in C++ just as in Java (in fact, Java's exception handling scheme looks just like the one in C++ -- which I think came first) to CATCH those exceptions. Also, you can use better libraries and STL to work with input strings and such -- there's no rule that says you have to use unsafe constructs.
;)
You can write code in C++ that is *just as safe* as the code you can write with Java. Of course... It'll run a hell of a lot faster.
Well, hang on a second now. You're making an unfair generalization about Linux coders. In fact, it's not a very nice generalization at all, and not very accurate.
In my experience, the people writing code as a hobby are professional coders or sysadmins during the day, who want/need an open source outlet for their talents at night. Most people I've heard about who contribute to Linux are pretty ordinary-looking, totally straightlaced, normal programmer/analyst types. I'm sure there are people like the "hack who lives in his mother's basement living off of bawlz and pizza" you describe, but I haven't met/encountered very many (those I have run into have been pretty much just shell scripters for some reason -- nothing against shell scripters, it may be a coincidence). For the record, I (for example) am a 32 year old, middle-of-the-road, jeans-and-polo-shirt-wearing senior programmer/analyst with short hair and no piercings (ok, ok, I do have some tattoos, but I'm ex military), I have my own car and a two bedroom apartment, I don't eat Bawls and pizza, I eat mostly vegetarian and spring water, and I don't speak in l33t. I guarantee that no suit-wearing executive would even take notice of me, much less find any reason not to trust me. And, having gone to a bunch of Linux conventions on and off, most of the people I see who are on the programming side are similar to me, with minor variations here and there (for some reason I see a lot of LOTR-type beards, especially among the sysadmin crowd; weird). Ok?
So let's get this out of the way right now: by "hobbyist programmer" I'm basically referring to the people I've noticed doing Linux work: totally normal, senior-programmer/analyst types on their free time with an itch to scratch.
What YOU're describing seems to have been taken straight out of some Microsoft flunky's FUD manual. So, please, refrain from insulting a whole class of people, ok? It isn't nice.
Ok, having gotten that ugly duty out of the way, let me point out that the hobbyists are still the main audience of Linux, they're still the core developers of new things for Linux, and they're still very important. Also, as I mentioned in my last post, they do things very differently from the way Big Business does them.
Piercings, tattoos and wild hair? Puh-LEASE. I don't even wear an earring.
By the way, in all fairness to your point of view and mine, I should add the following note:
.NET. So there's that.
I think that as a matter of basic philosophy, obviously, applications software designed for businesses will continue to be developed differently from desktop applications that target individuals. It always has been and always will be.
Businesses writing Linux software for other businesses (or for internal use) will probably end up using Java/J2EE because they'll want to use EJB, servlets, JBoss, and other similar technologies. If they didn't want to use Java, they likely wouldn't be using Linux -- they'd be using Windows and
People writing software for individuals will probably keep using their favorite tools (notably, C/C++, because the compiler and libraries are Free Software, for one thing, and because they work better on older equipment, which many Linux users use).
The little gnome who wrote the article I was complaining about attacked people writing software in C++. Since most Linux business software is java based, that implies that he was attacking the people who write for home Linux users, which is what I responded to in my post. SO, business and business's needs are kind of beside the point. We're talking about hobbyists, which produce the majority of the code used by home users (like myself) and also generally use the code themselves.
I hope that frames things a little more clearly. Anyway, I still disagree with you. I think your way of looking at Linux is way, way, too corporate.
gilesjuk said, " But if you take an existing wheel and improve it then it's much easier and you get a higher quality result. Plenty of open sourse mail systems, fork one and improve/adapt it."
Sure. That's one option. But you don't *have* to do that, you could try to roll your own, too. If you never roll your own, how will you know whether you could have done a better job? I think there's room for both approaches, and what ends up working well, will succeed. It's darwinism applied to programming. Tons of mutation, many totally new species, the best ones survive and continue to mutate. Besides, as I said, it's kicks, and probably healthier for you than watching television or downloading pr0n.
Most of the things that are a part of Linux are in fact built by hobbyists. You can't get around that, it's a fact and it's not going to change. Programmers nourish Linux by building their personal interests into code and sharing it freely with each other. If it weren't for this drive, there would BE no Linux, and we'd all be using FreeBSD, ok? So let's not pretend that Linux's hobbyist heritage is a Bad Thing. That's thing number one.
Which brings us to thing number two, which is that Big Business, which loves free and cheap things, has discovered Linux, but it isn't comfortable with the wacky bunch of granolas it perceives as running the show. So, Big Business being Big Business, it is trying to say that the fundamental character of Linux is a "problem". The programmers building Linux are so "unprofessional"! So, Big Business would like to change that, and reform Linux into what you're calling "a professional quality OS with professional quality apps".
What you (and Big Business) don't seem to understand is that the REASON Linux is superior to Windows is that it was built by hobbyists, who are doing this stuff for fun instead of money. So, they spend more time with their pet project, tweaking it, fiddling with it, making it better and improving it... They're not constrained by the bullshit deadlines and ridiculous schedules you see in "professional" shops, so they can actually take their time and do a good job. I might add that they don't have a bunch of suits breathing down their necks, which tends to make things a little smoother.
Now, sure, Linux is going to start to fragment a little. Some companies are going to start trying to turn out "professional" versions of Linux, to please people like you who are uncomfortable with all us commie hobbyists, and there's nothing wrong with that. Other groups, probably including Debian and Slackware, are going to keep Linux's hobbyist nature alive. And, that'll be cool too. There'll probably be a lot of bleed-over between the two groups because most things built into Linux will probably continue to be GPL'ed.
And, do you know what's going to happen?
All your talk of professional code aside, there will still be hobbyists, and most of the more interesting things produced will be produced by them. As always, their work will then be ripped off and copied by the "professionals", as stage two of the "three systems of man". Watch, you'll see.
I'm starting to ramble here, so let's get back on track: I think you should re-evaluate your way of looking at Linux. Linux does not exist so that it can be sold to Big Business. Linux exists for the hobbyists who built it originally, and who continue to build it. There are companies that are trying to make money in this area, and God bless them, they deserve all the success they can get. But don't try to make out like taking over corporate computing is Linux's prime mission. It's not. It's just the dream of people who want to make money using Linux as their product. Not that there's anything wrong with that, but let's keep it in perspective.
Linux's (or should I say "GNU/Linux") prime mission, whether you like it or not, is to offer the world a FREE alternative to the commercial operating systems most people are stuck using. All this business stuff is a side issue, and though I really do hope Red Hat, SuSE, et al succeed and get what they want, I don't for a second agree with you that this is central to Linux's success as an O/S.
So there we are. 'Course, neither one of us is going to come over to the other's point of view. But that's ok too. It takes all kinds to make a world.
Holy cow, now that you mention it, he does look a little bit like him, although less malnourished. Freaky...
bnenning said: "Duh. And if your needs include security, then consider the drawbacks of C/C++ in that regard."
Sure. Then go right ahead and program in C/C++, keeping in mind that you've got to be careful with your input data, strings, etc. As long as you're careful you should be fine. Note that I'm not saying you should do web scripting in C/C++ -- most people do that in PhP or Perl. But by the same token, if I'm writing a desktop application for Linux, I'm going to use C++. Again, use the tool you think is most appropriate.
Then he said: "The difference being that a buggy Java app is far less likely to result in an exploit."
Blah, blah blah. Don't you ever get tired of the religious war thing? But, since you brought it up, a Google search for java related exploits returned 206,000 results. Hmm...
Finally, he said: "This is how stuff like Windows gets produced. Security just can't be bolted on as an afterthought."
Ad hominem gets you nowhere with me, kid. Besides, you're full of shit. Windows was produced in a purely mercantile and corporate way, building and bolting code onto old code, and expanding a weak code base with more and more code, rushed unbelieveably to meet unrealistic deadlines and so on. I don't see how you can draw an analogy between harried, overworked windows coders and totally free, happy, open source developers who are coding for kicks, and thus can take as much time as they like. False analogy, ad hominem... Feh. Nice try though.
gilesjuk said, "Why reinvent the wheel? plenty of clients out there."
Because the wheel is there, and can be reinvented. The new wheel might be better than the old one (you'll never know until you try, right?), and might be a lot of fun to invent. Besides, if no one reinvented the wheel, we'd still all be riding in horse buggies with wooden wheels, wouldn't we? But, instead, we're driving fuel-efficient high-tech cars with CD players and air conditioning...
Reinvent the wheel! It's a gas, and might make you some money besides.
While I have to give him credit for managing part of the Bastille project, which I've used at home and which I think is extremely useful, his philosophy of programming is pretty simplistic and dumb, IMHO.
He thinks we should all be using languages like Perl and Java, unless we're doing something His Highness considers elite enough to *require* the use of a lower-level language like C or C++. He thinks that all the people developing for Linux who have chosen to use C/C++ instead of his pet languages (again, Perl and Java) are somehow irresponsible. He categorizes them all as "macho" types, who are using the language just to pretend they're cool. And, he compares programmers to jet pilots... I mean, God, Almighty, I think there's a little bit of a difference between someone who flies five hundred miles an hour and can take out a small town with a single "oopsie", and a guy writing a printer driver, don't you?
God, what an ego! Who does this guy think he is? And, how old is he, 22? His picture looks pretty damn young to me (actually, looking at his picture, the thought that crossed my mind was "Oh my God, he's a hobbit -- this guy's from the Shire"). What hubris! What arrogance!
I don't know about you guys, but I'm pretty damn tired of hearing Java jockeys go on and on about how "safe" and "secure" their pet language is, and how bad the tools the rest of us use are. These annoying people pursue their "one true tool" approach like a religious crusade, consistently make asses out of themselves, and waste time annoying the rest of us with their blather.
Before I kill off this rant, I'd like to make a couple of points:
1. There's NOTHING wrong with using C or C++. In fact, using C or C++ virtually ENSURES that your stuff is going to work on a wide variety of computers (yes, even the older ones without much RAM). For some of us, this is an important consideration. Another consideration is, gcc is GPL'ed, so no one can ever "take it away". Java is still proprietary. And, Perl is a scripting language, which is not fully object oriented; so some projects will naturally be easier to manage long-term via C++. What's my point? USE THE TOOL THAT MATCHES YOUR NEEDS, NOT THE TOOL SOME ARROGANT KID OFFICIOUSLY ORDERS YOU TO USE.
2. People choose C/C++/whatever for their own reasons. Many people know more about C++ and are familiar with the libraries available on Linux; they find this very convenient and pleasant. There is NOTHING wrong with using the tool you're good at using.
3. Most people developing for Linux are HOBBYISTS. This means, they use the tools they enjoy using. And there's NOTHING wrong with this, either. Different people, using different tools and following their own muses, make life interesting.
4. Buffer overruns and other bugs can be avoided if you're just a little careful with your code, and don't cut corners. It's just as easy to write buggy Java as it is to write buggy C++ (yes, Java fanatics, it is! Look at all the crashing applets and java apps around the web and THEN tell me how great your pet tool is...).
Ok, that's enough ranting for now...
In general, I'd say people should use the tools they enjoy using, and write the kind of stuff they like to write -- then, spend some time vetting your code before they release it. Lord knows, hardly anyone's getting PAID to write software anymore, we might as well enjoy the work...
Well, they ain't as thick as they used to be, that's true; but they still don't fit well in magazine racks or mailboxes! ;)
I think I agree with you here... Besides, regardless of what mall outlets do, most true geeks buy their stuff from online catalogs, where they have a better selection, and better prices. Or, barring that, they pick up a giant quasi-catalog-magazine like Computer Shopper. And, then there are the computer shows -- oh, my, those computer shows...
Isn't letting Microsoft teach secure programming kinda like letting the town drunk host AA meetings at Moe's Tavern???
As a currently very happy employee myself, I can tell you what specific conditions exist at my job that make me happy. Most of these conditions are a function of the job being A) unionized, and therefore solid with good benefits and a living wage, and B) in government, so there is a well-thought out bureaucracy in place to keep things running smoothly. BUT, the specific happiness inducing effects shouldn't be too hard to replicate in private industry -- IF the bosses want them to be. So, as a public service message from moi, here are the factors which lead to happiness:
1. Pay your employees a living wage, and AT LEAST give them medical and dental. Note that this doesn't mean you have to make them rich! But if you're not paying them at LEAST in the 40K range, they're going to be too busy worrying about getting their rent money together, to worry about YOUR work. In places like NYC or Boston, better make that 60K or your employees will be living in cardboard boxes.
2. Don't breathe down your employees' necks. Where I work, the bosses leave you alone as long as you produce. So, if your employees aren't missing deadlines, leave them alone and let them do their stuff. When managing programmers (as with herding cats) less == more. Just tell them to keep you posted on their progress, at least once a week (say, Friday before COB). If you need to find out how something is doing, ask casually (this is good because it shows interest and lets the programmer know he's not forgotten). The trick is to LET the programmers produce instead of trying to force it. You'll find they come to YOU to tell you how things are going, because people like to talk about what they're doing. And they'll like you more (this does matter).
3. Don't be anal about when programmers come and go. We're not the most precise people when it comes to getting up in the morning, or going home at night. We may get in a half hour late and leave two hours late at night -- you get a free hour and a half, and we barely notice. But if you enforce business hours, we get pissed and come in and leave on a much more exact schedule.
4. Casual dress code. This means, generally, something comfortable but tasteful, like jeans and a polo shirt. Don't enforce the whole "dockers and sky blue shirt" thing (god, that is SO over), or (worse) suits. If you're uncomfortable, you're worried about stretching your shirt collar, not coding that loop. This doesn't mean you have to let them walk in in a kilt and a see-through rubber shirt, either. But, let them be comfy.
5. Cubicle decoration (within the limits of good taste) should be encouraged. A cluttered, chaotic cubicle is a happy, productive cubicle. A pile of paper on a desk is a sign of activity. Don't sweat stuff like this.
6. Coffee. Lots of coffee. Don't skimp on the sugar and half-and-half, either, or no one will drink the coffee and that's like no coffee. Any old coffee pot will do as long as the coffee is a reasonable, good brand and when people notice the pot is empty, they can set a new one on to brew. I can't stress the importance of caffeine and sugar to programmers enough. They WILL find ways of acquiring it; if you don't supply it, they'll be taking breaks to make coffee runs. Which do you prefer; three minutes to fill the mug at the office coffee pot, or fifteen minutes to walk a block to the Starbucks, with you playing Spy Games to figure out who's going where and when?
7. When nothing serious is going on, let the programmers do pilot projects that will eventually be good for the department. You can direct this a little; if you know, say, that you're going to be using some specific set of email tools, mention it to a programmer who isn't too busy and ask him to fiddle around with it and see what he can make it do. Then, keep the source code around for when the project ramps up. Remember: idle hands are the devil's playthings.
That's about all you have to do, really, to keep people happy. Leave them alone, let them do their thing, keep up the supply of interesting things to do, don't push them unless you really have to, feed them lots of coffee, and let them dress comfortably.
But... The marketing staff generally LOWER morale. How are more of them going to help?
The Eric Conspiracy said: "...They are taking some report builder supplied by the accounting software vendor and using it to customize an end-of-month discrepancy report for the accounts recievable department."
What? I've never seen any report-builder. We've WRITTEN a few, but we're not using any canned stuff. I think you're managing a bunch of guys doing VBA, which makes you seem like you're in no position to discuss what makes good code. Where I work, we basically build client-server and distributed web applications, usually involving large databases. I can't imagine the sort of stuff you're talking about being the norm -- how depressing that would be! I guess people always tend to assume their experience is the norm, like thieves assuming everyone is a thief.
">>FIRST there is the CODE.
Gack!! I wouldn't want to use any software you wrote. First there is a need, an itch to scratch, a requirement for something. Then there is a project plan, THEN there is a team, and FINALLY there is code. CODE is the LAST part of the project, not the first."
Now, now, there's no reason to become snotty.
If you're going to be totally anal about this, yes, ok, first there is a need, blah, blah, and blah. We're not talking about the PROCESS here, we're talking about the SKILLS REQUIRED. My point, and you're either deliberately trying to dodge it or being a schmuck, was that the central thing in any project is the code. If the code isn't good, the project won't be, no matter how many pretty Gantt charts you've put together, or how well you're able to talk the talk. So, first, comes the QUALITY OF THE CODE. There, does that make it clearer for you? I've inserted three words. Sheesh. Now, don't be so thick; it ruins the conversation.
As far as other professionals becoming programmers go, well, I will admit that an engineer can pick up a language, and the rigor of his original training will make it easier for him to adapt. BUT he STILL doesn't know any of the theoretical background of computer science, and he'll still fail when his application has to do something difficult. Sorry; it's a basic truth. Computer scientists don't build bridges, and engineers shouldn't think they can just wade into a complex CS project because they're arrogant about their undergrad degrees being "tough". An engineer can LEARN all the advanced CS stuff, but then, a CS guy can study engineering, too. The point is that you can't really do it until you learn it. "It" would take at least a couple of years, by the way. Not impossible! But not as likely as you would like to imply, either.
You're off base about the math, too: generally, engineers take calculus I, II, and III, linear algebra, and differential equations (I know what I'm talking about: I initially studied Mechanical Engineering, before I changed my major to computer science in my junior year, so I've had about three years of each degree program). They may also take a lab math course, practical app stuff. CS majors take calculus I, II, and III, often take linear algebra, and always take discrete mathematics.
Now, differential equations does not prove useful in CS. But the discrete mathematics course a CS major takes DOES prove useful -- and it's something engineers generally don't have. So, all that calculus and such the engineers have doesn't do them any good, does it? Because the one thing they DO need, they don't have.
Besides, did you miss the paragraph where I told you about the courses a CS major gets that lends him an advantage? You're just dodging my points. Can an engineer read a book on programming and learn how to program? Sure. Will he be as good as a CS major of the same intelligence and ability level? Not necessarily.
And, that is no less true than it was the LAST time I said it.
Look, you're apparently some kind of project manager, right? You seem to be saying that's what you are. So you know bupkiss about the coursework I'm describing to you -- you're a PHB, really, and all you know is what you've been tol
Saint said:
:P
">>Fuck... What total and utter bullshit. This guy's
>>a troll.
Who is, HanzoSan? Gee, say it ain't so."
Umm... Now that you mention it, it does seem like it was a little obvious/redundant for me to SAY it...