9 ms·

"Smart and Gets Things Done" is necessary, but not sufficient

96 points by raganwald 14y ago

deleted 14y ago
[deleted]
- gcmartinelli 14y ago
  I, on the other hand, suspect that many people buying these books don't even want to get a job in programming... maybe they just want to learn, or build their personal projects. http://planoa.wordpress.com/2012/12/05/why-google-and-others-should-support-massive-online-open-education/ http://planoa.wordpress.com/2012/12/05/why-google-and-others...
  - gte910h 14y ago
    I am a professional programmer who's been working in the field for over a decade, who went to a top 40 school, use multiple languages professionally, yadda yadda. I buy those books and the "best" advanced book on the language when I want to get up to speed fast. Going through and doing all the exercises, and stupidly simple setup they always have is so worth it. Typing in all the code takes almost no time at all, and it gets you the basic understanding down pretty fast. Then the advanced book smacks any bad things the silly book tried to give you, and you can start making something real with it.
gtrak 14y ago
I think the counter-argument is this: We have control over the amount of real reasoning we can do about our code. The hassle of the real can be minimized. For example, I like clojure, and there are real benefits to theoretical things like immutability by default, or garbage collection. This ability to reason mathematically while being practical is worth promoting in computer science and engineering. If I couldn't reason this way about programming, I wouldn't be a programmer. Engineering is the intersection from theory to practice, and I appreciate that in computing, incidental complexity can usually be traced back to someone's neglect. Without this, we only have heuristics. There is no silver bullet, but things can be made measurably better. We can accept reality without giving up on reason. I think to prove it, we can look at the influence of mathematics on real discoveries in history, and maybe ponder if humans are just meant to think this way in order to make progress. I hope my code reflects more order (purity, generality, conciseness) than chaos (special cases, entropy, technical debt). I would just call the procs thing a 'wart' and avoid using it. I don't think my opinion favors the mathematically inclined programmers over the empiricists. So, let's think about the kinds of things that get done as a consequence of certain types of thinking. Tradeoffs.
luu 14y ago
I pretty much agree, but I'd like to point out that, as a field, programming emphasizes the importance of "Smart and Gets Things Done" more than pretty much any other field does. I've been interviewing lately, both at hardware and software companies. At microprocessor startups, I ask about the pedigree (past experience, not educational credentials) of pretty much everyone I meet. I don't do that at software companies. The reason is, you pretty much never hear about a new team successfully making a high-performance microprocessor. Apple bought PA Semi, which had a moderately successful exit, but PA Semi was basically the SiByte team, which left after SiByte was acquired by Broadcom, and SiByte was composed of key people from DEC who had been working together for over a decade. When you hear about a new team where most of the people are smart new grads, they usually spend ~ $100M over five or six years years, find that they don't have a competitive product (or, more likely, don't even have anything that's close to working). If they have funding left to burn they may pivot a couple times over the course of a couple years before they burn through their cash and implode. And that's despite microprocessor design being close to pure reason, in the grand scheme of things. Experience and wisdom matter a lot more in most endeavors. Something you see a lot, even here on HN, when non-CS/programming/engineering topics make it to the front page, are people who try to extrapolate from a few "obvious" facts and then come up with a conclusion that's completely and totally wrong. In software, you hear about successful companies founded by people just out of school, or even people who have dropped out of school, all the time. "Smart and Gets Things Done" can be good enough to make a decent product. But, something you'd never want to hear from a plumber or a carpenter is "well, I've read some books on the topic, and tried out some tools at home depot, plus I'm smart and good at hacking". Things like carpentry, manufacturing, etc. are hard. They're done so well here (in developed countries) that it's easy to forget an idea of how hard they really are. If you want to get an idea of how hard they are to learn from scratch, consider South Korea after WII. Its GDP per capita was lower than Ghana, Kenya, and just barely above the Congo[1]. For various reasons, the new regime didn't have much baggage, and they wanted Korea to become a first-world nation. The story I've heard is that the government started by subsidizing concrete. After many years making concrete, they wanted to move up the manufacturing chain and start making ships (among other things). They pulled some of their best people who had experience in business (having learned skills like management, operations, etc.) from working in concrete to try to build ships. They knew they didn't have the expertise to do it themselves, so they contracted out the plans and got detailed instructions how to build ships. They got plans from Scotland, because Scotland has a long history of shipbuilding. Makes sense, right? But, when the Koreans tried to build ships with Scottish plans and detailed step-by-step directions, the result was two ship halves that didn't quite fit together and sunk when assembled. For historical and geographic reasons, Scotland's shipyards weren't full-sized, and they built their ships in two halves and then assembled them. Worked fine for them, because they'd be doing it at scale since the 1800s, and had world renowned expertise by the 1900s[2]. The Koreans eventually managed to start a shipbuilding industry by hiring foreign companies to come and, build ships locally, and show people how it's done. It took decades to what we would consider basic manufacturing working smoothly, even though all of the requisite knowledge existed in books, was taught in university courses, and could be had from experts for a small fee. "Smart and Gets Things Done" goes so much further in programming than it does in virtually any other non-academic field. Today, anyone with a CS 101 background can take Geoffrey Hinton's course on neural networks and deep learning[3] and start applying state of the art machine learning techniques[4] to research grade problems within a couple months. But, if you want to build a ship, and you "only" have a decade of experience with carpentry, milling, metalworking, etc., well, good luck. You're going to need it. [1] http://www.nationmaster.com/graph/eco_gdp_per_cap_in_195-economy-gdp-per-capita-1950 http://www.nationmaster.com/graph/eco_gdp_per_cap_in_195-eco... [2] In 1913, 20% of the world's ships were built at Clyde. [3] https://www.coursera.org/course/neuralnets https://www.coursera.org/course/neuralnets [4] About 1/3rd of the way through the course, he talks about a new technique that was published after the course actually started. The future of education is going to be awesome.
holograham 14y ago
to me, constantly learning is part of being smart and getting things done, especially in the tech industry. You cant be smart and getting things done unless you are learning the latest tools and techniques. I have always like the saying "get things done, smart" better which perhaps encompasses this post's thesis better than Joel's original wording.
Jabbles 14y ago
To be honest, I didn't think there was much of an argument or a point here. The conclusion that "there's no substitute for experience" doesn't follow from the rest of the article, and most of the rest of the conclusion falls into "getting things done" anyway. You were able to think of an edge case for language feature that neither of your friends had considered. Awesome. Smart. Realising that upfront is the kind of skill that saves you hundreds (anecdotally) of hours of debugging because you solve it in the design phase. Saying "smart interferes with gets things done" is exactly what Joel was saying when he tacked on "and gets things done" - so you can't really use that to argue he left something out. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. http://www.joelonsoftware.com/articles/fog0000000073.html http://www.joelonsoftware.com/articles/fog0000000073.html
- raganwald 14y ago
  This is an interesting reply, thanks. I possibly didn't explain this well. My reasoning didn't actually help, unfortunately, because I convinced my self that a proc MUST behave like a lambda with respect to "return" semantics. So had I been left to my own devices, I might have written some Ruby code that assumed it was perfectly safe to return a proc from a method. This is a real danger for me, as I like programming with combinators. And I would have been bitten by my mistaken beliefs. The only thing I'll say in my own defence is that having made this mistake many times, I had the good sense to check how things actually worked when I got home. I used to know, I'd forgotten, and now I know again. I don't know if that's "getting things done." It may be spinning wheels. Perhaps someone "getting things done" never wastes any time worrying about the difference because they never bother to wonder what happens when you return a proc from a method. They simply avoid the problem in the first place, so not knowing is irrelevant.
  - Jabbles 14y ago
