Hacker News new | comments | show | ask | jobs | submit login
Software Engineering is different from Programming (medium.com)
17 points by ScotterC 9 days ago | hide | past | web | 11 comments | favorite

Wow, medium contents behind a login wall now? In the wise words of mean girls:

>stop trying to make medium happen! It's not going to happen!

Esp. not with this annoyance.

I guess Medium is one more domain to mentally filter out.

I added their domain to my google search results blocklist after seeing this members only stuff.

But could we please make "Software Artist" happen?

I had been wondering about this already but this puts me over the edge. There is a bunch of hn frontend websites. Can any of them be configured to filter out stories linking to medium or to other paywall sites?

I don't think of it this way. While engineering is certainly required I think of engineering as overhead and the more engineering you have to do is indicative of a problem somewhere else.

Take javascript: Javascript is probably the technology with the most engineering overhead in the world. Javascript is so bad that all practitioners of front end engineering have a huge amount of engineering overhead to deal with whether that's through automated testing or manual tests. This all comes down to : Lack of type checking, browser fragmentation. Would you write airplane controller software or airbag deployment software in javascript? No.

There would be significantly smaller engineering overhead if someone say wrote a backend application in Go. Needless to say the original author is a javascript/front end dude.

>If someone does not understand the problem, they should not be allowed to program a solution for it.

You ever done agile? You'd never engineer a bridge using agile. Agile is indicative of lack of understanding of a problem which is typical of 99% of software engineering. We simply do not fully understand business requirements until a product is deployed. So we deploy a project first and iterate and deploy again. Iteration is continuous and indefinite because real understanding of the business "problem" is never complete.

That's a poor analogy for agile. A better one would be knowing that you need to build a bridge, pave a road, and demo a building.

You determine that for this sprint, you need to build that bridge, because it's blocking off commuters and hurting commerce. You KNOW how to engineer a bridge, and you've just decided to dedicate this next iteration to doing that.

Next sprint, let's say you still haven't finished the bridge...but the building that needs to be demo'd has deteriorated to the point that it is an immediate threat to public safety. So you decide to pause the bridge building and focus on the demolition. But you KNOW how to engineer a demolition.

Understanding business requirements is different from engineering, anyhow. But don't conflate re-prioritizing with not knowing business requirements. Agile doesn't describe how you should do something, it just determines when you should do it.

The end result of this process is that nothing ever actually gets finished - you just fight the fire of the week forever, and ever, and ever. Meanwhile your half-finished bridge starts rusting away and collapses.

> Would you write airplane controller software or airbag deployment software in javascript? No.

I went to a developer meetup on Monday and one of the talks was about embedded JavaScript.

Would you or I do it? No but someone probably would.

There should probably be something like a Surgeon General's warning for embedded devices running JavaScript.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact