Slashdot Mirror
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?'"
And though HTC's Vineet Nayar's proclamation that American programmers are 'unemployable'...
Flamebait. The article goes on to say that Americans are all prima donnas who are out of touch with reality and want to start with 80K a year and whatnot. Besides that being a bad stereotype and not always true, and when it is true it also applies to math or engineering or whatever grads whose parents buttercupped them with promises of the American dream when they finished school. It is their fault for not anticipating reality just as it will be the Indians' fault if they refuse to anticipate their jobs going somewhere cheaper.
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.
They're already here, usually called "Software Engineering. The coursework is usually half business, half programming and IT. If you can survive rolling your eyes at all the buzzwords and colored charts, it's decent preparation for becoming a Dilbertian drone. Plus, you won't have to sweat learning the vector calculus you'll never use outside of school.
HTC is a Taiwanese electronics firm. The CEO in question is (according to the previous summary) running HCL Technologies. Of course if the previous summary is inaccurate as well, this is also wrong. But that's slashdot - they should replace the /. logo with a box of chocolates ...
Let me make this as clear as I can make it: Neil McAllister is an idiot. Stop posting his "stories".
And yet no evidence is offered as to why that's true. It simply is. Accept it on face value.
Not.
As a "self-taught coder" (remove the "cowboy", because that has completely different implications) I am regularly frustrated by the coding practices of my more learned colleagues. Or more precisely, my colleagues who have more college backing behind their code.
Bull^H^H^Hachlor's Degrees, Masters Degrees, PhDs, it doesn't matter. At the end of the day they still cram code into an editor with little regard for the reasoning behind the coding practices they follow. In result, those practices become useless as they overarchitect the system into a corner. (Or at a lower level, smoosh so much code into view that it becomes unreadable.)
In my experience, if they don't have years of experience under their belt to understand the purpose behind coding practices, then all the practices they teach you in college are for naught. A more senior individual still needs to guide the code in the right direction, regardless of education.
There you go. My anecdotal evidence that disproves your unfounded assertions. Are we all happy now?
Javascript + Nintendo DSi = DSiCade
part of me says that the out-of-the-box, non-conventional thinking that self learners typically have can be a real asset, it shows diligence, creativity and adaptability, nobody penned out the laws and rules for them, they had to find them on their own, it is its own category of brilliance in some respects. generally it doesnt lend itself to production environments though. but perhaps on a more problem solving level this characteristic is more valuable than the beautiful clean code than more schooled programmers learn. a good team of anything (programmers, sysadmins, football players) all have their strengths and weaknesses and they ought to compliment each other and balance out. in short both are needed but assessing the value of each must be done on independent terms, its the same animal but a different species.
i wage a holy war against the apostrophe.
I thought our messy unmaintainable code made us unfireable.
If you mod me down the terrorists will have won
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.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
You can take a creative person and teach them the correct ways to apply their ideas, but you can't take someone that knows the 'rules and regulations' inside and out, but sucks at independent thinking and teach them to be creative.
Hence why you'll get a bunch of people who have the same degrees from the same universities but they will have capabilities that are miles apart when it comes to software development. All the people were given the nuts and bolts knowledge, but only the creative ones excel in the real world think outside the box environments. That's not to say there aren't places for the 'by-the-book' developer, but it'll be maintenance coding, and not make the latest cutting edge app or game.
Hacker mentality or not, lack of creativity is why Indian developers tend to produce lackluster results. (And before I get flamed, I'm saying this in general, I'm sure there are many creative Indian developers out there, just as there are many uncreative American developers)
---
Programming is like sex... Make one mistake and support it the rest of your life.
Flame on, you crazy bastard.
"Developers", what have you. These names are overly generic, causing needless bickering about what they mean to various people. For a project of any size or consequence, you are likely going to need a spectrum of skills and perspectives to achieve anything worthwhile. If you are whining to the wold at large that every "programmer" doesn't fit the role you want someone to fill, you probably don't have such a project, or *you* are the problem.
A friend of mine uses Eclipse, not for some huge "grunt work" but just to have all the class reference stuff quickly available from code. I actually sorta like that; I've used NetBeans for the same reason, and I use Xcode sometimes for Objective-C. They all have the ability to provide real improvements in the work I'm actually doing.
Don't be too quick to throw away a tool. There is a reason that Rails has 'script/generate scaffold', and it's not just that programmers don't know any better -- it's that often that framework will be close enough to right to save you a ton of time.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
My observation is that good American programmers can produce software that is -vastly- more maintainable, efficient, understandable. Easier to modify or extend.
Mostly this is because they're combining a lifelong passion for programming with some education (formal or not) about software design practices. Foreign programmers on work visas are primarily concerned with making a better life for their family, altering their condition from one of near-poverty to significant wealth. They rarely have a passion for the work, and their only requirement is that they can accomplish enough to get and keep a job, not to excel.
Foreign programmers who could not get a work visa to come to the US, but work for US businesses remotely for a reduced rate due to the discrepancy in cost of living are usually of the same mindset. But usually they weren't good enough to get a job in the US! More recently, their standard of living can be equal or greater by staying in their country.
I simply don't know where the Indian or Chinese workers are that have significant skill or a real passion for programming, or computers in general. I have never met ONE in my life, despite working with countless dozens of foreign works on work visas. I have met some from other countries, but usually it is not places that are so poor that huge numbers of people are coming to the US to get a job that changes their standard of living. The exception is the former Soviet states. People from the former Soviet states often bring a passion for computing with them. Probably because they weren't poor in the same sense as someone of comparable income in India.
Today's Real Life Business Environment was created by the Hacker Ethic. Basically, the enterprise is defined as stuff that hackers create that is standardized into something that drones can operate cheaply, consistently and effectively. The limitations that exist are based on the lack of most worker's skills, rather than the "obtuseness" of so-called hackers.
I'm well aware that there are head cases out there who can't cooperate with anyone, but who created the original standards for computing and the Internet? Academics and hacker-types, which are not mutually exclusive groups. The Hacker mentality is very cooperative... just not social in the sense of physical connection. As long as they are safe in their bastions, hackers tend to work together on topics of mutual interest, and very effectively at that.
The problem is not the developer to developer interface, unless you insist on hiring literally minded drones, it is the business to hacker interface... which can be an issue. Business people like drones because they are cheap and predictable, even in their failures. The management of these Indian development groups smooths over the issues that hackers would bring straight to them. If the code isn't working, drone computing means you throw more developers and more time at it as long as it makes the deadline. Even quality can suffer a little. The hacker mentality means finding a better way of looking at the problem that isn't in the book or even telling the business that they are full of shit.
The interface problem is real. Business has a right to be able to make goals. However, their problems are not with turning hackers into drones, it is how they can work to interface with the hackers, perhaps with support staff such as better testers and technical writers. I have never been at a company that could use drone developers more than it could simply use some good tech writers, but for some reason the business hires the drones and leaves the people with the communication skills in the dark.
'American software development managers often complain that Indian programmers are too literal-minded,
Really? I think we've all seen this thing. If you aren't beign literal minded, you're making assumptions. When you make assumptions, at least some of them are going to be wrong. I spend a lot of time fighting for better defined requirements, because it means I'll spend less time doing rework when what I give my customer isn't what they wanted. The example I always give them is this:
You tell me college football, if you have possession of the ball and your knee touches the ground, the ball is down, whether or not the player was tackled. I give you a college football game, and the first time you try to kick a field goal, the ball is downed 7 yards behind the line of scrimmage because the holder's knee is touching the ground.
If you want something, your requirements better document it. Developers with "better practices" understand this. Unfortunately the people who write requirements usually don't.
Whale
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?
I don't know, but us IT guys save A TON of money riding a skateboard everywhere, and it's environmentally friendly! Who's laughing now?
-The Plague
Adidas To Bring Back Sneakernet
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.
"hacker ethic" as in "getting things done", versus "professional ethic" as in "cheating your way through school and career"? Let me see...
It's actively helpful.
Besides occasionally helping to solve an "unsolvable" problem, there is distinct difference between people who like figuring things out and coding, and people who just code.
People with the "hacker ethic" often have experience with a wide range of languages or disciplines, since they are interesting in knowing many things. This gives this a wide array of knowledge to draw on. The Mythbusters, in their RSA speech, said that they don't know a lot about any subject, but they don't know a lot about a lot of subjects, helping them succeed where others run into stumbling blocks. Same thing for hackers.
Of course businesses, at least at some point, like the hacker ethic. Many businesses, at least initially, would rather have the hacked up system that works and they can make money off of than the "correct" answer of "it's too complicated" or "it can't be done". Sure this code can become a headache later (a very big one), but that's really because people didn't invest enough in paying off the technical debt in the code. If they had improved it over time it wouldn't be a large headache later.
The people I've run into who don't have at least a little of the hacker ethic aren't good programmers. They may be able to program, but they don't move outside their little world of what they know how to do and what they use. The only improve when forced to (by being given a new assignment, etc) and they only do what is necessary to finish that assignment. Any knowledge they gained that they didn't need, they gained because they didn't realize they didn't need it.
But if they were the kind of person who wanted to learn that kind of thing, they'd have the hacker ethic.
It's a good thing. It keeps programmers sharp and interested. It helps them have more of the necessary skills when a new challenge arrives... or at least be able to pick up that skill faster/easier.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
What does the hacker ethic have to do maintainability? The hacker ethic is about testing boundaries, making things because you can, breaking things because you can, and bring out the full potential of technology. It has nothing to do with coding styles and what effect they may or may not have on maintainability.
I think the hacker ethic could strongly influence someone involved in software development in their choice of how maintainable to write code. But I think it influences some people to write unmaintainable code thinking that they're being "clever", and other people to write highly maintainable code because they know that it is indeed clever.
Also someone who thinks in terms of such passion for the art will be much more productive than others. So they can write maintainable code simply by having more time available (by being able to solve problems faster). Especially since the influence from management is never to make code maintainable, it's to produce it as fast as possible to satisfy some "business need". Writing maintainable code is an act of rebellion in most environments.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
"...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."
Which is why many universities offer software engineering degrees as a more practical alternative to computer science degrees. Software engineering degrees were offered at many of the schools I was looking at back when I started my undergrad in 2002. I was actually annoyed at how many software engineering classes my university crammed into my computer science curriculum since I had no intention of becoming a cube monkey.
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?'"
If only we were more in love! The thing is... the "cowboys" who can't shoot straight (e.g. write scalable, maintainable code) aren't real hackers anyway. It's a lot easier to be able to bang something together with glue and nails than it is to truly hack development. Any responsible hacker is going to know all about best practices, when to break them, and when to find new ones. There is beauty in simplicity as well as in obscure complexity. Whatever. Let the next generation all take classes in SharePoint or some crap like that and the good programmers among us may have even better job security than we had hoped for!
So your solution to a made up problem is that everyone should use Notepad? Ok, maybe you'll make an exception for vi, what if I fall on the emacs side of that holy war?
I think you need to think this through again, as you've obviously let something obvious slide by...
Things like PERL are deeply disturbing to anyone with a sense of design.
Perl is glue. Glue is messy. It's supposed to be messy; it handily fits things together that wouldn't otherwise interoperate.
Not much of a designer if you don't even know what glue is for.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Arguing against IDEs is pretty tired and boring. And embarassing. In general the code from "IDE Junkies/Jockeys" is just fine. An IDE is a tool like a hammer and if someone is using it wrong, you're going to see some bent nails. Refusing to use a tool isn't much better. An IDE takes a huge amount of trivial work out of designing GUIs, fixing syntax, refactoring, integrating with version control and just helping you remember the names of objects or methods or whatever. Am I an idiot because I'd rather look through a list that automatically pops up in my GUI than flip through a 500 page book?
Using a text editor instead of a full IDE (to work on appropriate scale projects) is like hunting with a spear, but you're not nearly as cool.
Whale
I'm a self-taught cowboy programmer.
...
My coworkers like my code reviews because I'm thorough and careful.
You are not a cowboy programmer.
Cowboys do not do code reviews. Cowboys do not question their own code. Cowboys just throw code at any and all situations. Cowboys don't test. Cowboys treat users like idiots. Cowboys don't document.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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.
Vineet Nayar does not 'belong' to HTC. he is the CEO of HCL Technologies. HTC is a Taiwan-based mobile handset manufacturer (among other things), and a pretty good one at that.
[Slashdot Comments We Liked]
and they're less likely to conform to organizational development processes and coding standards.
A lot of times, the "Cowboy Coding" is more effective because the "development processes and coding standards" were implemented and enforced by phonetaggers who have never written a productive line of code in their entire lives. Those who are inclined to break them, naturally, are more productive and seem more effective - despite the grumblings of the phonetaggers that they are "unmanageable".
But, really - Does "management" have any right to blame them? They spent the last decade proving to every developer the idea that if you allow yourself or your work to be commoditized, we will ship you or your job overseas where it can be done cheaper. And "development processes and coding standards" are usually implemented with the intent of "commoditizing", to a certain degree, the work of coding....and you're going to blame the *developers* for rejecting that? Middle management in the US basically *created* the environment that forced developers to either become "Cowboys" or to compete with people making $4/hr overseas.
Speaking on behalf of coders everywhere - You can take your "development processes and coding standards" and shove it - I'll keep my job and let you grumble under your breath about how I am "unmanageable", thank you.
I can't understand why anyone is surprised that people trained in computer science are ill equipped to develop
business software.
How many computer science graduates typically have the slightest clue what accounting is, or how it works?
How many computer science undergraduate programs deal with the customary and legal environment of
business?
How many computer science programs deal with the realities of designing and maintaining a datacenter,
in theory and/or practice?
Computer science is a theoretical self-serving discipline designed to produce more computer science
graduate students. Anyone who learns practical, appropriate, and customary reality does so more
often despite rather than because of their education.
Time for a radical reassessment.
Cost of living varies wildly across America. Thus how much you need to make to have a good life does as well. Where I live, housing is cheap. I have a condo where principal + interest + taxes + insurance + HOA fees is less than $1000/month. Obviously you can live pretty cheap here. Rentals are, of course, less than that. What's more, that's in the city so I can (and do) bike to work, saving on transportation costs. Now compare that to when my cousin went to school in California. His parents rented him a place that they then sublet to more kids. It was 4 people each paying $1000/month in rent. We are talking literally over 4 times the cost, and not as nice a place.
That isn't to mention other cost of living things. The old bank rule is take your gross monthly income by 3, 1/3rd for taxes 1/3rd for house 1/3rd for everything else (that is how to determine if you can afford a mortgage or not). The reason for that is because it is easy, but also rather accurate. As housing costs go up, so do other costs normally. Thus if your place is running you $4,000/month, you can expect that your other expenses (including setting aside money and such) will run you around $4,000/month.
Then there's kids, and that is a whole different situation. What works fine for a single person does not work fine when you are supporting children, who are rather costly and generate no income.
As such while $80,000 where I live is plenty, you can have a good life with children on that or much less, that's not the case in, say, New York City. Have a look at costs of living there sometime. Then consider that with a family, a little studio apartment isn't an option, you need a larger place.
There are indeed places where $80k is barely enough to do ok on.
Of course, you could argue that you wouldn't need glue if things were designed properly in the first place. I'll take my steel frame reinforced building over your glued together rocks any day.
There is a reason that Rails has 'script/generate scaffold', and it's not just that programmers don't know any better
I think it is, but the programmers are the Rails team. If every project that uses your framework is generating almost the same code, your framework is not exposing the correct interfaces. Microsoft is also guilty of this. How many MSDN articles say 'copy this 200+ line skeleton app that does nothing just sets up the default environment'?
I am TheRaven on Soylent News
What branch of physics do Computer Science graduates work in? Where does philosophy fit in?
I suspect that most CS graduates can be divided into 3 groups: 1) Those who debase themselves in the eyes of their professors by "merely" performing software development. 2) Those who preserve their purity by staying in academia and thus propagate the meme that CS isn't about programming. 3) Those who are unemployed.
Hey, I moved from NY because apartment prices were going too far up. But you can get very nice apartments - say two good bedrooms in a fashionable part of Brownstone Brooklyn, in the $2000-$3000 a month range. Granted, 15 years back those same apartments were $800-$1200. Still, it's more like $30,000 a year for a very nice NY apartment, including in some of the better parts of Manhattan these days.
That's still steep. But you can eat out better and cheaper in Brooklyn and Manhattan than about anywhere else in the country. And there's no need to own a car. It's all a matter of where your priorities are.
"with their freedom lost all virtue lose" - Milton
The GP was apparently talking about PERL, which is a joke programming language in which it's impossible to write maintainable code. You're thinking of the Perl programming language, which allows untrained novices to do useful things while not preventing diligent and careful programmers from writing effective and maintainable code.
You can safely ignore the opinion of anyone who spells the latter PERL.
how to invest, a novice's guide
Does research generate more or less long-run ROI in the corporation than rigor? Is there a place for both approaches? Assuming you have a proficient software engineer of each type, how does the corporation maximize shareholder value with each skill set?
If he had posed those questions, and maybe troubled himself to make a passing attempt at exploring the answer space, this article might be interesting. As it is, it is a mindless hit piece. Corporations need a balance of free-running and rigorous direction. This is particularly true in the high tech sector, which is far from a done deal. This stuff is evolving at lightning pace; exploration has solid value, as does mechanism. Consider what happens when you rigidly apply best practices in our field; you wind up with a system that is heavily coupled to CORBA, RUP, EJB, MDA, SOAP, and a dozen other zombie acronyms.
The problem is not research versus rigor, it is knowing how to apply each to appropriate problems. That is supposed to be a management task, but they don't understand our field and so don't know how to let a good horse run. They also do not know how to distinguish a good horse from a gluepot, so they do not trust either. And so management tends to prefer the rigorous engineer -- not because he generates more ROI, but because they understand him better. I must cut this short as I am starting to spin off topic, but I highly recommend reading Peter Drucker's exploration of the knowledge worker to see where my point was about to wander.
Stop-Prism.org: Opt Out of Surveillance