kylemaxwell 14y ago
I think this conflates "smart" in the sense of "raw ability to reason" with "smart" in the sense of "knows the intricacies of how things work". Or, as my uncles might have said, "book learnin' versus real knowin'". In fact, even in the example given with respect to Ruby procs and lambdas and returns and whatnot, clearly the author hadn't "gotten things done" in that area (by his own admission, this isn't snark). So to me, the real point is that thinking you've worked everything out from first principles doesn't mean you actually understand all the implications of the interactions in a complex system. That's the mistake I made as a young man, certainly, and it took me years of learning the hard way that I wasn't always right. Also: there's always a relevant XKCD. http://xkcd.com/793/ http://xkcd.com/793/
- raganwald 14y ago
  "smart" and "gets things done" are sufficiently vague that they can mean whatever you want. If I say "So-and-so is smart, however X," the reply can always be "Well, if X then so-and-so isn't truly smart" in the No True Scotsman sense. This is why I tried (perhaps poorly) to be specific and talk about smart in the sense of mathematics.
  - nimblegorilla 14y ago
    I think in the instance you described you were and weren't being smart in the sense of a True Smart Scotsman. Mathematic smarts isn't always enough to know how something really works. But I still think you were smart enough to realize you might be wrong and to double check how it really works. Also, you have the GTD mindset to accept how Proc works and try to learn from the experience instead of obsessing about how Proc is broken and ruby sucks.
