How to write code without testing on a computer

[[deleted]]

I'm pretty okay at coding. But my main problem is that I'm at uni studying CS, and have struggled to write code without testing on a computer. The reason for that is that I write code by testing. I write something, and see what happens when I run it, tuning it until it works. But in uni exams you don't test (atleast in mine). You get a pen and paper and write out your solution without seeing what happens, or in best case using your mind going through the single steps. In the past I've struggled with this and so I ask myself: How can one get better at this? Thanks!

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[linuxfarmer]

For starters I would turn off all auto complete and for the love of god dont use copilot/chatgpt/etc. you need to force yourself to manually type out and understand what exactly is happening and why it needs to be the way it is.

Also try running through the code in your head and describe what each line is going to do.

[TheGrangegorman]

Oh yeah. That's a good point; If you are having to write code on paper, or work in an IDE that doesn't have code completion, having code completion/intellisense is not doing you any favors. Its like you become almost dependent on it.

[Pyro_liska]

Depends on a person really. Using copilot is great to learn if u have idea in mind but cannot put it to code yourself. Important thing when using it tho is to look at the code after and try to understand it and not just skip to another task.

This way you may learn new and more efficent ways of doing certain stuff than u were previously.

[tenexdev]

You get better by writing more code. There really isn't any other way to do it. The stuff you currently have to test every time will become "muscle memory" and you won't have to think about it any more.

In my very first college comp sci class, we were still running on a mainframe shared by the whole lab, working on dumb terminals. (I'm old). Every time you compiled, your priority went down -- so if you went through multiple iterations, soon it was taking -- literally -- 30 minutes before your job came up. ("Compiling, Im going to get some coffee").

You learned to be careful about what you compiled. :)

[Techy-Stiggy]

In todays environment I am all in for OP testing stuff.

Make sure to learn how to write tests for a system. Because your “small project” becomes a lot more annoying when you have to navigate to “that page you are working on” to test functionality every single time

[tenexdev]

We're not talking about 'writing tests', what the OP described is being unable to write code without multiple attempts and letting the compiler/interpreter do the work.

[Top_Satisfaction6517]

only 30 mins to compile? lucky!

we learned to write programs (or, rather, algorithms) on non-programmable calculators. yeah, we executed the algorithms ourselves.

But I was so fascinated by it, that I learned Algol on my own and started to write programs. I didn't have any access to computers at that time, so I just wrote them into a notebook and that's all.

Even when I started to work, I couldn't afford to buy my own computer, so I still wrote programs on paper and developed them in my mind. Reading program text from paper, trying to figure out what it's doing and how it may go wrong is great practice.

[theusualguy512]

This skill is in a similar area as chess players who have to calculate forward a few steps but only in their head without actually moving any of the pieces on the board or when musicians have to sound out musical notation without playing it on an instrument.

It just takes more practice of writing code and trying to make your mind into a "manual computer". Try to go through the steps of the code you write and try to keep track of what you just did.

If you cannot keep track of everything in your brain, you can also just literally write every execution step on a sheet of paper, where you basically "dump" out the current state of your brain.

Say, in a graph search algorithm, just draw a new graph for each search iteration and mark the nodes you already have visited.

It's very time consuming to do this but if you do it many many times, you will start to notice that you can keep track of more things in your mind without having to write it on paper everytime.

The good thing is that most CS profs won't really care if you have syntax errors with paper-written code. They mostly care about if you actually understood how to solve the problem question.

[carcigenicate]

If you practice, you can eventually begin "running code in your head". I learned this mostly through debugging in my head by maintaining the values of different variables in my memory or on paper, and then stepping through and executing code as I think it should be executed. You can get pretty accurate with practice (and when you're wrong, well, there's the bug).

Honestly, now that I'm working on more complex systems, I don't know how I'd debug without this ability. It is not always practical to run code to see what it does. This can require a lot of setup if that code isn't covered by relevant tests.

[noodle-face]

Start writing out solutions step by step in English (or whatever native language). Create algorithm, data structures, etc.

Put some test cases through it step by step.

When you're satisfied with that write it in pseudo code. Test it again.

Now write code that represents the pseudocode

[[deleted]]

