Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Programming as a Profession

News Software Engineering Recommended Books Recommended Links Portraits of Open Source Pioneers
Code Reviews and Inspections Conceptual Integrity Design patterns Inhouse vs Outsourced Applications Development Code Metrics
KISS Principle Programming style Software Life Cycle Models  CMM (Capability Maturity Model) Object-Oriented Addiction
Brooks law Featuritis Agile Crap Slightly Skeptical View on Extreme Programming  CMM (Capability Maturity Model)
Real Insights into Architecture Come Only From Actual Programming Overload Toxic managers Cargo cult programming Etc

A very interesting view about programmer as a profession can be found in Andrey Ershov paper: Aesthetics and the Human Factor in Programming  (CACM, 1972). Another good article is Knuth Computer Programming as an Art

Slightly simplifying there are two contrasting ideologies of programming: Software Realism and Software Idealism. The latter in their turn can be subdivided into two major schools: Stallmanism and Raymondism

Here is how I defined them  in 1999 (the quote below is taken from Softpanorama OSS page):

In the vision of Software Realists programmers like all humans have weaknesses and guided primarily by self-interest and as such requiring formal organization and incentives (direct or indirect) to act outside the limits defined by their own self-interest. Software Realists see the evils of the software world as given and derived from the limited and unhappy choices available, given the inherent moral and intellectual limitations of human beings and existing hardware.   Some of them try to create better software like programmers involved in creation of all BSD flavors but they consider commercial programmers as equals (actually many of them wear two hats) and do not object to reusing the code that they developed pro bono in proprietary software. 

In this slightly tragic worldview the software development is a hard and often underappreciated labor that requires special, pretty rare, talent  People with this talent like talented sport stars (for example tennis players or ice ballet dancers) risk their health while they are young creating short living but tremendously complex artifacts (large software systems are probably the most complex system even created by humans) and for this reason should be remunerated accordingly.  It is important to understand that like in case of artists creating paintings on the sand beach programmers creation are short-lived and the new wave of hardware often wipes them clean.  For example, who now remembers the creators of PL/1 optimizing and debugging compilers, the compilers that were real breakthrough in many areas of complier writing art and in comparison with which some modern compliers still look like junk despite the fact that they were written 30 years ago.

In other words they see that due to immense complexity of those artifacts all software sucks. It is just that some software sucks less. It can be proprietary software, it can be free software -- all depends of the talent of the creators not so much on a particular ideology (which, by the way, can be completely wrong: Soviets invented quite a few new technologies and managed to launch the first man into space).  Thus, in view of Software Realists school the perfection of software is unachievable and old good Unix with its classic codebase might sometimes be preferable to new Turks be it Windows or Linux. That does not mean that Linux or Windows codebase is all crap. That just means that they are just another OSes in a long historical line of such systems. In some areas they might be better then competition, in some worse, but none has the monopoly on innovation (actually Linux is a pretty conservative kernel despite a radical ideology behind it). 

Software Realists are unconvinced by claims of linux superiority and want to see hard facts.  Furthermore, history guided them that the proper tradeoffs between different subsystems of OSes can be ironed out only via long, expensive and painful process that requires strong highly paid managers, programmers and testers who are ready to sacrifices their health for the success of their creation. The real art requires sacrifices and it is better when such sacrifices are properly remunerated, although stores of talented artists who died in poverty are nothing new. 

Because real talents are rare good software is a very expensive thing.  Software realism school  presuppose that modern software is almost always a compromise between the demands of the talent and demands of the marketplace.

The Software Idealist school (both in its Stallmanism and Raymondism incarnations) holds that mankind in general and programmers in particular has not yet achieved their full moral potential, and that they are (at least in principle) perfectible if guided by wonderful new software development ideology.  Foolish and immoral choices inherent in the creation of proprietary software explains the all the evils of the existing software world  and revolution was needed and actually already  came in the form of either free software movement or its less pure form called open source software movement. Both major Software Idealism schools rely on volunteer labor of programmers connected via Internet to produce immortal gems of software wisdom that will crush proprietary software developers like cockroaches. 

In Software Idealism  worldview, whether purely moral incentive actually work in a long run or not and what will happen when Linus Torvalds will become yet another retired dot-com multimillionaire with his own yacht is irrelevant to the achievement of true software justice, justice for all.  This utopian view holds that  volunteer programmer potential is immense and can do everything including improving human nature that should get rid of those outdated  economic rewards for software development and be satisfied  working part time in McDonalds in order to be able to participate in the movement. So the Software Idealism vision promotes pursuit of the highest ideals which somehow guarantee the best software solutions. At the end of the day new liberated men should all storm this evil Bastille of software oppression which is of course Microsoft and dance on its ruins. Sometimes in their enthusiasm  they can attack other sinful old fashioned proprietary software vendors instead of  Microsoft.  Until opening Solaris (and even after that) sometimes their target was Sun.

And if the unwashed masses who corrupt their soils by using Windows are slow in catching on, then it is the role of the intellectual vanguard (the keepers of programming craft who in Eastern Europe might be called "programming intelligentsia") to lead them  - even if in the short run, the masses can be unhappy with the results because they might not be able to use full capabilities of their laptops, cameras or scanners.  In general Software Idealists think that higher considerations should guide us and that those consideration somehow guarantee creation of a better software, the software that is not only better but which is as perfect as it is free.

Again this is a slight simplification but I believe it somehow catches the key points. 


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 03, 2017] Silicon Valley companies have placed lowering wages and flooding the labor market with cheaper labor near the top of their goals and as a business model.

Notable quotes:
"... That's Silicon Valley's dirty secret. Most tech workers in Palo Alto make about as much as the high school teachers who teach their kids. And these are the top coders in the country! ..."
"... I don't see why more Americans would want to be coders. These companies want to drive down wages for workers here and then also ship jobs offshore... ..."
"... Silicon Valley companies have placed lowering wages and flooding the labor market with cheaper labor near the top of their goals and as a business model. ..."
"... There are quite a few highly qualified American software engineers who lose their jobs to foreign engineers who will work for much lower salaries and benefits. This is a major ingredient of the libertarian virus that has engulfed and contaminating the Valley, going hand to hand with assembling products in China by slave labor ..."
"... If you want a high tech executive to suffer a stroke, mention the words "labor unions". ..."
"... India isn't being hired for the quality, they're being hired for cheap labor. ..."
"... Enough people have had their hands burnt by now with shit companies like TCS (Tata) that they are starting to look closer to home again... ..."
"... Globalisation is the reason, and trying to force wages up in one country simply moves the jobs elsewhere. The only way I can think of to limit this happening is to keep the company and coders working at the cutting edge of technology. ..."
"... I'd be much more impressed if I saw that the hordes of young male engineers here in SF expressing a semblance of basic common sense, basic self awareness and basic life skills. I'd say 91.3% are oblivious, idiotic children. ..."
"... Not maybe. Too late. American corporations objective is to low ball wages here in US. In India they spoon feed these pupils with affordable cutting edge IT training for next to nothing ruppees. These pupils then exaggerate their CVs and ship them out en mass to the western world to dominate the IT industry. I've seen it with my own eyes in action. Those in charge will anything/everything to maintain their grip on power. No brag. Just fact. ..."
Oct 02, 2017 | profile.theguardian.com
Terryl Dorian , 21 Sep 2017 13:26
That's Silicon Valley's dirty secret. Most tech workers in Palo Alto make about as much as the high school teachers who teach their kids. And these are the top coders in the country!
Ray D Wright -> RogTheDodge , , 21 Sep 2017 14:52
I don't see why more Americans would want to be coders. These companies want to drive down wages for workers here and then also ship jobs offshore...
Richard Livingstone -> KatieL , , 21 Sep 2017 14:50
+++1 to all of that.

Automated coding just pushes the level of coding further up the development food chain, rather than gets rid of it. It is the wrong approach for current tech. AI that is smart enough to model new problems and create their own descriptive and runnable language - hopefully after my lifetime but coming sometime.

