Phase1 - UP, Phase 2..., Phase 3 - Profit
Author
Hi,
I'm so frustrated. I want to learn to write software. Really, I want to learn to write software, but I can't find a book and I don't know any real programmers.
I am fed up with reading primers on C++, or C, or trawling through pages of tutorials on writing such and such an application.
Isn't there anyone out there who wants to be an actual programmer? Does anyone understand what I'm talking about?
I've read Teach Yourself C by Herb Schildt pretty much from cover to cover, and I the same with his C++ Reference, barring the STL section, which I read bits of. But that's not programming, that's just C or C++.
I don't understand the reasoning behind most of these tutorials. It's not like I just want to write games - I don't. And I'm always reading interviews with software developers where they say they don't get decent graduates out of universities these days. Why? They don't know how to programme.
Someone give me a starting point. Please?!
Phase 2: Practice.
Programming is all about problem solving. Unfortunately, since every problem is unique, it's impossible to make a book that covers every problem -- or even a good percentage of them. Worse, each problem can be solved in many ways -- each with it's own pros and cons.
At least in math, 1+1=2, and that's that!
There are some attempts to fix this problem -- we categorize our code with Design Patterns, we categorize our work process with Development Models, and we write APIs with some of the problems solved in certain ways so others can use them and build upon them.
But that still leaves the uncharted frontier of whatever it exactly is that you're writing -- since that problem hasn't been solved, before. For this, we must engage in science! Hypothesis, testing, and theory! Well, maybe not -- but still, trial and error at the very least. In other words: Practice!
And there will be lots of error. That's fine -- that's how we learn. It can be frustrating at times, admittedly.
Programming is all about problem solving. Unfortunately, since every problem is unique, it's impossible to make a book that covers every problem -- or even a good percentage of them. Worse, each problem can be solved in many ways -- each with it's own pros and cons.
At least in math, 1+1=2, and that's that!
There are some attempts to fix this problem -- we categorize our code with Design Patterns, we categorize our work process with Development Models, and we write APIs with some of the problems solved in certain ways so others can use them and build upon them.
But that still leaves the uncharted frontier of whatever it exactly is that you're writing -- since that problem hasn't been solved, before. For this, we must engage in science! Hypothesis, testing, and theory! Well, maybe not -- but still, trial and error at the very least. In other words: Practice!
And there will be lots of error. That's fine -- that's how we learn. It can be frustrating at times, admittedly.
You're mired in the "can't see the forest through the trees" stage that all beginners go through. So don't worry, everything is normal.
My advice would be to have a clear goal in mind. What do you want to create? A game? A desktop application? A system maintenance script? A web application? Those are all "software".
Having a goal and (slowly) moving towards it will teach you why you need to do certain things in programming. For instance, you'll hit a problem and then search for a solution. Because you experienced the problem first hand, you'll understand the solution. With a book full of exercises you might just think "OK... now what?" Having a goal or a pet project will feed you a constant stream of problems to solve as it grows larger and more complex.
My advice would be to have a clear goal in mind. What do you want to create? A game? A desktop application? A system maintenance script? A web application? Those are all "software".
Having a goal and (slowly) moving towards it will teach you why you need to do certain things in programming. For instance, you'll hit a problem and then search for a solution. Because you experienced the problem first hand, you'll understand the solution. With a book full of exercises you might just think "OK... now what?" Having a goal or a pet project will feed you a constant stream of problems to solve as it grows larger and more complex.
Failure is one of the best ways to learn; start trying to apply the knowledge your picking up from those books and tutorials to actual problems. It doesn't really matter what the problems are, they could be:
Anything is fine as long as you're actually programming. You'll make a lot of mistakes along the way, and if you stick with it and overcome those problems you'll eventually find you no longer make basic mistakes and even forsee problems before they arise. As MaulingMonkey says - practice!
So, I would say phase two of your little system is in fact a loop where you iterate through practicing, failing and learning.
Hope that helps. [smile]
- Throw-away exercises just to practice concepts.
- Programs you think would be useful to you.
- Games.
Anything is fine as long as you're actually programming. You'll make a lot of mistakes along the way, and if you stick with it and overcome those problems you'll eventually find you no longer make basic mistakes and even forsee problems before they arise. As MaulingMonkey says - practice!
So, I would say phase two of your little system is in fact a loop where you iterate through practicing, failing and learning.
Hope that helps. [smile]
Quote:Original post by jbadams
So, I would say phase two of your little system is in fact a loop where you iterate through practicing, failing and learning.
Yea! Program something simple like Tetris or Space Invader. The most important part is that you program something and not trying to do something you cannot achieve. I would say that you will have to focus on something in order to learn so don't try so much of everything try Tetris and Space Invaders in SDL.
I try to incorporate programming into my day-to-day life by writing programs to do stuff that I would have to do anyway. For example, I had an assignment to calculate the standard deviation of a bunch of number. I could have spent a long time tediously entering each one into my calculator (several times) and doing a bunch of calculations. However, I decided to write a program to calculate standard deviation for me. This ended up being a much better solution, because it turns out I didn't have an accurate idea of what standard deviation is, so I would have had to type all the numbers in multiple times :P
Obviously, this is only one example, but there's all kinds of things you can apply programming to, even if you don't go to school:
Create a program to help with taxes
Create a program to log purchases and balance finances, automatically generates graphs, pie charts, let you set budget info, etc. etc.
Obviously software exists for these things already, but they usually cost money, so you can save a little bit of money by investing a little effort...
Obviously, this is only one example, but there's all kinds of things you can apply programming to, even if you don't go to school:
Create a program to help with taxes
Create a program to log purchases and balance finances, automatically generates graphs, pie charts, let you set budget info, etc. etc.
Obviously software exists for these things already, but they usually cost money, so you can save a little bit of money by investing a little effort...
Yes, you need to understand that "programming is beside the point". I am not kidding. The first program I ever wrote was an optical design and analysis program - in junior high school. I am not kidding. Yes, it was a pretty sophisticated software application all things considered
### BUT ###
Every step of learning to write that program was simply HOW I was solving the individual problems of optical design. For example, part of that process is "tracing a [light] ray through a series of optical surfaces". So I needed to figure out how to store the position of the ray at each surface, which meant I needed to learn about "variables" - to store the ray position in variables x, y, z. And I certainly needed to learn about "data-types" of those variables at that point, because integer positions certainly would not work (unless my units were microns or angstroms). And that lesson unleashed me to create a dozens of variables, like k, l, m for the direction the ray was traveling, and r, p, q, n for the "radius of curvature of the current surface", "position of current surface", "conic shape of each surface", "index of refraction of each surface", etc.
But wait, my optical system has 10 or 15 or 21 surfaces. I can't store the position of every surface in one variable "p" can I? How do I process a whole series of surfaces without writing the same code 10 or 15 or 21 times... and change the code ever time I changed the optical design? Enter structures (where one structure can hold all the information for one surface), and enter arrays (where one array can hold any number of those structures). Now my program can access all information about every attribute of every ray at every surface at every tick (angular position) in every zone at every color at every skewangle (off-axis angle) like this:
And so forth.
My point is, the only relevance "programming" had to my brain was --- "how am I going to make my computer accomplish this or that aspect of MY PROBLEM.
So the person who said "you need a problem to solve" hit the nail on the head. You don't focus your attention on how to make your arm and leg muscles move when you build a house, you focus on the problem you are trying to solve, and only pay as much attention to your tools as necessary to accomplish your goal.
Yes, you need to understand how a hammer and nail work, but you only pay attention to the hammer and nail at the point when you need to make one piece of wood "stick" to another. And then you survey the tools you have available, and ask yourself "what is the best way to accomplish what I want with the tools I have available".
And THAT is how to learn to program.
-----
PS: In a way, you will have less trouble than me, because you have already filled your brain with "hints" about the tools you have available. I had none, and at every step I had to go find something in a totally lame 50-page reference manual for the programming language, try to understand what all (or some of) those strange words meant, and write tiny 10-line experiment programs to figure out how each feature worked... to see whether I could accomplish what I needed in my program. The focus is *always* on what you are trying to implement, NOT the programming language, or any of the endless bogus "frameworks" that everyone is always trying to sell you as a way to save yourself time and effort. My advice about that is, always program at the lowest level you can. Okay, program in C instead of assembly (sometimes), but avoid frameworks at all costs, especially while learning! Otherwise, you'll habituate to some total piece of crap and never be able to accomplish anything without their crutches (and you'll never invent better architectures yourself, you'll just adopt whatever lame scamware/scamwork you bump into on the web).
Anyway, that's my advice. GET A TOTALLY SPECIFIC PROBLEM TO SOLVE.
### BUT ###
Every step of learning to write that program was simply HOW I was solving the individual problems of optical design. For example, part of that process is "tracing a [light] ray through a series of optical surfaces". So I needed to figure out how to store the position of the ray at each surface, which meant I needed to learn about "variables" - to store the ray position in variables x, y, z. And I certainly needed to learn about "data-types" of those variables at that point, because integer positions certainly would not work (unless my units were microns or angstroms). And that lesson unleashed me to create a dozens of variables, like k, l, m for the direction the ray was traveling, and r, p, q, n for the "radius of curvature of the current surface", "position of current surface", "conic shape of each surface", "index of refraction of each surface", etc.
But wait, my optical system has 10 or 15 or 21 surfaces. I can't store the position of every surface in one variable "p" can I? How do I process a whole series of surfaces without writing the same code 10 or 15 or 21 times... and change the code ever time I changed the optical design? Enter structures (where one structure can hold all the information for one surface), and enter arrays (where one array can hold any number of those structures). Now my program can access all information about every attribute of every ray at every surface at every tick (angular position) in every zone at every color at every skewangle (off-axis angle) like this:
for (skew = 0; skew < skew; skew++) { for (color = 0; color < colors; color++) { for (zone = 0; zone < zones; zone++) { for (tick = 0; tick < ticks; tick++) { for (surface = 0; surface < surfaces; surface++) { error = trace_ray_through_surface (surface); x = design[surface].x; y = design[surface].y; o = design[surface].o; if (((x*x)+(y*y)) > (o*o)) { design[surface].vignette = true; } } } } }}And so forth.
My point is, the only relevance "programming" had to my brain was --- "how am I going to make my computer accomplish this or that aspect of MY PROBLEM.
So the person who said "you need a problem to solve" hit the nail on the head. You don't focus your attention on how to make your arm and leg muscles move when you build a house, you focus on the problem you are trying to solve, and only pay as much attention to your tools as necessary to accomplish your goal.
Yes, you need to understand how a hammer and nail work, but you only pay attention to the hammer and nail at the point when you need to make one piece of wood "stick" to another. And then you survey the tools you have available, and ask yourself "what is the best way to accomplish what I want with the tools I have available".
And THAT is how to learn to program.
-----
PS: In a way, you will have less trouble than me, because you have already filled your brain with "hints" about the tools you have available. I had none, and at every step I had to go find something in a totally lame 50-page reference manual for the programming language, try to understand what all (or some of) those strange words meant, and write tiny 10-line experiment programs to figure out how each feature worked... to see whether I could accomplish what I needed in my program. The focus is *always* on what you are trying to implement, NOT the programming language, or any of the endless bogus "frameworks" that everyone is always trying to sell you as a way to save yourself time and effort. My advice about that is, always program at the lowest level you can. Okay, program in C instead of assembly (sometimes), but avoid frameworks at all costs, especially while learning! Otherwise, you'll habituate to some total piece of crap and never be able to accomplish anything without their crutches (and you'll never invent better architectures yourself, you'll just adopt whatever lame scamware/scamwork you bump into on the web).
Anyway, that's my advice. GET A TOTALLY SPECIFIC PROBLEM TO SOLVE.
Quote:Original post by bootstrapIf the OP were trying to build a house and had the option of using a hammer or a nailgun, which would you recommend as the best way of accomplishing his goals with the tools he had available? There's no need to work at a lower level than is neccesary to solve the problem at hand; as long as the nailgun is appropriate for the situation and used correctly using the hammer would just make the overall project more difficult and prone to error. This is however my own personal preference and you're equally entitled to your opposing point of view, so I won't argue the case any further.
[...]
So the person who said "you need a problem to solve" hit the nail on the head. You don't focus your attention on how to make your arm and leg muscles move when you build a house, you focus on the problem you are trying to solve, and only pay as much attention to your tools as necessary to accomplish your goal.
Yes, you need to understand how a hammer and nail work, but you only pay attention to the hammer and nail at the point when you need to make one piece of wood "stick" to another. And then you survey the tools you have available, and ask yourself "what is the best way to accomplish what I want with the tools I have available".
[...]
My advice about that is, always program at the lowest level you can. Okay, program in C instead of assembly (sometimes), but avoid frameworks at all costs, especially while learning! Otherwise, you'll habituate to some total piece of crap and never be able to accomplish anything without their crutches[...]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
