この記事は1年以上前に書かれたもので、内容が古い可能性がありますのでご注意ください。
Before I begin I should probably clarify that I had a great college experience. The school I attended had a very solid Computer Science program, and many of my professors did an excellent job of making their classes both fun and effective.
In addition to my classes I had several friends at the school’s Computer Club. I’ve often joked that I learned more from my friends in casual discussions than I did in all my classes combined. There’s certainly some truth to that. There was a lot I learned from projects and discussions with my friends that couldn’t be learned in class (for example, a weather balloon/GPS project we worked on, pictured above). Most individuals who really love their work will probably tell you that being around people with a similar passion for what they do results in massively increased productivity and learning. Just being in the Computer Club office for a few hours over the course of a day would almost certainly mean learning something completely new. Even going out for a beer after a meeting usually meant discussions about computer-related topics that were much more interesting and advanced than anything offered by the school. I sincerely believe that being in the Computer Club was one of the things that kept me motivated and reminded me why I loved Computer Science, even when school felt like a chore.
With that said, there are several things my classes didn’t prepare me for. Admittedly, many of these are skills that can only be learned through experience or trial-and-error. On the other hand, many types of engineering are very hard to teach effectively using traditional methods of education. It seems that teaching methods are lagging behind field development for engineering, especially for Computer Science courses. These are just a few of the things I’ve had to learn the hard way:
1. Use the Right Tool for the Job
What they taught me:
There are a few tools for most jobs, but any “good enough” application can be applied as a blanket-solution to most related issues.
What I learned:
Though most classes allowed students to use their choice of development tools (and even programming languages), they did little to combat their students from creating dogmatic attachments to certain languages, architectures, or software applications. In fact, very few “tools” were presented to the students (perhaps as a result of a partnership the school has with Microsoft). This is not to say that open-source options weren’t presented. In fact, many of the most ferocious and defensive contingents were related to open source Unix or GNU-based operating systems. The larger issue isn’t that students form these attachments (familiarity is an extremely powerful motivator), but that educators rarely discourage them from gradually deepening. The result is a generation of software developers using less-than-optimal solutions for any given project.
Don’t get me wrong, Microsoft’s Visual Studio package is great for developing large GUI-oriented programs like games and graphic design environments, but many students in my classes were at a loss when they were required to use the gcc compiler in a terminal-based environment. I’ve since learned that while having preferred applications for different functions is perfectly healthy, those preferences should be questioned for each new project. I’m definitely not flawless in that regard (I used nano for years because the notion of learning to use vim was daunting), but I hope to improve.
2. Writing Secure Code
What They Taught me:
Virtually nothing.
What I Learned:
Hundreds of the practices I had been using (and instructed to use) were so absolutely dangerous that I’m amazed that this subject was never even skimmed in my classes. In fact, a massive proportion of the code samples my instructors provided contained glaring security holes. Not only that, the solutions to those security holes were often something as simple as changing two or three characters in a single line of code to prevent a potentially system-compromising format string vulnerability. It wasn’t until I started studying computer security independently that I realized just how dangerously flawed some of my code was. Panic-stricken, I removed execution permissions from every project I had written to that point until I could correct each source code file by hand.
3. Estimating Deadlines
What they taught me:
Very little, considering most projects were roughly the same size (apart from semester-projects), and could be completed in only a few hours. As long as a project was on time (or close to it), there was no need to estimate the total number of hours needed to complete the project. One class took the opportunity to suggest that project time estimates should generally be doubled to allow for debugging and other delays, but time requirements should have been an integral part of the learning process for any developer.
What I learned:
When I took fifteen hours to complete a project that I estimated would require only ten, I wasn’t simply missing the mark by five hours. More importantly, I was missing it by 50%! Even worse, those errors in judgement only affected me, so there was no disappointed client to help condition me to hit the mark the next time. Waking after only four hours of sleep because of a project I under-estimated was inconvenient, but two energy drinks in the car and a cup of coffee while I was in class were more than enough for me to pull through. This is one of those skills that most developers get better at with practice, but there is certainly more that could have been done to prepare me for “real world” deadlines. At this point all I really know is that I need to work at cost and time estimations, because I still tend to miss the mark by at least 20%.
4. Confidence
What they taught me (well, this is more something I was conditioned to feel…college can be TOUGH!):
Life is soul-crushing and stress can be absolutely paralyzing. Everyone “gets it” but you, and you’d probably be better suited to selling your blood than writing software.
What I learned:
Yes, that was a bit dramatic, but I’m sure many people know exactly the feeling I’m describing (including people much, much smarter than me). I honestly believed I was likely to be in the bottom 10% of my classmates in terms of actual coding ability. This continued fairly consistently for several years. Whenever I mentioned something technical in a conversation that the other person didn’t immediately seem to grasp I assumed they were either mocking me for my primitive understanding of the concept, or I had just said something very…very stupid. It wasn’t until much later (read: recently) that I realized that there were a massive number of topics about which I knew virtually nothing, but a few that I had actually become relatively competent in.
I learned that the nature of learning involved being constantly bombarded with a seemingly endless stream of new information. In a situation like that, it’s easy to feel extremely ignorant. It wasn’t until I was in a professional setting that I learned that although I would always continue learning and growing, my working knowledge of my field will probably remain sufficient. In short, I realized that I “got it”.
2024/09/13
2024/05/17
2024/05/10
2024/01/05
2023/08/18
2023/07/14
2023/05/12
2023/04/21