I love that this podcast only comes every two weeks. Some (like Software Engineering Daily) are far too often so I either feel the paradox of choice or that I’m missing out.
I’m not sure if it’s similar to what you’re talking about, but there is something called “TRIZ” that’s a collection of “things” we were introduced to in a mechanical design class I took.
Do you mind elaborating on the definition of "cross functional team" here? It seems either non-standard or something that may differ by industry.
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.
For what little it’s worth, the thing that finally made it click for me was a series of comments on HN that were discussing musical scales.
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.
I'm teaching discrete math in January — I'll try the analogy, wish me luck!
As someone who's gone through the mathematical ringer, the analogy doesn't ring true to me, but it does sound pedagogically useful still (my students will be CS majors, so the math will be for training rather than an end). Even at the highest levels the definitions are of prime importance, though I suppose once you get to "stage 3" in Terry Tao's classification (see elsewhere in the thread) definitions can start to feel inevitable, since you know what the theory is about, and the definitions need to be what they are to support the theory.
Personal aside: In my own math research, something that's really slowed me down was feeling like I needed everything to feel inevitable. It always bugged me reading papers that gave definitions where I'm wondering "why this definition, why not something else", but the paper never really answers it. Now I'm wondering if my standards have just been too high, and incremental progress means being OK with unsatisfactory definitions... After all, it's what the authors managed to discover.
Yeah, sorry if I wasn't clear. I 100% agree with definitions, theorems, counterexamples, and proof techniques being incredibly important. Those are the "warm ups" or "scales" or things that need to be repeatedly drilled in my mind before trying to jump into the "game," which, to me, is solving problems.
When I was doing an associate's in engineering, our calculus and differential equations courses were like this. We'd learn some math, do some problems by hand, then we'd have a lab component where we were introduced to either methods in a computer algebra system or some numerical methods. The problems we solved there were word problems that had the higher level physics already set up for us, so that we ended up just having to solve the calculus or differential equation portion of the problem.
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.
In the US most engineers do not have the PE and many (might be most, but I couldn't find the numbers) do not take the FE exam.
In the States most people working on software have computer science degrees, not software engineering degrees.
In general there is not a huge amount of certification overhead for engineers in the US, despite what some people seem to think, and I'm quite happy that's the way it is.
I was mostly looking for perspectives on how requiring credentials like these impacted actual work and workplaces.
This was posted as a comment on a thread about a new Google tool for LP [0]. It was in response to someone asking for resources on learning linear programming for business applications. It looks like the examples have been solved using Excel, and it's for business students at MIT. Definitely not cutting edge.
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.
[1] https://www.asc.ox.ac.uk/people