Arne Babenhauserheide -> Evelita , , 21 Sep 2017 14:48
What coding does not teach is how to improve our non-code infrastructure and how to keep it running (that's the stuff which actually moves things). Code can optimize stuff, but it needs actual actuators to affect reality.

Sometimes these actuators are actual people walking on top of a roof while fixing it.

WyntonK , 21 Sep 2017 14:47
Silicon Valley companies have placed lowering wages and flooding the labor market with cheaper labor near the top of their goals and as a business model.

There are quite a few highly qualified American software engineers who lose their jobs to foreign engineers who will work for much lower salaries and benefits. This is a major ingredient of the libertarian virus that has engulfed and contaminating the Valley, going hand to hand with assembling products in China by slave labor .

If you want a high tech executive to suffer a stroke, mention the words "labor unions".

TheEgg -> UncommonTruthiness , , 21 Sep 2017 14:43

The ship has sailed on this activity as a career.

Nope. Married to a highly-technical skillset, you can still make big bucks. I say this as someone involved in this kind of thing academically and our Masters grads have to beat the banks and fintech companies away with dog shits on sticks. You're right that you can teach anyone to potter around and throw up a webpage but at the prohibitively difficult maths-y end of the scale, someone suitably qualified will never want for a job.

Mike_Dexter -> Evelita , , 21 Sep 2017 14:43
In a similar vein, if you accept the argument that it does drive down wages, wouldn't the culprit actually be the multitudes of online and offline courses and tutorials available to an existing workforce?
Terryl Dorian -> CountDooku , , 21 Sep 2017 14:42
Funny you should pick medicine, law, engineering... 3 fields that are *not* taught in high school. The writer is simply adding "coding" to your list. So it seems you agree with his "garbage" argument after all.
anticapitalist -> RogTheDodge , , 21 Sep 2017 14:42
Key word is "good". Teaching everyone is just going to increase the pool of programmers code I need to fix. India isn't being hired for the quality, they're being hired for cheap labor. As for women sure I wouldn't mind more women around but why does no one say their needs to be more equality in garbage collection or plumbing? (And yes plumbers are a high paid professional).

In the end I don't care what the person is, I just want to hire and work with the best and not someone I have to correct their work because they were hired by quota. If women only graduate at 15% why should IT contain more than that? And let's be a bit honest with the facts, of those 15% how many spend their high school years staying up all night hacking? Very few. Now the few that did are some of the better developers I work with but that pool isn't going to increase by forcing every child to program... just like sports aren't better by making everyone take gym class.

WithoutPurpose , 21 Sep 2017 14:42
I ran a development team for 10 years and I never had any trouble hiring programmers - we just had to pay them enough. Every job would have at least 10 good applicants.

Two years ago I decided to scale back a bit and go into programming (I can code real-time low latency financial apps in 4 languages) and I had four interviews in six months with stupidly low salaries. I'm lucky in that I can bounce between tech and the business side so I got a decent job out of tech.

My entirely anecdotal conclusion is that there is no shortage of good programmers just a shortage of companies willing to pay them.

oddbubble -> Tori Turner , , 21 Sep 2017 14:41
I've worn many hats so far, I started out as a started out as a sysadmin, then I moved on to web development, then back end and now I'm doing test automation because I am on almost the same money for half the effort.
peter nelson -> raffine , , 21 Sep 2017 14:38
But the concepts won't. Good programming requires the ability to break down a task, organise the steps in performing it, identify parts of the process that are common or repetitive so they can be bundled together, handed-off or delegated, etc.

These concepts can be applied to any programming language, and indeed to many non-software activities.

Oliver Jones -> Trumbledon , , 21 Sep 2017 14:37
In the city maybe with a financial background, the exception.
anticapitalist -> Ethan Hawkins , 21 Sep 2017 14:32
Well to his point sort of... either everything will go php or all those entry level php developers will be on the street. A good Java or C developer is hard to come by. And to the others, being a being a developer, especially a good one, is nothing like reading and writing. The industry is already saturated with poor coders just doing it for a paycheck.
peter nelson -> Tori Turner , 21 Sep 2017 14:31
I'm just going to say this once: not everyone with a computer science degree is a coder.

And vice versa. I'm retiring from a 40-year career as a software engineer. Some of the best software engineers I ever met did not have CS degrees.

KatieL -> Mishal Almohaimeed , 21 Sep 2017 14:30
"already developing automated coding scripts. "

Pretty much the entire history of the software industry since FORAST was developed for the ORDVAC has been about desperately trying to make software development in some way possible without driving everyone bonkers.

The gulf between FORAST and today's IDE-written, type-inferring high level languages, compilers, abstracted run-time environments, hypervisors, multi-computer architectures and general tech-world flavour-of-2017-ness is truly immense[1].

And yet software is still fucking hard to write. There's no sign it's getting easier despite all that work.

Automated coding was promised as the solution in the 1980s as well. In fact, somewhere in my archives, I've got paper journals which include adverts for automated systems that would programmers completely redundant by writing all your database code for you. These days, we'd think of those tools as automated ORM generators and they don't fix the problem; they just make a new one -- ORM impedance mismatch -- which needs more engineering on top to fix...

The tools don't change the need for the humans, they just change what's possible for the humans to do.

[1] FORAST executed in about 20,000 bytes of memory without even an OS. The compile artifacts for the map-reduce system I built today are an astonishing hundred million bytes... and don't include the necessary mapreduce environment, management interface, node operating system and distributed filesystem...

raffine , 21 Sep 2017 14:29
Whatever they are taught today will be obsolete tomorrow.
yannick95 -> savingUK , , 21 Sep 2017 14:27
"There are already top quality coders in China and India"

AHAHAHAHAHAHAHAHAHAHAHA *rolls on the floor laughting* Yes........ 1%... and 99% of incredibly bad, incompetent, untalented one that produce cost 50% of a good developer but produce only 5% in comparison. And I'm talking with a LOT of practical experience through more than a dozen corporations all over the world which have been outsourcing to India... all have been disasters for the companies (but good for the execs who pocketed big bonuses and left the company before the disaster blows up in their face)

Wiretrip -> mcharts , , 21 Sep 2017 14:25
Enough people have had their hands burnt by now with shit companies like TCS (Tata) that they are starting to look closer to home again...
TomRoche , 21 Sep 2017 14:11

Tech executives have pursued [the goal of suppressing workers' compensation] in a variety of ways. One is collusion – companies conspiring to prevent their employees from earning more by switching jobs. The prevalence of this practice in Silicon Valley triggered a justice department antitrust complaint in 2010, along with a class action suit that culminated in a $415m settlement.

Folks interested in the story of the Techtopus (less drily presented than in the links in this article) should check out Mark Ames' reporting, esp this overview article and this focus on the egregious Steve Jobs (whose canonization by the US corporate-funded media is just one more impeachment of their moral bankruptcy).

Another, more sophisticated method is importing large numbers of skilled guest workers from other countries through the H1-B visa program. These workers earn less than their American counterparts, and possess little bargaining power because they must remain employed to keep their status.

Folks interested in H-1B and US technical visas more generally should head to Norm Matloff 's summary page , and then to his blog on the subject .

Olympus68 , 21 Sep 2017 13:49

I have watched as schools run by trade unions have done the opposite for the 5 decades. By limiting the number of graduates, they were able to help maintain living wages and benefits. This has been stopped in my area due to the pressure of owners run "trade associations".

During that same time period I have witnessed trade associations controlled by company owners, while publicising their support of the average employee, invest enormous amounts of membership fees in creating alliances with public institutions. Their goal has been that of flooding the labor market and thus keeping wages low. A double hit for the average worker because membership fees were paid by employees as well as those in control.

And so it goes....

savingUK , 21 Sep 2017 13:38
Coding jobs are just as susceptible to being moved to lower cost areas of the world as hardware jobs already have. It's already happening. There are already top quality coders in China and India. There is a much larger pool to chose from and they are just as good as their western counterparts and work harder for much less money.

Globalisation is the reason, and trying to force wages up in one country simply moves the jobs elsewhere. The only way I can think of to limit this happening is to keep the company and coders working at the cutting edge of technology.

whitehawk66 , 21 Sep 2017 15:18

I'd be much more impressed if I saw that the hordes of young male engineers here in SF expressing a semblance of basic common sense, basic self awareness and basic life skills. I'd say 91.3% are oblivious, idiotic children.

They would definitely not survive the zombie apocalypse.

P.S. not every kid wants or needs to have their soul sucked out of them sitting in front of a screen full of code for some idiotic service that some other douchbro thinks is the next iteration of sliced bread.

UncommonTruthiness , 21 Sep 2017 14:10
The demonization of Silicon Valley is clearly the next place to put all blame. Look what "they" did to us: computers, smart phones, HD television, world-wide internet, on and on. Get a rope!

I moved there in 1978 and watched the orchards and trailer parks on North 1st St. of San Jose transform into a concrete jungle. There used to be quite a bit of semiconductor equipment and device manufacturing in SV during the 80s and 90s. Now quite a few buildings have the same name : AVAILABLE. Most equipment and device manufacturing has moved to Asia.

Programming started with binary, then machine code (hexadecimal or octal) and moved to assembler as a compiled and linked structure. More compiled languages like FORTRAN, BASIC, PL-1, COBOL, PASCAL, C (and all its "+'s") followed making programming easier for the less talented. Now the script based languages (HTML, JAVA, etc.) are even higher level and accessible to nearly all. Programming has become a commodity and will be priced like milk, wheat, corn, non-unionized workers and the like. The ship has sailed on this activity as a career.

William Fitch III , 21 Sep 2017 13:52
Hi: As I have said many times before, there is no shortage of people who fully understand the problem and can see all the connections.

However, they all fall on their faces when it comes to the solution. To cut to the chase, Concentrated Wealth needs to go, permanently. Of course the challenge is how to best accomplish this.....

.....Bill

MostlyHarmlessD , , 21 Sep 2017 13:16

Damn engineers and their black and white world view, if they weren't so inept they would've unionized instead of being trampled again and again in the name of capitalism.
mcharts -> Aldous0rwell , , 21 Sep 2017 13:07
Not maybe. Too late. American corporations objective is to low ball wages here in US. In India they spoon feed these pupils with affordable cutting edge IT training for next to nothing ruppees. These pupils then exaggerate their CVs and ship them out en mass to the western world to dominate the IT industry. I've seen it with my own eyes in action. Those in charge will anything/everything to maintain their grip on power. No brag. Just fact.

Woe to our children and grandchildren.

Where's Bernie Sanders when we need him.

[Oct 03, 2017] The dream of coding automation remain illusive... Very illusive...

Oct 03, 2017 | discussion.theguardian.com

Richard Livingstone -> Mishal Almohaimeed , 21 Sep 2017 14:46

Wrong again, that approach has been tried since the 80s and will keep failing only because software development is still more akin to a technical craft than an engineering discipline. The number of elements required to assemble a working non trivial system is way beyond scriptable.
freeandfair -> Taylor Dotson , 21 Sep 2017 14:26
> That's some crystal ball you have there. English teachers will need to know how to code? Same with plumbers? Same with janitors, CEOs, and anyone working in the service industry?

You don't believe there will be robots to do plumbing and cleaning? The cleaner's job will be to program robots to do what they need.
CEOs? Absolutely.

English teachers? Both of my kids have school laptops and everything is being done on the computers. The teachers use software and create websites and what not. Yes, even English teachers.

Not knowing / understanding how to code will be the same as not knowing how to use Word/ Excel. I am assuming there are people who don't, but I don't know any above the age of 6.

Wiretrip -> Mishal Almohaimeed , 21 Sep 2017 14:20
We've had 'automated coding scripts' for years for small tasks. However, anyone who says they're going to obviate programmers, analysts and designers doesn't understand the software development process.
Ethan Hawkins -> David McCaul , 21 Sep 2017 13:22
Even if expert systems (an 80's concept, BTW) could code, we'd still have a huge need for managers. The hard part of software isn't even the coding. It's determining the requirements and working with clients. It will require general intelligence to do 90% of what we do right now. The 10% we could automate right now, mostly gets in the way. I agree it will change, but it's going to take another 20-30 years to really happen.
Mishal Almohaimeed -> PolydentateBrigand , , 21 Sep 2017 13:17
wrong, software companies are already developing automated coding scripts. You'll get a bunch of door to door knives salespeople once the dust settles that's what you'll get.
freeandfair -> rgilyead , , 21 Sep 2017 14:22
> In 20 years time AI will be doing the coding

Possible, but your still have to understand how AI operates and what it can and cannot do.

[Oct 03, 2017] Coding and carpentry are not so distant, are they ?

Thw user "imipak" views are pretty common misconceptions. They are all wrong.
Notable quotes:
"... I was about to take offence on behalf of programmers, but then I realized that would be snobbish and insulting to carpenters too. Many people can code, but only a few can code well, and fewer still become the masters of the profession. Many people can learn carpentry, but few become joiners, and fewer still become cabinetmakers. ..."
"... Many people can write, but few become journalists, and fewer still become real authors. ..."
Oct 03, 2017 | discussion.theguardian.com

imipak, 21 Sep 2017 15:13

Coding has little or nothing to do with Silicon Valley. They may or may not have ulterior motives, but ultimately they are nothing in the scheme of things.

I disagree with teaching coding as a discrete subject. I think it should be combined with home economics and woodworking because 90% of these subjects consist of transferable skills that exist in all of them. Only a tiny residual is actually topic-specific.

In the case of coding, the residual consists of drawing skills and typing skills. Programming language skills? Irrelevant. You should choose the tools to fit the problem. Neither of these needs a computer. You should only ever approach the computer at the very end, after you've designed and written the program.

Is cooking so very different? Do you decide on the ingredients before or after you start? Do you go shopping half-way through cooking an omelette?

With woodwork, do you measure first or cut first? Do you have a plan or do you randomly assemble bits until it does something useful?

Real coding, taught correctly, is barely taught at all. You teach the transferable skills. ONCE. You then apply those skills in each area in which they apply.

What other transferable skills apply? Top-down design, bottom-up implementation. The correct methodology in all forms of engineering. Proper testing strategies, also common across all forms of engineering. However, since these tests are against logic, they're a test of reasoning. A good thing to have in the sciences and philosophy.

Technical writing is the art of explaining things to idiots. Whether you're designing a board game, explaining what you like about a house, writing a travelogue or just seeing if your wild ideas hold water, you need to be able to put those ideas down on paper in a way that exposes all the inconsistencies and errors. It doesn't take much to clean it up to be readable by humans. But once it is cleaned up, it'll remain free of errors.

So I would teach a foundation course that teaches top-down reasoning, bottom-up design, flowcharts, critical path analysis and symbolic logic. Probably aimed at age 7. But I'd not do so wholly in the abstract. I'd have it thoroughly mixed in with one field, probably cooking as most kids do that and it lacks stigma at that age.

I'd then build courses on various crafts and engineering subjects on top of that, building further hierarchies where possible. Eliminate duplication and severely reduce the fictions we call disciplines.

oldzealand, 21 Sep 2017 14:58
I used to employ 200 computer scientists in my business and now teach children so I'm apparently as guilty as hell. To be compared with a carpenter is, however, a true compliment, if you mean those that create elegant, aesthetically-pleasing, functional, adaptable and long-lasting bespoke furniture, because our crafts of problem-solving using limited resources in confined environments to create working, life-improving artifacts both exemplify great human ingenuity in action. Capitalism or no.
peter nelson, 21 Sep 2017 14:29
"But coding is not magic. It is a technical skill, akin to carpentry."

But some people do it much better than others. Just like journalism. This article is complete nonsense, as I discuss in another comment. The author might want to consider a career in carpentry.

Fanastril, 21 Sep 2017 14:13
"But coding is not magic. It is a technical skill, akin to carpentry."

It is a way of thinking. Perhaps carpentry is too, but the arrogance of the above statement shows a soul who is done thinking.

NDReader, 21 Sep 2017 14:12
"But coding is not magic. It is a technical skill, akin to carpentry."

I was about to take offence on behalf of programmers, but then I realized that would be snobbish and insulting to carpenters too. Many people can code, but only a few can code well, and fewer still become the masters of the profession. Many people can learn carpentry, but few become joiners, and fewer still become cabinetmakers.

Many people can write, but few become journalists, and fewer still become real authors.

MostlyHarmlessD, 21 Sep 2017 13:08
A carpenter!? Good to know that engineers are still thought of as jumped up tradesmen.

[Oct 02, 2017] Programming vs coding

This idiotic US term "coder" is complete baloney.
Notable quotes:
"... You can learn to code, but that doesn't mean you'll be good at it. There will be a few who excel but most will not. This isn't a reflection on them but rather the reality of the situation. In any given area some will do poorly, more will do fairly, and a few will excel. The same applies in any field. ..."
"... Oh no, there's loads of people who say they're coders, who have on their CV that they're coders, that have been paid to be coders. Loads of them. Amazingly, about 9 out of 10 of them, experienced coders all, spent ages doing it, not a problem to do it, definitely a coder, not a problem being "hands on"... can't actually write working code when we actually ask them to. ..."
"... I feel for your brother, and I've experienced the exact same BS "test" that you're describing. However, when I said "rudimentary coding exam", I wasn't talking about classic fiz-buz questions, Fibonacci problems, whiteboard tests, or anything of the sort. We simply ask people to write a small amount of code that will solve a simple real world problem. Something that they would be asked to do if they got hired. We let them take a long time to do it. We let them use Google to look things up if they need. You would be shocked how many "qualified applicants" can't do it. ..."
"... "...coding is not magic. It is a technical skill, akin to carpentry. " I think that is a severe underestimation of the level of expertise required to conceptualise and deliver robust and maintainable code. The complexity of integrating software is more equivalent to constructing an entire building with components of different materials. If you think teaching coding is enough to enable software design and delivery then good luck. ..."
"... Being able to write code and being able to program are two very different skills. In language terms its the difference between being able to read and write (say) English and being able to write literature; obviously you need a grasp of the language to write literature but just knowing the language is not the same as being able to assemble and marshal thought into a coherent pattern prior to setting it down. ..."
"... What a dumpster argument. I am not a programmer or even close, but a basic understanding of coding has been important to my professional life. Coding isn't just about writing software. Understanding how algorithms work, even simple ones, is a general skill on par with algebra. ..."
"... Never mind that a good education is clearly one of the most important things you can do for a person to improve their quality of life wherever they live in the world. It's "neoliberal," so we better hate it. ..."
"... A lot of resumes come across my desk that look qualified on paper, but that's not the same thing as being able to do the job. Secondarily, while I agree that one day our field might be replaced by automation, there's a level of creativity involved with good software engineering that makes your carpenter comparison a bit flawed. ..."
Oct 02, 2017 | profile.theguardian.com
Wiretrip -> Mark Mauvais , 21 Sep 2017 14:23
Yes, 'engineers' (and particularly mathematicians) write appalling code.
Trumbledon , 21 Sep 2017 14:23
A good developer can easily earn £600-800 per day, which suggests to me that they are in high demand, and society needs more of them.
Wiretrip -> KatieL , 21 Sep 2017 14:22
Agreed, to many people 'coding' consists of copying other people's JavaScript snippets from StackOverflow... I tire of the many frauds in the business...
stratplaya , 21 Sep 2017 14:21
You can learn to code, but that doesn't mean you'll be good at it. There will be a few who excel but most will not. This isn't a reflection on them but rather the reality of the situation. In any given area some will do poorly, more will do fairly, and a few will excel. The same applies in any field.
peter nelson -> UncommonTruthiness , 21 Sep 2017 14:21

The ship has sailed on this activity as a career.

Oh, rubbish. I'm in the process of retiring from my job as an Android software designer so I'm tasked with hiring a replacement for my organisation. It pays extremely well, the work is interesting, and the company is successful and serves an important worldwide industry.

Still, finding highly-qualified people is hard and they get snatched up in mid-interview because the demand is high. Not only that but at these pay scales, we can pretty much expect the Guardian will do yet another article about the unconscionable gap between what rich, privileged techies like software engineers make and everyone else.

Really, we're damned if we do and damned if we don't. If tech workers are well-paid we're castigated for gentrifying neighbourhoods and living large, and yet anything that threatens to lower what we're paid produces conspiracy-theory articles like this one.

Fanastril -> Taylor Dotson , 21 Sep 2017 14:17
I learned to cook in school. Was there a shortage of cooks? No. Did I become a professional cook? No. but I sure as hell would not have missed the skills I learned for the world, and I use them every day.
KatieL -> Taylor Dotson , 21 Sep 2017 14:13
Oh no, there's loads of people who say they're coders, who have on their CV that they're coders, that have been paid to be coders. Loads of them. Amazingly, about 9 out of 10 of them, experienced coders all, spent ages doing it, not a problem to do it, definitely a coder, not a problem being "hands on"... can't actually write working code when we actually ask them to.
youngsteveo -> Taylor Dotson , 21 Sep 2017 14:12
I feel for your brother, and I've experienced the exact same BS "test" that you're describing. However, when I said "rudimentary coding exam", I wasn't talking about classic fiz-buz questions, Fibonacci problems, whiteboard tests, or anything of the sort. We simply ask people to write a small amount of code that will solve a simple real world problem. Something that they would be asked to do if they got hired. We let them take a long time to do it. We let them use Google to look things up if they need. You would be shocked how many "qualified applicants" can't do it.
Fanastril -> Taylor Dotson , 21 Sep 2017 14:11
It is not zero-sum: If you teach something empowering, like programming, motivating is a lot easier, and they will learn more.
UncommonTruthiness , 21 Sep 2017 14:10
The demonization of Silicon Valley is clearly the next place to put all blame. Look what "they" did to us: computers, smart phones, HD television, world-wide internet, on and on. Get a rope!

I moved there in 1978 and watched the orchards and trailer parks on North 1st St. of San Jose transform into a concrete jungle. There used to be quite a bit of semiconductor equipment and device manufacturing in SV during the 80s and 90s. Now quite a few buildings have the same name : AVAILABLE. Most equipment and device manufacturing has moved to Asia.

Programming started with binary, then machine code (hexadecimal or octal) and moved to assembler as a compiled and linked structure. More compiled languages like FORTRAN, BASIC, PL-1, COBOL, PASCAL, C (and all its "+'s") followed making programming easier for the less talented.

Now the script based languages (HTML, JAVA, etc.) are even higher level and accessible to nearly all. Programming has become a commodity and will be priced like milk, wheat, corn, non-unionized workers and the like. The ship has sailed on this activity as a career.

KatieL -> Taylor Dotson , 21 Sep 2017 14:10
"intelligence, creativity, diligence, communication ability, or anything else that a job"

None of those are any use if, when asked to turn your intelligent, creative, diligent, communicated idea into some software, you perform as well as most candidates do at simple coding assessments... and write stuff that doesn't work.

peter nelson , 21 Sep 2017 14:09

At its root, the campaign for code education isn't about giving the next generation a shot at earning the salary of a Facebook engineer. It's about ensuring those salaries no longer exist, by creating a source of cheap labor for the tech industry.

Of course the writer does not offer the slightest shred of evidence to support the idea that this is the actual goal of these programs. So it appears that the tinfoil-hat conspiracy brigade on the Guardian is operating not only below the line, but above it, too.

The fact is that few of these students will ever become software engineers (which, incidentally, is my profession) but programming skills are essential in many professions for writing little scripts to automate various tasks, or to just understand 21st century technology.

kcrane , 21 Sep 2017 14:07
Sadly this is another article by a partial journalist who knows nothing about the software industry, but hopes to subvert what he had read somewhere to support a position he had already assumed. As others had said, understanding coding had already become akin to being able to use a pencil. It is a basic requirement of many higher level roles.

But knowing which end of a pencil to put on the paper (the equivalent of the level of coding taught in schools) isn't the same as being an artist. Moreover anyone who knows the field recognises that top coders are gifted, they embody genius. There are coding Caravaggio's out there, but few have the experience to know that. No amount of teaching will produce high level coders from average humans, there is an intangible something needed, as there is in music and art, to elevate the merely good to genius.

All to say, however many are taught the basics, it won't push down the value of the most talented coders, and so won't reduce the costs of the technology industry in any meaningful way as it is an industry, like art, that relies on the few not the many.

DebuggingLife , 21 Sep 2017 14:06
Not all of those children will want to become programmers but at least the barrier to entry, - for more to at least experience it - will be lower.

Teaching music to only the children whose parents can afford music tuition means than society misses out on a greater potential for some incredible gifted musicians to shine through.

Moreover, learning to code really means learning how to wrangle with the practical application of abstract concepts, algorithms, numerical skills, logic, reasoning, etc. which are all transferrable skills some of which are not in the scope of other classes, certainly practically.
Like music, sport, literature etc. programming a computer, a website, a device, a smartphone is an endeavour that can be truly rewarding as merely a pastime, and similarly is limited only by ones imagination.

rgilyead , 21 Sep 2017 14:01
"...coding is not magic. It is a technical skill, akin to carpentry. " I think that is a severe underestimation of the level of expertise required to conceptualise and deliver robust and maintainable code. The complexity of integrating software is more equivalent to constructing an entire building with components of different materials. If you think teaching coding is enough to enable software design and delivery then good luck.
Taylor Dotson -> cwblackwell , 21 Sep 2017 14:00
Yeah, but mania over coding skills inevitably pushes over skills out of the curriculum (or deemphasizes it). Education is zero-sum in that there's only so much time and energy to devote to it. Hence, you need more than vague appeals to "enhancement," especially given the risks pointed out by the author.
Taylor Dotson -> PolydentateBrigand , 21 Sep 2017 13:57
"Talented coders will start new tech businesses and create more jobs."

That could be argued for any skill set, including those found in the humanities and social sciences likely to pushed out by the mania over coding ability. Education is zero-sum: Time spent on one subject is time that invariably can't be spent learning something else.

Taylor Dotson -> WumpieJr , 21 Sep 2017 13:49
"If they can't literally fix everything let's just get rid of them, right?"

That's a strawman. His point is rooted in the recognition that we only have so much time, energy, and money to invest in solutions. One's that feel good but may not do anything distract us for the deeper structural issues in our economy. The probably with thinking "education" will fix everything is that it leaves the status quo unquestioned.

martinusher , 21 Sep 2017 13:31
Being able to write code and being able to program are two very different skills. In language terms its the difference between being able to read and write (say) English and being able to write literature; obviously you need a grasp of the language to write literature but just knowing the language is not the same as being able to assemble and marshal thought into a coherent pattern prior to setting it down.

To confuse things further there's various levels of skill that all look the same to the untutored eye. Suppose you wished to bridge a waterway. If that waterway was a narrow ditch then you could just throw a plank across. As the distance to be spanned got larger and larger eventually you'd have to abandon intuition for engineering and experience. Exactly the same issues happen with software but they're less tangible; anyone can build a small program but a complex system requires a lot of other knowledge (in my field, that's engineering knowledge -- coding is almost an afterthought).

Its a good idea to teach young people to code but I wouldn't raise their expectations of huge salaries too much. For children educating them in wider, more general, fields and abstract activities such as music will pay off huge dividends, far more than just teaching them whatever the fashionable language du jour is. (...which should be Logo but its too subtle and abstract, it doesn't look "real world" enough!).

freeandfair , 21 Sep 2017 13:30
I don't see this is an issue. Sure, there could be ulterior motives there, but anyone who wants to still be employed in 20 years has to know how to code . It is not that everyone will be a coder, but their jobs will either include part-time coding or will require understanding of software and what it can and cannot do. AI is going to be everywhere.
WumpieJr , 21 Sep 2017 13:23
What a dumpster argument. I am not a programmer or even close, but a basic understanding of coding has been important to my professional life. Coding isn't just about writing software. Understanding how algorithms work, even simple ones, is a general skill on par with algebra.

But is isn't just about coding for Tarnoff. He seems to hold education in contempt generally. "The far-fetched premise of neoliberal school reform is that education can mend our disintegrating social fabric." If they can't literally fix everything let's just get rid of them, right?

Never mind that a good education is clearly one of the most important things you can do for a person to improve their quality of life wherever they live in the world. It's "neoliberal," so we better hate it.

youngsteveo , 21 Sep 2017 13:16
I'm not going to argue that the goal of mass education isn't to drive down wages, but the idea that the skills gap is a myth doesn't hold water in my experience. I'm a software engineer and manager at a company that pays well over the national average, with great benefits, and it is downright difficult to find a qualified applicant who can pass a rudimentary coding exam.

A lot of resumes come across my desk that look qualified on paper, but that's not the same thing as being able to do the job. Secondarily, while I agree that one day our field might be replaced by automation, there's a level of creativity involved with good software engineering that makes your carpenter comparison a bit flawed.

[Oct 02, 2017] Does >programming provides a new path to the middle class? Probably no longer, unless you are really talanted. In the latter case it is not that different from any other fields, but the pressure from H1B makes is harder for programmers. The neoliberal USA have a real problem with social mobility

Notable quotes:
"... I do think it's peculiar that Silicon Valley requires so many H1B visas... 'we can't find the talent here' is the main excuse ..."
"... This is interesting. Indeed, I do think there is excess supply of software programmers. ..."
"... Well, it is either that or the kids themselves who have to pay for it and they are even less prepared to do so. Ideally, college education should be tax payer paid but this is not the case in the US. And the employer ideally should pay for the job related training, but again, it is not the case in the US. ..."
"... Plenty of people care about the arts but people can't survive on what the arts pay. That was pretty much the case all through human history. ..."
"... I was laid off at your age in the depths of the recent recession and I got a job. ..."
"... The great thing about software , as opposed to many other jobs, is that it can be done at home which you're laid off. Write mobile (IOS or Android) apps or work on open source projects and get stuff up on github. I've been to many job interviews with my apps loaded on mobile devices so I could show them what I've done. ..."
"... Schools really can't win. Don't teach coding, and you're raising a generation of button-pushers. Teach it, and you're pandering to employers looking for cheap labour. Unions in London objected to children being taught carpentry in the twenties and thirties, so it had to be renamed "manual instruction" to get round it. Denying children useful skills is indefensible. ..."
Oct 02, 2017 | discussion.theguardian.com
swelle , 21 Sep 2017 17:36
I do think it's peculiar that Silicon Valley requires so many H1B visas... 'we can't find the talent here' is the main excuse, though many 'older' (read: over 40) native-born tech workers will tell your that's plenty of talent here already, but even with the immigration hassles, H1B workers will be cheaper overall...

Julian Williams , 21 Sep 2017 18:06

This is interesting. Indeed, I do think there is excess supply of software programmers. There is only a modest number of decent jobs, say as an algorithms developer in finance, general architecture of complex systems or to some extent in systems security. However, these jobs are usually occupied and the incumbents are not likely to move on quickly. Road blocks are also put up by creating sub networks of engineers who ensure that some knowledge is not ubiquitous.

Most very high paying jobs in the technology sector are in the same standard upper management roles as in every other industry.

Still, the ability to write a computer program in an enabler, knowing how it works means you have an ability to imagine something and make it real. To me it is a bit like language, some people can use language to make more money than others, but it is still important to be able to have a basic level of understanding.

FabBlondie -> peter nelson , 21 Sep 2017 17:42
And yet I know a lot of people that has happened to. Better to replace a $125K a year programmer with one who will do the same, or even less, job for $50K.

JMColwill , 21 Sep 2017 18:17

This could backfire if the programmers don't find the work or pay to match their expectations... Programmers, after all tend to make very good hackers if their minds are turned to it.

freeandfair -> FabBlondie , 21 Sep 2017 18:23

> While I like your idea of what designing a computer program involves, in my nearly 40 years experience as a programmer I have rarely seen this done.

Well, I am a software architect and what he says sounds correct for a certain type of applications. Maybe you do a different type of programming.

peter nelson -> FabBlondie , 21 Sep 2017 18:23

While I like your idea of what designing a computer program involves, in my nearly 40 years experience as a programmer I have rarely seen this done.

How else can you do it?

Java is popular because it's a very versatile language - On this list it's the most popular general-purpose programming language. (Above it javascript is just a scripting language and HTML/CSS aren't even programming languages) https://fossbytes.com/most-used-popular-programming-languages/ ... and below it you have to go down to C# at 20% to come to another general-purpose language, and even that's a Microsoft house language.

Also the "correct" choice of programming languages is also based on how many people in the shop know it so they maintain code that's written in it by someone else.

freeandfair -> FabBlondie , 21 Sep 2017 18:22
> job-specific training is completely different. What a joke to persuade public school districts to pick up the tab on job training.

Well, it is either that or the kids themselves who have to pay for it and they are even less prepared to do so. Ideally, college education should be tax payer paid but this is not the case in the US. And the employer ideally should pay for the job related training, but again, it is not the case in the US.

freeandfair -> mlzarathustra , 21 Sep 2017 18:20
> The bigger problem is that nobody cares about the arts, and as expensive as education is, nobody wants to carry around a debt on a skill that won't bring in the buck

Plenty of people care about the arts but people can't survive on what the arts pay. That was pretty much the case all through human history.

theindyisbetter -> Game Cabbage , 21 Sep 2017 18:18
No. The amount of work is not a fixed sum. That's the lump of labour fallacy. We are not tied to the land.
ConBrio , 21 Sep 2017 18:10
Since newspaper are consolidating and cutting jobs gotta clamp down on colleges offering BA degrees, particularly in English Literature and journalism.

And then... and...then...and...

LMichelle -> chillisauce , 21 Sep 2017 18:03
This article focuses on the US schools, but I can imagine it's the same in the UK. I don't think these courses are going to be about creating great programmers capable of new innovations as much as having a work force that can be their own IT Help Desk.

They'll learn just enough in these classes to do that.

Then most companies will be hiring for other jobs, but want to make sure you have the IT skills to serve as your own "help desk" (although they will get no salary for their IT work).

edmundberk -> FabBlondie , 21 Sep 2017 17:57
I find that quite remarkable - 40 years ago you must have been using assembler and with hardly any memory to work with. If you blitzed through that without applying the thought processes described, well...I'm surprised.
James Dey , 21 Sep 2017 17:55
Funny. Every day in the Brexit articles, I read that increasing the supply of workers has negligible effect on wages.
peter nelson -> peterainbow , 21 Sep 2017 17:54
I was laid off at your age in the depths of the recent recession and I got a job. As I said in another posting, it usually comes down to fresh skills and good personal references who will vouch for your work-habits and how well you get on with other members of your team.

The great thing about software , as opposed to many other jobs, is that it can be done at home which you're laid off. Write mobile (IOS or Android) apps or work on open source projects and get stuff up on github. I've been to many job interviews with my apps loaded on mobile devices so I could show them what I've done.

Game Cabbage -> theindyisbetter , 21 Sep 2017 17:52
The situation has a direct comparison to today. It has nothing to do with land. There was a certain amount of profit making work and not enough labour to satisfy demand. There is currently a certain amount of profit making work and in many situations (especially unskilled low paid work) too much labour.
edmundberk , 21 Sep 2017 17:52
So, is teaching people English or arithmetic all about reducing wages for the literate and numerate?

Or is this the most obtuse argument yet for avoiding what everyone in tech knows - even more blatantly than in many other industries, wages are curtailed by offshoring; and in the US, by having offshoring centres on US soil.

chillisauce , 21 Sep 2017 17:48
Well, speaking as someone who spends a lot of time trying to find really good programmers... frankly there aren't that many about. We take most of ours from Eastern Europe and SE Asia, which is quite expensive, given the relocation costs to the UK. But worth it.

So, yes, if more British kids learnt about coding, it might help a bit. But not much; the real problem is that few kids want to study IT in the first place, and that the tuition standards in most UK universities are quite low, even if they get there.

Baobab73 , 21 Sep 2017 17:48
True......
peter nelson -> rebel7 , 21 Sep 2017 17:47
There was recently an programme/podcast on ABC/RN about the HUGE shortage in Australia of techies with specialized security skills.
peter nelson -> jigen , 21 Sep 2017 17:46
Robots, or AI, are already making us more productive. I can write programs today in an afternoon that would have taken me a week a decade or two ago.

I can create a class and the IDE will take care of all the accessors, dependencies, enforce our style-guide compliance, stub-in the documentation ,even most test cases, etc, and all I have to write is very-specific stuff required by my application - the other 90% is generated for me. Same with UI/UX - stubs in relevant event handlers, bindings, dependencies, etc.

Programmers are a zillion times more productive than in the past, yet the demand keeps growing because so much more stuff in our lives has processors and code. Your car has dozens of processors running lots of software; your TV, your home appliances, your watch, etc.

Quaestor , 21 Sep 2017 17:43

Schools really can't win. Don't teach coding, and you're raising a generation of button-pushers. Teach it, and you're pandering to employers looking for cheap labour. Unions in London objected to children being taught carpentry in the twenties and thirties, so it had to be renamed "manual instruction" to get round it. Denying children useful skills is indefensible.

jamesupton , 21 Sep 2017 17:42
Getting children to learn how to write code, as part of core education, will be the first step to the long overdue revolution. The rest of us will still have to stick to burning buildings down and stringing up the aristocracy.
cjenk415 -> LMichelle , 21 Sep 2017 17:40
did you misread? it seemed like he was emphasizing that learning to code, like learning art (and sports and languages), will help them develop skills that benefit them in whatever profession they choose.
FabBlondie -> peter nelson , 21 Sep 2017 17:40
While I like your idea of what designing a computer program involves, in my nearly 40 years experience as a programmer I have rarely seen this done. And, FWIW, IMHO choosing the tool (programming language) might reasonably be expected to follow designing a solution, in practice this rarely happens. No, these days it's Java all the way, from day one.
theindyisbetter -> Game Cabbage , 21 Sep 2017 17:40
There was a fixed supply of land and a reduced supply of labour to work the land.

Nothing like then situation in a modern economy.

LMichelle , 21 Sep 2017 17:39
I'd advise parents that the classes they need to make sure their kids excel in are acting/drama. There is no better way to getting that promotion or increasing your pay like being a skilled actor in the job market. It's a fake it till you make it deal.
theindyisbetter , 21 Sep 2017 17:36
What a ludicrous argument.

Let's not teach maths or science or literacy either - then anyone with those skills will earn more.

SheriffFatman -> Game Cabbage , 21 Sep 2017 17:36

After the Black Death in the middle ages there was a huge under supply of labour. It produced a consistent rise in wages and conditions

It also produced wage-control legislation (which admittedly failed to work).

peter nelson -> peterainbow , 21 Sep 2017 17:32
if there were truly a shortage i wouldn't be unemployed

I've heard that before but when I've dug deeper I've usually found someone who either let their skills go stale, or who had some work issues.

LMichelle -> loveyy , 21 Sep 2017 17:26
Really? You think they are going to emphasize things like the importance of privacy and consumer rights?
loveyy , 21 Sep 2017 17:25
This really has to be one of the silliest articles I read here in a very long time.
People, let your children learn to code. Even more, educate yourselves and start to code just for the fun of it - look at it like a game.
The more people know how to code the less likely they are to understand how stuff works. If you were ever frustrated by how impossible it seems to shop on certain websites, learn to code and you will be frustrated no more. You will understand the intent behind the process.
Even more, you will understand the inherent limitations and what is the meaning of safety. You will be able to better protect yourself in a real time connected world.

Learning to code won't turn your kid into a programmer, just like ballet or piano classes won't mean they'll ever choose art as their livelihood. So let the children learn to code and learn along with them

Game Cabbage , 21 Sep 2017 17:24
Tipping power to employers in any profession by oversupply of labour is not a good thing. Bit of a macabre example here but...After the Black Death in the middle ages there was a huge under supply of labour. It produced a consistent rise in wages and conditions and economic development for hundreds of years after this. Not suggesting a massive depopulation. But you can achieve the same effects by altering the power balance. With decades of Neoliberalism, the employers side of the power see-saw is sitting firmly in the mud and is producing very undesired results for the vast majority of people.
Zuffle -> peterainbow , 21 Sep 2017 17:23
Perhaps you're just not very good. I've been a developer for 20 years and I've never had more than 1 week of unemployment.
Kevin P Brown -> peterainbow , 21 Sep 2017 17:20
" at 55 finding it impossible to get a job"

I am 59, and it is not just the age aspect it is the money aspect. They know you have experience and expectations, and yet they believe hiring someone half the age and half the price, times 2 will replace your knowledge. I have been contracting in IT for 30 years, and now it is obvious it is over. Experience at some point no longer mitigates age. I think I am at that point now.

TheLane82 , 21 Sep 2017 17:20
Completely true! What needs to happen instead is to teach the real valuable subjects.

Gender studies. Islamic studies. Black studies. All important issues that need to be addressed.

peter nelson -> mlzarathustra , 21 Sep 2017 17:06
Dear, dear, I know, I know, young people today . . . just not as good as we were. Everything is just going down the loo . . . Just have a nice cuppa camomile (or chamomile if you're a Yank) and try to relax ... " hey you kids, get offa my lawn !"
FabBlondie , 21 Sep 2017 17:06
There are good reasons to teach coding. Too many of today's computer users are amazingly unaware of the technology that allows them to send and receive emails, use their smart phones, and use websites. Few understand the basic issues involved in computer security, especially as it relates to their personal privacy. Hopefully some introductory computer classes could begin to remedy this, and the younger the students the better.

Security problems are not strictly a matter of coding.

Security issues persist in tech. Clearly that is not a function of the size of the workforce. I propose that it is a function of poor management and design skills. These are not taught in any programming class I ever took. I learned these on the job and in an MBA program, and because I was determined.

Don't confuse basic workforce training with an effective application of tech to authentic needs.

How can the "disruption" so prized in today's Big Tech do anything but aggravate our social problems? Tech's disruption begins with a blatant ignorance of and disregard for causes, and believes to its bones that a high tech app will truly solve a problem it cannot even describe.

Kool Aid anyone?

peterainbow -> brady , 21 Sep 2017 17:05
indeed that idea has been around as long as cobol and in practice has just made things worse, the fact that many people outside of software engineering don;t seem to realise is that the coding itself is a relatively small part of the job
FabBlondie -> imipak , 21 Sep 2017 17:04
Hurrah.
peterainbow -> rebel7 , 21 Sep 2017 17:04
so how many female and old software engineers are there who are unable to get a job, i'm one of them at 55 finding it impossible to get a job and unlike many 'developers' i know what i'm doing
peterainbow , 21 Sep 2017 17:02
meanwhile the age and sex discrimination in IT goes on, if there were truly a shortage i wouldn't be unemployed
Jared Hall -> peter nelson , 21 Sep 2017 17:01
Training more people for an occupation will result in more people becoming qualified to perform that occupation, irregardless of the fact that many will perform poorly at it. A CS degree is no guarantee of competency, but it is one of the best indicators of general qualification we have at the moment. If you can provide a better metric for analyzing the underlying qualifications of the labor force, I'd love to hear it.

Regarding your anecdote, while interesting, it poor evidence when compared to the aggregate statistical data analyzed in the EPI study.

peter nelson -> FabBlondie , 21 Sep 2017 17:00

Job-specific training is completely different.

Good grief. It's not job-specific training. You sound like someone who knows nothing about computer programming.

Designing a computer program requires analysing the task; breaking it down into its components, prioritising them and identifying interdependencies, and figuring out which parts of it can be broken out and done separately. Expressing all this in some programming language like Java, C, or C++ is quite secondary.

So once you learn to organise a task properly you can apply it to anything - remodeling a house, planning a vacation, repairing a car, starting a business, or administering a (non-software) project at work.

[Oct 02, 2017] Evaluation of potential job candidates for programming job should include evaluation of thier previous projects and code written

Notable quotes:
"... Thank you. The kids that spend high school researching independently and spend their nights hacking just for the love of it and getting a job without college are some of the most competent I've ever worked with. Passionless college grads that just want a paycheck are some of the worst. ..."
"... how about how new labor tried to sign away IT access in England to India in exchange for banking access there, how about the huge loopholes in bringing in cheap IT workers from elsewhere in the world, not conspiracies, but facts ..."
"... And I've never recommended hiring anyone right out of school who could not point me to a project they did on their own, i.e., not just grades and test scores. I'd like to see an IOS or Android app, or a open-source component, or utility or program of theirs on GitHub, or something like that. ..."
"... most of what software designers do is not coding. It requires domain knowledge and that's where the "smart" IDEs and AI coding wizards fall down. It will be a long time before we get where you describe. ..."
Oct 02, 2017 | discussion.theguardian.com

peter nelson -> c mm , 21 Sep 2017 19:49

Instant feedback is one of the things I really like about programming, but it's also the thing that some people can't handle. As I'm developing a program all day long the compiler is telling me about build errors or warnings or when I go to execute it it crashes or produces unexpected output, etc. Software engineers are bombarded all day with negative feedback and little failures. You have to be thick-skinned for this work.
peter nelson -> peterainbow , 21 Sep 2017 19:42
How is it shallow and lazy? I'm hiring for the real world so I want to see some real world accomplishments. If the candidate is fresh out of university they can't point to work projects in industry because they don't have any. But they CAN point to stuff they've done on their own. That shows both motivation and the ability to finish something. Why do you object to it?
anticapitalist -> peter nelson , 21 Sep 2017 14:47
Thank you. The kids that spend high school researching independently and spend their nights hacking just for the love of it and getting a job without college are some of the most competent I've ever worked with. Passionless college grads that just want a paycheck are some of the worst.
John Kendall , 21 Sep 2017 19:42
There is a big difference between "coding" and programming. Coding for a smart phone app is a matter of calling functions that are built into the device. For example, there are functions for the GPS or for creating buttons or for simulating motion in a game. These are what we used to call subroutines. The difference is that whereas we had to write our own subroutines, now they are just preprogrammed functions. How those functions are written is of little or no importance to today's coders.

Nor are they able to program on that level. Real programming requires not only a knowledge of programming languages, but also a knowledge of the underlying algorithms that make up actual programs. I suspect that "coding" classes operate on a quite superficial level.

Game Cabbage -> theindyisbetter , 21 Sep 2017 19:40
Its not about the amount of work or the amount of labor. Its about the comparative availability of both and how that affects the balance of power, and that in turn affects the overall quality of life for the 'majority' of people.
c mm -> Ed209 , 21 Sep 2017 19:39
Most of this is not true. Peter Nelson gets it right by talking about breaking steps down and thinking rationally. The reason you can't just teach the theory, however, is that humans learn much better with feedback. Think about trying to learn how to build a fast car, but you never get in and test its speed. That would be silly. Programming languages take the system of logic that has been developed for centuries and gives instant feedback on the results. It's a language of rationality.
peter nelson -> peterainbow , 21 Sep 2017 19:37
This article is about the US. The tech industry in the EU is entirely different, and basically moribund. Where is the EU's Microsoft, Apple, Google, Amazon, Oracle, Intel, Facebook, etc, etc? The opportunities for exciting interesting work, plus the time and schedule pressures that force companies to overlook stuff like age because they need a particular skill Right Now, don't exist in the EU. I've done very well as a software engineer in my 60's in the US; I cannot imagine that would be the case in the EU.
peterainbow -> peter nelson , 21 Sep 2017 19:37
sorry but that's just not true, i doubt you are really programming still, or quasi programmer but really a manager who like to keep their hand in, you certainly aren't busy as you've been posting all over this cif. also why would you try and hire someone with such disparate skillsets, makes no sense at all

oh and you'd be correct that i do have workplace issues, ie i have a disability and i also suffer from depression, but that shouldn't bar me from employment and again regarding my skills going stale, that again contradicts your statement that it's about planning/analysis/algorithms etc that you said above ( which to some extent i agree with )

c mm -> peterainbow , 21 Sep 2017 19:36
Not at all, it's really egalitarian. If I want to hire someone to paint my portrait, the best way to know if they're any good is to see their previous work. If they've never painted a portrait before then I may want to go with the girl who has
c mm -> ragingbull , 21 Sep 2017 19:34
There is definitely not an excess. Just look at projected jobs for computer science on the Bureau of Labor statistics.
c mm -> perble conk , 21 Sep 2017 19:32
Right? It's ridiculous. "Hey, there's this industry you can train for that is super valuable to society and pays really well!"
Then Ben Tarnoff, "Don't do it! If you do you'll drive down wages for everyone else in the industry. Build your fire starting and rock breaking skills instead."
peterainbow -> peter nelson , 21 Sep 2017 19:29
how about how new labor tried to sign away IT access in England to India in exchange for banking access there, how about the huge loopholes in bringing in cheap IT workers from elsewhere in the world, not conspiracies, but facts
peter nelson -> eirsatz , 21 Sep 2017 19:25
I think the difference between gifted and not is motivation. But I agree it's not innate. The kid who stayed up all night in high school hacking into the school server to fake his coding class grade is probably more gifted than the one who spent 4 years in college getting a BS in CS because someone told him he could get a job when he got out.

I've done some hiring in my life and I always ask them to tell me about stuff they did on their own.

peter nelson -> TheBananaBender , 21 Sep 2017 19:20

Most coding jobs are bug fixing.

The only bugs I have to fix are the ones I make.

peter nelson -> Ed209 , 21 Sep 2017 19:19
As several people have pointed out, writing a computer program requires analyzing and breaking down a task into steps, identifying interdependencies, prioritizing the order, figuring out what parts can be organized into separate tasks that be done separately, etc.

These are completely independent of the language - I've been programming for 40 years in everything from FORTRAN to APL to C to C# to Java and it's all the same. Not only that but they transcend programming - they apply to planning a vacation, remodeling a house, or fixing a car.

peter nelson -> ragingbull , 21 Sep 2017 19:14
Neither coding nor having a bachelor's degree in computer science makes you a suitable job candidate. I've done a lot of recruiting and interviews in my life, and right now I'm trying to hire someone. And I've never recommended hiring anyone right out of school who could not point me to a project they did on their own, i.e., not just grades and test scores. I'd like to see an IOS or Android app, or a open-source component, or utility or program of theirs on GitHub, or something like that.

That's the thing that distinguishes software from many other fields - you can do something real and significant on your own. If you haven't managed to do so in 4 years of college you're not a good candidate.

peter nelson -> nickGregor , 21 Sep 2017 19:07
Within the next year coding will be old news and you will simply be able to describe things in ur native language in such a way that the machine will be able to execute any set of instructions you give it.

In a sense that's already true, as i noted elsewhere. 90% of the code in my projects (Java and C# in their respective IDEs) is machine generated. I do relatively little "coding". But the flaw in your idea is this: most of what software designers do is not coding. It requires domain knowledge and that's where the "smart" IDEs and AI coding wizards fall down. It will be a long time before we get where you describe.

Ricardo111 -> martinusher , 21 Sep 2017 19:03
Completely agree. At the highest levels there is more work that goes into managing complexity and making sure nothing is missed than in making the wheels turn and the beepers beep.
ragingbull , 21 Sep 2017 19:02
Hang on... if the current excess of computer science grads is not driving down wages, why would training more kids to code make any difference?
Ricardo111 -> youngsteveo , 21 Sep 2017 18:59
I've actually interviewed people for very senior technical positions in Investment Banks who had all the fancy talk in the world and yet failed at some very basic "write me a piece of code that does X" tests.

Next hurdle on is people who have learned how to deal with certain situations and yet don't really understand how it works so are unable to figure it out if you change the problem parameters.

That said, the average coder is only slightly beyond this point. The ones who can take in account maintenability and flexibility for future enhancements when developing are already a minority, and those who can understand the why of software development process steps, design software system architectures or do a proper Technical Analysis are very rare.

eirsatz -> Ricardo111 , 21 Sep 2017 18:57
Hubris. It's easy to mistake efficiency born of experience as innate talent. The difference between a 'gifted coder' and a 'non gifted junior coder' is much more likely to be 10 or 15 years sitting at a computer, less if there are good managers and mentors involved.
Ed209 , 21 Sep 2017 18:57
Politicians love the idea of teaching children to 'code', because it sounds so modern, and nobody could possible object... could they? Unfortunately it simply shows up their utter ignorance of technical matters because there isn't a language called 'coding'. Computer programming languages have changed enormously over the years, and continue to evolve. If you learn the wrong language you'll be about as welcome in the IT industry as a lamp-lighter or a comptometer operator.

The pace of change in technology can render skills and qualifications obsolete in a matter of a few years, and only the very best IT employers will bother to retrain their staff - it's much cheaper to dump them. (Most IT posts are outsourced through agencies anyway - those that haven't been off-shored. )

peter nelson -> YEverKnot , 21 Sep 2017 18:54
And this isn't even a good conspiracy theory; it's a bad one. He offers no evidence that there's an actual plan or conspiracy to do this. I'm looking for an account of where the advocates of coding education met to plot this in some castle in Europe or maybe a secret document like "The Protocols of the Elders of Google", or some such.
TheBananaBender , 21 Sep 2017 18:52
Most jobs in IT are shit - desktop support, operations droids. Most coding jobs are bug fixing.
Ricardo111 -> Wiretrip , 21 Sep 2017 18:49
Tool Users Vs Tool Makers. The really good coders actually get why certain things work as they do and can adjust them for different conditions. The mass produced coders are basically code copiers and code gluing specialists.
peter nelson -> AmyInNH , 21 Sep 2017 18:49
People who get Masters and PhD's in computer science are not usually "coders" or software engineers - they're usually involved in obscure, esoteric research for which there really is very little demand. So it doesn't surprise me that they're unemployed. But if someone has a Bachelor's in CS and they're unemployed I would have to wonder what they spent their time at university doing.

The thing about software that distinguishes it from lots of other fields is that you can make something real and significant on your own . I would expect any recent CS major I hire to be able to show me an app or an open-source component or something similar that they made themselves, and not just test scores and grades. If they could not then I wouldn't even think about hiring them.

Ricardo111 , 21 Sep 2017 18:44
Fortunately for those of us who are actually good at coding, the difference in productivity between a gifted coder and a non-gifted junior developer is something like 100-fold. Knowing how to code and actually being efficient at creating software programs and systems are about as far apart as knowing how to write and actually being able to write a bestselling exciting Crime trilogy.
peter nelson -> jamesupton , 21 Sep 2017 18:36

The rest of us will still have to stick to burning buildings down and stringing up the aristocracy.

If you know how to write software you can get a robot to do those things.

peter nelson -> Julian Williams , 21 Sep 2017 18:34
I do think there is excess supply of software programmers. There is only a modest number of decent jobs, say as an algorithms developer in finance, general architecture of complex systems or to some extent in systems security.

This article is about coding; most of those jobs require very little of that.

Most very high paying jobs in the technology sector are in the same standard upper management roles as in every other industry.

How do you define "high paying". Everyone I know (and I know a lot because I've been a sw engineer for 40 years) who is working fulltime as a software engineer is making a high-middle-class salary, and can easily afford a home, travel on holiday, investments, etc.

YEverKnot , 21 Sep 2017 18:32

Tech's push to teach coding isn't about kids' success – it's about cutting wages

Nowt like a good conspiracy theory.
freeandfair -> WithoutPurpose , 21 Sep 2017 18:31
What is a stupidly low salary? 100K?
freeandfair -> AmyInNH , 21 Sep 2017 18:30
> Already there. I take it you skipped right past the employment prospects for US STEM grads - 50% chance of finding STEM work.

That just means 50% of them are no good and need to develop their skills further or try something else.
Not every with a STEM degree from some 3rd rate college is capable of doing complex IT or STEM work.

peter nelson -> edmundberk , 21 Sep 2017 18:30

So, is teaching people English or arithmetic all about reducing wages for the literate and numerate?

Yes. Haven't you noticed how wage growth has flattened? That's because some do-gooders" thought it would be a fine idea to educate the peasants. There was a time when only the well-to do knew how to read and write, and that's why they well-to-do were well-to-do. Education is evil. Stop educating people and then those of us who know how to read and write can charge them for reading and writing letters and email. Better yet, we can have Chinese and Indians do it for us and we just charge a transaction fee.

AmyInNH -> peter nelson , 21 Sep 2017 18:27
Massive amounts of public use cars, it doesn't mean millions need schooling in auto mechanics. Same for software coding. We aren't even using those who have Bachelors, Masters and PhDs in CS.
carlospapafritas , 21 Sep 2017 18:27
"..importing large numbers of skilled guest workers from other countries through the H1-B visa program..."

"skilled" is good. H1B has long ( appx 17 years) been abused and turned into trafficking scheme. One can buy H1B in India. Powerful ethnic networks wheeling & dealing in US & EU selling IT jobs to essentially migrants.

The real IT wages haven't been stagnant but steadily falling from the 90s. It's easy to see why. $82K/year IT wage was about average in the 90s. Comparing the prices of housing (& pretty much everything else) between now gives you the idea.

freeandfair -> whitehawk66 , 21 Sep 2017 18:27
> not every kid wants or needs to have their soul sucked out of them sitting in front of a screen full of code for some idiotic service that some other douchbro thinks is the next iteration of sliced bread

Taking a couple of years of programming are not enough to do this as a job, don't worry.
But learning to code is like learning maths, - it helps to develop logical thinking, which will benefit you in every area of your life.

James Dey , 21 Sep 2017 18:25
We should stop teaching our kids to be journalists, then your wage might go up.
peter nelson -> AmyInNH , 21 Sep 2017 18:23
What does this even mean?

[Oct 02, 2017] Programming is a culturally important skill

Notable quotes:
"... A lot of basic entry level jobs require a good level of Excel skills. ..."
"... Programming is a cultural skill; master it, or even understand it on a simple level, and you understand how the 21st century works, on the machinery level. To bereave the children of this crucial insight is to close off a door to their future. ..."
"... What a dumpster argument. I am not a programmer or even close, but a basic understanding of coding has been important to my professional life. Coding isn't just about writing software. Understanding how algorithms work, even simple ones, is a general skill on par with algebra. ..."
"... Never mind that a good education is clearly one of the most important things you can do for a person to improve their quality of life wherever they live in the world. It's "neoliberal," so we better hate it. ..."
"... We've seen this kind of tactic for some time now. Silicon Valley is turning into a series of micromanaged sweatshops (that's what "agile" is truly all about) with little room for genuine creativity, or even understanding of what that actually means. I've seen how impossible it is to explain to upper level management how crappy cheap developers actually diminish productivity and value. All they see is that the requisition is filled for less money. ..."
"... Libertarianism posits that everyone should be free to sell their labour or negotiate their own arrangements without the state interfering. So if cheaper foreign labour really was undercutting American labout the Libertarians would be thrilled. ..."
"... Not producing enough to fill vacancies or not producing enough to keep wages at Google's preferred rate? Seeing as research shows there is no lack of qualified developers, the latter option seems more likely. ..."
"... We're already using Asia as a source of cheap labor for the tech industry. Why do we need to create cheap labor in the US? ..."
www.moonofalabama.org
David McCaul -> IanMcLzzz , 21 Sep 2017 13:03
There are very few professional Scribes nowadays, a good level of reading & writing is simplely a default even for the lowest paid jobs. A lot of basic entry level jobs require a good level of Excel skills. Several years from now basic coding will be necessary to manipulate basic tools for entry level jobs, especially as increasingly a lot of real code will be generated by expert systems supervised by a tiny number of supervisors. Coding jobs will go the same way that trucking jobs will go when driverless vehicles are perfected.

anticapitalist, 21 Sep 2017 14:25

Offer the class but not mandatory. Just like I could never succeed playing football others will not succeed at coding. The last thing the industry needs is more bad developers showing up for a paycheck.

Fanastril , 21 Sep 2017 14:08

Programming is a cultural skill; master it, or even understand it on a simple level, and you understand how the 21st century works, on the machinery level. To bereave the children of this crucial insight is to close off a door to their future. What's next, keep them off Math, because, you know . .
Taylor Dotson -> freeandfair , 21 Sep 2017 13:59
That's some crystal ball you have there. English teachers will need to know how to code? Same with plumbers? Same with janitors, CEOs, and anyone working in the service industry?
PolydentateBrigand , 21 Sep 2017 12:59
The economy isn't a zero-sum game. Developing a more skilled workforce that can create more value will lead to economic growth and improvement in the general standard of living. Talented coders will start new tech businesses and create more jobs.

WumpieJr , 21 Sep 2017 13:23

What a dumpster argument. I am not a programmer or even close, but a basic understanding of coding has been important to my professional life. Coding isn't just about writing software. Understanding how algorithms work, even simple ones, is a general skill on par with algebra.

But is isn't just about coding for Tarnoff. He seems to hold education in contempt generally. "The far-fetched premise of neoliberal school reform is that education can mend our disintegrating social fabric." If they can't literally fix everything let's just get rid of them, right?

Never mind that a good education is clearly one of the most important things you can do for a person to improve their quality of life wherever they live in the world. It's "neoliberal," so we better hate it.

mlzarathustra , 21 Sep 2017 16:52
I agree with the basic point. We've seen this kind of tactic for some time now. Silicon Valley is turning into a series of micromanaged sweatshops (that's what "agile" is truly all about) with little room for genuine creativity, or even understanding of what that actually means. I've seen how impossible it is to explain to upper level management how crappy cheap developers actually diminish productivity and value. All they see is that the requisition is filled for less money.

The bigger problem is that nobody cares about the arts, and as expensive as education is, nobody wants to carry around a debt on a skill that won't bring in the bucks. And smartphone-obsessed millennials have too short an attention span to fathom how empty their lives are, devoid of the aesthetic depth as they are.

I can't draw a definite link, but I think algorithm fails, which are based on fanatical reliance on programmed routines as the solution to everything, are rooted in the shortage of education and cultivation in the arts.

Economics is a social science, and all this is merely a reflection of shared cultural values. The problem is, people think it's math (it's not) and therefore set in stone.

AmyInNH -> peter nelson , 21 Sep 2017 16:51
Geeze it'd be nice if you'd make an effort.
rucore.libraries.rutgers.edu/rutgers-lib/45960/PDF/1/
https://rucore.libraries.rutgers.edu/rutgers-lib/46156 /
https://rucore.libraries.rutgers.edu/rutgers-lib/46207 /
peter nelson -> WyntonK , 21 Sep 2017 16:45
Libertarianism posits that everyone should be free to sell their labour or negotiate their own arrangements without the state interfering. So if cheaper foreign labour really was undercutting American labout the Libertarians would be thrilled.

But it's not. I'm in my 60's and retiring but I've been a software engineer all my life. I've worked for many different companies, and in different industries and I've never had any trouble competing with cheap imported workers. The people I've seen fall behind were ones who did not keep their skills fresh. When I was laid off in 2009 in my mid-50's I made sure my mobile-app skills were bleeding edge (in those days ANYTHING having to do with mobile was bleeding edge) and I used to go to job interviews with mobile devices to showcase what I could do. That way they could see for themselves and not have to rely on just a CV.

They older guys who fell behind did so because their skills and toolsets had become obsolete.

Now I'm trying to hire a replacement to write Android code for use in industrial production and struggling to find someone with enough experience. So where is this oversupply I keep hearing about?

Jared Hall -> RogTheDodge , 21 Sep 2017 16:42
Not producing enough to fill vacancies or not producing enough to keep wages at Google's preferred rate? Seeing as research shows there is no lack of qualified developers, the latter option seems more likely.
JayThomas , 21 Sep 2017 16:39

It's about ensuring those salaries no longer exist, by creating a source of cheap labor for the tech industry.

We're already using Asia as a source of cheap labor for the tech industry. Why do we need to create cheap labor in the US? That just seems inefficient.

FabBlondie -> RogTheDodge , 21 Sep 2017 16:39
There was never any need to give our jobs to foreigners. That is, if you are comparing the production of domestic vs. foreign workers. The sole need was, and is, to increase profits.
peter nelson -> AmyInNH , 21 Sep 2017 16:34
Link?
FabBlondie , 21 Sep 2017 16:34
Schools MAY be able to fix big social problems, but only if they teach a well-rounded curriculum that includes classical history and the humanities. Job-specific training is completely different. What a joke to persuade public school districts to pick up the tab on job training. The existing social problems were not caused by a lack of programmers, and cannot be solved by Big Tech.

I agree with the author that computer programming skills are not that limited in availability. Big Tech solved the problem of the well-paid professional some years ago by letting them go, these were mostly workers in their 50s, and replacing them with H1-B visa-holders from India -- who work for a fraction of their experienced American counterparts.

It is all about profits. Big Tech is no different than any other "industry."

peter nelson -> Jared Hall , 21 Sep 2017 16:31
Supply of apples does not affect the demand for oranges. Teaching coding in high school does not necessarily alter the supply of software engineers. I studied Chinese History and geology at University but my doing so has had no effect on the job prospects of people doing those things for a living.
johnontheleft -> Taylor Dotson , 21 Sep 2017 16:30
You would be surprised just how much a little coding knowledge has transformed my ability to do my job (a job that is not directly related to IT at all).
peter nelson -> Jared Hall , 21 Sep 2017 16:29
Because teaching coding does not affect the supply of actual engineers. I've been a professional software engineer for 40 years and coding is only a small fraction of what I do.
peter nelson -> Jared Hall , 21 Sep 2017 16:28
You and the linked article don't know what you're talking about. A CS degree does not equate to a productive engineer.

A few years ago I was on the recruiting and interviewing committee to try to hire some software engineers for a scientific instrument my company was making. The entire team had about 60 people (hw, sw, mech engineers) but we needed 2 or 3 sw engineers with math and signal-processing expertise. The project was held up for SIX months because we could not find the people we needed. It would have taken a lot longer than that to train someone up to our needs. Eventually we brought in some Chinese engineers which cost us MORE than what we would have paid for an American engineer when you factor in the agency and visa paperwork.

Modern software engineers are not just generic interchangable parts - 21st century technology often requires specialised scientific, mathematical, production or business domain-specific knowledge and those people are hard to find.

freeluna -> freeluna , 21 Sep 2017 16:18
...also, this article is alarmist and I disagree with it. Dear Author, Phphphphtttt! Sincerely, freeluna
AmyInNH , 21 Sep 2017 16:16
Regimentation of the many, for benefit of the few.
AmyInNH -> Whatitsaysonthetin , 21 Sep 2017 16:15
Visa jobs are part of trade agreements. To be very specific, US gov (and EU) trade Western jobs for market access in the East.
http://www.marketwatch.com/story/in-india-british-leader-theresa-may-preaches-free-trade-2016-11-07
There is no shortage. This is selling off the West's middle class.
Take a look at remittances in wikipedia and you'll get a good idea just how much it costs the US and EU economies, for sake of record profits to Western industry.
jigen , 21 Sep 2017 16:13
And thanks to the author for not using the adjective "elegant" in describing coding.
freeluna , 21 Sep 2017 16:13
I see advantages in teaching kids to code, and for kids to make arduino and other CPU powered things. I don't see a lot of interest in science and tech coming from kids in school. There are too many distractions from social media and game platforms, and not much interest in developing tools for future tech and science.
jigen , 21 Sep 2017 16:13
Let the robots do the coding. Sorted.
FluffyDog -> rgilyead , 21 Sep 2017 16:13
Although coding per se is a technical skill it isn't designing or integrating systems. It is only a small, although essential, part of the whole software engineering process. Learning to code just gets you up the first steps of a high ladder that you need to climb a fair way if you intend to use your skills to earn a decent living.
rebel7 , 21 Sep 2017 16:11
BS.

Friend of mine in the SV tech industry reports that they are about 100,000 programmers short in just the internet security field.

Y'all are trying to create a problem where there isn't one. Maybe we shouldn't teach them how to read either. They might want to work somewhere besides the grill at McDonalds.

AmyInNH -> WyntonK , 21 Sep 2017 16:11
To which they will respond, offshore.
AmyInNH -> MrFumoFumo , 21 Sep 2017 16:10
They're not looking for good, they're looking for cheap + visa indentured. Non-citizens.
nickGregor , 21 Sep 2017 16:09
Within the next year coding will be old news and you will simply be able to describe things in ur native language in such a way that the machine will be able to execute any set of instructions you give it. Coding is going to change from its purely abstract form that is not utilized at peak- but if you can describe what you envision in an effective concise manner u could become a very good coder very quickly -- and competence will be determined entirely by imagination and the barriers of entry will all but be extinct
AmyInNH -> unclestinky , 21 Sep 2017 16:09
Already there. I take it you skipped right past the employment prospects for US STEM grads - 50% chance of finding STEM work.
AmyInNH -> User10006 , 21 Sep 2017 16:06
Apparently a whole lot of people are just making it up, eh?
http://www.motherjones.com/politics/2017/09/inside-the-growing-guest-worker-program-trapping-indian-students-in-virtual-servitude /
From today,
http://www.computerworld.com/article/2915904/it-outsourcing/fury-rises-at-disney-over-use-of-foreign-workers.html
All the way back to 1995,
https://www.youtube.com/watch?v=vW8r3LoI8M4&feature=youtu.be
JCA1507 -> whitehawk66 , 21 Sep 2017 16:04
Bravo
JCA1507 -> DirDigIns , 21 Sep 2017 16:01
Total... utter... no other way... huge... will only get worse... everyone... (not a very nuanced commentary is it).

I'm glad pieces like this are mounting, it is relevant that we counter the mix of messianism and opportunism of Silicon Valley propaganda with convincing arguments.

RogTheDodge -> WithoutPurpose , 21 Sep 2017 16:01
That's not my experience.
AmyInNH -> TTauriStellarbody , 21 Sep 2017 16:01
It's a stall tactic by Silicon Valley, "See, we're trying to resolve the [non-existant] shortage."
AmyInNH -> WyntonK , 21 Sep 2017 16:00
They aren't immigrants. They're visa indentured foreign workers. Why does that matter? It's part of the cheap+indentured hiring criteria. If it were only cheap, they'd be lowballing offers to citizen and US new grads.
RogTheDodge -> Jared Hall , 21 Sep 2017 15:59
No. Because they're the ones wanting them and realizing the US education system is not producing enough
RogTheDodge -> Jared Hall , 21 Sep 2017 15:58
Except the demand is increasing massively.
RogTheDodge -> WyntonK , 21 Sep 2017 15:57
That's why we are trying to educate American coders - so we don't need to give our jobs to foreigners.
AmyInNH , 21 Sep 2017 15:56
Correct premises,
- proletarianize programmers
- many qualified graduates simply can't find jobs.
Invalid conclusion:
- The problem is there aren't enough good jobs to be trained for.

That conclusion only makes sense if you skip right past ...
" importing large numbers of skilled guest workers from other countries through the H1-B visa program. These workers earn less than their American counterparts, and possess little bargaining power because they must remain employed to keep their status"

Hiring Americans doesn't "hurt" their record profits. It's incessant greed and collusion with our corrupt congress.

Oldvinyl , 21 Sep 2017 15:51
This column was really annoying. I taught my students how to program when I was given a free hand to create the computer studies curriculum for a new school I joined. (Not in the UK thank Dog). 7th graders began with studying the history and uses of computers and communications tech. My 8th grade learned about computer logic (AND, OR, NOT, etc) and moved on with QuickBASIC in the second part of the year. My 9th graders learned about databases and SQL and how to use HTML to make their own Web sites. Last year I received a phone call from the father of one student thanking me for creating the course, his son had just received a job offer and now works in San Francisco for Google.
I am so glad I taught them "coding" (UGH) as the writer puts it, rather than arty-farty subjects not worth a damn in the jobs market.
WyntonK -> DirDigIns , 21 Sep 2017 15:47
I live and work in Silicon Valley and you have no idea what you are talking about. There's no shortage of coders at all. Terrific coders are let go because of their age and the availability of much cheaper foreign coders(no, I am not opposed to immigration).
Sean May , 21 Sep 2017 15:43
Looks like you pissed off a ton of people who can't write code and are none to happy with you pointing out the reason they're slinging insurance for geico.

I think you're quite right that coding skills will eventually enter the mainstream and slowly bring down the cost of hiring programmers.

The fact is that even if you don't get paid to be a programmer you can absolutely benefit from having some coding skills.

There may however be some kind of major coding revolution with the advent of quantum computing. The way code is written now could become obsolete.

Jared Hall -> User10006 , 21 Sep 2017 15:43
Why is it a fantasy? Does supply and demand not apply to IT labor pools?
Jared Hall -> ninianpark , 21 Sep 2017 15:42
Why is it a load of crap? If you increase the supply of something with no corresponding increase in demand, the price will decrease.
pictonic , 21 Sep 2017 15:40
A well-argued article that hits the nail on the head. Amongst any group of coders, very few are truly productive, and they are self starters; training is really needed to do the admin.
Jared Hall -> DirDigIns , 21 Sep 2017 15:39
There is not a huge skills shortage. That is why the author linked this EPI report analyzing the data to prove exactly that. This may not be what people want to believe, but it is certainly what the numbers indicate. There is no skills gap.

http://www.epi.org/files/2013/bp359-guestworkers-high-skill-labor-market-analysis.pdf

Axel Seaton -> Jaberwocky , 21 Sep 2017 15:34
Yeah, but the money is crap
DirDigIns -> IanMcLzzz , 21 Sep 2017 15:32
Perfect response for the absolute crap that the article is pushing.
DirDigIns , 21 Sep 2017 15:30
Total and utter crap, no other way to put it.

There is a huge skills shortage in key tech areas that will only get worse if we don't educate and train the young effectively.

Everyone wants youth to have good skills for the knowledge economy and the ability to earn a good salary and build up life chances for UK youth.

So we get this verbal diarrhoea of an article. Defies belief.

Whatitsaysonthetin -> Evelita , 21 Sep 2017 15:27
Yes. China and India are indeed training youth in coding skills. In order that they take jobs in the USA and UK! It's been going on for 20 years and has resulted in many experienced IT staff struggling to get work at all and, even if they can, to suffer stagnating wages.
WmBoot , 21 Sep 2017 15:23
Wow. Congratulations to the author for provoking such a torrent of vitriol! Job well done.
TTauriStellarbody , 21 Sep 2017 15:22
Has anyones job is at risk from a 16 year old who can cobble together a couple of lines of javascript since the dot com bubble?

Good luck trying to teach a big enough pool of US school kids regular expressions let alone the kind of test driven continuous delivery that is the norm in the industry now.

freeandfair -> youngsteveo , 21 Sep 2017 13:27
> A lot of resumes come across my desk that look qualified on paper, but that's not the same thing as being able to do the job

I have exactly the same experience. There is undeniable a skill gap. It takes about a year for a skilled professional to adjust and learn enough to become productive, it takes about 3-5 years for a college grad.

It is nothing new. But the issue is, as the college grad gets trained, another company steal him/ her. And also keep in mind, all this time you are doing job and training the new employee as time permits. Many companies in the US cut the non-profit department (such as IT) to the bone, we cannot afford to lose a person and then train another replacement for 3-5 years.

The solution? Hire a skilled person. But that means nobody is training college grads and in 10-20 years we are looking at the skill shortage to the point where the only option is brining foreign labor.

American cut-throat companies that care only about the bottom line cannibalized themselves.

farabundovive -> Ethan Hawkins , 21 Sep 2017 15:10

Heh. You are not a coder, I take it. :) Going to be a few decades before even the easiest coding jobs vanish.

