6 ms·

Most of these have wide acceptance among the HN/Startup crowd; I might expect to see more disagreement if the list were exposed to corporate programming environ

by ajdecon 14y ago

Most of these have wide acceptance among the HN/Startup crowd; I might expect to see more disagreement if the list were exposed to corporate programming environments, or especially to their managers. I have a couple of quibbles, though: - 1: I'd modify "Programmers who don’t code in their spare time for fun will never become as good as those that do", to be "Programmers who don't code in their spare time for fun will never be as good as they would if they did". I definitely believe coding for fun helps your skills, but I've seen too many "just-a-job" programmers code circles around others on the same teams who had side projects and kept up with the trendy languages. It's not a clear differentiator, just a data point. - 2: Unit tests don't help you code in the same way that a safety net doesn't help you walk a tightrope: this is technically true, but not a helpful statement in reality. - 10: Print statements are "valid" in that they often work, but when a debugger is available it's almost always the right way to go.

learc83 14y ago
>Unit tests don't help you code in the same way that a safety net doesn't help you walk a tightrope: this is technically true, but not a helpful statement in reality. The author mentioned that unit tests are useful to check for broken code, but he's saying TDD doesn't actually help you write better code--that there are plenty of other ways to screw up that unit tests won't catch so the extra cost of writing them ins't worth it (in his opinion). He's saying that it's an ineffective safety net, not worth the extra time involved setting it up. I started out as a ruby developer, and I personally think TDD is can be useful, but it's not the panacea that the TDD cargo cult proclaims it is.
awolf 14y ago
>Print statements are "valid" in that they often work, but when a debugger is available it's almost always the right way to go. I don't know about this one. I think that having to write print statements makes you do actual thinking about your debugging strategy and therefore makes you understand the flow of your code more. A debugger is certainly useful, but I was surprised the first time I had to go without one to find that I didn't miss it that much and possibly was even more efficient.
- jedbrown 14y ago
  Debuggers have features like watchpoints, which cannot be emulated in any form using print statements. Also, many codebases are not set up to provide a decent stack trace without using a debugger. Features like watchpoints allow you to think about the debugging process in a very different way and can turn many otherwise difficult bugs into 30-second fixes.
  - nuclear_eclipse 14y ago
    > Also, many codebases are not set up to provide a decent stack trace without using a debugger. Is that not a problem of the codebase, language, and/or debugging system being used than a problem with printing/logging?
- debacle 14y ago
  I agree. In my experience, the only thing a debugger is most useful for (way faster than manual debugging) is performance.
- KirinDave 14y ago
  Debuggers are great and superior to print statements when they're usable. Use a debugger when you can. Sadly, it is increasingly the case that you cannot use a debugger when you want to use one. Print statement binary search is primitive, but it's survived as a tool because it's almost universally applicable.
  - vlisivka 14y ago
    IMHO, it is better to invest time into code quality than waste time on manual debugging. If you will spend your time on code, which will answer you where problem is, you will be better coder and you will have code, which you will be able to share and reuse more than once. If you will spend your time on manual testing and debugging of application, you will be better tester. For example, compare gdb with valgrind. I successfully avoid manual debugging for more than 10 years (after about 10 years of active use).
  - primitur 14y ago
DenisM 14y ago
10 - a complex system is likely to fail in the field, not on your desk, and print statements, redirected to a log file, are your last line of defense to iron out those rare or production-only bugs.
ajross 14y ago
That was my feeling too. I kept reading through the list and nodding, wondering where the "controversy" was supposed to be. Regarding your criticism of #2, I think you're arguing orthogonally. The point to me seemed to be against TDD and the idea that code written "to" a test is inherently better. The point is to write and execute tests, not to fetishize how those tests are written or run. And your point about #10 is just plain wrong, sorry. Arguments of the form "debuggers are easier than hacked-up logging" always presuppose that the "hacked-up logging" is hard to do. The fact that you feel more comfortable typing into gdb or whatever than you do adding a line of code and rebuilding tells me that you don't feel comfortable building and running your code. If that's the case, then you have already lost. Debug via printf works better because projects designed for debug via printf are inherently better. This applies to fancy tracing tools as well. They have their place, but if you can't whip out a printf then you need to fix that first.
- samspot 14y ago
  And, you can look at logs from production when something goes wrong. In my experience the debugger can only take the place of logs if you have access to the same data, and in many organizations you don't get that luxury.
