Commentary On How To Make Novice Programmers More Professional (slashdot.org)

Over the weekend, my colleague David ran a story that sought people's suggestion on how to make (force, encourage, advice) a novice programmer to be more professional. Several people have shared their insightful comment on the topic. One such comment, which has received an unusual support on not just Slashdot but elsewhere, is from William Woody, owner of Glenview Software (and who has previously worked as CTO at Cartifact, architect at AT&T Interactive). He writes: The problem is that our industry, unlike every other single industry except acting and modeling (and note neither are known for "intelligence") worship at the altar of youth. I don't know the number of people I've encountered who tell me that by being older, my experience is worthless since all the stuff I've learned has become obsolete. This, despite the fact that the dominant operating systems used in most systems is based on an operating system that is nearly 50 years old, the "new" features being added to many "modern" languages are really concepts from languages that are between 50 and 60 years old or older, and most of the concepts we bandy about as cutting edge were developed from 20 to 50 years ago. It also doesn't help that the youth whose accomplishments we worship usually get concepts wrong. I don't know the number of times I've seen someone claim code was refactored along some new-fangled "improvement" over an "outdated" design pattern who wrote objects that bear no resemblance to the pattern they claim to be following. And when I indicate that the "massive view controller" problem often represents a misunderstanding as to what constitutes a model and what constitutes a view, I'm told that I have no idea what I'm talking about -- despite having more experience than the critic has been alive, and despite graduating from Caltech -- meaning I'm probably not a complete idiot.) Our industry is rife with arrogance, and often the arrogance of the young and inexperienced. Our industry seems to value "cowboys" despite doing everything it can (with the management technique "flavor of the month") to stop "cowboys." Our industry is agist, sexist, one where the blind leads the blind, and seminal works attempting to understand the problem of development go ignored. You can read the full comment here or here.

Comments

The commentary has a major flaw

[ruir]

It does not comment the obvious, that industry love the young because they are cheaper, and have yet not learned to say no to crap.

Re:The commentary has a major flaw

[TheRaven64]

Experience is really not that rare, it is actually pretty much impossible to prevent getting more experienced

Old and experienced correlate, but they're not the same. Some people manage to spend decades repeating the same mistakes without learning from them. It's hard to gain experience without age, but it's surprisingly common to gain age without experience. This is also part of the reason some older folk find it hard to get hired: when you're young, ignorance and stupidity manifest similar symptoms and you can always hope that the person is simply ignorant and can be cured. When you're old, if you're still ignorant then the root cause is likely to be stupidity and so it's better to take a risk on someone younger (who is definitely ignorant, but might not be stupid). If you're old and competent, then you're far less likely to struggle to find employment.

Re:The commentary has a major flaw

[pla]

Maybe your amazingly robust website is not 2-3 times better, but only 1.2 times better and you should only be making a few dollars more than the 20 yo grad.

In programming, experience is worth drastically more than the pay differential for the same. A seasoned coder can crank out in a few hours what a recent college grad would literally spend a few weeks on; and it will be far more stable and maintainable.

Yes, I am conservatively some 50x more productive than my junior peers. A big part of that comes from knowing what to ask the customer up front, knowing what won't work, and knowing when to just build the damned birdhouse the customer requested rather than a 400 unit Gehry-inspired avian housing complex "just in case" the customer wants to upgrade in the future.

Re:The commentary has a major flaw

[Wraithlyn]

"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."

Dunning Kruger with employer approval

[sciengin]

In short its because idiots are too stupid to realize their own stupidity that experience is derided as outdatedness.
Of course a certain addiction to the "new and shiny" is probably what got many interested into CS in the first place, so it will be hard to get rid of that completely

This is then bolstered by employers knowing exactly that some 23 year old will work insane hours and is much more easily exploitable than a veteran.
Here comes the Dunning-Kruger effect on the employers side: They too are unable to realize that the code produced by a newbie can be orders of magnitude worse than that produced by a veteran. Sure the LoC per day look impressive but it is not at all a measure for productivity.

Re:tl;dr

[Anonymous Coward]

I got the same impression. It was his proper use of capital letters, commas, paragraphs, grammar in an essay that was logically constructed that shows his loss of faculties. Any one can do that with some effort. A younger person would have been able to forcefully make the same point with a concise tweet:
HAXXORS Sux!!! sjw ftw!

Some of it is obsolete.

[0100010001010011]

all the stuff I've learned has become obsolete

And as a mechanical engineer in my 30s I wish that some older engineers would accept that some of it is.

We trail behind software by some years, despite building software constantly. Every engineer I work with insists on building their own Simulink models. "Continuous Integration" is just some "new fad". Yet every so often we'll have builds break because they didn't run the build scripts in the right order.

I could replace 4-5 full time engineers with Jenkins and some continuous integration scripts building software, doing the dSpace hardware in the loop testing and e-mailing us the results.

Our process was literally:

1. Build software.
2. E-mail it to my lead
3. Lead forwards it to the testers
4. Testers manually flash the software
5. Testers manually unit test
6. Testers e-mail my lead with results
7. Lead e-mails me the result.

