Does the 'Hacker Ethic' Harm Today's Developers?

snydeq writes "Fatal Exception's Neil McAllister questions whether the 'hacker ethic' synonymous with computer programing in American society is enough for developers to succeed in today's economy. To be sure, self-taught 'cowboy coders' — the hallmark of today's programming generation in America — are technically proficient, McAllister writes, 'but their code is less likely to be maintainable in the long term, and they're less likely to conform to organizational development processes and coding standards.' And though HTC's Vineet Nayar's proclamation that American programmers are 'unemployable' is overblown, there may be wisdom in offering a new kind of computer engineering degree targeted toward the student who is more interested in succeeding in industry than exploring computing theory. 'American software development managers often complain that Indian programmers are too literal-minded,' McAllister writes, but perhaps Americans have swung the pendulum too far in the other direction. In other words, are we 'too in love with the hacker ideal of the 1980s to produce programmers who are truly prepared for today's real-life business environment?'"

Comments

Says who?

[seebs]

Hi, I'm a self-taught cowboy programmer. Never took a single CS course.

I spent ten years on the ISO C committee. My coworkers like my code reviews because I'm thorough and careful. While my code isn't as good as I'd like it to be, the big hunk of my code that we put into our last product release has one known outstanding bug, and it's considered "cosmetic" -- it never impacts the actual output. (And that's for five thousand lines of code I produced in three weeks...)

I don't buy it. I am a big fan of the "hacker ethic" -- and I see maintainability and code quality as *central* to it. Sloppy work is habit forming. The reason I can type ten-line shell scripts in at the prompt and have them work is that I have worked really hard to be good at what I do.

So, basically, I don't accept the premise. We used to have offshore coworkers from India, and they were useless. They'd reopen bug reports because the same package failed to build for TOTALLY unrelated reasons. ("TeX is not installed" and "linker error due to frame table full" are not the same bug.) Since then, we started hiring people in China, and actually hiring them as full-time staff, and it works a lot better. They're not all hugely experienced, but they're solid, and they learn. (They even argue with us sometimes, which I'm really enthused about. That's how you get good.)

Re:Stop posting McAllister. He's the new Dvorak.

[hedwards]

I have to admit, that I'm skeptical that coders now are any more cowboyish than they used to be. I mean I've read stories about how Bill Gates and Paul Allen used to handle Micro Soft's products early on before they changed the name and locale. Somebody will have to explain to me how today's coders can be any worse than they were.

Re:Structure can be learned creativity cannot

[seebs]

What makes you think creative thinking can't be taught?

Not just developers

[dave562]

The technology industry has moved beyond its infancy and become a fundamental part of most businesses. I'm a systems administrator and I started working in IT (MIS at the time) when I graduated from high school in 1996. In my childhood, I spent a lot of time hacking phone systems, hanging out at 2600 meetings, and doing all sorts of other not so legit activities with computers. I was interested in whatever systems I could get my hands on, whether it was a System 75 running Audix, a 5ESS/SS7 switch, Linux, Cisco routers, whatever. I read Internetworking with TCP/IP by Comer not because I was in college and had to, but because I wanted to understand what those around me were talking about. All of that development left me with a broad skillset that lacked focus. I developed a very high level understanding of how systems interconnect, and by working for some very good bosses, I developed an understanding of how the systems support the business processes of the organizations I worked for. I'm very much a stereotypical "Jack of all trades, master of none." sort of administrator.

When there weren't many people out there with an interest in or hands on aptitude with computer systems, people with my skillsets were in high demand. In the small business sector, where companies can't afford separate DBAs, system admins, network engineers and so on, I fit in quite well. In the corporate world, I can't even get a job interview because they are looking for individuals who are highly focused on a single aspect of the overall network. The same thing holds true for developers.

"Back in the day", being able to write code to get the job done was a mystical science for management types. Skilled coders were in short supply, so people who could hack programs together were employable. In this day and age, anybody can go to any number of colleges or trade schools and learn how to write decent code. Anybody can go to college or trade school and get an MCSE, or a CCIE, or any number of system/network specific certifications. Managers and employers want known quantities. They want developers who are going to deliver predictable code. They want system admins who are going to follow industry best practices.

The technology industry has grown up. We aren't in the days of "Just make it work" anymore. We're in the days of refining how things work. Best practices have been established. Frameworks for doing things have been established. Companies are just looking for people who can "Make application X do A and B." reliably.

Horse Pucky

[Greyfox]

There are just a bunch of really bad programmers out there. Degrees and nationality are largely irrelevant to skill at it. Don't blame "kids these days" or whatever because you're not good at filtering out the bad ones. It's not particularly difficult to spot the good ones, they're pretty enthusiastic about the questions you ask them and the problems you give them when you're interviewing.

Cowboy Up.

[SoupIsGood Food]

When Indian companies come up with globally game-changing software on the same timetable as a Silicon Valley start-up like Facebook or Google, we'll talk. When a Chinese company has the long-term track record of quality and maturity that IBM and Oracle exhibit, we'll talk.

Until then, the cowboy coder makes better software in less time at the beginning of their career, and matures into a more competent team player as the years roll by and experience piles up. This isn't a weakness, this is why we have an IT industry at all. H1B coders are generally useless until they learn to Cowboy Up... and once they do, there's not really much difference between them and the locals. (I wish more of them would apply for permanent residence and bring their families over. I like immigrants who want a better life, I don't like scabs.)

Engineers at Honda start out their career working for the racing division, designing high-performance parts. Engineers at the end of their careers are assigned to subcompacts and mini-vans. This is because Honda needs fresh insights and youthful eagerness and excitement, and if the engineer flubs it, the only ones who know are the racing team. More importantly, Honda needs experienced hands who know their craft inside-out and upside-down to engineer the components millions of their customers will be using everyday, and their senior engineers generally appreciate the stability and predictability of a long-term ongoing project.

Re:Stop posting McAllister. He's the new Dvorak.

[hairyfeet]

This will probably get me modded down, but what the hell, i got karma. You want to know the REAL difference between an American and an Indian coder, and why they think of us as "cowboys"? One word: Adaptability.

Working on this job with a really sweet Indian girl, who was quite happy to be an American citizen now and said she wouldn't go back if you paid her, I asked why does Indian tech support suck. This was after we were all rolling on the floor laughing as she dealt with tech support by cursing them in Hindi when they told her to reboot again. She rolled her eyes and said "it isn't just the tech support, it is the programmers too. I would take one American over a dozen of my countrymen if they have never lived here for any length of time". She then sat down and explained it like this-

"It is the caste system" she said, "There you NEVER question those above you, ever. if your boss says the sky is purple and 1+2=12 then that is the truth. You never question those above you for any reason. Which works fine as long as it is something that can be written down and followed step by step. But life and computers rarely work that way. They always throw you curve balls and pull weird things that somebody forgot to write down. In those cases the American will "pull a Macgyver" and make it work. The Indian will just be lost, as you just don't do things like that. That is why I am quite happy to be here, thanks."

So if you want to know why they think of us as "cowboys" there you go. It is because an American will try to figure out a weird problem while the Indian will wait on his/her boss to tell them what to do. Which is fine if you want nice little drones that can't think for themselves, but we just aren't built like that. And I for one am quite happy about that. So call us "cowboys" all you want, but it gets the job done.

Re:Stop posting McAllister. He's the new Dvorak.

[networkBoy]

The way we dealt with that was simple (if a bit patronizing). We have a couple "cowboys", myself included. We blaze proof of concept code in whatever the heck language suits our needs for a task at hand. The task is defined as we have these constraints, these goals, and need this data to sift out (this is machine test code). One of us will hack it up in a quarter or two*. Then it is handed off to the test engineering team to make a polished product out of it (usually in C/C++). During this transition we are answerable to the test devs at their leisure and whims, thus if you didn't doc things you'll be in more meetings (and who wants that, when you could be hacking the next shiny thing together).

It works exceptionally well, as we can react quickly to somewhat amorphous changes to the initial spec, that usually come about as the prototype code is actually run and people realize that "hey it'd be nice to have this", or "that does what I said, but not what I want". We've all encountered this before and it's horribly frustrating when changes like this have to go through committee after committee, and ECOs and all that assorted crap. By doing it as a one man hacker get-er-done these changes become less problematic, some get pushed to the formal re-write, others get implemented quickly. The best part is it basically forces the almost universally needed refactor every product could use, but never gets. The stuff that shows up on The Daily WTF.

-nB

*yes, we get about 6 months to produce properly working code. My last project was about 8 months, 60K lines of perl, 5K lines of C++, and about 4 major changes in architecture, 2 of which were ultimately reverted. In fact this latest one is good enough as prototype that they are not re-writing it and are simply running with it. Downside there is now I have to write _real_ documentation, not just code notes.
so another couple months writing about 200 pages of usage docs, and 400 pages of API docs...
-nB