What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.
Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.
The only reason why this product is still surviving and still works is due to literally millions of tests!
Here is how the life of an Oracle Database developer is:
- Start working on a new bug.
- Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
- Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
- Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
- Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
- Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
- Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
- Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
- Finally one fine day you would succeed with 0 tests failing.
- Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
- Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
- After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).
The fact that this product even works is nothing short of a miracle!
I don't work for Oracle anymore. Will never work for Oracle again!
To expand on this separately, this is roughly my process for debugging Ruby:
* Add a "reload!" method that will reload the code.
* Add a repl.rb file that loads the main app and throws you in a suitably configured irb or pry console, with a "reload!" method that'll reload the files you're running in (remember, `require`'s are only loaded once, so this can get tricky for projects that require's lots of things - you can pick a gem to handle this for you, but frankly I tend to find that I usually work on a small set of code at a time, and so I usually prefer to adjust what I want to reload semi-manually).
* Be set up to do remote debugging if your code takes over stdin/stdout, but try to ensure the majority of your code doesn't, so you can play with it from the debugger before you relinquish control at the top level. Or add a way to have your app temporarily surrender control. E.g. my editor will give up control of the terminal to pry when I press
ctrl+x, ctrl+p, and once on the Pry prompt I can access the entire editor state via $editor.
* Add some gems to make formatting data from your objects nicer, like e.g. by current side-project brings in sequel_pretty_print (because I use Sequel rather than ActiveRecord), awesome_print and hirb-unicode.
* While it's nice to be able to run throwaway lines in the REPL, I tend to copy things into methods very quickly, so I build up an array of tests and helpers *based directly on what I've done in the REPL.
Overall most of the "magic" will come from learning the full set of capabilities pry (and irb is finally starting to catch up) and ruby-debug provides you.
My goal tends to be that I shouldn't need to exit the REPL very often while debugging, so I can e.g. keep old objects around and compare state before/after a change, and not have to worry about the complexity.
I use WordPerfect 6.2 for DOS, not for any nostalgia or legacy reasons, just because it's a full-featured and highly configurable word processor that I can use in a terminal. I only use it for writing letters and so on, nothing too serious, but I prefer to stay in the terminal if I can.
It works beautifully under dosemu2, which has a terminal mode that can translate various VGA modes into S-Lang calls (S-Lang is like ncurses, so no X11 required). I find this technically impressive and makes a lot of old DOS software indistinguishable from native linux software; stdin/stdout, parameters, host filesystem access, etc all work transparently.
It can import TTF fonts and print to PostScript, which I just pipe into ps2pdf and then handle on the host.
I'm not aware of any other full-featured modern word processor that can run in an xterm. I know about wordgrinder but it's very very basic. You could use a text editor, but it's not ideal for layout because it doesn't understand things like proportional font geometries - you need that to know how lines/glyphs will fit on the physical page when it's printed. You could write it in some form of markup, html, TeX, markdown, whatever, but if I'm just trying to format a document I prefer a word processor.
(Note: dosemu2 doesn't require virtual 8086 mode, so it works fine on x86-64)
We've got younger guys on my team that hem and haw about the fact that we only have vim on our hardware implementation (SAMA5 busy box), and straight up don't understand why I basically can't use VSCode without the extension, and this article hits on so many good points. Vim is extremely expressive, and everyone ends up using it in slightly different ways. For me, my movement tends to center around:
- 'e' and 'k' rapidly, or 'h' and 'b' rapidly to move left and right, or using 'f'/'F' and a target character, with '0' and '$' as needed
- For vertical movement, I tend to use ctrl+'d'/'u' to move the document up and down in chunks, then specific line numbers, as well as marks (usually at most 2-3, with 'a', 'b', and 'c') to hold on to specific areas, or I just end up remembering line numbers and jumping to them.
- Lots of yanking and deleting to specific targets, be it hori or vert
There's plenty more beyond that, but that really is the "crux" of my vim usage, and from what I've seen watching over the shoulders of many programmers over the years, it makes me way faster than most. Programming isn't about typing speed, but my work is often in doing large refactors in enormous codebases. I need to be able to move around as close to the speed of thought as possible, and I have never found a tool that comes anywhere close to providing that ability as vim.
Whenever I interview people I explicitly make a section of the interview where I answer the candidate's questions, just in case it doesn't come up naturally or the candidate is a bit meek in that department. I think this is an important part of the interview. But if a candidate asked a bunch of these questions, it certainly would harm my opinion of them. I do not recommend using these questions as a guide.
Why not? For one, a lot of them are petty and kind of annoying, so you will come across as petty and kind of annoying. (Oh my God, if someone asks "tabs or spaces?" that is a no-hire right there.)
But also, note that many of these are leading questions for which there is supposedly a definite right or wrong answer ("Do you regularly correct technical debt? Do you use MVC or similar code structuring?" [This second question indicates a serious no-hire.]) Either these questions are appropriate, which implies you know more than the company does about how to develop software, or are at least its peer, in which case why are you interviewing there in a non-executive role, or why are you not off starting your own thing; or they are inappropriate, in which case you are signaling that you are going to be second-guessing everything the company does all the time, in a Dunning-Kruger kind of way, which is not something that anyone wants to deal with.
Either way, the attitude here is that the applicant can stand in judgement over the company, comprehensively across all these categories involved in programming, from the outside, with no real knowledge of what happens there day-to-day. This implies that the company cannot have much to teach the applicant or offer in terms of knowledge and technique, because if it could, then the answers to many of these questions would be surprising to the applicant or would even come across as "incorrect". So you're signaling that you think you know as much or more than the company about how to develop software well -- but news flash, most projects developed even with positive answers to all these questions are trash fires anyway. But some projects are very successful, so clearly there are factors much more important than are covered by these questions. If you treat these questions as important, you are signaling that you don't really know there are more important questions (while also being annoying).
Lastly, note that a lot of these questions are about minimizing the impact of the job on your life, "work-life balance" kinds of stuff. And there's a paradox here. On the one hand, I am not a fan of crunch or any kind of overworking people, and I do think it's reasonable for many people to avoid jobs that put you into that kind of situation. On the other hand, doing good work, for many people, is a primary vector for finding meaning in life; if you are not interested in investing time, energy and effort into a job, it probably is not meaningful to you, so these questions are kind of a checklist for finding a hollow meaningless job, actually. And if you ask a bunch of these kinds of questions from an employer, even one that is very careful about providing "work-life balance" (btw a phrase I never liked, I think it's a deep misconception, but at least we know what we are talking about), the employer is going to notice you keep asking this stuff and is going to get the feeling that you are someone who doesn't want to work very hard, unless you actively signal something like, I intend to work very hard within company hours but clock out exactly at 5pm, or whatever. But if you don't carefully do this kind of balanced signaling, and instead just ask a bunch of the questions from this list, you'll be giving the impression that you are someone most people don't want to hire, because why are you so preoccupied with minimizing work? It's a job, you are supposed to want to work there.
Questions I would recommend in lieu of those on this list:
* Why is the work important? What do I get from this job besides money (in terms of skills or other experience)?
* How is the company deciding what is "good" or "bad" in terms of the software or the development process? Aesthetically, what is considered good, what is considered bad?
* What kinds of decisions do I have the authority to make, and what kinds of decisions am I expected to defer upward?
* How closely will I be managed? What size of problem am I expected to solve independently, and what size of problem should be deferred upward?
* How far can I rise in my field by doing this job?
* How much of my time do I spend programming, and how much in meetings?
Note that none of these are questions with a pre-known right answer (except maybe a little bit the meetings one). They are also reasonable questions that should help maintain a good impression.
I deeply appreciate and am greatly privileged to benefit from the MIT AI Lab's "Tourist Policy" and general openness, generosity, and encouragement of education, which allowed me to use the lab's PDP-10s over the ARPANET as a high school student.
I could connect remotely over the ARPANET by dialing up a local ARPANET TIP and connect to any computer without a password, then apply for a free account on each of the MIT-AI Lab's PDP-10s, by saying that I wanted to learn Lisp or MDL or Macsyma, and use the computers read email (mine and other people -- there was no file security and snooping was encouraged) and play games (like Zork, Adventure, Guess The Animal, and Doctor) after business hours.
As a high school student living in Maryland, I'd occasionally go on a pilgrimage to MIT and visit the MIT-AI Lab at 545 Tech Square, the Media Lab, and other places on campus, including exploring the steam tunnels (like the ones depicted in Real Genius).
They welcomed me to the lab, and I could easily get into the machine room and offices at the AI Lab simply by knocking on the door in the elevator lobby, and somebody using a Lisp Machine would press [Terminal]-D to automatically buzz open the door without getting up from their seat or looking who it was, just to make the knocking stop. (You could also press [Terminal]-E on a Lisp Machine to summon an elevator to your floor.) Then I could walk around the lab, and find a free Lisp Machine, Knight TV, or Ann Arbor Ambassador terminal to log in with, and even sleep on a bean bag chair or couch in an office, if it wasn't already occupied by RMS or some other random tourist or grad student.
Members of the MIT-AI Lab would take the time to help and tutor me with Emacs and Lisp, invite me to go out and eat pot stickers and Suan La Chow Show at Mary Chung's and get ice cream at Toscanini's, encourage me to pick up free papers from the publications department, use the Dover laser printer and Velu Binder to print out and bind my own copies of the online ITS manuals and other documents (long before the consumer laser printers were available), and they'd even let me use the gigantic cappuccino machine (I heard one MIT grad student claim "I had offers from Harvard and Stanford, but I came here because of LCS's cappuccino machine!").
I've written about how the MIT machines were a nerd magnet for kids who had access to the ARPANET, and how I logged in over the ARPANET to play Zork:
How ITS's open approach to security through obscurity encouraged hacking but discouraged vandalism because it really wasn't much of a challenge to break in or crash the machines:
In my exploration of other people's home directories, I ran across an inexplicable (even to the author) TECO implementation of a Universal Turing Machine in Marvin Minsky's home directory "AI:MINSKY;":
Once my friend and I were hanging out in Norman Margolus's office with the lights out playing with his CAM-6 cellular automata machine, when his wife opened the door, turned on the light, and was surprised to see us there instead of her husband. She asked if we'd seen Norman, and we answered no, then she politely turned the lights back off and closed the door, leaving us to our fun.
How Jerry Pournelle got kicked off the ARPANET and MIT-AI Lab's computers for being an obnoxious antisocial unappreciative entitled drunken right-wing jackass, taking his unique precious privileges for granted while making impotent threats and accusing the same generous lab members who had welcomed, supported, and mentored him of being "communists":
>"One thing that is known about ARPA: you can be heaved off it for supporting the policies of the Department of Defense. Of course that was intended to anger me. If you have an ARPA account, please tell CSTACY that he was successful; now let us see if my Pentagon friends can upset him. Or perhaps some reporter friends. Or both., Or even the House Armed Services Committee." -POURNE (Jerry Pournelle)
>"The man has learned nothing from his presence on MC and sets a bad example of what people might potentially accomplish there. I'd rather recycle his account for some bright 12-yr-old...)" -KMP (Kent Pitman)
At the other end of the politeness spectrum, Rob Griffith's memories of touring the MIT-AI Lab and encountering Zork as a 15-year-old kid:
>"I believe on one trip we were touring the MIT Artificial Intelligence Lab, and we saw some people gathered around this terminal. And we inquired what they were doing, and out of that came this game Zork, and my friend, since he was at MIT, had us get an account, and we were able to log in and figure out what to me looked like an extremely arcane set of commands to actually get this game running. From then on we were pretty much hooked from the first time we actually saw it. I believe we saw it when we were walking through the MIT AI Lab. I was a guest. Even back then there was some pretty amazing stuff in there. To see all these students and professors huddled around this terminal. What are the doing? They had all these incredibly cool Lisp Machines with big gorgeous displays, and a bunch of people were huddled around a machine that's got text. And we were sort of intrigued. I believe that was the first time I actually saw the game, so to speak. You know, I never got names, so I don't know. I was a petrified little 15-year-old kid walking around the MIT lab, so it was a bit of a feeling of "Am I supposed to be here?", and if I am supposed to be here, I'm pretty sure I'm not supposed to talk, so perhaps I'll just be quiet and observe." -ROBG (Rob Griffith)
>>Cadging passwords and deliberately crashing the system in order to glean evidence from the resulting wreckage, Stallman successfully foiled the system administrators’ attempt to assert control. After one foiled “coup d’etat,” Stallman issued an alert to the entire AI staff.
>>“There has been another attempt to seize power,” Stallman wrote. “So far, the aristocratic forces have been defeated.” To protect his identity, Stallman signed the message “Radio Free OZ.”
>>The disguise was a thin one at best. By 1982, Stallman’s aversion to passwords and secrecy had become so well known that users outside the AI Laboratory were using his account as a stepping stone to the ARPAnet, the research-funded computer network that would serve as a foundation for today’s Internet. One such “tourist” during the early 1980s was Don Hopkins, a California [Maryland at the time, actually] programmer who learned through the hacking grapevine that all an outsider needed to do to gain access to MIT’s vaunted ITS system was to log in under the initials RMS and enter the same three-letter monogram when the system requested a password.
>>“I’m eternally grateful that MIT let me and many other people use their computers for free,” says Hopkins. “It meant a lot to many people.”
>>This so-called “tourist” policy, which had been openly tolerated by MIT management during the ITS years, fell by the wayside when Oz became the lab’s primary link to the ARPAnet. At first, Stallman continued his policy of repeating his login ID as a password so outside users could follow in his footsteps. Over time, however, the Oz’s fragility prompted administrators to bar outsiders who, through sheer accident or malicious intent, might bring down the system. When those same administrators eventually demanded that Stallman stop publishing his password, Stallman, citing personal ethics, refused to do so and ceased using the Oz system altogether.
>TOURIST POLICY AND RULES FOR TOURIST USE OF ITS MACHINES
>It has been a long standing tradition at both the Laboratory for Computer Science and the Artificial Intelligence Laboratory at MIT to allow non-laboratory people to use the laboratories’ computers during off hours. During the early days of the laboratories’ existence a non-laboratory person (such people have come to be called tourists) could gain access to one of the computers by direct personal contact with a laboratory member. Furthermore, tourist access was controlled because access to the laboratories’ computers was de facto achieved through on site terminals. A tourist sponsored by a laboratory member would generally receive some guidance and tutelage concerning acceptable behavior, proper design techniques for hardware and software, proper programming techniques, etc. The expectation on the laboratories’ part was that a large percentage would become educated in the use of the advanced computing techniques developed and used in our laboratories and thereby greatly facilitate the technology transfer process. A second expectation was that some percentage would become interested and expert enough to contribute significantly to our research efforts. Tourists in this latter group would at some point in time graduate out of the tourist class and become laboratory members. In actual fact a number of former and present staff members and faculty earned their computational wings in just this fashion.
Consider this:
Currently, that expands to this, which is still valid code: If it were just wrapped in braces, the code would be parsed like this: It's incorrect syntax to start a statement with else, so the compiler will say something like "Unexpected 'else' at line N."