Princeterns Part II
By stern on Jan 28, 2008
Common thread in customer meetings: Importance of diagnostics, inspection and analysis. I didn't script the customer discussions but each one touched on Dtrace, truss, packet sniffers and the need to analyze networked systems end to end.
What's different in the real world?: My answer to this one has been consistent for more than 20 years, namely the time scale and operational complexity of real-world applications. College projects run for no more than 10-12 weeks, typically completed within 10-12 days. Large-scale software projects run from months to years, in multiple phases, and rather than engineering the whole enchilada you typically have visibility into a small window of code and functionality. One of our customer visits touched on the need to continue to "feel like a startup" and move quickly, even as the company matures and has code aged in years, not weeks. Operational complexity isn't just about putting projects into deployment; it's about making sure the code works for all inputs, not just the ones needed to demonstrate required output. Emphasis on security, reliability, performance and the measurement points to assert those features increases after graduation once code has a life beyond the final exam.
Participation in open source projects could change this. Many of the software lifecycle engineering issues listed above show up if you have even tangential involvement with an open source software project. We (at Sun) have tended to look at our open source efforts at attracting campus developers, and we should be putting equal emphasis on the collaborative development model that inculcates long-term software perspectives.
When and how do you move into management? One thread of this discussion focused on the non-engineering disciplines that develop leadership, including dealing with different styles, cultures and approaches, managing conflict and setting and sharing a vision. The other thread was much more Sun-culture-centric, and was counter to some of the student perceptions of career ladders converging in management layers. Sun's engineering path goes from individual contributor through a "staff" level, typically recognizing the key technical contributors to a product, up to "principal" and "distinguished" levels, for director-sized influence and leadership or public appelation of outstanding engineering output, and finally the "fellow" title given to engineers who have VP-sized roles without VP-sized organizations reporting to them. Bottom line: there are many facets to leadership other than budgets and people management, and it's important to ensure that all of those facets reflect light along different career paths. What I learned from this discussion was that Sun should thinking about recent college graduates for non-engineering roles as well in business development, strategy, and operations, because their perspectives are both valuable and different from our own.
What are your [student] impressions of Sun? I wasn't ready for this answer -- that we're seen as a software company, particularly in light of the mySQL deal. The bad news is that hardware visibility is linked to visible logos (Princeton has a population of Sun systems, but they're not on desktops); the good news is that increasing our software footprint and distribution mass means that there's greater awareness of what we do as a company. As as a sidebar, both students had incredible knowledge of copyright and DRM issues, due to concerns about file sharing and content downloads. Perhaps Cory Doctorow is right and copyright criminal awareness is pervasive.
Did I feel old? Twice. One of our customers mentioned Feynman in terms of making problems accessible to non-experts, but the name didn't register. Feynman died before either student was born, scaring me that our cultural references are being compressed into ever-shorter timescales as a by-product of rapid cultural dissemination. We have too many things in the context, and therefore context switch more quickly. The other oldness came from one student asking me if I was familiar with Guitar Hero. Even without teenaged kids and game consoles, the gaming culture and its influence on social networks can't be ignored in technical circles. Students don't see gaming as a "separate thing". I mentioned the historical view of computing was a place you went to, not a thing you did, and certainly not something seamless in your everyday use of devices, and what I extracted from this simple question and follow-on was that gaming is as seamless to students as cell phone use is to their parents.
What would I do differently? You're tempted to say "nothing" but that's a bogus answer when you've had twenty years to think about the question. I would have focused more on writing and trying to find my voice as a writer; much of the writing I did was in response to questions posed by instructors and professors, and not something I wanted to inscribe. While I probably wouldn't have been accepted into a writing seminar with John McPhee or E.L. Doctorow (no relation to Cory) at the time, I should have tried, which would have required that I had the interest. It was Tim O'Reilly who helped me discover that I liked writing, and he did it by marrying my love of explaining things to putting ideas into words.
By the literal end of the day, I think I learned something from every exchange and question, and I'm looking forward to this program becoming more formal in future years.