Given how shit most coders of my acquaintance have been - especially in matters of work ethic, logic, matching s/w to user requirements and willingness to test and correct their gormless output - most future coding work will probably be in the area of disaster recovery. Sorry, since the poor snowflakes can't face the sad facts, we have to call it "business continuation" these days, don't we?
UncommonTruthiness , 21 Sep 2017 14:10
The demonization of Silicon Valley is clearly the next place to put all blame. Look what "they" did to us: computers, smart phones, HD television, world-wide internet, on and on. Get a rope!

I moved there in 1978 and watched the orchards and trailer parks on North 1st St. of San Jose transform into a concrete jungle. There used to be quite a bit of semiconductor equipment and device manufacturing in SV during the 80s and 90s. Now quite a few buildings have the same name : AVAILABLE. Most equipment and device manufacturing has moved to Asia.

Programming started with binary, then machine code (hexadecimal or octal) and moved to assembler as a compiled and linked structure. More compiled languages like FORTRAN, BASIC, PL-1, COBOL, PASCAL, C (and all its "+'s") followed making programming easier for the less talented. Now the script based languages (HTML, JAVA, etc.) are even higher level and accessible to nearly all. Programming has become a commodity and will be priced like milk, wheat, corn, non-unionized workers and the like. The ship has sailed on this activity as a career.

