[ambrop7]

I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test. Writing tests feels like the most wasteful and possibly harmful thing to me (like by people forcing dependency injection etc. where otherwise unneeded).

I don't really know what to think of the situation? Is this how it has always been? Do most software engineers really have no idea what they're doing?

[MaulingMonkey]

> I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test.

Or you may be using a different definition of "mostly bugless" than the rest of us.

I do gamedev. The ability to patch post-release is not a given, even today, for all platforms. Crashes, corruption, progress blockers, etc. are all VERY BAD in this environment.

I see bellow you're writing network code in C. I don't suppose you've done any fuzz testing? Run with address sanitizer? Static analysis? We live in a world of exploitable 1-byte buffer overflows. Maybe not such a big deal for a throwaway blog server, but perhaps a bit scarier if you might be facing HIPAA fines, or running industrial equipment.

A very important note here: Mostly bugless as far as you're aware and mostly bugless in actuality are two very different things. Without testing, I'm not sure how you can have any confidence that you're in the latter camp.

[ambrop7]

For my hobby projects I admittedly don't do much testing - simply because no one is paying me to. Only in rare cases do I intentionally write a test when something seems complex. And I do run address sanitizer etc. where that can reasonably be done (e.g. not on microcontroller code). Anyway my point is, my code has considerably less bugs than what you'd get from reasonably proficient programmers even if they DID write tests.

For example, I'm currently writing a TCP/IP stack for embedded systems [1]. While it's not quite complete yet (misses some essential code like fragmentation and congestion control), I'm very confident that it has (and will have when complete) much less bugs than related portions of lwIP; see for yourself all the bugs I've found in lwIP [2].

Again feel free to find bugs in my code. I very much appreciate people pointing out bugs, as it helps me make even fewer bugs :)

> We live in a world of exploitable 1-byte buffer overflows.

Indeed. But buffer overflows are so easy to avoid, just don't write over the end of the buffer. I doubt I've done a buffer overflow in years. The bugs that I do make, are much more complex.

[1] https://github.com/ambrop72/aprinter/tree/ipstack/aprinter/i...

[2] https://savannah.nongnu.org/bugs/index.php?go_report=Apply&g...

[TylerE]

How do you KNOW your code is working and bugless?

[ambrop7]

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes). - Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code. Often assertions are involved (which all have to be proved).

[jacques_chester]

> Play around with the program intelignetly and observe no bugs

What if the computer encoded your knowledge?

> Don't call it done until you haven't proven to yourself that the code has no bugs.

What happens when the software changes? Do you repeat every single desk-checking exercise to ensure nothing has broken?

Do you even remember every click, every experimental input?

Can you prove that you do?

> This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code.

I trust that smarter developers than me are smarter developers than me.

But I am dumb. I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct.

But my mental simulation is frequently wrong. So I wrap myself in explicit statements of what I think the code does. Then I make those explicit statements executable. And then I run them frequently.

And frequently, I realise again that I am dumb and I should leave the flawless coding to others.

[ambrop7]

> What if the computer encoded your knowledge?

> Do you even remember every click, every experimental input?

> Can you prove that you do?

I agree some tests are a good idea depending on the project. Doesn't mean I have to like writing them!

> I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct.

I try not to assume things until I've constructed associated proofs in my mind (and sometimes written them into comments). In fact keeping in mind what you've established (proven) and what not is a very important thing. Most of the bugs I've done are because I've simply forgotten to think about / prove something.

It's a completely different way of programming!

> Then I make those explicit statements executable. And then I run them frequently.

But I prefer to write down these explicit statements in the code itself, often as assertions. I can then prove them right on the spot!

[TylerE]

You know, I used to be like that. Then I had the revelation that in the time it took to click test something 4 or 5 times I could write test code that could click test in less than 100ms forever.

[crpatino]

> Play around with the program intelignetly and observe no bugs

That's the most sophomore thing I have read in a long time!!!

Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the office.

[ambrop7]

BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.

[joevandyk]

Probably means http://www.merriam-webster.com/dictionary/sophomoric

[Macha]

Sophomore is the name of the second year in American high schools, so he's basically calling it an comment someone inexperienced would make

[ambrop7]

Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.

[lisivka]

Just compare web design before ACID and after ACID. All browsers had working code, but web design was nightmare.

[lisivka]

How you prove to your peer that you done all of above? How your code is able to pass peer reviews??

[ambrop7]

Well, I haven't claimed to be able to to that, but to write mostly bugless code :) Though, writing insightful comments in the code helps. If anyone has doubt, you explain in a friendly way why they're wrong (if they are). Though, not all reviewers will study the code suffciently to find possible bugs, and also many findings are not the right/wrong kind but more about style/architecture.

[jasonm23]

Since you're actually writing tests (you say you're doing checks, which are effectively tests.) Why not just add them to a test suite?

You win twice, or more.

You get proof of the assertions you're making to your peers, you get regression tests to cover your code when it's being refactored, you also get to strongly document the intent of your code so that others can know it deeply, relatively quickly.

See devs like yourself who claim they aren't writing tests, but in essence they are, the only difference is they're not persisting their tests, and losing their value beyond initial validation of the correctness of the code.

[lisivka]

I also doing all of that AND test cases. However, I never use debugger. :-/

[lisivka]

Your performance as programmer is poor, but as QA you are excellent.

[ambrop7]

You mean me personally? What makes you think so?

[lisivka]

Because you said that you can test program manually faster than write automated test case for it. I'm opposite. Human must think, computer must work.

[ambrop7]

I can write tests. I just prefer not to, for the sake of productivity and preserving sanity. If you disagree that I can write mostly bugless code, I challenge you to find some bugs in my open-source projects :)

https://github.com/ambrop72/aprinter

https://github.com/ambrop72/badvpn

[lisivka]

Your code will not pass my peer review. ;-)

[z92]

If it works, then it works. That's the point.

If I don't use it because it doesn't pass my peer review process, whatever that might be, then my competitor will use it and come up with a faster/cheaper solution than my one.