> 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.
Are you saying people who do theoretical work don't don't it in practical ways?
As an example, take Google's self-driving cars. Would you say the meat of their body of work theoretical? But would say the code they (Sebastian Thrun himself, and others involved in the project) write code that's not very practical, readable, maintainable or without tests? I would say what they do is theoretical work. And they write practical code for their theoretical work.
If you look at Udacity classes - I've watched Peter Norvig not Thrun's so I'll use that as a reference - Norvig places a lot of importance for tests, maintainability, readability and other practical things throughout his class. I would assume the code he writes (however little now, however much in the past) is very practical. Yet what he writes code for has a huge theoretical aspect to it. I'm saying one can have their body of work being theoretical by nature but that doesn't mean they don't write practical code.
Would you care to elaborate? Surely most of the lines of code are not directly implementing theoretical things, but I would say the meat of the work is without a doubt theoretical.
I don't know about self driving cars, but I have known people who did PhD level research in control engineering and then went into industry (real, heavy metal industry, like offshore oil installations in the North Sea) implementing advanced control systems.
The estimate they gave me of the contribution of their control algorithms (the "theoretical" part of the project) to the over amount of effort getting the thing working was less than 1%.
Theory is thinking about how to build a self-driving car, and the algorithms and considerations that would be required to do so, and perhaps writing a paper about how best to go about doing it. Practical is writing code, running wire, and testing the car. Surely they've done both, but now that the car exists they're into the practical territory. As they adventure through the practical part, surely new theoreticals are discovered and published.
Just because nobody has built a self-driving car before does not automatically make actually building one a theoretical exercise. The process is applying the sciences to making a car do something, which is very practical. Your awesome sort algorithm and the paper explaining it is theoretical. My implementation of it is practical.
That is the differentiation that most people can't see.
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.
I'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.
"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already."
So said Alan Perlis, the first recepient of the ACM Turing award. I'll listen to Perlis all day than pay any attention to an Agile blowhard who calls himself a "thought leader" on his own biopage. customers can go fuck themselves. cs is what matters.
Well I for one want to make great products that make me feel like we surpassed ourselves and makes the customers happy. Most likely this involves technical innovation. I'm sick and tired of the ones writing "better" hash tables all day, blowing by budget and pissing everone off who actually wants to accomplish something.
Fun for me means keeping the project on track, delivering so that we get an income and can spend real money on R&D and events. I don't want to sit in a project which hasn't delivered in months, is in overtime (with all rhe stress that that means) and no working program what so ever, just a bunch of Impls, Contexts, BidiMaps and XxxUtils. That's not cs, and it sure as hl ain't fun!
Your salary from Bank of America comes from customers -- even if you're paid from investment, the investment is only there because Bank of America has customers. Your research in academia is paid for by customers of the institution, both former and present, and possibly governments (who are also interested in the product of the research). Your shortsighted world view is tragically common in those who favor academia, and without paying customers driving research into new areas, your precious academia wouldn't exist and you'd do well to understand that. Money is everything.
What the hell do you think the point of academia is? All throughout history, the sciences are almost always advanced due to a pressing need or mistake from practical execution.
> cs is what matters.
Execution is the only thing in the world that matters. You are basically admitting that you're the idea guy, searching for a "technical co-founder".
Had Mark Zuckerberg spent a lot of time worried about the runtime efficiency of parts of his code or whether there was a more efficient algorithm for sorting friends, Facebook would be nothing today. He executed and didn't give a shit, because he wasn't exercising computer science, he was exercising building a product.
Surely people went back and made things more efficient as Facebook scaled, but I've been at a rapidly-growing startup a while, and I haven't made my product more efficient through many computer science advances. Most have been using better software, better network topology, better configuration, less dumb code, and so on.
Your attitude completely misses what the article is explaining, and, frankly, your ad hominem on the guy talking about Agile is completely out of place when practically your entire LinkedIn profile is buzzwords, just your field instead of his.
(Aside: I love that HN makes it really easy to build a list of no-hires, fairly easily, just by observing how people think and communicate.)
"I haven't made my product more efficient through many computer science advances. Most have been using better software, better network topology, better configuration, less dumb code, and so on."
Please stop. You're getting irony all over my desk here.
No. I will not silence my opinion because you disagree. Although your comment is almost devoid of insight, I would infer that you're implying I'm being obtuse regarding the role of computer science in making my stuff better. Example of a performance improvement: choosing a frobnicator that uses multiple cores to frobnicate instead of a single core to frobnicate. Do I have computer science to thank for that? In a way, the same way I have medical research to thank for Advil. However, it's disingenuous to say medical research got rid of my headache. The Advil did.
Computer science has its place, but it needs to be more aware of that place. This thread is a very poignant demonstration of that.
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.