Lost a new commercial user this week :(

[ketmar via Digitalmars-d]

On Fri, 19 Dec 2014 15:38:27 +0000
Daniel Davidson via Digitalmars-d <digitalmars-d at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141219/48fc1592/attachment.sig>