jeremiep 14y ago
Steve Yegge wrote a great piece on the subject: http://steve-yegge.blogspot.ca/2008/06/done-and-gets-things-smart.html?m=1 http://steve-yegge.blogspot.ca/2008/06/done-and-gets-things-...
michaelochurch 14y ago
You want second-order smart. Not just experienced in the technologies you happen to use (as OP alleges), and not just generally quick learning (first-order smart). You want introspective and seasoned second-order learners: people who've learned how to learn, even under adverse circumstances, how to figure out what's worth learning, and how to tell when you've learned enough that the right next step is to start doing. One of the most useful things I've gotten out of my machine learning study and work on MOOCs is second-order learning. I've learned a lot about how I learn, especially under the added and somewhat artificial difficulty of having a full-time job. Very valuable second-order insights. "Gets things done" is ridiculous. It's a good size-up for very junior level developers, but beyond that... you want "does the right thing". The idea that there's a large number of perfectionists or lazy people who are constitutionally incapable of "delivering" is nonsense. When to stop perfecting and optimizing is one of many important skills, but not a hard one to learn. So... let's make it, second-order smart and does the right thing.
- juiceandjuice 14y ago
  As someone who has taken engineering courses and holds a BS in applied physics and a minor in math, while working as a developer (for physics experiments), I'd have to say that physics, more than any other major, teaches you how to learn. In reality, the main reason a BS in Physics even exists is to teach you how to learn so you're prepared when you get to graduate school to work on new problems people haven't had to face before. The unfortunate thing is that corporate american tends to highly undervalue the BS in Physics. While I graduated at the worst time possible time (2008/2009), it took me over a year and a half to find a "real" job. No, I didn't have two + years experience in developing with .Net. I did have 4 years of experience in everything from LabView to Verilog, photomultiplier tube calibration and particle detector design to advanced electrodynamics to CADD and machining, and all the calculus and linear algebra necessary to get there. As someone who was perpetually frustrated by a lack of consideration when applying to jobs, I'd just like to recommend that anyone reading this comment to always consider a candidate with a background in the hard sciences, even if they don't have the relevant experience.
  - 14y ago
nollidge 14y ago
I feel like this post might be talking about the arrogance/humility axis, which is important but orthogonal to both dumb/smart and lazy/gets-it-done (depending, I suppose, on how you define those things). Humility is necessary to say "yes, I'm smart, but there are the limits of that intelligence." Any smart person can learn enough C++ to get things done if they know Java, but it takes humility to say "I will learn C++ idiomatically and approach it on its own terms, rather than coding up Java paradigms with C++ keywords and libraries".
madhadron 14y ago
I'd say your argument was convincing, but you forgot that Ruby's language design is full of sharp edges where features were forced together in poorly thought out ways. For example, I yesterday learned that you can't determine the order of invocation when chaining super through multiple mixins that override the same method of a class. It's as though the designers thought that saying "we don't do multiple inheritance, just mixins" relieved them of actually having to define their semantics properly. So it's not that your reasoning was wrong. It's that your conclusion was. The right conclusion was, "What the hell were those amateurs thinking? That's idiotic!" I'm going to go fondle my ALGOL 60 report now...
- pnathan 14y ago
  Is there an Algol compiler for Linux these days? Brief poking reveals there's an Algol68 out there for Ubuntu.
