Live data from Hacker News

The Hard Thing About Software Development

linkedin.com

51–60 of 105 posts

Re: The Hard Thing About Software Development

#51
Yeah programmers / developers / software engineers act as an interface for other people for computers. It's not surprising that these qualities of that 'interface' affects price:

- intuitiveness i.e how easy is it to communicate with this person (language fluency, etc...)

- quality i.e. how well do this person understand not only the requirements but also the actual goals

- 'latency' i.e. how convenient and how fast can you communicate with this person (time zone, can you both see facial expressions, hear changes in voice, etc...)

Re: The Hard Thing About Software Development

#52
post #42
post #36

Earlier quoted context omitted.

> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…

> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…

> I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major

Because we don't yet understand software engineering. There has been insufficient empirical study of what yields maintainable/performant/what-have-you code, of what sorts of abstractions are "good" for maintenance/reuse/etc., at what's needed to reliably predict a program's resource requirements, and many software developers balk at design tools that restrict their style to detect certain errors as early as possible, like type systems.

Software development is not yet an engineering discipline for all of these reasons, and more.

Re: The Hard Thing About Software Development

#53
post #21

Here's the problem: - Here's a pool of knowledge about software development: hardware, operating systems, memory, disks, file formats, databases, networks, protocols, languages, debuggers, design patterns, security, accessibility, UI/UX, distributed systems, paradigms, typical algorithms & data structures, and CS problems - There's a pool of knowledge about whatever industry you get into as a developer: user demands,…

There is hope. How about instead of becoming the expert at whichever business domain the software is for, we become experts at helping business domain experts find and express the business rules that need to be implemented? You can fit a decent amount of that skill and the technical knowledge you mentioned in one skull, and it still lets you be quite effective in more than one domain. That's what I'm going for anyway…

I think the deep context is what the author is using to solve that issue. Devs are fluent enough and have enough context that business domain experts don't have to spend an inordinate amount of time going into detail. The level of detail cascading happens in the developer's head as opposed to conversation.

It's really an argument for who's going to spend the time and appears simple:

- Devs learning software and industry knowledge

- Business experts learning software knowledge (incl. technical writing) and industry knowledge

Product Managers with some technical knowledge and writing skills are best at being a middle layer between raw customer requests and development specs in my experience. PMs and customers struggle when they don't have a good vocabulary to use to describe features that they want. That's when a dev has to translate or teach the person. Then again, that's asking a PM to learn industry knowledge and technical knowledge and product management knowledge. This is especially true if you have a good QA pipeline.

I've seen analysts and PMs that didn't have a good UI/UX vocabulary or weren't exposed to different UI/UX's, and usually their requests were the most vague and resulted in the most unspoken details.

I've also had PMs that knew how to write a good technical spec down to quick UI mock-ups and error handling. They also had technical writers to pose questions about some of the details.

Pretending I could be as good as the latter is foolish, and if I could, my salary should have been combined for doing 3 jobs well. I think one-man-army, $250k/yr full-time positions are rare though. We seem to be inching closer to it though, maybe without the salary.

Re: The Hard Thing About Software Development

#54
post #50
post #42

Earlier quoted context omitted.

> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…

"Software Engineering" does exist as a degree. Or it used to (15 years ago).

Indeed, it does exist, but IME SE education is just "CS light". I'm not saying that to be disparaging for the sake of it[4], but: there's nothing close to traditional engineering in the software development world[2]. It's basically just business interests coopting the term to try to seem more legit -- and of course they established the equivalent of trade schools for CS as SE. For those in the know SE education is a complete joke. (Disclaimer: Anecdotal, obviously, but I've been a university educator, in a position to hire, etc. etc.)

Just to avoid the inevitable pedantry: Obviously there are people who are serious about this type of thing[1], but in the mainstream and in practice "software engineering" is a complete joke.

[1] E.g. Greg Wilson. WATCH HIS TALKS. Seriously. He's amazing at exposing how absurdly irrational we are when it comes to education and development in general.

[2] I'm not sure why we would expect there to be. Programs, by Turing Completeness, are absurdly non-linear and unpredictable. I'm not sure engineering in such circumstances is even possible nevermind practical. See also [3] to have your mind blown. Engineering is ultimately based on physics which is "linear" in our everyday world (pedantry alert), but "computing" apparently doesn't quite submit to those parameters.

[3] https://en.wikipedia.org/wiki/Busy_beaver (specifically non-computability)

[4] Also, I'd like to add: CS doesn't even remotely prepare you for actually dealing with customers (which is probably the eventual fate of most CS students), but that just means that CS people might need supplemental courses in "requirements analysis"... but they should have had a bit of that when trying to game tests?!? I know that I did game "expectations" massively during my university experience.

Re: The Hard Thing About Software Development

#55
post #42
post #36

Earlier quoted context omitted.

> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…

> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…

CS Major in Australia from around 2001 here, and our final project was a group project involving requirements documents, meetings (including finding times that suited everyone to meet), creating development schedules & milestones & resource allocation in Microsoft Project, meeting with the 'client' (in this case, our professor) to clarify requirements we weren't sure about. Then hacking together the product in Visual Basic. It's the closest we came to building a commercial / end-user software, and the most memorable part of my degree.

Re: The Hard Thing About Software Development

#58

The hardest thing about software development is having people in charge of you that know jack shit about software.

Funny, I've always thought the hardest thing about being an engineering manager is that by default all software engineers think they automatically know way more about everything than their management.

Re: The Hard Thing About Software Development

#60
post #36
post #2

I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…

> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…

I agree 100%. The most useful "software engineering" course I took was in the school of business called "Systems Analysis."
Post reply on HN