Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmers should never trust anyone, not even themselves

carbon-steel.github.io

Post reply on HN
Print view View original

101–110 of 163 posts

Re: Programmers should never trust anyone, not even themselves

#101

Post by randomdata »

bluGill wrote: post #98
randomdata wrote: post #87

Earlier quoted context omitted.

The first box on the testing checklist states that the test should first fail. I wonder how they managed to not test anything while seeing the tests transition from failure to success.

From the GP: mock data being manually manipulated by the test gave the result of test expected. These tests are easy to write - your mock returns something, and then you verify that the API does nothing (thus the test fails), then returns whatever the mock does and the test passes. These tests are easy to write and they do fail until code is written. However they are of negative value - you cannot refactor anything a…

I can't imagine writing a function that is nothing more than an identity function would be easy to write (unless it was explicitly intended to be an identity function, I suppose). There must be some terrible gut wrenching feeling that goes along with it, if nothing else? Frankly, I don't understand how this situation is possible in practice, but perhaps I misunderstand what is written?

Re: Programmers should never trust anyone, not even themselves

#102

Post by protomolecule »

pcwelder wrote: post #6

High quality article with some new advices. > Read more documentation than just the bare minimum you need I wish I practiced this before, I'd be as good and quick as some of my brilliant colleagues.

I usually do, but not a long time ago after I've read docs on boost::spirit, gpt4 suggested a trick with which I could've come up myself but I failed to connect two different pieces of documentation.

This left me wondering if reading the docs thoroughly is still a good investment.

On the other hand, having some level of knowledge of a library saves me some time since I can often write things faster by myself than explaining gpt4 in more and more details what I need.

Re: Programmers should never trust anyone, not even themselves

#104

Post by superidiot1932 »

n4r9 wrote: post #40
psychoslave wrote: post #16

> verifying code correctness is impossible Somehow, taking into account the state of our industry, yes. But this is not an absolute truth. I mean, we do have the theoretical frameworks and even tools to come with solutions that allow to proof that code is correct. It’s just that mapping this "know how" with the "how to deal with the expected flow rate feature" is very uncommon.

> tools to come with solutions that allow to proof that code is correct I may be misunderstanding, but isn't part of the problem that these tools are themselves written in code and therefore subject to bugs?

There are verified compilers such as the compcert compiler and also ways to verify that a given binary does in fact correctly implement an specification

Re: Programmers should never trust anyone, not even themselves

#106

Post by bitwize »

kryptiskt wrote: post #48

I think "trust, but verify" (as mentioned in the article) is a much more useful motto than "never trust anyone". The latter isn't an useful attitude, if you took it seriously you would have carefully check or rewrite everything from the ground up. And then you'd either have to trust the hardware anyway or enlist in a course on VLSI design. "Trust, but verify" is much more practicable, at least if you don't feel the n…

"Trust, but verify" comes from the Soviet Union and is an example of Russian humor. It helps that the Russian words for "trust" and "verify" rhyme.

It really means something like "act like you trust the person, but secretly, don't trust them and double check that they've fulfilled their commitments". Putting on a smiling face and acting as if everybody was acting in good faith, while secretly expecting the stab in the back because you would do the same, was key to diplomacy in the USSR, even between departments of the same government.

Re: Programmers should never trust anyone, not even themselves

#107

Post by ramesh31 »

You do need a certain level of self confidence to actually get anything done though, and not get lost in analysis paralysis. The mantra goes "strong opinions, loosely held". Be prepared to vigorously defend your position, while simultaeneously being willing to immediately toss it aside in the face of overwhelming evidence.

Re: Programmers should never trust anyone, not even themselves

#108

Post by Spivak »

fatnoah wrote: post #95
kryptiskt wrote: post #48

I think "trust, but verify" (as mentioned in the article) is a much more useful motto than "never trust anyone". The latter isn't an useful attitude, if you took it seriously you would have carefully check or rewrite everything from the ground up. And then you'd either have to trust the hardware anyway or enlist in a course on VLSI design. "Trust, but verify" is much more practicable, at least if you don't feel the n…

> "Trust, but verify" Even though my entire career has been software, I was an Electrical Engineering major, so I have taken VLSI design (and even designed an 8-bit ALU). My first job was writing embedded software, and would frequently "trust, but verify" the hardware through the use of a logic analyzer. When I pulled out printouts from the analyzer to show the hardware team that the hardware had a bug, the surprised…

This is why blameless postmortems are such good thing.

Going one step further having a culture where finding a bug or defect in your own code/design is rewarded makes it so people aren't afraid but excited to talk about them.

Re: Programmers should never trust anyone, not even themselves

#110

Post by Spivak »

marcosdumay wrote: post #94
atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

> I've also seen instances where tests are written too early, using a data structure that gets changed in development That's as clear a signal that they are testing the wrong interface as you can get. Unfortunately, developers think of tests as testing code, not interfaces. As a natural consequence, they migrate towards testing the most complex break-down of their code as they can; it increases the ratio of code cove…

There's two kinds of tests I think developers are trying to write and I think both of them have merits. Writing a test for the code is actually totally fine so long as the reason that you're doing it is because you want to be able to depend on that and you need something to scream if ever changes.

I think starting with a test that the code does what the code does is actually a pretty good starting point because it's mechanical. And if you never end up revising that code, it can just live there forever, but if you do end up revising the code, those tests will slowly morph overtime into testing the interface. When you actually do your revision, you get a very clear signal that like hey this test that is now failing as a result of the change, clearly that can't be the important part.

Waiting for the change to see what stays the same I think is often more accurate than trying to guess what the invariants are ahead of time.

Post reply on HN