Debugging Quotes

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

If you're good at the debugger it means you spent a lot of time debugging. I don't want you to be good at the debugger.

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

Iko held up a hand. "You need a system debug if you're suggesting that I would abandon you know.

Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.

Debugging: what an odd word. As if "bugging" were the job of putting in bugs, and debugging the task of removing them. But no. The job of putting in bugs is called programming. A programmer writes some code and inevitably makes the mistakes that result in the malfunctions called bugs. Then, for some period of time, normally longer than the time it takes to design and write the code in the first place, the programmer tries to remove the mistakes.

What kind of programmer is so divorced from reality that she thinks she'll get complex software right the first time?

Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code.

Life is Beautiful? Beyond all the vicissitudes that are presented to us on this short path within this wild planet, we can say that life is beautiful. No one can ever deny that experiencing the whirlwind of emotions inside this body is a marvel, we grow with these life experiences, we strengthen ourselves and stimulate our feelings every day, in this race where the goal is imminent death sometimes we are winners and many other times we lose and the darkness surprises us and our heart is disconnected from this reality halfway and connects us to the server of the matrix once more, debugging and updating our database, erasing all those experiences within this caracara of flesh and blood, waiting to return to earth again. "Life is beautiful gentlemen" is cruel and has unfair behavior about people who looked like a bundle of light and left this platform for no apparent reason, but its nature is not similar to our consciousness and feelings, she has a script for each of us because it was programmed that way, the architects of the game of life they know perfectly well that you must experiment with all the feelings, all the emotions and evolve to go to the next levels. You can't take a quantum leap and get through the game on your own. inventing a heaven and a hell in order to transcend, that comes from our fears of our imagination not knowing what life has in store for us after life is a dilemma "rather said" the best kept secret of those who control us day by day. We are born, we grow up, we are indoctrinated in the classrooms and in the jobs, we pay our taxes, we reproduce, we enjoy the material goods that it offers us the system the marketing of disinformation, Then we get old, get sick and die. I don't like this story! It looks like a parody of Noam Chomsky, Let's go back to the beautiful description of beautiful life, it sounds better! Let's find meaning in all the nonsense that life offers us, 'Cause one way or another we're doomed to imagine that everything will be fine until the end of matter. It is almost always like that. Sometimes life becomes a real nightmare. A heartbreaking horror that we find impossible to overcome. As we grow up, we learn to know the dark side of life. The terrors that lurk in the shadows, the dangers lurking around every corner. We realize that reality is much harsher and ruthless than we ever imagined. And in those moments, when life becomes a real hell, we can do nothing but cling to our own existence, summon all our might and fight with all our might so as not to be dragged into the abyss. But sometimes, even fighting with all our might is not enough. Sometimes fate is cruel and takes away everything we care about, leaving us with nothing but pain and hopelessness. And in that moment, when all seems lost, we realize the terrible truth: life is a death trap, a macabre game in which we are doomed to lose. And so, as we sink deeper and deeper into the abyss, while the shadows envelop us and terror paralyzes us, we remember the words that once seemed to us so hopeful: life is beautiful. A cruel and heartless lie, that leads us directly to the tragic end that death always awaits us.

Other people - store clerks, burger flippers, software engineers, the whole vocabulary of meaningless jobs that make up Life in America - other people just rely on plain old competition. Better flip your burgers or debug your subroutines faster than your high school classmate two blocks down the strip is flipping or debugging, because we're in competition with those guys, and people notice these things. What a fucking rat race that is.

You’re not a detective, dear. You’re a mechanic.” “It’s debugging, Bob, like I do every day. Start with what’s wrong, and go backward until you find the cause.” “You’re

And I was just there, less than an hour ago, debugging subroutines in my cubicle, when a motherfucking Earth Defense Alliance shuttle suddenly shows up and lands right outside my office building! I figured I must be losing it. Now I’m not sure what to think.

Fixing bugs is not making progress. You aren't paid to debug. Debugging is waste.

To paraphrase an old joke among programmers, “Writing code accounts for 90 percent of programming. Debugging code accounts for the other 90 percent.” Your computer will do only what you tell it to do; it won’t read your mind and do what you intended it to do. Even professional programmers create bugs all the time, so don’t feel discouraged if your program has a problem.

Debugging tip: For server applications, be sure to always specify the -server JVM command line switch when invoking the JVM, even for development and testing. The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop; code that might appear to work in the development environment (client JVM) can break in the deployment environment (server JVM).

But in a pinch, he was a capable coder too. He just wasn’t especially fast. So when he was finally done coding and debugging his program and ran a successful test, it was past eleven on Tuesday night. He hadn’t slept but for a few hours on Sunday night, and the lack of sleep had cooked him.

Gordy,” I said. “I need to talk to you." "I don't have time," he said. "Mr. Orcutt and I have to debug some PCs. Don't you hate PCs? They are sickly and fragile and vulnerable to viruses. PCs are like French people living during the bubonic plague." Wow, and people thought I was a freak. "I much prefer Macs, don't you?" he asked. "They're so poetic.

[M]any men have more skill in avoiding errors than in correcting them.

There really was, as [Tom] West had often said, more to building a computer than designing and debugging a Central Processing Unit. Someone had to dream up its general outlines in the first place. Someone had to make sure the computer worked compatibly with the company's existing line of peripheral equipment. Someone had to set goals of cost and performance and see that they could be met. 278

