Ask HN: Advice for a beginner programmer on understanding systems?

1 pointsstatusanxiety3y ago2 comments

I have recently started writing a web scraping bot to learn Selenium and have found that the problems that are truly stumping me are things related to the underlying systems of my computer. For instance, I didn't understand why Selenium was bringing up an import error when I'd definitely installed it. I later found I was using the wrong interpreter in vscode. I'm currently completely stuck on setting up a remote debugging port because I am having issues that I can't find answers for online and have no idea how to debug myself (my localhost won't connect on any browser).

How do I best go about solving problems that are not necessarily "coding" problems, but more related to setting up my system correctly for my code to work? How do I go about finding out what is necessary to learn and what I can ignore?

2 comments

2 comments · 2 top-level

dromedariusCase3y ago

The best thing to do is to be frustrated. And I mean it! The first few days of learning any new framework/language/system is to either slog through hours of tutorials and books with only tangential relevance to the task you want to accomplish, or to dive in head first and learn through a faster version of the genetic algorithm. The main loop looks something like this:

Want to do something -> try to do it (through google) -> doesn't work -> read exception -> search exception / stackoverflow -> try fix exception -> probably doesn't work -> eventually find error and underlying cause -> repeat.

As you learn more about the framework and language, the time to complete this loop becomes smaller and you learn more efficiently. However everyone goes through the initial slogging steps of being frustrated and unable to figure things out.

ggm3y ago

It's very much trial-and-error. Yes, probably somebody has been down this path, and yes they may even have packaged it in a docker or git repo somehow but you said you wanted to learn so I suggest that hunting for a wrapped solution to the problems is maybe less helpful than constructing your own model of how to fix them and documenting it for others.

TL;DR -keep going. You're doing fine. Keep a diary (dated, sequenced - a lab book, a jupyter, a GIT repo of the constantly evolving install script) and write something as a final state (the README.md for the git?) which is less about time and more about the problems of significance and leave a trail or markers to how you fixed things.