16 ways to torture developers

Having great developers means creating a great environment. In an increasingly competitive world, that means everything from free food to paid screw-off time. But not everyone has gotten the message.

Some places still practice developer abuse. Here are its many forms. Do not indulge in more than one or two, or you may never see your best developers again.

[ 10 steps to becoming the developer everyone wants [1] | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide [2]. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter [3]. ]

1. Hellish security
I've been to a place whose McAfee proxy bans Zip files with HelloWorld.java. This means that everything from downloading build tools to examples is prohibited. At another shop, the McAfee desfktop security scans every file a process touches for malicious code, even files unchanged since the last time it checked them in a single-threaded fashion, which means putting the entire contents of thousands of files through one core of the CPU for every operation. It took 30 minutes to launch the IDE and up to another 10 minutes to launch a build, even if the build touched only three source files and ran for a few seconds.

2. Torture tools
There is Subversion, and there is Git [4]. Frankly, all other version control/configuration management tools are way too slow and/or painful. ClearCase is the mother of all developer torture tools. One ... day ... the ... code ... will ... check ... out ...

3. Maintenance teams
Some places still have fixed teams, which get all the sucky work. Seriously, no one will stay on the "maintenance team" once they find a better job -- and the odds are on their side.

4. Forced Windows
Forcing your developers to use Windows as a development environment if they aren't writing .Net code is pretty sadistic. Forced Windows means feeding your developers the same crap nontechnical users are forced to run, with many of the same restrictions. (I realize that someone on my team will say I forced them to use Linux. That's really too bad.)

