My first computer I soldered together from parts and programmed using toggle switches on the front panel. This was about 35 years ago.
But I studies engineering, not computer science in collage. In my first programming course, Fortran for engineers, the taught us to start in the middle and work toward the beginning and end of the program at the same time. No subroutines at all.
Over the years I've been reading and learning to be a "real programmer" and after about 10 years on the job I got away from designing hardware altogether. (Software is a lot easier.)
The advice you've been getting here is very good, I think, but "learning to code properly", isn't the same as becoming a good programmer or computer scientist. Coding is a small part of the job.
I think you are somewhat like me ... I now stick to small projects or I have a small independent part of a bigger project. If the government came and asked me to design the software for the new national air traffic control system, I know that I'm not the right person for that job.
In fact, and this bothers me a bit, if someone wanted an e-commerce system that could scale to 500K transactions a day, I don't really know where to start. My education and experience on small scale projects just hasn't lead me in these directions.
So I've focused on learning how to design small software systems, first for embedded applications, and now for low traffic web sites.
To that end I have learned a bit about:
- Data structures
- Program structure (data hiding, object coupling, modularity, maintainability, extensability)
- Algorithms
- Design patterns
- Structured design
- Object oriented design
- Object oriented programming (but don't use inheritance too much)
- Database design (normalization)
- Software life-cycle management
- Project management and estimation (feature creep)
My first computer I soldered together from parts and programmed using toggle switches on the front panel. This was about 35 years ago.
But I studies engineering, not computer science in collage. In my first programming course, Fortran for engineers, the taught us to start in the middle and work toward the beginning and end of the program at the same time. No subroutines at all.
Over the years I've been reading and learning to be a "real programmer" and after about 10 years on the job I got away from designing hardware altogether. (Software is a lot easier.)
The advice you've been getting here is very good, I think, but "learning to code properly", isn't the same as becoming a good programmer or computer scientist. Coding is a small part of the job.
I think you are somewhat like me ... I now stick to small projects or I have a small independent part of a bigger project. If the government came and asked me to design the software for the new national air traffic control system, I know that I'm not the right person for that job.
In fact, and this bothers me a bit, if someone wanted an e-commerce system that could scale to 500K transactions a day, I don't really know where to start. My education and experience on small scale projects just hasn't lead me in these directions.
So I've focused on learning how to design small software systems, first for embedded applications, and now for low traffic web sites.
To that end I have learned a bit about:
- Data structures
- Program structure (data hiding, object coupling, modularity, maintainability, extensability)
- Algorithms
- Design patterns
- Structured design
- Object oriented design
- Object oriented programming (but don't use inheritance too much)
- Database design (normalization)
- Software life-cycle management
- Project management and estimation (feature creep)
That's all that comes to mind right now.
Peace,
Rob:-]