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.
Proponents of Agile development and similar philosophies have been saying exactly this for many years now. Where have you been?
...let the inmates run the asylum. I for one welcome our monkey-poo-flinging overlords!
where links are checked before they are submitted/published? Or are you just relying on the open-source crowd to tell you that you get a 404 when you click on the 2nd link?
Monstar L
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.
Coding skills are still a necessity. However they never have been sufficient (as the Example of the Reiser vs. Kernel developers shows). If you look in many completely failed projects of the past, and you read the story carefully, a lack of communcation is a very likely reason for *big* trouble (Read the Commodore story....).
There is a lot to be said for the bazaar model of intellectual work. The open source model is certainly an early adopter but by no means does it have a lock on this approach.
There is a whole new crop of innovation management tools that use crowd-sourcing techniques as a better way to work.
May I humbly submit some of my own tools in this field as examples here? Take a look at this general purpose problem solving platform called Cogenuity? Cogenuity currently uses a challenge based approach with a heavy emphasis on social networking and collaboration.
Another tool that I wrote is Code Roller which is a collaborative software development project life cycle management solution. It combines software engineering deliverables, process and workflow with project management practices, social networking features, and a crowd-sourcing style recommendation engine.
Both of these tools are free as in beer.
Oh, by the way, the infoworld link from the original submission here is broken.
The problem wouldn't have arisen in the first place if the programmers have not as a rule undersold their skills (not least by happily working for free) to the point where they are treated like shit and paid accordingly. The way to do it is to emulate lawyers (as a rule less intelligent than programmers, but not when it comes to money) and sell themselves as highly skilled practitioners of a mystical craft that can only be performed in high priced suits with gold rolexes and not for less than 300K/year
Negative moral value of force outweighs the positive value of good intentions.
Guess this is meant for CEOs and CIOs. Interesting ammunition for office politics, but it's CYA time these days - not the best timing.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Even back in the late 1980's it was obvious that thin pyramid management structures were being toppled through downsizing. Some of my relatives took early retirement from companies due to this. Long chains of management over 15 levels deep were definitely going out of fashion: director, assistant director, senior manager, assistant senior manager, supervising manager, project manager, assistant project manager, team leader, lead programmer, senior programmer, programmer, junior programmer and intern.
Start up companies just a far simpler structure: director, software/hardware architect, team leader, senior programmer and programmer.
Everyone knew about the hazards of "dead man's shoes" and how important it was to keep your skills up to date or lose your career.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
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.'
I think an equal question is where they're going to find more managers who aren't the habit of seeing coders as black boxes into which their decisions go in and desired code comes out.
People like to talk about the archetype of the "techie" who is, of course, good with technology but doesn't understand much else. I suppose I've met people who embody this, but generally, my experience is a little different: I frequently meet programmers who are three dimensional people who may be good at writing, music, presentation... even sales. So I wonder sometimes where this persistent stereotype of the "techie" comes from.
Mind you, this happens the other direction as well: I see programmers who are convinced the "soft skills" of other professionals are easy to pick up and practice and they could be doing any job in the company.
Tweet, tweet.
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.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
Instead, companies should emulate the open source model of development
1. Your mother's basement isn't large enough for the whole company
2. There may be liability issues if you put your company on a diet of pizza and coke
3. Employees want to be paid.
4. It's hard to ship product when all you do is squabble and pull the project in different directions
5. Most of your employees will prefer to shower.
If you mod this as troll you have no sense of humour whatsoever
These posts express my own personal views, not those of my employer
The author states that code improvements should be driven by "the developers with the deepest architectural understanding of the code, the closest interaction with the code, and the most responsibility for the code". However, this is a programmer biased perspective and not at all how a business operates.
A business is focused on making money. For the founders, the owners, the stakeholders with the most financial resources invested, that is what it comes down to. That is why if they find an employee that can generate more of it form them they are more likely to listen and give "the greatest decision-making power" to. Normally this ends up being the sales person, marketer, etc. They become the CEO. Those that are good at making things work become the COO.
While things are going well and the company is successful people will not question this model. Customers will request features, companies will implement them. When resources are short they will hire more people, layers of management gets added, everyone feels like their job is/can go somewhere.
The problem occurs when those in charge become lazy or egotistic. The lazy manager will stop gathering user input, or fail to understand why developers gawk at the 100th feature request that are not followed-up on for the month. The impact on morale is the real cancer that kills ideas and companies.
The egotistic manager will achieve similar results, but for different motivations. The incessant push for their ideas, the attempt at pressuring coders to succeed for them, etc. is too shallow and most egotistic managers are not good enough leaders/manipulators to actually motivate people even if it were for purely selfish purposes.
For a coder the best skill is not communication skills, although it is important, but business skills. If you can make money, you can do whatever you want. If you are good enough you can leave all the petty office politics behind and start your own enterprise.
Following another manager, however great, will never lead to security for the pure developer. This is because in the scheme of things you are just carrying out the vision of someone who helps the company achieve financial success. Just as soldiers are trained not to think too much, that is what managers want out of their coders as well when they have an agenda.
The times where I have seen managers ask developers for ideas and comments are when managers are out of ideas. In which case they do so less out of a willingness to communicate and more out of desperation. That is why many CEOs describe their job as cultivating a culture because in a "my way or the highway" environment there is no way people will bother suggesting alternatives.
If a coder wants security they need to first prove their worthiness to decision makers that they can be one of them, then lead and succeed for the organization; basically become a manager themselves. All of this requires a lot of investment in time and effort away from the text editor/IDE and a lot more time in front of people.
This is why there will always be a divide between managers and coders, the roles simply require different skill sets and to be good at either is not easy. The best of either class are good at reaching out, which still requires both parties to be willing to participate for the exchange to occur.
I have worked with people who can be categorized as coders. Some of them are good in writing down code blocks some of them are not so good at it. However, most of them arm poor in communicating, contributing in the design phase, or shutting up and implementing the stuff they're asked to do.
The problem is, that they like to code, but not to plan. But without proper planning no project ever gets finished. So the first problem is that they do not really contribute to the high-level design (if they are invited) then they are not very communicative when they are asked to contribute to the detailed design. Mostly for strange reasons:
a) The high-level design is flawed in their eyes, but they never bothered to tell anybody when they were asked.
b) The don't like one or two technical decisions. This demotivates them.
When you reach implementation phase, they hate to read documentation of the design or underlying frameworks, which results in duplication of framework functions. They work that way because they like to code, but hate to read specs., framework documentation, or the design. Sometimes they deviate from the design, just because they think their idea is better than the concept in the design.
So it is difficult to catch them before they go crazy and you have to look after them often. At least until they know the routine. And the frameworks used.
It is easier to work with people with more CS knowledge, because they understand the necessary of proper planning and design. They are able to discuss design issues and most of them speak their mind. Also they are able to have a discussion and accept better arguments from their colleges. Also most of them are able to learn a new language more quickly.
Well what I wrote above is very black and white, but sometimes you have to exaggerate to make a point.
For example, today is 04/04/2009. It's a very useful technique, maybe Slashdot just wanted to let us the power at our fingertips?
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
Now I don't mean to be incendiary, but I notice a lot of arrogance on the parts of most so-called coders. Disparaging talk of 'manual labors' and exalted speech on the superlative intelligence of coders over other complicated and nuanced professions (i.e. lawyers) seems prevalent in this thread.
But at the end of the day, coders are the manual laborers of the software world, and that is not a bad thing. Anyone who has worked a physical job will be able to immediately tell you the difference between a skilled manual laborer and an idiot who happens to own a hammer. But just as your house, your car, your clothes, your computer hardware, your appliances, and pretty much everything else you use was built by a manual laborer, so also is the software that you use coded by a manual laborer.
The suggested paradigm shift of moving more of the decision making to the programmers makes sense to a degree, so long as those programmers are able to step outside of their insular worlds and be completely cognizant of the role they play.
A construction site has staffed with a strata of management, crew leaders, foremen, etc. Each able to make increasingly more important decisions. A crew leader might be able to tweak the plans a bit to run the conduit here instead of there to make things actually work, but he would not be able to change the placement of the wall. Even if he thought he knew everything about the way the building was to be built, and the engineering of the structure, and the final use. It is not his call. He might be the best damned hammer swinger in the country, but the architect and engineers put the walls where they want them, and it is not his call (no matter how smart he may think he his) to move it.
OK, so this was a long and rambling post, but the final point is that perhaps some of the communication problems that people (read non coders) have with coders is the arrogance and myopic, narcissistic visions they hold.
So the best way to make sure you'll still be not only hirable, but desirable?
Learn Hindi.
Any sufficiently simple magic can be passed off as mere advanced technology.
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.)
Stereotypes aside, that's basically true. Except for the programmers being poor spellers, etc. It's not programmers. It's really pretty much everyone that's graduated in the past decade or so. That might be some hyperbole, but it's not far from the truth. I mean, just look at how the 30+ crowd writes, and then compare that to today's high school graduates. It's chilling.
Does anyone remember Matrix Layout (which later became Objects Layout) from the early 90s? You made flowcharts from ready-made blackboxes. The whole thing was drag and drop. It was pretty impressive during the days of DOS. You had a choice of generating EXEs, or C++, Pascal and BASIC (if you wanted to fine-tune your code). An ad in Byte magazine read: "Not a single damn line of code ever again!" And I had thought back then that the days of mainstream coding would be over by the next decade.
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 problem with an "IT BAR exam" equivalent is that software engineering is not yet subject enough to the scientific process to make an objective exam. Can anyone really objectively *prove* that OOP is better than functional or visa versa? That Java is "better than" Lisp? That static typing is better than dynamic? Even objectively proving that goto's are "bad" has been difficult. There's a large psychological aspect to code design.
At best such a test can verify that one is aware of and skilled at different methodologies, paradigms, and languages. But we already have certification programs for specific ones, which is what most HR departments want: a narrow fit.
Plus, the law requires that legal practitioners are licensed before they perform certain activities, such as filing lawsuits. It's not just the knowledge; there's legal restrictions on the unlicensed. I doubt such will exist anytime soon in the software field, except maybe in narrow specialties, such as for medical devices.
Software is weird stuff.
Table-ized A.I.
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
It's often business end people who don't understand the business needs for the code, and don't want to hear it.
Japanese always work in groups. The boss is the coach who negotiates with the team and goes over the business requirements. The team is rewarded or penalized based on results. The coach minimally is but not to the crazy extend as it is in American culture where the CEO gets credit for everything.
Engineers need to make technical decisions and work together in a high performance work group and leaders for different things in the code base will alternate on their own depending on respect and who knows more in each area. The coach just makes sure the business processes are in properly and perhaps gives customer feedback.
Many companies like HP already do this and this is why Japanese cars are so reliable. Engineers make the decisions and not cost saving accountants (with the exception of now Nissan who has American management). If only health insurance companies followed this mantra when accountants make critical medical decisions for the doctors and then the prices skyrocket as a result of mistakes.
Paired programming is annoying but having the geeks hammer it out and do their thing works and the business analysts who has more limited power can make sure it does what it needs to do.
http://saveie6.com/
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 work for a company which has development groups in lots of countries including India. For reasons that might have sounded great in theory, they farmed off a lot of maintenance development to India - hey it's 1/3rd the price!
As a principal / architect I would often be tasked with overseeing their work, or trying to direct their solutions. That experience was incredibly frustrating for multiple reasons:
a) Cultural differences. Indian developers were the most passive bunch I have ever worked with. They never took the initiative on anything, never offered alternative or better ways to do something, never took time to understand *why* they were asked to do something. Basically if a requirement or design said X they would implement X even if it was ambiguous or nonsensical from a business or coding point of view. Other groups in other countries would push back and the process would improve. This meant the devs had to be closely supervised and all changes reviewed and approved. Tasks took 2-3 times as long to complete which negated any cost savings and also pushed out roll-out times.
b) Language issues. Email was fine. Phone communications were a complete nightmare. Many Indians simply couldn't be understood on the phone. Verbal communication is a critical skill for any programmer. I recognize English is not their first language but its still a requirement and many other countries manage it just fine.
c) Revolving door development. Turnover in India was crippling and every fix or update was handled by different people. This made it impossible to imbue business knowledge, or good coding standards or common practice. Development took longer and the code rapidly becomes a mess of hacks and unsafe techniques.
I'm not saying work can't be farmed out but there has to be a core team of long-term developers. Developers who have business knowledge, developers who will speak out when some requirement is bullshit, developers who have some vested interest in the quality of their code. If you treat developers as an interchangeable commodity you will get back complete shit for your efforts and quality will go down the tubes.