5. Locking out all libraries
Years ago, when I worked at IBM, I was told not to use third-party libraries -- open source or not -- unless it would save me at least two months of development time because the hour or two of lawyer time necessary to vet everything would cost more than two months of my time. I upped my hourly billing rate soon after. Sure, you need a policy stipulating where and how you will consume libraries without going through a formal vetting process, but even so, "optimistic locking" is usually fine. Otherwise you're committing a heinous act of developer abuse by forcing everyone to reinvent the wheel.

6. WebSphere
Look, I can live with DB2 now that IBM finally added READ_COMMITTED. But WebSphere is too painful. Don't make me boot WebSphere or go through the 50 GUI screens necessary to deploy a WAR file. Seriously, WebSphere is developer abuse pure and simple. It is bad. It has always been bad. If you take nothing else away from this, uninstall WebSphere. Otherwise, your developers will hate on you behind your back. If they don't, you need better developers.

7. Marching unto death
If you force your developers into a constant death march, you burn them out. Also, they feel like they've put everything together with paperclips and duct tape. A maintenance sprint is not the answer because no one wants to clean up a big mess for weeks on end. Instead, give your developers slightly less time than they want. Anything more will produce cost overruns, and anything less is developer abuse.

8. Ah, 2010 was a good year
So you really like "standardizing" on old stuff -- say, a three- to four-year-old version of an IDE running on a version of the operating system (probably Windows) it wasn't ever tested on. In a competitive labor market, you can bet someone will offer them full benefits and the chance to use a newer version.

9. I'm sorry, we only do boring
I sympathize that you hate HipsterHacker [5] architecture. You don't want a system that was developed entirely in "oh look shiny let me download that too." On the other hand, making your developers write code in the same set of stuff with nothing new under the sun makes them think about their career. Mix it up, let your developers touch new stuff, and mitigate the risk into a stable architecture.

10. The VM of the eternal hourglass
Your company is totally virtual! Even the development environments are virtual! Cool beans, man! Oh, but you underfunded the hardware or didn't tune it right, so everything is slow, horrible torture. Some people are Zen and don't mind a two-hour-long build process. I am not one of those people.

11. The faux-scrum daily standup meeting
There's a special level of hell reserved for the worst sinners. It's known as the daily scrum meeting for management status updates, where everyone feels compelled to talk for at least five to six minutes, not to convey important developments, but to communicate to management that they're busy doing stuff and should stay employed. The meetings inevitably have 12 or more people in them, the vast majority of whom don't need to be present. They run for 30 to 45 minutes or more (a real scrum should take about five to six minutes), and everyone not speaking spaces out. Worse, no one does any work before these meetings because they know the context switch is coming. After the meeting, well, lunch is in another hour anyway, so why start anything hard now? Basically these meetings cost your team their entire morning, poison morale, and accomplish nothing. Learn to do agile right or cancel the meeting.

12. Formalism
Formalism is more than wearing a suit and can show up in unexpected ways. Ironically, casual environments are more difficult because establishing the line is harder, but developers have fought long and hard against formal environments. When I worked for JBoss, three directors of development in a row told me I shouldn't wear a dress shirt-and-slacks combo, and they would pay for me to buy decent clothes at Target. They were dead serious. The concern was that if JBoss (a perceived sandal brigade) showed up in a suit, management would eventually force the developers back into the penguin costume. The casual environment was, in fact, a synthetic construct. I tried setting the bar recently when hiring an HR manager who immediately asked, "Does this mean we can't say [the F word] anymore?" I replied, "No, [the F word] is a holy word, and we will utter it at any time, any place, and for any or no reason whatsoever ... unless customers are around."

There is a divide between the button-down environments and the no-button environments that crosses in to how people talk (such as dongle jokes [6]) and how people think ("makes the most technical sense" versus "isn't in my territory"). Some of this is due to larger environments requiring more rules; other times, people love ceremony and excessive "formalism" in procedure, speech, dress, and more. Forcing developers to do everything inside the box for the sake of formality is the abuse of the mind and spirit.

13. Management by hostage crisis
Sometimes a load test will fail, and management may want to hear the root cause and a solution. They may even threaten to revert the changes, even if it breaks the implementation. This is a perfect path to knocking the development process off-track. Micromanaging and asserting authority from up high not only interrupts the normal iterative process of implementation and testing; it also makes developers afraid to try anything and attract unwanted attention. Threatening drastic and immediate destructive action to resolve problems without understanding the related functionality leads to a rushed product at best. Putting a project at the mercy of panicked customers or managers assures developers that the situation is out of their control, but they will be blamed for the outcome despite their warnings. Goals and deadlines guide work to completion. A thrashing whirlwind destroys it.

14. We ask the questions around here
Let's say someone finds a rogue machine trying to connect to Skype on a restricted port. The developer is unaware this violates the rules. But when asked about other guidelines, no details are provided. Congratulations -- you've just punished a developer for failing to adhere to vague, unannounced, or undocumented restrictions. Don't be surprised if this leaves them looking for the nearest exit.

15. Details, baby, details
Pointy-haired boss: "The customer asked for a tweak. Can you add that in time for release?"

Coder: "No. That would require a major architectural change. We asked before we started out, and we were told not to spend the time making that sort of expansion possible."

Though requirements are rarely set in stone at the outset, pressing developers to take the shortest path to them without accommodating for likely changes puts them in a tight spot when the demands come later.

16. Never mind how it works, just tell me how it works
Some managers demand immediate solutions to problems while simultaneously refusing to entertain hypothesizing about the causes and resisting efforts to investigate properly. It usually comes with verbal challenges to the effect of, "Aren't you an expert? Why can't you just explain or solve it?" To find a solution, you must investigate the causes, as well as hypothesize and test those hypotheses. No, we can't fast-forward to the end -- our problem-solving methodology will devolve into guess-and-check!

This article, "16 ways to torture developers [7]," was originally published at InfoWorld.com [8]. Keep up on the latest developments in application development [9] and read more of Andrew Oliver's Strategic Developer blog [10] at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter [11].

[Aug 25, 2010] 101 Ways To Know Your Software Project Is Doomed

  1. Management has renamed its Waterfall process to Agile Waterfall
  2. You start hiring consultants so they can take the blame
  3. The Continuous Integration server has returned the error message "Screw it, I give up"
  4. You have implemented your own Ruby framework that uses XML configuration files
  5. Your eldest team member references Martin Fowler as a 'snot-nosed punk'
  6. Your source code control system is a series of folders on a shared drive
  7. Allocated QA time is for Q and A why your crap is broken
  8. All of your requirements are written on a used cocktail napkin
  9. You start considering a new job so you don't have to maintain the application you are building
  10. The lead web developer thinks the X in XHTML means 'extreme'
  11. Ever iteration meeting starts with "Do you want the good news or the bad news…"
  12. Your team still gives a crap about its CMM Level
  13. Progress is now measured by the number of fixed bugs and not completed features
  14. Continuous Integration is getting new employees to read the employee handbook
  15. You are friends with the janitor
  16. The SCRUM master doesn't really care what you did yesterday or what you will do today
  17. Every milestone ends in a dead sprint
  18. Your best developer only has his A+ Certification
  19. You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR
  20. Your manager could be replaced by an email redirection batch file
  21. The only certification your software process has is ISO 9001/2000
  22. Your manager thinks 'Metrics' is a type of protein drink
  23. Every bug is prioritized as Critical
  24. Every feature is prioritized as Trivial
  25. Project estimates magically match the budget
  26. Developers use the excuse of 'self documenting code' for no comments
  27. Your favorite software pattern is God Object
  28. You still believe compiling is a form of testing
  29. Developers still use Notepad as an IDE
  30. Your manager wastes 7 hours a week asking for progress reports (true story)
  31. You do not have your own machine and you are not doing pair programming
  32. Team Rule – No meetings until 10 AM since we were all here until 2 AM
  33. Your team believes ORM is a 'fad'
  34. Your team believes the transition from VB6 to VB.NET will be 'seamless'
  35. Your manager thinks MS Project is the best management tool the market offers
  36. Your spouse only gets to see you on a webcam
  37. None of your unit tests have asserts in them
  38. FrontPage is your web page editor of choice
  39. You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC
  40. The company motto is 'Do more with less'
  41. The phrase 'It works on my machine' is heard more than once a day
  42. The last conference your .NET team attended was Apple WWDC 2000
  43. Your manager insists that you track all activity but never uses the information to make decisions
  44. All debugging occurs on the live server
  45. Your manager does not know how to check email
  46. Your manager thinks being SOX compliant means not working on baseball nights
  47. The company hires Senetor Ted Stevens to give your project kick-off inspiration speech
  48. The last book you read – Visual InterDev 6 Bible
  49. The overall budget is mistaken for your weekly Mountain Dew bill
  50. Your manager spends his lunch hour crying in his car (another true story)
  51. Your lead web developer defines AJAX as a cleaning product
  52. Your boss expects you to spend the next 2 days creating a purchase request for a $50 component
  53. The sales team decreased your estimates because they believe you can work faster
  54. Requirement – Rank #1 on Google
  55. Everyday you work until Midnight, everyday your boss leaves at 4:30
  56. Your manager loves to say "Why do the developers care? They get paid by the hour."
  57. The night shift at Starbucks knows you by name
  58. Management can not understand why anyone needs more than a single monitor
  59. Your development team only uses source control as a power failure backup system
  60. Developers are not responsible for any testing
  61. The team does not use SVN because they believe the merge algorithms are black voodoo magic
  62. Your white boards are mostly white (VersionOne)
  63. The client continually mistakes your burn-down chart for a burn-up chart
  64. The project code name is renamed to 'The Death March'
  65. Now it physically pains you to say the word – Yes
  66. Your teammates don't refactor, they refuctor
  67. To reward you for all of your overtime your boss purchases a new coffee maker
  68. Your project budget is entered in the company ledger as 'Corporate Overhead'
  69. You secretly outsource pieces of the project so you can blog at work
  70. A Change Control Board is created and your product isn't even its first alpha version
  71. Daily you consider breaking your fingers for the short term disability check
  72. The deadline has been renamed a 'milestone'…just like the last 'milestone'
  73. Your project managers 'open door' policy only applies between 5:01 PM – 7:59 AM
  74. Your boss argues "Why buy it when we can built it!"
  75. You bring beer to the office during your 2nd shift
  76. The project manager is spotted consulting a Ouija board
  77. You give misinformation to your teammates so you look better on your personal review
  78. All code reviews are scheduled a week before product launch
  79. Budget for testing exists as "if we have time"
  80. The client will only talk about the requirements after they receive a fixed estimation
  81. The boss does not find the humor in Dilbert
  82. You start noticing your boss's poker tells during planning poker
  83. You start wondering if working 2 shifts at Pizza Hut is a better career alternative
  84. All performance issues are resolved by getting larger machines
  85. The project has been demoted to being released as a permanent 'Beta' version
  86. Your car is towed from the office parking lot as it was thought to be abandoned
  87. The project manager likes to doodle during requirements gathering meetings
  88. You are using MOSS 2007
  89. Your SCRUM team consists of 1
  90. Your timesheet looks like a Powerball ticket
  91. The web developer thinks being 508 means looking good in her Levi Red Tabs
  92. You think you need Multiple Personality Disorder medication because you are Mort, Elvis, and Einstein
  93. Your manager substitutes professional consultant advice for a Magic 8 Ball
  94. You know exactly how many compile warnings cause an 'Out of Memory' exception in your IDE
  95. I have used IDE twice in this list and you still don't know what it stands for
  96. You have cut and pasted code from The Daily WTF
  97. Broken unit tests are deleted because they are obviously out of date
  98. You are sent to a conference to learn, but you skip sessions to go hunting for swag
  99. QA has nicknamed you Chief Off-By-One
  100. You have been 90% complete 90% of the time
  101. "Oh, oh, and I almost forgot. Ahh, I'm also gonna need you to go ahead and come in on Sunday, too… thanks"