The label “jack-of-all-trades but master of none” is normally meant to be derogatory, implying that the labelee lacks the focus to really dive into a subject and master it. But, when your online shopping application is on the fritz and you’re losing orders by the hundreds as each hour passes, it’s the jack-of-all-trades who not only knows how the application’s code works but can also do low-level UNIX debugging of your web server processes, analyze your RDBMS’s configuration for potential performance bottlenecks, and check your network’s router configuration for hard-to-find problems. And, more important, after finding the problem, the jack-of-all-trades can quickly make architecture and design decisions, implement code fixes, and deploy a new fixed system to production. In this scenario, the manufacturing scenario seems quaint at best and critically flawed at worst.

Pham Nuwen spent years learning to program/explore. Programming went back to the beginning of time. It was a little like the midden out back of his father’s castle. Where the creek had worn that away, ten meters down, there were the crumpled hulks of machines—flying machines, the peasants said—from the great days of Canberra’s original colonial era. But the castle midden was clean and fresh compared to what lay within the Reprise’s local net. There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it—the horror of it, Sura said—was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely. . .the starting instant was actually some hundred million seconds later, the 0-second of one of Humankind’s first computer operating systems. So behind all the top-level interfaces was layer under layer of support. Some of that software had been designed for wildly different situations. Every so often, the inconsistencies caused fatal accidents. Despite the romance of spaceflight, the most common accidents were simply caused by ancient, misused programs finally getting their revenge. “We should rewrite it all,” said Pham. “It’s been done,” said Sura, not looking up. She was preparing to go off-Watch, and had spent the last four days trying to root a problem out of the coldsleep automation. “It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what—even if you did, by the time you finished, you’d have your own set of inconsistencies. And you still wouldn’t be consistent with all the applications that might be needed now and then.” Sura gave up on her debugging for the moment. “The word for all this is ‘mature programming environment.’ Basically, when hardware performance has been pushed to its final limit, and programmers have had several centuries to code, you reach a point where there is far more signicant code than can be rationalized. The best you can do is understand the overall layering, and know how to search for the oddball tool that may come in handy—take the situation I have here.” She waved at the dependency chart she had been working on. “We are low on working fluid for the coffins. Like a million other things, there was none for sale on dear old Canberra. Well, the obvious thing is to move the coffins near the aft hull, and cool by direct radiation. We don’t have the proper equipment to support this—so lately, I’ve been doing my share of archeology. It seems that five hundred years ago, a similar thing happened after an in-system war at Torma. They hacked together a temperature maintenance package that is precisely what we need.” “Almost precisely.

there is always a danger that the engineers will somehow program their own subconscious biases into the software.21 Yet once we discover such mistakes, it would probably be far easier to debug the software than to rid humans of their racist and misogynist biases.

It’s like finding Jesus.” “It’s like finding out the things you believed in as a child are actually real.” “It’s like eating the mushrooms in Super Mario.” “It’s like recovering from dysentery.” “It’s like Christmas morning.” “It’s like all eight nights of Hanukkah.” “It’s like having an orgasm.” “It’s like having multiple orgasms.” “It’s like watching a great movie.” “Reading a great book.” “Playing a great game.” “It’s like finishing debugging on your own game.” “It’s the taste of youth itself.” “It’s feeling well after a long sickness.” “It’s running a marathon.” “I’ll probably never have to do a single other thing in my life, because I tasted this peach.

But the interesting cases are those where the conflict remains obstinately in place however much we ponder the problem. These are the cases where we are tempted to conclude that "intuition cannot be trusted." In these situations we need to improve our intuition, to debug it, but the pressure on us is to abandon intuition and rely on equations instead.

That’s the nature of culture. It’s not a single decision—it’s a code that manifests itself as a vast set of actions taken over time. No one person makes or takes all these actions. Cultural design is a way to program the actions of an organization, but, like computer programs, every culture has bugs. And cultures are significantly more difficult to debug than programs.

It is the one who accepts commitment who is strong. The true commitment is the artistic one. This is why artists are so often attacked. They are attacked for their morals, for their ideas – even for their work. Yet their essence – their commitment – is the secret which is unassailable. The true artist knows that creativity is its own reward. Ordinary people fear commitment, you see. Ordinary people fear creativity. They know that if they allow that seething cauldron of yellow liquid to boil over within themselves, then their whole lives will be changed. People fear change. People do not wish to be creative and artistic in any real sense. They wish to decorate, perhaps, and to make things around themselves pleasant – but this has little to do with creativity. … All spiritual paths should be creative. Creativity is involved with sacrifice. That stew of yellow liquid which boils in everyone is a sacrificial broth …

By contrast, the early majority want to buy a productivity improvement for existing operations. They are looking to minimize the discontinuity with the old ways. They want evolution, not revolution. They want technology to enhance, not overthrow, the established ways of doing business. And above all, they do not want to debug somebody else’s product. By the time they adopt it, they want it to work properly and to integrate appropriately with their existing technology base.

Take for example job applications. In the 21st century the decision wherever to hire somebody for a job while increasingly be made by algorithms. We cannot rely on the machines to set the relevant ethical standards, humans will still need to do that, but once we decide on an ethical standard in the job market, that it is wrong to discriminate against blacks or against women for example, we can rely on machines to implement and maintain these standards better than humans. A human manager may know and even agree that is unethical to discriminate against blacks and women but then when a black woman applies for a job the manager subconsciously discriminate against her and decides not to hire her. If we allow a computer to evaluate job applications and program computers to completely ignore race and gender we can be certain that the computer will indeed ignore these factors because computers do not have a subconscious. Of course it won't be easy to write code for evaluating job applications and there is always the danger that the engineers will somehow program their own subconscious biases into the software, yet once we discover such mistakes it would probably be far easier to debug the software than to get rid humans of their racist and misogynist biases.

