My CS professor just said that your code should always work the first time you run it because you should work out all the details and test cases on pa...

My CS professor just said that your code should always work the first time you run it because you should work out all the details and test cases on paper beforehand. This approach seems tedious compared to going straight into trial and error like I usually do. What does IQfy think?

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 3 weeks ago
    Anonymous

    your cs professor is a boomer

  2. 3 weeks ago
    Anonymous

    measure thrice cut once
    in all fields

  3. 3 weeks ago
    Anonymous

    i don't even know how that is humanly possible, noone's fricking code will run the first time. trial and error is comfy and everyone does it. everyone will fricking overlook details the first time they run the code, it's not a sin ffs.

    • 3 weeks ago
      Anonymous

      the idea is to write your test, have them all fail since there's no new code yet, then keep developing your code until all the tests succeed, at which point you're supposed to feel confident it's bug free and working until all the possible parameters

    • 3 weeks ago
      Anonymous

      >noone's fricking code will run the first time
      mine usually does

    • 3 weeks ago
      Anonymous

      skill issue

    • 3 weeks ago
      Anonymous

      It's possible, especially for school projects

  4. 3 weeks ago
    Anonymous

    Your CS professor is thinking of a time when the most complex programs were measured in KBs

    • 3 weeks ago
      Anonymous

      Not him but one of my teachers did it because, in his words, 'no one is smart enough to be able to just write code without working it out on paper first'. Though to be fair he was a pajeet, that also liked b***hing about machines taking indian jobs. This was probably 5 years ago or so.

  5. 3 weeks ago
    Anonymous

    The truth is somewhat in the middle. What he's trying to say is that you should have a coherent overview of your program before you start shitting out technical debt and code that will end up having to be replaced.

  6. 3 weeks ago
    Anonymous

    there's no once size fits all method to software development. If I'm working on a large feature I'll code a proof of concept first, then write a design document with the fleshed out details for my peers to review and then implement it. I don't do test driven development (writing the tests first), mostly because it can be a pain in the ass to mock things in complex products with lots of external dependences. I usually write my code until I get something working then try to cover what I can in tests

    in the end it doesn't matter what you do as long as you deliver code in a reasonable timeframe that doesn't break

  7. 3 weeks ago
    Anonymous

    ask him how many times hes ever worked private sector

  8. 3 weeks ago
    Anonymous

    This is easily done by wrapping your entire software around a unit test that expects it to work

  9. 3 weeks ago
    Anonymous

    Your professor is right, it would be quite tedious to input the program again with new set of punched cards.

  10. 3 weeks ago
    Anonymous

    Dude it's called a hyperbole and it's a rethoric tool you midwit.
    Obviously you cannot have your code run perfectly every time, but unless your problem is hyper trivial you should always first think about how you can solve it, take note of the existing code/libraries/Apis and dependencies and their requirements, quirks and whatnot and then formulate a decently laid out concept, then structure it into self-contained and logical subproblems and finally solve those. Also think about edge cases and such and properly address them. If you got that then 9/10 you shouldn't run into semantic problems, and if you use a syntax checker in your ide then it should work.

    You don't actually have to make the notes by hand, some quick notes in a comment block is sufficient, and if the problem isn't particularly hard and you can manage you can just do the entire process in your head without taking notes at all.

  11. 3 weeks ago
    Anonymous

    you need to strive for it. but by and large errors are inevitable

  12. 3 weeks ago
    Anonymous

    CS professors are generally pretty poor programmers. After all, CS is basically math.

  13. 3 weeks ago
    Anonymous

    that’s moronic. sure try to write your algorithm where you understand what’s happening but using print statements to debug is way more efficient

  14. 3 weeks ago
    Anonymous

    One way of writing bug-free code is to never write code at all.

  15. 3 weeks ago
    Anonymous

    >what does IQfy thing?
    waterfall agile coding programming

  16. 3 weeks ago
    Anonymous

    most professors are wankers who never actually worked in the industry
    I shit on their opinion
    t. 10 year experience as a C++ code monkey

  17. 3 weeks ago
    Anonymous

    >What does IQfy think?
    So... I'm a CS PhD student, and while I haven't finished my thesis yet, I think at this point, I can say I'm qualified to advise undergrads. I will offer my perspective here.

    What your professor has suggested is not reflective of how anyone in industry writes code. As you have noted, it is tedious, and a lot of companies are willing to play fast and loose to get software out before their competitors. In many cases, these products are a bit buggy, and they deal with maintenance later.

    Sometimes, it may make sense to not develop things fast, because a bug in production may cause catastrophic results. So you'll want to make sure it works for certain before you release. In these circumstances, you might ask, "Is my professor right? Should I work it all out on paper first?" And I'll answer... probably not. Bugs come from a wide variety of sources, not all of which can be formally proven. You can work out an algorithm on paper before implementing it, and formally prove the correctness of that algorithm, but your program is not just your implementation of the algorithm.

    Just typing things out, you will make mistakes. Sometimes, those mistakes can be caught by the compiler. If you make a typo, you should hope that the variable you mistyped is not another variable within the same scope (i.e. swapping i for j in some loop), so you can at least get an error for an invalid identifier. Sometimes, however, the language is not compiled and tries to just chug along doing the wrong thing instead of ceasing execution of the program (i.e. JavaScript). Sometimes the language lets you do dumb things like using = in an expression where == is used for comparison, and you end up mutating things when you didn't intend to. Sometimes the error isn't even your fault, but that of a coworker implementing a different function.

    You can't rely exclusively on formal proofs. Someone, somewhere, is going to frick up anyways.

    • 3 weeks ago
      Anonymous

      >You can't rely exclusively on formal proofs.
      The problem there is that what you can formally prove (typically by construction) is that the program conforms to its specification. It's much harder to prove that the specification is what it actually needs to be, and the spec often changes as people understand more about what they want the program to really do. There's also a real sense in which the specification is the real program, not the code that is generated from it; that's merely a compiler output.

    • 3 weeks ago
      Anonymous

      >So... I'm a CS PhD student
      Thanks for the heads up, and saving me from having to read your pompous blog post.

      • 3 weeks ago
        Anonymous

        >So... I'm a CS PhD student
        Stopped reading right there.

        Kek

    • 3 weeks ago
      Anonymous

      >So... I'm a CS PhD student
      Stopped reading right there.

    • 3 weeks ago
      Anonymous

      >So... I'm a CS PhD student
      lmao bro what is wrong with you
      you know 2 years of experience is worth more than a PhD right?

    • 3 weeks ago
      Anonymous

      upvoted sir!

  18. 3 weeks ago
    Anonymous

    I think targeting a specification is more important than writing stupid test cases on paper. People who say that the unit tests or the code itself are the documentation are wrong.

  19. 3 weeks ago
    Anonymous

    What horseshit. Dude probably never “broke the build” in his life, because he never committed anything sizeable to a code base. Is he trying to hell you to use a strongly & statically typed language where you can pretty much be assured it will run if it compiles? It’s run, but not necessarily give you the functionality you want.

    > t. Old fart that’s been doing this way too long.

  20. 3 weeks ago
    Anonymous

    I always try to make a plan on how I should build the code but getting it to run first try when you are doing 300+ lines of code is not gonna happen. your cs prof is a boomer i gotta assume

  21. 3 weeks ago
    Anonymous

    It is far easier to make an incorrect program correct than it is to write a correct program in the first place. And anyone who thinks otherwise simply hasn't waited long enough to find out how incorrect their programs actually are.

    One of the beautiful things about our field is that is you try something and it crashes, you have lost literally nothing except your time. No materials, no widgets you can run out of. Just $0.0000001 of electricity that is dwarfed by the HVAC it takes for you to sit comfortably wherever you ran the code. So, crash away, I say.

    • 3 weeks ago
      Anonymous

      you must be the guy who compiled my ungoogled-chromium-bin

  22. 3 weeks ago
    Anonymous

    Coding is dead dude. Why are you wasting time in CS???

  23. 3 weeks ago
    Anonymous

    There's a reason why he's a professor and not a developer. Those who can't do, teach.

  24. 3 weeks ago
    Anonymous

    Your professor punched cards.

  25. 3 weeks ago
    Anonymous

    your professor is out of touch. many such cases with academia.

  26. 3 weeks ago
    Anonymous

    It’s the comsci equivalent of theory vs application. Sure your professor is smarter than me for understanding every nook and cranny but my application actually gets used by people.

  27. 3 weeks ago
    Anonymous

    You should be able to do both.

    I was taught to see it as hacking vs architecting

  28. 3 weeks ago
    Anonymous

    try working on a codebase that takes half an hour to build i.e. not your homework/toy programs

Your email address will not be published. Required fields are marked *