Wednesday, September 5, 2012

Lessons I Wished I'd Learned Earlier As An Undergrad

Having worked at a real company now for several months, I've been given the opportunity to go back to my Alma mater and participate in a lecture with some up-and-coming students. And get free food, of course, since this is a university event. I received fairly short notice (5 days) to come up with something engaging to talk about for anywhere between 5 and 20 minutes.

The topic: Lessons Learned After Graduating That Would Have Made University a whole helluva lot easier. Here's a short list of things I'm considering:
  • Involvement
    • Find groups that encourage development of your programming skills including user groups, tech lectures, open-source projects, and startup weekends.
  • Use IDEs
    • Why did this one take me so long to figure out? At my university, they taught us to use MATLAB freshman year (which hardly qualifies as an IDE without any form of auto-complete), and they showed us how to install Netbeans and Eclipse my senior year (but did not encourage us to use them. They also taught us how to use a VHDL IDE my senior year, but that's a different subject. Using IDEs greatly increases productivity, syntactical consistency, and enhances organization. A problem is that it can dumb a programmer down by not forcing them to look things up, and a dev can become lazy using auto-complete all the time.
  • Reach outwards
    • Don't do what you always do. Do things that you've never done before. My degree had a strong focus on C: so I did almost all projects where I was given a choice in either C or (eventually) C++. Given a distant deadline, a project could be started in any number of interesting languages, including Ruby or Perl or CoffeeScript or Scala.
  • Don't do an activity just for your resume
    • This one is the worst. People join a half-dozen clubs just to pad their resumes. This should not be done. Join one or two clubs that you're passionate about instead, and put a lot of time and effort into making that organization better. Companies will be far more interested in your automation of the secretary position in your Linux Club than your perfect attendance at your Rock Band Club.
  • Use Office Hours
    • Stuck on something? Go to office hours. It doesn't matter if it seems mundane, or the professor already explained it in class, or you skipped the lecture on this material, you will save yourself a world of time by going to office hours.
  • Don't avoid lesser-known companies
    • When I went to career fairs, I would be sure to visit all the companies on the list that I recognized. I would walk up to these companies, hand them my resume, walk away, and likely be offered an interview via email several days later. However, one career fair I took it upon myself to stop by several companies of which I had no idea what they were. So I stopped and I asked them if they were looking for someone like me. Some said yes, some said no. The ones who said yes took my resume, talked to me about all the information on it, and signed me up for an interview on the spot. The larger companies seemed distant and made me feel like a hamster in a cage. The smaller companies were warm to me and made me feel like a real person.
  • Be "That Person"
    • We won't have to worry about the project if we have "that guy" in our group. "That guy" works hard and gets the job done. Just do it. Work late. Understand things. Become an expert in whatever project you're working on. Your groupmates will respect you and any presentations you give will show off your vast amounts of knowledge.
  • Use the internet
    • Stuck on something that you know hundreds of other people have already solved? Use the internet. The internet knows the solution to that integral. The internet knows how to create a stack using a linked list. The internet knows how to get that program installed on your dev machine. You'd be surprised at what seemingly arbitrary things you can find answers to on the internet.
  • Learn keyboard shortcuts
    • Makes you more productive. I could list some, but they're on the internet.
  • Write down everything
    • You say you solved this problem three weeks ago but now you can't remember how to do it? The professor has your homework with the solution on it but never got it graded? You found some awesome Ruby syntax to do 10 lines of work in a single keyword? You should write these helpful things down in a notebook somewhere. Have several notebooks for several different topics. You'll thank yourself later.

No comments:

Post a Comment