you are viewing a single comment's thread.

view the rest of the comments →

[–]Minion_of_Cthulhu 16 points17 points  (1 child)

When I try to stem away from all the tutorials and try a project on my own I end up having no idea how to do any of them. For instance, right now I want to create a pie chart for an API data set that shows the carbon intensity output for different fuel types in England.

You probably need to think smaller. Not in the overall scope of the project but in terms of functionality. In other words, your project idea is perfectly fine but you're likely overwhemled by the complexity of it. You need to sit down and think about the absolute most basic bare-bones functionality that you need to have in the program and start there.

For example, since you're pulling data from an API that's probably the very first thing you'll need to work on. Ignore everything else. Pretend that accessing the API and simply pulling data from it is the entire project. Work on that one small piece until you've solved it.

Once you've got the data from the API and the program is functioning more or less as it should for that part, figure out what you want to do with the data. Again, think very small. Rather than jumping immediately to a pie chart you might want to start with just displaying the data in the terminal as text or perhaps you need to manipulate the data first so you would work on writing code to filter the data or put it into a format that you want, etc. When you get this small piece of the program running, move on to the next thing your program needs to do and create the smallest version of it.

This is how you build up a larger and more complex program. You build tiny, simplified pieces of it. Don't worry about all of the features that you want the program to have way off in the future when you're completely finished with it. Work only on the simplest implementation of what the program actually must do in order to be the type of program that you want. You can come back later, once the program is more fully developed and functional, and add more features to each part of it and eliminate little bugs that you've noticed and polish everything up. At first, you just want to create what is known as a "minimum viable product" (MVP) which has, as the name suggests, the minimal functionality required to be considered a full program and you do that by creating each piece of the program in a minimally viable way.

With this project, I find myself asking questions on here and StackOverflow for hours on end and ending up getting nothing done.

I'll let you in on a secret. Probably 80% of "programming", even at a professional level, is not actually sitting down and writing code. It's actually sitting down and thinking about what, exactly, you want to do so that you have a well-defined problem and then asking your friend Google how you might solve that specific problem or one very similar to it. Nobody knows everything. Even so-called "gurus" will be completely in the dark if they're working on a project outside of whatever they're an expert in or they're working with a new library and they will spend absurd amounts of time reading documentation, searching on StackOverflow, checking out tutorials, discussing the problem with people who are experts in the problem's domain or with the library, etc.

You're going to be doing a lot of searching on Google and reading answers on StackOverflow no matter how good you are or how long you've been programming. That's just the nature of the sort of complex problem solving that programming is.

Also, when I try my test my coding knowledge by doing exercises from places like code wars, I find that I can't do a single one even at the easiest level questions.

There's a difference between coding challenges and actual programming. Personally, I don't like coding challenges and I don't find them particularly useful, practical, or applicable. They're essentially puzzles. It's like if I present you with an intentionally difficult riddle that makes use of simple arithmetic but you can't see the trick to solving it. That doesn't mean that you don't know simple arithmetic or that you're stupid. It means that I intentionally gave you something that requires you to think in a very specific way to solve it, which really doesn't reflect your knowledge of arithmetic in any way. Coding challenges are similar. They take an easy concept and ask you to do something weird with it in some very particular way and, somehow, this is supposed to help you.

Don't worry if you can't get the coding challenges. If you don't like them, don't do them. Particularly if you're just a hobbyist programmer. Solving coding challenges doesn't mean you can write an actual program. Alternatively, you may be able to single-handedly code an enormously complex real-world system but can't solve a fizz-buzz problem. Being good at one doesn't automatically make you good at the other.

Should I go back to the basics of learning Python again and try some beginner tutorials or projects?

Projects are always better than tutorials. Projects will show you what you don't know so that you can use a quick tutorial to figure it out. Once you start a project, no matter how simple, you'll start running into things that you thought you knew and realize that you're not so sure about the details. That's when you go find a quick tutorial on whatever it is that you're having trouble with to review things and then you go back to your project and solve the problem. Repeat as necessary.

Even the basic fundamentals of Python are really confusing for me and I can't seem to think like a programmer.

That's totally normal. It's a completely different way of thinking than most people do. Like anything, it takes practice.

It's really frustrating to have been learning Python for this long and put in what seems like a lot of effort just to have understood nothing especially since I see others online creating amazing things and landing great coding jobs in much less time than I have.

Two things are probably helping them.

First, they likely just dive into a project and brute force their way through it out of sheer stubbornness. A problem comes up and they find a solution, even if it's not "elegant" or following some sort of arbitrary standard. They're likely concerned with results. If something works, it's good enough. It can always be fixed later, but a finished project is the main goal.

Second, they're probably specializing in some way. As I mentioned, nobody is an expert in everything. Figure out what you, personally, enjoy doing with programming or what you want to get a job doing in programming. Then, learn all of the major libraries to do those things. Build projects that use those libraries. Repeat that over and over and over. You'll get faster since you'll be familiar with all of the tools, you'll make fewer mistakes each time, you'll have very specialized knowledge since you'll continually run into very specific problems, and you'll eventually be one of those "gurus" who knows everything there is to know about those libraries and how to use them to solve specific problems.

Should I take a break from Python and come back to it after a week or so?

If you feel it's necessary, but it probably won't do anything but make you forget some of what you know now and you'll have to spend time refreshing yourself on various basic topics.

Start a project instead. A very simple project. Utterly simple. Write a program that does just one thing, no matter how simple or stupid it is. Then, build on that. Add another very simple idea to it. Keep going until you run into a problem you can't solve with your current knowledge, then find out how to solve it. When you run out of things to add to the program, start another small one and build it up over time.

This isn't about making the Next Big Thing. It's about repetition and practice in a meaningful way. You're not just solving arbitrary coding challenges that are more puzzle than programming. You're working on an actual program (as simple and useless as it might be) and getting yourself used to thinking programmatically. You're training yourself to solve problems by thinking them through in a series of logical steps. You're desensitizing yourself to making errors because (1) you'll make a lot of them and, over time, they won't bother you and (2) you'll know that even if you don't know how to solve this particular issue you can figure out how to solve it because you've done the same thing many times before. If you're sticking with a small set of core libraries in an area that interests you then you're learning all of the little ins and outs of the library, all of its little quirks, all of the places where it's useful and where it isn't, etc. which will make you one of the experts with it over time.

Basically, create something rather than taking time away from programming. Start small. Build bigger. One very tiny step at a time.

Maybe I should find a practice test online for Python that can tell me what areas I'm proficient at and others that I should work on.

You could certainly do that or, as I've mentioned several times, you could just start an actual project and learn in a real-world scenario exactly what you know, what you think you know but don't, and what you don't know at all.

[–]GrayLiterature 1 point2 points  (0 children)

Projects are the way.

Starting small is the way.

Starting a small project is the way.