Thoughts about my ICS education

Replies to This Discussion

Permalink Reply by Zhien Wang on September 2, 2008 at 10:58pm

I have only an alumni in ICS for two years. But I think the best advice I can give is to research and be exposed more to the current technology trends during the college years. Not only programming itself, but also tools used in the development process and forum discussions on particular subjects you are interested in.

Such as wireshark, SVN, basic networking, etc.

Permalink Reply by Laurence A. Lee on October 5, 2008 at 12:55pm

By far, the most rewarding classes I took as an Undergraduate of ICS were ICS 413 and 414, Software Engineering I and II.

It wasn't so much because they taught me about team processes, time and size estimations, and source control. It was because I was able to re-evaluate my management style (or lack thereof), and adjust accordingly. Doing a Senior Project for a REAL company (with real deadlines and all the associated pressures) is definitely an eye-opening experience.

When my team of 4 first started out, we were a loosely-knit group of college classmates, "growing up" in the ICS program together. ICS 212 and algorithms with Sugihara? Yup. ICS 241 discrete math with Gersch? Yup, many of us barely scraped by in that class, too.

Nothing in my entire UH Education program would've better prepared me for my toughest challenge of all, though: managing my own colleagues, as I learned how to step up and become a Team Leader.

It was as close to Real-World as we all would ever get before graduating: a Team-Developed Senior Project created for a real Honolulu Company, with hard deadlines, deliverables, and all the headaches and aggravations that come from assembling a "Team" out of people who haven't really worked together on a "large", long-term project before.

At first, I thought it was going to be easy: Do the software metrics to estimate sizes, evaluate everyone's strengths, and assign a balanced load of work amongst everyone and have all the pieces magically built on time and on schedule, so we can assemble the final product and deliver it. You know, just like how the Book says things will be.

I can't believe I was ever so green and naiive. :-p

Scheduling conflicts, work ethics, and personality clashes soon crept up in our regularly scheduled team meetings. Some members weren't delivering on time, or they produced code that eventually had to be rewritten. Other members were feeling used because they were pulling everyone else's weight around.

In the initial weeks, it became obvious that we each had a one-way ticket on a train to Hell, and that we'd be at each other's throats in no time.

Soon I learned how to be a "Project Smoother" as well as a "Team Leader". I learned how to take the edge off of the most productive team members with praise and words of encouragement (admittedly, all while continuing to add a disproportionately heavier workload). I also learned that you gotta put a flame under some peoples' butts to get them to deliver on time. I also had the foresight to add some padding in case their deliverables needed additional work. Thank goodness.

It was a huge balancing act of being a productive Developer to work within a Team, being a persuasive Parent, trying to convince their kids to eat their veggies, and keeping a close eye on the long-term schedule.

In the end, we all barely got through the ordeal with a delivered Product, and, surprisingly, no hard feelings between each other. It was tough in crunch-time, but somehow we all pulled together and got it done.

Truth be told, I think it was more luck and team determination than my feeble Managerial skills at the time.

The other team members walked away from the experience with an understanding of how to deliver their part in a team environment, and to receive (and negotiate) marching orders from a Leader. Some people are self-starters and "just do it". Others, well.. if you can figure out how to motivate them to deliver, they can do great things. At the end of the day, they all were good (well-intentioned) coders.

Me, I've since moved onto bigger things. Though... I seriously doubt I'd have gotten so far, so fast, if I didn't learn how to Lead a Development Team before graduating.

Permalink Reply by Jim Thompson on February 17, 2009 at 1:14am

I'm doing the completion-backwards principle. After nearly 30 years in the industry (starting with Fortran on cards) I've decided to go back and "pick up" the degree.

I've designed and delivered some very large software systems (the billing system for Wayport (now owned by AT&T) was rolled entirely in-house, as was some of the early hardware used. (You try managing over 5,000 remotely-located linux machines, all of which, if down, are dropping revenue on the floor.) I've managed projects that require a level of sophistication not normally found in "embedded systems", in this case, a couple products that implemented "phased array" antennas for WiFi.

I've helped raise over $300M in "venture capital", a process I'm unlikely to willingly repeat.

Even with that, I'm looking forward to the 413/414 sequence. Always good to learn a better way, or improve on one's existing methods.

I was at Sun (working for Bill Joy) before Java saw the light of day. I've seen it since grow into something it was never intended to be, but sometimes these things have a way of finding a life of their own. Java is ... OK (far better than C++, which it was designed to replace), but not within a country mile of what Lisp can do, yet Lisp isn't taught except as a 'slice' in 313. Why is this the case? Being able to think in a functional manner (OK, so Lisp isn't a "pure" functional language) is going to be super-critical in the coming decade. ICS @ Hawaii has a bit too much emphasis on Java for my taste. It seems to give it a 'flavor' of some kind of high-level 'trade school'.

I'm especially interested in systems such as Clojure, and parallel algorithms applied to fields such as financial modeling and bioinformatics. These are 'hot topics' in the field right now, and UH would do well to ensure that its
grads are familiar with the changing landscape of computing as things like lock contention relegate technologies like RDBMS to the "maintenance heap" of history. (Yes, someone will get paid to maintain these systems, but imagine your life as a PL/1 programmer today.)

After my short experience, I have to say, that some of the profs @ UH seem either ignorant of the field (they literally lack subject-matter expertise), or they are completely unavailable for interaction with students. Fortunately, thus far I've only found a few like this. Many are completely the opposite.