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


Forgot your password?

Ask Slashdot: How Would You Teach 'Best Practices' For Programmers? 220

An anonymous reader writes: I've been asked to put together a half-day workshop whose title is "Thinking Like a Programmer." The idea behind this is that within my institution (a university), we have a vast number of self-taught programmers who have never been taught "best practices" or anything about software engineering. This workshop's intention is to address this lack of formal training.

The question is, what should be covered in this workshop? If you have an idea -- that also has an example of best practice -- please share!

It's really two questions -- what "thinking like a programmer" topics should be covered, but also what examples should be used to illustrate best practices for the material. So leave your best thoughts in the comments.

How would you teach best practices for programmers?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Would You Teach 'Best Practices' For Programmers?

Comments Filter:
  • Learn math (Score:5, Interesting)

    by Master5000 ( 4644507 ) on Sunday February 25, 2018 @07:38AM (#56184265)
    There is no way around it. Never seen a great developer without strong analytical skills.
    • Re: Learn math (Score:4, Insightful)

      by Reverend Green ( 4973045 ) on Sunday February 25, 2018 @07:47AM (#56184289)

      Imho grammar is at least a important as math. If a person speaks like an illiterate rube, chances are he'll program like one too.

      • A student should have an uncluttered mind. A mind that is cluttered is a sign of someone impatient and lacking in self-discipline.

        Have a programming apprenticeship program where the student writes code and the "advisor" reviews it for correctness, completeness and style. At first once per day review, then once very two days, to once per deliverable.

        Most of all, the student for a few weeks, be given ample time and low priority tasks, and as the skills improve, tighten up the student's timeframe to deliver.

    • by PolygamousRanchKid ( 1290638 ) on Sunday February 25, 2018 @08:12AM (#56184363)

      I think a combination of the "Wizard of Oz" approach and Cognitive Behavior Theory would be very effective here.

      Never seen a great developer without strong analytical skills.

      I've never seen great developer, or actually, someone who thinks that he is a great developer, who didn't look, smell and act like one.

      Do not shave your neck any more.

      Stuff yourself with unhealthy junk food; preferably, while working at your keyboard.

      Think that you are a super-genius and all your colleagues are idiots. Convince yourself that your code never has any bugs, and the problem must be somewhere else.

      Showers and baths? Forget it. The whole world is in a drought, and you need to save water.

      Get yourself into meaningless arguments about trivial things like vi vs. emacs. Refuse to stop arguing, even when everyone else has left the room.

      In short, you don't need to be a great developer! Just play one on TV!

    • Agreed, that's one of the minority of things where "I'm following the best practices" means something else than "I've decided to copy everyone else's mistakes" for a change.
    • And why do you write Math in your subject line but talk about analytical skills in the comment?
      Math != Analytical skills

      • by Bongo ( 13261 )

        And why do you write Math in your subject line but talk about analytical skills in the comment?
        Math != Analytical skills

        That's what I was wondering. I imagine there is a reason that development uses the word "architecture". Design is often about understanding where and how to make compromises between contradictory requirements. And didn't IBM originally think that programming was something like music composition? Which is not to say that some problems are not extremely mathematical, just that that is one form of cognition, and there are other intelligences which come up in other problem types. So perhaps the question is a bi

        • Architecture is the combination of known design elements to meet a particular use case.

          Engineering is design based on mathematical calculation of all the strengths of the necessary materials.

          Software can be created using either of those systems, or using almost any other creative pattern or procedure.

          Code is normally designed as in architecture, but sometimes (spaceships and traffic controls) it is engineered.

          You don't actually need to learn how to "do" math in the sense that they mean it in math classes, w

          • Actually we agree what "best practices" are.
            You can google for it and then you find the 5 steps/levels of CMM(I) which are centered around about best practices.
            https://en.wikipedia.org/wiki/... [wikipedia.org]

            The question however is for a single developer which of the best practices he should know. That is why we developed agile methods like Extreme Programming (XP) and Scrum, to focus on the stuff that is relevant for a single developer so that others can focus on the bigger picture (like acquisition, planning etc.)

  • Back to basics (Score:4, Insightful)

    by Calydor ( 739835 ) on Sunday February 25, 2018 @07:44AM (#56184281)

    Indentation and comments.

    Stopping for a moment to ask yourself if you NEED to load a 50 MB library for two lines of code.

    • Indentation and comments.

      And many so called comments are a no-no. New programmers comment the steps in the procedure and they shouldn't. The code itself is supposed to be the documentation of the procedure. Name your variables and functions appropriately, refactor down large functions, and document the damn data.

      • Re:Back to basics (Score:5, Insightful)

        by Strider- ( 39683 ) on Sunday February 25, 2018 @08:43AM (#56184459)

        Oh hell no. So-called “self-documenting code” isn’t. You can write the most comprehensible, clear code in the history of mankind, and that’s still not good enough.

        The issue is that your code only documents what the code is doing, not what it is supposed to be doing. You wouldn’t believe how many subtle issues I’ve come across over the decades where on the face of it everything should have been good, but in reality the code was behaving slightly differently than what was intended.

        • Re:Back to basics (Score:5, Insightful)

          by JaredOfEuropa ( 526365 ) on Sunday February 25, 2018 @08:58AM (#56184487) Journal

          The issue is that your code only documents what the code is doing, not what it is supposed to be doing

          Mod this up. I aim to document my intent, i.e. what the code is supposed to do. Not only does this help catch bugs within a procedure, but it also forces me to think a little bit about the purpose of each method or function. It helps catch bugs or inconsistencies in the software architecture as well.

        • The issue is that your code only documents what the code is doing, not what it is supposed to be doing.

          You can document that with good names. No need to add comments that are likely to become actively misleading.

          Javadoc-style comments are useful (and, actually, if you're writing appropriately-small functions provide all the space you should ever need for documenting the rationale), but inline comments are a code smell. If you feel the need to type a comment explaining what a small block of code does, that's a hint that the block should be factored out so that you can name it something that documents its pu

        • I remember in `99 printing out all the C headers for Gtk+, because it was better documentation than whatever existed for the Perl bindings I was using.

          Yes, when the code is well written enough, like Gtk+ 1.0 was, then that is all the library user should need.

        • Self-documenting code can make it easy to see what the code is doing. It doesn't describe what the code is doing, or why. That's what comments are for.

          Comments that don't tell you anything the code doesn't are mostly useless. Worse, someone will change the code and forget to change the comments. Comments that tell what the code should do are a lot more stable.

    • by AmiMoJo ( 196126 )

      Sometimes I'd rather they load a well tested, robust 50MB library that try to write it themselves.

      Naming is where most programmers go wrong. I have some rules, like putting the units in the name, and am not afraid to re-factor if it makes something's function clearer.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Don't comment your code. Code your comments.

  • I am talking from my old days. When I was at university, most of the things I did was on my own. However, in the real world, it is hard to see a single person carrying all the burden and responsibility of a project. Team skills are important if you want to get out of your mom's basement.
  • by Anonymous Coward

    One should start with assembly language, machine code, or even gate layouts. Higher level languages evolved as a pile of shortcuts and safety measures on top of this, and programmers should understand what is being shortcutted or protected against and why.

    Once you've learned from experience all the terrible mistakes you can make in assembly, and learned the self-discipline not to make those mistakes ever again, you are ready to move on to the next level.

    • Nope. Start with a usable language. Higher-level languages evolved as abstractions over the machine code, and the abstractions are very useful. The hard part of programming is taking an informal problem statement and turning out an accurate formal solution, and that's enough to learn on its own without worrying about which register has what.

  • by Anonymous Coward

    1) There are always things to learn
    2) KISS
    3) If it can go (and it will) wrong then test for it and handle the error.
    4) There is no one solution for anything
    4a) There is no one RIGHT solution for any problem. There are always different ways to skin the cat.
    5) Never act like you know it all even if your name happens to be D. Knuth. (joking)
    6) Read, ask, read, ask and then think. Think again before you even start to think about coding.
    7) Don't be afraid if your first solution is crap and really does not work v

    • 9. Distrust your darlings - if you've done something very clever that you're quite proud of, it's probably a good idea to give it a good hard looking over with a critical eye (or better yet, have someone else do so), and see if you haven't made a grossly over-complicated solution in search of a problem, when something much more straightforward could do the job better.

      I'd disagree with (6) though - it needs more thought between "read" and "ask".

    • by pjt33 ( 739471 )

      Point 5 could be strengthened. Don Knuth doesn't act like he knows it all (source: personal experience), so certainly no-one else should.

  • The basic summary is: you don't know how to code or you would know it takes a decade of trial and error to get good, even after learning the basics. It's sure as shit not going to happen in a half-day workshop and teaching "best practices" will at most create a zealot who doesn't know what the Hell they are doing and is adamant about not learning. Code workshops don't work, best case scenario you're a lazy low-or-moderate-ability programmer, worst case you're a marketing hack.

    TL;DR: Stop tricking idiots i

  • When they arrive, slap them hard on the back and then look them in the eye and say in as sinister a manner as possible.

    "We like team players here, Nugget. Are you a team player?"

    Emphasise the words 'team' and 'player'.

    Then walk off.

    Also have a broken build bear

    http://www.vikingcodeschool.co... [vikingcodeschool.com]

    Be ready to break things. Sometimes things get through QA, sometimes you break the build. A lot of times that will get caught in your continuous integration systems and testing and everything like that. But sometimes even you just push production, like bad code to production, so you're going to break stuff. The most important thing I can say from day one is to know how to fix it. Know how to back the changes out, know how to do things that can undo the damage that you do and then just accept it. It happens, we have a "broken build bear" that we pass around our office for people that do it as a shaming mechanism, but it's mostly in good fun. But it is important to sort of know how to undo.

  • by raynet ( 51803 ) on Sunday February 25, 2018 @08:05AM (#56184347) Homepage

    The most efficient way to teach best practices is to give the programmer electric shocks for every error, and more for bugs caught in testing. For approved commits you may award them with treats.

  • Start with the CERT Secure Coding standards, especially for C programmers it covers many of the "gotchas" to watch out for.

            SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition)
            https://resources.sei.cmu.edu/... [cmu.edu]

    Apparently they them for other languages like C++, Java, Perl.

  • Don't you have any Comp. Sci. professors there? There job is to teach students how to think like programmers (as opposed the "learning to code" that gets so much press coverage).
  • by 110010001000 ( 697113 ) on Sunday February 25, 2018 @08:14AM (#56184371) Homepage Journal
    With a bat.
  • If that's all the time you've got, you've got a systemic problem. This kind of thing needs to be an ongoing process of education. You can't cover anything like this in half a day. Or a full day. WTH.

    Schedule "brown bag" sessions once a week for ongoing training and discussion, and get subject matter experts in for different things: security, TDD, algorithms, optimization, etc. And keep going; don't just do each of those once, because each of those is a full course full of stuff (at least).

    If you're only goi

  • I don't think there's a reliable way to teach programmers best practices. Programming is like composing music: you can teach all the rules and be a technically perfect musician but in the end the real difference between a good programmer and a bad one is elusive. The trick is not to teach programmers, the trick is to find them.

    • Of course there is.
      Just like for composers. For composers you would assume he can play at least one instrument or can use music programs good enough to compose tracks that sound not to bad.
      Same for a programmer, he should be able to use his tools properly, like a version control system and a build system and depending on organization know about continuous integration etc.
      Then probably comes a ticket system. And learning how to pick up requirements, aka Use Cases or Stories or more technical requirements in

      • You wanted to disagree with it, you really did!

        But you don't seem to have understood the point.

        Instead of getting hand-wavy and dismissing the idea that good composers can't be reliably taught, consider first the ways in which it is true. Then you can understand the points being made, and when you go to argue with them, you'll succeed at finding them! Instead of just talking past them and arguing from ignorance.

        Hint: that a competent musician might not be able to write anything that sounds good even on that

        • Composing is more an art, and the composer has ofc to accept the judgement of his audience.
          The internal quality and external quality of a piece of music is the same.

          Programming software is just a craft (yes, you can drive it up to higher levels and the highest might be art ...) as long as the software passes a test (probably automated) it is fine.
          The internal quality and external quality of a piece of programming is not the same. The software can look from the outside perfect, my be even perfectly useable.

  • I've been asked to put together a half-day workshop whose title is "Thinking Like a surgeon." ...
    I've been asked to put together a half-day workshop whose title is "Thinking Like a pimp." ...
    I've been asked to put together a half-day workshop whose title is "Thinking Like a police." ...
    I've been asked to put together a half-day workshop whose title is "Thinking Like a plumber." ...

    Why not, while you are at it?
    • And which of your workshops was the most successful? I like to join it sometimes, perhaps :D
      Well, the pimp thing probably not ...

    • Half-day workshop on Thinking Like a Pimp, targeted for theater beginners.

      1 hour vocabulary study with dialog practice.
      1 hour study of misogynistic tropes with role-playing exercises.
      1 hour of gait study and exercises
      1 hour of costume study

      Method study not recommended.

      • by ruir ( 2709173 )
        Any woman that uses the word misogynistic loses instant credibility, any man is a mangina.

        The opposite of feminism is machismo, no more, no less.
        You are an hopeless baizuo.
    1. 1. That programming is not "coding". Programming should include designing - otherwise, it is "hacking" (pejorative).
    2. 2. Teach about race conditions, aka "TOCTOU errors". This problem is the most prevalent in real time systems - such as phone software, Web software, and pretty much everything we use today.
    3. 3. The value of type safety when refactoring.
    4. 4. Basic concepts such as information hiding, decomposition, interfaces, and that the more shared an interface is, the more stable it should be.
    5. 5. Some machine l
    • 1) I guess "coding" is just the new word everyone likes to use because it sounds cool, so yes, it is programming.
      2) Race conditions by definition only happen in multi threaded systems. And plenty of software is not. Your examples are wrong. A web server will be multi threaded, but most of the time will only use exactly one thread per request. In other words, the programmer of the web application will never see race conditions ... the programmers of the web server will ... and those are likely 2 or 3 levels

      • 2) Actually it's not uncommon at all as a web developer to have a problem arise because two people are viewing a website at the same time and the two threads make database alterations in the wrong sequence. You have to be aware of it and make decisions about how to handle it.

      • lol if you don't think you can have a race condition in single-threaded code, wow... that's what I call "sheltered."

        Doing consulting work it isn't even surprising or uncommon.

        Race conditions are any time the algorithm relies on things happening in a certain order without checking. So any type of non-blocking read, for example. Or you might have to set some system register, and then wait for some other register flag to show up before doing the next step. Screw it up and you've got a race condition.

        I had one

        • lol if you don't think you can have a race condition in single-threaded code, wow... that's what I call "sheltered."
          No you can't.

          So any type of non-blocking read, for example. Or you might have to set some system register, and then wait for some other register flag to show up before doing the next step
          That is nonsense.

          I had one a few weeks ago where an interrupt service routine simply made a faulty assumption about the maximum number of cycles it could take to start
          That is not a race condition.


  • I don't know sign me up! Seriously I need this.
  • by Pinky's Brain ( 1158667 ) on Sunday February 25, 2018 @08:51AM (#56184471)

    Stumbling towards a steaming pile of shit with flavor of the day development strategy, flavor of the day framework and flavor of the day lingo and absolutely never with any structural ways to avoid the most common security flaws we have been aware of for multiple decades. That's what you have to teach them.

    They want a job, knowing best practices isn't conducive to that.

  • Teaching people by showing them errors or bad code doesn't move the needle very much. In technical subjects I prefer to used researched based teaching strategies. Put attendees into groups, give them bad code examples, and have them find the errors or ways in which the example could be improved. Then have a discussion about it and guide them all to a common understanding. If you show someone a bad example or give comments for improvement, it typically goes in one ear and out the other, if they find the er

  • From my experience of answering tons of questions on StackOverflow, a huge deal of newbies or self-taught programmers program the following way:

    - try some random thing
    - get an error
    - ask how to fix the code (and not even post the error)

    You should teach them the right process, which is based on reading (a lot), experimenting, analysing errors, making deductions on what needs to be changed, and repeating the cycle:

    - read documentation, before starting programming. You need to u

    • by Qwertie ( 797303 )
      There is so much advice one could give. Here's mine.

      Organization is key - both within a file and across the whole program - to letting anyone else understand your code. At the project level, try to make it obvious how the project is structured by choosing appropriate names and, if it's a large-ish project, break it up into folders in a logical way and provide a readme.txt that tells readers about the main parts of the project, where they are located (files and names of types/classes) and how they fit tog
  • If you are good at identifying problems or inefficiencies, programming is easy. -Most people really can't, it takes practice.
    Good programmers can identify the real problem underlying the problem that is presented to them. Most projects (in any field - not just programming) are poorly specified and don't have well defined requirements. Think of the Obama-care website or pretty much any government construction project.

    If you are good at predicting possible mechanisms for failure, programming is easy.
    • All of this.

      But as a self taught programmer who works in education I'd love a half day or full day of hands on learning of how to use git and other version control systems

  • I don't think you can teach then to write "better" code, like the actual ability to break an task into programmatic steps. While you could learn some useful algorithms and patterns that's a long topic and more something you get with experience. What I would focus on is a self-taught programmer has probably mostly worked alone, written all the code themselves and done relatively small projects with a limited lifespan and a lot of greenfield projects where you deliver version 1.0 in the end. This may not be t

  • by AeiwiMaster ( 20560 ) on Sunday February 25, 2018 @10:17AM (#56184589)

    A couple of years ago I took a MOOC called "systematic program design."
    Even though I was a self tough programmer and had been programing for 25 years,
    i still learned something new.

    They used this book
    https://www.amazon.com/How-Des... [amazon.com]
    I recommend you check it out and google the course name.

  • Here are some good practices for developers:
    1. When a bug is reported in a group project, there are 2 types of people.
    1.1 Without any investigation, a developer declares that it isn't his/her problem.
    1.2 A developer who assumes it might be his/her problem and starts investigating.
    I certainly prefer the latter. This isn't about ego, it's about code doing its intended job.
    2. Developing always creates bugs.
    Prolific developers create lots of bugs.
    Developers should not be judged on the n
  • If you had half a year, it would be doubtful you could achieve much. Half a day is a complete joke.

  • For the love of trump, just sanitize your input!!!
  • by Anonymous Coward
    Before you change anything ask yourself the question "Will this affect someone other than myself?"

    If the answer is "yes":

    1. a) Have you updated the docs?
    2. b) Have you consider users who may be reliant on the old way?
    3. c) Have you considered the people that have to support, sell or market your software?
    4. d) Does the change need to be verbally communicated in meatspace to other people in your org?

    Basically, never assume that checking in code is the final step

  • by petes_PoV ( 912422 ) on Sunday February 25, 2018 @10:55AM (#56184645)

    we have a vast number of self-taught programmers who have never been taught "best practices"

    Arrrrgh! The worst sort.

    These people tend to be rank amateurs. But with the "experience" that makes them think they are actually professionals. Almost none of them are. And most never will be.

    Most people, even people who make a living from programming, are much worse at it than they think they are. They are impatient, they are hit-and-miss, most can't think clearly and an unfortunate number share in the twin misconceptions that "if it compiles cleanly, it works" and that testing is merely a stage that comes between coding and release to production (and is not there to fix problems, merely to tick boxes).

    Personally I would focus this workshop on the cost of the errors made - and target it at the senior people there. Drum it home that "good" software - best practices is not about how many million lines of code you can write in a day, nor about how complex you can make an algorithm. It is about being able to hand your work off to others and the ease with which they can understand what it does.

    • My best advice for "being a good programmer" doesn't have anything to do with writing code. One of my professors taught us to "define, defend, and attack" something to show you have a solid understanding of it. Another lesson I've learned is to never come to a manager/leader with a problem. Come to them with a problem and at least 3 well thought-out solutions. I've really taken these lessons to heart in my career. Going into a design meeting, concisely and thoroughly explaining the problem and being able to

  • You could take a look at what Software Carpentry https://software-carpentry.org... [software-carpentry.org] teach. They cover relatively practical skills like version control, regression tests, etc. which are still a big step forward for many research programmers.

    At a more conceptual level you are aiming towards "abstraction" and "separation of concerns". Self-taught academic programmers are usually quite good at getting individual methods to work, but hopeless designing software so that changes are localised.

  • Me code pretty some day
    A voice in the wilderness
    http://world.std.com/~swmcd/st... [std.com]

  • Get them to work in a support team before allowing them to develop code from scratch. Having to maintain the mess that is other people's code will soon instil an abject horror of those things that should be avoided.
  • During the 1980s, there was much research into the psychology of experts and that included programmers. Soloway et al found that experts exhibit tacit problem solving skills that they apply automatically. I completed research work a few years back looking at the effects of teaching such skills explicitly to novice programmers. If you're interested, here's a good starting point... http://crpit.com/confpapers/CR... [crpit.com]
  • The ideas of "best practices" and "design patterns" lend themselves to cargo cult programming. So let them be aware of best practices and design patterns, but what you should teach is that you should keep refining code until either the deadline runs out, or there's nothing left to remove.
  • I would say the first best practices is to make code easy to read. That would include:
    - Syntax formatting all the indents and whatever case things are popular for variables, globals, functions, etc.
    - Breaking out of command packing lines, Indenting, how you present opening and closing brackets/braces/parenthesis
    - Descriptive naming of tables, fields, variable, functions, etc.
    So when you are done comments wont be apologizing, but just augmenting what is apparent. Once much of that is done class should star

  • If you want to write good code, do not think like a programmer. Do think like a hacker, and try to imagine how your code could go wrong.
  • This workshop's intention is to address this lack of formal training. Why not provide them with formal training (CS degrees?) if you want to address their lack of formal training?

  • For professional programmers, the most important skill is sniffing out unnecessary work (requirements that will be changed) and putting it off. But if we're talking scientists using code in their work.... 1) Learn to name your variables. No, nobody knows what "d2" is, and knowing it's "delta sub 2" doesn't help much either. Yes, I know your papers are filled with random symbols that are never explained and no one will call you on because they don't want to look stupid, but that's not proper practice in
  • Having dealt with a lot of code (and programmers) who came from other backgrounds (EE or math), here are the top things I would try to teach them:

    1. Data structures and interfaces. Too many of these people create a sea of global variables and functions that manipulate them in difficult to follow ways. Discourage global variables in general except for constants because they WILL abuse them. If you get them thinking in terms of data structures and interfaces (and thus subcomponents of the problem) it will

    • this++. EEs are trained to instantiate rather than abstract; if they need two UARTs, then they need to put two chips on the board, so they expect to cut-and-paste-and-modify two copies of the UART code for the two devices. If they understand the concept of a subroutine, they pass in "1" or "2" and have a zillion "if" statements choosing between the two UARTS. They do *not* understand the idea of one subroutine using a pointer parameter with all of the code being identical - even though that's pretty much
  • You should probably start with Software Design Principles:

    DRY (Don't Repeat Yourself)
    KISS (Keep It Simple, Stupid)
    YAGNI (You Ain't Gonna Need It)
    SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion

    Then plan on having a lot more of these meetings, because you should not be able to adequately cover these principles in a half day. Afterwards, you should probably also have meetings on coding standards, methodology (waterfall, agile, or whatever), testi

  • I've worked as a developer in similar environments - where there are a lot of smart people with a background in math, physics, EE, or aerospace, who've googled their way to a moderate level of programming proficiency (they can probably hack together a script to do just about anything) but have zero understanding of code style, modularity, maintainability, or quality.

    Some of the things that I wish everybody understood:

    Very basic ideas about rules of thumb and sniff tests for maintainability and readability -

  • Mark Twain's essay "Fenimore Cooper's Literary Offenses" saved me from a high school English paper. His opening thesis also turns out to be prescient regarding software design, if one replaces "personages" in a "tale" with the variables or objects in a software system.

    There are nineteen rules governing literary art in domain of romantic fiction -- some say twenty-two. In "Deerslayer," Cooper violated eighteen of them. These eighteen require:

    1. That a tale shall accomplish something and arrive som
  • It's not about programming: engineering reliable computer systems is about how you work with the organisation and people around you to deliver, to prove you've delivered, and to keep alive your system.

    If you don't understand your code well enough to teach it to anyone -- especially those less technical, educated or experienced than you -- you don't pass review.

    If you don't practise for critical incidents -- which firefighters and emergency-response teams do -- you'll make that unexpected bad day a whole lot

Mathematicians stand on each other's shoulders. -- Gauss