You’re a grown-up, these days. You don’t wear a kamikaze pilot’s rising sun headband and a tee-shirt that screams DEBUG THIS! and you don’t spend your weekends competing in extreme programming slams at a windy campsite near Frankfurt, but it’s generally difficult for you to use any machine that doesn’t have at least one compiler installed: In fact, you had to stick Python on your phone before you even opened its address book because not being able to brainwash it left you feeling handicapped, like you were a passenger instead of a pilot. In another age you would have been a railway mechanic or a grease monkey crawling over the spark plugs of a DC-3. This is what you are, and the sad fact is, they can put the code monkey in a suit but they can’t take the code out of the monkey.

Five minutes later he was out of there. About thirty seconds to do the job, and three minutes thirty to cover his tracks. He could have done anything he liked in the virtual structure, more or less. He could have transferred ownership of the entire organization into his own name, but he doubted if that would have gone unnoticed. He didn’t want it anyway. It would have meant responsibility, working late nights at the office, not to mention massive and time-consuming fraud investigations and a fair amount of time in jail. He wanted something that nobody other than the computer would notice: that was the bit that took thirty seconds. The thing that took three minutes thirty was programming the computer not to notice that it had noticed anything. It had to want not to know about what Ford was up to, and then he could safely leave the computer to rationalize its own defenses against the information’s ever emerging. It was a programming technique that had been reverse-engineered from the sort of psychotic mental blocks that otherwise perfectly normal people had been observed invariably to develop when elected to high political office. The other minute was spent discovering that the computer system already had a mental block. A big one. He would never have discovered it if he hadn’t been busy engineering a mental block himself. He came across a whole slew of smooth and plausible denial procedures and diversionary subroutines exactly where he had been planning to install his own. The computer denied all knowledge of them, of course, then blankly refused to accept that there was anything even to deny knowledge of and was generally so convincing that even Ford almost found himself thinking he must have made a mistake. He was impressed. He was so impressed, in fact, that he didn’t bother to install his own mental block procedures, he just set up calls to the ones that were already there, which then called themselves when questioned, and so on. He quickly set about debugging the little bits of code he had installed himself, only to discover they weren’t there. Cursing, he searched all over for them, but could find no trace of them at all. He was just about to start installing them all over again when he realized that the reason he couldn’t find them was that they were working already. He grinned with satisfaction. He tried to discover what the computer’s other mental block was all about, but it seemed, not unnaturally, to have a mental block about it. He could no longer find any trace of it at all, in fact; it was that good. He wondered if he had been imagining it. He wondered if he had been imagining that it was something to do with something in the building, and something to do with the number thirteen. He ran a few tests. Yes, he had obviously been imagining it.

because engineers are so creative, they like to make up new bugs, not use the same old ones.

Remember, though, that debugging is as much art as it is computer science [..]

minimum software requirements to program in C is a text editor, as opposed to a word processor. A plain text Notepad Editor can be used but it does not offer any advanced capabilities such as code completion or debugging.

TFS has an option to publish all the PDB files from your builds to a shared location, which can then act as a Symbol Server for Visual Studio, enabling you to debug all previous versions of an application without having the source code around.

In debugging, errors are seen not as false but as fixable. This is a state of mind that makes it easy to learn from .6 Multiple passes also brought a new feel for the complexity of design decisions.

So he’d reach into the drawer for the tape with the FLIT debugger and feed that into the computer. The computer would then be a debugging machine, and he’d send the program back in.

Well-designed computational systems, like well-designed automobiles or nuclear reactors, are designed in a modular manner, so that the parts can be constructed, replaced, and debugged separately.

When you're debugging something and then you figure out that not only is the map wrong but the tools are broken—that's a good time.

When you start to realize: you are something that is precious to me, "Debug" me as you like; and when you have understand "addressing byte" and "memory mapping" of my heart, then i'm implore, accept me as I am ...

Programming, and especially debugging, sometimes brings out strong emotions. If you are struggling with a difficult bug, you might feel angry, despondent or embarrassed. There is evidence that people naturally respond to computers as if they were people 2 . When they work well, we think of them as teammates, and when they are obstinate or rude, we respond to them the same way we respond to rude, obstinate people. Preparing for these reactions might help you deal with them. One approach is to think of the computer as an employee with certain strengths, like speed and precision, and particular weaknesses, like lack of empathy and inability to grasp the big picture

Logging can also change the interaction of the threads and mask the problem. And non-optimised, “debug,” builds of your software can perform rather differently from the “release” builds. These are affectionately known as Heisenbugs, after the physicist Werner Heisenberg’s “observer effect” in quantum mechanics. The act of observing a system can alter its state.

Fire Fighting Although helping users with their various problems is rarely included in a system administrator’s job description, it claims a significant portion of most administrators’ workdays. System administrators are bombarded with problems ranging from “It worked yesterday and now it doesn’t! What did you change?” to “I spilled coffee on my keyboard! Should I pour water on it to wash it out?” In most cases, your response to these issues affects your perceived value as an administrator far more than does any actual technical skill you might possess. You can either howl at the injustice of it all, or you can delight in the fact that a single well-handled trouble ticket scores as many brownie points as five hours of midnight debugging. You pick!

He’d been surprised to find that in at least one way he fit in: More than half the programmers at Goldman were Russians. Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: They had been forced to learn to program computers without the luxury of endless computer time. Many years later, when he had plenty of computer time, Serge still wrote out new programs on paper before typing them into the machine. “In Russia, time on the computer was measured in minutes,” he said. “When you write a program, you are given a tiny time slot to make it work. Consequently we learned to write the code in ways that minimized the amount of debugging. And so you had to think about it a lot before you committed it to paper. The ready availability of computer time creates this mode of working where you just have an idea and type it and maybe erase it ten times. Good Russian programmers, they tend to have had that one experience at some time in the past—the experience of limited access to computer time.