[Aug 25, 2010] 21 Laws of Computer Programming

  1. Any given program, once deployed, is already obsolete.
  2. It is easier to change the specification to fit the program than vice versa.
  3. If a program is useful, it will have to be changed.
  4. If a program is useless, it will have to be documented.
  5. Only ten percent of the code in any given program will ever execute.
  6. Software expands to consume all available resources.
  7. Any non-trivial program contains at least one error.
  8. The probability of a flawless demo is inversely proportional to the number of people watching, raised to the power of the amount of money involved.
  9. Not until a program has been in production for at least six months will its most harmful error be discovered.
  10. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  11. The effort required to correct an error increases exponentially with time.
  12. Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
  13. Any code of your own that you haven't looked at in months might as well have been written by someone else.
  14. Inside every small program is a large program struggling to get out.
  15. The sooner you start coding a program, the longer it will take.
  16. A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
  17. Adding programmers to a late project makes it later.
  18. A program is never less than 90% complete, and never more than 95% complete.
  19. If you automate a mess, you get an automated mess.
  20. Build a program that even a fool can use, and only a fool will want to use it.
  21. Users truly don't know what they want in a program until they use it.
Jeffrey Nonken:

#6 is actually an extension of Parkinson's Law. http://en.wikipedia.org/wiki/Parkinson's_law

#17 is covered in the Mythical Man Month. The author is serious.

#13: I've learned to comment my code extensively. I pretend that in six months somebody will have to work on the code again, and that it might be me. If it isn't me, I'll have to stop whatever I AM working on to answer questions.

It's true often enough to continue to motivate me.

I've gotten high praise for the quality of my commenting.

#15 is just a corollary of #6.

#19 is covered in Code Complete 2, in a fashion. He urges you to get your code working RIGHT before worrying about getting it working FAST. If you optimize bad code you'll end up with fast, bad code, and you'll just end up throwing away all the effort along with the optimized code.

Sorry if I seem to be picking on this list, I'm really not. It's a pretty good list and funny. It's just that after 3 decades of programming I've learned most of these laws the hard way. :)

[Feb 12, 2008] Inter-Sections " Blog Archive " How to recognise a good programmer by Daniel Tenner

This is good post of the pretty fuzzy theme and as such it should be taken with a grain of salt as there is no universal criteria and also programming like love is a very fuzzy word. For example early start is a good indication of abilities but that does not mean that somebody who has early start in other discipline cannot switch to programming and reach the top. Ability to write is another, but it is not as universal as one might think... Game programming is not the same as RPG programming of financial applications. IMHO comments are more interesting the post... Also compare with Aesthetics and the human factor in programming by Andrey Erchov

How do you recognise good programmers if you're a business guy?

It's not as easy as it sounds. CV experience is only of limited use here, because great programmers don't always have the "official" experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great programmer.

I consider myself to be a pretty good programmer. At the same time, I've spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good programmers, and I want to share it in this article, in the hope that it may help other "business guys" to recognise good programmers. And, who knows, perhaps some programmers who have the potential to be good but haven't really exploited this can also read this and realise what they need to do to become good (although, as I'll argue, that's definitely not accessible to all programmers!).

In his article The 18 mistakes that kill startups, Paul Graham makes the following point:

"… what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That's actually much harder than it sounds-almost impossibly hard in fact-because business guys can't tell which are the good programmers. They don't even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't. Then they're mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you're not a programmer? I don't think there's an answer. I was about to say you'd have to find a good programmer to help you hire people. But if you can't recognize good programmers, how would you even do that?"

I disagree with Mr Graham on this one. I think there are a number of very strong indicators of a "good programmer" (and, conversely, strong indicators of a "not-so-good programmer") that even a business guy can recognise. I'll summarise some key indicators and counter-indicators in a list at the end of the article.

#1 : Passion

In my corporate experience, I met a kind of technical guy I'd never met before: the career programmer. This is a person who's doing IT because they think it's a good career. They don't do any programming in their spare time. They're shocked when they find out I have a LAN and 3 computers at home. They just do it at work. They don't learn new stuff unless sent on a training program (or motivated by the need to get a job that requires that technology). They do "programming" as a day job. They don't really want to talk about it outside of work. When they do, they talk with a distinctive lack of enthusiasm. Basically, they lack passion.

  • Gordon
    January 11th, 2008 at 10:07 pm

    I think the passion indicator is entirely overrated. I see cases all the time, especially in college, where a person's passion exceeds their abilities. They are the same people who spend day and night in the computer labs and even know a plethora of cutting-edge technologies, but are ultimately mid-tier students who are passed up by truly good programmers.

    With that said, raw intelligence is the best indicator. That's why puzzle questions are not entirely bad. They generate less false-positive, which is the worst-case for a new hire, and are harder to fake. All of the qualities you listed above can be faked easily. They are also universal in the sense that the business-minded variety are capable of asking them.

I believe that good developers are always passionate about programming. Good developers would do some programming even if they weren't being paid for it. Good programmers will have a tendency to talk your ear off about some technical detail of what they're working on (but while clearly believing, sincerely, that what they're talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they're doing at the expense of social smoothness is a very strong indicator. Can you get this guy to excitedly chat up a technology that he's using, for a whole half hour, without losing steam? Then you might be onto a winner.

#2 : Self-teaching and love of learning

Programming is the ultimate moving target. Not a year goes by without some new technology robbing an old, established standard blind and changing half the development universe. This is not to say that all good programmers pick up these changes and ride the bleeding edge. However, there's a class of programmers that will never, ever pick up a new technology unless forced to, because they don't like learning new stuff. These programmers will typically have learnt programming at university, and expect to get by on whatever skills they picked up there, plus whatever courses their company is willing to send them on.

If you're thinking of hiring someone as a programmer, and he ever utters the words "I can work with that, just send me on a training course for a week and I'll be good at it", don't hire that guy. A good programmer doesn't need a training course to learn a new technology. In fact, the great programmer will be the one talking your ear off about a new technology that you haven't even heard of, explaining to you why you must use it in your business, even if none of your staff knows how to use it. Even if it's a technology he doesn't know how to use yet.

#3 : Intelligence

Some business people assume that lack of social tact and lack of intelligence are the same. Actually, intelligence has several facets, and emotional/social intelligence is only one of them. Good programmers aren't dumb. Ever. In fact, good programmers are usually amongst the smartest people you know. Many of them will actually have pretty good social skills too. The cliché of the programmer who's incapable of having a conversation is just that - a cliché. I've been to a few meetings of the London Ruby User Group and I can say that with only a very few exceptions, most people there are smart, talkative, sociable, have varied interests, etc. You wouldn't look at them chattering away in the pub and think "what a bunch of geeks!" - at least until you approach a group and realise they're talking about the best way to design a RESTful application with a heavy UI frontend.

This doesn't mean that they'll all feel comfortable in every social context. But it does mean that if the context is comfortable and non-threatening enough, you'll be able to have as great a conversation with them as you would with the most "socially enabled" people (perhaps better, since most good programmers I know like their conversation to revolve around actually useful topics, rather than just inane banter).

Don't ever hire a dumb person thinking they're a good developer. They're not. If you can't have a great conversation with them in a relaxed social context, they're very likely not a good programmer. On the other hand, anyone who's clearly very smart at the very least has a strong potential to be a good or great programmer.

#4 : Hidden experience

This is correlated with the "Passion" point, but it is such a strong indicator that I'd like to emphasise it with its own point.

I started programming when I was about 9, on a Commodore 64. I then migrated onto the PC, did some Pascal. When I was 14 I wrote a raycasting engine in C and Assembler, spent a large amount of time playing with cool graphic effects that you could get your computer to do by messing directly with the video card. This was what I call my "coccoon stage". When I entered that stage, I was a mediocre programmer, and lacked the confidence to do anything really complicated. When I finished it, I had gained that confidence. I knew that I could code pretty much anything so long as I put my mind to it.

Has that ever appeared on my CV? Nope.

I strongly believe that most good programmers will have a hidden iceberg or two like this that doesn't appear on their CV or profile. Something they think isn't really relevant, because it's not "proper experience", but which actually represents an awesome accomplishment. A good question to ask a potential "good programmer" in an interview would be "can you tell me about a personal project - even or especially one that's completely irrelevant - that you did in your spare time, and that's not on your CV?" If they can't (unless their CV is 20 pages long), they're probably not a good programmer. Even a programmer with an exhaustive CV will have some significant projects that are missing from there.

#5 : Variety of technologies

This one's pretty simple. Because of the love of learning and toying with new technologies that comes with the package of being a "good programmer", it's inevitable that any "good programmer" over the age of 22 will be fluent in a dozen different technologies. They can't help it. Learning a new technology is one of the most fun things a programmer with any passion can do. So they'll do it all the time, and accumulate a portfolio of things they've "played around with". They may not be experts at all of them, but all decent programmers will be fluent in a large inventory of unrelated technologies.

That "unrelated" bit is the subtle twist. Every half-decent java programmer will be able to list a set of technologies like "Java, J2EE, Ant, XML, SQL, Hibernate, Spring, Struts, EJB, Shell scripting", etc.. But those are all part of the same technology stack, all directly related to each other. This is possibly hard to recognise for non-programmers, but it is possible to tell whether their technology stack is varied by talking to them about it, and asking them how the different technologies they know relate to each other. Over-specialisation in a single technology stack is an indicator of a not-so-good programmer.

  • David Emery
    January 11th, 2008 at 10:26 pm

    Good list and I'd like to emphasize #5. My position is that I -never- hire a programmer without experience/knowledge of more than 1 programming language. The Sapir-Whorf hypothesis applies; if you know only 1 programming language you can't really think through alternate approaches to the problem. I've told people who clearly qualified based on the other criteria in this list, "Go learn another programming language and then come back and I'll hire you."

    See also this article: http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

    With respect to #4, some of us are old enough that our first chance to do any programming was when we got to universities. And that's a point I'd like to make: Experience counts. Someone with 20 years experience, even if it's not in the hottest technologies, but that otherwise meets these criteria, is often likely to be more productive in the middle to long run, than someone with 1-2 years of direct experience but no "time-in-life". A tremendous amount of stuff I experienced 20 years or more ago in some "antique" technology is still relevant; part of the skill to look for is an ability to apply life experiences to the new technologies. Remember that 1 good programmer significantly outperforms several mediocre programmers (based on both skill and Brooks' Law about team sizes.)

    dave

Finally, if some of those technologies are at the bleeding edge, that's a good positive indicator. For instance, today (November 2007), knowledge of Merb, Flex, RSpec, HAML, UJS, and many others… Please note that these are fairly closely related technologies, so in a couple of years, someone who knows all these will be equivalent to someone familiar with the Java stack listed in the previous paragraph.

Update: As a clarification to this point, there's in fact two indicators here: variety and bleeding edge. Those are separate indicators. A good variety of technologies across a period of time is a positive indicator, whether or not the technologies are bleeding edge. And bleeding edge technologies are a positive indicator, whether or not there's a variety of them.

#6 : Formal qualifications

This is more a of non-indicator than a counter-indicator. The key point to outline here is that formal qualifications don't mean squat when you're trying to recognise a good programmer. Many good programmers will have a degree in Computer Science. Many won't. Certifications, like MCSE or SCJP or the like, don't mean anything either. These are designed to be accessible and desirable to all. The only thing they indicate is a certain level of knowledge of a technology. They're safeguards that allow technology recruitment people in large corporations to know "ok, this guy knows java, he's got a certification to prove it" without having to interview them.

If you're hiring for a small business, or you need really smart developers for a crack team that will implement agile development in your enterprise, you should disregard most formal qualifications as noise. They really don't tell you very much about whether the programmer is good. Similarly, disregard age. Some programmers are awesome at 18. Others are awesome at 40. You can't base your decisions about programmer quality on age (though you might decide to hire people around a certain age to have a better fit in the company; please do note that age discrimination is illegal in most countries!).

As a final note to this, in my experience most average or poor programmers start programming at university, for their Computer Science course. Most good programmers started programming long before, and the degree was just a natural continuation of their hobby. If your potential programmer didn't do any programming before university, and all his experience starts when she got her first job, she's probably not a good programmer.

Disclaimer

None of the indicators above or below are sure-fire indicators. You will find great programmers who break some of those moulds. However, my view is, you'll rarely find a great programmer that breaks all of them. Similarly, you may find poor programmers that meet (or appear to meet) some of these criteria. But I do strongly believe that the more of these criteria a programmer meets, the more likely they are to be one of those elusive "good programmers" that, as a business guy, you need to partner with.

  • Richard
    January 11th, 2008 at 10:28 pm

    As someone that has programmed for nearly 15 years (hobby and professionally) with a background in psychological research I hate to say I find this "essay" not very scientific. This is all based on anecdotal evidence, stereotypes, and conclusions were reached without a solid methodology.

    Can I find people that fit these bullet items that are good programmers? Sure, but I can also point to some really bad programmers that fit this model in nearly every way also.

The criteria in bullets

So, in summary, here are some indicators and counter-indicators that should help you recognise a good programmer.

Positive indicators:

Negative indicators:

I hope these help. Let me know below if you have any comments, or anything to add to them!

Thanks for reading.

[Feb 11, 2008] What Makes a Good Programmer By Katherine Noyes

02/11/08 | linuxinsider.com

At a Loss for Words

Yet it is a heavy responsibility, too, which is why this week we'd like to direct our readers' attention to a recent post by Red Hat (NYSE: RHT) blogger Havoc Pennington pointing out a very excellent article by blogger Daniel Tenner titled "How to recognize a good programmer."

While Pennington's post was from Tuesday, the article itself dates back to a blog post from November. Given the timeless importance of the article's topic, we wouldn't even point out its publication date were it not for the shocked reaction we got from certain Slashdot founders, who went only so far as to say, "My only comment is that you should try to be more punctual :)."

We can only assume the topic's profound importance and magnitude rendered those unnamed Slashdot founders at a loss for words.

Misleading Resumes

Other bloggers, fortunately, were much more forthcoming on the topic, which is so central to the daily lives of so many of us.

Tenner writes that good programmers are not always easy to recognize, particularly for those who are not programmers themselves.

"It's not as easy as it sounds," writes Tenner, who has worked both in programming and on the business side.

"CV experience is only of limited use here, because great programmers don't always have the 'official' experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading," he adds. "Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great programmer."

You're Good If...

Among Tenner's list of positive indicators suggesting someone is a good programmer are:

Do these technologies describe you or someone you know? If so, you may be in the midst of greatness, according to Tenner.

Passion Is Key

"I don't consider myself a good programmer yet (but a TON of those things applied to me), and I have no experience in hiring programmers," Monochrome Mentality blogger Kevin Dean told LinuxInsider.

Passion, however, may in fact be one of the unsung heroes of the open source development model's success, Dean asserted.

"As a general statement, I've often disagreed with Eric S. Raymond and Linus Torvalds about the open source development model producing 'better' code," Dean said. "A topic not really discussed by either of those guys was the number of people passionate about the code they were writing."

Free software allows people to choose the projects that interest them, Dean added. "I've always thought this factor was the single MOST important reason for 'better code,' rather than 'more people looking at it,'" he said.

Nice Guys First

Traditional experience and certifications may be less indicative of programming skill than other characteristics, agreed Slashdot blogger yagu.

"There's a lot of conventional wisdom that good programmers come with exceptional brilliance, and lots of certifications proving their mastery (read 'certifications')," yagu told LinuxInsider. "While I'd expect a good programmer to be smart, I couldn't care one lick for their paper trail, short of ground-breaking doctorates awarded on research in the industry."

One trait characteristic of good programmers is friendliness, yagu asserted.

"Contrary to the classic, mysterious and cranky genius in a dark back room, a good programmer does have social skills and should be friendly and easy to communicate with," he said. "If you can't talk with a programmer, you'll never communicate needs efficiently. This is a cornerstone of creating useful software."

Along similar lines, good programmers are generous in spending time helping others use applications and understanding technology, yagu said, and they are empathetic. "He doesn't judge or criticize a user as 'stupid,' but tries to see their problem as they experience it and then works with the user to come up with a solution," yagu explained.

Mystery and arcane jargon are not things good programmers promote or hide behind, he added.

Did We Mention Passion?

Good programmers don't have to be geniuses, yagu added, but they should be smart and they should have a creative approach. "A good sign of smart would be a programmer who has mastered several, if not many, programming languages," he said.

Indeed, good programmers are well-rounded, yagu added. "Find me a programmer who also loves to bicycle, attend theater, read a good book," he said. "A programmer with external and various interests is going to look at the universe without the distortions of a 'technology-only' lens."

Finally, passion is another key characteristic of good programmers, yagu agreed. "A good programmer loves to describe the intricacies and nuances of technology, often beyond your need to know or capacity to understand," he said.

And on that timely note -- passion, that is -- we here at LinuxInsider would like to remind our readers that Valentine's Day rapidly approaches. Don't forget the human factors!

embracing-my-inner-geek-part-2-the-job

Compare with Aesthetics and the human factor in programming by Andrey Erchov


A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy. The process of developing software differs from organization to organization. Some are more "shoot from the hip" style, others, like my current employer are much more careful and deliberate. In my 8 years of experience I've worked for 4 different companies, each with their own process. But out of all of them, I've found these stages to be universally applicable:

Dreaming and Shaping

A piece of software starts, before any code is written, as an idea or as a problem to be solved. Its a constraint on a plant floor, a need for information, a better way to work, a way to communicate, or a way to play. It is always tied to a human being ≈ their job, their entertainment┘ their needs. A good process will explore this driving factor well. In the project I'm wrapping up now I felt strongly, and my employer agreed with me, that to understand what we needed to do, we'd have to go to the customer and feel their pain. We'd have to watch them work so we could understand their constraints. And we'd have to explore the other solutions out there to the problem we were trying to solve.

Once you understand what you need to build, you still don't begin building it. Like an architect or a designer, you start with a sketch, and you create a design. In software your design is expressed in documents and in diagrams. Its not uncommon for the design process to take longer than the coding process. As a part of your design, you have to understand your tools. Imagine an author who, at the start of each book, needs to research every writing instrument on the market first. You have to become knowledgeable about the strengths and weaknesses of each tool out there, because your choice of instrument, as much as your design or skill as a programmer, can impact the success of your work. Then you review. With marketing and with every subject matter expert and team member you can find who will have any advice to give. You meet and you discuss and you refine your design, your pre-conceptions, and even your selected tools until it passes the most intense scrutiny.

Once you have these things down, you have to be willing to give them up. You have to go back to the customer, or the originator of the problem, and sell them your solution. You put on a sales hat and you pitch what you've dreamt up┘ then wait with bated breath while they dissect your brain child. If you've understood them, and the problem, you'll only need to make adjustments or adapt to information you didn't previously have. Always you need to anticipate changes you didn't plan for ≈ they'll come at you through-out the project.

Once you know how the solution is going to work, or sometimes even before then, you need to figure out how people are going to work with your solution. Software that can't be understood can't be used, so no matter how brilliant your design, if your interface isn't elegant and beautiful and intuitive, your project is a failure.

I don't pick those adjectives lightly either. All of them are required, in balance. If its not elegant, then its wasteful and you'll likely need to find a new job. If its not beautiful, then no one will want to use it. And if its not intuitive, no one will be able to use it. The attention to detail required of a good interface developer is on par with that of a good painter. Every dot, every stroke, every color choice is significant.

To make something easy to use requires at least a basic understanding of human reactions, an awareness of cognitive norms. People react to your software, often on a very base level. If you don't believe me, think of the last time your computer crashed before you had a chance to save the last 2 hours worth of an essay, or a game you were playing. What you put before your users must be easy to look at so that they are comfortable learning it. It must anticipate their needs so that they don't get frustrated. It must suggest its use, simply by being on the screen. And above all else, it must preserve their focus and their effort.

So you paint, using PowerPoint, or Visio, or some other tool, your picture of what you think the customer is going to want to use, and once again you don your sales hat and try to sell it to them. Only, unlike a salesperson selling someone else's product, you are selling your own work, and are inevitably emotionally-attached to it. Still, you know criticism is good, because it makes the results better, so you force yourself to be logical about it.

Then finally, when your solution is approved, and your interface is understood, you can move on to the really fun part of your job:

Prose and Poetry

A good sonnet isn't only identified by the letters or words on the page, but by the cadence, the meter, the measure, the flow┘ a good piece of literature is beautiful because it is shaped carefully yet communicates eloquently.

Code is no different. The purpose of code is to express a solution. A project consists of small stanzas, called "Methods" or "Functions" depending on what language you use. Each of these verses must be constructed in such a way that it is efficient, tightly-crafted, and effective. And like a poem, there are rules that dictate how it should be shaped. There is beauty in a clever Function.

But the real beauty of code goes further than poetry. Because it re-uses itself. Maybe its more like music, where a particular measure is repeated later in the song, and through its familiarity, it adds to the shape of the whole piece. Functions are like that, in that they're called throughout the software. Sometimes they repeat within themselves, in iterations, like the repeating patterns you see in nature. fern.jpgAnd when the pieces are added up, each in itself a little work of art, they make, if programmed properly, a whole that is much more than a sum. Its is an intertwined, and constantly moving piece of art.

As programmers, we add things called "log messages" so that we can see these parts working together, because without this output, the flow of the data through the different rungs and branches we put together is so fluid that we can't even observe it and, like trying to fathom the number of stars in the sky, it is difficult to even conceptualize visually the thousands of interactions a second that your code is causing. And we need to do this, because next comes a Quality Assurance Engineer (or QA) who tries to break your code, question your decisions, and generally force you to do better than what you thought was your best.

I truly believe that code is an art form. One that only a small portion of the population can appreciate. Sure anyone can walk into the Louvre and appreciate the end result of a Davinci or a Van Gogh, but only a true artist or student of art can really understand the intricacy of the work behind it. Similarly, most people can recognize a good piece of software when they use it (certainly anyone can recognize a bad piece of software) but it takes a true artist, or at least an earnest student, to understand just how brilliant ≈ or how wretched ≈ the work behind it is.

And always, as you weave your code, you have to be prepared to change it, to re-use it, to re-contain it, to re-purpose it in ways that you can't have planned for. Because that is the nature of your art form ≈ always changing and advancing.

Publishing and Documenting

Its been said that a scientist or researcher must "publish or perish." The same is true of a software developer. A brilliant piece of code, if not used, is lost. Within months it will become obsolete, or replaced, or usurped, and your efforts will become meaningless, save for the satisfaction of having solved a problem on your own.

So after months of wearing jeans, chugging caffeine, cluttering your desk with sketches and reference material, you clean yourself up, put on a nice pair of pants, comb your hair, and sell again. Although most organizations have a sales force and a marketing department, a savvy customer will invariably want technical details that a non-coder can't supply. As a lead developer on a project, it falls to you to instill confidence, to speak articulately and passionately about the appropriateness and worth of your solution. Again, as before, pride is a weakness here, because no matter how good you are, someone will always ask if your software can do something it can't ≈ user's are never really satisfied. So you think back to the design process, you remind them when they had a part in the decisions, and you attempt to impress upon them respect for the solution you have now, while acknowledging that there will always be a version 2.0.

And you write and you teach. Not so much in my current job, but in one previous, as a lead developer it was my responsibility to educate people on the uses of our technology ≈ to come up with ways to express the usefulness of a project without boring people with too many technical details. One of the best parts of software development, a part that I miss since its not within my present job description, is getting up in front of people ≈ once they've accepted your solution ≈ and teaching them how to use it and apply it. Taking them beyond the basic functionality and showing them the tricks and shortcuts and advanced features that you programmed in, not because anyone asked you for them, but because you knew in your gut they should be there.

And Repeat

Then there's a party, a brief respite, where you celebrate your victory, congratulate those who've worked on parallel projects, and express your deepest gratitude for your peers who've lent their own particular area of expertise to your project┘ And you start again. Because like I'm sure any sports team feels, you are only as good as your latest victory.

So do I fix computers? Often its easier or more expedient to hack together a solution to a problem on my own ≈ certainly the I.T. Department is becoming something of a slow-moving dinosaur in an age where computers aren't the size of buildings, and most of us are comfortable re-installing Windows on our own ≈ but that's not a part of my job description.

No, I, like my peers, produce art. Functional, useful, but still beautiful, art. We are code poets, and it is our prose that builds the tools people use every day.

However, unlike most other artists, we're usually paid pretty well for our work ;-)

Slashdot The Life of a Software Engineer

[Apr 05, 2007] Working for The Man Advice to a young programmer Tech News on ZDNet

Commentary -- Making a career out of writing software? Remember that the community is more important than your employer.

Working for Google is full of surprises. When I first arrived I started to get to know my office-mate. He's a laid back, rather cool but studious-looking guy with longish hair. I asked him what he did and learned a lot about how students were taught parallel processing in a cluster environment. Politely he responded with the same question and I started to tell him about Samba and what I was currently working on. "You remember around 1988 when AT&T came out with a file-sharing protocol called RFS (Remote File System) to compete with NFS (Sun's Network File System)..." I continued.

