Coders, Your Days Are Numbered 305
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 it helps to be.. (Score:5, Insightful)
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.
Either trivial or bullshit (Score:5, Insightful)
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.
Engineers should run tech companies not MBAs (Score:5, Insightful)
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.
One size doesn't fit all (Score:5, Insightful)
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.
Partially right (Score:5, Insightful)
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.
Re:Either trivial or bullshit (Score:5, Insightful)
1. He says that everybody needs to learn communicate. That's trivial.
Trivial or not, there are many so-called "professional" programmers out there who don't seem to understand it. They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone". Well, frankly, you need to be able to communicate those details, so you _should_ be able to talk to somebody about the coding while you're doing it. The focus is on the implementation, not the communication. It should be the other way around.
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.
Did you read the same article as me? I seriously don't see where it says this. What it says it that lead-from-the-top teams where jobs are parcelled out by an architect with a vision and are implemented by junior programmers will go the way of dinosaurs; it says that everyone is going to need to understand the whole product they're implementing it, the business reason why it's necessary, and to interact with the eventual users of the system to ensure that what they're implementing is the right thing.
This isn't news to some of us, but there are still a lot of people out there who don't seem to understand this.
In defense of business analysts... (Score:5, Insightful)
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.
Re:Blame open source (Score:5, Insightful)
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.
Yeah, right (Score:4, Insightful)
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.
Re:Either trivial or bullshit (Score:5, Insightful)
Witness the common reaction to the idea of pair programming: "it'll disturb my concentration... it's hard to hold the details of your coding in your head if you're talking to someone".
Yeah right, that's just the reaction on the outside. On the inside the guy is thinking, "He wants me to do pair programming? He's an idiot. Maybe I'll give him tons of reasons and he'll go away." If you have decent programmers, pair programming is a waste of resources. Much better to have team programming, where each person is working on the different parts of the same project. Then when you have problems, you can discuss them with your partner, not on every single line (should we use a while loop or a for loop here?)
Incidentally, he is right. When I code, I don't think in words, I think in code. If someone speaks to me while I am coding, it can take a second for me to get back into English mode. A similar effect happens when I'm thinking in Spanish and someone unexpectedly says something to me in English. Or when I am playing the piano and someone talks to me.
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
Re:Blame open source (Score:2, Insightful)
"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?
Re:This is extremely old news. (Score:5, Insightful)
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).
Re:Blame open source (Score:3, Insightful)
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?
Re:So it helps to be.. (Score:5, Insightful)
That's why we don't let our HR department do anything more than post ads, collect resumes, run background checks, type up offer letters, deal with lawyers, and handle workplace issues.
If you let these people get their well-meaning tentacles into your business, you are screwed. These people are the code-monkey version of management: willfully proud of knowing nothing about the actual business needs, and inordinately satisfied with their mad HR skills. Only thing worse than an HR "specialist" is an MBA who works on his MBA skillz rather than learning the business he is being paid to support.
We flushed out a lot of the middle-management parasites twenty years ago. Now they seem to be back with new job titles.
Re:This is extremely old news. (Score:3, Insightful)
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.
Re:Either trivial or bullshit (Score:2, Insightful)
They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming
I think this is one extreme to the other - I think pair programming is bad for many reasons, but that doesn't mean I can't communicate. It's important to be able to write documents, communicate with other developers, managers, customers, and so on. But that doesn't mean I want to have to be conversing 40 hours a week for everything I do.
I might as well turn it the other way round and say that someone who thinks that communication is important is incapable of working on their own. Obviously, that would be unfair too - it's most effective to balance these things, rather than being at one extreme.
Re:Either trivial or bullshit (Score:5, Insightful)
I'm sorry, but as someone who has recently been exposed to pair programming I can say you're talking out of your backside. If a programmer can't deal with pair programming them they're a very poor programmer. Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution. If you can't do it then it's likely that your ego is taking over and you're ignoring better solutions.
Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
Re:Either trivial or bullshit (Score:5, Insightful)
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
It's much older than that - IIRC "The Mythical Man Month" first formalized the idea that N programmers do not produce working code N times as fast as 1 programmer, and that's essentially what is happening with paired programming.
The real problem was discussed long ago in "Programmers and Managers" by Kraft. Two skilled programmers operating independently will indeed produce good code faster than two programmers paired. The problem lies with the idea that there is a large supply of "skilled" programmers. There aren't and most of software development methodology for the last thirty or forty years has been aimed at creating processes by which mediocre programmers can produce reasonable quality code in a reasonable time. Unfortunately nothing will ever change the fact that the productivity range of programmers spans an order of magnitude, possibly two depending on who you listen to.
Want good quality results? Hire 5 good programmers, not 15 mediocre programmers. That means that you'll probably have to pay them pretty good coin and treat them well and that is management's real problem. Management dreams of cheap replaceable labor working on an assembly line. After all assembling cars and developing highly sophisticated software have so much in common!
As for the comments on disturbing concentration - absolutely! Any significant chunk of code is highly complex and detailed. It needs to be kept in the head as a whole, in an organized fashion and in detail. It is nothing short of mind boggling that anyone can imagine that a process that requires being continually interrupted and distracted will aid that task. This is nothing but another doomed attempt to take the bottom 10% of the talent pool and try and squeeze some productivity out of them.
Re:Where are they going to find these managers? (Score:3, Insightful)
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.
Range and availability of Skilled People (Score:3, Insightful)
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
Re:This is extremely old news. (Score:4, Insightful)
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...
Re:This is extremely old news. (Score:1, Insightful)
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.
Re:Either trivial or bullshit (Score:1, Insightful)
So you're only catching trivial bugs? Sounds like a communication problem where the other person doesn't understand what you're doing, or not critically thinking about the problem from another perspective... and hence is only looking for trivial spelling errors.
You can't assign creativity ... esp. to developers (Score:2, Insightful)
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.
Re:Either trivial or bullshit (Score:5, Insightful)
I'm sorry, but as someone who has recently been exposed to pair programming I can say you're talking out of your backside. If a programmer can't deal with pair programming them they're a very poor programmer.
Or maybe they just don't want to deal with insulting twits who think that the latest and greatest buzzword is the One True Way to write code.
Re:Either trivial or bullshit (Score:4, Insightful)
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
I once tried pair programming for a few days, and I found the exact same thing. Yes, together, we were more efficient. I could catch bugs the other guy missed while he was typing, which saved him some debugging time. However, it wasn't a huge improvement, I'd say something like 50%, but it took 100% more manpower, so it was a net loss.
What few people realize though is that pair programming is boring for the person without the keyboard. It's mind-numbingly boring. It's like watching someone do mathematics homework for a whole day. I enjoy programming, but watching other people code is a lot less fun.
Older then you think (Score:4, Insightful)
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.)
Re:So it helps to be.. (Score:2, Insightful)
It makes sense. Any 15-year-old geek can code. What makes software engineers and good coders different? The fact they can communicate, work in teams and have experience working together.
In fact Dad was telling me that just recently he hired some Law/InformationSystems graduate to do work that seemed more like a manager's aide. Within two years, he's promoted that guy up to be a junior manager. What he studied had nothing to do with what he's doing, rather, the double degree gave him intelligence and analytical skills which are top-notch and thus, very useful. AS opposed to his actual knowledge on the topics of law and information systems.
~Jarik
Re:This is extremely old news. (Score:3, Insightful)
That's because there are no Pointy Haired Managers, and no dumb coders.
Re:Either trivial or bullshit (Score:2, Insightful)
If a programmer can't deal with pair programming them they're a very poor programmer.
Where did he say he couldn't deal with it?
I might as well claim "If a programmer can't deal with programming on his own, they're a very poor programmer".
Is that fair? Of course not. The debate here is about which is better, and I see no evidence that pair programming is better than two programmers working normally.
The fact that advocates of pair programming can't argue their case, other than resorting to ad hominems of "You must be a crap programmer" for anyone who dares disagree makes me even more reluctant to accept it.
Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution.
Which is done in normal programming too. Just because you don't share a desk and computer 40 hours a week doesn't mean there is no communication.
Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.
And your evidence for this is, compared with two decent programmers who don't work together 40 hours a week? How do they compare on productivity more generally?
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
You almost have it. (Score:4, Insightful)
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.
Re:Either trivial or bullshit (Score:2, Insightful)
finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code
It's not about "volume of code", it's about functionality.
And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on
All this can be done without pair programming too. The reason it usually doesn't happen in most companies is because they don't have the resources to hire twice as many people, so pair programming isn't an option there anyway. If companies could hire twice as many people, then even with non-pair programming, you could still double people up in each area of functionality, thus spreading the knowledge base.
Pair programming only compares well to places with half as many developers, or a straw man version of non-pair programming where everyone works in a sealed box and never communicates with anyone else.
Rain Man coders (Score:2, Insightful)
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.
Re:Either trivial or bullshit (Score:2, Insightful)
Re:Either trivial or bullshit (Score:3, Insightful)
Well I think the idea is to extend programming away from the keyboard, i.e. you can still be "programming" if you're not the one doing the typing, by thinking about the problem and your solution and how it fits with the rest of the program.
What I've never understood is exactly how this is meant to work. Surely you need to do all the planning stuff before you start writing code, even if you have a buddy to assist. At that point all the pre-programming is done so you're just whacking it into the computer, and it's a bit pointless for the buddy to sit around watching you input it. If the concept isn't known to be sound or its integration with the rest of the program hasn't been fully thought out, why on earth would you be writing it already?
Arguably it's better for someone to stop you half way through coding a module to say it ain't gonna work out then to wait until you're finished, but such realisations ought to come before the typing begins.
Re:You can't assign creativity ... esp. to develop (Score:1, Insightful)
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 [halcyon.org]
User-developer connection (Score:3, Insightful)
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.
Re:This is extremely old news. (Score:3, Insightful)
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.
Re:So it helps to be.. (Score:3, Insightful)
Don't say that. That attitude does more harm than anything to the software industry.
Imagine what our cities would be like if people took the line that "anyone who can stack two bricks can build"? Well, that's what our software world looks like, precisely because people have taken the line that "anyone who can stick two lines of VB together can code". See thedailywtf for a depressing amount of proof.
The fact is, even in the middle of a downturn, managers don't want to pay for software engineers if they can afford code monkeys. (And they definitely don't want to pay for software engineers if the CEO's nephew is "really good" with computers and needs work experience.) If you want things to get better, don't tell them they need expensive coders -- tell them the truth, that most people who call themselves coders can't code.
Re:So it helps to be.. (Score:2, Insightful)
You make a fair point. I should change my statement from "Any 15-year-old geek can code" to "a large amount of professional software developers can code as much as 15-year-old geeks".
I think the problem is a large amount of people who have coding as their careers just pick it up as purely a job - so they know how to code one language. They know Java, or they know C++, or more commonly, PHP/ASP/web-based languages. But their knowledge is very narrow and limited - what they've been taught in their course. While the 15-year-old geek is probably doing it for love of computers, and has a broader and more in depth knowledge on coding in general.
It astounds me at times to talk to 'professional' web coders who don't know what a compiler is.
~Jarik