Hacker News Reader

>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.

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.

> 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?

I agree. In my experience, the only thing a debugger is most useful for (way faster than manual debugging) is performance.

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.

Print statements fit right in with good unit tests.

Print Statements, basically a form of logging, can be superior to debuggers, too (especially "when they're usable" :-) )

IMO, all three: logging, printing and the debugger have their place. In theory, print statements could be 100% replaced by debugger macros or dtrace, but the tooling just is better (it is easier to keep your output the same across runs) for a class of "takes a couple of days to find" bugs.

Debuggers are more efficient at locating and fixing specific bugs. However when you debug with print statements you get the opportunity to review the code and find bigger design problems that need to be fixed.

Furthermore, and more controversially, if you debug with debuggers, you will be driven to use programming techniques that are friendly to your debugger. But when you debug with print statements, you are free to use whatever programming techniques are best for human comprehension.

Now before you raise your keyboard and rush to disagree, consider carefully that the position I just described is agreed with by well-known programmers such as Linus Torvalds and Larry Wall. There are equally well-known programmers who disagree.

The true merits of the case are hard to determine. But if you think that one side is trivially wrong, then you should view this as a learning opportunity. Because you're certainly mistaken.

See http://lkml.indiana.edu/hypermail/linux/kernel/0009.0/1148.h... and http://www.perlmonks.org/?node_id=48495 for more background on this topic.

The only time I need to pull out a debugger is when I can't reason through the problem on my own (possibly with a couple print statements)

By and large, the only time I can't reason through the problem on my own is because the code in question is not properly unit tested, and it is complex to isolate the problem itself.

The only time it's worth my time to bring out the debugger is when the issue is so opaque as to require that level of in-depth investigation. I've spent days tracking down esoteric heap smashers in gdb.

However, most of the time, I just watch my unit test assertions fail, and then fix the issue.

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.

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.

"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.

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.

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.

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?"

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.

I'd much rather simply be asked to code (at the interview, or as a "homework" thing before the interview, whenever... just not over the phone, please!) something similar to what they'd want me to do at the job.

My side projects are for fun and playing around with new ideas, and don't really represent the style of code I'd be writing in a professional engagement. Here's an example from in the past: I wanted to crunch some baseball stat numbers using a Matlab library I'd found. So I hacked together some minimal parsing of publicly available game logs in Python, since I wasn't that interested in learning Matlab IO, then dumped them from Python to a format Matlab could read. Iterated that part until it worked for all the files I was interested on (but still in a rather ugly state) then hacked together some analysis in Matlab. DRY, or good design in general? Nah, it was a one-off thing.

You can't please everyone. There are numerous HN posts about how people don't want to spend a lot of time doing coding during an interview. Or are offended that they'd be ask to do a code test as part of an interview. And doing work for hire like this is considerd spec work in other industries, which is often frowned upon too.

My point was that sideproject code is better than no code at all. And it's not so much the quality of the code that's at issue, it's being able to talk intelligently about it. Hopefully you'd want to work with someone who can understand that something that is one-off is going to be lower quality than something you might write professionally, and having code to look at and examine that you wrote, that you're an expert on (because you wrote it), gives context to having discussions around how the code might be improved or why you made the decisions to made for a one-off.

There are numerous HN posts about how people don't want to spend a lot of time doing coding during an interview. Or are offended that they'd be ask to do a code test as part of an interview.

Those people are instant no-hires. You aren't going to write code when I ask you to write it? That is your job!

(I would grant exceptions is very exceptional cases, like the candidate having physically lost his hands. Or being blind.)

And doing work for hire like this is considerd spec work in other industries

Are you talking about the company giving the guy a problem, and then taking his answer and putting it right in their codebase without hiring him?

OP was talking about companies judging the quality of your one-off side project play for-fun code in the same way that they might judge the quality of your professional work code.

"Those people are instant no-hires. You aren't going to write code when I ask you to write it? That is your job!"

Well... typically, my 'job' involves people paying me as well. If you want me to 'code when you ask for it', then you need to pay for that. Or... make it easier to judge how I do stuff (like look at my side work).

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.

>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.

>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.

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