cycomachead

It sucks that Pamela's leaving Berkeley. We worked closely together for the past year.

These thoughts are incredibly valid -- I also wrote something similar after two years, though didn't share it. Salary is a tough sticking point in the Bay, but it's far from the only thing there. At the same time, it'd be one that the University could relatively easily fix if they tried...

The point about inflexibility is really worth underscoring. My calendar is WAY more full during the semester than it ever was as a SWE. While my summers are quite a bit more flexible in terms of a calendar, they are completely filled with prep and research projects - some to fill in a pay gap, some that are fun... I also find the 15 week (really more like 18 week) semester in the Fall quite a slog. In industry it's often possible to take a couple days vacation when you need it without issue, but it's incredibly difficult to recharge during the semester.

Hmm...I tend to agree...but why?

I would assume his output wasn't 0, so the economics are hard to justify. A typical engineer earns many times their salary in revenue for the company. So, maybe this guys was low performing, but maybe that works out to a wash in terms of revenue per employee.

Or maybe, Amazon says "actually, losing $500K to retain good people isn't that bad every so often" -- how many employees can realistically be in the situation? 100 a year? That's what, $50mm...nothing to Amazon in the big picture.

Obviously there comes a time when you need to fire people, and we don't have the full picture. But it's also not like this money really matters to Amazon that much either.

> If he wants to lash out at anything, I suggest lashing out at a system that requires us to work while going through such awful life circumstances. That man shouldn't have had to work.

And yet, this man worked for a company who could very reasonably enact such a system if it desired to, at least for its own employees.

There is no law which requires corporations to do the minimal amount required by the law. The fact that many chose to do so is a choice motivated by profits and expediency.

There's quite a difference between "I can't perform at my full capacity" and "Go home because you can't do any work". And no doubt, unpaid leave in the midst of costly medical bills (even with insurance costs at up) seems like a poor option.

It sounds to me like the author was asking "can you cut me some slack?", which doesn't seem like an unreasonable question. I'm sure there's a million creative ways an employer could have tried to come up with a solution, even if it's not the most desirable... (Part time work? Delaying a review cycle? Just letting a month of work go?)

I'm an educator—and obviously school is quite different from a job—but when a student is struggling outside of class, you figure out ways to still help them learn! Telling someone to withdraw from a course is certainly a necessary and valid option, but it's far from the first thing I'd present to a student. If I were a manager, hell yes, I would try to modify someone's role or duties before just saying "don't come in".

And, yes, this is one side of the story, but if this person were toxic, they could have been fired at any time and for that reason. (I'm going to assume this person is reasonably truthful, otherwise there's nothing to discuss about a fake story, IMO.)

In the File menu inside Snap!, click on libraries and on that list there's an entire APL library that expands upon these ideas. I am no APL expert; this is something really designed more about pushing the limits than something we're actively trying to teach, but there's definitely useful tools in there.

Depends on what you're doing, but coding is probably the obstacle. There's about 4 of us working various amounts of part time.

In the case of auto-save, there's a lot of unsettled design trade-offs, and other needs keep coming up. But if you're curious, you're welcome to check out the GitHub: snap-cloud/snapCloud is the backend, and jmoenig/snap is the main IDE.

Pretty much. I think "just" is oversimplifying a bit of how powerful they can be, but yes all the reporter blocks are shape generic, and we're exploring whether other tools can be as well. Could we build a really intuitive version of np.vectorize? Maybe. :)

All correct! That's pretty much it!

Snap! is designed to allow students write code in the same way they might in Scratch, but then move them on to exploring CS concepts. It's also somewhat more extensible, including allowing people to make blocks pseudo-natively in JS. (We don't really expect students to do this, but it's a great way for instructors to build tools for assignments or just experiment with ideas not yet in the language.)

Trust me, I know. But even here we run into issues, such as projects over the local storage limit, and the fact that (well, until COVID...sigh), a non-trivial number of students were in computer labs that contained programs like deep freeze making anything local storage based headache inducing as a means of support.

The idea is to be able to easily move someone from beginning features to more complex stuff. The APL functions are new, but in the past this meant story-based projects to using tools like lambdas, map, filter, etc. When done as part of a course, it's definitely something students can learn.But you can do everything in Snap! without those features, too. (The FOR EACH construct for example works just by dropping in a stack of blocks, but you could choose if desired to pass in a lambda and do different parameter binding...but not many people really do that. ;))

We've played around with various ideas for how many blocks to show and it's definitely a work in progress constantly, but the current design is because most people are using Snap! in the context of a course where there's a push to learn those tools and so they get used pretty frequently. :)

Most students end up taking a course in another language. At UC Berkeley, they go from Snap! to Python, and it's typically something like VSCode or Sublime as the IDE.

Autosave is not exactly trivial, but it's definitely on the list. I do agree it's something incredibly useful!

(Doing it right also can incur some costs, and that's something we would need funding for...)

The advanced features are there - like making API requests, Lambdas and real custom blocks/functions. Beyond, that you can write in JS to extend Snap! within itself.

Is it really today (Oct 22)? Not that I care about the specific date, I'm just wondering if there's a particular story as to why this date. It'd be cool to hear if it exists.

A lot of other stories mention "summer". e.g. https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts...

People are not using 50 year old operating systems. It's not as if Linux or macOS today are the same as Unix even in the 90's! People are proud that certain ideas have persisted 50 years. People are proud because many things beyond Linux and macOS can be traced to Unix and the philosophy it holds, but also Unix's place in the broader story of computing history. Bell Labs, Thompson, Ritchie and many more played foundational roles. Like any other anniversary, it's nice to look back and reflect and celebrate.

I still love TextMate -- but I have to be honest, I switched to VSCode recently. The community around VSCode is hard to pass up, and thanks to documentation (and it being JSON), I've found it fairly easy to configure, and in a few ways, it's much easier to configure the whole UI. (pros and cons there...)

I won't say VSCode as stable as TextMate, and it certainly doesn't feel like a native Mac app in the same way, but it's simply easier for me to find plugins that I need.

Tim Bell is an amazing guy! He’s inspired many to do CS. :)