freshhawk 14y ago
Hmm, this lead me down a different path of thinking. This is exactly why the rough edges in language design like the proc/lambda differences in ruby impose a considerable cost on the community as a whole when you add it all up. As I get more experience I appreciate the benefits of languages that try very hard to minimize cases like this, as well as how difficult that is and the trade-offs that must be made. It's hard to encourage flow type states of high productivity when your mental model of execution either keeps disagreeing with reality or is so full of previously discovered edge cases that it's too complicated to do useful simulations of code in your head.
dasil003 14y ago
An interesting read as always from raganwald, but I think the title is off. It seems to me that the reason Joel added "gets things done" to his creed was to avoid exactly these kinds of problems, and by "these kinds" I mean all the myriad ways that smart people shoot themselves in the foot by either overthinking, or making assumptions, or just plain being used to gliding through on minimal effort. Now obviously the definition of "smart and gets things done" is open to a huge amount of interpretation, but I think it's clear enough that he means getting things done in terms of shipping useful product. If one does that, then the problems that come with inexperience are self-rectifying. The problem is if someone is not "smart", they won't learn from their mistakes, and if someone doesn't "get things done" they may lose site of the final goal and fall into mental tarpits as they gain experience.
TOGoS 14y ago
+1 because of the up-front TL;DR.
- scott_s 14y ago
  Where I come from, we just call it an abstract.
j_baker 14y ago
We pondered this for a while and the conversation meandered elsewhere, no doubt because my companions were embarrassed on my behalf. I had committed one of the basic errors of inexperience with the state of programming: Assuming that you're smart and you can work things out from first principles. I used to have this problem. Not the "problem" of assuming you're smart. I mean the problem of assuming that if someone moves the conversation away or disagrees with me, it must be because of something I'd done. Psychologists call this "intrapunitive behavior". Here's what I would posit happened: you said something intelligent that your companions had no way of countering. Thus, you showed them up and rather than fess up to it, they decided to change the subject.
- raganwald 14y ago
  Thanks for the support, but that was a literary device.
  - j_baker 14y ago
    Then I suppose I'm saying that I support you, but not your literary devices. :-)
d23 14y ago
The great conceit of thinking you are "smart" is believing that because you are very good at working out consequences from axioms, you needn't know everything. If you know the axioms and the rules, that's it, you know everything. I feel like I have to deal with this all the time -- people who think they're smart and reason their way to tenuous conclusions based upon a ton of seemingly solid beliefs. This rarely ever works, and it surprises me how people who base a significant portion of identity on being "smart" don't grasp that basic point. There are a lot more confounding variables than there are times when things go perfectly. 6 months of direct knowledge/experience of a particular domain can go a lot further than a year of theory. In theory, anyway.
- benjamincburns 14y ago
  I think the underlying point in all of this is just that "smart and gets things done" isn't something someone can be trusted to observe about themselves. The example he gives about FizzBuzz in the Lambda Calculus is perfect. If you're truly working from first principles, then you ought to understand the difference between a theoretical and an acceptable solution. I'd say that in the context of software, "smart and gets things done" is at a minimum someone with a solid ability to extrapolate from first principles coupled with the ability to problem solve and think critically about what is is they're actually building. Experience helps tons on that front, but it's no better an indicator of future success than grasping first principles.
taf2 14y ago
this was a lot of words about how - you have to just try something really to know how it works... it's like voyager 1, we thought we knew what the edge of the solar system would be like, but until we actually reached it or at least reached the zone we are in now we didn't know it would behave the way it does... With code, that is also true, you can't assume it will behave as you'd expect, what if under the given conditions there is a bug in the assembly code generated by gcc when it compiled the ruby interpreter such that the lambda behaved incorrectly? Or even a bit of memory was flipped into an invalid or unexpected state... shit happens which is why we must type, test, type, test, type test... all day to figure out how it really works...
bestes 14y ago
Can someone take a shot at listing a few math languages vs non-math ones?
mcgwiz 14y ago
This is especially true and contradicts the generally accepted opinion repeatedly expressed around here, that knowing about programming in general is enough to be an expert in any technology in a short amount of time. The reasoning then goes that when hiring, one shouldn't rule out seasoned developers that have no experience in the technologies in actual use. This is an arrogant recipe for pain for the whole team. The myriad combination of interfaces between tools/stacks/technologies cannot be understood expertly in any small amount of time. I suffered at a polyglot consultancy that shifted people around rapidly between stacks and technologies due to overconfidence in this belief; it is very painful for any programmer with a sense of craft and client stewardship. Of course, if all you care about is banging out a piece of garbage that will hold up until the checks clear, then I guess this doesn't matter.