"I was eight years old in 1988," he replied.

After I'd finished checking for obvious facial wrinkles in the bathroom, I decided to go on a quest to find other engineers in the building who were at least as old as I was, and felt much better when I found some. But it set me thinking about what kind of advice I would give if I could meet myself at his age, in order to guide the young Allison into a promising engineering career. So, in the best spirit of "The Screwtape Letters," here is some of what I've learned so far about making yourself a career in writing software.

If it's not what you love, don't do it

I've worked with many programmers during my career. Without a doubt, the only ones who are any good at it are those who see writing code as art, a creative process. I know it's an obvious lesson, but it's really important. If you want to make lots of money and retire early, don't start by writing software; learn about business and start a company instead. I've run into so many poor programmers, in both senses of the word, who got into the field because they "wanted to be the next Bill Gates." Bill Gates didn't get rich by programming, he got very rich by being very good at running a company. I've had to fix code created by these people and it isn't pretty. Eventually they usually move into management where they might have a chance to find their true calling.

Learn the architecture of the machine

Many programmers, especially those who write for virtual machines such as Java or the .NET CLI, think that low-level machine architecture and processor instructions don't matter anymore. That's still not true, and I don't believe it ever will be. Someone who understands what the machine is really doing underneath all the modern layers of glop such as virtual machines, garbage collection algorithms, network and threading abstractions, will always be able to solve problems better than someone who lets the compiler or the "execution environment" they're using make all the decisions for them. These days the effects of processor caches and memory bandwidth mean that it's even more important to understand the lower levels of computer architecture than it used to be in order to be a good programmer. The good news is that modern tools like the amazing free software tool "valgrind" can emulate an entire processor in software and make understanding what is going on at each line of code as simple as looking at a visualization of execution time. Using resources efficiently matters when you're dealing with modern clusters containing thousands of machines.

Reputation is important

The days of starting at IBM after college and working there in obscurity until you retire are long gone. Any modern programmer will move between many companies in his or her career. It is very important to be able to show your next employer what you have done, and what you are able to do in a team. Free software/open source is the ideal way of doing this. It's not just a better way of producing software, it's actually better for the reputation of the people creating it. One of the first things I do when evaluating someone is to look for samples of their code out there on the Internet. If you work on proprietary software you can't show anyone anything, and real code speaks louder than any list of projects you claim to have worked on.

Comments:
Working for The Man? Advice to a young programmer

What about the side effects of programming? The long hours at the office, staring at a computer screen for hours on end, and the one thing I'd be most concerned with is carpal tunnel. Then there is lower back pain from sitting in a chair for too long. The health risks are just as important.

Posted by: Loverock Davidson Posted on: 04/05/07

====

Art? Since when is that part of so-called 'corporate culture',

which is not driven by art but by money and how marketable something is. And as we've often seen, marketable does not always equate with quality.

Or if something if released, corporations should promise to fix it before adding new abilities to it.

Having said that, I see the logic behind hopscotching jobs. Trouble is, with some jobs so far away, anyone with a family may not be able to uproot themselves. And families are part of communities too. Or is some group of people not satisfied with the already high number of divorces and other family fall-outs; hoping this scenario will do the trick?

Posted by: HypnoToad72 Posted on: 04/05/07

Rick's World - Post details What makes a good programmer

My friend Dave, wrote a blog a few days ago, commenting on what he thought made a good programmer. I thought I was respond by listing my own qualifications for a good programmer:

Housemarque

Landing a programming position at Housemarque

At Housemarque we mainly develop full scale, console games for international market. A typical game may take 1-3 years to develop and may consist of 100k-300k lines of code. The competition in this market is tough, so we place tough requirements on our programmers.

Requirements

We do not require a degree in software engineering or computer science. We do, however, require:

In addition, since nearly all of our development is currently done in C++ and in english, we require:

Pluses:

Demonstrated exceptional skills in:

Computer graphics

Questions we'd like to be asked

What makes a good programmer in our view? The most important characteristic of a good programmer is the constant desire to learn more. If you think that you know everything there is to know about programming and/or have not read more than 2 programming books in the last 12 months, then it is unlikely that we would hire you - but in case you really know everything, then we would like to know whether P is NP (formal proof required). A good programmer is well versed in many areas of programming. ,

How do you evaluate programming samples?

All candidates are required to submit a source code sample of their programming. Without the sample, we can not make an assessment of your programming skills and can not consider you for a programming position. Performing a code review of a non-trivial programming sample is generally the most accurate way to assess the programming skills of an applicant.

A programming sample should preferably be in C++, because that is the main language we use in game development, but we accept programming samples in other languages.

ryanlrussell What makes a good programmer

Aha! I just found a quote from Joel which puts into words what makes a good programmer.
You need training to think of things at multiple levels of abstraction simultaneously, and that kind of thinking is exactly what you need to design great software architecture.
The quote can be found in this blog post.

Software quality has almost nothing to do with algorithmic elegance, compactness, or speed - in fact, those attributes do more harm to quality than good.

The objective is to make things as clear as possible to the designer and to yourself, and excessive formality can destroy clarity just as easily as modest formality can enhance it.

[The Spec] Be literal in your interpretation and smile when the designer accuses you of semantic nit-picking.

In programming, it's often the buts in the specification that kill you.

Don't squeeze the code. Don't squeeze the code. DON'T SQUEEZE THE CODE.

Like so much in testing, the act of getting the information on which to base tests can be more effective at catching and exterminating bugs than the tests that result from that information. Insisting on getting transaction flows or the equivalent is sometimes a gentle way of convincing inept design groups that they don't know what they're doing. These are harsh words, but let's face it: superb code and unit testing will be useless if the overall design is poor. And how can there be a rational, effective design if no one on the design team can walk you through the more important transactions, step by step and alternative by alternative. I'm sure that mine is a biased sample, but every system I've ever seen that was in serious trouble had no transaction flows documented, nor had the designers provided anything that approximated that kind of functional representation; however, it's certainly possible to have a bad design even with transaction flows.

Boris Beizer: Software Testing Techniques 2E. Van Nostrand Reinhold, New York 1990

Overpaid and underworked csmonitor.com

Overpaid and underworked?

The salary often seems greener on the other desk, but studies show that may not be true.

By Marilyn Gardner | Staff writer of The Christian Science Monitor

When the subject turns to salaries, an IT consultant in the New York area sums up the feelings of many workers when he says, "I'm probably paid a little less than I'm worth."

Now he wants to change that. "I'm exploring my options," the consultant says, asking to be identified only as Eric because he fears he could jeopardize his current position if his firm finds out he is job-hunting.

Eric has plenty of company. A survey released Monday by Salary.com reveals that nearly 60 percent of workers seeking jobs claim they are underpaid. But in a surprising twist, the salary data website finds that nearly 20 percent are actually overpaid. Less than 20 percent are underpaid.

"Phrases like 'overworked and underpaid' perpetuate that feeling," says Lena Bottos, director of compensation for Salary.com. The online survey of employee satisfaction and retention polled nearly 14,000 workers and some 400 human-resources managers in a wide range of industries.

Salaries have long been cloaked in secrecy for many workers, making comparisons difficult. Now, online salary data sites enable workers to measure their pay against comparable positions in their field and location.

"You network with your peers, and absolutely they talk about salaries," Eric says. "At least they talk about ranges. Just looking around at what ranges are offered, you have an idea of the market rate. The consensus among my peers is that the way to get a good raise is to switch companies."

Another survey, done in 2005 by Hudson Highland Group, finds that only half of workers believe they are paid on a par with their peers.

The number of employees in the Salary.com poll who describe themselves as "very likely" to leave their current jobs increased more than 50 percent in the past year.

"There are a lot more new jobs," Ms. Bottos explains. "People see that the market is starting to pick up. The grass is always greener."

At the same time, employees are becoming "a little bolder" in terms of what they think they are worth, says Jeff Cooper, a senior business consultant at Authoria, a talent-management software company in Waltham, Mass.

Employers themselves have unwittingly created some of the confusion. When the economy slows, some companies inflate workers' titles in lieu of salary increases. Salary.com finds that nearly 30 percent of respondents are "over-titled."

"When a manager wants to reward an employee and doesn't have the budget to do so, you tack on 'supervisor,' 'manager,' 'director,' or 'senior' to their title," Bottos says. "But the problem then arises that you've given someone this 'manager' title, but they don't manage. You've created a disconnect between what their title is and what their salary should be."

Workplace experts caution that titles are deceiving and vary from company to company. "In the end, a title is what goes on someone's business card," says Lauren Williams, a managing partner with Princeton Search Group, an executive search firm. "It speaks very little to their abilities. What could be a manager in one company could be a director in another. An executive assistant in one company could be a receptionist in another. But responsibility is responsibility. That's what people can be accounted on and compensated for."

Whatever their title, many employees who are dissatisfied with their income say that a 10 percent raise would be enough to keep them for another year, according to Salary.com.

Bottos calls that "an interesting number, because it isn't outrageous."

Joel on Software A good introduction to Dr. Deming's philosophy of management: Four Days with Dr. Deming summarizes the four day seminars Deming used to give to business leaders.

If you're in a rut constantly trying to figure out how to rejigger your employees' incentive systems, this book will get you out of it.

Lord Palmerstron Syndrom

Lord Palmerston: "The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it." Programming has gotten too hard.

Student Syndrom

"Student Syndrome" - no matter how long you give students to work on something, they will start the night before.

Phil Greenspun noticed this: "The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before."

The Law of Leaky Abstractions

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions, and it's dragging us down. Read all about it in my latest feature article: The Law of Leaky Abstractions.

Front End Programming Sucks

Author: James Fristrom

Posted: 2/6/2002; 8:06:22 PM

Topic: Front End Programming Sucks

Msg #: 55 (top msg in thread)

Prev/Next: 54/56

Two facts.

Fact #1: You can't trust the front end to a mediocre programmer. They'll take at least twice as long to get it done, it will be shoddy, it will violate the console manufacturer's Technical Requirements Checklist.

Fact #2: Good programmers don't like working on the front end.

You could say that you shouldn't hire mediocre programmers in the first place. But then who will work on the front end?

So what do you do?

I wish I knew. I've worked on three projects where vital front end functionality was missing and broken right up to the wire. This latest time was worse than most: we ended up firing the front end programmer and dividing his remaining bugs between the lead and two trusted coders.

Why isn't professionalism - the virtue of enjoying a job well done - enough to keep good coders happy with doing front ends? I guess we didn't get into this industry to be professional, we did it to work on cool games.

Maybe it's that front ends don't seem 'challening' enough. But front ends aren't without challenges: front ends often mix three-d and two-d elements, stream data and audio at the same time, have stunning graphics.

"I was meant for more important things," I hear programmers say. The most visible system in the game isn't important enough. Doesn't require their advanced skill set.

My dream front end programmer might be someone from the web design community, but someone who also was skilled at C++. Someone who didn't mind working on tools. (The same problem I outlined above also holds true for tools programming...it's vital to your success but nobody wants to do it.) Someone who had enough design sense to make decisions without being micromanaged by an art director. Does such a person exist? And could a game development company afford them, or is web programming far too lucrative?

Actually, my dream front end programmer would be a clone of myself with a pay cut.

(Michael Vance pointed out that this last sentence is obnoxious. He's right, it is obnoxious, but I'm going to leave it up here out of shame.)
Posted by James Fristrom on 2/6/02; 8:19:41 PM
from the dept.

I've heard widely varying opinions on why software is so lousy, the most recent from this article by Charles C. Mann. Mr. Mann makes an excellent anecdotal case for just how bad software has become. Then, he concludes that perhaps a bit more litigation would help matters. While one of the perpetrators of bad software he cites is Microsoft, they, and other wealthy software development companies, might be among the least vulnerable to lawsuits brought over poor software. As is frequently the case, increased litigation would probably put the small developer at even more of a disadvantage relative to the large software corporation.

But more to the point, why is software so bad? Programming is sometimes compared to an engineering specialty and the point is made that product standards are much lower for software. Software, unlike building construction, for example, is pure design. The actual programming phase is just a finer grained version of what we programmers normally call 'design'.

Software development is one hundred percent design.

Consider the implications of that statement for a moment. Virtually all of the cost of software development is, directly and indirectly, the cost of design. If a student architect could design a skyscraper, push a button, and have some futuristic genesis device instantly construct the building at virtually no cost -- and at no danger to anyone -- and with perfect components throughout, would he not do so? Further, imagine that with a push of another button, the entire building could be reduced back to its constituent atoms.