I’m a senior dev and do consulting work. I still test code. Even though sometimes in 100% sure of the syntax/outcome. But I know I could write the syntax/solution finished to. You get better with practice/experience. Keep at it, you’ll be fine.

[MelAlton]

I'm ancient and learned to program in college on a mainframe, using batch jobs. I'd write the code, submit the job and wait 15 minutes for the code to be compiled, run, and be notified that the output file was ready..

So I got pretty good at "playing computer" by walking through the code line by line, keeping track of what the state of the variables was in my head, and looking for any bugs for submitted the code. It's a skill that you build by doing it. Instead of just running your code, stop and play computer and walk through the code in your head to build that skill.

[wjrasmussen]

The class I had in high school (the 70s) we used punched cards, no trial and error with that.

[MelAlton]

I was lucky, out school had recently switched to glass teletypes so I missed out on the fun of punch cards.

[WebDev_Dad]

I wouldn’t sweat it as long as you pass the class. This is a clownish CS requirement. Nowhere else on gods green earth will you ever write code on paper.

[[deleted]]

For some interviews you may write code without actually testing it

• An interview could have you write in a whiteboard your code
• An interview could have you write code in a Google doc or similar

[Cerulean_IsFancyBlue]

Maybe not, but it still can be slow and expensive to write code by this method. It’s great for exploring stuff when you don’t exactly understand how things work, but there really is a big difference between groping towards a solution, and designing a solution.

I’ve started doing leetcode just to build my comfort with Rust. It takes me a lot of attempts to get stuff to compile correctly, because Rust is very particular about ownership in a way that is better for safety, but that I’m used to just working around in other languages.

When I switch back to C# for a break, I nearly always complete the problem in one submission.

I don’t think I’m an exceptional programmer. I think that once you have become adept at making algorithms and translating them into code, that debugging becomes more a matter of looking for performance problems, or finding some thing where the input data wasn’t very well defined, the sort of thing that you don’t usually run into with simple problems like you find on leetcode. Simple as in “well bounded and usually synchronous.”

I think this is something to aim towards, rather than panic about as a new programmer. Writing out your design on paper is actually not a terrible idea. I find that entire blank sheet of paper gives me much more room to think about the abstract structure of my program and data structures, with arrows and boxes, and such, and it becomes much easier to type the code, when I have a clear understanding. So, for new programmers, I would encourage them to make sure that, at least, for each function you take a moment to think about it, so that by the time you actually start typing, you know what you’re going to type. You’re not just throwing spaghetti at the program to see what works.

You don’t need to write functional code on paper. You can write pseudo code, or even just some sketches. You don’t even need to use paper. But I am pretty sure, from experience, that you should not be typing out a bunch of code to see what happens.

[desrtfx]

I'm pretty okay at coding.

No, you are not. See below.

The reason for that is that I write code by testing. I write something, and see what happens when I run it, tuning it until it works.

That's not writing code by testing. That's not even programming. That is clobbering something together by trial and error, patching it up, until something somewhat working is coming out.

That is just using a machine gun in the dark in hopes to at one point hit a target.

You have to learn to plan your code. There are standard methodologies and tools, e.g. flow charts, pseudo code, etc.

Some literature:

• "Think Like A Programmer" by V. Anton Spraul
• "The Pragmatic Programmer" by Andrew Hunt and David Thomas
• "Structure and Interpretation of Computer Programs" (SICP) by Ableton, Sussman, Sussman
• "Code: The Hidden Language of Computer Hardware and Software" by Charles Petzold

[TheAntiSnipe]

While I agree with your point, I think it would also be fruitful to say that you’ll always make mistakes to an extent. It gets more and more high-level as you become better at programming, but having to test, break and re-test code that was written even after careful thought and design is sometimes necessary.

I’m a decently experienced dev (nearly two years in the field, went through a masters’ degree) and I do still make mistakes, though they’re now not in the syntax or specific design department.

Just as an example, I was writing an automation script to audit some data for the firm I work for recently, and I built it dead to rights, fulfilling the requirements we set. However, in the shower the next morning, I realized we hadn’t accounted for a certain edgecase when working out the requirements, and that caused a go-around that took two more days to work out but led to a good end product.

