Live data from Hacker News

Logical fallacies in software engineering

artur-martsinkovskyi.github.io

121–130 of 151 posts

Re: Logical fallacies in software engineering

#121
post #37

Earlier quoted context omitted.

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason. The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter…

I'd add to that the predilection for hiring young engineers and overlooking older ones. While it's true that older ones can get stuck in past practices, they also recognize things that have been tried before, seem like good ideas, but just don't work for non-obvious reasons. For example, implicit declaration of variables in programming languages. A strong team will have a mix of older and younger engineers.

Language design is its own thing with its own body of knowledge and experience. Of course, often times new languages were designed by those who could engineer their compilers and interpreted, leading to lots of mistakes that would be more apparent to a seasoned language designer.

Re: Logical fallacies in software engineering

#122

Earlier quoted context omitted.

This touches on another thing, which is “Thing X is known to be imperfect, Pat says thing Y is better. Nobody else on the team has tried Y but we have all these aphorisms like ‘no silver bullet’ that lead us to think Y can’t be that good.”

When somebody presents me with a new shiny solution to a hard problem describing it as a silver bullet, I immediately become suspicious. So, it depends a lot on how good Pat says that Y is.

Do these people actually say, “this is a silver bullet” or is that your interpretation? Does this mean is pat undersells you on Y you might be more receptive?

Re: Logical fallacies in software engineering

#123
post #90
post #65

Earlier quoted context omitted.

>This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend e…

Good example, was that from Effective C++? Widely repeated, yet wrong.

>Widely repeated, yet wrong.

Not right, either.

Personally, I wouldn't inherit from a class that didn't have a virtual destructor unless I had a good reason. The point isn't whether it is right or wrong. Stating it as wrong is as problematic as stating it as right. The point is that whether it is OK to do it or not is an opinion, not a fact, and should be discussed as such.

Re: Logical fallacies in software engineering

#124
post #45

Earlier quoted context omitted.

May I add to this with a third: difficulty in creating a strong system of mentoring? Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies). In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that…

In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning. I have mentored a few people during my job and generally feel that my time was wasted only if they don't take initiative to learn themselves. Many a times I leave a crucial thing out of the answer and ask them to try to find for themselves as teaching is not about giving…

> In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning.

I wish my personal experience was the same, but it has been the polar opposite. In my current and previous roles, there is always too much work, which causes management to pressure development for deliverables, which results in juniors getting pushed aside. It's a terrible cycle and I have no idea how to improve it.

Re: Logical fallacies in software engineering

#125

The "nirvana fallacy" is definitely one I commonly see on Hacker News. The ease with which people jump from "thing x is imperfect" to "thing x is worthless" is mind-boggling. This is usually coupled with familiarity bias, where the flaws of any existing technology are discounted vs. those of a new technology.

I had a few double takes where "flawed" was used as a takedown for entire concepts and their backers. What in this world isn't flawed?

Re: Logical fallacies in software engineering

#126
post #48
post #37

Earlier quoted context omitted.

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason. The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter…

Mentorship at the highest level (principle to senior and below) is desperately lacking. I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting. I pair programmed for 3 months (which I consider apprenticeship / live action mentorship) with someone who was a way better engineer than me at my first "career job" out of college. I learned more in…

> I learned more in those 3 months about software engineering than in my previous two.

Do you mean you learned more than you did in 2 months of school? Did you drop "years" as the last word? Did you mean it wasn't a great experience because you could have learned what you did in 2 months instead of 3?

Re: Logical fallacies in software engineering

#127
post #90

Earlier quoted context omitted.

Good example, was that from Effective C++? Widely repeated, yet wrong.

I am not following. Sure you can, sure it may work now, but it seems like something that is a recipe for future bugs being created?

It only causes problems if you try to delete it via a pointer to the base class. If your base class doesn't have any virtual functions then it's very unlikely that anyone would ever write code which tried to do that anyway, so it's not an issue.

A base class with virtual functions but a non-virtual destructor is what'll get you into trouble down the road.

Re: Logical fallacies in software engineering

#128

I'm constantly fighting the sunk cost fallacy with managers, I'm surprised it hasn't been mentioned, or maybe it has been but in a different form?

"Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)" WRT software projects, what's the opposite? When I bring up sunk cost, the assumption is that I'm lobbying for wholesale rewrite. In some (not all) cases I am - take the lessons learned, maybe some algorithms, data, whatever, and rebuild. The standard rejoinder to t…

>"what makes you think you're so much smarter/better than the previous team?"

You hopefully learned from the problems they encountered, which they likely didn't know about when they started.

Re: Logical fallacies in software engineering

#129
post #5

"both at perception, dexterity and mind work" Off-by-one error ;-)

Isn't this correct in English? The equivalent on my first language (Portuguese) is very clearly wrong, but I've seen the English version in more than one book.

It's definitely wrong. But it is blasphemous to even believe that there can be right or wrong in such matters.

Re: Logical fallacies in software engineering

#130

Earlier quoted context omitted.

In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning. I have mentored a few people during my job and generally feel that my time was wasted only if they don't take initiative to learn themselves. Many a times I leave a crucial thing out of the answer and ask them to try to find for themselves as teaching is not about giving…

> In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning. I wish my personal experience was the same, but it has been the polar opposite. In my current and previous roles, there is always too much work, which causes management to pressure development for deliverables, which results in juniors getting pushed aside. It's a terri…

This is not necessarily the opposite. It is perfectly possible that the knowledgeable people you've worked with actually wanted to pass it on. They just weren't given the time to do it.

You should be angry about overtight deadlines and companies who live by those, not to the actual people. This also points to a possible solution for you: switch companies.

Post reply on HN