The ones that a missing are old and may have been moved around. I’ll see if I can find them or updated versions. Was there a specific one you were interested in? (Ping me on Twitter or @gmail if I forget to reply here.)

Can you reliably delete the server?

I'm sure it bothered him, too. Keep in mind that the goals of university courses are not just to learn the material but to learn how to learn something. I know it bothers faculty members when they barely feel ahead, but at the same time -- teaching well is as much about understanding pedagogy as it is about understanding the content. And there's a lot of computer-science specific teaching techniques that would transfer to this course.

In an intro course, you seldom get into the super advanced parts of that topic. He's still a very distinguished CS instructor, and even if a student were to ask some question about, say, a CSS cascade question, he'd be more than capable of looking up the answer and explaining things, even if he doesn't know something on the spot.

I'll add that when live coding, you need to generally be more than just comfortable explaining a topic -- even if you understand say, using jQuery callbacks with AJAX requests, you'd probably avoid teaching it live until you know how to recover from errors in reasonable ways or exactly where in the docs you need to look. It's not that you couldn't figure out the solution, but you want to be comfortable debugging something on the order of seconds of to a minute or two so you don't loose lecture time.

This does happen most of the time, and UM has quite a large TA group. He almost definitely had TAs and the majority of the learning is around discussion/recitation sections and practice. In this case, he also wasn't developing the course from scratch either. So, the content in the course was built by those more familiar with the web.

I think it makes sense why people compete on experiences. Can you really differentiate how much you're learning between the top 50 (or even 300) schools? It really depends on personal motivation.

And in terms of non-educational successes, the school name alone often provides the value, and since it's virtually impossible get an exact value, schools compete on other factors.

Combined with the fact students are more and more willing to go further away from home to get a degree, you need to offer something more than education. Going to a good school (and doing the work) will be challenging regardless of where it is, and I think most people realize this at some level -- so you look for the place that will make you happy otherwise. Slogging through finals week anywhere is tough, but it's hell if you also hate the school you're at and wish you were somewhere else.

As far as the "university model" -- it's got problems, definitely. But the value of the top schools has always been the name. Consider that graduates of top schools are so overrepresented in the highest levels of both the public and private sector, it will be hard to break the cycle of top-down everyone buying into the idea of a 4 year degree. It will probably happen at some point, but it seems slow going.

The biggest schools (especially R1-level unis) fare much better in terms of providing funding and aid to students, so they aren't always as cost prohibitive as many for profit schools are (where the vast majority of student loan debt is tied up).

Also, consider that the desire for greener pastures is a very top-down cultural thing in the US, that's not always true world wide (though, it increasingly seems that way.)

By number of students, most higher ed institutions are community colleges, which are (for the most part) low on the BS and extra fun. For profits, and a growing number of 'bootcamp' type schools also fit in this area.

However, 4 year schools (starting off with good ol' Harvard) completely dominate the idea of what higher ed is like. Employers still revere 4 year degrees and a "big name" still has its advantages. Many students grow up thinking that's the only/right/best option for them - so between dozens of essentially equivalently good schools (i.e. The "Top 50", and arguable the top 100-200 too), students pick on factors other than learning.

A few months ago, 538 wrote a fun piece called "Shut Up About Harvard", which is worth a read. https://fivethirtyeight.com/features/shut-up-about-harvard/

Here we go again... ?

Then again, this doesn't seem anywhere near as crazy as the IO.js days.

Very weird -- earlier this year the FedEx guy delivered some photo mattes to the apartment across the street. The vendor wouldn't refund me because it showed as delivered, but Amazon told me (and refunded the $40) specifically under their A-Z program. Eventually a few weeks later, the box turned up because I guess someone decided to actually check the address and re-deliver it.

Simpler than the iterative is hard to argue -- it's closer to a strict mathematical definition but the iterative version can also be setup very simply too.

To say one is more powerful is really false. I think recursion is great, and for some situations it should be the go to method, but anything you can write iteratively you can write recursively and vice-versa.

p5 has also been around for a while, but even then the tech isn't the cool part.

Processing was well thought out from a learnability standpoint, and p5 takes that and allows you to build some _very_ compelling lessons, modules and even whole CS courses that can be delivered and completed online. Because it's also JS, it means that if you can always augment an exercise with any of the rest of the JS ecosystem (for better or worse).

Berkeley undergrands have a special talent for building pretty websites that are terribly underperformant.

I say this with the utmost respect; I built a few of those as an undergrad too. :)

(And yes, it's obviously not just us Berkeley folks.)

Oh man, I 100% agree about color! I've worked on Snap! (which looks a lot like Scratch) and it has a feature called "zebra coloring" that's very similar. I've seen it be very effective with students.

Hacking up a friendly version of emacs does sound like an interesting project. I suspect it's an uphill battle to convince people to use it, but someone should try. :)

Syntax errors can be a large impediment to learning to program, so that's one big advantage. Frame-based editing has some other advantages, some of which you'd see in more complex IDEs like being context aware of what the user is truing to do.