Slashdot Mirror
Coders, Your Days Are Numbered
snydeq writes "Fatal Exception's Neil McAllister argues that communication skills, not coding skills, are a developer's greatest asset in a bear economy. 'Too many software development teams are still staffed like secretarial pools. Ideas are generated at the top and then passed downward through general managers, product managers, technical leads, and team leads. Objectives are carved up into deliverables, which are parceled off to coders, often overseas,' McAllister writes. 'The idea that this structure can be sustainable, when the US private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.' Instead, companies should emulate the open source model of development, shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code. And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'" Update: 04/04 19:52 GMT by T : InfoWorld's link to the archived version of the story on open source development no longer works; updated with Google's cached version.
So, I might do well if:
1) I can actually communicate with the people that are paying me.
2) I can write code that doesn't suck.
3) I actually understand the business needs for the code I'm writing.
Wow. I'll be much more effective now. Thanks.
What he argues is either trivial or bullshit. I don't understand what he says, to be honest, so there are 3 possibilities:
1. He says that everybody needs to learn communicate. That's trivial. Everybody, even manual workers, need to communicate. You can excel, but if you cannot cooperate, you cannot work in modern society.
2. He says that communication, not other skills, is where real money/power is. This is also trivial. To scale beyond the abilities of a single person, you have to control other humans, and for that, you need people skills more than other specific skills.
3. He says that the U.S. economy in the future won't need any people with technical skills, only managers, as technical skills can be outsourced. This is bullshit, as the U.S. is going to experience the hard way in the upcoming years.
I think the anti-pattern I see in most companies that are weak in the technology area is the guy at the top is great at landing deals, public speaking, and sales but he can't figure out what those damned pesky nerds are doing and why they need to get paid so much money.
As a general rule, most successful tech companies are started and run by people with engineering and/or cs backgrounds (Google, Paypal, Ebay, Microsoft to name a few). Many companies these days, which are in the information handling business (finance, etc), have little competitive advantage over their competition except for their technology platform and are thus essentially tech companies, even though they might not know it yet. Now with the down economy they actually have to be better than the competition and can't just survive by endlessly rolling over credit lines. Hence, the greater need for engineers who can create a technological vision for the company instead of just doing what they are told to do by clueless bosses.
I'm always amused when I read stories like this about how X or Y is the only possible future of development.
What works for one application or company doesn't necessarily work for the next. This isn't a one-size-fits-all industry. If it were every company would be using the same languages with the same methodologies.
Meh.
If you do what you always did, you get what you always got.
Leaving development decisions to core programmers can lead to chaos in development priorities. A hard core coder may spend large amounts of time chasing down just that little bit of latency in the process scheduler; but what the business needs is a rewrite in order to simplify processes.
This is why the OS model has a hard time living in the corporate environment. Many times what needs to be done for the business is tedious programming driven by idiots (== users). No one wants to do that. So a core group of programmers ends up adding a plethora of new features that are elegant in implementation, advanced in design, and useless for users.
The other major factor in corporate America (can't speak for the other 96% of the world) is the vast armies of "business analysts". These people allegedly have communication skills with both users and coders. In reality, however, they are incented to drag out projects in requirements and testing phases in order to make their own functions seem more useful. Many projects I've worked on have burned upwards of 3/4 of the hours billed to business analysts.
The remedy? Coders who can speak Business, are WILLING to speak Business, are willing to let the needs of the users drive their projects, and the ability to code. In that order. These people are far and few between, sadly.
I've seen my share of products fail miserably because nobody brought in the business analysts or consultants to gather functional and end-user requirements and spec out the system, and, generally, drive the project. Consequently, the engineers are left with an incomplete or incorrect idea of what to build or of what the acceptance criteria should actually be.
Lawyers can charge what they do and sell themselves as highly skilled practitioners because they passed the Bar exam, which acts as both a hurdle to keep everyone and their uncle out, and as an indicator of some standard level of performance.
"Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled. So, the field is flooded with tons of mediocre and unskilled coders, punctuated by the rare skilled programmer. This drives salaries down. Everyone in the field is forced to undersell themselves lest they be underbid by one of the many who are all talk and no skill.
What software engineers need are credible and selective certification programs so that the few very talented professionals who pass can authoritatively show themselves to be skilled. This would definitely help weed the field of posers and amateurs and bring salaries up to where they should be.
Switch to the open source model of development where the only things that get implemented are the things the developers are interested in. With all due respect, this would be a return to the bad old days of mainframes when users had to put up with whatever the data processing department built and be happy that they had any automation at all.
One of the dumbest ideas I've seen on my screen in one devil of a long time.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
"Coders" have no such yard stick. Anyone and their uncle can call themselves "coders" or, even more outrageously, call themselves software engineers. There's really no certification, standardized exam, or prestigious private college out there whereby one can stand out as highly skilled.
You mean my MCSE doesn't make me a skilled software engineer?
Open source development is not Agile. One of the critical activities in Agile development is paying some attention to the users.
Actually, open source developers do. Sometimes, it's just that the users are themselves.
Besides, Agile isn't about paying attention to the users per se... it's paying attention to the people who the payer wants to enable. Again, in the open source world, that might well be the developer himself (paying in time, not money).
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Wow, that's an incredibly arrogant and impossibly high bar to meet. I guess you want to limit the number of "certified" software developers to what, 300? And do what with the rest, fire them all?
I don't agree here...
As Eric Raymond says, "scratch one's itch" does not imply listening to users.
Put it as follows. We all drive cars, but using scratch one's itch it implies that we are all mechanics as well. And that is not the case, though it can be said that all mechanics do drive cars.
What the article is getting at is that you understand the user that you are empowering. In my case it is being able to understand the formulas and mathematics of the trader trying to define a trading system.
The main difference between the open source you're thinking of and the user situation is that these user's are actually willing to pay. Thus, any itch they have will the developer's itch, since the developer want them happy. Of course, for this to work, user happiness would need to actually figure in the bill payers success criterion, which is surprisingly often not the case. I'd argue that the developers would do themselves a favor making sure that it does, though.
Still, for pure open source (scratch you itch) type of open source, the user (=developer) is listened to. Indeed, that does mean that everyone who is not a mechanic is not a user --- because everyone who is not a mechanic does not pay (in time).
Is it clear now? Not entirely sober, so if I'm not I apologize.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Dont you watch the mass media? The media are run by people who failed basic science, and assume that, because they are clueless about sci/tech, that anyone with sci/tech understanding must be as clueless about the rest of the world as they are about sci/tech.
Not only that, they often have a huge personal comittment to protraying techies as "wierd" because it justifies their own willful ignorance.
Sent from my ASR33 using ASCII
The skill range is actually infinity, as there are people who just cant program.
Of those that can 100:1 is normal
The US is going to have to grow up, and get educated again, or other places really will eat their lunch. Fortunately Obama seems to realise this, but neither Mainstreet or the rest of the world will put up with the MBA/Wall street culture again.
If you listened to the G20 proceedings you will realise just how surely the game is up
Agile is about keeping coders dumb by not allowing them to look more than two feet in front of their nose. It's about protecting managers from being cut out of the decision process entirely. Which they should be.
As for the actual article, seems to me that it's the managers whose days are numbered. Coders who have people skills will become managers, coders who don't will remain serfs, and managers who have no technical skills will become unemployed. It won't happen overnight... some existing businesses will continue to employ those managers. But that choice will kill those businesses, because they're basically putting blind men in charge. It'll take time though...
-1 Uncomfortable Truth
A whole hell of a lot of managers are managers because they can kiss ass, and not because they can manage. If and when their boss realizes this the #2 ass kisser then becomes managers..rinse and repeat..news at 10.
Programmers are neither abstractly creative nor socially comfortable by default; in my experience it is usually the reverse. To be blunt, they are the worst spellers, often haven't read a book (not text, paper or graphic novel...'book') since high school, and have the communication skills of, well, that chubby guy sitting in the corner staring at the ceiling.
Besides, you only need *one* guy on a team who doesn't sweat like the proverbial whore in church every time he/she has to speak in front of a crowd. Call him king geek, let him speak on behalf the team, and let the rest of the guys get back to work. This is known as "the way it currently works".
Give a programmer a debugger, a pack of Redbull and some clearly defined goals, and he'll work magic. Put him in a suit and tell him to pitch a few new ideas and he'll show up with a cheetos-stained tie and a stress-induced facial tic.
Plato once suggested that we should all be assigned our jobs at birth, and that philosophers should be the leaders. This is sort of like that, but less realistic.
This same bit of rhetoric happens ever time there is a downturn in the IT economy. It never happens the way it is predicted because coding ends up being harder then the authors think.
As for Agile - another fad, this too shall pass. (We called it prototyping last time around and it failed then too.)
That's because there are no Pointy Haired Managers, and no dumb coders.
Agile is good a the following:
#1. Product managers and development team leaders can use the make believe "persona" as a way to beat each other over the head with their agenda.
#2. Lets management push developers hard on short term wins that generate enough change to justify a short release schedule and drive up renewal revenue.
What agile seems to be bad for:
#1. Any hope of major architectural change is out the window, along with anything requiring more than a few months to make happen.
#2. QA drops through the floor. Features come fast and furious and compromises have to be made. A strive for mediocrity rules the day.
#3. Documentation ceases to exist in any meaningful sense.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
The last thing a business needs is some pack of rain man coders directing where projects go.
Deep coders are too hyper-focused to understand business needs and the people running the business are too focused on that to understand the code.
In the real world where jobs depend on money and deadlines there need to be abstraction layers between the people writing the code and the people running the project.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I'll tell you what's chilling: a whole bunch of schools these days teach "whole-word reading". This turns English into Chinese.
Instead of teaching the basic phonics, so that a student can "sound out" any word she/he has never seen before, this idea is that the student should learn to recognize a whole word as a gestalt. If you visit a primary school and see posters where there are words surrounded by outlines that emphasize their shape, you are in a whole-word school.
If you don't know the phonics, learning one word doesn't help you learn another. It's just like Chinese, where you have to memorize all the words as pictures. (It's a pretty close analogy; the Chinese for "ice" contains the Chinese letter for "water", just like the word "therein" contains the word "there". But learning "there" doesn't help you learn "theatre".) It's actually harder to learn whole-word English than Chinese, because English can be written in capital letters, or italics; while Chinese letters are always written the same way.
This disastrous idea came about because someone studied adults and found that most adults have learned to recognize words as gestalts. Why not, then, teach the young ones to do this? Just skip past that wasteful phonics thingy and go straight to the productive whole-word reading. But this isn't really the best for kids, as many studies have shown.
Kids need to learn the phonics, to give them the tools to tackle words they have never seen before.
Thank God I was taught phonics when I was young.
Teach the kids whole word reading if you must -- AFTER they have learned their phonics. Young kids have sponges for brains and can learn more than one way. Just give them the phonics tools they need.
http://www.halcyon.org/wholelan.html
I think that the more layers of people that there are between developers and users, the less appropriate or useful the product will eventually be.
This is all just my personal opinion.
I've often been tempted to call them and discuss the placement of components, whenever I've had to replace a headlight. People who design engine compartments should have a mandatory period of working as mechanics first.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.