The Daily WTF

Oliver works for a very large company. Just recently, someone decided that it was time to try out those “newfangled REST services.”Since this was “new”, at least within the confines of the organization, that meant there were a lot more eyes on the project and a more thorough than average code review process. That’s how Oliver found this.

It’s hard to do any non-trivial programming in C without having to use a struct. Structs are great! A single variable holds access to multiple pieces of data, and all the nasty details of how they’re laid out in memory are handled by the compiler.In more modern OO languages, we take that kind of thing for granted. We’re so abstracted from the details of how memory is laid out it’s easy to forget how tricky and difficult actually managing that kind of memory layout is.Of course, if you’re Jean-Yves R’s co-worker, letting structs manage your memory layout is beginner mode stuff.Jean-Yves was trying to understand why a bunch of structs were taking up huge amounts of memory, relative to how much they should take. Every bit of memory mattered, as this was an embedded application. Already, these structs weren’t actually stored in RAM, but in the flash memory on the device. They served as a database- when a request came in over Modbus or CAN or I2C, the ID on the request would be used to look up the struct containing metadata for handling that request. It was complex software, so there were a lot of these structs taking up flash memory.It didn’t take long to see that the structs were defined with padding to ensure every field fell on a multiple of 32-bits, which meant there were huge gaps in every struct. Why? Well, this is an example of how they’d search the database:

