Become a fan of Slashdot on Facebook


Forgot your password?
Businesses Programming

Why Non-Coders Shouldn't Write Code 421

jfruh writes "Software firm FreeCause made a bit of a splash with a policy that requires all its employees — including marketers, finance, etc. — to write JavaScript code. And not just 'code to learn basics of what JavaScript can do,' but 'write code that will be used in production.' Phil Johnson, a tech writer and editor who himself once coded for a living, thinks this is nuts, a recipe for miserable workers and substandard code."
This discussion has been archived. No new comments can be posted.

Why Non-Coders Shouldn't Write Code

Comments Filter:
  • by Gripp ( 1969738 ) on Thursday September 20, 2012 @04:58PM (#41404489)
    You know, I almost wonder if anyone has ever sat on a phone conference and just parroted whatever comes up on that thing. I think with a typical non-technical tech PM talking to another non-technical tech PM (something I've actually seen a lot) this could actually fly. Would be at least fun to try!
  • by Chemisor ( 97276 ) on Thursday September 20, 2012 @05:14PM (#41404673)

    Every cook has to learn how to govern the state.
            - Vladimir Lenin

    In the early days of the Soviet Union it was a very popular idea that there should be no specialization in work. No man should have to do the same thing over and over every day of his life. Jobs should be changed regularly to keep the worker interested and motivated.

  • by mykepredko ( 40154 ) on Thursday September 20, 2012 @05:39PM (#41405007) Homepage

    Back in the '80s, IBM Canada gave a number of employees the chance to learn how to write code after being told that they didn't have any other skills that the company required. If you wanted to stay employed by IBM, you had to take a two year course which was actually quite substantial (covering assembly language, PL/1 (which was the language of choice at IBM back then), databases, and the usual IBM system stuff like JCL) and was administered by Ryerson (which was a polytechnic, not a University then).

    A surprising number of people graduated the course - I seem to remember that it was 80% or more - and went on a new career path coding in the Toronto Lab.

    So learning to program because your employer requires it is not necessarily a bad thing for both the company and the employee.


  • vanity (Score:5, Interesting)

    by spongman ( 182339 ) on Thursday September 20, 2012 @05:43PM (#41405047)

    this isn't about altruistically teaching others a valuable skill. it's about vain programmers trying to show their non-programmer colleagues how hard it is to code in order to get more respect. how much more condescending can you get? different people have aptitudes for different skills. go teach some dis-interested people how to do the rubic's cube, or something.

  • by theshowmecanuck ( 703852 ) on Thursday September 20, 2012 @05:56PM (#41405181) Journal

    About 20 years ago I worked at a chemical company. Almost all the junior engineers hired had to work out in production facilities for six months to a year, disigning and implementing the occasional needed improvement they discover. After that they were allowed to become office based engineers if they wanted, or stay in operations but move to real management. It worked very well.

    One time we had an electrical engineer who was trained to program Distributed Control Systems, and somehow he was never required to work in a production facility before that time. He built some attrocious logic into the system making it a pain to manage the smelter I was at. Things that should have been grouped for safety (i.e. you adjust a control, but the reading you needed to watch was on another screen) or just good functionality so the operators could focus on the situation in the plant and not switching screens all the time.

    When we complained he told us we were whiners and not capable. Since a few of us were actually closer to the operations manager in terms of grade, we had him forced to use his own software in production on a few weeks of midnight shifts. There was a noticable improvement in functionality before the 3 weeks were up. And even more in the months that followed. It is often very good to forcefully put people in someone else's shoes, since they will often say it, but not do it on their own (even metaphorically).

  • by theshowmecanuck ( 703852 ) on Thursday September 20, 2012 @06:31PM (#41405557) Journal

    In the late 90s I was at a software company that created circulation system software for the newspaper industry. We had a good number of system testers (pretty much all of them) who had never worked at a newspaper before. As one of the senior leads, on every project I worked on I made sure that a system tester went on site with me to sit with the various departments and help them understand/learn the new system (as opposed to just classroom teaching). This was a 'bonus' for the customer.

    My bosses were leery of not getting money for this extra training. But when they realized that the system test people improved by orders of magnitude because they actually understood implicitly what the features were for they started sending coders on site as well (to program in situ on projects). The quality of our system improved immensely, much quicker than otherwise would have happened.

  • by Anonymous Coward on Thursday September 20, 2012 @06:56PM (#41405745)

    "your pay scale does not, in any way, reflect what kind of person you are. One look into any boardroom in this nation is all one needs to know that most of the people who take home the lion's share are complete, abject pieces of shit."

    How did you manage to pull that off within a sentence?

    1) Your payscale doesn't reflect you
    2) Your payscale determines who is an abject piece of shit

    Truly you are amazingly mentally flexible.

  • by mykepredko ( 40154 ) on Thursday September 20, 2012 @10:18PM (#41407087) Homepage

    I was told that some kind of test was applied to determine aptitude and this was used to select the individuals for the program but...

    I tutored one our (former) secretaries as she went through the class and she had a devil of a time understanding that after a statement like:

            a = b;

    "b" wasn't 'empty' (ie she felt there was something physically moved from "b" into "a", leaving "b" empty). The idea that "b" would continue to have the same value after the value in the variable is stored somewhere else just didn't compute (if you can excuse the pun).

    She eventually got past this hurdle and made it through the course.

    So, maybe IBM knew something 25 years ago that seems to have been lost.


Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling