Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hard Thing About Software Development

linkedin.com

Post reply on HN
Print view View original

91–100 of 105 posts

Re: The Hard Thing About Software Development

#91

Post by sidlls »

tj-teej wrote: post #71
naasking wrote: post #52

Earlier quoted context omitted.

> 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…

+1 to this - not to say the cliche "AI is the future" statement, but careers span decades and if the fundamental dynamics of writing software changes mid-career you'll be glad you have a strong background in CS fundamentals rather than having taken "Java", "OO Programming", and "Scripting 101" classes.

A strong background in fundamentals is sufficient for a very small number of programming tasks. Do not mistake my top-level comment as an endorsement of the status quo focus on CS minutiae that reigns in this industry.

Your comment is tantamount to claiming an engineer ought to have a strong understanding of theoretical physics fundamentals in order to adapt his career over the span of decades. The reality is substantially different.

Re: The Hard Thing About Software Development

#92

Post by marssaxman »

naasking wrote: post #52
ramzyo wrote: 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.…

> 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…

We will never understand software engineering in that way, because we are in the business of automating ourselves out of work. As soon as we understand part of the process well enough that it could become an engineering discipline, we simply build some new tools and let the robots handle that part of the job, moving the humans along to wherever today's frontier of uncertainty happens to be. We will never be engineers in the traditional sense, because that would be a waste of human brainpower.

Re: The Hard Thing About Software Development

#93

Post by alexpw »

creeble wrote: post #62
Tutankamon wrote: post #57

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

Man does that ring true on this Friday morning. I'm working with an intern who's implementing a "proof-of-concept" for voice control using both Alexa and API.AI (Google). He's a CS freshman. It's amazing what he's gotten working so far, but his code is unreadable noise. Like he never learned what a subroutine is for. But he's giving a demo to the CEO today, and said CEO will undoubtedly say "Nice, finish it and let's…

Eerily similar circumstances here: intern, alexa, demo this morning. First round is on me...

Re: The Hard Thing About Software Development

#94

Post by naasking »

marssaxman wrote: post #92
naasking wrote: post #52

Earlier quoted context omitted.

> 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…

We will never understand software engineering in that way, because we are in the business of automating ourselves out of work. As soon as we understand part of the process well enough that it could become an engineering discipline, we simply build some new tools and let the robots handle that part of the job, moving the humans along to wherever today's frontier of uncertainty happens to be. We will never be engineers…

You overestimate AI. Incompleteness is everywhere in CS. Overcoming these limitations is not trivial at all.

Besides, software hasn't automated any other engineering discipline, and those are much more straightforward because they're more mature and the principles understood.

Re: The Hard Thing About Software Development

#95

Post by manyxcxi »

ramzyo wrote: post #42
sidlls wrote: 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.…

At my uni (Oregon State) we had MIS (Management Information Systems), which covered a wide range of these topics. I switched to this from CS my junior year because I felt it wasn't preparing me for the professional world, and I was right- to a degree.

My CS curriculum had some Software Engineering classes (I believe they were actually called Software Engineering I and II) where we did requirements gathering, estimation, etc- it felt like all of SEII was requirements gathering and documentation. Besides those though, it was very theoretical, and since I was already working in the field while going to school I realized that the theories would be helpful, but not nearly as helpful as being able to plan, document, and manage tasks in the context of a project.

If CS is producing developers, MIS is definitely producing technical analysts. It was extremely light on any development (there were a few classes where people had to write code and it was like every other student was being asked to build a rocket to go to Mars). But it did a great job of teaching how to identify problems and apply technology based solutions to them. Not just fixing things by making code, organizational level solutions.

Armed with MIS and a minor CS (and one class short of a math minor) I hit the ground running and was quickly leading projects, then dev teams. Six years in I was a Director and was also leading a skunkworks Innovation Lab where I got to keep my hands dirty.

The absolute fundamental difference is that I got the hard core tech depth from so much time in CS (and actually using the tech in practice) but I got the study I needed for it's useful application in a business environment. Selling to leadership, planning, source control processes, etc.

Most developers show up with the mindset of a craftsman toiling away in their shop, wanting only to emerge with their beautiful creation when it's ready. Pragmatism and being able to accept trade offs because of time/money/whatever will always make developers stand out.

Re: The Hard Thing About Software Development

#96

Post by BatFastard »

davidjnelson wrote: post #73
indogooner wrote: post #44

This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at d…

Great points. > multiple if-elses encoding the business rules A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.

Not saying rules encoded in "if-elses" are good, but they can put all the rules in one location. Polymorphism can spread those rules out in somewhat obscure ways. I use both, depending on what I want to do.

Re: The Hard Thing About Software Development

#97

Post by davidjnelson »

BatFastard wrote: post #96
davidjnelson wrote: post #73

Earlier quoted context omitted.

Great points. > multiple if-elses encoding the business rules A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.

Not saying rules encoded in "if-elses" are good, but they can put all the rules in one location. Polymorphism can spread those rules out in somewhat obscure ways. I use both, depending on what I want to do.

Right, I wasn't saying polymorphism was the only solution. I was saying deeply nested if elses are hard to maintain. There's many solutions to avoid them. So I think we agree, use what makes sense given the context.

Re: The Hard Thing About Software Development

#98

Post by scarface74 »

learc83 wrote: post #83
ramzyo wrote: post #46

Earlier quoted context omitted.

Interesting, maybe a more informative question for me would be - if you did have a class/classes that covered those topics, did you feel that they prepared you sufficiently for a job as a software engineer? But now I'm starting to sound like an alumni survey... :)

My degree required a class like this. It was the most useless class I took. The theory heavy classes (automata, algorithms etc...) covered material that changes very slowly. But, as a previous poster said "we don't yet understand software engineering." Because of this software engineering best practices change with the wind. As a result, the software engineering class was a hopelessly outdated survey of how software…

Software Engineering doesn't change that rapidly.

The idea of iterative software development - that we now call "agile" was first documented in 1957

The Mythical Man Month was published in 1975 and is just as relevant today as it was when it was written.

Code Complete came out in 1993 and is still relevant.

Even when you start talking about programming languages, both Java and C# have been popular in the enterprise since 2005.

Re: The Hard Thing About Software Development

#99

Post by scarface74 »

Terr_ wrote: post #80
mfoy_ wrote: post #79

Earlier quoted context omitted.

"Just send me your questions and I'll pass them along..." Because no one has _ever_ had a question answered and had a follow-up question based on the answer before... /s

True story: Myself and a bunch of internal customers are literally less than 50 meters away in the same office. The blessed middleman is in a different timezone 8 hours ahead. So instead of a quick conversation 30 minutes with helpful whiteboard doodles, I have to compose my questions and decision-tree into an e-mail and wait at least for a day or two for a reply that may or may not be useful.

I came in my company as a team lead to a very disfunctional department, the developers were frustrated because of unclear requirements and the business side was upset because they could never get their deliverables despite "very clear" 100 page documentation specs and a "detailed" list of requirements.

They would email each other even though they were in the same office more to document everything and CYA than for communications.

On the dev side, I banned internal email for discussions. I told them that they must talk to people first if they are in the office and then send emails of documents, screen shots or whatever.

I also took it on as personal mission to never say "no" to any request and always talk to the person who was making the request - in person - see if we could come up with an acceptable compromise and tell them how it would affect their deliverable.

Post reply on HN