I had the whole process packed up into a Jenkinsfile and automated but most people thought it was some "new fad".

Accept that sometimes we come up with a way to do better.

Re:Some of it is obsolete.

[0xdeadbeef]

Accept that sometimes we come up with a way to do better.

Do you think a millennial invented automated unit tests? Do you think a millennial invented source control triggers?

That was old hat in 2003. The only reason it wasn't "continuous" integration is that build times could be on the order of hours.

So true

[Aethedor]

Too often I've heard that the way I develop my web applications is outdated. My 'old' but proven stable an secure approach is labeled 'obsolete', while the modern and 'cool' new techniques often cause stability and security issues. There seems to be an unspoken contest for many young developers to be the first to adopt new fancy technology. It's more about being cool than about delivering quality.

Also, many young developers use third-party libraries too easily. They don't look at the quality of that library, they only look at 'does it do what I want'. Too often, that results in a big mess of spaghetti code. Young developers are lazy, too lazy to determine the 'general approach' (don't know the right English term for it) for their software and they're not mature enough to stick to that. I a big fan of the Keep It Short & Simple (KISS) approach. The third-party libraries I use must also follow that approach. If I can't find the right library, I write it myself. Yes, that takes more time. But it will safe time in the end, because it will give me good control over my application. I won't allow a crappy third-party library to mess up my application. Ever.

Re:So true

[0xdeadbeef]

Also, many young developers use third-party libraries too easily.

This is probably my biggest pet-peeve about younger programmers.

It is a nice metric for measuring competence, though. Anyone who automatically trusts a black box assumes it is higher quality than anything they need to test. Anyone who uses third party code assumes it solves their problem faster, failure risk and debug cost included, than writing it themselves. The quality of the third party code someone chooses shows the upper bound of their own ability, and of their ability to perceive quality itself.

It can be used as a flanking maneuver to trick incompetent people into outing themselves. Critique their code directly, they puff up and make excuses. Criticize the third party shit they introduced into the build, and if they agree with you to appear wise and knowledgeable, the noose goes tight.

If only I could say this directly: we can fix the shit you write. Fixing someone else's shit you found on github is more expensive.

Re:How to make an employer more realistic?

[VernonNemitz]

It is possible that the employers are confusing arrogance for competence. Recently I had a somewhat generic insight into an old old adage, "Power corrupts" --and that insight came in two parts.
The first part is that "power" doesn't have to be political to be corruptive. Money is power, for example. Knowledge is power, for another (can include knowing "all" about computers).
The second part of the insight is that the first symptom of corruption is arrogance....

I agree, BUT...

[bradley13]

As a 50+ programmer, who has written lots of code in more languages than I can remember, I agree absolutely that experience counts for a lot.

Why am I not excited about that great new framework? Because it does the same thing that X did 2 years ago, Y did 5 years ago and Z did 10 years ago, and they were bloated crap too. Great steaming piles of half-tested code that introduce outside dependencies in our project that we cannot control.

Oh look, a new programming language. Everyone who ever enjoyed a compiler course has written their own programming language. Me too, whoopie. It's the libraries that come with the language that make it useful, not the syntactic sugar. It's the maturity of those libraries that make it stable and secure. I love playing with new languages, but I would never use a new language for anything important. WebAssembly? Ouch, please tell me they aren't serious, because I guarantee it will be used for productive websites far too soon. The articles about compatibility problems (websites depend now not only on your browser, but on your hardware), security breaches (sandboxed, riiiight), etc. almost write themselves, lacking only the specific details that we will hear all too soon.

On the process side: Agile programming? We called it iterative development 30 years ago. It has the same advantages and disadvantages that it always had. Scrum? Don't get me started. DevOps? Old hat with new buzzwords. If we keep changing our tools and processes every couple of years, it's no wonder we produce crappy products filled with bugs and security holes.

Chasing the new shiny is almost always a stupid idea if you are trying to produce a solid, reliable, secure system. Experienced programmers recognize crappy new ideas for the re-treads they usually are. Experienced programmers have probably built systems similar to what you need, and know how to do it. Experience counts for a lot.

BUT.

But, there is still competence. I have worked with "seasoned programmers" whose productivity was a net negative, because the rest of the team spent so much time cleaning up after them. Typically, these people have no idea how incapable they really are - they actually do view themselves as the seasoned, experienced programmer you just can't do without. Also typically, for whatever reason, you aren't allowed to remove them from your team.

And I have also seen young programmers produce some incredible stuff. Three of my bachelor students build a complete website, multilingual, including a custom CMS and custom rendering, along with most of an accompanying web-shop. For a customer with very specific requirements. In nine weeks. The code is still running today, 8 years later. The custom, multilingual CMS and the rendering system is rock-solid stable, running unchanged. Some of the code shows that they were only students - hard-coded constants and other sins - but overall it's better quality stuff than what 99% of the "seasoned" programmers could produce, much less in such a short time.

So, yes: experience counts, but so does skill. And the two are not always correlated...