96 points by raganwald 14y ago

deleted 14y ago

[deleted]

gcmartinelli 14y ago
I, on the other hand, suspect that many people buying these books don't even want to get a job in programming... maybe they just want to learn, or build their personal projects. http://planoa.wordpress.com/2012/12/05/why-google-and-others-should-support-massive-online-open-education/ http://planoa.wordpress.com/2012/12/05/why-google-and-others...
- gte910h 14y ago
  I am a professional programmer who's been working in the field for over a decade, who went to a top 40 school, use multiple languages professionally, yadda yadda. I buy those books and the "best" advanced book on the language when I want to get up to speed fast. Going through and doing all the exercises, and stupidly simple setup they always have is so worth it. Typing in all the code takes almost no time at all, and it gets you the basic understanding down pretty fast. Then the advanced book smacks any bad things the silly book tried to give you, and you can start making something real with it.

gtrak 14y ago

I think the counter-argument is this: We have control over the amount of real reasoning we can do about our code. The hassle of the real can be minimized. For example, I like clojure, and there are real benefits to theoretical things like immutability by default, or garbage collection. This ability to reason mathematically while being practical is worth promoting in computer science and engineering. If I couldn't reason this way about programming, I wouldn't be a programmer. Engineering is the intersection from theory to practice, and I appreciate that in computing, incidental complexity can usually be traced back to someone's neglect. Without this, we only have heuristics. There is no silver bullet, but things can be made measurably better. We can accept reality without giving up on reason. I think to prove it, we can look at the influence of mathematics on real discoveries in history, and maybe ponder if humans are just meant to think this way in order to make progress. I hope my code reflects more order (purity, generality, conciseness) than chaos (special cases, entropy, technical debt). I would just call the procs thing a 'wart' and avoid using it. I don't think my opinion favors the mathematically inclined programmers over the empiricists. So, let's think about the kinds of things that get done as a consequence of certain types of thinking. Tradeoffs.

luu 14y ago

I pretty much agree, but I'd like to point out that, as a field, programming emphasizes the importance of "Smart and Gets Things Done" more than pretty much any other field does. I've been interviewing lately, both at hardware and software companies. At microprocessor startups, I ask about the pedigree (past experience, not educational credentials) of pretty much everyone I meet. I don't do that at software companies. The reason is, you pretty much never hear about a new team successfully making a high-performance microprocessor. Apple bought PA Semi, which had a moderately successful exit, but PA Semi was basically the SiByte team, which left after SiByte was acquired by Broadcom, and SiByte was composed of key people from DEC who had been working together for over a decade. When you hear about a new team where most of the people are smart new grads, they usually spend ~ $100M over five or six years years, find that they don't have a competitive product (or, more likely, don't even have anything that's close to working). If they have funding left to burn they may pivot a couple times over the course of a couple years before they burn through their cash and implode. And that's despite microprocessor design being close to pure reason, in the grand scheme of things. Experience and wisdom matter a lot more in most endeavors. Something you see a lot, even here on HN, when non-CS/programming/engineering topics make it to the front page, are people who try to extrapolate from a few "obvious" facts and then come up with a conclusion that's completely and totally wrong. In software, you hear about successful companies founded by people just out of school, or even people who have dropped out of school, all the time. "Smart and Gets Things Done" can be good enough to make a decent product. But, something you'd never want to hear from a plumber or a carpenter is "well, I've read some books on the topic, and tried out some tools at home depot, plus I'm smart and good at hacking". Things like carpentry, manufacturing, etc. are hard. They're done so well here (in developed countries) that it's easy to forget an idea of how hard they really are. If you want to get an idea of how hard they are to learn from scratch, consider South Korea after WII. Its GDP per capita was lower than Ghana, Kenya, and just barely above the Congo[1]. For various reasons, the new regime didn't have much baggage, and they wanted Korea to become a first-world nation. The story I've heard is that the government started by subsidizing concrete. After many years making concrete, they wanted to move up the manufacturing chain and start making ships (among other things). They pulled some of their best people who had experience in business (having learned skills like management, operations, etc.) from working in concrete to try to build ships. They knew they didn't have the expertise to do it themselves, so they contracted out the plans and got detailed instructions how to build ships. They got plans from Scotland, because Scotland has a long history of shipbuilding. Makes sense, right? But, when the Koreans tried to build ships with Scottish plans and detailed step-by-step directions, the result was two ship halves that didn't quite fit together and sunk when assembled. For historical and geographic reasons, Scotland's shipyards weren't full-sized, and they built their ships in two halves and then assembled them. Worked fine for them, because they'd be doing it at scale since the 1800s, and had world renowned expertise by the 1900s[2]. The Koreans eventually managed to start a shipbuilding industry by hiring foreign companies to come and, build ships locally, and show people how it's done. It took decades to what we would consider basic manufacturing working smoothly, even though all of the requisite knowledge existed in books, was taught in university courses, and could be had from experts for a small fee. "Smart and Gets Things Done" goes so much further in programming than it does in virtually any other non-academic field. Today, anyone with a CS 101 background can take Geoffrey Hinton's course on neural networks and deep learning[3] and start applying state of the art machine learning techniques[4] to research grade problems within a couple months. But, if you want to build a ship, and you "only" have a decade of experience with carpentry, milling, metalworking, etc., well, good luck. You're going to need it. [1] http://www.nationmaster.com/graph/eco_gdp_per_cap_in_195-economy-gdp-per-capita-1950 http://www.nationmaster.com/graph/eco_gdp_per_cap_in_195-eco... [2] In 1913, 20% of the world's ships were built at Clyde. [3] https://www.coursera.org/course/neuralnets https://www.coursera.org/course/neuralnets [4] About 1/3rd of the way through the course, he talks about a new technique that was published after the course actually started. The future of education is going to be awesome.

