5 ms·

> 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, w

> 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 ago
I 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 ago
  Well, 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 ago
  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.
  - dxbydt 14y ago
    > most customers want products, not research "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.
    - strictfp 14y ago
      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!
    - jsprinkles 14y ago
      > customers can go fuck themselves. Oh, dear Lord. This comment makes me hurt. 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.)
ashishgandhi 14y ago
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.
- jsprinkles 14y ago
  > As an example, take Google's self-driving cars. Would you say the meat of their body of work theoretical? No.
  - snikolov 14y ago
    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.
    - jsprinkles 14y ago
      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.

netvarun 14y ago

I 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 ago
Well, 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 ago
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.
- dxbydt 14y ago
  > most customers want products, not research "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.
  - strictfp 14y ago
    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!
  - jsprinkles 14y ago
    > customers can go fuck themselves. Oh, dear Lord. This comment makes me hurt. 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.)

ashishgandhi 14y ago

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.

jsprinkles 14y ago
> As an example, take Google's self-driving cars. Would you say the meat of their body of work theoretical? No.
- snikolov 14y ago
  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.
  - jsprinkles 14y ago
    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.