As a fresh semester starts up for me teaching web development, now seems a good time to talk about communication.
Communicating code and design problems is a skill, something that has to be learned by clients, students, and novice developers alike. You don’t need to be a fully-fledged programmer to ask questions, and you shouldn’t hesitate to ask for help, but gaining a positive resolution to your problem is far more likely if your conversation follows a few simple guidelines.
Read any associated documentation before asking your question: if it’s well-written, your problem has probably already been anticipated. Be sure to also read any provided comments.
Example 1: “This doesn’t work in Internet Explorer.” Highlighted in the text immediately above the comment section is a statement of exactly that, why, and ways of working around it.
Example 2: “This doesn’t work in Chrome.” In the body of the article is a guide for learners to add vendor prefixes for browsers that still require them.
Take reasonable steps to address the problem yourself before asking your question:validate your HTML, look for any errors in the browser console, restart your browser and test again, etc.
While providing code-dumps is better than nothing, it’s much easier for a developer to see your work in context. URLs are good; live code (on CodePen, for example) is better. The services are free, and it’s very likely you will solve your own problem as you use them.
If it’s a problem on a site, detail the steps needed to replicate the issue.
“It doesn’t work” doesn’t help anyone. What are you trying to accomplish? What browser are you using? Which version? On what platform? What operating system? Each of these factors contributes to making a site work or fail, especially as you approach the cutting edge in web development.
Example 1: “This doesn’t work in Safari.” Developer assumption: they’re talking about the latest version of Safari on the most recent version of OS X. Nope: they’re talking about Safari on Windows, which hasn’t been updated in years.
Example 2: “This doesn’t work on my page”. No mention that they’re using WordPress, which completely changes the context of what they’re trying to accomplish.
Understand that code is not Lego
Simply copying and pasting code, jamming it together and expecting it to work, rarely results in success. Saying “I just want this to work!” without knowing the broader context (not understanding CSS, for example, while trying to achieve an advanced effect) is usually an exercise in frustration. You can learn this way, but any knowledge you gain is piecemeal and haphazard. Don’t get frustrated if a senior developer tells you to go back to square one to learn the basics.
It’s unfortunate that this needs to be stated, but: be polite and patient. Unless you are paying a developer for their time, they don’t owe you anything. Pushy demands usually get pushed to the back of the pile; polite requests are more likely to be responded to.