A friend and I will be giving a talk to a group of computer science students in a few weeks. We're both students ourselves, but are a bit older and have more working experience than the average attendee will probably have.<p>Here are some of the ideas we've had so far:<p>- Present on "using and knowing the tools" from OS to editor to libraries.<p>- Something interactive, like working as a group through one of the problems from the New Turing Omnibus.<p>- Talk about the social aspects of coding, like group dynamic and collaboration tools, and maybe introduce pair programming.<p>The audience will be mostly undergraduate CS students. My friend and I are 25, and have worked freelance and at startups/medium sized companies on mostly Rails, PHP, and Java web apps for 5+ years. We have a lot to learn ourselves, and see this speaking opportunity as a way to better ourselves as presenters and learn more about the topic we pick.<p>So, what's a good topic? What's something every CS grad wishes they had learned or heard about? Thanks in advance for your suggestions!
Don't waste your expensive and valuable college time on software engineering tools, source control, and other mundane crap that any monkey can learn quickly. Every programming tool that I learned about in college is now either unused (CVS, RCS, Motif), or dismissed by the l33t rock-stars as dinosaur technology (C++, Java, Perl). Today's l33t tools will be just as dead in ten years. Learn enough to do your assignments well, but view the time invested as a sunk cost.<p>If you want to learn how to be a coder, go to DeVry, or read some O'Reilly books and hack away. Your career will be mercifully short and uneventful.<p>If you want to be a computer scientist, spend your time learning math and theory, and learn it inside out. Then take business classes, chemistry classes, language classes, art classes -- anything to make you marketable in a non-technical way. The only way you're going to survive to old age in software (if that's even possible) is by acquiring talents that grow more valuable with age and experience -- skills that can't be cheaply exported to the next younger guy who is willing to work 80 hours a week for low wages and free soda.
Everything useful I learned about programming came either before college, after college, or when I got home from classes.<p>I'm obviously from the pro-dropout sector, but I can tell you that the one thing I've learned about learning is that for anyone successful (by pretty much any definition) I've met, most learning has taken place outside of a classroom setting.<p>Grab something hard, confusing, foreign, etc... Master it. Then move on. Learn things that are ostensibly completely useless to your job. You will do your job better than those who do not.<p>I still do take classes to help with things occasionally (there was a great arduino class at the hacker dojo recently), but even in that case, I've learned more about it on my own since the class than I did during it.<p>So here's my advice: Don't wait for other people to teach you things. Learn stuff on your own now. Maintain the expectation that you only know 10% of what you need to know.<p>And if anyone ever hears me say that I know everything worth knowing, someone please shoot me.
"Take initiative. You're not going to learn to be a programmer in college. Do open source, internships, summer jobs... Make sure you work with people better than you."<p>And then focus on getting the most out of the stuff that college is good at teaching: fundamentals and theory. Do you really want to learn how to be a practician from a career academic?
I'm in my final year of CS undergrad, and I've learned a couple of things outside of class that help me, all stuff I wish they would teach (well) in class:<p>* Learn how to write a Makefile, your builds should be one button/command away<p>* Learn how to test your code using assert.h, JUnit, whatever, just test all the fucking time.<p>* Learn GDB, stop using printf to debug.<p>* Use source control for everything, but especially group work. The groups in your classes emailing code around are doing it wrong, and by the time they'll find out, it will be to late.<p>* Spend some time in a functional language, and apply what you've learned to your Java/C/C++ class work. Minimizing side effects will minimize errors<p>Most of all though, get involved with your faculty or department, and try to affect some positive change. The connections you will make with other students and faculty could change your programming career more than anything else you do in school.
Source control, continuous integration, automatic testing. All of those things you might learn on a software engineering course but for some reason were conspicuously absent on my CS course.
How to research.<p>How to ask a question.<p>How to communicate.<p>How to come back to a program you've written after a year. Or after ten.<p>Distributed source code control.<p>Incremental development.<p>Integrated debugging. Planning for failure. For support.<p>Finding and using libraries or frameworks.<p>Backup.<p>Source code archeology; how to understand and extend and maintain complex applications.<p>How to work within a team of programmers.<p>Upward-compatibility and code longevity; the multi-edged sword of an installed base.<p>The game (tools, operating systems, languages) changes at least every five to ten years, or more often.<p>You're an integrator first, and a programmer second. Or third. When you need to.
The whole purpose of learning about technology is to make technology do something for people. So somehow we got the idea to focus exclusively on the technology and hope the people part takes care of itself.<p>Smart people can learn all sorts of interesting technical stuff. In fact, if you're smart, you're going to learn all sorts of stuff like SDLC, functional programming, OOAD, ER Modeling, etc.<p>What they don't teach you is the part about interacting with regular people -- people who have no idea how to make technical things happen.<p>Interviewing. Negotiation. Conflict resolution.<p>I know it sounds fluffy, but I see smart guys all day long. What separates the truly successful from the rest of the pack is how well they interact and solve problems for people, not tech smarts. Technical smarts [and a willingness to develop them more] are a given by the time you get into the field.
Highly relevant stackoverflow.com thread: "What is the most important thing you weren't taught in school?": <a href="http://stackoverflow.com/questions/258548" rel="nofollow">http://stackoverflow.com/questions/258548</a>
Compilers.<p>Somehow I got a BS and MS in computer science without taking a single compilers course, and I've regretted it.<p>I recently saw someone make a comment along the lines of "I'm a web developer, why would I ever want to learn about compilers?" Many people seem to think compilers are just programs like gcc that turn a language like C into machine code, but that's really just one kind of compiler.
My biggest nitpick about Georgia Tech was the lack of web-geared CS courses. The most "advanced" web-geared class was an 8-person class taught by a grad student about basic MySQL/PHP/Ajax. Of course I had the regular C, SmallTalk, Java, Matlab et cetera courses, but none of that interested me like LAMP, RoR and other stacks do.<p>Also not too many CS students early on have played with version control, and when they do it's CVS or something that was required by a class. SVN and Git should be more common in curriculum IMHO.<p>So I guess I'm suggesting you should address to these students where they can get started in web app development, because my university sure didn't help much when it came to that. Every semester I asked my academic advisor on their status of adding a Rails CS course and it was usually "same as last time.. looking for a professor that can teach it"
How to collaborate with a large team of others. We had group projects, sure, but they were small enough that usually one or sometimes two guys would do all the coding and everybody else would just fuck around.<p>The stuff you have to learn to effectively collaborate -- including task estimation, task splitting, source-management, communicating progress effectively, knowing when to ask for help, and more -- is basically what you spend the first year or two of your working career learning.<p>I don't know if it can be effectively taught in an academic context, but I really wish it had been. It's a timeless skill that transcends the actual technology used to get it done.
Don't forget about all the non-technical stuff. No one programs in a vacuum...<p>The Systems Development Life Cycle: analysis, design, development, testing, security, deployment, project management<p>Underlying systems theory, regardless of language: architecture, databases, frameworks, MVC, properties, methods<p>Underlying logic, regardless of language: iteration, branching and conditions, functions and routines, variable typing and scope<p>Anyone can go to webmonkey and learn how to write a "Hello World" program. But these basic underlying concepts that you use for the rest of your life: that's what college <i>should</i> be for.
I wish I took a software engineering class earlier than my junior year. I started programming my freshman year, and didn't realize how badly I was doing it till that class.<p>I also wish I didn't learn a compiled language first. I almost think there should be two beginner classes: lisp or python and then a unix tools class where you learn scripting.<p>Operational things like getting a box setup, code deployed, etc. would also have been nice.<p>I guess I'm saying I learned enough theory and math, and wanted more practical knowledge.
This will obviously vary depending on how much the school focusing on CS or CE, but I'd stress mastering the basics of several programming languages in different domains (e.g. C, Java, PHP, Python, Lisp). There is a lot to be taken from each of these, even if you think they suck on their own.<p>I don't think you can effectively give a talk about "using and knowing the tools" without being too specific. If you're specific you fail. Instead, I'd focus on simply drilling it in people's mind that they should feel incredibly comfortable using their editor. It's the only thing they will always be able to control and it's the only place you'll be modifying your code. I'd encourage you have them pick an OS, and a standard library for each programming language and get super familiar with it.<p>I'm not sure interaction in the form of social coding would work in a single presentation. If this were a regular thing, sure. I think you can provide greater value doing something else.<p>One thing that I feel is often missing from my fellow students is confidence. They're all a bunch of babies and school is torture for them. I think an interesting talk (and judging by your experience, I'm sure you could make it awesome) would be to emphasize the confidence and empowerment that comes with mastering a programming language and doing some cool shit with it (a side project). There are too many people in my classes that are always sinking, who have not yet realized that they can actually do cool things because they're too busy sucking at class. They need to learn something really cool on their own, which will drive them to learn and finish school because they'll finally see dots starting to connect.
First, congratulations on being offered the opportunity to talk to your peers. I would echo many of the comments here to go outside academia and CS and focus on what you have learned by coding for pay and pleasure.<p>How to build your personal online coder reputation, begin contributing to the community (open source, blogging) - focus on what you personally have done/not done and your experiences good and bad with sharing and collaborating. And what's it like starting? or working at a startup<p>My point here is focus on experiences that have made you learn. Come in as peers who have been out in the external-college real world and tell them about the real world (calibrate their expectations)<p>I think most of the students are expecting a standard tech briefing, and I challenge you to switch it up on them. Promise some soup du jour tech topic but change it to talking about the real business world (change it after audience is seated so you get the students who probably would have skipped a real-world/business topic oriented lecture).<p>One of the most valuable lectures I've ever crashed was one for Ch.Eng seniors on how to get the job you really, really want. I directly respect the impact of that lecture with giving me enough real knowledge to apprach interviewing with confidence.
I wish I had learned C++, personally. A number of the places I was hoping to work for required many years experience in it. Like or hate the language, it's used frequently. Or at least it was.<p>Some other things I wish I had done/learned:
* working with external libraries in C
* working in groups on LARGE projects<p>Something I did learn through extracurricular activities, not school work for the most part:
* SOLVING PROBLEMS!!! UVa, TopCoder, Google Code Jam, ACM Programming Contest. Learn how to take a given problem and convert it into code.
First, never confuse schooling with education<p>Second learn stuff thats in this book: <a href="http://www.amazon.com/Introduction-General-Systems-Thinking-Anniversary/dp/0932633498/ref=sr_1_1?ie=UTF8&s=books&qid=1259567705&sr=1-1" rel="nofollow">http://www.amazon.com/Introduction-General-Systems-Thinking-...</a><p>Third,The general idea of good education is to prepare you for the future rather than learning about the past
Make up (or find) as much gnarly, twisted data as needed to throw at your code to convince yourself that it will respond gracefully no matter what comes along. (Then if you can, get someone else to.) If it can't - or you can't test all conceivable ways it can fail - then you need to either rethink your design or switch languages.
I used to be quite concerned that all my major programming projects were for my own business, and as a result I figured that I had to be missing some sort of 'process' step that would mean I was developing software the <i>right way</i>.<p>Being walked through a few different development lifecycle models would have helped to put my mind at ease.
Experience is the best teacher. Just build programs! The more you build, the better you'll be. Note how I said build, not write. Think about it.<p>Oh yeah, and contributing to open source is the bomb. You learn so much about real-world applications of your knowledge.
I went through a "Information Science and Technology" program rather than a "Computer Science" program but the one thing I <i>really</i> felt like I missed out on was gaining experience using svn/git/etc in teams.