holograham 14y ago

to me, constantly learning is part of being smart and getting things done, especially in the tech industry. You cant be smart and getting things done unless you are learning the latest tools and techniques. I have always like the saying "get things done, smart" better which perhaps encompasses this post's thesis better than Joel's original wording.

Jabbles 14y ago

To be honest, I didn't think there was much of an argument or a point here. The conclusion that "there's no substitute for experience" doesn't follow from the rest of the article, and most of the rest of the conclusion falls into "getting things done" anyway. You were able to think of an edge case for language feature that neither of your friends had considered. Awesome. Smart. Realising that upfront is the kind of skill that saves you hundreds (anecdotally) of hours of debugging because you solve it in the design phase. Saying "smart interferes with gets things done" is exactly what Joel was saying when he tacked on "and gets things done" - so you can't really use that to argue he left something out. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. http://www.joelonsoftware.com/articles/fog0000000073.html http://www.joelonsoftware.com/articles/fog0000000073.html

raganwald 14y ago
This is an interesting reply, thanks. I possibly didn't explain this well. My reasoning didn't actually help, unfortunately, because I convinced my self that a proc MUST behave like a lambda with respect to "return" semantics. So had I been left to my own devices, I might have written some Ruby code that assumed it was perfectly safe to return a proc from a method. This is a real danger for me, as I like programming with combinators. And I would have been bitten by my mistaken beliefs. The only thing I'll say in my own defence is that having made this mistake many times, I had the good sense to check how things actually worked when I got home. I used to know, I'd forgotten, and now I know again. I don't know if that's "getting things done." It may be spinning wheels. Perhaps someone "getting things done" never wastes any time worrying about the difference because they never bother to wonder what happens when you return a proc from a method. They simply avoid the problem in the first place, so not knowing is irrelevant.
- Jabbles 14y ago

kylemaxwell 14y ago

I think this conflates "smart" in the sense of "raw ability to reason" with "smart" in the sense of "knows the intricacies of how things work". Or, as my uncles might have said, "book learnin' versus real knowin'". In fact, even in the example given with respect to Ruby procs and lambdas and returns and whatnot, clearly the author hadn't "gotten things done" in that area (by his own admission, this isn't snark). So to me, the real point is that thinking you've worked everything out from first principles doesn't mean you actually understand all the implications of the interactions in a complex system. That's the mistake I made as a young man, certainly, and it took me years of learning the hard way that I wasn't always right. Also: there's always a relevant XKCD. http://xkcd.com/793/ http://xkcd.com/793/

