I was fortunate enough to attend a school for a year that had an amazing library. Not just for computer science, but for everything, from what I've heard. Clearly, since I'm a software guy, I only cared about their collection of computer science books, and they certainly didn't disappoint.
If you could find it on O'reilly, you could find it in this library. After I went there for the first time, I was hooked. Never in my life had I viewed going to the library as an exciting experience. I wanted to go to the library. I'd spend 90 minutes browsing the shelves.
Then, for reasons we won't go into, I transferred schools. I ended up at a pretty decent community college for a year while I was transitioning, and I was deeply saddened by what I found in that library. So, what's my point?
Those books are there for a reason, and they are free. Take advantage of them.
Computer science is one of only about a handful of professions that is pretty "take-home". Maybe that isn't true for everyone, but the vast majority of people in this line of work, namely programming, take their work home with them. It's not necessarily because they are work-a-holics, but simply because they love doing what they do. Their brains don't allow them to just "turn it off" and leave some programming issue for the office. They enjoy solving problems. Unfortunately, sometimes people's jobs depend on them taking their work home with them, but we won't get into that. In fact, this paragraph needs to be it's own entry, so I digress...
Basically what I'm saying is that you can't be the best programmer that you'd like to be by relying on your college courses to teach you what you need to know. I may not be done with school yet, but I'm not exactly naive on this matter. Your college classes teach you very little about what being a programmer means. In part, it's not their fault. They have to keep things at a general level to allow for a vast number of technologies that the students may have to work with. Still though, you have got to put in the work outside the class room. I don't think I need to belabor this point too much as if you've made it through at least 2.5 years of a CS/SE degree, you truly do love what you are doing. Also though, you will be expected to continue to learn when you graduate. You'll have to use a language at work that you may hate, or may not know at all. You'l have to learn API's you've never even heard of, etc... but you can't give that as an excuse to your boss. There will be some degree of toleration for your lack of experience in a particular area, of course, but when it comes down to it, if you want to keep your job and do well at it (which in-turn means you'll enjoy it a hell of a lot more), you've got to put some effort in "off the clock". I'm not saying you have to ssh in, vnc, whatever...and start writing your work code from home, but you will have to crack a book (or 5 as I find myself doing) and soak up some knowledge.
Take advantage of your schools library instead of taking it for granted. You'll be surprised how much you enjoy reading. Not a bad place to meet girls either, especially when you are carrying around fancy sounding programming books...
Friday, March 14, 2008
There's more to coding than...well.... coding.
Learning how to write software is really a tiny piece of what it means to be a programmer. Let's be honest, writing code is actually pretty easy to do. You spend a few years learning how the basic logic structures work, the looping, function calls, return values, blah blah blah. After that, the most work you put in is studying some new API or learning the nuances of some new language. All in all though, it's not terribly hard to do.
Unfortunately, there's a lot more to it than that. The book series "Effective C++" by Scott Meyers (I've provided links at the end of this entry to all of the items I rave about, so no need to fire up Google) really opened me up to this notion. It was the first book I had read about programming that didn't teach you how to write code, but how to write proper code. Actually, not just proper code, but great code. It was such a breath of fresh air to pick up a book about programming and not have to see the same step-by-step teaching process. Books like this (you should have already gone and checked it out from your library by now...if not, stop reading and go. now. I'm waiting.) focus on things that too many programmers neglect: writing proper, efficient code that does exactly what you intend it to do, and does so very nicely.
But again, that's just another piece of the puzzle. I've been browsing some programming blogs recently and I came across this one: http://www.gamesfromwithin.com/ There is some really great content in there and I encourage you to check it out. The relevance for this discussion is that the author is a big proponent of agile development and test driven development. If you aren't familiar with those concepts, I hear Google works quite well. The basic run down of agile development is that it's a production mechanism of sorts that stresses quick iteration of software based on client feedback (whether the clients are other programmers working on other features or your actual end-users depending on the type of project you have). A main element of agile development tends to be a team oriented approach that involves things like XP (2 programmers working side-by-side on the same piece of code).
For an example of how well these things can work, check out this entry in the above mentioned blog: http://www.gamesfromwithin.com/articles/0602/000104.html You'll be amazed at how much work gets accomplished with this method.
Test driven development follows with the iterative theme in that you essentially reverse the coding process. How? With the use of a unit testing framework, you write your tests before you write your code. Clearly, the test should fail. Then, you write just enough code to make that simple test pass. The key word there is simple. The tests you design should be very small and simple to implement. The author of that blog suggests between 1-2 minutes to design the test, and not much more than 15 to implement the code to pass the test. "Test Driven Development" by Kent Beck seems to be a godsend book on this design methodology. I just picked it up from the library yesterday and it's very helpful in outlining the process, go get it!
These are just 2 examples of design methodologies in software engineering, but there are a ton of other ones. Some work better for certain things, but the point is that this stuff matters. It's vital in a professional software development environment. Without things like this, nothing would get done, and even if it did, the result would be awful. I encourage you to start learning about this stuff while you are still in school, because chances are you won't have too much meaningful class time devoted to things like this. All of it can only serve to make you a better programmer.
This is where the distinction between "Computer Science" and "Software Engineering" comes in. Software engineering is devoted to stuff like this. It's all about the design, the planning, the process. Computer science tends to be focused on the implementation alone. The curriculum in colleges today leaves much to be desired in my book. How can you send CS majors out into the work field with very little knowledge of software engineering principals? To me, they go hand in hand. You can't write any sort of decent code without a design or a planning process. What about a roadmap or schedule for the project? You can't just "wing it" and expect any worthwhile results to come out the other end. Some people think all of this "management" should be the responsibility of the projects "manager". Maybe so, but I don't think it's black and white. The project manager can't write your test cases for you. The project manager (in the sense that most people think of him/her in) can't set realistic and useful code milestones for you. As a programmer, you can't get to where you need/want to be unless you know where that place is before you start.
I encourage you to read as many blogs by professional developers as you can. These people are wise beyond my years, so I could go on and on, but you're better off hearing it out of their mouths (or fingers...) than having me repeat to you what I've learned from them. The "Games From Within" blog above is really outstanding. I learned more about software engineering in a few hours than I have in 3 years of college. In addition, look for some language-specific blogs by some seasoned vets as well. These blogs tend to focus on many similar topics that the "Effective C++" series does. That is to say, the "how to do it right" as opposed to just the "how to do it". I found this site the other day and it has a wealth of information from blogs by over a dozen different professionals, to regular articles: http://www.artima.com/index.jsp
Good luck, and remember: learning how to program is just the first small step in being a software developer.
Resources You Need To Check Out
Websites / Weblogs
Unfortunately, there's a lot more to it than that. The book series "Effective C++" by Scott Meyers (I've provided links at the end of this entry to all of the items I rave about, so no need to fire up Google) really opened me up to this notion. It was the first book I had read about programming that didn't teach you how to write code, but how to write proper code. Actually, not just proper code, but great code. It was such a breath of fresh air to pick up a book about programming and not have to see the same step-by-step teaching process. Books like this (you should have already gone and checked it out from your library by now...if not, stop reading and go. now. I'm waiting.) focus on things that too many programmers neglect: writing proper, efficient code that does exactly what you intend it to do, and does so very nicely.
But again, that's just another piece of the puzzle. I've been browsing some programming blogs recently and I came across this one: http://www.gamesfromwithin.com/ There is some really great content in there and I encourage you to check it out. The relevance for this discussion is that the author is a big proponent of agile development and test driven development. If you aren't familiar with those concepts, I hear Google works quite well. The basic run down of agile development is that it's a production mechanism of sorts that stresses quick iteration of software based on client feedback (whether the clients are other programmers working on other features or your actual end-users depending on the type of project you have). A main element of agile development tends to be a team oriented approach that involves things like XP (2 programmers working side-by-side on the same piece of code).
For an example of how well these things can work, check out this entry in the above mentioned blog: http://www.gamesfromwithin.com/articles/0602/000104.html You'll be amazed at how much work gets accomplished with this method.
Test driven development follows with the iterative theme in that you essentially reverse the coding process. How? With the use of a unit testing framework, you write your tests before you write your code. Clearly, the test should fail. Then, you write just enough code to make that simple test pass. The key word there is simple. The tests you design should be very small and simple to implement. The author of that blog suggests between 1-2 minutes to design the test, and not much more than 15 to implement the code to pass the test. "Test Driven Development" by Kent Beck seems to be a godsend book on this design methodology. I just picked it up from the library yesterday and it's very helpful in outlining the process, go get it!
These are just 2 examples of design methodologies in software engineering, but there are a ton of other ones. Some work better for certain things, but the point is that this stuff matters. It's vital in a professional software development environment. Without things like this, nothing would get done, and even if it did, the result would be awful. I encourage you to start learning about this stuff while you are still in school, because chances are you won't have too much meaningful class time devoted to things like this. All of it can only serve to make you a better programmer.
This is where the distinction between "Computer Science" and "Software Engineering" comes in. Software engineering is devoted to stuff like this. It's all about the design, the planning, the process. Computer science tends to be focused on the implementation alone. The curriculum in colleges today leaves much to be desired in my book. How can you send CS majors out into the work field with very little knowledge of software engineering principals? To me, they go hand in hand. You can't write any sort of decent code without a design or a planning process. What about a roadmap or schedule for the project? You can't just "wing it" and expect any worthwhile results to come out the other end. Some people think all of this "management" should be the responsibility of the projects "manager". Maybe so, but I don't think it's black and white. The project manager can't write your test cases for you. The project manager (in the sense that most people think of him/her in) can't set realistic and useful code milestones for you. As a programmer, you can't get to where you need/want to be unless you know where that place is before you start.
I encourage you to read as many blogs by professional developers as you can. These people are wise beyond my years, so I could go on and on, but you're better off hearing it out of their mouths (or fingers...) than having me repeat to you what I've learned from them. The "Games From Within" blog above is really outstanding. I learned more about software engineering in a few hours than I have in 3 years of college. In addition, look for some language-specific blogs by some seasoned vets as well. These blogs tend to focus on many similar topics that the "Effective C++" series does. That is to say, the "how to do it right" as opposed to just the "how to do it". I found this site the other day and it has a wealth of information from blogs by over a dozen different professionals, to regular articles: http://www.artima.com/index.jsp
Good luck, and remember: learning how to program is just the first small step in being a software developer.
Resources You Need To Check Out
Websites / Weblogs
- http://www.artima.com/index.jsp
- http://www.gamesfromwithin.com/
- http://powerof2games.com/
- http://www.aristeia.com/
Monday, March 10, 2008
There's room for everyone
One of my biggest problems to date has been that I get discouraged when I look at what's already been accomplished in this field. When you are sitting down to work on a trivial idea you've come up with, it's easy to stop and say "Wow, do you have any idea how complex the GCC compiler is? What the hell am I doing with this simple program?!" It's an easy trap to fall into, but a deadly one.
We can't all be John Carmack, Bill Gates, Linus Torvalds, etc etc etc... but that doesn't mean we should find a new profession. Implementing those trivial ideas are essential for growing as a developer, and if you don't go through that process you'll never get to where you want to be. John Carmack didn't roll out of bed one day and write a 3D game engine. He had years of programming experience. Granted, he's a very intelligent man when it comes to math and science, regardless of his programming abilities, but again, he's one of the many exceptions. Most people simply aren't that gifted. However, if programming is the field you want to be in, you can work hard enough at any area of it and become proficient.
The only remedy I've found for this issue is that when you have an idea for a piece of software you'd like to create, don't "Google it". Most ideas that most of us have will be based off of some piece of software that is already in use. Going to Google to check out some of those applications is only going to worsen this issue. I like to get off of my computer, grab a pen and paper and start designing the system "offline". It's actually a lot more productive than sitting in front of your monitor, and you can't get discouraged if you pretend that nobody has ever made this piece of software before.
Going back to the trivial nature of some of the programs we may write... Just as programming books start you off simple before branching into pointers, objects, templates, data structures, etc... you should be doing that with your code. Now, this tends to happen naturally anyways since you can't well write code involving things you don't yet know how to do, but I know I've certainly tried. Not to say that it's always a bad thing to test new waters, but you shouldn't really make a habit of doing something until you understand it. A book progresses rather quickly, but your projects should progress much more slowly in terms of the complexity of the underlying software. This is paralleled by the fact that you cannot simply read a programming book front to back as if it were a novel, it must be an interactive experience in which you are typing the code from the book, doing the examples, doing the projects, etc... The more time you spend building the complexity of your projects up, the better off you'll be in the long run because you'll have an expert-level understanding of everything you've done, which will then make the transition into the really advanced stuff easier.
A great way to do this is to develop your software idea just like a mainstream piece of software. Have iterative releases of your application, adding new features and refactoring code along the way. Make a habit of creating a "TODO" list after each release so that you have specific points to focus on. Ideally you'd have setup some sort of road map at the outset of the project, so you should already have some direction in this regard. Set stern, but reasonable deadlines for your releases, manage a blog documenting the process, invite others to use your applications (friends are fine, as long as they will give honest feedback), etc... Doing all of these things will keep you excited about your project, focused on your project, and you'll absorb a lot more of the techniques than if you just fleshed out your initial idea and say "Meh, that's cool I guess...".
Hope this helps.
We can't all be John Carmack, Bill Gates, Linus Torvalds, etc etc etc... but that doesn't mean we should find a new profession. Implementing those trivial ideas are essential for growing as a developer, and if you don't go through that process you'll never get to where you want to be. John Carmack didn't roll out of bed one day and write a 3D game engine. He had years of programming experience. Granted, he's a very intelligent man when it comes to math and science, regardless of his programming abilities, but again, he's one of the many exceptions. Most people simply aren't that gifted. However, if programming is the field you want to be in, you can work hard enough at any area of it and become proficient.
The only remedy I've found for this issue is that when you have an idea for a piece of software you'd like to create, don't "Google it". Most ideas that most of us have will be based off of some piece of software that is already in use. Going to Google to check out some of those applications is only going to worsen this issue. I like to get off of my computer, grab a pen and paper and start designing the system "offline". It's actually a lot more productive than sitting in front of your monitor, and you can't get discouraged if you pretend that nobody has ever made this piece of software before.
Going back to the trivial nature of some of the programs we may write... Just as programming books start you off simple before branching into pointers, objects, templates, data structures, etc... you should be doing that with your code. Now, this tends to happen naturally anyways since you can't well write code involving things you don't yet know how to do, but I know I've certainly tried. Not to say that it's always a bad thing to test new waters, but you shouldn't really make a habit of doing something until you understand it. A book progresses rather quickly, but your projects should progress much more slowly in terms of the complexity of the underlying software. This is paralleled by the fact that you cannot simply read a programming book front to back as if it were a novel, it must be an interactive experience in which you are typing the code from the book, doing the examples, doing the projects, etc... The more time you spend building the complexity of your projects up, the better off you'll be in the long run because you'll have an expert-level understanding of everything you've done, which will then make the transition into the really advanced stuff easier.
A great way to do this is to develop your software idea just like a mainstream piece of software. Have iterative releases of your application, adding new features and refactoring code along the way. Make a habit of creating a "TODO" list after each release so that you have specific points to focus on. Ideally you'd have setup some sort of road map at the outset of the project, so you should already have some direction in this regard. Set stern, but reasonable deadlines for your releases, manage a blog documenting the process, invite others to use your applications (friends are fine, as long as they will give honest feedback), etc... Doing all of these things will keep you excited about your project, focused on your project, and you'll absorb a lot more of the techniques than if you just fleshed out your initial idea and say "Meh, that's cool I guess...".
Hope this helps.
Tuesday, March 4, 2008
College Courses
When I transferred to my current school last year, I heard a big buzz about a change in the department from C++ to Java. At my previous school (a very, very good one), Java was the focus of the curriculum. We did a lot of advanced things with Java, and although I don't use Java as my primary language, I learned a lot about programming. C++ was used to teach pointers primarily, but some of the OOP concepts were also presented of course. Now, the difference between that school and the one I'm at now is that this school is on semesters instead of quarters. At my old school, you could ideally finish all of your Java courses in your first year of school, thus opening the door for more specialized courses that didn't force you to use a certain language. The main issue of this post is to discuss the programming curriculum that I think should be in place in most schools, but isn't.
Below is a basic outline of the flow of programming courses that I would prefer be offered:
My main concern is that a lot of kids will graduate from school with zero ability to program in anything other than Java. That's more of a reality than you may think, especially when C++ is essentially being removed from the curriculum of some schools. The bottom line on this is that C++ is widely used, and that isn't going to change. In fact, in some areas of Computer Science, namely Game Programming (console/PC), C++ is king.
More and more I'm finding kids in my CS courses that have never done a lick of programming work before coming to college. The market is always good for Computer Science, so they decide to pursue it as a career. These are one of groups of people that I have in mind when I say you can't go from Java and learn any language. The popular argument against this is that C/C++ is too complicated for these people. Maybe so, but I don't agree with that if the course is taught properly. Secondly, think of it as a "weed-out". It seems the popular choice for a "weed-out" course at a number of schools is discrete math. While I understand the concepts presented are important, I don't view them as things that are specific to this course. I think you garner all of the logic you need to in your programming courses/experiences. Secondly, I don't think this course serves as any sort of useful primer for a data structures course, and at a lot of schools that is how they have the pre-reqs set up. The only logical reason to do that is to "weed-out" kids that may not be cut out for this line of work. I think a more useful test would be teaching C/C++ as a first language as opposed to Java. After all, if you can't design and write solid code, you won't have a job very long. Anyone can sit down and work out logic puzzles.
Just my two cents.
Below is a basic outline of the flow of programming courses that I would prefer be offered:
- C - Focus on basic programming logic, functions, recursion, arrays, and introduce structs.
- C++ - Pointers and memory management, heavy focus on OOP from novice to expert topics. I would choose to wait until now to deal with memory management because a lot of bad habits get formed when you do this stuff in C without knowing what you're doing.
- Java - Heavy focus on interfaces/abstract classes. The most confusing things to most people in Java is having to extend the standard library, override functions, etc...
- C# - With this language coming into popularity, it's a must have.
My main concern is that a lot of kids will graduate from school with zero ability to program in anything other than Java. That's more of a reality than you may think, especially when C++ is essentially being removed from the curriculum of some schools. The bottom line on this is that C++ is widely used, and that isn't going to change. In fact, in some areas of Computer Science, namely Game Programming (console/PC), C++ is king.
More and more I'm finding kids in my CS courses that have never done a lick of programming work before coming to college. The market is always good for Computer Science, so they decide to pursue it as a career. These are one of groups of people that I have in mind when I say you can't go from Java and learn any language. The popular argument against this is that C/C++ is too complicated for these people. Maybe so, but I don't agree with that if the course is taught properly. Secondly, think of it as a "weed-out". It seems the popular choice for a "weed-out" course at a number of schools is discrete math. While I understand the concepts presented are important, I don't view them as things that are specific to this course. I think you garner all of the logic you need to in your programming courses/experiences. Secondly, I don't think this course serves as any sort of useful primer for a data structures course, and at a lot of schools that is how they have the pre-reqs set up. The only logical reason to do that is to "weed-out" kids that may not be cut out for this line of work. I think a more useful test would be teaching C/C++ as a first language as opposed to Java. After all, if you can't design and write solid code, you won't have a job very long. Anyone can sit down and work out logic puzzles.
Just my two cents.
Monday, March 3, 2008
Why put a go-kart engine in a Camaro?
I was browsing some projects on Sourceforge yesterday and I came across a basic game of Checkers. I believe they were using GTK and maybe SDL as well. All of the source files were C++. Now, SDL works natively in C++, but as far as I know, you'd need to use GTKMM in order to write GTK code in C++. Nevertheless...
This person usesd absolutely NO features of C++ in his code. It was all straight-C. I really don't understand this at all. Why incur the extra overhead of the standard C++ libraries and then not use them? Secondly, why use C if you don't need to? When I say that, I'm referring to the need to do a lot of low-level memory manipulation, in-line assembly, and other things of the like. Of course, any of that stuff can be done in C++, but usually C is preferred. This application had none of that in it. It was just a bunch of structs, char*'s, and SDL/GTK library calls.
My stance on this particular instance is to just use C++ instead of simply changing the file extension to ".c". std::string is a lifesaver, and the C-style structs just get clumsy and very limited after a while, especially in a game. Those 2 things alone would have made the game more extensible, easier to maintain, and a lot easier to understand.
Just my two cents.
This person usesd absolutely NO features of C++ in his code. It was all straight-C. I really don't understand this at all. Why incur the extra overhead of the standard C++ libraries and then not use them? Secondly, why use C if you don't need to? When I say that, I'm referring to the need to do a lot of low-level memory manipulation, in-line assembly, and other things of the like. Of course, any of that stuff can be done in C++, but usually C is preferred. This application had none of that in it. It was just a bunch of structs, char*'s, and SDL/GTK library calls.
My stance on this particular instance is to just use C++ instead of simply changing the file extension to ".c". std::string is a lifesaver, and the C-style structs just get clumsy and very limited after a while, especially in a game. Those 2 things alone would have made the game more extensible, easier to maintain, and a lot easier to understand.
Just my two cents.
Subscribe to:
Posts (Atom)