Do people actually use UML in practice? It's not something I've ever really found useful for my own development. Maybe it's more of a communication tool than a design tool? Or am I being too hasty?

Yes but only pragmatically not dogmatically. Activity diagrams can be an excellent way to reason about and document some more complex processes imho.

I work mostly in enterprises, I see UML all the time, especially Use Case diagrams and Sequence diagrams.

in my experience sequence diagrams tend to betray the challenges of distributed computing.

Do you mind explain it a bit more? I use it mostly to document the steps between systems, I don't see how distributed computing changes that.

there's no guarantee that 2 requests kicked off at the same time will arrive or complete at the same time. When time is an axis (often y axis), typically we see parallel lines in sequence diagrams, when in reality they will often cross the latter request will actually arrive/finish before the earlier request.

Additionally, any reasonable system will have timeout + retry, but it's not possible to differ btwn timeout and inordinately delayed. Meaning your requests maybe replayed many times, and the system frequently doesn't handle that well

I think it also works as a mental tool. It helps you think about the structure of your software.

Learning Rust without the context of what it solves with C seems a bit weird to me. C isn't easy to master but it's a lot smaller language than Rust and easier to get up and running.

Agreed. Ownership would be way too confusing to start out with.

> Also IMO UML and those Software Engineering classes are not useful for Bay area styled tech companies.

Out of interest, what do you base this opinion on?

I'm not the original poster, but I'll share my opinion. As an undergrad I took two semesters of software engineering at Cal Poly San Luis Obispo (CSC 308 and 309), and as a grad student I was a TA for a year-long senior-level software engineering sequence at UC Santa Cruz (CMPS 115, 116, and 117), which culminated in a capstone project. In these courses we were taught formal software engineering methodologies, with an emphasis on iterative development (at UCSC we taught our students Scrum). However, at the companies I've worked for, which include a mixture of traditional, conservative companies (such as an aerospace company, an "old-school" Silicon Valley enterprise giant, and a traditional Japanese IT company) and large Web giants (like Google and Facebook), the software engineering processes I've encountered in industry have been much more informal.

Granted, at both Cal Poly and UC Santa Cruz we learned very useful skills that are very important when writing production software, such as source control, code reviewing, coming up with effective testing strategies, and other things that I use in my career daily. However, we learned other things that I haven't encountered in industry yet, such as writing formal requirements documents and drawing UML diagrams.

Learning it ~15 yrs ago and then never using it again.

Anecdata.

UML is pretty retarded.

Hey look. Let’s make system documentation easy by drawing a bunch of stick figure people.

Stickman is a bank customer.

And he needs to

1. Open an account

2. Deposit funds

3. Withdraw funds

4. Close an account

Seriously?

I mean this is from the time when Waterfall was a thing and the "best practice" was let's design the entire system specs upfront and then build it..

The interviewer: “In Rust We Trust, of course... But, O Say, Can You C?”