One thing I enjoy in my first-ever dev role is the opportunity to learn from the brightest minds and expand my developer skillset. Encountering cod...
For further actions, you may consider blocking this person and/or reporting abuse
Somewhat of an add to step 3, try searching your own team/org projects in git for similar words and functions you are using (and getting errors for). Many times, someone else has implemented or used something similar, allowing you to learn from their example without having to go to them directly.
great point - and something I do a lot; I will add!
Also search the issue tracker, in case of a bug.
A secret tactic: search the issue tracker once more, when cause was found. Others might have stumbled in the same problem.
It happened to me that the fix just unlocked a second bug, and all that (along with a fix for a third bug) was already found and solved in a different release.
Step 7: If you've reached this far, you might want to take a step back, go for a walk, boil a pot of coffee, and take your mind off the problem. A surprising amount of time you just need to clear your mind off the problem to come up with a solution.
One thing I've added, once I've worked through a similar version of your awesome steps above, is considering what questions they may ask me that I hadn't thought of. I don't know how many times I've stood up and thought "wait, they're probably going to ask for x, y, and z" and found my solution somewhere in there. As I grow in my experience, I hope I'll reach those kinds of thoughts much sooner.
Great points! My rule of thumb is, ask after one hour of not making any progress despite various attempts.
A opportunity to ask without interrupting is in a coffee break.
I want to write in depth about debugging in my book - slowly getting there.
At the moment you use slack or any other messenger, follow this old but gold rules about getting help on IRC:
workaround.org/getting-help-on-irc/
Most important, share what you already tried to solve the problem and provide examples to reproduce the error
I read your subject and was planning on replying “It’s never lazy to ask for help!”
While I do think that’s true, this is a fantastic list of things to cover before doing so. Although depending on the team dynamic, I might suggest dropping the error messaging Slack (or whatever) as your starting these steps Incase anyone has seen the message and can give you the answer quickly.
Parting thoughts...
What’s wrong with being lazy. Lazy engineers automate their jobs and move on to bigger better things. 😉
True story: As a “Jr. HTML Programer” in the late 90s, I learned Perl because I was took lazy to make 100s of HTML a day changes by hand. The rest as they say...
Food for thought.
Nice!!!! It's also something I have been questioning myself on, thanks!
For the web devs, in step 1, check that your servers are running and your database is fine.
Oh absolutely! I'm adding this to the post! :D