Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#191

Post by knightofmars » Mon, Feb 03, 2020, 5:23 PM UTC

pc86 wrote: post #175

pfarrell wrote: post #147

Earlier quoted context omitted.

> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate. I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and…

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 portion of information which they need to ask questions to learn about. This happens both with those with minimal experience as well as leadership. 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. Which is sad, as people who ask smart questions generally are the best leaders.

Re: Things I Believe About Software Engineering

#192

Post by TheCoelacanth » Mon, Feb 03, 2020, 5:28 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…

I think you're underestimating the amount of work involved in creating a web browser by multiple orders of magnitude.

If it really took a year to make a bug-free browser, we would have 100 of them instead of 0.

Re: Things I Believe About Software Engineering

#193

Post by SubuSS » Mon, Feb 03, 2020, 5:29 PM UTC

pc86 wrote: post #175

pfarrell wrote: post #147

Earlier quoted context omitted.

> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate. I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and…

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…

Whenever this happens (juniors questioning decisions which have a lot of context requirements that they don't have OR VPs from other departments questioning something core to my world) I look at it as a problem with myself not presenting the case in a convincing manner.

The junior engineer is probably trying desperately hard to apply something he read in a book somewhere or hacker new the previous day. You will have to invest time to tease out the differences, ensure they feel listened to.

The VP is probably trying to either catch you off foot to make a point he is itching to make to belong OR is trying to ensure you know what you are doing. Good senior folk build knowledge like a tree: Some branches are full and dense, some are bare - but overall they make up the whole tree. The bare branches here would be your core world and once they get a sense of you knowing what you're talking about, usually you should be fine. Bonus if you add to their knowledge without being defensive.

RE time taken for this: I look at it as future investments. If it is a junior dev in my team OR a VP who can actually impact my day to day life, it is worth building that relationship where they get to a trusting spot. If it is a random person, I might just agree / nod my head and move on to wrap up the conversation.

And yes there are bad actors everywhere - tough luck if it is the VP (happens), hopefully you can manage out the junior fella.

Re: Things I Believe About Software Engineering

#194

Post by oarabbus_ » Mon, Feb 03, 2020, 5:46 PM UTC

crimsonalucard wrote: post #177

jmull wrote: post #134

> Most measures of success are almost entirely uncorrelated with merit. A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems. A mistake you can make is to believe the the rules of merit that you believe are the same ones others believe, that the ones they state are the same ones they actually believe, that the rules don't depend on context, etc. It's har…

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.

Re: Things I Believe About Software Engineering

#195

Post by thewebcount » Mon, Feb 03, 2020, 5:49 PM UTC

crimsonalucard wrote: post #177

jmull wrote: post #134

> Most measures of success are almost entirely uncorrelated with merit. A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems. A mistake you can make is to believe the the rules of merit that you believe are the same ones others believe, that the ones they state are the same ones they actually believe, that the rules don't depend on context, etc. It's har…

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.

> Our schooling and educational systems are very merit based.

I'm not sure where' you're based, but that's certainly not the case where I live. I once worked for a company that made grading software. I quit after 3 months because they wanted to implement features like, "Teacher wants to be able to change grade to a specific letter, even if student's scores add up to a different letter grade." (In other words, even though this student received an "A" based on test scores, I want them to have a "C" instead. Or vice-versa.)

Re: Things I Believe About Software Engineering

#196

Post by mark-r » Mon, Feb 03, 2020, 5:59 PM UTC

SubuSS wrote: post #193

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…

Whenever this happens (juniors questioning decisions which have a lot of context requirements that they don't have OR VPs from other departments questioning something core to my world) I look at it as a problem with myself not presenting the case in a convincing manner. The junior engineer is probably trying desperately hard to apply something he read in a book somewhere or hacker new the previous day. You will have…

RE trying to ensure you know what you are doing. This reminds me of one of my favorite stories about Bill Gates: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Re: Things I Believe About Software Engineering

#197

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

groby_b wrote: post #172

est31 wrote: post #161

Earlier quoted context omitted.

> If you're an above average driver, a below average driver will ram your car unexpectedly. And there will be nothing you can do, because your reaction times are human. That doesn't require level 5 self driving cars, only brake assistants. > Also, you're likely not as above average as you think yourself to be. That doesn't mean that there aren't above average drivers. I'm not assuming I'm among them, but for them, dr…

It requires more than brake assistants. People are, in the limit, idiots (at least when driving). If you drive long enough, you'll see lots of really hair rising things - and the benefit for the above average driver is that the below-average drivers are off the road. The benefit to self-driving cars is not only that they are driving (hopefully) better than humans - it's also that they minimize the risk of completely…

The idiots you encounter are not all the same people all the time. And sometimes, you're someone else's idiot. You might not even notice when that happens.

All it takes is a moment of confusion, or distraction, or frustration. Or a chemical impairment. Or having a stroke. Or drowsiness.

Braking assistants are good, a self-drive function that has the goal of safely removing the vehicle from traffic--for operators that can suddenly no longer function at speed--would be better. Hitting a panic button and waking up on the shoulder with the hazard lights on is preferable to getting intimate with a pole or guardrail while the cruise control is set to 70 mph.

Our informational machine assistants would also be better with access to vehicle state and sensor data. Your navigation assistant could then tell you, if you are approaching an intersection with your left turn signal on, that left turns are not allowed, before you get there and possibly make a bad snap decision. The nav app on your phone doesn't know that you are signaling left. The GPS signal isn't quite reliable enough to pinpoint which lane you're in. It only knows the positions of vehicles whose operators are currently using the same app.

Obviating snap decisions by drivers should be a goal, because less thinking time means more mistakes. Mobile nav apps have gotten better at this, saying which lane you should be in, and whether destinations are on the left or the right, but they could still do better for in-vehicle improvisation, when the destination changes while enroute, or temporary detours are needed.

Re: Things I Believe About Software Engineering

#198

Post by mark-r » Mon, Feb 03, 2020, 6:05 PM UTC

barrkel wrote: post #32

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…

I have a different expectation of correctness; absolute correctness is impossible, in practice correctness is not a binary condition. Even if something provably executes correctly according to spec, the spec may be wrong (and probably is, since everything interfaces with humans eventually). Everything is in a process of becoming; 100% correctness is not achievable, but it's not desirable either - it costs too much; i…

I once worked at a place where a bug in the spec was treated as impossible - if people couldn't get the results they wanted because the spec made it impossible, there was no way to get it fixed. Any attempt to log it as a bug was rejected.

Re: Things I Believe About Software Engineering

#199

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

smilliken wrote: post #189

skywhopper wrote: post #185

Earlier quoted context omitted.

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…

It's not about eliminating effects! It's about controlling them. A program that had no effect would be perfectly useless. In distributed systems, it's important to be very intentional about effects, instead of letting them creep into any part of your program.

Specifically, it’s about controlling side effects by isolating them. That is, code with side effects has to explicitly declare that it has them, and calling any code with side effects allows the compiler to infer the calling code has side effects. Typically, the isolation mechanism is either explicitly monads, or, is equivalent to monads.

This is incredibly useful for debugging, as is single assignment style code, although single assignment is not necessarily implied by “functional programming.”

Re: Things I Believe About Software Engineering

#200

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

Here is my (unpopular? original?) opinion about software engineering: software engineering is more like writing a novel than building a bridge. Bridges are fairly well understood, and the parameters necessary to build them successfully can be approximated very closely once it’s decided what materials to use. Software will surprise you, in the sense of “no battle plan survives contact with the enemy.”

You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec.

Knuth has famously said he thinks reusable code isn’t all it’s cracked up to be. It’s re-editable code that we ought to all be striving for. There are two aspects to this. First, how often do you get to write entirely new code inside a mature software project? Not often, I would wager, so why not make the job as easy on future you as possible? Second, re-editable code needs to be understood before it can be edited to extend it. This means we need to write code for humans to read, and computers, only incidentally, to execute (I think EWD might have said something to that effect).