6 ms·

BIG disclaimer: I have NO formal training. 1. Tools. I generally shy away from tools. I just don't like using anything that makes me more productive when I'

by edw519 16y ago

BIG disclaimer: I have NO formal training. 1. Tools. I generally shy away from tools. I just don't like using anything that makes me more productive when I'm programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I want the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming "one" with my project is. I may not start as fast as others, but that doesn't matter. It's not how fast you start, it's how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it "firmware" in my brain. It's not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go very quickly; that code is already in my brain's RAM and it got there the hard way. 2. Simple Algorithms. Yes! I love this example: * EnterOrders 08/31/10 edw519 * return(); I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it. 3. Debugging. I don't. I've seen 25 different debuggers and I hate them all. Print() is my friend, especially beyond the right hand margin. Better yet, write code that doesn't need to be debugged (See #1 & #2 above.) (Of course, this is much harder with someone else's code.) 4. References. Don't need no stinkin' manual. I have become extremely adept at about 4% of what's available to me, but that 4% accomplishes 98% of what I want to do. (OK, I'll refer to a manual when I need something from the other 96%, but that doesn't happen too often.) Nice post, Gabriel. Got my juices flowing. We could talk about all kinds of other things too, like variable naming, how to iterate and branch, and never typing the same line of code twice, but this was a nice starting subset.

johnrob 16y ago
I share your aversion to debuggers. Everyone is different, and plenty of people like them - but I've always thought that they consume brain cycles that otherwise could be engaging with the code. That's why I like print(); it keeps my head in the code.
- barrkel 16y ago
  When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. Personally, I'm fond of configurable logging, but I'm not under any illusions; logs are like freeze-dried debug sessions with less features. Logs verbose enough to contain the relevant information can also get borderline unwieldy and time-consuming to generate and process. The compiler I work with, when hosted in the IDE, could easily produce over 100GB of log output on a complex project test case, so I usually try and keep it down to 1..2GB or so, but that often leaves out the incriminating evidence, so it takes some back and forth... And the reason I'm using log files at all is often because debugging itself gets unwieldy on large test cases.
  - jrockway 16y ago
    When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. We're talking about programming, and that's not programming. That's called piling shit on top of shit.
    - barrkel 16y ago
      No, it's what happens when you have code that's been maintained for decades by dozens of programmers, most of whom have since moved on to pastures new. Not all of the code has someone on the team who has full insight into it. Sometimes that code breaks because of changes elsewhere. Yes, it would be nice to fully understand the code before fixing the problem; but that's not always a luxury you have.
    - mcknz 16y ago
      I would argue that piling shit on top of shit would qualify as part of the job description for half of the corporate world, programmers and non.
      - 16y ago
barrkel 16y ago
Finding a buffer overrun is much easier with a debugger; if you have a deterministic test case, all you need to do is find the address of the corrupted memory (any point after you notice it's gone bad will do), then restart, set up a hardware breakpoint for that address, and continue: usually no more than a modification or two will do the trick. And if there's too many modifications, a different trick will do. Change the breakpoint to a counted breakpoint with a nice high count, then run until the corruption occurs, then check the pass count on the breakpoint. You can then set the count on the breakpoint to the exact value needed to stop at the corruption, like stepping back in time (i.e. the famous "who modified this variable last" debugger feature).
kenjackson 16y ago
"Better yet, write code that doesn't need to be debugged (See #1 & #2 above.) (Of course, this is much harder with someone else's code.)" This is pretty hard with your own code too. :-) It never ceases to amaze me how often I go back to code I've written and think, "Why did I think this would work for all cases and exceptional conditions?". Then again, it's often hard to remember what I knew a year ago... maybe I wasn't even aware of these cases.
astine 16y ago
"2. Simple Algorithms. Yes! I love this example: * EnterOrders 08/31/10 edw519 * return(); I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it." There is nothing like simply getting a "Hello World" up and running as a simple sanity check and starting point.
- cabacon 16y ago
  I like the game programming story about the black triangle to illustrate this point: http://rampantgames.com/blog/2004/10/black-triangle.html http://rampantgames.com/blog/2004/10/black-triangle.html
- techbio 16y ago
  This are called Tracer Bullets in the book "The Pragmatic Programmer" by Andrew Hunt and Dave Thomas. They advocate: Users get to see something early on. Developers build a structure to work in. You have an integration platform. You have something to demonstrate. You have a better feel for progress. As a solo founder I need working code, that I can put out of mind, while I produce more.
  - prodigal_erik 16y ago
    I've always heard "tracer bullet" as a request to a production system that selectively gets much more detailed logging or diagnostic output than usual.
    - aaronbrethorst 16y ago
      Which is to say you haven't read The Pragmatic Programmer? I highly, highly recommend it. I bought my first copy about 8 years ago, and pull it off the shelf once a year or so to freshen up. I always learn something new every time I do.
  - tjpick 16y ago
    I know this as top-down programming.
techbio 16y ago
#1,2 - http://news.ycombinator.com/item?id=1649922 http://news.ycombinator.com/item?id=1649922 #3 - inspired a "printState() div" 10,000px off-page #4 - Especially when there's more than one way to do it, relying on my little mind saves huge amounts of productive time.
vilya 16y ago
I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The thing is, every single bit of code you write depends on something else that you DIDN'T write. Everything. No exceptions. And the thing about stuff you didn't write is that you end up making assumptions about it - often without even realising. Sometimes the assumption is simply that the code works. Sometimes, some of your assumptions will be wrong. Debuggers help you check your assumptions. They're a very useful tool for this - more so than many people who say "I prefer printf" realise. I apologise if you're not in that category, but did you know that many debuggers have a way to print a message (without stopping) whenever the program hits a certain line? Just like printf, only it doesn't have to be built in to your code ahead of time. There are times when a debugger isn't the right tool for the job, but it's always better to make an informed choice.
- anamax 16y ago
  > I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The big advantage of printf as a debug technique is that it doesn't work unless you understand what you're doing. If you plan to debug using printf, you must write code that is easy to understand. Great debuggers let you try to fix code that you don't understand. Worse yet, they make it reasonable to write such code. Since the person reading the code is never as smart as the person who wrote the code, encouraging simple to understand code is extremely important.
  - Roboprog 16y ago
    A big disadvantage of printf() in C (or similar non-memory-managed languages) is that printing values can disturb the "noise" on the stack that you were trying to find. That is, if you had a bug due to an uninitialized local variable or buffer overrun, the printf() call could "stabilize" things and cause a bug to stop manifesting. Better to use a debugger, if you can. Not that I haven't ever sprinkled print's into the middle of a big mass of somebody else's code or framework just to get the initial lay of the land :-)
    - vicaya 16y ago
loewenskind 16y ago
I hate to say this, but you're never going to be very good (unless you change this). Someone good will have so many projects that they could never remember every detail of each of them, so every second you've spent burning this into your brain will be wasted. It's much better to use the tools as far as you can [1], use nice big descriptive names (since you never have to actually type them out this is win-win) and try to be as consistent as possible [2]. For projects I've been the driver on I never have to look at anything. I know how the project is going to be laid out, what the naming scheme will be like, etc. I can e.g. open up the Visual Studio solution file, Ctrl+n, type in the capital letters of the class I know will be of interest (e.g. WRI for WidgetRepositoryImplementation) and off I go. While you're still birthing out your first class I'll already be tightening up my tests. And there are people vastly better/faster than I am at this. [1] But be sensible about this. For me, big code generators are a no go. I use spring because it (a) doesn't sprinkle it's code anywhere I have to see and (b) regenerates the code every time so there is no sync issue between changing a source and regenerating a dependency. [2] Always refactor when you touch code, including making the code consistent with current coding standards.
- edw519 16y ago
  I hate to say this, but you're never going to be very good (unless you change this). I don't hate to say this, but responses like yours are the classic example of hn's biggest problem: people talking when they should be listening. I suppose your opinion could be accurate if we had a flux capacitor and you were making your prediction in 1979. But it's you versus 1,000,000 lines of code deployed, 1,000 successful projects, and 100 satisfied customers. They outrank you. FWIW, I made 2 posts yesterday. This grandparent which included intimate secrets of my success and earned nothing and this little joke: http://news.ycombinator.com/item?id=1649922 http://news.ycombinator.com/item?id=1649922 which earned 58 points. Gabriel Weinberg made wrote an interesting post which got my juices flowing and led me to share my experience (experience, not opinion). Then people like you tell me I'm wrong or worse, that what actually happened couldn't have. Any wonder why outliers with successes to share are reluctant to share them?
  - loewenskind 16y ago

by edw519 16y ago

johnrob 16y ago

I share your aversion to debuggers. Everyone is different, and plenty of people like them - but I've always thought that they consume brain cycles that otherwise could be engaging with the code. That's why I like print(); it keeps my head in the code.

barrkel 16y ago
When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. Personally, I'm fond of configurable logging, but I'm not under any illusions; logs are like freeze-dried debug sessions with less features. Logs verbose enough to contain the relevant information can also get borderline unwieldy and time-consuming to generate and process. The compiler I work with, when hosted in the IDE, could easily produce over 100GB of log output on a complex project test case, so I usually try and keep it down to 1..2GB or so, but that often leaves out the incriminating evidence, so it takes some back and forth... And the reason I'm using log files at all is often because debugging itself gets unwieldy on large test cases.
- jrockway 16y ago
  When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. We're talking about programming, and that's not programming. That's called piling shit on top of shit.
  - barrkel 16y ago
    No, it's what happens when you have code that's been maintained for decades by dozens of programmers, most of whom have since moved on to pastures new. Not all of the code has someone on the team who has full insight into it. Sometimes that code breaks because of changes elsewhere. Yes, it would be nice to fully understand the code before fixing the problem; but that's not always a luxury you have.
  - mcknz 16y ago
    I would argue that piling shit on top of shit would qualify as part of the job description for half of the corporate world, programmers and non.
    - 16y ago

barrkel 16y ago

Finding a buffer overrun is much easier with a debugger; if you have a deterministic test case, all you need to do is find the address of the corrupted memory (any point after you notice it's gone bad will do), then restart, set up a hardware breakpoint for that address, and continue: usually no more than a modification or two will do the trick. And if there's too many modifications, a different trick will do. Change the breakpoint to a counted breakpoint with a nice high count, then run until the corruption occurs, then check the pass count on the breakpoint. You can then set the count on the breakpoint to the exact value needed to stop at the corruption, like stepping back in time (i.e. the famous "who modified this variable last" debugger feature).

kenjackson 16y ago

"Better yet, write code that doesn't need to be debugged (See #1 & #2 above.) (Of course, this is much harder with someone else's code.)" This is pretty hard with your own code too. :-) It never ceases to amaze me how often I go back to code I've written and think, "Why did I think this would work for all cases and exceptional conditions?". Then again, it's often hard to remember what I knew a year ago... maybe I wasn't even aware of these cases.

astine 16y ago

"2. Simple Algorithms. Yes! I love this example: * EnterOrders 08/31/10 edw519 * return(); I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it." There is nothing like simply getting a "Hello World" up and running as a simple sanity check and starting point.

cabacon 16y ago
I like the game programming story about the black triangle to illustrate this point: http://rampantgames.com/blog/2004/10/black-triangle.html http://rampantgames.com/blog/2004/10/black-triangle.html
techbio 16y ago
This are called Tracer Bullets in the book "The Pragmatic Programmer" by Andrew Hunt and Dave Thomas. They advocate: Users get to see something early on. Developers build a structure to work in. You have an integration platform. You have something to demonstrate. You have a better feel for progress. As a solo founder I need working code, that I can put out of mind, while I produce more.
- prodigal_erik 16y ago
  I've always heard "tracer bullet" as a request to a production system that selectively gets much more detailed logging or diagnostic output than usual.
  - aaronbrethorst 16y ago
    Which is to say you haven't read The Pragmatic Programmer? I highly, highly recommend it. I bought my first copy about 8 years ago, and pull it off the shelf once a year or so to freshen up. I always learn something new every time I do.
- tjpick 16y ago
  I know this as top-down programming.

techbio 16y ago

#1,2 - http://news.ycombinator.com/item?id=1649922 http://news.ycombinator.com/item?id=1649922 #3 - inspired a "printState() div" 10,000px off-page #4 - Especially when there's more than one way to do it, relying on my little mind saves huge amounts of productive time.

vilya 16y ago

I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The thing is, every single bit of code you write depends on something else that you DIDN'T write. Everything. No exceptions. And the thing about stuff you didn't write is that you end up making assumptions about it - often without even realising. Sometimes the assumption is simply that the code works. Sometimes, some of your assumptions will be wrong. Debuggers help you check your assumptions. They're a very useful tool for this - more so than many people who say "I prefer printf" realise. I apologise if you're not in that category, but did you know that many debuggers have a way to print a message (without stopping) whenever the program hits a certain line? Just like printf, only it doesn't have to be built in to your code ahead of time. There are times when a debugger isn't the right tool for the job, but it's always better to make an informed choice.

anamax 16y ago
> I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The big advantage of printf as a debug technique is that it doesn't work unless you understand what you're doing. If you plan to debug using printf, you must write code that is easy to understand. Great debuggers let you try to fix code that you don't understand. Worse yet, they make it reasonable to write such code. Since the person reading the code is never as smart as the person who wrote the code, encouraging simple to understand code is extremely important.
- Roboprog 16y ago
  A big disadvantage of printf() in C (or similar non-memory-managed languages) is that printing values can disturb the "noise" on the stack that you were trying to find. That is, if you had a bug due to an uninitialized local variable or buffer overrun, the printf() call could "stabilize" things and cause a bug to stop manifesting. Better to use a debugger, if you can. Not that I haven't ever sprinkled print's into the middle of a big mass of somebody else's code or framework just to get the initial lay of the land :-)
  - vicaya 16y ago

loewenskind 16y ago

I hate to say this, but you're never going to be very good (unless you change this). Someone good will have so many projects that they could never remember every detail of each of them, so every second you've spent burning this into your brain will be wasted. It's much better to use the tools as far as you can [1], use nice big descriptive names (since you never have to actually type them out this is win-win) and try to be as consistent as possible [2]. For projects I've been the driver on I never have to look at anything. I know how the project is going to be laid out, what the naming scheme will be like, etc. I can e.g. open up the Visual Studio solution file, Ctrl+n, type in the capital letters of the class I know will be of interest (e.g. WRI for WidgetRepositoryImplementation) and off I go. While you're still birthing out your first class I'll already be tightening up my tests. And there are people vastly better/faster than I am at this. [1] But be sensible about this. For me, big code generators are a no go. I use spring because it (a) doesn't sprinkle it's code anywhere I have to see and (b) regenerates the code every time so there is no sync issue between changing a source and regenerating a dependency. [2] Always refactor when you touch code, including making the code consistent with current coding standards.

edw519 16y ago
I hate to say this, but you're never going to be very good (unless you change this). I don't hate to say this, but responses like yours are the classic example of hn's biggest problem: people talking when they should be listening. I suppose your opinion could be accurate if we had a flux capacitor and you were making your prediction in 1979. But it's you versus 1,000,000 lines of code deployed, 1,000 successful projects, and 100 satisfied customers. They outrank you. FWIW, I made 2 posts yesterday. This grandparent which included intimate secrets of my success and earned nothing and this little joke: http://news.ycombinator.com/item?id=1649922 http://news.ycombinator.com/item?id=1649922 which earned 58 points. Gabriel Weinberg made wrote an interesting post which got my juices flowing and led me to share my experience (experience, not opinion). Then people like you tell me I'm wrong or worse, that what actually happened couldn't have. Any wonder why outliers with successes to share are reluctant to share them?
- loewenskind 16y ago