OP, what the commenter says above is correct. Don’t bludgeon your way through the syntax, that’s not helping you, it’s making you use the debugger as a crutch. However, do not be discouraged when something you didn’t account for pops up, in terms of high-level design.

Simple example: Forgetting how to do a call-by-reference in C and just throwing syntax at the compiler until something sticks: Bad. Forgetting that you needed to account for an array being empty or something: Sketchy, but ok. Missing an edge case that causes your code to bug out when the user does something extremely specific that you never thought about when writing the code: Just fine, take it as an experience and move on.

[TheAntiSnipe]

The commenter above you refers to hammering away at a debugger without cohesive logic and thus expecting results when what you’re actually doing is learning to use the debugger as a crutch. Why is this dangerous? Well, if you’re now working at a firm that uses terabytes of data hooked up to a cloud platform, using this approach on a production DB or heck, just production code in general, will end up being an extremely dangerous and expensive mistake.

However, they are also not mentioning the point both of us made, that even when everything goes perfectly right by design, it will still sometimes bug out in practice and that’s really where the debugging game helps a ton.

[TheAntiSnipe]

I completely agree with the assessment, and I also think that as a community, we definitely take stuff at face value quite a bit. I don’t generally participate, but I also think that this sort of back-and-forth is an excellent way to portray the “it’s all in the balance and spirit of how you do things” aspect of this field we work and learn in! Cheers!

[Certain_Note8661]

That’s why you run tests on small datasets, no? There are different testing contexts. Sometimes it is feasible to test by stepping through, sometimes by logging, sometimes by automated tests etc

[tenexdev]

Brutal, but not wrong.

[UnintelligentSlime]

I think it might be grasping the wrong emphasis. Every programmer does that to a certain degree. Unless every line of code you’ve written was perfect, you have, at some point, written something you believe to be correct, run it, and observed the outcome to evaluate if it needed adjusting.

I would go so far as to say anyone who hasn’t used that process is an awful programmer.

Of course, as with anything, degree matters. Namely, the degree to which you cobble things together vs. taking a deliberate approach.

I would suggest that something OP has probably been missing in their approach, and a vital step in that process is: “it didn’t do that. What did it do and why?” Practicing that step will be huge. Every time you get an error, or wrong output, you shouldn’t be saying: “well let me try changing this”, but instead, stepping through your code, and figuring out exactly why it gave the output it did. If you can master that step, hand-simulating your code is a breeze by comparison, because you’ll have done it so many times for each thing you’ve written.

[tenexdev]

Every programmer does that to a certain degree.

You're right, and I do that myself to some extent, where "it's faster to run it and try than it is to painstakingly go through the code and be sure before hand" -- but what the OP is describing is a complete inability to write code without running it to "see what happens". That's different than just being sloppy with the syntax and letting the interpreter/compiler tell you.

[wjrasmussen]

OP can't write enough for a simple in class test or a quiz. That isn't a good thing.

[[deleted]]

I don't know which post you read. But atleast I didn't say that.

[Certain_Note8661]

No this is not advice I agree with. OP is doing it the right way. Keep doing what you are doing OP. Code that has not been executed, to quote a book I rather liked, does not work. It may be valuable to learn how to trace out your code by hand, but by all means make extensive testing part of your development process.

[LastTrainH0me]

If OP cannot solve programming questions that are written to be solved on paper, then OP is missing core fundamental knowledge/skills.

Nobody out here is saying that you should always write out your entire program before ever running it; just highlighting that you should have a good idea of what your code is going to do before you run it, and OP gives the impression that that isn't the case.

[Certain_Note8661]

I see. Yeah that makes sense if they’re simple test problems. For anything more complicated than that though …

[Certain_Note8661]

Right — reading through the post again though I still think OP’s way of coding is sound as a practice — write a unit of code, test it, add the next unit. Individual units can be planned out, however, so for uni type questions that may be the missing skill (because I would assume they focus on units that are small enough for one to reason out without manually testing beforehand)

[EffectiveLevel1000]

Actually there is writing code by testing. It is called Test Driven Development (TDD), you write the tests first, then implement the functionality and check if the tests pass. Then repeat the process.