The student could try and try again, refining his design until it was finally just what he wanted. Now, imagine that there was no danger in occupying such a building. Would it change the way we make buildings? Given the alternative of spending millions to build the building the old fashioned way versus spending a fraction of one percent of that to do only the design -- and automate the remainder for virtually nothing -- I suspect that the market would choose the vastly cheaper method.

For software that doesn't involve life-or-death applications, the development cost model closely resembles our fictional architectural scenario.

People are understandably reluctant to add real engineering discipline to software development. While there is no physical building phase, the complexity of a large application is staggering. A large program might have millions of (logically) moving parts, all interrelated. To prove that it all works correctly, as specified, might be more than just prohibitively expensive; it may well be impossible. And even if such verification were possible, proving the correctness of a large program would greatly delay the release date.

Perhaps life support systems, X-ray machines, and other such critical programming does belong in the engineering realm with formal education requirements, legal responsibilities, and state certification. But for my favorite projects, I think the status quo is just fine.

Yes, software sucks -- but it's usually cheap. Further, in my experience, the cheapest software, free, seems to suck the least.

Fast, good, cheap: choose two.

[June 2005] Programmers are People, Too

by Ken Arnold, Independent Consultant

From Security
Vol. 3, No. 5 -

As API designers we may talk about a trade-off between simplicity and power, but we can look to human factors to find tools to address it. One such tool is progressive disclosure: rather than put expert-level features at the same level as basic ones, you put them behind a door marked "expert." Consider the car, where most folks can work with the controls in the cabin but, with a few exceptions (such as washer fluid), they never need to open the hood. You know the engine is there, but most people just leave that part alone. A few experts do open it up and adjust the car with these expert-level controls, and if you want to do it, you know where to look. But if operating a car presented you with the entire engine as a control structure, most humans would find driving dauntingly complex, even if they just had to learn not to look at "all them wires and tubes and valves and things."

You see progressive disclosure fairly often in GUI designs, typically as an Advanced or Expert button. This might expose settings for Web proxies in a browser or a rarely needed configuration for adjusting color balances on a printer.

We could do the same thing with APIs. For example, the Java Swing JButton class-the basic GUI button-has well over 100 methods. But if you think about GUI buttons, there are only a half-dozen things you typically care about most of the time. When presented with this massive complexity, how are you to tell where to start? Should you be adjusting the preferred or minimum size? What happens if you change the text? Do you need to fire those things called "change listeners," and if so, which kind?

To start getting this nonsense under control, you can start by breaking the JButton methods down into three major groups:

Now we could use progressive disclosure to help reduce the complexity of that JButton class: put the expert stuff in an object returned by a getExpertKnobs() method, and the graphics subsystem hooks in an object returned by a getIntegrationHooks() method, and you would be left with a button API that had just a handful of methods-the basic methods we all need.

The overall system would be a bit more complex if you simply count methods and types, but you should not fall into the trap of thinking all methods are the same. If you look at what is presented to the programmer, the system would go from well over 100 methods to consider when using a button to fewer than 10. All the power would be present and available, but only when you wanted it. For the most part, you could ignore it completely because they would be behind "doors" labeled, "You probably don't need to look here." If one were sufficiently brutal in exiling functionality to behind the doors, the API would almost be self-explanatory to the nonexpert user. (To be fair, Swing is not unique in its complexity. This malaise seems to infect most GUI frameworks of note, including the Microsoft Foundation Classes, the X11 toolkits, and so on.)

What progressive disclosure does here is reduce the surface area, a term I use to talk about how much users have to understand about something before feeling confident they can use it. The more methods in an API, the more a user has to read through and understand before knowing, for example, if changing the label is something as simple as calling setText or if one those other methods affects this. The larger the surface area, the harder it is to learn to use the tool well for even simple applications.

SECOND EXAMPLE: THE AUDIENCE

Another human-factors approach that could be applied to programmer tools is to consider the audience (sometimes called the user model). A good UI design has a notion of audience: What kinds of people are we designing for? What do they know, not know, and expect? If a UI has a clear and consistent audience, it is easier for users to make predictions about what the system will do. This reduces unpleasant surprises and means that the users can guess how to do things without reading the documentation (which they hardly ever do). Sounds like a pretty good feature in a programming language or API, doesn't it?

This can work even if the user is not a part of the targeted audience. If you present a consistent model of some known kind of user, other kinds of users can potentially adapt, consciously or otherwise thinking via the role of the target user.

If you apply this question to C++, for example, you will find major problems. Sometimes C++ believes that programmers like to have the compiler do obvious things on their behalf and correct the compiler when it's wrong. C++ will, for example, generate a default copy constructor that can create a copy of your type of object. Yes, the default copy constructor can be wrong, but it is right fairly often, so the language gives you a hand. If it's wrong, any C++ programmer should know enough to provide a replacement that does work properly.

At other times C++ has a different model of the user: it believes that it should do nothing that stands a chance of being wrong, no matter how many times an obvious assumption would be right. One example is what doesn't happen if you define how to check if two objects are equivalent (overriding the == operator). It seems obvious that knowing if two objects are equivalent would let you know if they are not equivalent. That is, knowing how to test x == y, then x != y can be thought of as !(x == y).

But C++ does not define != for you because it is possible in some odd cases that this is not true, though the number of such cases must be infinitesimal. It is surely wrong in many fewer cases than the default copy constructor is wrong.

So is C++ a language that helps you with obvious things that are usually correct, or one that is more concerned with formal correctness? As an example, take a guess: if you define a constructor that can create a new Foo object from a Bar object, does C++ use it to automatically define how foo = (Foo) bar will work? Put another way, does it override the = operator for assigning a Bar to a Foo? Is your gut instinct different for these two questions?

This kind of inconsistency makes a system harder to learn and harder to use correctly. Instead of a consistent, comprehensible model of the audience that the user can grasp, you have instead a large collection of special cases where you can neither predict nor use some rule of thumb as a hint.

WHERE TO GO WITH THIS?

When you use a GUI that has profound inconsistencies about what level of expertise and control you have, or presents you with a dialog box with 100 options when you just want to change the display font, is it fair to say that the designer made a mistake? Then why not judge the API or language designer the same way?

The problem is that these basic rules of thumb and experiences in human factors are not part of the design discourse about the primary tools we build for ourselves: programming languages and APIs. We ought to change this. If we can learn from human factors to do things better, we will be able to write code with fewer bugs. And because it will be easier, we can spend less time learning how to do stuff and more time doing it. The study of human factors is for humans, not for GUIs. And (see above) programmers are humans.

So let's proceed from the following theorem: An API or programming language is a user interface to the programming model that is being presented to the user (the programmer).

Let's look at several typical rules of thumb for human factors and see how they might be applied.

Similar things should look similar. If two things mean the same or very similar things, they should be presented in ways that express that similarity. In a GUI this would mean that no matter how many ways and reasons there are to open files, the basic interaction for opening files should be the same. For an API this might mean that if there are multiple things that can be started and stopped, then the same terms should be used for each kind of thing. It would be important to pick, for example, "start" and "stop" and use them for all starting and stopping, rather than have some places where you end execution using "end" or "terminate" or "close" or "destroy."

As a negative example, C has two rather different variable declaration mechanisms: one used for declaring function parameters (which is comma-separated), and another used for all other variables (which is semicolon-terminated). Although we've all learned this, it is one of those small things that you can stumble over. Everywhere but in function parameters you can declare that x and y have the same type via "double x, y;" but in method parameters it must be "double x, double y", which loses the connection between the types of variables. In the first form you can change coordinates to be held in float variables naturally, whereas in the second form you must change the types of x and y independently, as if it somehow might be reasonable to change only x.

Use forcing functions to prevent errors. You could think of this as the "This button turns on the bathroom light, and that button launches global thermonuclear war. Don't mix them up!" rule.

A forcing function makes the user do something that prevents (or makes unlikely) some type of mistake. Many cars, for example, will not let you take the key out of the ignition unless the car is in a correct gear. This makes it very unlikely that you will leave the car in neutral when you leave your car, only to watch it slip down the hill and into your mother-in-law's new Lexus.

In programming you can apply this to many areas. In many languages you can make it impossible to write certain kinds of incorrect code. In C++ the presence of const is intended for exactly this purpose. If the compiler simply won't let you make a modifying call on an object, and you hand out only const references to your objects, then users can't make the mistake of modifying something they shouldn't. (Well, at least not casually-you can cast away const, but this is clearly suspicious behavior, so you've at least made them do something that raises alarm bells. This is still a forcing function.)

Another example is quite common: if you don't have the right token, you can't perform a particular action. Any time you see a function that requires a certain type of handle that you can only get somewhere specific, you are being forced to do something first. In Java, for example, you can open with a File object, but you can close only the resulting FileInputStream object, not the File object. This makes it impossible to write code that closes a file without opening it first.

Think from the user in. Interestingly, the forcing function principle also demonstrates the difficulty of actually applying human-factors principles. Reading a file is a very different category of action than destroying existing files, which risks much more damage. The normal forcing function approach would be to make it more awkward to destroy a file than to read one. Maybe we could make destroying files a multistep process or use longer function names that would never be accidentally typed.

Programmers, however, are not just humans, but notoriously lazy and problem-solving humans. In the face of such a design, programmers would write single methods that combine all the steps, or create shortcuts for long method names, or otherwise remove the "problem" of awkward access. I know I would. So in applying this principle we are limited by both our "materials" (programming languages) and our audience.

In other words, your audience has particular features: habits, assumptions, knowledge (correct and wrong), and customs. Programmers are human. They also are particular kinds of humans. And the user of some particular API is yet further specifiable.

The one thing they are almost certainly not, however, is you. You are thinking about how to solve the problem, the merits of various approaches, the detailed trade-offs between one algorithm and another, the literature on doing the work involved, and so on. By the time you are done figuring out what to do, you are likely one of the most expert folks in the world on the task you are trying to help people with.

And your users? They just want it to happen. They will have varying degrees of expertise, but even the most expert will have one reason to use your system: so they can think about it as little as possible. If you have done your job well, their use of your code will be only as large as you make them make it. Remember, if possible, your users would want you to provide a single command: dwim (do what I mean).

So you must think like your user: think in to the problem from their desires and viewpoints rather than out from your sophisticated understandings of solutions and mechanisms. Your design should ask, "What does the user want to do?" instead of "How can I present Whilfolze's 3rd Equation to optimize applications of Guilemorting's Principle?" If Whilfolze and Guilemorting have useful things to say about solving the user's actual problem, you should apply their insights instead of making the user tell you how to apply them. The user should say "solve this," and your code should use Whilfolze and/or Guilemorting if that's a good thing to do.

Consider the difference between a car designer asking, "How does the user control the car?" vs. "How can the user adjust the fuel intake, injectors, cylinders, spark plugs, fans, differentials, etc.?" The first question is much more likely to produce a design usable by car-ignoramuses like me because the question it asks is one I will ask. Approaching the design as a way to fiddle with the complex car parameters will almost certainly produce a more complex design with more alternatives and features presented to me. I don't want that. If I want to become a car expert, I will open the hood. I just want the thing to work.

One way to approach the problem is this: write the pseudocode your users would want to write, and then make it work with as few additions as possible.

The primary questions are: What problems are users trying to solve? What kinds of things do users have in hand when they want to solve the problem? How does the user think of the problem? What must the user tell me and what can I deduce for myself? This starts with a good definition of who your users are, of course, which is a task most designs seem to ignore.

Remember that users have a notorious history of thinking they know how something should be done and being wrong. One classic example is the register keyword of C. The idea was that the user (in this case a programmer) would tell the compiler which local variables should be stored in fast-access processor registers because the programmer knew what was critical. It turned out that compilers were almost always smarter about register allocation than users could ever be. The register keyword quickly became advisory, and by now I suspect that all C/C++ compilers just ignore it, snickering.

Humor

Signs You Live in the Year 2002 (02h21807.txt)

  1. You just tried to enter your password on the microwave.
  2. You have a list of 15 phone numbers to reach your family of 3.
  3. You call your son's beeper to let him know it's time to eat. He e-mails you back from his bedroom, "What's for dinner?"
  4. Your daughter sells Girl Scout Cookies via her web site.
  5. You chat several times a day with a stranger from South Africa, but you haven't spoken with your next-door neighbor yet this year.
  6. You check the ingredients on a can of chicken noodle soup to see if it contains Echinacea.
  7. Your grandmother asks you to send her a JPEG file of your newborn so she can create a screen saver.
  8. You pull up in your own driveway and use your cell phone to see if anyone is home.
  9. Every commercial on television has a website address at the bottom of the screen.
  10. You buy a computer, and 6 months later it is out of date and now sells for half the price you paid.
  11. Leaving the house without your cell phone, which you didn't have the first 20, 30 or 40 years of your life, is cause for a panic and you turn around to go get it.
  12. Using real money, instead of credit or debit, to make a purchase would be a hassle and takes planning.
  13. Cleaning up the dining room means getting the fast food bags out of the back seat of your car.
  14. Your reason for not staying in touch with family is that they do not have e-mail addresses.
  15. You consider 2nd day air delivery painfully slow.
  16. Your dining room table is now your flat filing cabinet.
  17. Your idea of being organized is multicolored post-it notes.
  18. You hear most of your jokes via e-mail instead of in person. (OUCH!)
  19. You get an extra phone line so you can get phones calls.
  20. You disconnect from the Internet and get an awful feeling, as if you just pulled the plug on a loved one.
  21. You get up in the morning and go online before getting your coffee.
  22. You wake up at 2 a.m. to go to the bathroom and check your e-mail on your way back to bed.
  23. You start tilting your head sideways to smile.= :)
  24. YOU'RE READING THIS!!!!!!!
  25. EVEN WORSE: YOU'RE GOING TO FORWARD IT TO SOMEONE ELSE, JUST LIKE I DID!

SOMETHING

Something in the way it fails,
Defies the algorithm's logic!
Something in the way it coredumps... 
I don't want to leave it now
I'll fix this problem somehow
Somewhere in the memory I know,
A pointer's got to be corrupted.
Stepping in the debugger will show me... 
I don't want to leave it now
I'm too close to leave it now
You're asking me can this code go?
I don't know, I don't know...
What sequence causes it to blow?
I don't know, I don't know...
Something in the initializing code?
And all I have to do is think of it
Something in the listing will show me... 
I don't want to leave it now
I'll fix this tonight I vow!

The Evolution of a Programmer

[Ed. Note: This is original by Dennis Lou. Please leave this attribution intact if you forward it.]

High school/Jr. High

10 PRINT "HELLO WORLD"
20 END

First year in college

program Hello(input, output);
begin
writeln ('Hello world');
end

Senior year in college

(defun hello
(print
(cons 'HELLO (list 'WORLD))))

New professional

#include <stdio.h>
main (argc,argv)
int argc;
char **argv; {
printf ("Hello World!n");
}

Seasoned pro

#include <stream.h>

const int MAXLEN = 80;

class outstring;
class outstring {
private:

int size;
char str[MAXLEN];

public:
outstring() { size=0; }
~outstring() {size=0;}
void print();
void assign(char *chrs);
};
void outstring::print() {
int i;
for (i=0 ; i< size ; i++)
cout << str[i];
cout << "n";
}
void outstring::assign(char *chrs) {
int i;
for (i=0; chrs[i] != '0';i++)
str[i] = chrs[i];
size=i;
}

main (int argc, char **argv) {
outstring string;

string.assign("Hello World!");
string.print();
}

Manager

/* George, I need a program to output a string "Hello World!" */

Divine Computer Challenge

Jesus and Satan have an argument as to who is the better computer programmer. This goes on for a few hours until they agree to hold a contest with God as the judge.

They set themselves before their computers and begin. They type furiously for several hours, lines of code streaming up the screen.

Seconds before the end of the competition, a bolt of lightning strikes, taking out the electricity. Moments later, the power is restored, and God announces that the contest is over. He asks Satan to show what he has come up with.

Satan is visibly upset, and cries, "I have nothing! I lost it all when the power went out."

"Very well, then," says God, "let us see if Jesus fared any better."


Jesus enters a command, and the screen comes to life in vivid display, the voices of an angelic choir pour forth from the speakers.

Satan is astonished. He stutters, "But how?! I lost everything, yet Jesus' program is intact! How did he do it?"

God chuckles, "Jesus saves."

Levels of UNIX Expertise

Todd E Van Hoosear (vanhoose@lalaland.cl.msu.edu) Fri, 3 Feb 1995 19:56:38 -0500 (EST)


Levels of UNIX(R) expertise

BEGINNER: - insecure with the concept of a terminal - has yet to learn the basics of vi - has not figured out how to get a directory - still has trouble with typing RETURN after each line

NOVICE: - knows that ls will produce a directory - uses the screen editor but calls it "vie" - has heard of C but never used it - has had his first bad experience with rm - is wondering how to read his mail - wonders why the person next to him likes UNIX so much

USER: - uses vi and nroff but inexpertly - has heard of regular expressions but never seen one - has figured out that - precedes options - has attempted to write a C program and decided to stick with Pascal - is wondering how to move a directory - knows how to read his mail and wonders how to read news

KNOWLEDGEABLE USER: - uses nroff with no trouble and is learning tbl and eqn - uses grep to search for fixed strings - has figured out that mv will move directories - has learned that learn(1) doesn't help - somebody has shown him how to write C programs - once used sed to do some text substitution - thinks make is only for wimps

EXPERT: - uses sed when necessary - uses macro's in vi, uses ex when necessary - posts news at every possible opportunity - write C programs with vi and compiles with cc - has figured out what && and || are for - thinks that human history started with !h

HACKER: - uses sed and awk with comfort - uses undocumented features of vi - writes C code with cat >foo.c and compiles with !cc - uses adb because he doesn't trust source debuggers - can answer questions about the user environment - writes his own nroff macros to supplement standard ones - writes scripts for Bourne shell (/bin/sh) - knows how to install bug fixes

GURU: - writes m4 and lex with comfort - writes assembly code with cat >foo.s - uses adb on the kernel while system is loaded - customizes utilities by patching the source - reads device driver source with breakfast - can answer any unix question after a little thought - uses make for anything that requires two or more commands - has learned to breach security but no longer needs to

WIZARD: - writes device drivers with cat >foo.o - fixes bugs by patching the binaries - can answer any question before you ask - writes his own troff macro packages

- can answer any question before you ask - writes his own troff macro packages - is on first-name basis with Dennis, Bill, and Ken

--
       -Paul S. R. Chisholm, UUCP {ihnp4,cbosgd,pegasus,mtgzz}!lznv!psc
httpjoke - Internet E-Mail Computer Humor

ELEANOR RIGBY

Eleanor Rigby
Sits at the keyboard
And waits for a line on the screen
Lives in a dream
Waits for a signal
Finding some code
That will make the machine do some more. 
What is it for?
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long?
Guru MacKenzie
Typing the lines of a program 
that no one will run; 
Isn't it fun?
Look at him working,
Munching some chips as he waits 
for the code to compile; 
It takes a while...
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long?
Eleanor Rigby
Crashes the system and loses 
6 hours of work; 
Feels like a jerk.
Guru MacKenzie
Wiping the crumbs off the keys 
as he types in the code; 
Nothing will load.
All the lonely users, 
where do they all come from? 
All the lonely users, 
why does it take so long? 

Last modified: September 12, 2017