On Fri, 19 Dec 2014 15:38:27 +0000 Daniel Davidson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote: > > This is true. The first week for a new developer where I work > > is developing a better boot loader. The debugger is not allowed > > during this induction week and as a result our devs learn how > > to write better code first time through careful planning and > > understanding of what's going on at the machine level. > > > As you beat your chest over your boot loader - consider both this > example and in general Walter's lack of need for a debugger. > Could this lack of need be attributable to understanding of the > entire code base being used? I imagine you don't have many > outside dependencies for your boot loader. I imagine most of what > Walter works on involves an entire stack that he has either > written from ground up or when pulling outside dependencies in > has much less surface area to deal with that is new to him. > Contrast that with someone wanting to tie into a framework > (vibed) or use a sophisticated library (websockets). Yes, you can > stick with the "real men don't use debuggers" line, but that is > much easier to stomach when your outside dependencies are small > in scope. Isn't one of the best ways to learn a new codebase to > step through it in the debugger? > > Maybe your devs learn how to write better code the first time > through. But what happens when they are thrown new requirements > on dependencies that are challenging to deal with? one of the worst things one can do to understand some big codebase is start it under debugger. if that codebase is so shitty that you can't see the modules and interfaces without tracing them in the debugger... well, in this case debugger will not help, the codebase is crap. if that codebase is well-documented and well-decoupled, you can get a picture in your head by learning what each part of the system do and then descend into various parts, learning APIs. what "stepping through it in the debugger" does is effectively simulates the work. and gives you a simulated understanding. i was thrown into huge codebases with alot of dependencies for past decades and "stepping through it in the debugger" was always just a waste of time. it's not the best way to understand how to use some engine by watching how it's gears turning. it may be fun, but not very productive. first you grok what that engine was designed for, and only then you may want to see the gears. but it's often not necessary.
signature.asc
Description: PGP signature