Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#201

Post by jimbokun » Mon, Feb 03, 2020, 6:22 PM UTC

skywhopper wrote: post #185

crimsonalucard wrote: post #174

Earlier quoted context omitted.

Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed. Have you heard of functional programming?

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relativel…

The state of the art in distributed programming is Erlang, which uses functional programming to enable levels of scalability very difficult to achieve with any other development stack.

This also applies specifically to the problem of lacking "infallible" infrastructure. Because of the largely stateless nature of an Erlang process, they can be killed, migrated to other machines, and quickly scaled up and down to meet changing demands.

Re: Things I Believe About Software Engineering

#202

Post by pmiller2 » Mon, Feb 03, 2020, 6:24 PM UTC

oarabbus_ wrote: post #194

crimsonalucard wrote: post #177

Earlier quoted context omitted.

I don't agree with 'most.' Our schooling and educational systems are very merit based. One could say that in the work place, success is uncorrelated with merit.

>One could say that in the work place, success is uncorrelated with merit. Do you truly believe this? In my career experience, success is highly correlated with merit. Sure, I have seen plenty of incompetence at high positions, and I've seen brilliant people who received little success in their careers. But overall, I'd say the correlation is very high.

I would be willing to bet that advancement to any given level correlates with a certain base level of merit. However, I would also guess that the higher up one goes, the thing that correlates best would be luck. I have no empirical evidence for this other than myself and what I know of people around me, but it definitely rings true to me.

Edit: what a coincidence this is on the front page right now: http://theconversation.com/huge-success-in-business-is-large...

Re: Things I Believe About Software Engineering

#203

Post by jimbokun » Mon, Feb 03, 2020, 6:32 PM UTC

knightofmars wrote: post #191

pc86 wrote: post #175

Earlier quoted context omitted.

Just make sure you're negotiating the thing you're supposed to negotiate. I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives. I'm all for asking thoughtful questions but if you have 2 years of experience at a different company in a different industry, saying you don't think Product X is going to make money doesn't really qual…

> I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives Oof. I'm a big supporter of questions not statements in these situations. I've witnessed people with this behavior, where a person makes claims and argues a point but doesn't have a clear understanding of the situation. They don't realize they're ignorant to a certain porti…

> Though in the latter case I suspect it is not wanting to be perceived as not having grasp of a situation or being perceived as lacking in knowledge.

Ha, amateurs! One of the best techniques for making an argument is to ask a leading question that challenges some unstated assumptions. Allows the other party to provide clarifying information. Or if they don't have a good response, that makes your argument for you far more strongly than directly asserting your position would.

So to further emphasize your point, nothing makes you look smarter than asking a really insightful question.

Re: Things I Believe About Software Engineering

#204

Post by hinkley » Mon, Feb 03, 2020, 6:32 PM UTC

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Margaret Hamilton's pedantry on the Apollo scheduler saved the mission, and possibly lives, when a low priority process started flapping. From what I understand nobody forced her to write the code that way but her own conscience.

We know that now, but it's an example of a rule that was not written in blood. Many are. Someone had an intuition and nobody died because of it.

Re: Things I Believe About Software Engineering

#205

Post by jimbokun » Mon, Feb 03, 2020, 6:34 PM UTC

jwr wrote: post #24

Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapa…

> This is why I am afraid of the hype behind self-driving vehicles.

Well, they don't have to be absolutely correct. Just a lot more correct than human drivers across a broad range of driving scenarios to justify replacing human drivers.

Re: Things I Believe About Software Engineering

#206

Post by takeda » Mon, Feb 03, 2020, 6:37 PM UTC

sacado2 wrote: post #88

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

And it's obviously not the developers' fault, but the clients/customers'. You want a 100% bug-free web browser? OK, so let's define precisely and formally what the browser is supposed to do. Then, you'll sign a very expensive contract, and in 6 months to 1 year, I'll deliver the software, with a formal proof it works as expected. Of course, the requirements won't change during the development process, and any update…

If you want to see extreme cases of this look at code of games. It's no wonder they are so buggy when released.

Re: Things I Believe About Software Engineering

#207

Post by Silhouette » Mon, Feb 03, 2020, 6:50 PM UTC

sacado2 wrote: post #88

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

And it's obviously not the developers' fault, but the clients/customers'. You want a 100% bug-free web browser? OK, so let's define precisely and formally what the browser is supposed to do. Then, you'll sign a very expensive contract, and in 6 months to 1 year, I'll deliver the software, with a formal proof it works as expected. Of course, the requirements won't change during the development process, and any update…

Your general argument seems reasonable, but it also doesn't necessarily contradict the GP's point.

If we're going to build something non-trivial that is correct, we first need to specify what a "correct" result would be, in some rigorous, comprehensive, unambiguous form. That in itself is already beyond the vast majority of software development projects, though not necessarily outliers like very high reliability systems.

That is partly because the cost of doing so is prohibitive for most projects. This is a common argument against more widespread use of formal methods.

However, it's also partly because for most projects the desired real world outcomes simply don't have some convenient formalisation. The potential for requirements changing along the way is just one reason for that, though of course it's a particularly common and powerful one. There's also the practical reality that a lot of the time when we build software, we're not exactly sure what we want it to do. What should the correct hyphenation algorithm for a word processor be? How smart do we want the aliens in our game to be when our heroes attempt a flanking manoeuvre? If you're a self-driving car on a road with a 30 legal limit but most drivers around you are doing 40, how fast should you go and why? Once we get into questions of subjective preferences and/or ethical choices, there often isn't one right answer (or sometimes any right answer), so how do we decide what constitutes correct behaviour from the software?

Re: Things I Believe About Software Engineering

#208

Post by boring_twenties » Mon, Feb 03, 2020, 6:57 PM UTC

dschadd wrote: post #162

AJRF wrote: post #154

> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?

Pragmatic Programmer and Code Complete are usually mentioned as classic programmer text books. I own both and have probably read 10 pages between the 2 books.

I haven't read Code Complete but I did flip it open to a random page around halfway through the book, and was treated to a page-long explanation about the fact that conditions in loops aren't constantly being evaluated, but only once at the top of each loop.

I think it's reasonable to simply assume the entire book is bullshit after that.

Re: Things I Believe About Software Engineering

#209

Post by faeyanpiraat » Mon, Feb 03, 2020, 7:10 PM UTC

prox wrote: post #93

jwr wrote: post #24

Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapa…

Cooper: Hey TARS, what's your honesty parameter? TARS: 90 percent. Cooper: 90 percent? TARS: Absolute honesty isn't always the most diplomatic nor the safest form of communication with emotional beings. Cooper: Okay, 90 percent it is.

Self destruct in 10.. 9..

Re: Things I Believe About Software Engineering

#210

Post by jdance » Mon, Feb 03, 2020, 8:18 PM UTC

antirez wrote: post #169

> There are many fundamental discoveries in computer science that are yet to be found. That's a strange claim. It could be, but there are large evidences that we discover most of the fundamental things immediately up to the 80s, and then the other improvements are kinda really incremental, a program from 1970 is not alien today. Technology of computing progressed a lot more than CS itself, a computer of 1970 kinda is…

I don't think we will sit at our computers writing code in the same way a hundred years from now. It just feels very inefficient to me, it's a good abstraction for now but better will come, new paradigms that probably look radically different. I personally would find the opposite claim rather strange :)