I have worked on production lines and I’ve worked in the manufacturing and quality engineering side of things.

I know a lot of companies do have that old school production at all cost approach, but the better places I’ve worked at have put quality metrics ahead of productivity metrics.

Usually the metrics are safety, quality, delivery, and cost in that priority.

I know Goodhart’s law, “when a measure becomes a target, it ceases to become a good measure,” gets quoted a bunch on HN, but then nothing else is offered up. In my opinion, having these additional metrics with their own targets serves to balance out and constrain a single metric screwing things up. For example, if productivity is going up by producing lower quality parts, this will be shown in either the quality metrics (e.g., scrap rate, yield) or the cost metrics (e.g., material costs have increased, rework costs have increased).

The other component of it all is that the operators can only produce to the level of the systems they have. They can make some small, point improvements to help, but generally there need to be larger process or system level changes supported to make significant improvements.

Where I live, we are going through a lot of this right now (98+% of population growth is from immigration).

Immigrants have more kids than the non-immigrant population, but they do not actually have above replacement rate amounts of kids, so they are going to require more immigrants to take care of them later on. Also, the children of immigrants have non-immigrant level fertility rates. So, it's not a long term, sustainable way to "replace the aging population."

On top of this, immigrants often want to bring their elderly relatives with them when they are possible. I know there are some ways to try to mitigate this (e.g., immigration limits, charging them extra fees on immigration), but at some point there becomes a large enough immigrant voting bloc that this changes. Now you have extra, unaccounted for elderly people that are required to be looked after.

I have no idea what the solutions are, but if we are trying to plug the gap through immigration, it'll require perpetual immigration. Most countries globally are now at below replacement fertility rates, so this opens up a huge can of worms. I'm sure I'm missing something obvious, but it doesn't seem like anything other than a quick band-aid or a solution that's doing anything other than adding "debt" to the issue.

Harvard Business Review and probably hundreds of other online content providers provide some simple rules for meetings yet people don't even do these.

1. Have a purpose / objective for the meeting. I consider meetings to fall into one of three broad categories information distribution, problem solving, decision making. Knowing this will allow the meeting to go a lot smoother or even be moved to something like an email and be done with it.

2. Have an agenda for the meeting. Put the agenda in the meeting invite.

3. If there are any pieces of pre-reading or related material to be reviewed, attach it and call it out in the invite. (But it's very difficult to get people to spend the time preparing for a meeting.)

4. Take notes during the meeting and identify any action items and who will do them (preferably with an initial estimate). Review these action items and people responsible in the last couple of minutes of the meeting.

5. Send out the notes and action items.

Why aren't we doing these things? I don't know, but I think if everyone followed these for meetings of 3+ people, we'd probably see better meetings.

I understand I’m replying against the spirit of your point, but the IEEE has actually published one and it seems to get updated very slowly.

https://www.computer.org/education/bodies-of-knowledge/softw...

In general, though, my very limited experience working in manufacturing was that much of the blog equivalents were covered in things like white papers from hardware manufacturers or articles in trade publications. We always had a bunch of magazines delivered each month and there were usually some interesting articles to review.

[1] https://www.asc.ox.ac.uk/people

https://en.m.wikipedia.org/wiki/TRIZ

Where I've worked, a cross functional team is one made up of functional experts from different groups. A team where everyone could do the work of everyone else was a team that was cross trained.

I don’t have any musical training, but I related it back to the practice and warm up sessions we had before we’d play an actual game in the sports I played as a kid.

Perhaps some explanation like that will get it to click with someone.

I also learned of the existence of soft question tags on Math Overflow and Math Stack Exchange that contained an incredible amount of guidance that I think was never possible in lectures. Sharing links to those websites in the syllabus may be helpful for the odd student that actually looks at the syllabus.

The calculus books we used were not set up like this and the books that focused on learning the CAS or numerical methods weren't structured any better. I think this only worked because it was a small program aimed at technical education with a faculty that cared about developing a unified curriculum.

When I transferred to a different university to finish a degree as a stats major, all of our courses and most of the textbooks were structured in a way to use R. We did some problems on simple linear regression by hand, but very quickly it becomes impractical do to it any other way. This seemed very natural to me, but apparently it was not the typical experience of studying statistics.

Perhaps there are some calculus books out there that do a good job of both teaching calculus concepts and using CAS / numerical methods, but my narrow minded view is that calculus is a tool for physics, engineering, or other applications, and you'll be bogged down in teaching the relevant domain knowledge to get interesting examples. If you're looking for your own examples, perhaps this could be done purely through the differential calculus topics of related rates and optimization or the integral calculus topics of simple ordinary differential equations.

I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chapter 17 on mathematical foundations would cover at least 4 classes (discrete math, differential calculus, integral calculus, probability).

The US of A did have a software engineering principles and practices of engineering (PE) exam, but it's been discontinued, and I haven't managed to find an archived snapshot of the exam spec. I'm not American, but I think there is a common fundamentals of engineering (FE) exam [1] that has to be written to register as an EIT and then the PE [2] has to be written to be licensed and given the PE.

I'm not familiar with which American schools were ABET accredited in software engineering, but in Canada, several schools do have accredited software engineering majors. You can review the curriculum and see a fair amount of alignment to the SWEBOK topics. Again, some of these chapters could be split across multiple courses, but some chapters look more like a couple of weeks in one class.

For comparison, there is a 61 page industrial and systems engineering body of knowledge [3] available from the IISE (Institute of Industrial and Systems Engineers), which is really just a couple short paragraphs on each topic, a list of key areas within each, and a list of reference books. At a quick glance, all of the areas correspond to sections in the industrial FE [4] and the industrial PE [5].

> There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.

I'm not an engineer. I did an associates in engineering technology in Canada, so I'm a "pretengineer" at best. As far as I know, engineers in Canada have a discipline and then areas of practice. For industrial, there are 9 different areas of practice, but people are generally licensed to practice in 1 to 3.

In my region, software is not even broken out into its own areas of practice. Software is an area within computer engineering. I think software is way too vast right now and the expectations are much too big. So, the traditional engineers have much more limited scope problems. But I could be limited by my perspective and lack of license.

[1] https://ncees.org/exams/fe-exam/

[2] https://ncees.org/exams/pe-exam/

[3] https://www.iise.org/Details.aspx?id=43631

Links to PDFs

[4] https://ncees.org/wp-content/uploads/2022/09/FE-Industrial-a...

[5] https://ncees.org/wp-content/uploads/2024/10/PE-Ind-Oct-2020...

The original posting is about new tools and algorithms, with some more analysis. Well beyond my background from undergrad courses in LP and OR, but probably more relevant and insightful to you.

[0] https://news.ycombinator.com/item?id=41609670

A variation of this exists with one more word thrown in for good measure: https://en.wikipedia.org/wiki/Rapid_application_development

When I worked in manufacturing, we distinguished between “continuous improvement,” which were these smaller improvements that will get you to a local minimum, and “radical transformation,” which will get you significant improvements and requires redesign of the entire system.

But I can’t find an article in a quick check on er website.

There are some mentions on their website about how splitting the family fortune dilutes it and causes families to lose money.

There are families in Europe that pass the bulk of the family fortune to the oldest son. That son does what they can to help the rest of the family live comfortably, but the rest certainly aren’t rich. So, this statistic may only be applicable to American families or places where it’s common to successively divide the fortune up.

Was there any cost considerations associated with prioritizing the implementation or even limiting the scope of the solution?