From then on, whenever Aiken put his head through the door and asked if they were making numbers, if they were not, they would tell him they were debugging the computer, a term and a procedure they may have been the first to institutionalize.

A staggering $312 billion per year is spent on the wage bills for programmers debugging their software. To put that in perspective, that’s two times all Eurozone bailouts since 2008! This huge, but realistic, figure comes from research carried out by Cambridge University’s Judge Business School.[9] You have a responsibility to fix bugs faster: to save the global economy. The state of the world is in your hands.

Debugging itu adalah sebuah metode yang dilakukan oleh para programmer untuk mencari jarum di tumpukan jerami

Systems Test No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore, the time required depends on the number and subtlety of the errors encountered. Theoretically this number should be zero. Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming. For some years I have been successfully using the following rule of thumb for scheduling a software task: l /3 planning l/6 coding l/4 component test and early system test l/4 system test, all components in hand.

Well done, Mica,” Phoenix congratulated him. “You’ve just earned your baby-jiggling badge. Be sure to unlock all the infant services badges.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

scripting language is a programming language that provides you with the ability to write scripts that are evaluated (or interpreted) by a runtime environment called a script engine (or an interpreter). A script is a sequence of characters that is written using the syntax of a scripting language and used as the source for a program executed by an interpreter. The interpreter parses the scripts, produces intermediate code, which is an internal representation of the program, and executes the intermediate code. The interpreter stores the variables used in a script in data structures called symbol tables. Typically, unlike in a compiled programming language, the source code (called a script) in a scripting language is not compiled but is interpreted at runtime. However, scripts written in some scripting languages may be compiled into Java bytecode that can be run by the JVM. Java 6 added scripting support to the Java platform that lets a Java application execute scripts written in scripting languages such as Rhino JavaScript, Groovy, Jython, JRuby, Nashorn JavaScript, and so on. Two-way communication is supported. It also lets scripts access Java objects created by the host application. The Java runtime and a scripting language runtime can communicate and make use of each other’s features. Support for scripting languages in Java comes through the Java Scripting API. All classes and interfaces in the Java Scripting API are in the javax.script package. Using a scripting language in a Java application provides several advantages: Most scripting languages are dynamically typed, which makes it simpler to write programs. They provide a quicker way to develop and test small applications. Customization by end users is possible. A scripting language may provide domain-specific features that are not available in Java. Scripting languages have some disadvantages as well. For example, dynamic typing is good to write simpler code; however, it turns into a disadvantage when a type is interpreted incorrectly and you have to spend a lot of time debugging it. Scripting support in Java lets you take advantage of both worlds: it allows you to use the Java programming language for developing statically typed, scalable, and high-performance parts of the application and use a scripting language that fits the domain-specific needs for other parts. I will use the term script engine frequently in this book. A script engine is a software component that executes programs written in a particular scripting language. Typically, but not necessarily, a script engine is an implementation of an interpreter for a scripting language. Interpreters for several scripting languages have been implemented in Java. They expose programming interfaces so a Java program may interact with them.

Use manual sanity checks in data pipelines. When optimizing data processing systems, it’s easy to stay in the “binary mindset” mode, using tight pipelines, efficient binary data formats, and compressed I/O. As the data passes through the system unseen, unchecked (except for perhaps its type), it remains invisible until something outright blows up. Then debugging commences. I advocate sprinkling a few simple log messages throughout the code, showing what the data looks like at various internal points of processing, as good practice — nothing fancy, just an analogy to the Unix head command, picking and visualizing a few data points. Not only does this help during the aforementioned debugging, but seeing the data in a human-readable format leads to “aha!” moments surprisingly often, even when all seems to be going well. Strange tokenization! They promised input would always be encoded in latin1! How did a document in this language get in there? Image files leaked into a pipeline that expects and parses text files! These are often insights that go way beyond those offered by automatic type checking or a fixed unit test, hinting at issues beyond component boundaries. Real-world data is messy. Catch early even things that wouldn’t necessarily lead to exceptions or glaring errors. Err on the side of too much verbosity.

The Fusion log This is a very useful tool for debugging failed attempts by the CLR to bind to an assembly at run time. Rather than trying to step through the application in the Visual Studio debugger, it is better to turn Fusion on and read the log file that results. To enable Fusion you must edit the Windows registry, as shown in the following code.HKLM\Software\Microsoft\Fusion\ForceLog 1 HKLM\Software\Microsoft\Fusion\LogPath C:\FusionLogs

The five stages of model development. —Donald Knuth, Stanford computer scientist Knuth discovered that computer program development goes through five stages. These steps also apply to building models, and I rigorously adhere to them in my consulting work. 1. Decide what you want the model to do. 2. Decide how to build the model. 3. Build the model. 4. Debug the model. 5. Trash stages 1 through 4 and start again, now that you know what you really wanted in the first place. Once you realize that step 5 is inevitable, you become more willing to discard bad models early rather than continually to patch them up. In fact, I recommend getting to step 5 many times by building an evolving set of prototypes. This is consistent with an emerging style of system development known as Extreme Programming.2 To get a large model to work you must start with a small model that works, not a large model that doesn’t work. —Alan Manne, Stanford energy economist

