Professors and students in a nearby research group have been brainstorming a syllabus for a new, low-level computer science course. Normally I only “lurk” in such discussions, but this time I couldn’t hold my tongue. The following is my contribution, from my perspective as one who has interacted with “computer scientists” as a fellow team member, project leader, hiring manager, business partner and even corporate recruiter (interviewing mostly for other hiring managers).
This version has been edited slightly to make it better suited for a blog…
As an “old guy” who has interviewed his share of CS, CE and EE’s over the years (and hire and/or managed more than a few of them), here are my thoughts from an “outcomes” perspective…
-
It’s really exciting to work with a developer who groks the concepts to such a degree that specific languages and language boundaries simply don’t matter. Seeing a prototype done in Erlang because it was perfectly suited is SO much better than listening to whining over how it is hard to do it in Java or C# or Visual Basic N. They are usually curious about everything; the dude that coded a prototype NoSQL-style data store for our team in Erlang had been playing with it for a few months, “just because…”
-
Methodical problem solving matters. Which some would equate to Engineering(tm). But really it’s about gaining a ton of experience attacking problems. The number one thing I’ve looked for over the years is actual experience — through project work, interesting course projects, and esp. internships — in completing cool projects. And please, don’t wait to be assigned; always look for problems, and just do them.
-
Join the software ecosystem. The most impressive developers I’ve met over the years — some are currently undergrads at the Tetherless World Constellation at RPI — understand how to contribute to software ecosystem(s); usually this is through the open source community. They understand the tools, they understand how to engage with other developers, they understand how to analyze and improve other people’s code.
Here’s one way to think about it: if you aspire to be a professional musician (or artist), chances are you’ve participated in the “music ecosystem” in a wide variety of ways for many years, even before entering college. The best developers I’ve met — and those “computer scientists” who are developers at heart — have done the same (one guy I know built his first Linux kernel when he was in middle school).
-
Understand systems end-to-end. Now we’re back to the topic at hand 😉 The best contributors over the years have been those who had hands-on experience with absolutely every aspect of the “system.” This doesn’t mean going From Relays to Twitter in 10 Weeks, but it does mean understanding the relationships between all system elements.
I doubt very much that this is a problem for anyone on this list, because the very nature of PKI work requires one to have just this sort of broad and deep knowledge; plus, your professor and I have had a few conversations about this over the years…BTW, my daughter’s now at Southampton working on her Ph.D in numerical relativity and writing code on a supercomputer cluster 😉
UPDATE (29 Oct 2010): Nature recently published this interesting article, Computational science: …Error …why scientific programming does not compute, (13 Oct 2010) on the increasing need for scientists to have hard-core software engineering skills to do their science.
Hi John,
Thanks for writing this – the point about language barriers has been a real beef of mine recently, and you’ve articulated it really well.
I’d add “understand that programming is an act of communication with other developers as much as with a computer”, which probably comes in as part of your point about ecosystem.
jim
By: Jim Downing on November 3, 2010
at 11:33 am