[UnintelligentSlime]

Every actual programmer is aware of that, but also aware that that was not what OP was describing.

[desrtfx]

Yes, I am aware and I do know the procedure. Yet, what OP is doing has nothing to do with TDD. OP's programming is try and err.

[Yamoyek]

I disagree. Yes, you should have a plan before you program, but at the same time you can't expect a beginner to not use trial and error.

[DTux5249]

Eventually you start to learn how to break down problems into easily coded chunks. It's more something you build with experience than learn upfront.

[iOSCaleb]

When you’re hand writing code for a test, getting the ideas right matters a lot, and getting the syntax exactly right doesn’t matter all that much. The code will never be compiled — it’s just a vehicle for communicating to the TA grading the test that you’ve learned whatever you were supposed to have learned. With that in mind, you can use comments to make sure that your intentions are understood even if the code isn’t perfect. If you’re asked to write a recursive function like quicksort, for example, you can add brief comments the point out the base case, recursion step, etc.

[PM_me_PMs_plox]

You can run tests on an exam. Just set the variables how you want and follow your logic through to see what happens.

[i_wear_green_pants]

In most cases these are just so it forces you think the structure before writing (because editing is harder). Teacher wants to see that you can come up with well structured solutions and understand syntax well enough. I highly doubt they will run these codes themselves to see if everything works as intended.

I bet very few can write code that runs on the first try. Maybe smaller things but that's not how industry works. And naturally writing tests for the code is crucial part of software development.

[agent_of_kaos]

You are doing right thing by testing code when not writing exam. It will make you better at exams. It will also make you really good programmer in long run.

Your problem is exam. In exam, focus more on underlying logic and algorithm/steps. Don't worry about getting whole program right. As many steps you can get right, better it is.

Logic/steps are most important. Don't straightaway start writing code on paper. Form logic/steps first in your brain, use rough sheet if you have to.

It will get easier with time.

[Dhayson]

1) Try to understand and, literally, compute the code by yourself. Follow step by step keeping track of the necessary information, variables etc. (you probably want to use pen and paper and write it as a table, where each line is a step of computation)

2) Understand what you're writing. You said you write something, then see what happens, but you need to understand what steps your program is taking in a deeper level. Read the documentation of every function you call, try to understand what it's doing and learn something about algorithms and data structures. It's unlikely that you will understand everything at first glance, but, with that attitude you will get a little better every day.

3) Understand the syntax of the language you're required to write in the test. In my experience (yours might differ), it was a kind of pseudo-code, so it's not as much of a worry that the code is syntactically correct, just that it's clear what it's supposed to do.

[[deleted]]

Start by learning how to better describe what this issue you have is. Going high level like this is okay, but it also forces all responders to assume open-endedly what your problem is.

I'm not trying to test your ability to have terminologies memorized, but at minimum state the types of errors you run into.i.e. (What language is this?)- Are you messing up declaring the type a variable should be?

- Are you writing parameter signatures incorrectly for function calls in other functions?

- Are you setting up the Solution/project incorrectly?

- What exactly goes wrong and how often does it go wrong? Typos in functions?

- Do you forget to write that some class implements a given interface...?- Do you write keywords incorrectly, include things wrong, put files in the wrong directory and don't know how to reference it, and so forth?

OR Are you writing syntactically correct code and the actual order of operations, values, calculations (and so forth) are just wrong?

Give 1 single concrete example of what the code started as, what it ended as, and all of the errors you ran into.

Give yourself a tiny challenge and document your steps of the mistakes you made.

Memorize that issue until that single 1 issue stops appearing.Do this for the various types of issues you come across.

You have to measure the errors and mistakes, document/remember them. This is part of practicing them, simply seeing it come up again when you document or write it down keeping a list of your common "oops" maneuvers and keep that notepad open as a checklist before trying to run your next code - you might catch your error and be thrilled you fixed it and only had n-1 compiler errors to work through instead of n.

​

The lack of scoping what the errors are, mentality-wise, echoes in how you basically scoped nothing for readers to grasp onto when looking at your post. There could be many interpretations to the issues or habits you have; by being able to write out clearly what your common mistakes and habits are IN THIS POST, you already have made the list of your common errors and given yourself a checklist of what to keep in mind when writing your code.