The Core Debugging Process The core of the debugging process consists of four steps: Reproduce: Find a way to reliably and conveniently reproduce the problem on demand. Report erratum Prepared exclusively for castLabs GmbH this copy is (P2.0 printing, February 2010) FIRST THINGS FIRST 18 Diagnose: Construct hypotheses, and test them by performing experiments until you are confident that you have identified the underlying cause of the bug. Fix: Design and implement changes that fix the problem, avoid intro- ducing regressions, and maintain or improve the overall quality of the software. Reflect: Learn the lessons of the bug. Where did things go wrong? Are there any other examples of the same problem that will also need fixing? What can you do to ensure that the same problem doesn’t happen again?

The Deliverator does not know for sure what happens to the driver in such cases, but he has heard some rumors. Most pizza deliveries happen in the evening hours, which Uncle Enzo considers to be his private time. And how would you feel if you bad to interrupt dinner with your family in order to call some obstreperous dork in a Burbclave and grovel for a late fucking pizza? Uncle Enzo has not put in fifty years serving his family and his country so that, at the age when most are playing golf and bobbling their granddaughters, he can get out of the bathtub dripping wet and lie down and kiss the feet of some sixteenyear- old skate punk whose pepperoni was thirty-one minutes in coming. Oh, God. It makes the Deliverator breathe a little shallower just to think of the idea. But he wouldn't drive for CosaNostra Pizza any other way. You know why? Because there's something about having your life on the line. It's like being a kamikaze pilot. Your mind is clear. Other people -- store clerks, burger flippers, software engineers, the whole vocabulary of meaningless jobs that make up Life in America -- other people just rely on plain old competition. Better flip your burgers or debug your subroutines faster and better than your high school classmate two blocks down the strip is flipping or debugging, because we're in competition with those guys, and people notice these things. What a fucking rat race that is. CosaNostra Pizza doesn't have any competition. Competition goes against the Mafia ethic. You don't work harder because you're competing against some identical operation down the street. You work harder because everything is on the line. Your name, your honor, your family, your life. Those burger flippers might have a better life expectancy -- but what kind of life is it anyway, you have to ask yourself. That's why nobody, not even the Nipponese, can move pizzas faster than CosaNostra. The Deliverator is proud to wear the uniform, proud to drive the car, proud to march up the front walks of innumerable Burbclave homes, a grim vision in ninja black, a pizza on his shoulder, red LED digits blazing proud numbers into the night: 12:32 or 15:15 or the occasional 20:43.

After the debacle of the party, debugging the code running in his own brain was bliss. His body lay safely in his bed. His mind exulted inside the Nexus development environment, tracing the events that had led to the fault. Here he was in his element.

More generally, a data scientist is someone who knows how to extract meaning from and interpret data, which requires both tools and methods from statistics and machine learning, as well as being human. She spends a lot of time in the process of collecting, cleaning, and munging data, because data is never clean. This process requires persistence, statistics, and software engineering skills — skills that are also necessary for understanding biases in the data, and for debugging logging output from code. Once she gets the data into shape, a crucial part is exploratory data analysis, which combines visualization and data sense. She’ll find patterns, build models, and algorithms — some with the intention of understanding product usage and the overall health of the product, and others to serve as prototypes that ultimately get baked back into the product. She may design experiments, and she is a critical part of data-driven decision making. She’ll communicate with team members, engineers, and leadership in clear language and with data visualizations so that even if her colleagues are not immersed in the data themselves, they will understand the implications.

Doctors troubleshoot the human body—they never got a chance to debug it. (It took God one day to design, prototype, and release that product; talk about schedule pressure! I guess we can forgive priority-two bugs like bunions and male pattern baldness.)

If you’re working on long-running scientific problems where each job takes many seconds (or longer) to run, then you might want to review Gael Varoquaux’s joblib. This tool supports lightweight pipelining; it sits on top of multiprocessing and offers an easier parallel interface, result caching, and debugging features.

Linux provides programmers with everything they need: libraries, compilers, and debugging/development tools. These features are included in all standard Linux versions.

An individual block of code takes moments to write, minutes or hours to debug, and can last forever without being touched again. It’s when you or someone else visits code written yesterday or ten years ago that having code written in a clear, consistent style becomes extremely useful. Understandable code frees mental bandwidth from having to puzzle out inconsistencies, making it easier to maintain and enhance projects of all sizes.

But there was no real-time debugging. When the system crashed, basically the run light went out and that was it. You had control-panel switches where you could read and write memory. The only way to debug the system was to say, “What was the system doing when it crashed?” You don't get to run a program; you get to look at the table that kept track of what it was doing. So I got to look at memory, keeping track on pieces of graph paper what it was doing. And I got better at that. In retrospect, I got scarily better at that. So they had me have a pager. This was back in the era when pagers were sort of cool and only doctors had them. It was a big, clunky thing and all it would do is beep. No two-way. No messages. And it only worked in the Boston area, because its transmitter was on top of the Prudential Center. But if I was within 50 miles of Boston, it worked. And basically, I was a trained little robot: when my pager went beep, beep, beep, I called in to find out what the problem was. What was bizarre was that with no paper, in a parking lot, on a pay phone I could have them examining octal locations, changing octal locations and then I would say, “OK, put this address in and hit run,” and the system would come back up. I don't know how the hell I managed to do that. But I could do those kinds of things. I took care of the time-sharing system for probably a good two or three years.

On the main menu, if you hold down shift while looking at other world options you will get the option to go on Debug mode. Click it and see Minecraft in a whole new way.

Cultural, religious and emotional manipulations are powerful tactics used by the manipulators to maintain psychological control. Most need to unlearn and debug but I was born a wild beast with a mind of my own, whoever tried to tame me only got burnt instead.

Fear of failure is one of the most common traits of bad managers.

