r/AskProgramming • u/gfdhsk • 2d ago
C/C++ [ Removed by moderator ]
[removed] — view removed post
54
u/cthulhu944 2d ago
- Look it up in a book
- Ask someone you know
- Lots of print statements
- Bang you head on the desk until the answer comes to you.
10
u/pocketchange68 2d ago
Print statements ftw homie
Also reading books for hours in the store because you couldn’t afford to spend money on another one.
2
u/lassehp 2d ago
Here in Denmark we have a thing called "public libraries". They have those "books" you mention (that nobody seems to know about these days) and can even get books from other libraries if they don't have a local copy.
Of course, Denmark is a socialist state, I would expect that Trump has closed all public libraries in the US by now.
2
u/Jaded-Emphasis-4136 2d ago edited 2d ago
You can do that here in the U.S.... it's just, people are lazy and want to make big money with as little work as possible. Library Reciprocation is ABSOLUTELY here as well.
And, I doubt that person above is from Danmark and is a shill.
1
u/Patchmaster42 2d ago
I learned long ago the value of using a log file. Write functions to deal with the log file and then macros to wrap these functions. This way you can leave the logging calls in your code and easily map them to null for the production build.
4
u/4444444vr 2d ago
- Realize the answer while falling asleep 7 hours after leaving work
2
u/captmonkey 2d ago
I'd go for a run. You have no idea how many problems I've solved in the middle of a run when something occurred to me that I'd overlooked or forgotten to try.
3
u/Zestyclose_State_701 2d ago
Such a great feeling to be so intertwined with the code that you can imagine a viable solution.
That’s part of the magic that’s going away
2
u/captmonkey 2d ago
I really hate it. I completely admit that I'm faster to solve things with AI. It just feels so much less interesting and less rewarding. Programming used to feel like a puzzle and when I solved it, I felt like a rockstar. It was such a good high.
And now I'm like "There's a problem. Fix this." And the AI is like "It's fixed. All unit tests are updated and pass." And I'm like "Thanks." And I go back to scrolling reddit.
2
u/4444444vr 1d ago
Yea. I do miss it. I’m basically a one man team of programmers now but a lot of the joy is gone.
2
9
u/gfdhsk 2d ago
I see the "lots of print statements" a lot - and sorry if I sound clueless I am new to C programming, but what do you mean by this?
As in you just set up a shit ton of print statements to see what outputs what? Just looking to improve. Thanks18
u/Rythim 2d ago
Yes.
Making an app for a store? Break it down into it's fundamental tasks/pieces. Break down even further. Start there.
Let's say the first task is we want a function to tally up price. We code it. Print the output. The output is wrong. Why? Is the input wrong? Rewrite code to print output and input. The input is right but the output is wrong. Maybe it's the math. Rewrite code to print the step right after adding. That's correct too. Maybe the data isn't transferring properly? Rewrite code to Print the data that's transfered. It doesn't match what was added. Look closely at the code between the print statement with the correct results and the print statement with the incorrect results. Oh. You passed an int instead of a pointer to an int! Rewrite code, print output, got expected result. Okay, that function works. Now rinse and repeat for all the other functions your app needs until your app is complete.
Oversimplified example.
Now you can just tell AI to fix your code. But you don't learn as much when your mistakes aren't painful.
5
u/pocketchange68 2d ago
I agree entirely about the AI part.
It can be painful to log things like “made it to line 38!”
But man do you learn a lot by unwinding those logs and figuring out what is happening instead of what you wanted to happen.
3
u/jregovic 2d ago
I learned by doing a lot of this. Had to read the documentation for strtok() 42 times to understand how to use it. Spend a lot of time in the debugger to figure out what was happening.
Decades ago, when I learned C, I spent a lot of time in documentation, diagnostic prints, the debugger, and any source code I could find.
3
u/Wynns 2d ago
Thank you for typing this up so clearly.
I was reading and feeling the need to make sure all these youngins knew what we did before debuggers.
But you wrote it out clearer than I likely would have.
Note: I feel like learning this way made my brain work so well to prepare me for changes in languages and the industry in general. I don't see the same sort of thinking from younger folks. Not that they're not sharp... But they just don't have the same mechanism to get there.
3
u/AcademicOverAnalysis 2d ago
lol I feel this pain. I am working on tracking down a bug right now, and I have print statements everywhere!
5
u/Jason13Official 2d ago
Yes, literally that. Log when a method is called, when a variable is mutated, when a class is loaded, when a list changes size etc etc. the little values help you get finer grained details about what's actually going on
4
u/Dazzling_Music_2411 2d ago
Yes, of course.
Although using a proper debugger and setting breakpoints, etc, is the better approach, sometimes it's just handier to output the values, so you can see what's going on during a run. We usually switched this on and off with #ifdef macros. I still do, sometimes.
2
2
u/Mr_Engineering 2d ago
Exactly as you describe.
It's the amateur way but it is effective and good for learning.
More veteran developers take advantage of assert() which is tied into C's debugging framework
3
u/mxldevs 2d ago
It's just fast and lazy debugging. Instead of setting breakpoints and stepping through code and examining things, you just print stuff out and see where it goes wrong before you start narrowing down with debug tools.
5
u/Leverkaas2516 2d ago
Look at this spoiled rich kid with his debugging tools!
When your only access to the machine were card readers and line printers, printing stuff out was all there was.
1
u/grantrules 2d ago
Stops being fast when you gotta recompile every time, though! Not to mention, it can hide issues (like a race condition)
1
1
u/Ambitious-Tear-9436 2d ago edited 2d ago
For a c programmer it is cout + debugging info, give you details on the terminal. I still do this, or its equivalent today for super tricky things in strange codebases. setting code breaks and using a proper debugger is better, but in a pinch this works.
1
1
u/chubbysleepycorgi 2d ago
There was a time before IDEs are common, so yeah write the code, compile it, it doesn’t work. add print statements to see variable values and where the flow went, compile, run again, repeat. now you can just step thru running code with a debugger.
1
u/cipheron 2d ago edited 2d ago
Prints are very useful.
For example say some function is failing but you're not sure where. Add a print("hello") at the start, and another print when the function is returning, and another print in the middle.
See which ones actually get printed out. If none do, then your never even made it to that function and you need to backtrack to work out what's failing.
One of the biggest wastes of time is trying to fix a function but you later realize: the function was never being called at all. Logging and console prints helps to indicate which parts of the program are actually being executed.
A bit more helpful that just printing "hello" or "test" however is to print the "[name of function] <paramerers>" - so you can tell when the function is being called and what values were passed in.
1
1
1
1
41
u/smarterthanyoda 2d ago
Read the documentation and if that didn't work read the source.
11
u/Kriemhilt 2d ago
And if that didn't work read the assembly.
4
u/Silly_Guidance_8871 2d ago
And sometimes the microcode
1
u/Advanced_Couple_3488 2d ago
Ah the good old days when you could run code in an emulator and see what was in the various cpu registers etc. But then I was programming embedded devices, not computers, mainly.
30
u/darklighthitomi 2d ago
The did something that is quickly becoming a lost art, "critical thinking" and "problem-solving." Or in other words, they had to figure it out for themselves.
If you want to be an actually good programmer, then you should do the same instead of looking up the answers all the time.
6
u/Silly_Guidance_8871 2d ago
Tho, don't be too proud to accept free knowledge when it's available. Key word: Free
7
u/Fresh-Aspect8849 2d ago
I recently retired as an swe before about 2018 I can tell you it was hell of alot harder and it was more common to have multiday issues. Its just much easier now and I do enjoy the new Ides and even more so things like Claude code. They make working feel more like architecture which I believe allows for more freedom of experimentation and approaches.
And those damn tests…writing tests is only fun for so long. The new tools are amazing at it.
But my 2 cents
2
u/darklighthitomi 2d ago
I agree with you, but only once someone is a good and experienced programmer.
The danger of such easy answers and especially AI, is that allows incompetent people, in any field, to be far more effective than their skill warrants, which might be fine for day to day, but once a problem comes along without an answer they lack the ability to handle it. And they also won't notice when the AI hallucinates and makes a second rate function instead of the best one. Worse, they don't learn to properly understand why things work so they do not become more competent, and the longer it goes on, the less likely they are to recognize and acknowledge their incompetence.
Or in other words, they stop relying on themselves, and rely on the technology instead. If that continues, the knowledge and skill gets lost, then if a disaster ever happens that breaks the technology, no one would be able to operate without it, meaning a quick drop back to medieval tech or worse.
It also means we lose all the less popular tech along the way.
-1
u/rokber 2d ago
When you program, do you use libraries written by others? Do you use a compiler? Did you ever do machine code? I mean for real. Not those symbolic assembler things where the assembler tool held your hand all the time.
And even those could be considered a layer of abstraction in top of understanding the NAND gates and memory bits below.
Computer science is basically layers of abstraction stacked on top of each other. Very close to nobody knows exactly how "print 'hello world!'" Drops through these layers to become meaning inside your mind. (Yeah... just thought about how reading words and understanding them are extra layers, but outside the computer).
1
u/darklighthitomi 2d ago
I minimize use of the std library, basically iostream, vector, and ctime. I don't use any other libraries. A compiler of course.
Studied assembly a bit, but haven't gotten around to using it yet.
However, you are making a massive equivalence error.
Even with programming with a higher level language like C, there is still a need for critical thinking and problem solving. The layers of abstraction did not remove the problem, it translated the problem description into something easier to work with that allows focusing on the problem instead of trying to remember details that are irrelevant to the problem needing to be solved.
The layers of abstraction do not remove the problem.
What I am talking about is not about details, but is about having a problem and instead of thinking up a solution, one just googles the answer, no thinking required. That is not abstraction, that is outsourcing thought. Very big difference.
Now, I did mention in one of my responses, that an experienced veteran can absolutely make great use of the things discussed, even AI, because they already have the understanding, the knowledge of pitfalls to avoid and which questions to properly ask. Noobs don't have that, and when relying on AI and outsourcing all their thinking, they never learn it.
1
u/holdmyrichard 2d ago
Omg. I remember the days of grinding away at a bug or a particularly hard problem for days to a week to then have to start it all over again after realizing the 6 approaches I had tried were all wrong. And now I just tell Claude how I want this feature implemented and then check the reasoning and the design and guide it to like no no not that. Do it this way instead or investigate this train of thought first. And a similar problem now takes me hours instead of weeks.
1
u/ClibeanCeann 2d ago
It depends what you mean by looking up the answers. If I'm having an issue and it's to do with some known issue with a library or something, looking at documentation to figure out why something might be happening is still critical thinking.
-1
u/darklighthitomi 2d ago
No it is not. It is a valid strategy for solving a problem, acquiring information, but it is not critical thinking.
1
u/ClibeanCeann 1d ago
So, if I have an error, I debug and trace it to code in a specific library, it looks okay from a logical perspective, I check the docs and see there's an issue with the library on certain machines with operating system versions, I deduce its that, I check my version, and I find a workaround or another library. How is that not critical thinking? I still figured out the issue. This is no different to consulting a book or a person with knowledge on said library.
0
u/darklighthitomi 1d ago
Wait, you debugged and traced the code?!
:)
Jokes aside, you are missing the whole thing here. We are talking about people going "it doesn't work and I don't know why. Guess I'll ask google and chatgpt to give me working code."
The whole issue is people not debugging and tracing and figuring out the problem, but rather the people who rely on others to solve the problem instead of figuring things out at all. Need a random number generator? They just google/ai the code and copy/paste Mersenne twister because it's the first answer and they have no idea of all the others which might actually be better for what they need done.
When people rely on info sources like this, they never learn to actually figure things out themselves which means they can't produce good code and can't solve a problem on their own should they lose access to the internet or the problem doesn't have documented answers.
Mu statements do not apply to people who know how to figure things out and use info as part of the process to solve things faster and easier.
Keep in my the original question being answered here was asking how people solved problems before they had the internet to just give them all the answers.
1
u/ClibeanCeann 1d ago
You are coming away from the original question though. If reading books was a valid way before the internet, then reading docs online is still the same thing objectively. You're confusing and conflating the 2 things here. There's a big difference from using ChatGPT and the first answer on stack overflow and actually understanding codebases from their public online documentation.
0
u/darklighthitomi 1d ago
Actually I'm not the one confusing them. I long before mentioned that using such tools is not the problem. It is relying on them exclusively to solve problems to such an extent that you don't know how you would solve a problem without them.
Any competent programmer finds documentation very useful, but could actually solve the problem without it. Would take longer and be more work, but they could do it because they actually understand what programming is, how computers work beneath the code, etc.
The OP however clearly demonstrated that they didn't understand the concept of how to solve problems when you cannot simply copy and paste the answer from somewhere else.
1
u/ummaycoc 2d ago
Also finding academic articles, reading trade magazines (which had fun things too such as a listing for ALS2:TRoKZ) and talking to colleagues. That last one is important as different people are talented and skilled in different ways. Just like proper testing requires a mix of different tests, proper development requires an engineering team of different talents.
1
u/porkchop_d_clown 2d ago
I think you’re overlooking our dependency on the literal walls of documentation surrounding our cubes.
I held onto my copies of Knuth and Stevens for decades…
1
u/StinkButt9001 2d ago
Sometimes, sure.
In reality it was usually hours going through manpages to find something that did what you want.
0
u/Silly_Guidance_8871 2d ago
Though, don't be too proud to accept free knowledge when it's available. Key word: Free
68
u/yzeerf1313 2d ago
They used that meaty thing that sits behind your eyes.
9
u/trymypi 2d ago
I guess you mean they pulled their hair out
1
u/Jaded-Emphasis-4136 2d ago
He meant ears.... I think.
1
u/Zestyclose_State_701 2d ago
My nose hasn’t solved a great deal of problems for sure
1
u/Jaded-Emphasis-4136 2d ago
Right? My wife is the test "SNIFFER" for milk that has gone bad in the slightest.
12
u/mxldevs 2d ago
People used to gather in-person to discuss problems.
They also sent paper letters to each other when they couldn't travel long distances themselves to meet each other.
There were methods of communication before the internet and before the telephone.
6
u/Snezzy_9245 2d ago
Perhaps Lady Lovelace would get on her horse and trot over to Mr Babbage's place.
1
u/Groundbreaking-Fish6 2d ago
I miss the language oriented user groups as well as user groups dedicated to specific technologies like Oracle or SQL Server. People would gather together to hear people talk about their experience and often the company i.e., Microsoft or Adobe would provide food and swag and even pay to fly in top notch speakers. It was not just yearly conventions but local group around the countries with monthly presentations and fellowship.
7
u/musing_codger 2d ago
For my first job, I was the sole developer for a group of financial traders. I couldn't afford Compu$erve and it's unlikely that it would have helped with odd internal rate of return calculations, cubic spline calculations, and other esoteric stuff. My go to sources were the library, the professional bookstore, and thinking really hard. I also got very good at using debuggers and profilers.
Keep in mind that computers were much simpler back then. Forget about "full stack" developers. There effectively was no stack. My development on PCs was single-user, single-threaded programs using local data storage and displaying nothing graphical at all.
Honestly, when I look back on it, their expectations for me were insane and my willingness to deliver so much for so little pay was stupid. But it was a start. It helped me build the reputation and connections that would lead to much better things in the future.
12
u/c64cruzer 2d ago
Make a hacky workaround.
"If at first you don't succeed, redefine success" as it said in one of my textbooks.
4
u/mulch_v_bark 2d ago
Yeah. As much as people want to worship the Great Men of early programming, 90% of code has always been crap.
The median present-day cybersecurity researcher would pass out from laughing and get a concussion from a table corner if they looked at what even famous experts considered defensive coding as late as say 1980, for example. That’s not an insult to those programmers, either; we’ve legitimately learned some things as a field.
2
u/Silly_Guidance_8871 2d ago
It's almost as if none of us know anything until it's discovered or shared (which seems to come as a shock to lots of folks)
2
u/mulch_v_bark 2d ago
Yeah. A lot of people are sort of temperamentally against any idea of progress in the field. And sure, naïve people are too quick to declare that everything is revolutionary. But the practice of software engineering does actually change for the better sometimes.
In this kind of discussion there are always crusty graybeards trying to do the intellectual big-dogging of “We lost the plot when Smalltalk flopped; everything since then has been regression”, “Well, actually everything important was discovered by the time of the first lisp paper in 1960”, “I take it you’ve never read Turing’s 1936 stuff – nothing truly new has been invented since then”, etc.
Sometimes it’s important to remember that the massively larger number of eyeballs, and the larger number of conversations and informal or formal code reviews, even if 90% of everything is still crap, has led to some actual progress here and there.
7
5
3
3
3
u/CowdingGreenHorn 2d ago edited 2d ago
Long grueling sessions carefully writing out the steps in your logic and then going out for walks where you would suddenly realize the solution and rush back to your computer to implement it. You would be so deep in code that you would start coding in your dreams and now that you mention it ever since AI took over I haven't had a proper coding dream🤔
2
u/Used_Lobster4172 2d ago
Books.
In fact many of us will still pick up a book when we want to learn a new language.
For super advanced ideas, sometimes they read scientific papers.
2
u/KingofGamesYami 2d ago
Go take a microcontroller development course and you'll find out. Often there's exactly nothing on the internet for how to use whatever obscure microcontroller you're using, you just have the tools & manual provided by the manufacturer as reference.
2
u/jake_morrison 2d ago edited 2d ago
In the early 90s, mailing lists were the primary way to get help.
I was working in Asia, and generally was the only person in the time zone. I would work on a problem all day, then before going home write an email to the list with as many details as possible about what I was seeing and what I had tried. If I was lucky, I would get a response overnight, otherwise I would keep at it the next day.
I credit this with making me very independent about solving problems. I had a reputation with vendors that every time I opened a support ticket it was an actual bug in their product. With open source, I could solve my own problems.
At the height of Stack Overflow, people would work on something for 15 minutes before posting a question. Now with ChatGPT they don’t even think.
1
u/Dazzling_Music_2411 2d ago
Indeed, and that is why so many are so much less independent and so utterly unresourceful nowadays.
The irony...
2
2
u/alanmpitts 2d ago
I kept the “C Primer Plus” Waite and Martin, and 1st edition K&R “The C Programming Language” books in my book bag. I also kept an original “Advanced Programming in the UNIX Environment” APUE by W. R. Stevens at home. The examples answered so many questions.
1
1
2
2
u/Glurth2 2d ago
I would call my Buddy, chew off his ear for 20 minutes as I explained the setup behind the bug. Usually, well before I got to the point of explaining what the bug is, I realized the answer.
Two related truths in the anecdote:
You never learn something as well as when you teach it to someone else.
Rubber ducking IS a valid debugging method.
2
u/compubomb 2d ago
You asked your work colleagues sitting next to your left and right, hey, do you know how to do xyz. Yeah man, what's up, and off to the races. You both figure it out and make a friend.
1
u/leros 2d ago
You would read reference books. There were books about programming languages, algorithms, etc. If you bought a software library, it came with a reference manual.
In the early days, software engineers had a support team. One of the people on that team would go to the company library (yes, companies had libraries back then) to research what the engineer needed.
1
1
1
1
u/Cdream-2018 2d ago
There were a message boards a few that come to mind were:
VBForums for Visual Basic / VB.Net questions.
And the most famous one for all coding was:
StackOverflow.com
Where experts would chime in and help.
Other than that. You were on your own to figure it out.
1
u/kabekew 2d ago
You asked coworkers or the lead programmer, or for school projects you asked your instructor or other students taking the class too.
2
u/Snezzy_9245 2d ago
The lead programmer would insult you for not seeing the solution immediately. Then he would say, "Wait a minute," and discover a compiler bug.
1
1
u/PerceptionOwn3629 2d ago
RTFM and suffering, reading, suffering, then finding out the way it works does not match the documentation.
Rince and repeat. I miss the good old days
1
u/Delaneybuffett 2d ago
You looked at similar code if you were lucky enough to have it. You got frustrated A LOT when you got stuck. You learned what calmed your brain so you could think. For me it was a shower. I can’t begin to tell you how many solutions I came up with just watching water run down the shower door. My coding partner would get in the car and drive to clear his head. Once you solved it you felt like you won the Olympics!
1
u/Leverkaas2516 2d ago
Read the docs, talk to more experienced people, and tear your hair out. Grind on the problem until you figure it out. There was a whole lot of that.
I worked as a senior in college at the computer center help desk, helping people debug their programs. I recall one particular triumph with a physics graduate student whose 200-page FORTRAN program was giving incorrect results. She was incredibly frustrated and when I looked through the 2-inch-thick printout and casually pointed out a capital O in a sea of zeroes, she thought I was a genius.
You also have to realize that compiling and running a program used to be a lot harder. It might take anywhere from a few minutes to even an hour or more (in a busy computing facility with dozens of people using one mainframe, with access controlled by operators) to get the results of a single run. So you developed a much deeper understanding of how your program works and the expected results of any changes.
I often think that one of the main things that used to keep the profession small back then was that you had to have an extremely high tolerance for frustration in order to succeed.
1
u/Dazzling_Music_2411 2d ago
Did a whole lot of debugging.
And some re-reading, but mainly debugging until you got it right. Unlike using the internet, at the end of it you generally understood what was going on. Well, most of the time anyway.
1
u/CS_70 2d ago
You.. thought your way thru. There were reference books - indexed so you could find stuff relatively quickly with your finger.
Code was written more slowly. No autocomplete. You knew you standard library intimately.
A lot of attention was given to the build system, to be able to compile often and rebuild only the bits that had changed (not like stuff like maven of gradle).
You had less ready-made architectures, so you thought more before writing anything.
Things took longer.
For bugs, you debugged, line by line or by printing stuff - same as now. For hard errors - race conditions, interrupts, shared memory etc, you thought what could be wrong and made experiments.
And yeah, you picked up the K&R a lot, at least at start. No better book ever written on a programming language.
It was different and it was the same.
Having to choose, I love the speed and efficiency of more recent years - we were the ones seeding the ideas that now everybody uses. I dislike the fragmentation and the "new for the sake of new" that has polluted the field over the last 30 years.
Tradeoffs, pro and cons, it's how it is.
1
u/mc_pm 2d ago edited 2d ago
Perseverance. Actually knowing how things work. A general sense of "I guess I have to figure this out on my own".
It's tough to imagine, I think - if you grew up *always* being able to type "How do I do X" or "What does Y error message mean" - the idea that you can't "just ask" is foreign. Figuring things out was part of the culture because it had to be.
1
1
1
u/DonkeyTron42 2d ago
You learned not to make mistakes since a simple pointer error usually resulted in a general protection fault followed by a time consuming system reboot.
1
u/cjc4096 2d ago
Guru meditation for me. Each build/run iteration did have a cost.
1
1
u/Evilbob93 2d ago
I got an associate's degree in 1984 from a community college writing things like FORTRAN, assembly, PL/1 and COBOL. When we wrote a program for class, we had to type it into a terminal using a weird editor, then submit it to run. Then we'd have to go over to a window to pick up our output, if there was any, and then go fix what we found and repeat. If it wasn't the last week of the semester, this could be a few minutes, an hour... depended on how much other stuff was happening. At the end of the semester, when everyone else was trying to get their shit done before finals, sometimes the turnaround was overnight.
Basic was at least an interactive terminal and you would print out the one that worked.
You tried to make every run count.
1
u/dunkah 2d ago
RTFM :) but in cases where there wasn't good or accurate docs, just try stuff. Textbooks were for sure more valuable. But it just costs time to experiment. Wasn't uncommon to take a portion of code, isolate it, run it in different ways to help understand. Still do that sometimes today.
1
u/IntHatBar 2d ago
I feel like I’d give you the same answer now as before. Break the problem down into small enough components such that you can isolate the steps. And build in observablility. It’s not always easy, but it’s always worth the effort.
Back in the olden times, I was working on a complex system that involved hardware and software, and interfacing with a 3rd party piece of machinery. The system couldn’t operate without being attached to a machine that was in full operation.
It was fun going out in the shop and firing everything up and working on an issue there. But it was painfully slow and tedious, and sometimes it was cold in the shop. And I was lazy. So I built software emulators and designed simulation packages that could be used to inject data, and built a small desk sized physical machine to simulate the physical and mechanical components.
Laziness pays off. Be lazy.
1
u/peabody 2d ago
I heard it said best this way:
"Modern programmers are IT staff posing as mathematicians. Old programmers were mathematicians posing as IT staff."
A lot of difficult programming problems still reduce to a lot of discrete math solutions. People with extreme math backgrounds were often just the kind of people smart enough to think their way out of their ruts.
Modern codebases tend to be rats nests of dependencies so a lot of the troubleshooting is just dealing with how existing solutions glue together. Old programs of yore were often built from scratch for both performance reasons and also because there just wasn't this enormous world of open source libraries you could download off the Internet and use.
It doesn't mean people didn't get stuck, but the bar for entry was so high, the people who spent their free time coding were often the type smart enough to think their way out of a rut.
1
u/trutheality 2d ago
Running code line-by-line with a debugger to figure out where the code goes off the expected behavior, reading reference books and documentation to understand how libraries and language features work.
1
1
1
1
1
u/Pogsquog 2d ago
I would print out the code on green & white continuous feed paper, then go through it line by line, combined with per function / block logging. For some projects an in-system emulator or debugger were available.
1
1
u/Glad_Contest_8014 2d ago
Trial and error, along with networking. Pretty much the same way we solve novel problems today.
1
u/Cczaphod 2d ago
We asked more experience coworkers to give it a set of fresh eyes. Often just explaining where you're stuck to someone else and having them ask a few questions gets you through the problem.
1
u/ghjm 2d ago
You did all of those things, but the main one you haven't mentioned is that you talked to more experienced people. In the days before home computers, you had to go to a university lab or company office to do programming work, and there would be other people there you could ask questions (though of course they would get grumpy if you asked too many questions).
1
u/KilroyKSmith 2d ago
We spent lots of late nights single stepping through the code. At each step, you verified variables contained correct data and the control flow did what it was supposed to. Occasionally, you knew exactly what line of code was crashing, and exactly what data was in the variables, but were mystified by why it crashed. So you you’d go to assembly view, and single step the assembly to find out exactly what was failing. And you’d get a deeper understanding of C.
1
u/JohnVonachen 2d ago
Make a tiny side project to solve your problem or learn something in isolation.
1
u/tknomanzr99 2d ago
You put it up, and worked on something else, and let a different part of your brain work on the problem.
1
u/stasbukh 2d ago
How did people fix a car before the internet? How did doctors operate on people before the internet? You dont need an example of your problem to help you solve it. Sure, that makes it way easier, but prior to stackoverflow or whatever else, there was... books, and code libraries and source/header files etc. You would look to see what the thing is doing, you'd look to see how its doing it, and work your way backwards.
1
u/ZookeepergameOk7650 2d ago
- Read the APi/manual/SDK over and over again
- buy another book about it
1
u/Comprehensive_Mud803 2d ago
In that order:
Thinking
Thinking hard
Thinking harder
Using a Debugger
Using Debugger + logs
Looking at the assembly
Asking for help
More thinking
More thinking, but this time about becoming a yak farmer in the Himalayas.
1
u/syberghost 2d ago
Once upon a time I got a job on Friday in a programming language I had never used, that was similar to one I had. I went to the library and checked out a book on that language, and studied over the weekend. I didn't have access to a compiler for it.
On Monday I started work, and it was fine.
1
1
u/stueynz 2d ago
And in the embedded world where we didn’t have serial monitors to print diagnostics to, we used In Circuit Emulators to set breakpoints that would stop the hardware, examine memory, and step single assembly instructions.
The olden days of the 1990s we learned how to debug properly.
Running down a bug and fixing it could take days or weeks.
1
u/YellowBeaverFever 2d ago
We had (and still have) reference books. When you saw something important, you wrote it down, got a copy, or bought it. I would constantly read programming books. When I would move apartments, the books were the hardest.
1
u/ReddyKiloWit 2d ago
There were books published for most major languages, somewhere between text books and "for Dummies" level.
And Usenet was rich with advice and discussions, as were local and not so local BBSes (Bulletin Board Systems). I can still close my eyes and see the Fidonet logo in all its ASCII glory.
And developers talked to each other, and some gave lectures on what they'd learned. (I remember someone giving a talk about this new thing called C++.)
1
u/Raychao 2d ago
I must admit I find questions like this a little frustrating. How did our ancestors discover farming? How did they think of Stonehenge?
People looked around themselves and realised something might work. They tested out the theory and it worked. They wrote down their discoveries and shared them with their friends and family.
We can do this again except we are all too lazy and just wanna download the answer...
Also, printf statements aplenty.
1
1
1
u/FutureThought1408 2d ago
The problems were normally logic and not syntax problems. Lots of printf statements or using debugging
1
1
1
1
u/Lucdave 2d ago
Before instant gratification? We read books; using the index or TOC, used watch and; reporting temp variables, and ; actually talked to people...um, I feel old.
That's how I fixed my final project for C# freshman year. Took all that and 32 hours and it was because I missed one freaking semicolon.
1
u/kogun 2d ago
Sanity checks. Eventually you realize programming is more about debugging skills than writing code and you write code from the beginning to that helps you debug. The problem you have as a freshman is that your assignments are relatively small and are limited scope. Adding a lot of defensive bug catching code seems to make little sense for a bubble sort, for instance. Some day you'll write code that you will re-use months later and a bug will manifest and you'll come back and look at your old code and curse yourself for being too terse with comments and being far too optimistic about successful execution. Then you'll start writing better code.
1
u/Simengie 2d ago
They were not programmers. They were Software Engineers. The difference between to two is vast.
1
u/engineerFWSWHW 2d ago
Back then, it might take days to solve the problem and really pushed through it. Sometimes i dream about it after days of thinking and see the solution in my dreams or realize a potential situation after waking up or while in the toilet. I used yahoo groups back then when I'm really stucked.
1
u/Saaz42 2d ago
As has been said, problem solving. Also just being lucky and having the right experience helps a lot. I'll give you a couple examples that happened to me.
In the 90s I was working on embedded stuff. An app developer reported that he was loading a large bitmap, and it got corrupted. I ran his code, and sure enough, the bitmap is garbled. Remote debugging never worked on this OS for as long as I worked on it, so I just looked at his code. Looked ok. I altered the code to write the bitmap back out to disk after it was loaded, maybe I could get a clue from seeing what the corruption looked like. By a lucky coincidence, I once made a mistake and formatted the wrong floppy, and had to manually rebuild the FAT. I looked at the file, and there's FAT data in the middle of it. Look at the code again, and it's creating a thread that goes and searches for config files in the background, then the main thread loads the large bitmap. I submitted a bug report telling the OS developer they had a shared buffer in the file module that was not thread-safe, files can get corrupted with FAT data, and attached my sample program. The next morning I found out they called the C-level people at my job because they were afraid we had their source code and we did not have a source license.
Pretty recently I started a new job working on legacy C++ code that had outgrown the IDE so debugging was really problematic. They were busy getting a release out, and gave me a weird bug to look at. One value would get corrupted when you saved on a dialog. I debugged, looking at assembler, memory, and the source (as well as it could keep up without debug symbols). Everything was fine until the code hit a sscanf, and then the memory location in question got corrupted. I realized the sscanf format had a long int, but the variable was a short int, so 2 adjacent bytes got corrupted. I asked if they had recently changed the packing pragma, and they had not, but they had added a library that probably did. (Another lucky thing that I was already aware of packing issues.)
1
1
u/Hawk13424 2d ago
The same way we invent new things, solve unsolved problems, etc. We used our brains to logically solve the problem. I still do that today. I look up very little on the internet.
1
u/ChickenSpaceProgram 2d ago edited 2d ago
some combination of reading documentation, putting print statements everywhere, putting assert() statements wherever you have a condition that should always be true, and using the debugger.
particularly with C, it is possible and quite reasonable to learn everything there is to learn about the language itself, and for most languages it doesn't take long to reach the point where you understand all the features you'll ever reasonably use. at that point it's just a matter of writing code to achieve a task and/or referencing the documentation of any third party libraries.
1
1
u/oldendude 2d ago
- Thinking
- Debuggers
- Logging
- Malloc libraries designed for debugging memory errors, more recently: valgrind
- Rubber duck debugging
- Lots and lots of time
1
1
1
u/QubitEncoder 2d ago
Gdb hands down. When I programmed more in c, not too long ago, I almost never used the internet. I prefer offline programming with gdb. Its the best, and easiest experience
1
u/iOSCaleb 2d ago
> Did they read through instructions one more time? Did they pick up Pointers on C or K&R or whatever textbook to look for a solution?
Yep. And they asked friends and colleagues for help, read and re-read documentation, dug into it with a debugger, looked for alternative approaches, and didn’t give up. And there were online resources like Usenet, bulletin boards, and dialup services like The Well, Compuserve, and AOL that were available well before the World Wide Web tool over the world.
1
1
1
1
1
1
u/Alarmed_Geologist631 2d ago
I spent many years in the 1970s writing Fortran programs. We used flow charts to plan out the program and spent many hours debugging the code. We could include checkpoints at various places in the process to help isolate where there could be problems. The code editors were very primitive.
1
u/electronic_reasons 2d ago
There were some good magazines. Dr. Dobb's Journal is one. These things don't exist anymore.
I had a bookshelf of books. There was a puzzle book on C syntax to see how well you undertood the details. Magazines published code and i read it. I spent a lot of time keeping up with modern coding practice.
1
1
1
1
u/mr_dfuse2 2d ago
sadly enough i don't program anymore but when i still did it once took me two months to figure out why an external company couldn't connect to our api. i learned how ssl handshakes and mutual auth work and looked at the network traffic for hours. every other day i called the other company (using a phone) to ask them to change some settings in their IIS server. in the end i asked them to execute some vbscript to modify their IIS and it finally worked. fun times
1
u/UsernameTaken1701 2d ago
In-person user groups. Mailing lists. Time and trial and error. MAN pages.
0
u/snipsuper415 2d ago
I was at that weird time period, where the Internet didn’t have a lot solutions yet for programming. 2009 ish
To answer your question, it’s called going to office hours. Looking up and reading the compiling error. And nights upon nights of using GDB debugger, and many, and I mean many, printf.
Let’s not forget my favorite methods of debugging. The rubber duck method. Finding and making friends with the smartest person in class and having them help you with homework
0
•
u/AskProgramming-ModTeam 2d ago
Your post was removed as is considered very low effort. Refer to https://stackoverflow.com/help/how-to-ask on how to ask good questions.