Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses The Almighty Buck IT Technology

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

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.
This discussion has been archived. No new comments can be posted.

Commentary On How To Make Novice Programmers More Professional

Comments Filter:
  • by Anonymous Coward

    How come we don't ask this question? Can we get rid of the layers of useless HR bureaucracy?

    • by VernonNemitz ( 581327 ) on Monday March 13, 2017 @09:35AM (#54028919) Journal
      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've heard it said, "Power corrupts. Absolute power corrupts absolutely. Petty power corrupts out of all proportion."

    • How come we don't ask this question? Can we get rid of the layers of useless HR bureaucracy?

      It's not asked much because the answer is no.

      Control in employment (and government) extends top down, not bottom up. Most places, if you even attempt it as bottom up, you're likely to be out on the street, starving.

      If you don't want to be a controlled resource, then you have three options.

      1: Strike out on your own. This is very hard, but it can be done. I did it and was successful at it. I retired reasonably early (i

    • by gweihir ( 88907 )

      Only with an UBI. Then we can have them argue with each other and the sane rest of us can ignore them. We should also do the same thing with the lawyers and the politicians. These people have a massively negative productivity.

  • by ruir ( 2709173 ) on Monday March 13, 2017 @09:11AM (#54028721)
    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: (Score:2, Interesting)

      by Anonymous Coward

      Yup.

      I'm always fascinated by the enormous scale of the disasters that young 'uns manage to create.

      They tend to want to create giant structures from toothpicks made of green wood.

      However, if you put them on small projects, with minimal impact, it can make it worth it.

      They may be cheap, but you get what you pay for.

      That said, lots and lots of folks feel they don't want to pay for quality and robustness. They would prefer to pay, for example, $1000 every two years for complete site redesigns by crappy Indian M

      • by Wraithlyn ( 133796 ) on Monday March 13, 2017 @06:50PM (#54033327)

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

    • The commentary has a major flaw. 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.

      Not only does it ignore the primary reason why companies often favor young workers, that omission causes the commentary to not touch on the the times when our industry values experience as much as any other.

      While I have seen a great deal of ageism in this industry, I have never seen it on projects when a project is really important to the company. When I work on a project where the C-level really cares about its success, they don't want young people in important roles on the project. I grew out a beard in m

  • How do you become a more professional programmer when your full time job isn't programming?

    I was a video game tester for six years, went back to school to get an A.S. degree in computer programming, and got into IT support because I enjoy the work. I program at home (Python and web development) and occasionally write PowerShell scripts at work, but the only time I deal with other programmers is when I'm cleaning up their messes over the network at work.

    BTW, Microsoft SharePoint IS NOT a proper bug tracking

  • Arrogance (Score:2, Funny)

    by Anonymous Coward

    I like how much of the comment was focused on arrogance, and then he broke out the Caltech means I'm smarter bullshit.

    • by Anonymous Coward

      Leaving out the entire "I'm told that I have no idea what I'm talking about despite having more experience than the critic has been alive" part and rephrasing it as if the speaker was the one being condescending is an excellent start on a strawman argument, but you need to make it less obvious that you're a arrogant millennial who instantly gets butthurt when someone with more experience calls you on your egotistical bullshit.

  • by sciengin ( 4278027 ) on Monday March 13, 2017 @09:18AM (#54028769)

    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.

    • What's "new and shiny" in CS? When I went back to community college to learn computer programming on a $3K tax credit that George W. signed into law after 9/11, I was trying to leverage six years as a black box tester to become a white box tester. That never happened since I got into IT support, enjoyed the work and never looked back. The only "new and shiny" thing I've gotten back then was Microsoft Visual Studio at academic pricing.

    • by slew ( 2918 )

      Also, what comes around, goes around.

      Fourty years ago computer science folks decided that they wouldn't be making a profession, but creating a job out of their hobby. Thus they created a job category with no credentialing, no apprenticing, no continuing education requirements, no board certification, so they continue with they hobby with the lowest set of requirements so they could change the world w/o having to deal with the "grown-ups".

      Now that hobby has become an industry and a certain amount of "pride"

    • by gweihir ( 88907 )

      Very much this. In fact, many inexperienced coders have negative productivity, because cleaning up after them is much more expensive then the value they generated.

  • by 0100010001010011 ( 652467 ) on Monday March 13, 2017 @09:24AM (#54028807)

    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.

    • by Anonymous Coward

      I did the same thing with an ASIC design group a while ago.

      In the end we agreed to let the processes (manual and automated) just run in parallel and after a couple of months it became obvious that the automated process was doing a good job catching the stupid little errors a lot faster. In fact after about 3 weeks the test team started only testing stuff that cleared hudson (hey I said a while ago)

    • I could replace 4-5 full time engineers with Jenkins and some continuous integration scripts...

      You may be able to do so, but it may not be wise, necessarily. For each, highly skilled engineer you get rid of, you also give up an amount of expertise, that will be expensive to replace, should you need it later. For example if the company needs to expand its business, change its product line or whatever; efficiency savings (just like outsourcing) often look better on paper than when you get to implementing them.

      If you want to introduce new methods and technologies, you have to sell the idea - not only to

    • by 0xdeadbeef ( 28836 ) on Monday March 13, 2017 @11:49AM (#54030033) Homepage Journal

      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.

      • automated unit tests. source control triggers

        And yet here I am in 2017 not using either of those things because they're scary and new in my industry. People sound no different than the article poster whining about how the "old way is more better" for a variety of reasons that mostly hinge on personal feelings.

    • by gweihir ( 88907 )

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

      Very, very, very rarely. And then it is often actually some older guy that has actually done it.

  • So true (Score:5, Insightful)

    by Aethedor ( 973725 ) on Monday March 13, 2017 @09:28AM (#54028855)

    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.

    • Amen.

      I don’t trust Wordpress and their ilk. Many moons ago, a static website I was maintaining suddenly had some strange PHP code at the beginning of each file.

      Turns out the server was compromised, and they changed every Wordpress site into a zombiebot. But since I did not use Wordpress, it was totally inert.

      I eventually was forced out by some cougar honcho with her pet autistic kid/programmer who only swore though CMS, despite my warnings of vulnerabilities

      It did not take 6 months to have their

    • by mrvan ( 973822 )

      Although I agree with you on the need to check out 3d party libraries before making your code dependent on it, it sounds like you might err on the side of rewriting. The biggest issue with code isn't writing it, it's maintaining it; and if a 3d party library is actively used and developed it means that in general someone else will be doing the maintenance, even if the codebase might not be the best ever. Writing and maintaining a new sockets/csv/oauth library is not what I want to spend my time on...

      • Agree. But when all you have is a library that is known for being crappy/unstable/vulnerable, what do you do? A young developer would simply use it, because he won't know it's crappy/unstable/vulnerable. An experience developer would deal with it, by 1) writing a good library himself, 2) use it anyway, while taking the right precautions or 3) find a total different approach. Knowing what you're doing is the difference between a young developer and an experienced developer.
    • Re:So true (Score:5, Insightful)

      by 0xdeadbeef ( 28836 ) on Monday March 13, 2017 @12:34PM (#54030447) Homepage Journal

      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.

      • we can fix the shit you write. Fixing someone else's shit you found on github is more expensive

        This is gold. I am totally stealing it.

  • by Anonymous Coward

    Yep, I've been coding for 40 years and have seen this argument come up over and over. Every set of 20 somethings pee on older coding methods and bang the drum for their 'new' way of software development and then when they get into their 30's they bitch about the the next 20 year old's peeing on their code. They should teach a class in college about it. There's only one thing worse than this. It's some 50 year old Architect who always trying to prove he's hip by jumping on every new thing that comes down

  • I agreed with the poster up until the last part, where he suggested that the "massive view controller" problem was a misunderstanding of what constitutes a "view" and a "model". I'd ask poster if he understands what constitutes a "controller" in the MVC model. And from that I surmise that who ever told him he didn't know what he was talking about was probably correct, at least in that particular instance.

    But that the poster didn't realize this, throws into doubt earlier things he said, which I agreed with

    • MVC is a particularly bad example, because the original Smalltalk MVC was very different from modern MVC libraries.

      While he might claim this problem was solved decades ago, it is just a fact that compile-time static analysis for dynamic memory allocation did not exist until recently, except in the form of "scope" as opposed to "lifetime", which, while similar, it is different from.

      Actually, it did since the '70s (and some of the theoretical work dates back to the '60s), it's just that it was regarded as computationally infeasible for most software until recently. Even then, it doesn't really handle covariant and contravariant types very well. The same is true of a lot of 'modern' compiler techniques: a lot of things are possible on dev machines with 16GB of RAM that se

    • I would say for instance that, while it didn't need to invent a new language to do it, "Rust" provides a good solution to dynamic memory allocation (namely, compile-time static analysis), that is different and in many ways better than garbage collection and automatic reference counting (ARC). While he might claim this problem was solved decades ago, it is just a fact that compile-time static analysis for dynamic memory allocation did not exist until recently, except in the form of "scope" as opposed to "lifetime", which, while similar, it is different from.

      Escape analysis and data flow analysis have existed for quite some time, and both are compile-time steps that can be used to substantially limit the amount of consing. There have also been linear types sometime around 1990. Lisp also allows for explicit dynamic extent declarations in case that everything else fails but the programmer knows what he's doing.

      • "Escape analysis and data flow analysis have existed for quite some time..."

        Okay, well neither of these things are built in compile-time static analysis of memory allocation to prevent memory leaks efficiently. So I'm not sure why you mention them.

        "Lisp allows for..." ...yeah, I'm going to stop you right there.

  • by sycodon ( 149926 ) on Monday March 13, 2017 @09:38AM (#54028947)

    Anyone who's been in the industry for more than a decide knows it.

  • by pipingguy ( 566974 ) on Monday March 13, 2017 @09:39AM (#54028953)
    Younger people are usually cheaper and easier to fool and push around. We've outsourced thinking, experience and knowledge to the machine. There's no going back. Welcome to the permanent "Leisure Class" except with no money. We're boned.
  • Maybe it is time to let go, retire and go repair motorcycles or support local communities by starting up a Hackerspace or something.

    I've been watching the development of AI recently, reflecting on all of the work we did in the 70s on Machine Intelligence and Perception, or in the 80s on Expert Systems, and ruing the day that all of that expertise was kind of lost; we seem to now be benefiting from the march of technology to provide huge resources for computation that are built into Brute Force solutions
  • A surprising amount of the resistance is plain fear: if you describe a solved problem in computer science, some number of the PHBs and some of the engineers will be frightened, and push back. Others will cover their ears and say "naa, naa, naa, can't hear that". After all, if they knew it was a solved problems and did the wrong thing, they could get in trouble!

    The frightened folks need to keep an eye on the news: I reccomend the morning paper [acolyer.org].

    The person proposing a known fix should do so either very early i

  • This sort of thing affects lots of different organizations not just the programming world. The arrogant newbie enters into an organization and immediately wants to change everything because in his/her eyes, until they came along the place was being run by a bunch of hick hayseeds. That's not to say that things can't be improved but one needs to spend some time observing, building relationships, and then making suggestions for improving things. One of the most appropriate lines from Beverly Hills Cop is w

  • Our industry seems to value "cowboys

    Yes. I have lost count of the number of times people have been praised and rewarded for fixing some "disaster" or outage. But without anybody ever asking how the problem occurred - frequently at the hands of the very same hero who then "saved" the company.

    There seems to be the view in upper management that problems just happen: like earthquakes and floods. There is usually so much relief when the lights come back on (metaphorically) that everything leading up to an outage gets forgotten or forgiven. I ev

    • About half the much lauded "firefighters" I ever worked with were awesome engineers whose opinions I completed trusted. The other half were proverbial chain smokers who left smoldering stubs everywhere they went. I have my doubts that management ever figured out the difference.
    • "Intellectuals solve problems, geniuses prevent them." -Einstein

  • by nbritton ( 823086 ) on Monday March 13, 2017 @10:08AM (#54029209)

    It's not because your obsolete, it's because you're too expensive. When I was young I was lucky to get $40k, now I can command six figures. It's because I have experience. If you want more professional programmers then pony up the cash for experienced professionals... you get what you pay for and there is no free lunch.

    If you are a senior professional, the important thing to remember is don't price yourself out of the market. For me, salary is usually the last thing I think about during the job hunt, I'm more interested in finding a role doing something that I enjoy and something that can benefit from my experience. As long as pay is within two standard deviations from the national average I'll seriously consider the offer. Also pay isn't everything, I prefer companies with a good benefits package and ones that are stable with a proven track record.

    • I learned early in my career that I don't want to work at companies that moan and whine about how much software staff costs. This extends to non-programmers as well. "Why should I pay for a professional QA person, when I can just pull someone off of the line and pay them peanuts?"

      I remember sitting in an IT staff meeting getting a lecture that we were lazy overpriced bums. "You are 20% of our staff, but make 50% of our wages!"

      Yeah, asshole, its because we have degrees (mostly 2 year, because they were cheap

      • I realized at that point that as a programmer, I do not want to work in IT ever again.

        Sounds like you worked in a small company. Corporate IT is a different ball game. The worse corporate IT I ever worked for had upper management insisting that the IT service provider deliver "double the performance for half the cost" as a requirement. The only way to meet that metric was to cut the staff in half and double the workload on everyone else. Last time I checked that company was on its fifth IT service provider, the IT staff was too small to support current operations, and everyone I knew ten yea

        • Yeah, it was fairly small.

          I once worked in a big software development division at a huge corporation and it was much like that. Employees are an expense not a resource, squeeze margins until they squeal. Hire contractors so they can be let go without any strings attached.

          When they moved on to offshore, I jumped ship... so to speak. I will not work for a company that does offshoring ever again.

  • As a member of the Obsolete generation, I have a "biased" view of what was stated. The industry is guilty of being Ageist, and Sexist. Also of being blind to history. Thus they repeat it. All the "new" innovations are based on reworked versions of past innovations. The Cowboys rule and they have always. Companies and schools have tried to impose standards, but fail because results count, not support ability. Batch job submission became RJE, RJE became RPC with a GUI, Time sharing became CIS, Citrix is tim
  • The core problem is not w/ engineers nor CEO-level executives: the real root problem here, as usual, is a failure of low-level management & hiring policies.
  • "Programming is not a field, it's a pop culture." -- Alan Kay, paraphrased
  • I didn't read the original article. I did read the summary which says absolutely nothing about "How To Make Novice Programmers More Professional." It seemed to be a whinge about how one seasoned developer felt disrespected by management. I don't see how that helps make novice programmers better in any way.

    Looking back on my development, a mentor was insistent that shortcuts often lead to delays and inefficiency later on. Do things right in the first place and move forward.

    I'm not sure that's relevant to thi

  • Sure. Anyone my age has seen the wheel reinvented several times because the minicomputer people were too arrogant to study what the mainframe people had done, and then the microcomputer people were too arrogant to study what the minicomputer people had done.

  • I'm in IT, and we have the same problems programmers have, to a slightly lesser degree. Experience is not valued the same way it is in other fields -- most people don't trust a doctor straight out of medical school more than they'd trust a mid-career specialist who's probably seen thousands of patients. The reverse seems true in development -- employers place enormous faith in fresh grads programming in Web Framework of the Month and discard people who've seen this stuff 20 times over because they're too ex

    • You basically have to know someone to get hired past 40 at some places.

      Or get a job in government IT. I'm the youngest at 47 in my department. Everyone else is in their 50's, 60's or 70's.

  • Like the difference between "bear" and "bare". Or maybe how to not keep the smart quotes from Word in the article so it doesn't barf on the screen under /.'s retarded lack of unicode.

    I don't see a lack of professionalism - just standard lack of experience and youthful hubris. And only more projects and time fix those.

  • Saying older programmers can't perform as well as younger ones is just HR-speak for "older programmers don't put in free overtime." You can't change HR.
  • I am strongly going on 50. The funny thing is, part of my work-time I code (mostly C these days) and for full consulting-rates at that, because what I code is apparently too difficult for the hot-shot cowboys. Of course, I also deliver useful documentation, analyze problems not caused by me, explain how web-technology works to "developers", explain different architectural, design and implementation options, do security analysis, etc. The very competent and helpful UNIX-guru on the customer-side is even 10 y

  • I agree, BUT... (Score:4, Insightful)

    by bradley13 ( 1118935 ) on Monday March 13, 2017 @03:43PM (#54032043) Homepage

    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...

  • I am in New Zealand and I have not seen age as an issue with the exception of pay expectations due to experience levels. I am 54 and no one asks if my knowledge is current, they just look at the work I have been doing recently. There is a shortage of skilled workers here so people are employed based on their skills/experience vs their pay expectations, age is not a consideration. My understanding is there is a skills shortage in the USA too so age bais seems counter productive. What about other countrie

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...