I often said I wouldn't have pursued programming as a career if I still did drugs. This is probably true, since weed was always immensely crippling for me. I would have weed hangovers for days, and while stoned, was unable to read or do much of anything besides clean and play video games. Whether or not this would have turned out to be true is academic, but it's definitely true that I wouldn't have become a programmer if I hadn't lost my mind, because the recovery process taught me my most valuable skill as a programmer: how to not think. Programming requires the acceptance that you are entering meaningless symbols into a machine that's going to spit out other meaningless symbols, and this can be hard to accept. It requires abandoning all hope for an answer for the existential "why?" in favour of shuffling boolean values ad infinitum. By no interpretation of the concept of understanding does a computer understand what you're telling it or what it's telling you. On top of that, programming as an act is more often hindered than helped by thinking. Despite zero years of training in computer science, I've found I have an edge in debugging because I never look or ask for an explanation. Ninety percent of the computer bugs in a program are tiny, one-line errors, and you just have to find that error. Holding the entire logical structure of a million lines of code in your mind in futile. The task is to find the references and connections and track them back until you hit the problem. If I get an error message, I copy it into Google, because someone somewhere has encountered and solved the problem, probably by tracking down the people who originally wrote the program. In seven years of programming, I've solved exactly two undocumented bugs via pure deductive reasoning.

CHECKING CONNECTIONS AS A TEAM Finding circuit problems is called debugging, and it’s easier to do with some help. When you get stuck, ask someone else to look at the circuit diagram and say the connections out loud one by one while you check the real connections. For example, if your friend is reading the schematic and you’re looking at the breadboard, you might have a conversation like this: Friend: “The positive side of the battery is connected to one side of R1.” You: “Got it!” Friend: “The positive side of the battery is also connected to pins 4 and 8 of the IC.” You: “Got it!” Friend: “The other side of R1 is connected to pin 7 of the chip and to one side of the resistor R2.” You: “Oh, wait! I don’t have the connection to pin 7!” And just like that, you’ll discover the problem.