majormajor 14y ago
"I'd modify "Programmers who don’t code in their spare time for fun will never become as good as those that do", to be "Programmers who don't code in their spare time for fun will never be as good as they would if they did". I definitely believe coding for fun helps your skills, but I've seen too many "just-a-job" programmers code circles around others on the same teams who had side projects and kept up with the trendy languages. It's not a clear differentiator, just a data point." Yeah, as originally written it basically reduces to "programmers with more experience are always better than those with less experience" and that's just not true. Side projects are a good sign that someone cares, and a good way to get experience faster than others and (potentially, unless you're just repeating stuff you already know in them) keep your experience diverse, but that's all.
- danielweber 14y ago
  Somewhere along the line, it changed from "do you program in your spare time?" to "show us your side projects." I program in my spare time. I like it. But when interviewers want to pour over my "spare time" code before I get a job, it stops being fun. It becomes more work.
  - thwarted 14y ago
    Without the ability to look at code you've written "on the job", side projects are the next best thing. Get a license for code you've written at previous employers and showcase that during the interview.
    - danielweber 14y ago
      Get a license for code you've written at previous employers "Hi, I'm leaving. Oh, can I have a license for all the source code I've written?"
      - thwarted 14y ago
        It's not necessarily unheard of. People who work at architecture firms routinely having portfolios of stuff they've worked on. If you don't have a portfolio of work from previous employers handy, what is in your portfolio? And if one doesn't have a portfolio of demo code that showcases style and experience and skill, one doesn't really get to complain that someone else doesn't have context to judge appropriateness for a job, or that they are expecting some context to be able to make an informed judgement.
SCdF 14y ago
>Most of these have wide acceptance among the HN/Startup crowd; I might expect to see more disagreement if the list were exposed to corporate programming environments, or especially to their managers. Hi, corporate code monkey here: that list looks entirely fine and not particularly controversial. Thanks.
- repsilat 14y ago
  It's telling that these are the 20 most upvoted "controversial" opinions. I don't think they should have taken the 20 most controversial (according to the voting system), or the 20 most downvoted, but the system chosen does have obvious consequences. Looking at the results, they break down a few ways - Reactions to corporate processes and "things management likes", old and unpopular things are no good, programmers should be more free to express themselves and so on. The reason people think these things are "controversial" is that the sources of information these programmers are getting are often limited to their immediate environment, their university profs, and what they read online. That naturally excludes the bulk of competent programmers who don't blog or speak in conferences[1]. It's impossible to constantly remember to account for the biases in the media you consume, so people are naturally (and gradually) led to believe that the trendy ideas of yesterday and today are ubiquitous. They forget about the masses of programmers doing heads-down development on non-web, non-mobile platforms because the web and mobile guys are trendy and they all have blogs. 1: http://prog21.dadgum.com/143.html http://prog21.dadgum.com/143.html

by ajdecon 14y ago

learc83 14y ago

>Unit tests don't help you code in the same way that a safety net doesn't help you walk a tightrope: this is technically true, but not a helpful statement in reality. The author mentioned that unit tests are useful to check for broken code, but he's saying TDD doesn't actually help you write better code--that there are plenty of other ways to screw up that unit tests won't catch so the extra cost of writing them ins't worth it (in his opinion). He's saying that it's an ineffective safety net, not worth the extra time involved setting it up. I started out as a ruby developer, and I personally think TDD is can be useful, but it's not the panacea that the TDD cargo cult proclaims it is.

awolf 14y ago

>Print statements are "valid" in that they often work, but when a debugger is available it's almost always the right way to go. I don't know about this one. I think that having to write print statements makes you do actual thinking about your debugging strategy and therefore makes you understand the flow of your code more. A debugger is certainly useful, but I was surprised the first time I had to go without one to find that I didn't miss it that much and possibly was even more efficient.

jedbrown 14y ago
Debuggers have features like watchpoints, which cannot be emulated in any form using print statements. Also, many codebases are not set up to provide a decent stack trace without using a debugger. Features like watchpoints allow you to think about the debugging process in a very different way and can turn many otherwise difficult bugs into 30-second fixes.
- nuclear_eclipse 14y ago
  > Also, many codebases are not set up to provide a decent stack trace without using a debugger. Is that not a problem of the codebase, language, and/or debugging system being used than a problem with printing/logging?
debacle 14y ago
I agree. In my experience, the only thing a debugger is most useful for (way faster than manual debugging) is performance.
KirinDave 14y ago
Debuggers are great and superior to print statements when they're usable. Use a debugger when you can. Sadly, it is increasingly the case that you cannot use a debugger when you want to use one. Print statement binary search is primitive, but it's survived as a tool because it's almost universally applicable.
- vlisivka 14y ago
  IMHO, it is better to invest time into code quality than waste time on manual debugging. If you will spend your time on code, which will answer you where problem is, you will be better coder and you will have code, which you will be able to share and reuse more than once. If you will spend your time on manual testing and debugging of application, you will be better tester. For example, compare gdb with valgrind. I successfully avoid manual debugging for more than 10 years (after about 10 years of active use).
- primitur 14y ago

DenisM 14y ago

10 - a complex system is likely to fail in the field, not on your desk, and print statements, redirected to a log file, are your last line of defense to iron out those rare or production-only bugs.

ajross 14y ago

That was my feeling too. I kept reading through the list and nodding, wondering where the "controversy" was supposed to be. Regarding your criticism of #2, I think you're arguing orthogonally. The point to me seemed to be against TDD and the idea that code written "to" a test is inherently better. The point is to write and execute tests, not to fetishize how those tests are written or run. And your point about #10 is just plain wrong, sorry. Arguments of the form "debuggers are easier than hacked-up logging" always presuppose that the "hacked-up logging" is hard to do. The fact that you feel more comfortable typing into gdb or whatever than you do adding a line of code and rebuilding tells me that you don't feel comfortable building and running your code. If that's the case, then you have already lost. Debug via printf works better because projects designed for debug via printf are inherently better. This applies to fancy tracing tools as well. They have their place, but if you can't whip out a printf then you need to fix that first.

samspot 14y ago
And, you can look at logs from production when something goes wrong. In my experience the debugger can only take the place of logs if you have access to the same data, and in many organizations you don't get that luxury.

majormajor 14y ago

"I'd modify "Programmers who don’t code in their spare time for fun will never become as good as those that do", to be "Programmers who don't code in their spare time for fun will never be as good as they would if they did". I definitely believe coding for fun helps your skills, but I've seen too many "just-a-job" programmers code circles around others on the same teams who had side projects and kept up with the trendy languages. It's not a clear differentiator, just a data point." Yeah, as originally written it basically reduces to "programmers with more experience are always better than those with less experience" and that's just not true. Side projects are a good sign that someone cares, and a good way to get experience faster than others and (potentially, unless you're just repeating stuff you already know in them) keep your experience diverse, but that's all.

danielweber 14y ago
Somewhere along the line, it changed from "do you program in your spare time?" to "show us your side projects." I program in my spare time. I like it. But when interviewers want to pour over my "spare time" code before I get a job, it stops being fun. It becomes more work.
- thwarted 14y ago
  Without the ability to look at code you've written "on the job", side projects are the next best thing. Get a license for code you've written at previous employers and showcase that during the interview.
  - danielweber 14y ago
    Get a license for code you've written at previous employers "Hi, I'm leaving. Oh, can I have a license for all the source code I've written?"
    - thwarted 14y ago
      It's not necessarily unheard of. People who work at architecture firms routinely having portfolios of stuff they've worked on. If you don't have a portfolio of work from previous employers handy, what is in your portfolio? And if one doesn't have a portfolio of demo code that showcases style and experience and skill, one doesn't really get to complain that someone else doesn't have context to judge appropriateness for a job, or that they are expecting some context to be able to make an informed judgement.

SCdF 14y ago

>Most of these have wide acceptance among the HN/Startup crowd; I might expect to see more disagreement if the list were exposed to corporate programming environments, or especially to their managers. Hi, corporate code monkey here: that list looks entirely fine and not particularly controversial. Thanks.

repsilat 14y ago
It's telling that these are the 20 most upvoted "controversial" opinions. I don't think they should have taken the 20 most controversial (according to the voting system), or the 20 most downvoted, but the system chosen does have obvious consequences. Looking at the results, they break down a few ways - Reactions to corporate processes and "things management likes", old and unpopular things are no good, programmers should be more free to express themselves and so on. The reason people think these things are "controversial" is that the sources of information these programmers are getting are often limited to their immediate environment, their university profs, and what they read online. That naturally excludes the bulk of competent programmers who don't blog or speak in conferences[1]. It's impossible to constantly remember to account for the biases in the media you consume, so people are naturally (and gradually) led to believe that the trendy ideas of yesterday and today are ubiquitous. They forget about the masses of programmers doing heads-down development on non-web, non-mobile platforms because the web and mobile guys are trendy and they all have blogs. 1: http://prog21.dadgum.com/143.html http://prog21.dadgum.com/143.html