TDD. 100%.

Design on paper first, and then convert those paper thoughts into tests. As you're writing your tests out, you'll think of edge cases and it will take a second or two to write a test header for it.

Before you have a line of code, paper and pencil are your best friends.

Thanks How do you reason about program? Do you workout examples by hand ? Or prove it formally by mathematics

(Not the person you responded to.)

I will actually execute the program in most cases. Most of the development I do is in the context of a web request (server) or browser DOM (client) so running some quick snippet of code might be as simple as initiating a request from my browser to see what the server does or interacting with it in some other way which triggers the client-side stuff.

You're going to have "something you start with" (input) and "what you want it to be" (output). Understanding these things will go a long way to reason out what you need to actually do to accomplish your goal. Usually a program's "goal" is to "output the correct thing" and the programmer will have to know what "correct" is.

Certainly no formal proofs and I usually work things out "in my head", as it were, because it helps me to understand the problem that I'm working on. See also "rubber ducking" (https://en.wikipedia.org/wiki/Rubber_duck_debugging). It might help to try to build a small program to better wrap your head around "what" programming is.

I don't do formal proofs, or use maths for proof. Most time the math is overkill. Yes I can show that indexing field [x,y] improves speed, but bench marks work here better than math.

I just think of the thing I want to build, and I break it into smaller and smaller bits.

I don't write code on paper.. just the "what do I want to happen".. super high level.

What does the comment "test your design" mean? Are you mostly referring to eliminating potential coding bugs, or are you referring more to "did I build the right interface/UI/UX to solve a particular problem?"

Eliminate potential bugs in the program earlier in the process. I.e to avoid programming by coincidence

Until humans come up with a better way of building software, something like TDD seems to be the best way to build correct software.

Keep in mind though that tests are also software built by humans that can be wrong too, sometimes giving you false confidence about correctness.

The best test of a system is always real-world usage.

TDD is the second best method.

The first is developing good habits—list out all edge cases and just manually test it out. If you work in a team, the PM, developers, and QA can brainstorm these edge cases together. It’s these simple things that make a huge difference and you’d be surprised how many teams don’t do this.

Prototypes. When you have a design element in mind, you prototype it. This may mean writing multiple programs before producing the final program(s). Using the same language for your prototypes as for your final (target) system mitigates the concern there because you can take components of your prototypes and turn them into modules/libraries used by the final system.

Testing. Always test the system. Automate every test you can so you can trigger them and get a report once completed rather than wasting your time clicking buttons or typing in commands.

I don't design or test, that sounds like some stuff you'd be forced to do in school. It's stepping stones, I don't know where the next one will be but I know ill work it out when I get there. I build in a pretty modular, loosely coupled way, the correct structures reveal themselves as you go, you'd need to be a Tesla level genius to work it all out from the start and not make mistakes.

I handle the things i'm aware of in the code, and I cant test for things i'm not aware of so it makes no sense to me. Generally once I've built something that's it bombproof, nothing stops working because there is no reason for it to.