3 ms·

I like Larry Wall's conceptual framework for this. The chapter of Programming Perl regarding software libraries starts out with a discussion of Laziness, Impat

I like Larry Wall's conceptual framework for this. The chapter of Programming Perl regarding software libraries starts out with a discussion of Laziness, Impatience, and Hubris (http://c2.com/cgi/wiki?LazinessImpatienceHubris http://c2.com/cgi/wiki?LazinessImpatienceHubris ), but more importantly, it also explicitly mentions the ideas of False Laziness, False Impatience, and False Hubris, which each in turn lead software developers from making poor choices as to whether they should build a new software library, reuse an existing library, or just get on with their damn job, and write something easy. But this essay gets right to the same core here. How is it that we do our jobs as software developers? What is the right way to approach a particular problem? These are hard questions to answer in abstract, but thinking about the nature of invention is a pretty good proxy.

raganwald 15y ago
Thank you, may I quote this?
- knowtheory 15y ago
  Please do!
kamaal 15y ago
I also like Larry Wall's "Waterbed theory of complexity" (http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory) which fundamentally says complexity needs to be handled at layer or the other in a system. Which primarily brings the eternally asking the question of "Using the right tools" for the job. Apart from knowing all the CS know-how behind how things work. Practical software is all about knowing if there are existing off the shelf solutions that can be just plugged into take care of that part of the complexity. I think innovation is more than just code, its also about how you can go about solving a particular business problem in the most practical way. I think in MIT lecture series of Structure and Interpretation of computer programs, the instructor bring about a very point. Its something like this "A part of understanding and building large complex systems is to know what parts to neglect". We often test people with knowing about the granular details. But we never see if they know how to build powerful abstractions. Which is basically the core any large complex system.

raganwald 15y ago

Thank you, may I quote this?

knowtheory 15y ago
Please do!

kamaal 15y ago

I also like Larry Wall's "Waterbed theory of complexity" (http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory) which fundamentally says complexity needs to be handled at layer or the other in a system. Which primarily brings the eternally asking the question of "Using the right tools" for the job. Apart from knowing all the CS know-how behind how things work. Practical software is all about knowing if there are existing off the shelf solutions that can be just plugged into take care of that part of the complexity. I think innovation is more than just code, its also about how you can go about solving a particular business problem in the most practical way. I think in MIT lecture series of Structure and Interpretation of computer programs, the instructor bring about a very point. Its something like this "A part of understanding and building large complex systems is to know what parts to neglect". We often test people with knowing about the granular details. But we never see if they know how to build powerful abstractions. Which is basically the core any large complex system.