Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Education Programming

Ask Slashdot: How Do You Make Novice Programmers More Professional? 347

Slashdot reader peetm describes himself as a software engineer, programmer, lecturer, and old man. But how can he teach the next generation how to code more professionally? I have to put together a three-hour (maximum) workshop for novice programmers -- people with mostly no formal training and who are probably flying by the seat of their pants (and quite possibly dangerous in doing so). I want to encourage them to think more as a professional developer would. Ideally, I want to give them some sort of practicals to do to articulate and demonstrate this, rather than just "present" stuff on best practices... If you were putting this together, what would you say and include?
This raises the question of not only what you'd teach -- whether it's variable naming, modular programming, test-driven development, or the importance of commenting -- but also how you'd teach it. So leave your best answers in the comments. How do you make novice programmers more professional?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Do You Make Novice Programmers More Professional?

Comments Filter:
  • Very simple (Score:5, Funny)

    by Anonymous Coward on Saturday March 11, 2017 @10:42PM (#54020773)

    Let them accumulate experience and wisdom, and when they achieve it then tell them they're too old to work in this field.

    • Time for carousel. Renew! Renew! Renew!
    • They only have three hours in which to do this.

      Personally, I'd suggest beating them over the heads with printed copies of man pages whilst trying to emphasize the importance of commenting their goddammed code.

      But that's just me.

      • by Rei ( 128717 )

        I'd rather teach them to keep their functions short and their function titles descriptive, so that the code comments itself. Nothing annoys me more than comments like:

        for (i = 0; i < 3; i++) // Loop three times
        {
              some_fn();
        }

        Comments should be about why, not what. What should be easily visible in your code on its own.

        • "Comments should be about why, not what. What should be easily visible in your code on its own."

          Think of it as comments needing to be one level above the code. Function and section header descriptions should be two levels above.

      • They only have three hours in which to do this.

        Personally, I'd suggest beating them over the heads with printed copies of man pages whilst trying to emphasize the importance of commenting their goddammed code.

        But that's just me.

        If code needs comments your probably doing it wrong. Code should instead be broken down into small units with meaningful method names and tests.

        There are certain edge cases where you need to include a comment because you might be doing something strange then the comment can explain why you doing, for the most part though the code should be easy to follow just by reading through the method names.

        Oh, and while we are on the subject, as soon as you use And in a method name really try and split it into two sepe

        • Breaking code into small units results in excessive call / return pairs and consequent poor performance.

          Replacing comments with descriptive method names causes hard-to-read long lines.
          Comments have several audiences, including the original programmer, people familiar with the project who have to support or modify the code, and complete strangers who have to figure out what everything does. Descriptive names alone don't do the job, and having to read tests to understand the code means having to double the n

  • by Registered Coward v2 ( 447531 ) on Saturday March 11, 2017 @10:42PM (#54020775)
    In 3 hours you will be able to cover 5 or 6 things in enough detail to really explain them so you need to focus on what you think it i critical for a novice to know. I would start with identifying hat would you have liked to have known when you started out, then list the critical error you see novices make consistently, and then identify any critical skills a novice needs to have. Once you have that list, pick the 5 or 6 you think are the most valuable and over them.
    • by ShanghaiBill ( 739463 ) on Saturday March 11, 2017 @11:04PM (#54020841)

      My company hires many young non-degreed self-taught programmers (because that is all we can find). We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time. The books include "Clean Code", "Programming Pearls", "The Pragmatic Programmer", several books on algorithms, code complexity, and books on software engineering such as "The Mythical Man-Month" and "Joel on Software". A lot of it is stuff that they would have learned if they had a CS degree. They can substitute books of their own choosing with pre-approval.

      Many of these younglings have matured into great programmers. I hired one guy while he was a junior in high school. He worked for several years, and then decided to go to college, and ended up getting a PhD from Stanford.

      • by phantomfive ( 622387 ) on Saturday March 11, 2017 @11:16PM (#54020899) Journal

        . We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time. The books include "Clean Code", "Programming Pearls", "The Pragmatic Programmer", several books on algorithms, code complexity, and books on software engineering such as "The Mythical Man-Month" and "Joel on Software".

        So, question........how do you ensure that they actually read them?

        • The reading list is obviously chosen from a select set of things that outline skills they're expected to know to do their jobs. If you're someone who has already read these books and understood them then it's pretty easy to see who finished and understood the reading assignments just by reviewing their code.

        • by ShanghaiBill ( 739463 ) on Sunday March 12, 2017 @01:42AM (#54021297)

          So, question........how do you ensure that they actually read them?

          I ask them what they thought of the book, what they learned from it, and what questions they have that the book didn't answer.

          These are self-taught people that passed a rigorous interview process consisting mostly of coding. They want to learn. I have never caught any of them faking their professional development.

          • These are self-taught people that passed a rigorous interview process consisting mostly of coding. They want to learn.

            Good point.

        • If they say the book was good, they didn't actually read it.

          Okay, I only read one of those books and while it was informative I didn't like it.

      • by bill_mcgonigle ( 4333 ) * on Saturday March 11, 2017 @11:48PM (#54020991) Homepage Journal

        because that is all we can find

        Is there an implicit "for cheap" at the end there? Because lots of old guys are frequently bellyaching here about how after age 40/50 they can't get any work (and one presumes they know the ropes by then).

        • Re: (Score:3, Interesting)

          Is there an implicit "for cheap" at the end there?

          No. When we make an offer, it is almost never rejected as being "too low". In fact, it is seldom rejected at all. We just don't get enough qualified applicants (CS degrees AND actually able to write code (the first does not imply the second)). This is in San Jose, California.

          Because lots of old guys are frequently bellyaching here about how after age 40/50 they can't get any work

          By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-worker

          • Re: (Score:2, Interesting)

            by Anonymous Coward

            By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-workers are glad to be rid of them. There are a LOT of people like that out there. These are the guys you remember from college who wanted to copy your assignment an hour before it was due, because they had no idea how to do it themselves, the dead weight on your programming team, and now they are old.

            Condescending asshole, you're forgetting about the entire generation of socially awkward nerds whose childhood coincided with the personal computer revolution, who grew up interacting with machines instead of people, who never learned social skills, and who never accumulated a professional network because they'd rather not interact with people like you. Those were the technically inclined kids who were doing all your programming assignments while you dead weight bastard cheated your way through college. T

            • by JaredOfEuropa ( 526365 ) on Sunday March 12, 2017 @06:25AM (#54021845) Journal
              While I don't endorse the tone, I do agree somewhat with the sentiment of this. Depending on your field and your location, it can be very hard to find a job as a 45+ year old professional, and not just in IT: there's a few other professions which are not in hot demand right now, with a lot of older experienced people looking for jobs. It may be somewhat true that people with extensive professional networks always get hired, but that certainly doesn't equate to "the good ones will always find work", and by extension "it's your own fault if you can't find any work"

              until social scum like you forced the socially awkward out of the industry which they built for you

              I'd say that the industry has evolved beyond the basement dwelling coder; social skills are more important in IT these days, and the industry is better for it. But now that there are fewer job openings, employers get to be more picky, and they don't always select on the right criteria. A strong emphasis on social skills where they aren't needed, for example. Or just hiring the most likable of qualifying candidates. Add to that the widespread notion that programming is a young man's game, that good programmers always move on to do other stuff at some point, that you're a loser dinosaur if you're still coding past your 30s. I recently had a chat with some ex-colleagues about hiring practices, and I got the impression that their companies are looking for people who are either college graduates, or experienced programmers who at the very least have developed and launched a wildly successful new OS or social media service. But a middle aged coder who is "merely" very good is suspect: why isn't he an architect or a project manager?

              • by LesFerg ( 452838 )

                But a middle aged coder who is "merely" very good is suspect: why isn't he an architect or a project manager?

                For me, I started out in small companies where I was doing a bit of everything, so the title didn't include architect etc, but I had projects that were challenging and fun, and I just got in there and did them. Later on when I started looking round for another job, I had piss all to prove what I had done or what I knew, and had a bunch of young quiz masters trying determine if I knew something, but I couldn't tell what it was they were looking for, it certainly didn't relate to the decades of experience I

            • by LesFerg ( 452838 )

              By the time someone is 40-50, they should have a broad skillset, and a deep network of former colleagues. The old guys whining about being unable to find a job are mostly turds that have serially rejected and their former co-workers are glad to be rid of them. There are a LOT of people like that out there. These are the guys you remember from college who wanted to copy your assignment an hour before it was due, because they had no idea how to do it themselves, the dead weight on your programming team, and now they are old.

              Condescending asshole, you're forgetting about the entire generation of socially awkward nerds whose childhood coincided with the personal computer revolution, who grew up interacting with machines instead of people, who never learned social skills, and who never accumulated a professional network because they'd rather not interact with people like you. Those were the technically inclined kids who were doing all your programming assignments while you dead weight bastard cheated your way through college. Those nerd kids grew up, and they're literally 40-year-old virgins now. Until recently they were able to make a decent living using only their technical skills, until social scum like you forced the socially awkward out of the industry which they built for you.

              I agree with most of that, tho also I have the problem that most of my network of former colleagues have retired or died. Guess I could have moved on to managing other developers but I didn't enjoy that, and stuck with doing what does give me reward.

          • by johannesg ( 664142 ) on Sunday March 12, 2017 @03:22AM (#54021479)

            Project Euler is a test of math skills, not programming skills. The two are often conflated, but in reality overlap only rarely. In many branches of programming you can function very well while knowing nothing more than what +, -, *, and / do.

            Moreover, the problems are arranged in chains that lead up from basic understanding to advanced understanding. Simply dumping one at random into the lap of an unprepared person is very likely to weed out all the excellent programmers, leaving only math students - who I'm guessing aren't responding to your ads to begin with. So that's your problem right there: you ask for one skillset, and then you are surprised that your test for another skillset isn't working out. It isn't the quality of your candidates. It's you.

            If this wasn't clear enough: I've been programming since the eighties, I have my masters degree, and somehow they trust the software I write controlling (which literally means "deciding life and death of") spacecraft costing 300 million euro and up. If I ever fuck up I guarantee you _will_ read about it here on slashdot. Yet somehow I have _never_ needed to determine if a number is prime, or indeed any of the other circus tricks at Project Euler.

            • Project Euler is a test of math skills, not programming skills.

              Junior high school math. I haven't seen any that require any trig or calculus. My daughter is in 9th grade, and has taken algebra and geometry, and learned Python last year. She hasn't had any trouble with the first 100 problems.

              I agree that they require little programming skill. That is why they are a good test of minimal ability.

              Here is a sample problem:

              A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 × 99.
              Find the lar

              • Questions not relevant to the actual job done are not a good indicator of future success. These types of questions are great for recent students or people who enjoy riddles problems though. There is a whole field of study about learning and testing. There has been numerous studies done showing that these types of things don't correlate. Interviewers use them because they are a cheap and fast way to weed people out.

                Colleges should add a pedagogy classes to help interviewers understand how to test people more

            • "spacecraft costing 300 million euro and up. If I ever fuck up I guarantee you _will_ read about it here on slashdot. "

              And if your EUR 300M spacecraft reaches its goal, and accomplishes wondrous things there, but you happen to be wearing the wrong shirt at the press conference, you will be hearing from Huffington Post forever.

            • I checked out that Euler site to see what type of problems there were and I'd like to see the average 14 year using tricks to solve geometric progressions and such, which was clearly something that was necessary on the first random problem I looked at.
      • by Ichijo ( 607641 )

        My company hires many young non-degreed self-taught programmers (because that is all we can find).

        Let me guess. You only try to hire people who are looking for a job. Am I right?

      • by RevDisk ( 740008 )
        Could we get a full list of those books?
        • by ShanghaiBill ( 739463 ) on Sunday March 12, 2017 @02:19AM (#54021379)

          Could we get a full list of those books?

          This is the list I currently use. I welcome additional recommendations. What CS books have you read recently that you really wished you had read 10 years ago?

          Programming:
          Clean Code
          Code Complete
          Programming Pearls
          The Pragmatic Programmer
          Regular Expressions
          Algorithms by Robert Sedgewick
          Introduction to Algorithms by Tom Cormen
          Hacker's Delight by Henry Warren

          Interface design:
          Don't Make Me Think
          The Design of Everyday Things
          Microinteractions

          Software Engineering:
          The Mythical Man-Month
          Joel on Software
          Test Driven Development

          Theory:
          The Turing Omnibus
          Deep Learning, by Goodfellow, Bengio, Courville
          Concrete Mathematics by Donald Knuth
          Physics for Game Developers
          Computability, Complexity, and Languages

          • Great list! However you missed the one quintessential CS book.

            Godel, Escher, Bach: An Eternal Golden Braid [amazon.com]

            --
            It's 2017, and /. STILL can't properly display Unicode?! GÃdel *sigh*

            • Great list! However you missed the one quintessential CS book.

              Godel, Escher, Bach: An Eternal Golden Braid [amazon.com]

              Actually, I didn't miss it. GEB used to be on my list. But I removed it. To really appreciate the book, you need to already have a foundational knowledge of completeness, recursion, complexity, emergent phenomena, etc. But it isn't such a good book for learning those topics in the first place. Non-tech people can enjoy reading the book while not even realizing how much is whoosing over their head.

          • I've read a fair few of those books; this is a great list for self-taught programmers, and I certainly include myself in that category

            But one thing I often find lacking in both amateur programmers and coders with a formal education is the skills to do OO properly. These days most of them know the basics: class vs instance, abstract classes, inheritance and overloading etc, but what's missing is the knowledge and skill to design a good object model. In an OOP course I did years ago, students were given t
            • by Bongo ( 13261 )

              I gather the notion of design patterns came from an architect (buildings) who visited Italian towns to try to find out why they "worked". In other words, he was trying to learn from established experience. And the film director Ridley Scott said that the voice of experience is what he calls intuition. In a way it is the opposite of math puzzles. It's having enough experience in organising things that you start to intuitively foresee that some arrangements will turn out more simple and elegant and maintainab

          • I would add: The Power of Habit: Why We Do What We Do in Life and Business. This gets you started thinking about why people do things a certain way, and if you do interface design you should think about how your interface will be used and what triggers actions.
      • Out of (not so idle) curiosity, what is the complete list?
      • My company hires many young non-degreed self-taught programmers (because that is all we can find). We give them a reading list, and require them to spend about four hours per week doing professional reading and studying on their own time.

        While your approach has merit it would seem your company is setting itself up for a lawsuit over unpaid wages, unless the new hires are truly exempt employees.

      • Just having a suggested reading list sounds amazing to me! I've unfortunately never worked for a company I thought put continuous effort into training their employees to be more effective. It seems like the only employee benefit I've never had from a job... Are you hiring now?

        I'm self taught but went back to school after a ten year absence and got my CS degree. I recently left my current employer because they were too willing to hire under-qualified candidates (myself included) without having a good support

      • by shmlco ( 594907 )

        I take exception to the expectation that they're supposed to complete a company assignment on their own time. Where I work now they tend to run a "book club" where once a week the current group gets together and discusses the latest chapter or so, asks or answers question, and a moderator/mentor is often present to explain why we do what was discussed.

        (Or why, after consideration, we decided NOT to do that...)

  • by Anonymous Coward

    Find some good source code for them to study

    • by Z00L00K ( 682162 )

      Then give them a part to work on and tell them to break it down into pieces no larger than about 40 to 50 rows, let them also write code that tests their code so that they can explain what each piece do.

      Today the tools for maintaining code are a lot better than what many of us suffered in the 80's. If we were lucky it was 'vi', not 'vim'. Or on other platforms like OpenVMS it was "EDIT /EDT". A few here may remember EDLIN from DOS. Then realize that in the beginning programmers coded on punch cards that had

      • Darn the person who dropped the box of cards and had to sort them out in the right order.
        For thar you have a card sorter, later computers sorted the cards first anyway, and depending on your punch card system, you can easily sort them with a knitting needle.

  • Poor (Score:5, Insightful)

    by Anrego ( 830717 ) * on Saturday March 11, 2017 @10:47PM (#54020791)

    Ideally, I want to give them some sort of practicals to do to articulate and demonstrate this, rather than just "present" stuff on best practices...

    This raises the question of not only what you'd teach -- whether it's variable naming, modular programming, test-driven development, or the importance of commenting -- but also how you'd teach it.

    I think this is already going down the wrong path. Those are just technical skills and practices that will be picked up over time, and some kind of workshop isn't really the place to learn them imo.

    The important differences between a new guy and someone with a decent bit of professional experience under their belt isn't so much in technical skills or adherence to best practices, but it's more of a mindset and general direction thing. Once you've seen a few projects from start to completion, you start to recognize certain patterns and points where things can go really well or really bad. Once you've worked on a bunch of different teams, you start to recognize how different people contribute to a team dynamic and the various ways in which a team functions. You start to understand how your job integrates with the rest of our department and the rest of the business, how the whole management structure works, and what really drives most technical decisions (hint: technical merit is often the last thing driving a decision).

    The problem is, you can't really teach that. So I guess my answer would really be very generic "how to be a good employee" type stuff: Take ownership of your problems, check your ego, play well with others, etc. Being a more professional programmer has little imo to do with being a better programmer and more to do with being a better professional. You become a more professional programmer by learning how to have a productive meeting with management about your project, not by learning the magic of continuous integration.

    • I think the question is more like: What rubber chickens do I throw at the new people to make the snobby people feel better about letting in the barbarians?

    • What I want is the experienced programmers to actually act like experienced programmers! Too many self taught people with EE or physics background with absolutely atrocious coding skills, no concept of algorithms, and an attitude that quick and dirty is the proper way to do things. I can't believe how some people manage to get an advanced degree without possessing any analytical skills.

      At least novices can be trained.

      • by Anrego ( 830717 ) *

        I think this partly falls on the people leading a technical project. Yes, programmers should take initiative to produce the best code they can, and many do, but people have a tendency to the path of least resistance, and even when they are legitimately trying, they may lack the experience to intuitively know that what they are producing is sub-par.

        Good technical leadership sets _and enforces_ standards. This should happen at every level, with the quality of the standards increasing as the experience of the

        • Some of these people ARE the leaders. They become leaders because they have work experience, or because because they've been at the company the longest, or because they're the only person working on a key piece of the project that no one else knows. (ie, someone understands radio so they get put in charge of doing the radio code, or they were the person who wrote all the unintelligible code back when the company was a startup and now they're senior lead in charge of screwing it up)

          • by Anrego ( 830717 ) *

            These are management problems and are way deeper than programmers producing shitty code. Unfortunately they arn't that uncommon.

    • by AmiMoJo ( 196126 )

      The most important thing is to make them realise that there are techniques and patterns to learn and that they are what separate the professionals from the amateurs.

      To that end some introductory stuff about things like variable naming and code organisation could be really helpful. Give them a starting point and enough to see the value in studying it further.

  • Start with some practical code/app samples that demonstrate clear trouble. Ask them to participate -- see if they can solve the trouble. Then show how the original dev got themselves into that trouble, and the "professional" thing you would have applied to avoid it.

    Bonus points for going comedic with examples that are ridiculous to the extreme [destroyallsoftware.com].

    • Re:Invert it (Score:5, Insightful)

      by kbrannen ( 581293 ) on Sunday March 12, 2017 @01:23AM (#54021247)
      I agree on the examples and discussion around them.

      I taught a class for some new programmers fairly recently out of school. They knew PHP and a few other languages, so they could do basic coding. However, we needed them to know Perl and our app.

      I taught 5 classes of 1 hour each, 2 every week. There was about 20 minutes of lecture up front to explain ideas beyond the basics, and they were encouraged to ask questions during that. I also gave them a problem to solve at end of the lessons to complete for next time. The homework at the beginning was solvable in 10-20 lines; the ones at the end took nearly 50 lines. The last ~40 minutes of a session was spent going over the homework and discussing it. Each person presented their answer for everyone to look at and were asked what they found hard to do and why and we talked about solutions with emphasis on the why.

      Part of the reason it worked well was because I stressed there was not 1 definitive answer, not even mine ... a working program (without bugs :) was the goal -- however they got there (rule 1). Negative criticism wasn't allowed -- only constructive criticism (rule 2) -- and thankfully there were no issues with this. My usual teaching phrase was to say "a better way to have done the same thing was ___ because ___", and to remind them that in the end we paid them to write working code.

      The discussion of the homework allowed them to see how others did it, I also showed my answer though I always went last. We also talked about ways to do it better with a large emphasis on why something was better, trade-offs, etc. I also did my best to point them in the direction of good habits: comments, testing, modularization, maintainability, etc. I also mentioned useful books, most of which have been mentioned by others.

      If I ever had to teach something like this again, I believe I'd do it the same way. All of the class members gave me good feedback and said they liked the format.
  • by djbckr ( 673156 ) on Saturday March 11, 2017 @10:55PM (#54020815)
    Make them read at least some of these books [codinghorror.com].
  • by phantomfive ( 622387 ) on Saturday March 11, 2017 @11:00PM (#54020827) Journal
    If they are new programmers, probably they need more than just programming skill, they need skill acting like a professional. The Clean Coder [amazon.com] does a really good job with that.
    For programming skill, I'm going to suggest Zero Bugs and Program Faster [amazon.com]. That book tries to change the way people think about code.

    On the practical side, there's no substitute for looking at good code. Assuming you're a good programmer, this would mean code review is one method. Have him review your code and find mistakes. He'll think he's trying to catch you, but he'll learn a lot doing it. Then you can review his code, too.

    Another good mentoring technique is unit tests. They show you the kinds of things the programmer is thinking about when they test. So you can look over the tests in code review and say, "hey, you forgot to test this aspect." Ideally you'll want him/her to be thinking of every possible test case, even if he/she doesn't actually write out the test.

    Another thing is to treat the younger person with respect. Sometimes if you say, "Oh you did that wrong" they will automatically assume, "he hates me" and put themselves in an adversarial stance, which is not helpful for anyone. Look for things that they do that you really respect, and point them out.
    • Most coders will read more than they write, especially if they forget their own code.

      I learned a lot from MESS/MAME code, and I do almost 0 C today. But I remember how to write. Write, read someone else, and give feedback.

      Clever one liners are neat, but almost always compile the same as using intermediate variables. One is easier to read and debug.

    • by david_bonn ( 259998 ) <davidbonn@NOSpam.mac.com> on Saturday March 11, 2017 @11:35PM (#54020955) Homepage Journal

      Positive examples are good. So are negative ones. I'd recommend giving a novice ownership of a large, ugly, very messy, but heavily used hunk of software and have them "clean it up". The ones that don't kill themselves will become professional programmers.

    • > For programming skill, I'm going to suggest Zero Bugs and Program Faster

      I second that, good book. Specifically it's a collection of good ideas, each of which takes about ten minutes to read. Zero Bugs and Program Faster would be an excellent choice if you want to spend just a few minutes each day, to have continuous slow improvement. It was my bathroom reading for a while and it was perfect for that.

      (If you assembled the top 50 best forum posts related to creating robust software, you'd end up with s

      • >> For programming skill, I'm going to suggest Zero Bugs and Program Faster
        > I second that, good book.

        I'll third that book. Great book !

  • What worked for me (Score:4, Insightful)

    by Snotnose ( 212196 ) on Saturday March 11, 2017 @11:05PM (#54020845)
    No college degree, self taught Z80 assembler. Long story short, marketing found out I wrote space invaders for an 8080 based 1553 bus protocol analyzer. Took it to trade shows. Management found out, took me from tech to engineer. As an engineer I wrote code for various hardware. The rule was, when a bug came in you had to fix it. No matter how long ago it was, you owned it.

    Quickly learned how to write good code that I could understand a year after release.
  • by SlithyMagister ( 822218 ) on Saturday March 11, 2017 @11:21PM (#54020911)
    Professionalism is some mixture of attitude and effort.
    If a programmer has a willing attitude, and puts in a good effort, the competence will come with time.

    No matter how competent, a programmer whose attitude is lacking, or whose effort is lacking will hinder whatever project they're a part of.

    As for building competence, I really liked "Code Complete"
    • by meburke ( 736645 )

      I would have brought up the distinction between "professional" and "competent" but someone beat me to it.

      However, neither of these labels have a specific meaning. How do you know if a programmer is "competent"? It is easier to tell if a programmer is incompetent, but the line between the two states is fuzzy, particularly since the competency criteria depend on context such as specific languages, specific hardware, and purpose of the software. An assembly language programmer may be perfectly competent or eve

  • Explain to them why they should use tabs for indentation and spaces for alignment?
  • Look at how the best private schools educate the best students.
    Good hardware, good software, great teachers, a good environment to learn, help with computer tasks that build on many years of quality math and science education.
    Private schools build on math, art, CS classes over years. The student is then full prepared for quality private higher education.
    Once graduated such people are fully ready for the work force and have the connections to find work they enjoy.
    Thats years of quality math and science
  • by ruir ( 2709173 ) on Saturday March 11, 2017 @11:47PM (#54020985)
    Next article, how can I make a baby walk like an adult
    How about paying proper experienced people, and put them orienting your newbies?
    • More like trying to make a monkey walk like a human. Education is overrated. There are lots of dummies who get degrees, especially bachelors degrees. Find an intelligent person and they can learn whatever they need in a matter of days or weeks. Writing good code isn't really that hard. It's just machine building--an exercise in simple logic. Be smart enough to recognize other smart people to hire. Unfortunately this requires that you are intelligent yourself. Intelligence and a willingness to work hard are

      • by ruir ( 2709173 )
        Whilst I agree with you in the degree part, and recruiters doing the wrong questions, proof of formal training and especially experience is not so underrated.
        Money is also a problem. As in the OP, they recruit unexperienced people because they do not want to pay a fair ongoing market rate.
        People are also there a couple of years in that sweat shops and then move on to greener pastures.
        Writing code is not really that hard, writing good code is hard. It has to be simple logic hardwired to people with good
  • First, read this: http://kotaku.com/5975610/the-... [kotaku.com]
    That is an analysis of the coding style used in the Doom 3 source code

    Next, read this: ftp://ftp.idsoftware.com/idstu... [idsoftware.com]
    It is linked within the first article, but it is important enough to directly reference. It is id Software's official programming guidelines. Seriously, just having clean, clear, consistent guidelines for source code makes a world of difference in quality.

    The very first thing to teach young'ns is this:
    "Programs must be written for people t

  • Accept that this isn't a single tutorial, but a continuous process of teaching and learning. And failing! Here's some tips I recommend:
    1. Don't dump every best practice you can on them at once.
    2. As you see individuals demonstrate these skills, have them present it to the group.
    3. Use code reviews so that they are motivated to catch each others mistakes during reviews, then are motivated to not make those mistakes themselves.
    4. Have senior members of the team demonstrate these practices and participate in

  • by gravewax ( 4772409 ) on Sunday March 12, 2017 @02:27AM (#54021397)
    Coding standards documentation, Peer review of their code and gated checkins. They either learn to be more professional or they quickly are identified as someone you don't want and you do that as an educational experience, it is ok to make a mistakes as long as you aren't repeatedly making the same ones.
  • by LostMyBeaver ( 1226054 ) on Sunday March 12, 2017 @03:08AM (#54021461)
    I've been a developer since I was a child. I became a software engineer after education. I have been a senior developer on at least 3 projects that have impacted a billion or more people for 5-10 years and have a list of "inventions" to my name that is quite long.

    I am not properly educated. I couldn't afford to attend the university in America, so instead, I latched on to the head of science and engineering at a major university and traded work for books etc... but I received no paper. I was forced to know every book verbatim at all times for years because in order to work in generally Ph.D. level positions and be taken seriously, I had to be a walking reference at all times. It was a bumpy road, and I got my scars, but I made it.

    I become a structure zealot. I became absolutely obsessed with Big-O, data structures in general, design patterns, etc... I rarely if ever wrote a piece of code without obsessing over its design extensively before doing it. I learned that all the best programming started on the backs of napkins at coffee shops. A local coffee shop even let me and a colleague use white board markers on their windows for an hour or two each day because we were costing them a fortune in napkins they said. We often had an audience, less professional developers wanting to learn how to plan and employ complex things.

    Together my colleague and I reinvented methods of programming such as methods of decoding images using a push pipeline rather than simply a FIFO by designing state machines similar to VHDL coding that would decode and display pixel by pixel of an image (jpeg, png, gif) as soon as the data was available. We designed new methods of compiling lex and yacc grammars that would dispense of tables and handle contexts while also processing data as it arrives based on state machines and make corrections if new data changes the meaning of older data. We wrote memory allocators, just-in-time compilers (back before they were properly named).

    None of these tasks could have been accomplished without
    1) Education
    2) Reading to further education
    3) A thorough understanding of computers (we were both demo coders when that meant something)
    4) Math
    5) Patience
    6) Respect for each other instead of competition.

    Now, I've gotten old and I decided I liked money a lot, so I left my job as a programmer after nearly 20 years and moved onto being an network instructor. First of all, networking people are all very similar to informally trained programmers. They're typically more talk and less real knowledge. They spout off things they don't fully understand and they often find them to be mysterious and amazing. They learn a new acronym like HSM and even learn it means Hierarchical State Machine and before you know it, your code is littered with chaotic amounts of junk because every problem they try to solve, they employ their new toy to solve. Sadly, it's not magical and they make coding changes that will permanently impede your ability to work professionally since training new programmers on the project will now take 3 times as long.

    Let's start with a few bullet points :

    1) New languages can bring new methods, but new languages come and go
    PERL, PHP, Ruby, Python, what's next?
    Due to children making decisions all the time, there are companies with millions of likes of bad PERL, PHP, Ruby and Python code out there. Each time there's a new "hot language" we end up rewriting absolutely everything over and over and get it wrong over and over. Those languages are great for some reasons, but while I use Python once in a while, I generally limit how much I use it since I expect support to slowly taper off within 3-5 years. I may be wrong, but it's a "language of the week" and I don't believe in investing in languages of the week.

    2) Communication is the absolutely most important thing
    Algorithms, Desi
  • Send them on a Computer Science degree course.
    Its clueless to think that programming to a professional level is something you can learn in a few hours. ... or maybe you're one of those people that would be happy if your surgeon turns out to actually be a plumber that just felt like having a go at surgery after watching a youtube video.

  • Say what you will about it, I've found pair programming a strong Sr. level developer with a junior one of the fastest way to improve the junior's skills.
  • Stuff like "Code Complete", that don't explain how to write code, but how to write code so it's readable, understandable, debuggable and maintainable.
  • Demonstrate the value of good practice. The difference between inexperience and experience is the experienced have made the mistakes and seen the consequences of other mistakes. The point of all those software approaches is that they improve end software quality,and medium to longer term improve maintainability and extensiblility of the code. (If they don't achieve any of those, you probably should get rid of the process).

    The real problem with inexperienced programmers is they haven't seen the result on a l

  • by w3woody ( 44457 ) on Sunday March 12, 2017 @09:47AM (#54022425) Homepage

    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, [wikipedia.org] the "new" features being added to many "modern" languages are really concepts from languages that are between 50 [wikipedia.org] and 60 years old or older, [wikipedia.org] and most of the concepts we bandy about as cutting edge were developed from 20 [wikipedia.org] to 50 years ago. [wikipedia.org]

    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" [www.objc.io] over an "outdated" design pattern who wrote objects that bare no resemblance to the pattern they claim to be following. (In the case above, the classes they used included "modules" and "models", neither which are part of the VIPER backronym.) 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" [techrepublic.com]) to stop "cowboys." Our industry is agist, [businessinsider.com] sexist, [cbsnews.com] one where the blind leads the blind, and seminal works attempting to understand the problem of development [wikipedia.org] go ignored.

    How many of you have seen code which seems developed using "design pattern" roulette? Don't know what you're doing? Spin the wheel!

    Ours is also one of the fewest industries based on scientific research which blatantly ignores the research, unless it is popularized in shallow books which rarely explore anything in depth. We have a constant churn [cleancoder.com] of technologies which are often pointless, introducing new languages using extreme hype [apple.com] which is often unwarranted as those languages seldom expand beyond a basic domain representing a subset of LISP. [paulgraham.com] I can't think of a single developer I've met professionally who belong to the ACM [paulgraham.com] or to IEEE, [ieee.org] and when they run into an interesting problem tend to search Github or Stack Overflow, [techcrunch.com] even when it is a basic algorithm problem. (I've met programmers with years of experience who couldn't write code to maintain a linked list.)

    So what do we do?

    Beats the hell out of me. You cannot teach if your audience revels in its ignorance and doesn't

  • by cas2000 ( 148703 ) on Sunday March 12, 2017 @10:15AM (#54022523)

    Two of the essentials, anyway. Not enough by themselves, but necessary.

    make everyone use git or similar, and have all merge requests reviewed by coders who are both willing and capable of explaining what's wrong with the submitted code AND offer pertinent, targeted suggestions for fixes and improvements.

    a code review without learnable critique is next to useless. it's not an opportunity to say "fuck off, your code is shit", it's an opportunity to teach and encourage improvement in your colleagues.

    This helps the more experienced coders to improve too - explaining something to someone else is a great way to enhance your own understanding.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde

Working...