Tools A wire cutter (Jameco #35482, Bitsbox #TL008) to cut small pieces of wire. A multimeter (Jameco #2206061, Bitsbox #TL057, Rapid Electronics #55-6662) to debug your circuit if it’s not working correctly.

This is, in fact, exactly how electrical engineers go about understanding and debugging circuits such as computer boards (to reverse engineer a competitor’s product, for example), using logic analyzers that visualize computer signals. Neuroscience has not yet had access to sensor technology that would achieve this type of analysis, but that situation is about to change. Our tools for peering into our brains are improving at an exponential pace. The resolution of noninvasive brain-scanning devices is doubling about every twelve months (per unit volume).31 We see comparable improvements in the speed of brain scanning image reconstruction:

When put on the spot, most people won’t say much about this, but there are usually a few things that everyone would like to do in the next five years: get promoted, learn something new, launch something important, and work with smart people.

At Google, one of our favorite mottoes is “Failure is an option.” It’s widely recognized that if you’re not failing now and then, you’re not being innovative enough or taking enough risks.

Traditional managers worry about how to get things done, while leaders worry about what things get done…(and trust their team to figure out how to do it).

Fitz treated Jerry like an adult, Jerry always got his work done, and Fitz never had to worry about Jerry being at his desk, because Jerry didn’t need a babysitter.

First, note that the example configures the same message level at the console and for terminal monitoring (level 7, or debug), and the same level for both buffered and logging to the syslog server (level 4, or warning). The levels may be set using the numeric severity level or the name as shown earlier in Figure 33-3. The show logging command confirms those same configuration settings and also lists the log messages per the logging buffered configuration.

If (as is generally accepted) over 75% of a typical software project’s life-cycle costs will be in maintenance and debugging and extensions, then the common price policy of charging a high fixed purchase price and relatively low or zero support fees is bound to lead to results that serve all parties poorly. Consumers lose because, even though software is a service industry, the incentives in the factory model all work against a vendor’s offering competent service. If the vendor’s money comes from selling bits, most effort will go into making bits and shoving them out the door; the help desk, not a profit center, will become a dumping ground for the least effective employees and get only enough resources to avoid actively alienating a critical number of customers.

I do not believe we will find the magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified. Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it. More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

There’s a tradition among programmers to see mistakes not as a sign of failure but as “bugs” that can be fixed. An important part of becoming a programmer is to learn strategies for debugging—that is, how to identify and isolate a problem, then make changes to get around the problem.

Was there a moment you realized you could control how you interpreted things? I think one problem people have is not recognizing they can control how they interpret and respond to a situation. I think everyone knows it’s possible. There’s a great Osho lecture, titled “The Attraction for Drugs Is Spiritual.” He talks about why do people do drugs (everything from alcohol to psychedelics to cannabis). They’re doing it to control their mental state. They’re doing it to control how they react. Some people drink because it helps them not care as much, or they’re potheads because they can zone out, or they do psychedelics to feel very present or connected to nature. The attraction of drugs is spiritual. All of society does this to some extent. People chasing thrills in action sports or flow states or orgasms—any of these states people strive for are people trying to get out of their own heads. They’re trying to get away from the voice in their heads—the overdeveloped sense of self. At the very least, I do not want my sense of self to continue to develop and strengthen as I get older. I want it to be weaker and more muted so I can be more in present everyday reality, accept nature and the world for what it is, and appreciate it very much as a child would. [4] The first thing to realize is you can observe your mental state. Meditation doesn’t mean you’re suddenly going to gain the superpower to control your internal state. The advantage of meditation is recognizing just how out of control your mind is. It is like a monkey flinging feces, running around the room, making trouble, shouting, and breaking things. It’s completely uncontrollable. It’s an out-of-control madperson. You have to see this mad creature in operation before you feel a certain distaste toward it and start separating yourself from it. In that separation is liberation. You realize, “Oh, I don’t want to be that person. Why am I so out of control?” Awareness alone calms you down. [4] Insight meditation lets you run your brain in debug mode until you realize you’re just a subroutine in a larger program. I try to keep an eye on my internal monologue. It doesn’t always work. In the computer programming sense, I try to run my brain in “debugging mode” as much as possible. When I’m talking to someone, or when I’m engaged in a group activity, it’s almost impossible because your brain has too many things to handle. If I’m by myself, like just this morning, I’m brushing my teeth and I start thinking forward to a podcast. I started going through this little fantasy where I imagined Shane asking me a bunch of questions and I was fantasy- answering them. Then, I caught myself. I put my brain in debug mode and just watched every little instruction go by. I said, “Why am I fantasy-future planning? Why can’t I just stand here and brush my teeth?” It’s the awareness my brain was running off in the future and planning some fantasy scenario out of ego. I was like, “Well, do I really care if I embarrass myself? Who cares? I’m going to die anyway. This is all going to go to zero, and I won’t remember anything, so this is pointless.” Then, I shut down, and I went back to brushing my teeth. I was noticing how good the toothbrush was and how good it felt. Then the next moment, I’m off to thinking something else. I have to look at my brain again and say, “Do I really need to solve this problem right now?” Ninety-five percent of what my brain runs off and tries to do, I don’t need to tackle in that exact moment. If the brain is like a muscle, I’ll be better off resting it, being at peace. When a particular problem arises, I’ll immerse myself in it. Right now as we’re talking, I’d rather dedicate myself to being completely lost in the conversation and to being 100 percent focused on this as opposed to thinking about “Oh, when I brushed my teeth, did I do it the right way?

Another completely different way that the contacts of a relay could fail was if dirt or an insect got trapped in the spacing between contacts. If a fly or a moth, for example, happened to be sitting on the make contact when the coil was energized, then it could be squashed and, after its smashed little body dried, the contacts would be covered with a very disgusting but quite effective insulator. To clean up such a disabled relay was called debugging, a term that has survived in the vocabulary of modern computer users trying to fix their faulty programs. This is not a joke—I heard it as a quite serious story in a lecture at the Naval Postgraduate School in 1982 from a legend in computer science, Rear Admiral Grace Hopper (1906–1992), a Yale PhD mathematician who worked during the Second World War with Harvard’s five ton, 800 cubic foot Mark I relay computer, which when operating was described as sounding like a “roomful of ladies knitting.” To debug such a machine must have been an “interesting” job for someone;

Thompson, who designed and implemented the first UNIX system, has stated that he much prefers printf debugging.24 But as Baird put it, “If you are a genius like Ken Thompson, you are going to write good code.”25 The rest of us need to move beyond printf debugging to get our code working, as I rapidly discovered once I started working on the internals of Windows NT at Microsoft (the fundamental skill is learning to use a specialized piece of software called a debugger, which can examine the memory of another program).

Another detrimental effect of undervaluing people skills was that in some cases, programmers were rewarded more for raw code production than for meeting the user's needs. Marge Devaney, a programmer at Los Alamos National Laboratory in the 1950's, recalled sex differences in how programmers judged their performance. Asked if she had ever experienced gender bias on the job, sh replied that discrimination was difficult to prove, adding, "With things like computing, it's very hard to judge who's doing the best. Is it better to produce a program quickly and have it full of bugs that the users keep hitting, and so it doesn't work? Or is it better to produce it more slowly and have it so it works?...I do know some of the men believed in the first way: 'Throw it together and let the user debug it!'" This critique is echoed by women today who find their male peers rewarded for averting disasters through heroic last-minute efforts, while women's efforts at preventing such problems through careful work and communication with users go unrecognized. As a female software engineer complained in 2007, "Why don't we just build the system right in the first place? Women are much better at preventive medicine. A Superman mentality is not necessarily productive; it's just an easy fit for the men in the sector.

I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows and Microsoft Visual C++. In no time at all, it seemed, they had generated many screens full of windows and toolbars and dialogues, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and and unexplainable outcomes, they stood agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to not knowing. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall 'productivity' of the system, the fact that it came into being at all, was not the handiwork of tools that sought to make programming seem easy, but the work of engineers who had no fear of 'hard.

if you write code constantly trying to see it through the eyes of an engineer two years down the line who has to make a change to it, you will find that the code completes on time and on budget. It will debug faster and be more reliable in production.

One can visualize a debugging assistant that offers very generalized suggestions at first, but as more and more system structure is embodied in the rule base, becomes more and more particular in the hypotheses it generates and the tests it recommends.

The following interpretation methods are all example-based: Counterfactual explanations tell us how an instance has to change to significantly change its prediction. By creating counterfactual instances, we learn about how the model makes its predictions and can explain individual predictions. Adversarial examples are counterfactuals used to fool machine learning models. The emphasis is on flipping the prediction and not explaining it. Prototypes are a selection of representative instances from the data and criticisms are instances that are not well represented by those prototypes. 2 Influential instances are the training data points that were the most influential for the parameters of a prediction model or the predictions themselves. Identifying and analysing influential instances helps to find problems with the data, debug the model and understand the model’s behavior better.

... he de-bugged and de-moused the office ...

Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code

I am many things: not a single one of them makes me qualified to troubleshoot or debug or antivirus an AI.

History is how you debug our broken society. Many billions of dollars are spent on history in the engineering world. We don’t think about it that way, though. We call it doing a post-mortem, looking over the log files, maybe running a so-called time-travel debugger to get a reproducible bug. Once we find it, we might want to execute an undo, do a git revert, restore from backup, or return to a previously known-good configuration. Think about what we’re saying: on a micro-scale, knowing the detailed past of the system allows us to figure out what had gone wrong. And being able to partially rewind the past to progress along a different branch (via a git revert) empowers us to fix that wrongness. This doesn’t mean throwing away everything and returning to the caveman era of a blank git repository, as per either the caricatured traditionalist who wants to “turn back the clock” or the anarcho-primitivist who wants to end industrialized civilization. But it does mean rewinding a bit to then move forward along a different path16, because progress has both magnitude and direction.

On the main menu, if you hold down shift while looking at other world options you will get the option to go on Debug mode. Click it and see Minecraft in a whole new way.

MIND GAME Name That Loop For the rest of the day, try to “catch” your negative mind loops as they happen. Watch for signs of mental “pain” or friction, which are a good indicator of thought processes that need debugging. Debug each negative thought loop down to its root problem using one of the three techniques: • The Five Whys: Ask “Why?” five times. • Worst-Case Scenario: What’s the worst thing that could happen? • Third-Person Perspective: What would you say if you were hearing this from someone else? At the end of the day, write down each of the “root problems” you uncovered on your practice sheet, preferably using the METAL method. In Part 1 of Mind Hacking, we’ve seen how the mind is a naturally noisy place and how we can cultivate focus and awareness of the mind’s programming through

regular concentration practice. Using the laser-like clarity that we develop through this practice, we can examine areas of our thinking where we have pain or difficulty, debugging our negative loops with skill and precision. This sets the stage for active reprogramming of the mind, which we’ll cover next, in Part 2.

On a scale of one to ten, how strong is the emotion attached to the memories we’ve been working on?” Curtis Rouanzoin asks one day. The procedure I’ve been going through with him is called EMDR, or eye movement desensitization and reprocessing, which looks at the way trauma is stored in the brain and attempts to properly process it. “If it used to be a ten, now it’s an eight,” I tell him. Lindsay Joy Greene is trained in a therapy called SE, or somatic experiencing, and she’s been locating trauma trapped not in my brain, but in my body, and releasing the stored energy. One day she asks, “On a scale of one to ten, how much anger do you feel when you recall the memories we’ve been discussing?” “If it used to be an eight, now it’s a seven,” I tell her. Olga Stevko practices her own variant of NLP, or neuro-linguistic programming. Where the experientials with Lorraine were about debugging my operating system, her process is about rewriting the original code. For example, she tells me that inside my mother’s words, “Never grow up to make anyone as miserable as your father makes me,” was a hidden command: Never grow up. As she helps me grow up, it brings my trauma down to a six. Greg Cason specializes in cognitive behavioral therapy, which takes it to a five. And I don’t know what to call Barbara McNally’s method and her bottomless quiver of techniques, but they work, they’re original, and they bring the emotion associated with those memories to a four. And I do so much more: I beat pillows with baseball bats. I tap on energy meridians. I make shadow maps of my dark side. I try psychodrama. Not all of it works, but none of it hurts.

They spent a week or two testing the circuit together for a few hours each day. Debugging a complex electronic device being almost as powerful a bonding experience as, say, serving on a submarine in wartime, Metcalfe learned a lot about his partner: That he was a digital whiz, accomplished at wielding the oscilloscope, and, most interesting, underemployed in his POLOS work.

Intel’s mental model of its product,” according to Ceruzzi, “was this: an industrial customer bought an 8080 and wrote specialized software for it, which was then burned into a read-only memory to give a system with the desired functions. The resulting inexpensive product (no longer programmable) was then put on the market as an embedded controller in an industrial system.”13 (Ceruzzi adds that Intel did build several microcomputers during this period; however, it marketed the ten-thousand-dollar Intellec “Development Systems” not as general-purpose computers but as tools to help customers write and debug software for embedded processors.)

forward along a different path16, because progress has both magnitude and direction. All these concepts apply to debugging situations at larger scale than companies — like societies, or countries.

Attesting to the nested quality of culture, NASA’s entire Shuttle Program exhibited the “unruly technology” that characterizes the engineering craft when complex technical systems are involved: interpretive flexibility, absence of appropriate guidelines, unexpected glitches as commonplace, “debugging through use,” extensive systemwide problems with technical components, practical rules based on experience that supplemented and took precedence in technical decision making over formal, universal rules, and cost/safety compromises as taken-for-granted.

I can manually debug a few hundred thousand lines. It won't be fun, but I ... who am I kidding, it will be fun.

That’s a horrible voice to live with, Kaiyo. I understand that. It’s hard not to listen to it. But it is another distortion of depression. At a fundamental level, we have to remember that, yes, depression is a consistent low mood, but its impact is mainly a distortion of perspective. It is a legitimate mental health difficulty. This means that your brain, mind, and body are not functioning in a healthy way. “What this means is that any information processed by your brain right now is going to be corrupted. We need to debug the system slowly. We can’t trust what it puts out. So, when it tells you the antivirus isn’t working, it means nothing.” Kaiyo furrowed his brows thoughtfully, chewing at his lip. Claudia continued. “This makes it incredibly hard to track progress if you only use what the malware—excuse me if I’m taking this metaphor too far—is corrupting. And what it is corrupting right now is ‘emotional perspectives on world and self’. You feel like nothing has changed. You feel like you’re useless. You feel like this is going to go on forever.

Bugs are sometimes the mess we create, Raphael created a bug when he forgot to tidy up his toys.