[Welly Wu]

I bought an Amazon Kindle book entitled Learning C++ by Joseph Kalash and I am using Microsoft Visual Studio Professional with MSDN 2010 as my Integrated Development Environment. There is a lot of reading involved and the author does a good job of explaining things slowly so that new programmers can learn. I am almost finished with chapter one and most of the sample programs have worked right out of the book.
 
Coding is a maddening process of debugging. The slightest mistake can turn an otherwise functional C++ program into utter uselessness. It can take a significant amount of time to find and fix bugs even when copying code from the book due to simple mistakes in typing in the code.
 
I cannot say that coding is fun. All I am doing is building console applications. They are not sexy by any stretch of the imagination. While I would love to create the next Microsoft Office or Windows, I fear that I am not there yet in terms of my coding skills and experience and it will take quite some time before I even dare to reach that level.
 
What programs have you developed or engineered that you can talk about?
 
What was it like when you first learned how to code?
 
How long did it take for you to get the knack of coding down so that you do not need to refer to a textbook for help?
 
As for myself, I am limiting myself to 20 minutes of reading and coding per day. This is my own pet project. I am only taking one bridge course at NJIT this semester which is an undergraduate course in Principles of Operating Systems. I am not working this spring 2011 semester either. So, I have the time to learn how to code.
 
I will probably need to retake CS115 C++ programming over again since I earned a C in it. As a graduate student, I need to earn at least a B average or higher for all of my courses. I also need to retake Databases because I earned a D. I worked too many hours as a Help Desk and Support Technician at NJIT last semester and it hurt my grades badly. That is the truth.
 
What tips can you offer to new coders especially in the C++ language?

 

[Surreal.]

It's no cake walk!
 
As of this moment I only know Java and C.
 
I wish we would have learned C++ but alas it seems our school pushes C rather strongly.
 
If I were you I wouldn't fall into the habit of reading the sample code in a book and trying to manually type it out. Rather, understand the concept and produce something to the same effect of what is being taught. You'll catch any syntax errors beforehand that you were merely regurgitating before.
 
Some advice: Have a plan before you start coding. It's unwise to just start tapping at the keys without any clear direction. You'll spend more time digging yourself out of a hole than if you would have spent a few minutes drawing a state machine, flow chart, or something similar and figuring out your basic plan.
 
Try and document as much as you can. As in write comments, make side notes, documents, etc. You usually will get "aha" moments when you least expect it and when you run back to your code to implement it you don't want to be staring at a wall of text thinking "what in the ... was I doing." Later in your career it won't be just for your sake but rather for your team members or teachers that will be modifying, reading, working with your code. It's good habit to document every step of the way.
 
Debugging can be beyond frustrating but you will have debugging sessions where you will feel good about yourself. Parsing through line after line hunting for your logical/semantical error can be quite exciting sometimes. When you find it its like a weight's been lifted.
 
I don't think you can completely stop referencing a book. There will always be something that you need to look up, forgot the syntax of, return value, etc. Don't be afraid to use your book!
 
As for projects I've developed I can mention a few.
 
Are you familiar with Cyclic Redundancy Check? If not, it's a "hash function" that is used to evaluate transmitted messages for any integrity issues. I created a program that took any message (in standard HEX), computed its corresponding CRC, and appended it to the end of the message. The message would now be ready for transmission and could be verified upon arrival to ensure the message has not been altered whether maliciously or accidentally. It is scalable to accommodate any size polynomial and input. 
 
I really liked it because it has real life applications and it's always fun to produce something that is potentially usable rather than mindless procedural stuff found in introductory classes. Regardless this is a rather simple program and can be done by a beginner. So if you want to tackle a problem, this is a good one.
 
I've done a food bank "terminal", simple calculator, some GUI driven procedural stuff, a path finding algorithm-using program dressed up as an evacuation team searching for survivors trying to minimize zombie encounters, among others.
 
I'm currently working on an Android application in Java and a compiler in C (doing the lexical analyzer now).
 
It's still early in my curriculum so I'm hoping for more fun projects!

 

[mulveling]

C++ is easy to "learn" and extremely difficult to master. That's a good description of programming in general - it even applies to "easy" languages like JavaScript. However, the difficult-to-master part is particularly relevant with C++, relative to newer OO languages (e.g. Java, Python, C#, etc).
 
I "learned" Pascal, then C++, in my final year of high school (~ 13 years ago) - it was my first exposure to programming. I was writing nontrivial "fun" applications within the year - e.g. a home-brew ray tracer with a few non-trivial features, a 3D graphing calculator with my own "kinda" Phong shading. Used no reference to books for code (also, the internet wasn't a great resource back then), except for a single fast-polygon rendering function from a flight-sim book, which I modified to add lighting/shading effects. Did all the math and built out a horrible parser design on my own (for parsing input functions z=f(x, y) so that I didn't have to recompile to graph another surface). These were perhaps 10K line apps, but I sure as heck wouldn't list C++ on my resume now. This was not "clean" code.
 
On a second go-round, I wouldn't have picked C++ as an early language. I needed more grounding in theory to better understand how it all works under the hood - which is quite important in a language like C/C++ - as well as proper OO design techniques and design patterns (the Design Patterns book is a classic), etc. Otherwise you'll end up just hacking with no solid foundation or understanding. Then you'll have to unlearn all that hacking.
 
C++ was developed at a time when instructional-level efficiency was still extremely relevant for most applications, and compilers/interpreters/virtual machines weren't as far along as they are now with respect to converting higher-level syntax into something efficient. The result was C++ - C syntax plus Object-Oriented features, fast/efficient as hell (even when using most of the OO features) IF you the programmer don't shoot yourself in the foot. However, nowadays many application developers often have available far more processing power than they need for a given task, and in those cases you'll only be concerned with algorithmic efficiency, which is language independent. For my line of work, IMO, it pays to use a language with references, garbage collection, etc - though you still have to be aware of memory leaks caused by careless programming. I also personally like languages that are dynamically typed, offer anonymous functions/classes/etc. Still, it's good to have a solid background in pointers/malloc/realloc/delete etc.
 
Did your C++ class focus more on Computer Science theory, or just syntax? C++ can be excellent for implementing practical assignments/exercises in the former, though straight up ANSI C would probably be even better until you get into OO design. For just a synax or a "learn a popular language" course, C++ seems a rather sadistic choice.
 
I am a software dev for a living (9 years). You'd better like writing code right from the get-go. It's not going to get easier, and there are plenty of awful jobs out there. I no longer do personal side-projects - fulltime work is enough and I do enjoy my work - but for the first 5 years I spent a substantial chunk of my personal time on that stuff. Wouldn't have stuck to if so long if I hadn't loved it 1/3rd of the time, liked it another 1/3rd, and tolerated it that last 1/3rd (please note: these are aggregate percentages; not discrete periods of time - I like my current job very much).
 
If you're getting into this more, take the time to read/analyze/understand quality code from quality projects. Some open source projects can be great for that, but you'll need to start smaller at first. Wish I'd done more reading, especially early on. And theory. Don't forget theory. Be rigorous.