raganwald 14y ago
"smart" and "gets things done" are sufficiently vague that they can mean whatever you want. If I say "So-and-so is smart, however X," the reply can always be "Well, if X then so-and-so isn't truly smart" in the No True Scotsman sense. This is why I tried (perhaps poorly) to be specific and talk about smart in the sense of mathematics.
- nimblegorilla 14y ago
  I think in the instance you described you were and weren't being smart in the sense of a True Smart Scotsman. Mathematic smarts isn't always enough to know how something really works. But I still think you were smart enough to realize you might be wrong and to double check how it really works. Also, you have the GTD mindset to accept how Proc works and try to learn from the experience instead of obsessing about how Proc is broken and ruby sucks.

jeremiep 14y ago

Steve Yegge wrote a great piece on the subject: http://steve-yegge.blogspot.ca/2008/06/done-and-gets-things-smart.html?m=1 http://steve-yegge.blogspot.ca/2008/06/done-and-gets-things-...

michaelochurch 14y ago

You want second-order smart. Not just experienced in the technologies you happen to use (as OP alleges), and not just generally quick learning (first-order smart). You want introspective and seasoned second-order learners: people who've learned how to learn, even under adverse circumstances, how to figure out what's worth learning, and how to tell when you've learned enough that the right next step is to start doing. One of the most useful things I've gotten out of my machine learning study and work on MOOCs is second-order learning. I've learned a lot about how I learn, especially under the added and somewhat artificial difficulty of having a full-time job. Very valuable second-order insights. "Gets things done" is ridiculous. It's a good size-up for very junior level developers, but beyond that... you want "does the right thing". The idea that there's a large number of perfectionists or lazy people who are constitutionally incapable of "delivering" is nonsense. When to stop perfecting and optimizing is one of many important skills, but not a hard one to learn. So... let's make it, second-order smart and does the right thing.

juiceandjuice 14y ago
As someone who has taken engineering courses and holds a BS in applied physics and a minor in math, while working as a developer (for physics experiments), I'd have to say that physics, more than any other major, teaches you how to learn. In reality, the main reason a BS in Physics even exists is to teach you how to learn so you're prepared when you get to graduate school to work on new problems people haven't had to face before. The unfortunate thing is that corporate american tends to highly undervalue the BS in Physics. While I graduated at the worst time possible time (2008/2009), it took me over a year and a half to find a "real" job. No, I didn't have two + years experience in developing with .Net. I did have 4 years of experience in everything from LabView to Verilog, photomultiplier tube calibration and particle detector design to advanced electrodynamics to CADD and machining, and all the calculus and linear algebra necessary to get there. As someone who was perpetually frustrated by a lack of consideration when applying to jobs, I'd just like to recommend that anyone reading this comment to always consider a candidate with a background in the hard sciences, even if they don't have the relevant experience.
- 14y ago

nollidge 14y ago

I feel like this post might be talking about the arrogance/humility axis, which is important but orthogonal to both dumb/smart and lazy/gets-it-done (depending, I suppose, on how you define those things). Humility is necessary to say "yes, I'm smart, but there are the limits of that intelligence." Any smart person can learn enough C++ to get things done if they know Java, but it takes humility to say "I will learn C++ idiomatically and approach it on its own terms, rather than coding up Java paradigms with C++ keywords and libraries".

madhadron 14y ago

I'd say your argument was convincing, but you forgot that Ruby's language design is full of sharp edges where features were forced together in poorly thought out ways. For example, I yesterday learned that you can't determine the order of invocation when chaining super through multiple mixins that override the same method of a class. It's as though the designers thought that saying "we don't do multiple inheritance, just mixins" relieved them of actually having to define their semantics properly. So it's not that your reasoning was wrong. It's that your conclusion was. The right conclusion was, "What the hell were those amateurs thinking? That's idiotic!" I'm going to go fondle my ALGOL 60 report now...

pnathan 14y ago
Is there an Algol compiler for Linux these days? Brief poking reveals there's an Algol68 out there for Ubuntu.

freshhawk 14y ago

Hmm, this lead me down a different path of thinking. This is exactly why the rough edges in language design like the proc/lambda differences in ruby impose a considerable cost on the community as a whole when you add it all up. As I get more experience I appreciate the benefits of languages that try very hard to minimize cases like this, as well as how difficult that is and the trade-offs that must be made. It's hard to encourage flow type states of high productivity when your mental model of execution either keeps disagreeing with reality or is so full of previously discovered edge cases that it's too complicated to do useful simulations of code in your head.

