Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

331–340 of 500 posts

Re: You are never taught how to build quality software

#331
post #303

Earlier quoted context omitted.

This is why internships and real world experience is so important. A course is 3 in class hours a week over 12-14 weeks typically. After homework and assignments it is ultimately maybe 40-80 hours of content. Which means you learn more in one month of being on a normal, 40 hour workweek job than you have in an entire semester of one course.

>A course is 3 in class hours a week over 12-14 weeks typically. After homework and assignments it is ultimately maybe 40-80 hours of content. Huh? I was spending 20+ hours a week on assignments alone in upper level software engineering classes. Also, internships were required.

Were you the sort of person who responsibly worked a little bit on the assignments over the course of the week/two weeks, or did you carve out an evening to try to get the whole thing done in one or two sittings?

My group did the latter. I think based on what we know now about interruptions, we were likely getting more done per minute than the responsible kids.

Including reading, we might have been doing 15 hours a week sustained, across 2-3 core classes.

But these were the sort of people who got their homework done so they could go back to the ACM office to work on their computer game, or work out how to squeeze a program we all wanted to use into our meager disk space quota.

Anything more than a B was chasing academia over practical knowledge. B- to C+ was optimal.

Re: You are never taught how to build quality software

#332
post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

I chose software engineering. 3 years into the program the head of the department made a speech at an event to the effect of "Software hasn't changed in the last 10 years". It instantly devalued the entire program for me.

I know where you come from and I know where the people who are responding to you come from too.

Software has changed in the last 10 years, but a lot of it has changed superficially. A green software engineer most likely won't be able to tell the difference between a superficial change and a fundamental change.

It has a lot to do with the topic of this thread. "Quality Software" It's a loaded term. There's no formal definition, everyone has their own opinion on it and even then these people with "opinions" can't even directly pinpoint what it is. So the whole industry just builds abstraction after abstraction without knowing whether the current abstraction is actually close to "quality" then the previous abstraction. It all starts out with someone feeling annoyed, then they decide to make a new thingie or library and then they find out that this new thing has new annoyances and the whole thing moves in a great flat circle.

That's the story of the entire industry just endless horizontal progress without ever knowing if we're getting better. A lot of the times we've gotten worse.

That being said there have been fundamental changes. Machine learning. This change is fundamental. But most people aren't referring to that here.

Re: You are never taught how to build quality software

#333

Earlier quoted context omitted.

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

TOI?

I’m guessing Transfer of Information.

Re: You are never taught how to build quality software

#334
post #323
post #224

The reason I find it easier to work with people who have a degree in Computer Science is that I don't have to convince them of the need for good algorithms and not to try to implement parsers or cryptography by hand. When it comes to software engineering I feel there is no qualification where you can feel that the gross naivety about quality and working in teams (and with other teams) has been similarly ironed out. I…

Cryptography yes, but are you sure about parsers? As far as I can tell, there's some kind of U-curve there. Beginners code them by hand, intermediate-level programmers and intermediate-scope projects use parser generators, and people maintaining the most sophisticated parsers prefer to code them by hand too. For example, GCC used to have a bison parser, but they switched to a hand-coded recursive descent one because…

I offer, again, my JetBrains GrammarKit counterpoint from the last time that assertion came up https://news.ycombinator.com/item?id=38192427>

>>>