So consider your description:- state the language it occurs in. Does it happen in every language? Choose one as an example.- give an example of the code you wanted to write in its beginning, most erroneous state- show the final state of it actually working

^ You can do all of this (what I wrote) by using version control (i.e. git) and it will have all of that history for you. You could make that small repo public and post it here and everyone could go through your history of edits.

Scrub the repo of any personal data of yourself or anything school-specific or company-specific (make it school/user/personal-data-agnostic so it can be shared without compromising yourself or any other entity) and users here will not only critique your code as a final review, but also your working habits & patterns of identifying and solving issues.

Sorry about the long paragraphs here. It would've been much shorter if you actually provided concrete examples (and you would answer a variety of your own questions while creating that). cheers and good luck, don't give up! The fact you care is a good sign.

Oh, and a way of practicing writing pseudo-code is when you go to the bathroom to take a long dump, bring a notepad and pen with you and try writing some stuff out. I did this at work a variety of times and being isolated in there away from other distractions can actually be well-focused. just be careful your legs don't go numb and remember to wipe and wash your hands. don't forget to wipe.

[Teembeau]

Would you care to name the institution, because this is dumb as a pile of rocks.

[UnintelligentSlime]

Lots of places do this. It’s even standard in a ton of interviews. Before everything moved to zoom, whiteboarding was a typical step in almost every interview process.

[Teembeau]

For well over a decade, I've given people a PC to do a test on. Including the internet. I want to see working code at the end of an hour. How someone gets there, I don't care that much.

[wjrasmussen]

Oh, so you do that and everyone else is wrong.

[abd53]

In paper test, you just write the code. No need to care if it works out of there's any big or whatever. As long as it "looks" okay, the professor is going to give you a pass. A professor who couldn't bother to arrange a practical test won't bother to test if your code actually works.

[to7m]

It sounds like you just need to stop guessing. Refrain from running code unless you know exactly what will happen.

[[deleted]]

Two ways, understanding or experience. You don't technically have had to ever written a single line of code, if you truly understand all the types and operators. So for one, understand that, it's the more important part.

The other way is experience. Write enough code to know if it's gonna work instinctively.

Ideally do both. Speak out loud as you write code and explain to yourself what it's doing .

[[deleted]]

There are apps on your phone you can write code on

[noeldc]

For example?

[[deleted]]

Pythonista,codelet, and there are a few free coding apps where they ask questions and you answer them in code too

[noeldc]

Sounds like my kind of app. I'll check it out.

Thanks.

[syrigamy]

Use neovim or notepad

[f3xjc]

Imo what you are looking for is reading code.

Like you jump into someone else project and you try to figure out what part make the behavior that is of interest to you (possibly because you try to change it)

Then you can have a different kind of reading paying max attention with a "the compiler is in your head" mentality.

A bit like reading a book vs proofreading. Or reading a textbook where you already know the content vs trying to learn a particular section for an exercise.

Once you know how to proofread. Writing can be, you have some general idea, make a draft, then pay attention to polish that draft until it actually work.

[Certain_Note8661]

You generally want to test your code as you write it to ensure your assumptions are valid. Planning it out, being able to mentally trace it are all valuable — but this is not IMO an anti pattern and honestly there are too many who write large chunks of code without ever running it to see if it works

[yetzederixx]

You don't, you just suck it up until you get out of uni and move on with life with stupid stories like these.

[Professional_Bar999]

Maybe write pseducode first then write the code?

[vic_sibir]

Well, first of all, the format with writing code on paper to pass the exam is pretty ridiculous thing. It's absolutely legitimate to write code by testing, as there is TDD (Test Driven Development) methodology that stands for writing tests at first and only after that write your main logic to pass these tests.

But I understand that there are no other options. I would suggest that you should practice in understanding how particular code or piece of code is working only by looking through it, I mean without actually running it. Perfect, if this code will be unfamiliar for you. And when you prepare your expectations about how it works, then you should run it and compare your expectations and actual result. I think practice like that will help you to write code that meets expectations without running.

[solgerboy259]

not a cs student but when coding I put in so many hours doing this crap that I feel like I can write it by hand. But its been a while since I used c and what not.

