Responding to questions… what is an appropriate level?

This is very much an open ended question and is meant to raise a discussion.

(Also, if you feel that any critique is aimed at you; it’s not. Some examples may be triggered by what some of you wrote, but it’s not meant to be judgmental. These are questions that have grown with me over years through interacting with this community and others throughout the internet. It’s just very applicable to the core idea behind Processing).

//

When trying to convey solutions and give support (to novice coders in particular) I’m never sure at what point it is right to introduce more rigid coding best practices and proper terminology.

Participating in various threads throughout the years I’ve observed that other contributors style, detail-level and preparedness to push best-practices does vary a lot. It becomes extra apparent if those contributor types converge on the same topic.

Personally, I often opt for a more “non-coding language” when giving an answer. For example, I’ll talk about “creating and filling an array” instead of using terms like declare and define. Both convey the same idea, but one is clearly more topically sound and correct, when viewed from a “best practices”-perspective.

In a recent post about fundamentals of arrays, one answer introduced the idea of static and final keywords for non-changeable data. And the follow-up discussion kinda took several steps away from the basic problem at hand.

Or, naming conventions. Wouldn’t a novice just need to know that “make the name descriptive”? Maybe know about camel case. But then introducing snake, screaming, prefix, Hungarian, etc. may be more of a distractor in the moment.

And a classic, someone is struggling to handle several items on screen, like declaring x1, y1, x2, x2, x3, y3, etc. The obvious answer is “Use OOP!”, but that is placing a coding Mt. Everest in front of someone who hasn’t yet gotten an intuition for navigating a cartesian coordinate system.

//

Just to drive home my point, I’m coming from a place where I believe that a majority of novice coders get thrown off already by the presence of “void” in a function declaration. Their brains are not yet wired to think in “return types”. In my mind – and based on my own experiences – the existence of “void” is not questioned, but instead it’s a pattern you have to follow, otherwise your code breaks.

This is obviously not bashing novice coders, on the contrary, I’m trying to be extra aware of how prepared or willing they are to take on replies and their ability to digest proper technicalities of programming therein. In my mind, wrapping answers into non-coding language can help take off the edge a little.

I then also believe that there is an upper limit of how detailed or in-depth an answer can be, before it begins to become an obstacle in and of itself.

//

I now hear some of you say, “That’s laughable, obviously anyone serious about using Processing will have the basics down and are open to learn more advanced terms, practices and conventions.”

One question to ask here is: What is the end-goal when supporting someone in this forum?

  • have them duct-tape together a working sketch, best-practices be damned
  • prime them for a CS career

The answer clearly is “it depends and always consider the context”. But I believe it’s vital to shape your answers appropriately, even if it means dumbing down and foregoing what you know would be better.

Despite Processing’s maturity and the many advanced topics discussed in this forum, I still feel that Processing has this distinct “for non-coders” urgency to it. Specifically, creatives and artists that want access to the possibilities of creative code BUT at the same time have little to no interest in becoming proficient coders. Just good-enough coders.

//

What is your take on this? What motivates you to write your answers the way you do? What do you put extra focus on? What do you deliberately leave out? Do you think in one-size-fits-all or do you shape an answer based on who is asking?

No rights and wrongs, all opinions welcome.

1 Like

Answering with some post-posting-this-post thoughts:

The more the merrier. A mix of viewpoints, detail-levels and approaches will always outperform a singular blunt answer. In that sense, having everybody answer with a uniform, formulaic structure is absolutely not what we want.

Though I think it most impactful, if the first reply – the “initial contact” – manages to match the mindset and skill-level of the person asking the question. If that connection and understanding gets established successfully, then any additional, more elaborate and alternative viewpoints can be more easily added (and digested) in the pool of replies.

As you say there is no correct answer so I can only discuss this from my own perspective and experience.

When responding to a forum discussion there are several factors I will take into consideration

  1. What is the expectation of the original poster (OP)?
    Maybe they want a quick fix and are not interested in exploring anything beyond that. On many occasions they are looking for better ways of doing something or improving their code.
  2. What is the OP’s level of programming skill / experience?
    Generally, this can be accessed by how they phrase the question or if they post some code, it can be very apparent. Beware that not all OP’s are novices, I have asked questions on the forum and I am certainly no novice.
  3. All OP’s deserve respect, after all they are trying to do something new and probably out of their comfort zone. Like everyone else I started as a novice programmer and it has taken many, many years of programming, study, experimentation and pure perspiration to develop the skills I have now.

In a short discussion post it is very difficult to get the response level right but I try to answer at a level that I think they can understand and avoid extraneous advanced syntax. That doesn’t mean I will not introduce new concepts but I try to keep them at a level they might be able to absorb.

Some aspects of programming are considered good programming practice they include

  1. Use of whitespace (tabs and blank lines) to organise the source code to highlight the program structure. Most IDEs have a command to format source code, in Processing Ctrl+T or Cmd+T performs this task.
  2. Naming conventions. In Java the initial letter of a class name is capitalized, function/method names start with a lowercase letter and constants are all uppercase. This is not unreasonable after all if you were reading a novel you expect the author to follow the grammatical rules of the written language.
  3. Where appropriate use variable/ constant identifiers that reflect the meaning of the data e.g. speed instead of s.
  4. Comments should be used for any non-trivial source code. Not only will it help others to understand the purpose of the code I guarantee the author will find them useful later when debugging or extending the code.

A novice can totally ignore these practices and still write code that works so don’t see the point of them. Since all skilled programmers follow them, it is sensible for all novices / programmers to do the same. After all they are easy to implement as they are not dependent on a language syntax and if a novice wants a more experienced programmer to provide an answer it is sensible to present the code using a ‘standardized’ format.

One thing to be aware of, it is easy for a novice to underestimate the difficultly of the problem. As a novice I was not immune from this mistake. In these cases, the experienced programmer knows that the solution requires the use of advanced language features that the novice is not ready to learn. These questions are really difficult to answer because the forum is not a great place to give holistic answers.

4 Likes