Posts by Ryan:
- Study
- Eat Pizza
- Go to Parties
- It gave me the chance to make a difference on campus. Through Student Government and Connect with Tech, I was able to make a positive impact on my fellow Tech students.
- It gave me the chance to try new things. Public speaking terrified me before I started at Tech. Getting involved in the way that I did thrust me in front of crowds more times than I can count. Not only did this exposure help me overcome my fear of public speaking, it helped me become pretty darn good at it.
- I met a ton of new people. I met many of my best friends through the various organizations I was involved with. People I might never have spoken to otherwise. That might be one of the biggest benefits. Not only that, but I made a lot of professional contacts. (See “Network” below)
- I got leadership experience. I will never know exactly why corporate recruiters picked me, but I have a pretty good hunch that they were attracted to my leadership experience. I had a proven track record of success. Plus, it helped me develop as a person.
- Print business cards. When you go to networking events, having a business card means they won’t just forget about you when they’re done talking to you. Not to mention the majority of your counterparts won’t have business cards to hand out. This gives you a leg up.
- Go to corporate receptions and information sessions. Georgia Tech hosts a TON of information sessions and corporate receptions. The former is generally organized by the company, and gives you some face time with their recruiters and staff. The corporate receptions are typically organized by The Institute, and they want to bring in proactive students so they can show you off. Events like these give you a great opportunity to talk to recruiters in a more relaxed context.
- Volunteer for Career Fairs. Sure, you can go to the career fair, and get lost in a sea of black suits, and I’d encourage you to do so. Unfortunately, these are not the best way to meet people. The venue is crowded, you only get a couple of minutes of face time, and there is little you can do to set yourself apart. But if you sign up to volunteer, you will spend your day bringing them water, food and chit chatting to make sure they’re comfortable. They get a chance to interact with you on a more personal level, and they will see that you are working hard. Hand out a few business cards at the end of the day and they will probably not forget about you.
- I met the recruiters for ConocoPhillips at a corporate reception. I walked up, introduced myself, and was invited to interview on campus the following day.
- I met the recruiters for Microsoft at a restaurant on campus (Moe’s Southwest Grill, in case you were interested.) I was volunteering at the career fair that day, so I knew who they were, and when they finished their meals I walked over to say hello and give them my business card. They invited me to walk back to the career fair with them, and I got a call back for an interview later that afternoon.
- Management is taking out the trash.
- “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” — George S. Patton
- “In preparing for battle, I have always found that plans are useless but planning is indispensable.” — Dwight D. Eisenhower
On “Getting Out”
May 13th, 2011
Thanks to Angie (linked at the end) for Graduation Day photos!
Five Years. 132 credit hours. Over 2 GB of email. Three or four dozen all-nighters. More tests, quizzes, and homeworks than I can count. That’s the most obvious way to sum up my college experience. But it doesn’t seem to do it justice.
The five years I spent at Georgia Tech were possibly the five most important years of my life thus far. I learned a lot about technology, business, and (perhaps most importantly) myself. It’s been a couple days since I strode across the stage, and the reality of the situation hasn’t quite set in yet. Nonetheless, I’ve spent a great deal of time reflecting during the last 72 hours. Reflecting on what I learned, where I’m going, and what it really means to be a Yellow Jacket. I have tried to think of a phrase or tagline to describe it, but that’s harder than it sounds. So instead, I’ve compiled a couple of bits of advice for current and future Georgia Tech students, and maybe students at other institutions could benefit as well.
Get Involved
When I first arrived on campus, I had a college plan that could be distilled into three parts:
It was a grand plan, constructed over many years of watching Real Genius and Animal House. After a few months of it, I started to wear down. I didn’t have a lot going on. I had some great friends, and I was learning, but on a day to day basis, my life was becoming monotonous (I even tried branching out from pizza to chicken wings). It was at the beginning of my second year that I set out to get involved on campus. I applied to be a host for Connect with Tech, an overnight visitation program for high school students. Fast forward a few years, and I found myself involved in more than four organizations, and I was spending more time in meetings than in class. But most importantly, I felt fulfilled. Getting involved gave me a lot of things.
Be Irresponsible…Just Not Often
Some of the closest friendships I developed during my college career were
Working hard at a Connect with Tech Session
strengthened by general mayhem. The adventures ranged from simply staying out too late on a school night, to hopping a fence to a closed pool in the dead of winter, to constructing fake identities to make our way into the VIP section of a club (it didn’t work). Few things strengthen a bond like doing something crazy.
I think this is where a lot of college students go wrong — they either take irresponsibility too far and flunk out, or they err on the side of caution and miss opportunities for silliness. The cautious approach certainly works better than partying all the time (academically, anyway) but I think there’s a happy medium. I tried to strive for generally responsible, dependable, but not boring.
Network
The old adage goes “it’s not what you know, it’s who you know.” There’s a lot of truth to that, but I think a more accurate version would be: “It’s not what you know, or who you know, it’s who knows you.” It wasn’t until I started looking for internships that I truly realized the importance of networking. The truth of the matter is, of the job offers I have received (for full time jobs and internships) not one came without personally making a contact within the company. I submitted my resume through all kinds of online tools, and I got a couple of callbacks, but my ratio of callbacks to submissions was probably close to 1:20. In instances where I made a contact within the company and attempted to get an interview, my ratio is nearly one-to-one. In fact, every job offer I received for full time positions after graduation was the result of reaching out to an individual personally.
So what do I recommend? Here are just a few suggestions:
But the most important rule of networking is be genuinely interested in getting to know people. It’s easy to tell the difference between someone who is chatty for the sake of furthering their career and someone who is friendly and engaged. Ask questions. Lots of them. You can learn something from everyone, and realizing that is the first step to being a successful networker. Talking to strangers wasn’t in my nature when I arrived on campus. I had to work my way up to it. It was well worth it.
Fun facts about my experiences with networking:
Conclusion
In the beginning I said I couldn’t come up with one sentence to sum up my college experience. I still can’t. But after writing this entry, I can come up with one that’s kind of close. It’s not only how I feel about my time at the Institute, but about life in general: Do something that scares you. And never stop. The scary experiences are the ones that you learn from. You emerge from them stronger and more prepared to take on the world than ever. They allow you to stretch yourself, to try new things, and to really learn who you are.
Moving away from my family and friends to go to school at Georgia Tech made me anxious, giving my first tour scared me, walking up to strangers and handing them my business cards terrified me, moving 2,500 miles away from everything familiar to start a new career in Seattle scares the hell out of me. But I know that, like all the other adventures, it’s going to be good for me. So sure, I’m scared. Am I excited? Absolutely.
Georgia Tech has done an incredible job of preparing me for whatever is to come, and I can say with 100% confidence that I would not be who I am today without my experiences at The Institute.
Go Jackets!
With Jordan and Randall on Graduation Day
Graduation day photos courtesy of Angie Watson.
An Unlikely Project Manager
January 9th, 2010(Author’s Note: This is an old post from January 2010, restored from the old blog. Old comments were not transferred along with the content.)
On January 11th, I will begin my next adventure at Georgia Tech. I’m not really talking about Spring Semester 2010, which should be another chapter of Georgia Tech life. I’m referring to the fact that I will be embarking on my first adventure in project management. As the Information Technology chair for Georgia Tech’s Student Government Association I have a variety of responsibilities. Until this time, most of those responsibilities involved adding/modifying content on SGA’s website (and sitting in a lot of meetings, of course.) Next semester my committee is going to undertake a comprehensive rewrite of Course Critique. Course Critique provides grade distributions and survey information for every course offered at Georgia Tech. Unfortunately, the current incarnation is prone to outages (particularly during registration periods) and several portions of it are not functional at all (namely the mechanism that uploads and processes grade distribution and survey info — a critical component.) After assessing the code base, I decided it was best to begin a complete rewrite. But this time we are going to do it right.
Even though this project doesn’t officially begin until January 11th, I am using what little spare time I have had over the winter holiday to begin what is arguably the most boring phase: requirements gathering and specification. While this may not be the most interesting phase, I really believe that it is one of the most critical (if not the most critical.) Proper design and documentation will (hopefully) prevent this project from going the way of its predecessor.
I titled this post “An Unlikely Project Manager” because until recently (like, really really recently) I saw myself as a software developer. I figured I’d be a developer forever, which I was sort of ok with. It was in the past year when people started suggesting that I could combine my technical skills with my skills as a communicator and bring balance to the force (Hopefully it goes better for me than it did for the Jedi.) This is my first opportunity to get my feet wet and see how good I really am at this whole “management” thing.
In an effort to avoid becoming a pointy-haired boss, I am going to be doing as little managing of people as possible. I’m going into this experience with three key ideas/quotes:
Management is taking out the trash
I wish I could remember where I heard this quote, but I searched for a long time and couldn’t find it anywhere. (Maybe I invented it? Unlikely.) Regardless of its origin, this statement captures what I believe (and remember, I’m a college student who hasn’t done any professional managing) is a key idea in project management. I will be doing little-to-no coding on this project. Instead I’m relying on the ingenuity of my team. My primary purpose will be to remove objectives from their paths. I’ll be doing most of the preliminary planning, communicating with third parties, initially setting up their environment (issue tracking, source control, etc.) and all the other boring stuff. I guess what I’m getting at is that you should let them do what they’re good at, and don’t bother them with the other stuff. Sometimes that means taking the can out to the curb.
“Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”
Patton was dead on here. As I mentioned before, I will be doing almost no programming. I’m ok with that, but it’s important that I avoid the micromanagement trap. This project will be fairly large, and there is no way for me to have my hands in everything. I picked this team because I felt they were capable, and I think they can put together some great software without being pestered. This isn’t a promise that I won’t offer my opinion, of course, I just want them to argue with me when they disagree. I’ll probably cave.
“In preparing for battle, I have always found that plans are useless but planning is indispensable.”
Well, people liked Ike. I thought if I included a quote from him people would like me, too.
In all seriousness, I think this is one of my favorite quotes. Not just as it relates to software engineering or project management, but in general I think it’s a pretty solid guideline. I am going to make sure that my team is given a complete and clear requirements document as well as functional specification. We’ll be laying out a schedule of milestones with target dates. And in spite of all this, approximately one week into the project we’ll realize we’re behind/the requirements have changed/there is no spoon. But that’s ok. It happens. Things will almost certainly not go according to plan, but thorough planning will give us a deeper understanding of the problem, making it easier for us to adapt to change. We can’t realistically count on meeting all our deadlines, or the server setup working just the way we would like it to. People will get sick, or become overwhelmed with school. There’s really no way to know what’s going to happen when we embark on our first sprint. Adaptation is the key to a successful operation. So we’ll adapt.
Here we go…
So I’ll be keeping those three things in mind as I start this adventure. I’m planning to use this blog to chronicle the progress of the project (partially as a personal record, and partially because it seems like a good way to generate some content and discussion.) Wish me luck!
Comments Off
Living on the Edge
December 17th, 2009(Author’s Note: This is an old post from December 2009, restored from the old blog. Old comments were not transferred along with the content.)
or The One in which I Rebuke all things Shiny and Cutting Edge
Living your life on the bleeding edge can be exciting (I mean heck, Aerosmith wrote an entire song about it.) The Edge is an exciting place — gadgets are shinier, smaller, and more expensive there. It’s hard to resist the allure of a new gadget, or the features of a new technology. We’re all guilty of it from time to time. All it takes is one press release, one vague and over-hyped magazine article, or (for some of us) a late night TV commercial with a 1-800 number plastered across the bottom of the screen. Next thing you know you’re busting out the plastic. Trust me, I own a Snuggie or two. I think there’s some law of nature that says “He who Dies with the Shiniest Stuff Wins.”
It’s bad enough to spend roughly the money supply of Turkmenistan on new gadgets, but it’s when this mentality carries over into other fields that it becomes really dangerous. When I say “other fields” what I really mean is “software development.” I have had two experiences with this, and both of them had one thing in common (other than the fact that the projects were overwhelmed by the shininess.) In both cases, it was decided (once by an executive decision and once by a vote) that we would be using Ruby on Rails for a new project. There is nothing wrong with Ruby on Rails, but on both teams, there was only one person who had written so much as a line of Ruby in his life. I’m going to talk about the most recent project in this post, because it was equally stressful and frustrating but it has a happier ending. Blogging is a lot like writing a summer blockbuster in that respect.
DISCLAIMER: This post is about to descend into what many will call “RoR bashing” but I assure you it’s not. Rails is a badass framework, and I hope it’s going to be around for a long time. This isn’t about the technology itself, it’s about the “let’s use what’s hot right now” mentality.
One of the Computer Science courses that most every Computer Science student at Georgia Tech has to take is CS3300 – Introduction to Software Engineering. It’s the second course where students are assigned a large team project. (The first being CS 2340, which I wrote about in my previous post “Adventures in Teamwork“) In this course, each team is instructed to come up with an idea for a software project, and go through the Software Development process to bring it to life. We decided to build a web app that would detect the user’s location (using HTML 5 geolocation services) and find the nearest restrooms with crowdsourced cleanliness ratings and comments. (We decided to call it “Poopt,” for anyone who was wondering. I can never resist a pun. Apologies to Sam Altman.) It would run in any web browser that supports HTML 5, but the target would be mobile phone users. I got the idea from an episode of Seinfeld where George told Jerry to give him any street corner in New York, and he could tell him the nearest clean public restroom.’
Before we even started design, one of my group members turned to us, and with a twinkle in his eye, suggested we develop our project in Ruby on Rails. The other three of us got pained looks on our faces — we had never written a line of Ruby in our lives. He assured us that both Ruby and the Rails framework were easy to learn, and that RoR could essentially do the hard parts of our project for us. Nothing gets a bunch of overworked Georgia Tech students on board like the promise of less work. On top of that, this could be a cool opportunity to learn something new! So, with some free RoR resources on hand, we decided to dive in.
Now, group work is a funny thing. It can bring out the best and worst in people. In any team, you can find at least one or two slackers (if you can’t find one, it’s you.) In my case, every member of the Poopt (it might be juvenile but I bet you grinned a little) team had agreed to learn Ruby and do their part. Things started off well — our RRoRG (Resident Ruby on Rails Guru, pronounced “Rawrg”) gathered the three of us together and started explaining things. Unfortunately, after day 1, interest started to dwindle in learning Ruby. There is supposed to be this little voice in your head named “Common Sense” that says things like “Now Ryan, maybe deciding to build a (tightly scheduled) project in a language no one knows is a bad idea.” Unfortunately, my little voice was too busy drooling and saying things like “so…shiny…”
Needless to say, by the second week of our project, the team had realistically dwindled to two: RRoRG, and poor Ryan, just trying to keep up.
In the end, we finished our project, and managed to pull an A out for every milestone, but it was largely because Mr. RRoRG worked really hard. I did what I could, but we both recognized that because of our timeline, there was no time for me to try to learn, the best I could do was tweak displays and templates.. RRoRG worked long nights, and I sat at the table and try to take care of all the bureaucratic and administrative legwork. I was totally willing to learn, but with the time constraints and my other coursework, there just wasn’t enough time.
Now, RRoRG was right about one thing — Ruby on Rails DID have a lot of features that made our project much easier. It would have been perfectly suited for our project if the rest of us knew what we were doing. Sometimes, you just have to settle for the old fallback. Maybe it’s less shiny and less exciting, but when it comes down to it, you’ve got to work within the constraints of your system.
I think I can sum up this long diatribe with one sentence: Next time you find yourself rushing out to buy a Snuggie, ask yourself: will a blanket do?
Epilogue
I’d like to say thank you, RRoRG, for working long hours, trying to teach me when you could, and not lumping me in with any other dead weight that we may or may not have had. You know, some day (when I have the free time) I’d really like to learn Ruby on Rails…
Comments Off
Adventures in Teamwork
November 22nd, 2008(Author’s Note: This is an old post from November 2008, restored from the old blog. Old comments were not transferred along with the content.)
I recently finished up my first real team software project. One of the classes I’m taking this semester is CS 2340 – Objects and Design. This is the first software project class at Georgia Tech, so it’s full of…well let’s just call them “learning experiences.” Most of the students have never really worked on a team before, and if they have it’s been in a more restricted environment. Technically I work in a team at CSI, but on a day to day basis I’m on my own. Most all of my tasks are delegated by my boss, and it was rare to work in sync with someone else. Needless to say, I approached this project more sure of myself than I should have been.
Our task for this semester was to develop our own version of The Oregon Trail in Smalltalk. No one in our class had any Smalltalk experience, and we’ll just say that it is “interesting” and leave the this-language-totally-sucks rants for another day. We split up into teams of Five, and were given a series of milestones and deadlines. Collectively, the milestones would represent 44% of our grade, leaving 16% for small projects and 40% for exams.
Our first milestone was due shortly after we were assigned to teams — we had to put together a rough outline of our Domain classes (a few scenarios and CRC Cards.) This milestone was no problem, but the next week we had to have our preliminary UML Diagram done. We worked to arrange a meeting, and this was where we hit our first roadblock.
Lesson one – People come and people go…
And sometimes there’s more going that coming. While we were trying to get our second meeting set up, we recieved an email from one of our group members in which she let us know she was going to be dropping the class for the semester. That was an understandable excuse, and only left us four-handed. Four seemed like plenty, so we arranged our second meeting for a night later in the week. This was the last time we heard from Teammate number four. He is still enrolled in the course, but we haven’t seen him in class and he hasn’t responded to our emails. Then there were three.
This was a real shock for me, I wasn’t expecting this sort of thing to happen. I got lucky in that the other two guys in my group have worked super hard and have been very accessible, but we could have been up a certain creek without a paddle. I realized that sometimes you just can’t count on everyone on your team. Sometimes people miss deadlines, sometimes people just up and quit, and there’s not much you can do about it. And, even though no one wants to admit it, that person could be you.
We had to scale back a lot of our plans because we were short-handed. This leads me to my second point…
Lesson two – If you can dream it, you can do it…
Given the proper amount of time and manpower, of course. This was a lesson that hit us fairly hard. We had some pretty extravagant plans for our Oregon Trail game: Markov Chains for realistic weather simulation, Procedural Generation of graphics (a la Spore), a hefty database back end, and some more all-around awesomeness. Unfortunately, when we lost team members, we realized fairly quickly that we had to adapt. We decided to scrap some of the “unessential” features. This translated to “just make the darn thing functional before demo time!” We had to scrap a lot of our cool features, but I do think we did something right here. Before we got knee-deep in late, half-finished special features, we laid out what these features would require. This made it easier to see what needed to be cut. Proper planning sort of saved us from digging ourselves into a hole this time.
The final product didn’t look quite as cool as we had hoped, but we prioritized. We managed to meet the requirements, and still had some time for bonus features.
Lesson three – Use the source (control), Luke…
Anyone who knows me will give me a lot of grief for even having to write this section (“Ryan, you ALWAYS preach the importance of adequate source control! How could you?”) and I probably deserve it. Normally I’m pretty good about source control. I try to set up a repository even for one-man personal projects. Yes, I have been known to complain about source control on other projects. But, in a moment of mass-foolishness, we decided we didn’t need a formal source control system. We set up a “repository” on Sakai, which pretty much just consisted of a Wiki with a “check out list” and a folder of the accepted “stable” Smalltalk source files. It worked just long enough to give us headaches in the end.
Initially, things were progressing slowly enough that the system worked fine. I might have the Wagon class checked out, and if a teammate decided he needed another feature in Wagon, he could just shoot me an email and have me add it while I had it in my possession. No problem. Problems began to arise the weekend before the due date when we were furiously working on features, trying to get things working (don’t judge, it happens to everyone) and we couldn’t always reach one another. Even though we knew better, we started modifying files that others had checked out. This resulted in one of my teammates having to do a (very messy) manual merge of source files right before the due date.
Even a simple setup of SVN would have saved time (and aspirin). Sometimes, it takes a little stress to reaffirm what you already knew.
Happy endings
Ultimately, everything turned out okay despite our problems. We met our deadlines, did fine on the milestones, and no one died of dysentery. My two remaining team members were great, and that was most certainly a factor. Working on a team is definitely a different experience. I have a feeling I’ll be shelving my Smalltalk knowledge after finals week, but the things I’ve learned about team work will follow me forever. Now my eyes are on next semester, where I can certainly look forward to more “Adventures in Teamwork”.
Comments Off