dasil003 14y ago

An interesting read as always from raganwald, but I think the title is off. It seems to me that the reason Joel added "gets things done" to his creed was to avoid exactly these kinds of problems, and by "these kinds" I mean all the myriad ways that smart people shoot themselves in the foot by either overthinking, or making assumptions, or just plain being used to gliding through on minimal effort. Now obviously the definition of "smart and gets things done" is open to a huge amount of interpretation, but I think it's clear enough that he means getting things done in terms of shipping useful product. If one does that, then the problems that come with inexperience are self-rectifying. The problem is if someone is not "smart", they won't learn from their mistakes, and if someone doesn't "get things done" they may lose site of the final goal and fall into mental tarpits as they gain experience.

TOGoS 14y ago

+1 because of the up-front TL;DR.

scott_s 14y ago
Where I come from, we just call it an abstract.

j_baker 14y ago

We pondered this for a while and the conversation meandered elsewhere, no doubt because my companions were embarrassed on my behalf. I had committed one of the basic errors of inexperience with the state of programming: Assuming that you're smart and you can work things out from first principles. I used to have this problem. Not the "problem" of assuming you're smart. I mean the problem of assuming that if someone moves the conversation away or disagrees with me, it must be because of something I'd done. Psychologists call this "intrapunitive behavior". Here's what I would posit happened: you said something intelligent that your companions had no way of countering. Thus, you showed them up and rather than fess up to it, they decided to change the subject.

raganwald 14y ago
Thanks for the support, but that was a literary device.
- j_baker 14y ago
  Then I suppose I'm saying that I support you, but not your literary devices. :-)

d23 14y ago

The great conceit of thinking you are "smart" is believing that because you are very good at working out consequences from axioms, you needn't know everything. If you know the axioms and the rules, that's it, you know everything. I feel like I have to deal with this all the time -- people who think they're smart and reason their way to tenuous conclusions based upon a ton of seemingly solid beliefs. This rarely ever works, and it surprises me how people who base a significant portion of identity on being "smart" don't grasp that basic point. There are a lot more confounding variables than there are times when things go perfectly. 6 months of direct knowledge/experience of a particular domain can go a lot further than a year of theory. In theory, anyway.

benjamincburns 14y ago
I think the underlying point in all of this is just that "smart and gets things done" isn't something someone can be trusted to observe about themselves. The example he gives about FizzBuzz in the Lambda Calculus is perfect. If you're truly working from first principles, then you ought to understand the difference between a theoretical and an acceptable solution. I'd say that in the context of software, "smart and gets things done" is at a minimum someone with a solid ability to extrapolate from first principles coupled with the ability to problem solve and think critically about what is is they're actually building. Experience helps tons on that front, but it's no better an indicator of future success than grasping first principles.

taf2 14y ago

this was a lot of words about how - you have to just try something really to know how it works... it's like voyager 1, we thought we knew what the edge of the solar system would be like, but until we actually reached it or at least reached the zone we are in now we didn't know it would behave the way it does... With code, that is also true, you can't assume it will behave as you'd expect, what if under the given conditions there is a bug in the assembly code generated by gcc when it compiled the ruby interpreter such that the lambda behaved incorrectly? Or even a bit of memory was flipped into an invalid or unexpected state... shit happens which is why we must type, test, type, test, type test... all day to figure out how it really works...

bestes 14y ago

Can someone take a shot at listing a few math languages vs non-math ones?

mcgwiz 14y ago

This is especially true and contradicts the generally accepted opinion repeatedly expressed around here, that knowing about programming in general is enough to be an expert in any technology in a short amount of time. The reasoning then goes that when hiring, one shouldn't rule out seasoned developers that have no experience in the technologies in actual use. This is an arrogant recipe for pain for the whole team. The myriad combination of interfaces between tools/stacks/technologies cannot be understood expertly in any small amount of time. I suffered at a polyglot consultancy that shifted people around rapidly between stacks and technologies due to overconfidence in this belief; it is very painful for any programmer with a sense of craft and client stewardship. Of course, if all you care about is banging out a piece of garbage that will hold up until the checks clear, then I guess this doesn't matter.