I consider the JetBrains parsing system to be world class and they seem to hand-write very few (instead building on this system: https://github.com/JetBrains/Grammar-Kit#readme )

- https://github.com/JetBrains/intellij-community/blob/idea/23... (the parser I'll concede, as they do seem to be hand-rolling that part)

- https://github.com/JetBrains/intellij-community/blob/idea/23... (same for its parser)

- https://github.com/JetBrains/intellij-community/blob/idea/23... and https://github.com/JetBrains/intellij-community/blob/idea/23...

- https://github.com/JetBrains/intellij-plugins/blob/idea/233.... and https://github.com/JetBrains/intellij-plugins/blob/idea/233....

Re: You are never taught how to build quality software

#335
post #322

You learn this at quality shops. 10-15 years ago roughly FAANG. Today? TailScale and stuff like that. You can just noT have a bunch of pointless micro services and docker in your runc and layer on layer of json de/re, and unit test to get coverage but ignore quickcheck and hypothesis and fuzzing. You can use stacked diffs and run oncall loops out of the team authoring the code and all of it. You can minimize dynamic…

[flagged]

I don’t work for TailScale, I don’t hold shares.

Just a fan.

Re: You are never taught how to build quality software

#336
post #152

Earlier quoted context omitted.

Do SE classes teach debugging skills? I hope they do. So many times I have seen people try random things rather than follow a systematic approach.

I worked with programmers around my junior year and some of them were in classes I was in. I thought they were all playing one-upsmanship when I heard how little time they were spending on homework. 90 minutes, sometimes an hour. I was a lot faster than my roommate, and after I turned in my homework I’d help him debug (not solve) his. Then I was helping other people. They really did not get debugging. Definitely felt…

I believe that software-related college degrees are mainly there to get the horrible first few tens of thousands of lines of code out of people before they go into industry.

Re: You are never taught how to build quality software

#337
post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

I went to a STEM school and exactly 0 of the professors had been in industry ever or at least in the last 30 years. The only guy with some experience was an underpaid lecturer. He was also the only good lecturer.

A lot of professors just want to do research and mentor students onto the PHD track to self replicate. My mandated faculty advisor was basically like "go to the career center" when I asked about, you know, getting a job of some sort with my degree.

So yes, it is a real problem. CMU may stand out by actually having courses in the space, but it is not the norm by any means.

Re: You are never taught how to build quality software

#338
post #276

Earlier quoted context omitted.

There's a massive gap between taught at CMU and taught at most universities. And even if it is taught, it's usually outdated or focused on very literal stuff like how to write web applications. I'd have killed for a class that actually focuses on implementation, on teamwork, on building complicated systems.

I've wished that students would be required to hand their semester long project to the person next to them each week.

Almost every CS course I took went the other way and had strict cheating policies that essentially made any group work verboten. There was 1 group project in 1 course I took in 4 years.

My spouse on the other hand took an explicitly IT program and they had group projects, engaging with real world users, building real solutions, etc.

Re: You are never taught how to build quality software

#339
post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

I chose software engineering. 3 years into the program the head of the department made a speech at an event to the effect of "Software hasn't changed in the last 10 years". It instantly devalued the entire program for me.

> "Software hasn't changed in the last 10 years". It instantly devalued the entire program for me.

As opposed to maths, physics, philosophy, civil engineering, classical studies which have gone through complete revolutions in their topics, problems and study methods in the last 10 years?

Re: You are never taught how to build quality software

#340
post #180

Earlier quoted context omitted.

Aviation in particular has a very strong culture around (government mandated) checklists and post-crash investigations. This has both pros and cons. The pros is that every airline learns from the mistakes made by every other airline and over time the system becomes really quite safe indeed. The cons are that it is quite expensive and time consuming. Imagine if every software company was obliged by law to: - Every sin…

I wish someone would create that 500 line checklist. I've seem attempts, but they tend to be either not actionable (is the software high quality - meaningless), or of metrics that are just gamed (is test code coverage > 80%?)

> or of metrics that are just gamed (is test code coverage > 80%?)

The rebuttal to your implied Goodhart's Law https://en.wikipedia.org/wiki/Goodhart%27s_law> that was offered by my manager was "tension metrics" https://en.wikiversity.org/wiki/IT_Service_Management/Contin...>

If I understand his theory correctly, in your case there would be a competing metric to the "test coverage" one that said for any changeset, a test cannot itself change by more than 20% in the same changeset as non-test code. So you can change the code such that it still passes the existing tests, or you can change the test to adapt to new requirements, but you cannot rewrite the tests to match your newly changed code

I'm acutely aware this is a terrible example, the devil's in the details, and (in my experience) each company's metrics are designed to drive down their own organizational risk https://en.wikipedia.org/wiki/Conway%27s_law>, combined with "you're always fighting the last war" :-D

Post reply on HN