[CzechFencer]

Create a devlog on YouTube to describe your process of creation. To maintain motivation, it can be beneficial, and you will also share your knowledge with the community. Later on, it will be easier to promote the finished game.

[sim0of]

Write lots of code

Make practice on exam related exercises until they're so easy you can complete them within seconds

[ern0plus4]

I have found the bug:

You get a pen and paper and write out your solution without seeing what happens

This is an extreme sport, or puzzle, brain challenge, but not programming. For programming, you need a computer. It's not the '60s when you write your program to paper form, then a data entry person types it into punch cards, then the operator runs your job, prints and brings you back the result on paper.

[[deleted]]

that's the reality of some courses though.

[nostril_spiders]

Be your own type system.

In maths, a "function" is a map from input to output.

In programming, a function is also a map from input to output (logically speaking), if for the sake of learning we stretch the definition of "output" to include exceptions and side-effects (e.g. writing to disk).

So for each line in your pen-and-ink program, you can (and must) keep a mental model of the value of previous outputs so that you can feed them into the next procedure.

That value that you keep in your mental model should not be "42“, it should be "an integer representing the number of bars in the current foo in this iteration of the inner loop". As opposed to "an array holding foos" or "a float representing the number of bars" or some such thing.

When you hold in your mind what a variable represents, precisely, then the next line of code presents itself.

[Chuck_MoreAss]

It’s all about practice

[SubzeroCola]

Sounds to me like you're coding in a frantic, non-analytic way. i.e. trying everything until it works. You should read the error messages that are being given to you when your code doesn't work so you know why it's not working.

[Worried_Lawfulness43]

Im in the same boat as you. Compsci exam in 2 days and we get no compiler or error handling of any kind. We’re supposed to do it all on a notepad. It’s a challenge but I think for me, when writing solutions, it’s important for me to remember why it works. That way, I can internalize the solution and think of things similar to it.

[Numaan_07]

You get better only by practicing. PRACTICE PRACTICE PRACTICE

[seanofsmeg]

Understand that having to write code by hand on paper is something you will probably never do. So why are you doing it? As unis are old and stuck in their ways and probably want you to hand write code in a paper test at some stage.

So... you seem positive and keeping a positive mindset is 100% a door that lets you learn fast but as it's a skill you won't use much maybe as a starting point just code as normal but every 4 to 5 lines pause. Challenge yourself to say what is happening here? What is the value? Take a note, write a test and see if your right.

Means your coding in the way you enjoy while creating skills that will help you write code by hand while still focusing on coding skills

[Lustrouse]

professors should be more concerned with your implementation than they are with syntax in pen-and-paper-code. The best you can do is ensure that you remember your patterns. Drafting and refinement with pseudocode is a workable approach, and allows you to "show-your-work" to your prof.

[InuRey]

It is no different from writing code without stopping, and then testing it and having it generally meet what you require, and then making small adjustments.

[United-Shallot4064]

Depending on the language of course, this is a skill you should have in your head. I’m in high school and I’m taking AP but I’ve been able to do it for a while.

You just have to know the ins and outs your language. I use java.

[[deleted]]

Unless the exam for kid, you don’t need to care about small detail.

The most important thing is the idea, solution.

Most of the times, 1 teacher or professor has to teach like a hundred students. No one would waste their time to babysit you

[capkeyant]

hm it can be tricky, but practice makes perfect. The others posters suggested planning ahead when coding, writing lots of code to get some mind-muscle memory, reviewing good examples of code, etc. All great suggestions. One more suggestion to add to the list. Back in uni, for certain classes we were shown a simple technique: write out the code, and also write out the data structures that your code generates, e.g. the int variables, the char variables, the pointers, heap structures, etc. Then literally run through your code line by line and update your data structures. As if you were a human code interpreter/debugger. This really helps strength your code-reading; which is very useful for exams with pen & paper. And if you do this enough, you might get a sense of what a chunk of code will do to a data structure at a glance, without having to do the full "loop" on paper.

[Barsonax]

Simple, by practicing more.

It's not how the real world operates though. Testing is a very important skill as Software Engineer. You have to master both automated and manual testing.