4 ms·
fwiw, an opposite take, from a decade ago. at my cs pgm, the assistant professors were supposed to make a presentation on day 1 so the grad students could make
by dxbydt 14y ago
fwiw, an opposite take, from a decade ago.
at my cs pgm, the assistant professors were supposed to make a presentation on day 1 so the grad students could make an informed decision which prof to work with, which subjects to sign up for.
the software engg prof was a glib, entreprenurial hotshot who said "my students have been placed at netscape, sun, microsoft, oracle". he talked about industry partnerships, internships, 1000s of lines of production code, maintenance, unit tests, refactoring...
the db prof said "i have personally placed all my students in oracle". he talked about rdbms, schemas, superkeys, boyce codd normal forms, how "everything was ultimately data, so you'll never be jobless if you became a dba".
the algorithms prof was a shy lanky dude who went straight to the blackboard and wrote "computers are to computing what telescopes are to astronomy". at that point none of us knew who dijkstra was, so we just looked at each other like "huh?". he then turned to us and said "99% of cs is about searching and sorting. sort algorithms. search algorithms." then he drew a table which listed performance of quicksort, shellsort, heapsort, insertion sort, and two algorithms of his own invention. he talked about Big O notation, theorems, discrete math, taocp. our heads were spinning, and when he left there was a huge collective sigh of relief.
at the end, the student breakup was like 49-49-2. So only 2% of the class signed up for algos. Like most indians, I come from a poor household & my main concern was coin. So I signed up for Software engg. After 1 month, I dropped the course and went crawling back on my knees to the Algo prof, and begged him to take me on. That single decision changed my whole life. In that 1 month, I had found out something about myself - that I was a royal prick. I was personally not cut out to do scut work.I had zero interest and respect for maintenance, unit tests, requirements & specs, UML modelling, refactoring, waterfall method, agile, kanban...I found that whole discipline filled with unproven subjective airheaded garbage, essentially a fad. To this day when a recruiter mentions the word "unit tests" on the phone, I just hang up. Just pure instinctual reflex.
It takes all kinds...
- j-b 14y agoDegrees don't matter so much. Can you learn? Are you smart? Can you ship good code (given enough training)? Real programming skills comes through experience and domain knowledge. I am less interested in the educational background of developers that I've hired than I am of their future growth potential which has more to do with personality than IQ.
- petitmiam 14y agosadly not every employer is like you
- jsprinkles 14y ago> I was personally not cut out to do scut work. I had zero interest and respect for maintenance, unit tests, requirements & specs, UML modelling, refactoring, waterfall method, agile, kanban... The world in which this is "scut work" is not the world I want to live in. Let's be honest. You don't want to do practical, you'd rather do theoretical, and that's fine. However, don't disrespect practical just because it isn't your bag of chips, particularly to an audience that is full of practical engineers. I could spend all day disrespecting theoretical -- mainly because most of those passionate about theoretical at the expense of practical make comments like these -- but I do not, because I see theoretical as necessary for our craft.
- netvarun 14y agoI have to disagree with you. Software engineering 'ideas' regarding modeling and testing have gone way overboard. I have a feeling that that all those who peddle fancy buzzwords such as agile and kanban are either MBA graduates with no real engineering background or failed engineers trying to reinvent their career.
- jsprinkles 14y ago> Software engineering 'ideas' regarding modeling and testing have gone way overboard. Maybe, but he also said specs and maintenance.
- nernst 14y agoWell, here are a few of the people "peddling fancy buzzwords". I think their bios speak for themselves. * Martin Fowler - http://martinfowler.com/aboutMe.html http://martinfowler.com/aboutMe.html * David Anderson - http://agilemanagement.net/index.php/bio_david/ http://agilemanagement.net/index.php/bio_david/ * Steve McConnell - http://www.stevemcconnell.com/bio.htm http://www.stevemcconnell.com/bio.htm
- strictfp 14y agoI'm a preacher of Agile. I talk about it in order to get things done. Theoretical work is important, but let's face it, most customers want products, not research. Your average person declaring himself 'theoretically oriented' is no good in delivering products. He hasn't understood the bigger goal and will just waste the clients time and money training himself to write better algos. Most likely he will be rather unexperienced, and produce pale replicas of existing library algos and data structures. In my experience the ones who know the most theory are also often the most pragmatic and professional ones. These don't boost about their technical knowledge, but they know it and know how to apply it. These will declare themselves 'problem solving'. One that declares himself mostly theoretical most likely just hasn't gotten that far yet. Then we have real researchers, but that's another story entirely.
- jaaron 14y agoI've tended to explain it to people this way -- In the related computer science fields there are only three kinds of problems: 1) The problems math makes for you. These are the kind of problems lots of people think they work on, but don't. Compared to other problems, there aren't a lot of them, but solving one has a huge impact on the field as one solution can be shared across the industry. 2) The problems physics makes for you. These are the problems you encounter when you take the math and start applying it to actual machines. This is hardware design or software to directly make that hardware do what you want. This is 'applied' computer science and again, many can leverage the work of a few. 3) The problems other software engineers make for you. This is what most computer scientists/engineers/programmers actually have to do. This is dealing with making someone else's code do what you want. It's dealing with API's and layers and layers of other, primarily human-created, problems.
- baddox 14y agoAm I reading it correctly that people in your CS program didn't know about basic algorithms until the beginning of graduate school?
- robyates 14y agoReminds me of this: http://www.scott-a-s.com/cs-is-not-math/ http://www.scott-a-s.com/cs-is-not-math/
- mironathetin 14y agoThis is not an opposite take, if you write, you found yourself are a royal prick. This confirms the 0.1% rule of the op.