Alice's team was thirty developers, taking up most of the floor of a nondescript office building in yet another office park. Their team was a contractor-to-a-contractor for a branch of the US military, which meant a variety of things. First, bringing a thumb drive into the office was a firing offense. Second, they were used to a certain level of bureaucracy. You couldn't change a line of code unless you had four different documents confirming the change was necessary and was authorized, and actually deploying a change was a milestone event with code freezes and expected extra hours.Despite all this, the thirty person team had built a great working relationship. They had made their process as efficient as they could, and their PM, Doug, understood the work well enough to keep things streamlined. In fact, Doug did such a good job that Doug got promoted. Enter Millie, his replacement.Millie had done a stint in the Air Force and then went back to school for her MBA. She had bounced around a few different companies, and had managed to turn every job change into a small promotion. This was Millie's first time overseeing a pool of software developers, but she had an MBA. Management was management, and there was no reason she had to understand what developers did, so long as she understood the key performance indicators (KPI).Like the quantity of defects. That was a great KPI, because it was measurable, had a clear negative impact, and it could be mitigated. Mitigated with a process.After a few weeks of getting her bearings, Millie called a meeting. "Alright, everyone, I've been observing a little bit of how we work, and I think there may be some communication and organization issues, so I wanted to address that. I've looked at our current workflow, and I've made a few small changes that I wanted to review."On one side of the white board, she drew a bubble labeled "In Production". "This is where we want our code to be, right? Working, quality-controlled code, in production, with no defects." On the opposite side of the board, she added a bubble for "PCCB Ticket." "And any code change starts with one of these- the Product Change Control Board reviews an open ticket. They'll then turn that ticket into a Functional Requirement Document." Millie added another bubble for that.Alice had some questions already, but not quite about the inputs or outputs."Great, okay, so… we need to iterate on the FRD, and once the PCCB signs off we'll convert that to a System Requirement Document. Either a PM or a SME will decompose the SRD into one or more Work Packages."Millie continued scribbling furiously as she explained exactly what a work package was, as this wasn't currently a term in use at their organization. Her explanation wasn't terribly clear, as Millie explained it as the set of steps required to implement a single feature, but a Functional Requirement was a feature, so how was the Work Package (WP) any different than the FRD?"Please, hold your questions until the end, we have a lot to get through."Finally, once the Work Package was analyzed, you could create a "Ticket Lifecycle Document", a new document which would hold all information about all of the efforts put towards the PCCB ticket. Which meante the TLD contained all the WPs, which raised questions about the point of adding work packages. From the TLD to a new PCCB ticket- a "Ready" ticket, then finally those requirements could go onto a Release backlog and a release management plan could be created."Finally," Milile explained, "we're ready to write code." In the center of the board, she added a single bubble: "Code".And on and on the meeting went. The diagram grew. Lines kept getting added. Bubbles got inserted between existing bubbles. Arrows pointed to labels, or to bubbles, or maybe to arrows? By the end of Millie's meeting, it looked something like this."There, that lays out the correct pattern for getting our software to production, with a feedback loop that prevents defects. Any questions?"There weren't any questions at the meeting, no. But boy, were there questions. Loads of questions. Questions like, "What font should I use on my resume?" and "is it time to stop listing my VBA experience on my resume?"Over the next few months, under Millie's leadership, 17 developers from the 30 person team left the company, Alice among them. Every once in awhile, Alice checks the job listings for that company, to see if those developer positions have been filled. They're still hiring for software developers. Unfortunately, Alice hasn't seen any openings for a PM, so Millie is probably still there. [Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!

Animations have become such an omnipresent part of our UI designs anymore that we tend to only notice them when they're bad.Ben is working on an iOS application which appeared to have a "bad" animation. In this case, it's bad because it's slow. How slow? Well, they have a table view with ten items in it, and the items should quickly tween to their new state- position, text, colors all could change in this process. And it was taking four seconds.Four seconds to update ten items is a lot. Now, their application does have a lot of animations, and the first suspicion was that there was some ugly interaction between animations that was causing it to take a long time. But upon digging in, Ben discovered it wasn't the animations at all.

Jake works in Python. Python is a very flexible language, and Jake has some co-workers who like to exploit it as much as possible.Specifically, they’re notorious for taking advantage of how any symbol can be redefined, as needed. Is int a built-in function? Yes. But what if you want to have a variable called int? No problem! Just go ahead and do it. Python won’t mind if you do int = int(5).Sure, any linter will complain about the possible confusion, but do you really think this developer checks the linter output?Now, this particular block of code happens to be a test, which Jake provided because it’s one of the more head-scratching versions of this pattern, but it’s representative of this approach.

Christopher started a new job as a “full-stack” developer. Unfortunately, most of the developers are still on the “why do you need anything other than jQuery” school of front-end development, despite efforts to transition their UIs to Vue.This meant that Christopher didn’t do much backend, and ended up being the mid-level front-end dev, in practice if not in job title.One of the Vue components was a “Wizard” style component, which was designed to be highly configurable. You supply a JSON description of the Wizard process, and it would generate the UI to navigate you screen-by-screen. Since Christopher was new at the organization, he wanted to understand how the Wizard worked, so he started poking at the code.He got as far as the stepBack function before deciding he needed to rewrite it from scratch. Christopher assumed that stepBack could be as simple as popping the last element off the array of previous steps, and then update what’s currently displayed. That, however, isn’t what it did at all.

The interview was going well—as well as one could possibly expect. Alarik, the candidate, had a no-nonsense attitude, a high degree of precision to his speech, and a heavy German accent. He was applying for a job with Erik's company as a C# developer working on an inherited legacy codebase, and he'd almost earned himself the job. There was just one routine question left in the interview:"So, why did you leave your previous job?""Ach," he said, his face twisting with disgust. "It was my superiors. They did not wish to improve the codebase."This was the first red flag. Erik's company had a terrible codebase, littered with technical debt. He was all for improving it, but it had to be done carefully to avoid breaking their bread-and-butter application while they struggled to keep the company solvent. He'd been leading careful efforts to tackle the worst bits while still delivering new functionality. "Can you tell me more about this?" he asked, frowning just a touch."I was all set to develop unit tests for every unit," Alarik replied. "It would have saved effort in the long run, but the bosses did not see return on investment. It is always about money with them, never craftsmanship."Erik chuckled weakly. "Well, we're a small company, run by developers and former developers. We don't have MBAs here running the show, so we definitely appreciate craftsmanship. But I'll warn you off the bat, the product you'd be working on has no unit tests. We're working towards that, but we're not there yet."Another disgusted noise. "Tch. If you hire me, I will need time to improve this. Perhaps not the entire codebase, but at least the core functionality.""I appreciate your candor." And Erik did—it meant this leading candidate was pushed back to second place. After all, he might be a great developer, but dictating demands in the interview wasn't exactly a strong recommendation.They proceeded with the interview process, but their first choice fell through, so they ended up inviting Alarik back for a second interview. After all, not everyone who appreciates craftsmanship and prefers unit tests is necessarily inflexible."Do you have code samples we could look at?" Erik asked, hoping to convince himself the value of a good developer was worth some butting heads about priorities."Yes, yes, of course. Here, let me show you. I have brought you a unit test I wrote.""Great," said Erik, feigning some degree of enthusiasm. This again ..."This is a unit test for the Absolute Value function in the Math library," Alarik continued, pulling up the code with a few deft keystrokes.Please tell me it's just a sample, Erik thought. Does he think I don't know what a unit test is? Or does he really not trust the built-in absolute value function? What kind of person has a unit test for Math.Abs() pre-written on their computer? Will he tell me some war story about some platform where Math.Abs() failed to work on some edge case?!Erik mustered an insincere smile, sitting through Alarik's walkthrough. It was a well-written test, for certain, but he just couldn't shake the questions about why it was being shown in the first place. "This is a little simple. Do you have an example of a test you wrote for some actual business functionality?"."Ah, yes. Here is my test for `String.split`."Changing the subject, Erik asked about another sticking point: "You mentioned in our first interview that you wanted to break up class files that are too large.""Yes. No file should be over 400 lines."Erik thought back to one code file in their codebase that was over 11,000 lines, wincing a little. We're overdue to break this up, but I'd hate for this guy to come in and rearrange every one of our hundreds of files. "How strictly would you apply that rule to a legacy codebase?" he asked."It is good to be flexible," Alarik replied. "It's not a strict rule."Feeling relieved, Erik drilled further: "What if you found a class file that's a thousand lines long?""That I would break up, of course.""How about 500?""I would break it up.""What if there's no natural way to break it up?""There is always a natural way to break up complexity.""Well, how do you find that? Let's say you found a 11,000 line file. What steps would you take to break it up?""I would move blocks of code into other files."That did it. Erik thanked Alarik for his time, deciding to wait 24 hours and then give him the bad news. In rejecting him, Erik still felt guilty—he felt like the team was sloppy for not using unit tests and having a huge range of source code file sizes.No doubt we'll falter and fail, he thought sarcastically. It would serve us right for not employing the only person who could have taught us proper software development processes.And yet, three years on, in submitting this story, Erik wanted us to know that the company was doing better than ever, still with 0 unit tests in a codebase that's loaded with WTFs, and still feeling guilty enough about this interview to write in. [Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

Many decades ago—before laser printers, graphical operating systems, and device-independent imaging models—Gus worked in the IT department of a local college. As a personal project during slow moments at work, he took it upon himself to figure out how to print Greek text. About a week later, he'd hacked together a solution that resulted in a printout of classical Greek writing.Gus' boss, although a manager in IT, happened to be a classical scholar. He'd never seen Greek text printed from a normal printer before, and he was ecstatic. He told his friends, who told their friends, and so on. The world of classical Greek scholars soon buzzed with the excitement of a rowdy symposium.One day, Gus received an email from an unknown professor at an Arizona college. He'd heard from Gus' boss about the wonderful, mythical software. Could he have it, too?Gus wanted to oblige, but there was a problem. His solution was specific to the previous version of the VAX/VMS operating system and Pascal compiler, to one particular VERSAMOD-200 printer that could be put into a dot-matrix mode, and to a special print driver that'd been carefully binary-patched so that it wouldn't mess up dot-matrix images. Gus doubted the professor had the technical knowledge to appreciate this explanation, so he replied in polite, less technical terms: sorry, but his software just wouldn't work anywhere else. A week later, his boss showed up at his desk, mentioning the friend in Arizona and nicely asking whether Gus couldn't find some way to send him the software after all. Gus' attempts to explain the impossibility of getting the code running on any other computer in the world fell on deaf ears."You're a genius, Gus! I'm sure you'll think of something. Thanks!" Pleased with his own optimism, the boss left.Gus thought about what he could possibly do to comply, or even semi-comply, with the request. Finally, he hit upon an idea. Into his computer's shell prompt, he typed:

Chaz had a pretty sweet gig as a software architect at a tech-based toy company. Being able to play around with computers AND toys all day wasn't terrible, but the pot got even sweeter when his company licensed a cool robotic product from a certain Danish toy company that specializes in small, colorful bricks. Chaz was happy to become the lead platform architect for this exciting new initiative.The intended outcome was to make the robots consumer-programmable via an interface with a smartphone app. Chaz had grand ideas for how he wanted to build the app and backend from the ground up with stability, performance, and security as the main pillars. That dream was dashed by Stellan, the CFO-turned-CTO, who insisted they develop against the same in-house platform they'd been using for over a decade. Chaz argued with Stellan until he was blue in the face, but Stellan scoffed at him, "I don't care if smartphones didn't even exist when our platform was designed. The cost of building a whole new one would be astronomical. We want a quick turnaround and high profit margin on these robots!" Stellan clearly showed he was far more qualified to be a CFO than CTO.Chaz and the development team slogged for six months to make the robot toys and the smartphone app work with their antiquated platform. By late July, they were prepared for their targeted launch at the end of August. Chaz was tasked with leading a demo for Stellan and other C-level executives. "Stellan, how to you like your coffee?" Chaz queried, his custom robot proudly displayed on the conference room table. Stellan informed him he took three sugars, two creamers. Chaz punched in a couple things on his smartphone then set it down. The executives stared in amazement as Chaz's robot grabbed a coffee cup, dispensed coffee from the carafe, then added what Stellan requested and gave it a good stir before delivering it to him."That's amazing!" Stellan shouted, looking down at the robot like it just performed a biblical miracle. "What else can it do??""Well, this is all I programmed it to do for our demo. But for anyone with an imagination and a smartphone, there are boundless possibilities," Chaz assured them."Brilliant!" Stellan added. "This gives me an idea!" The grin Chaz had from the successful demo suddenly faded. "I think we would be foolish to not collect data on how consumers are using these robots. We could use it to help improve and know what people look for in our product!""It's a good thought. Anonymous usage data can be beneficial in future product upgrades," Chaz agreed while hiding his skepticism."Future upgrades?" Stellan questioned, looking above the rim of his glasses at Chaz. "The future is now, Chaz my man. We need this data tracking in time for launch next month!" Unwilling to go on a rant in front of all the big-shots, Chaz saved his reservations for a more appropriate time. It didn't matter. Stellan's idea had to be put in. Fast.Chaz and the devs worked long hours over the next month to bang out the activity tracking and log upload functionality. The absurd timeline forced Chaz to approve a lot of corner cutting. The app was set to collect activity data from the robot every 23 seconds. Any higher frequency would cause the app to crash. From there, it would transmit the data back to a shoddy web service that Chaz also had to quickly produce. This gave Stellan the usage data he greatly desired.He gave another demo the week before launch but cautioned everyone that it hadn't been tested nearly as thoroughly as it should be. But it was too late to turn back. The programmable robots created a lot of buzz and there were nearly a million pre-orders by launch day. Chaz and his warnings didn't matter one bit.Launch day came with long lines of fans in cities across the globe eagerly waiting to get their hands on the product Chaz didn't trust. The thrill of all those sales eventually turned into panic as the modest support call center was flooded with calls about "robots gone mad."Chaz got a report from the support manager with a common problem consumers were having. Their robots would be working fine, then every so often, about 23 seconds or so, they would freeze up. Eventually the robots would become unresponsive. Some time later, they would "go crazy" and start doing all sorts of actions without input.Chaz checked the web and database servers. Both were flooded with activity and couldn't keep up. Chaz didn't need to check any logs to know what was happening - the activity tracking functionality couldn't handle to load that the logs a million launch day robots were generating. As for the phycho robots, that was caused by the inputs of users frantically tapping the app when their robots froze up. They would queue up on the smartphone and when the app got back to a point it could send commands to the robots, they all came in at once - giving the appearance of "robots gone mad".In a post-mortem meeting the following week, Chaz took the wrath of Stellan and the other executives. Obviously, it was his fault for arcitecting a bad product. Chaz pleaded with them to let him fix it the right way to make sure it didn't happen again. "Oh, this won't happen again," Stellan rebuffed. "We only had one launch day, there will never be that much activity again. What we have should be able to handle a slower trickle of robots coming online. As for you, Chaz, start packing up your desk. You're done here."Chaz was disappointed to be leaving what had been a cool job. But getting his bonus tied to the number of robot sales as a severance made it more palatable. On the way out, he actually wished he could be around to see Stellan's face after another million or so robots came online Christmas Day. Any angry letters to Santa about faulty robots should be redirected to Stellan by the North Pole post office. [Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!

Jon worked for a small company that specialized in automation of inspection systems: basically the industrial version of home automation, where you glue together a series of disparate automatable parts to create a specialized workflow. Jon was the only software person at his 15-man company. The client was in Russia, and the company was in the USA, so communication went through email and primarily via a client representative, Sam. Sam would gather the requirements verbatim from the client and hand them to Jon; Jon would augment the software to meet their automation needs, and send a new version over to Sam to deliver. It worked, after a fashion. The system was designed to control a robot that mostly opened boxes, picked things up, ran a series of quality checks on the things, and put them back.With home automation, most of the time the equipment isn't dangerous: light bulbs, speakers, maybe a garage door. Much of Jon's job, by contrast, was figuring out how to safely encode sequences of steps so that the robots—and the people standing nearby—didn't break. Requirements like "Don't move this piece while the robot is in motion" or "Don't put things into a box if the box is closed" required a good deal of time and effort to encode. Requirements like "Don't start the software if the robot isn't attached" seemed designed to hinder testing as much as possible.The software shipped, and the inevitable change requests started rolling in. There had been two configurations of crate and robot that the company had initially asked for, but in practice, they used at least six. One of the changes they asked for was a checkbox to tell the robot whether it needed to open the box or whether the box simply didn't have a lid at all. The initial requirements had been concerned about the human error of accidentally forgetting to toggle the checkbox and causing the robot to smash through a closed lid, but in practice, the workers weren't going to add lids to boxes that didn't arrive with them, so it was needed after all. That particular update shipped, and Jon got to work on the next update.It wasn't long before Sam was at his desk, frowning a little. "So, I have this bug report from the client, but ... I'm not sure how to enter it into Jira.""Huh? You just type it in. What's the issue?" replied Jon."Well, here, they sent over a video. Come look at this on my screen.""I'm a little busy, what's the problem?""The software just ... goes crazy. Somehow."This Jon had to see. He walked with Sam back to the latter's desk, hovering awkwardly behind his chair as they watched the video. Sure enough, after enabling the "bypass lid" checkbox, when the settings were saved and the dialog box closed, random buttons began depressing, settings toggling, and other behavior. It was absolute pandemonium—and Jon knew instantly what had happened.Software testing is a bit of an art, really: you have to be good at thinking like the end user, but you also have to be good at thinking outside of the box and anticipating the un-anticipatable. Testers have come up with shortcuts, ways to help guide testing to be more comprehensive to catch all the edge cases. One shortcut in particular had called to Jon: he could automate the UI, in much the same way the UI automated the robots. By clicking buttons at random, with random timing and random order, he could test extreme user error, determining that even if a literal monkey operated the software it wouldn't do anything unsafe.He'd of course removed this mode from the final software, but he hadn't removed the code that made it function for fear of screwing up something else on accident after it had already passed his testing. That had worked beautifully in the initial version. However, when he needed a new checkbox, he had seen that there was an invisible one already in place and just re-used it. Furthermore, when he renamed the checkbox, his editor had helpfully renamed the associated click handler so that they remained linked. And without the robot, he couldn't actually start the software to test his code, so he'd just sent the update over and waited for bug reports to roll in."Tell them to roll back the update. Tell them I'm very sorry and I'll have a new patch on their desk by the end of day," Jon said, rubbing the back of his neck."But what on Earth happened?" asked Sam, gesturing to the screen."Ghosts." Jon shrugged."What?""The software's possessed. Haven't you ever heard people talk about 'the ghost in the machine?'" [Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!

Many years ago, Chris B. worked for a company that made CompactPCI circuit boards. When the spec for hot-swappable boards (i.e., boards that could be added and removed without powering down the system) came out, the company began to make some. Chris became the designated software hot-swap expert.The company bought several expensive racks with redundant everything for testing purposes. In particular, the racks had three power supply units even though they only required two to run. The idea was that if one power supply were to fail, it could be replaced while the system was still up and running. The company also recommended those same racks to its customers.As part of a much-lauded business deal, the company's biggest-spending customer set up a lab with many of these racks. A short while later, though, they reported a serious problem: whenever they inserted a board with the power on, it wouldn't come up properly. However, the same board would initialize without issue if it were in place when the system was first started.Several weeks slipped by as Chris struggled to troubleshoot remotely and/or reproduce the problem locally, all to no avail. The customer, Sales, and upper management all chipped in to provide additional pressure. The deal was in jeopardy. Ben, the customer's panicked Sales representative, finally suggested a week-long business trip in hopes of seeing the problem in situ and saving his commission the company's reputation. And that was how Chris found himself on an airplane with Ben, flying out to the customer site.Bright and early Monday morning, Chris and Ben arrived at the customer's fancy lab. They met up with their designated contact—an engineer—and asked him to demonstrate the problem.The engineer powered up an almost empty rack, then inserted a test board. Sure enough, it didn't initialize.Chris spent a moment looking at the system. What could possibly be different here compared to our setup back home? he asked himself. Then, he spotted something that no one on the customer side had ever mentioned to him previously."I see you only have one of the three power supplies for the chassis in place." He pointed to the component in question. "Why is that?""Well, they're really loud," the engineer replied.Chris bit back an unkind word. "Could you humor me and try again with two power supplies in place?"The engineer hooked up a second power supply obligingly, then repeated the test. This time, the board mounted properly."Aha!" Ben looked to Chris with a huge grin on his face."So, what was the issue?" the engineer asked."I'm not a hardware expert," Chris prefaced, "but as I understand it, the board draws the most power whenever it's first inserted. Your single power supply wasn't sufficient, but with two in there, the board can get what it needs."It was almost as if the rack had been designed with this power requirement in mind—but Chris kept the sarcasm bottled. He was so happy and relieved to have finally solved the puzzle that he had no room in his mind for ill will."You're a miracle-worker!" Ben declared. "This is fantastic!"In the end, functionality won out over ambiance; the fix proved successful on the customers' other racks as well. Ben was so pleased, he treated Chris to a fancy dinner that evening. The pair spent the rest of the week hanging around the customer's lab, hoping to be of some use before their flight home. [Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!

Gary works at a medium company. Big enough that workers are specialized in their duty, but small enough to know people in other departments and to make turf wars a little more close and personal: danger close. Most of the departments see themselves as part of a team, but a few individuals see themselves as McCarthy, who will themselves alone save the company and defeat the enemies (who are all spies inside the company sent to destroy it from the inside).One of these individuals is named Eric. Eric is close to a Kevin. Eric is the front-end developer, and neither likes nor cares about what happens on the backend. Whenever Eric has an issue, he blames the backend. CSS rendering glitch? Backend problem. Browser crash? That’s the backend problem. Slow UI, even when all the data is cached clientside? Definitely a backend problem. Gary used to get mad, but now knows that Eric is so dumb that he doesn’t even know how dumb he is.Eric grates on people’s nerves. Since nothing is his problem, he doesn’t seem to have any work, so he bugs backend developers like Gary with terrible jokes. A typically Eric joke:“Do you know why they call back end developers back end,” Eric asked.

When I was in college, as part of the general course requirements we had to take Probability and Statistics. The first time around I found it to be an impenetrable concept beyond my grasp, and I flunked. Since it was a requirement, I took it again and barely skated by. Joy; I had cleared the hurdle!By that time, it had become clear to me that I was going into a field that required a whole lot more understanding of P&S than I had acquired. Since I wanted to be properly prepared, I signed up for a free summer school course to try it once more.This time, the professor was a crotchety old German mathematician. He would not allow us to record the lectures. We were told not to bring the textbook to class as the turning of pages distracted him. We were not even allowed to take notes. Every class began with Good morning, Pencils Down! He firmly believed that you had not mastered a skill unless you could explain it in simple words to a complete neophyte, by merely describing it in non-technical terms that they already understood.Based upon my prior two attempts at this subject, after two classes I was convinced that this was going to be a waste of time. After all, if I could barely understand it with the textbook and notes, what chance did I have like this? But I had already signed up and committed the time, so I stuck with it.To my shock-surprise-awe, he managed to verbally paint a picture through which the concepts became crystal clear; not just to me, but to everyone in the class. I had no trouble acing all the homework assignments and tests, and my entire notebook for the course consisted of: