ess3

I think this is a hard problem to solve for a couple of reasons.

- Skew of supply and demand. There will be always be another musician willing to earn less money because they still get to do their ”dream job”.

- The need for background music. No matter how joyless it feels to produce this stuff, there’s a need for it.

I think companies like Epidemic offers an alternative route for musicians to earn some money on the side of their artistic vision.

Biggest issue which is more a philosophical one is how Spotify is shaping how we consume music.

I wonder if we’ll ever see a computer assisted style in esports, like what exists within chess. Bring your best cheats.

Reminds of a quote about Van Morrison:

There are two types of people. The people that like Van Morrison and the people that have met him

A quote from a jazz theory book comes to mind. Goes something like this:

Jazz is 99% theory 1% magic. The difference between the greats is that they’ve forgotten all the theory

This basically the plot of the movie ”Real Genius”

Very nice! The first brief I give my students when teaching web development is similar - Web design like it’s 1999

I don’t remember where I read this (think it was some published paper) but I was building some audio streaming thing on top of WebRTC and there was an estimate that 60% of people would be able to do p2p.

Actually reimplementing something that’s already exists is a great way to get an understanding of it precisely so you can deal with the questions you mention.

My rule of thumb is that you should always understand at least one level of abstraction down.

As a kid I acquired my parent’s login to the school platform meaning I could call in sick myself. However one day I actually got sick so they had to call it in which means they would’ve seen all previous calls.

So I downloaded the HTML for all pages required for this exact flow and removed the previous sick days. I then changed my etc/hosts file, gave them my computer and prayed that they wouldn’t try to visit any other page than the ones I downloaded.

Worked like a charm. Later I called in sick myself.

Cannot recommend this course enough

My biggest gripe is touch interfaces on stoves. You constantly spill water or other things.

I’m very much teaching the same thing - an eight week introduction to JS (after 6 weeks of HTML/CSS).

My approach was to lead with one week of unplugged programming just introducing the concepts of CS. Then introducing the fundamentals of variables loops etc using a block based language.

The following week we transition to JS doing one week of fundamentals and after that moving on the DOM and events.

So far I think it has worked out pretty well. A key part is to work both bottom up and top down at the same time until things eventually click.

The word safe here is doing a lot of heavy lifting imo. Not necessarily safe as in physical safety but also contractual safety.

An example is pension where companies not under collective agreement tend to not specify pension in contract rather just a blurb about "pension is to be compensated based on the currently applicable company policy". Basically allowing them to do whatever bait and switch they want later. Even if the benefits are good now there's no guarantee that they will stay that way. That's what a collective agreement is supposed to protect, that you can't go below that standard.

I just resigned from my job as a software engineer (~9 years of experience) without having another job signed. Best decision I have ever made. The second I did was the second the curiosity and eagerness to learn things came back.

Indeed. It’s really a bummer that “frontend engineer” has more become synonymous with “react engineer”.

Not sure if this is what you mean but built in “masonry” support is now part of the CSS spec (barely any browser support yet though.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_la...

I’m still looking for a lightweight solution (no react etc) that lets me write normal CSS but scoping it to an arbitrary part of my HTML tree. Most of the time I’ll be working in a partial where I know what generic names such as .container refers to And I don’t want to bother with coming up with unique names.

The best I can think of is to use descendant selectors but that increases the specificity and is hard to maintain imo.

Excited to see what the @scope feature draft can bring to this

I’m a teacher mainly for front end development. One of the courses I added this year is called The Ecosystem of the Web.

The brief was that they have to propose a new feature of the web and explain how it would end up being something you can use.

Really fascinating to see what students with very little experience thinks about and suggest. The importance of agency really hit home with me and I’ll try to bring that to the class.

I’ve found the opposite work for me. Finding silly pun names early greatly improves the chances of me finishing it.

Don’t know too much about the Canadian market but isn’t the convenience of not doing something illegal and it being easily accessible worth paying for. That’s why streaming service’s completely beat out piracy

And on that note the ”trick” to being more experienced is being able to anticipate what’s coming up next and already have a mental model for how to solve that.

Easier said than done though

I think what’s missing from a lot of agile teaching material is how you build trust with your stakeholders/management. Without it whatever process you implement will still morph to have to include deadlines and estimates.

For more nostalgia check out https://www.cameronsworld.net/. Great curation of old geocities websites complete with a Netscape navigator lookalike.

Isn’t a debate by definition two sides trying to convince a 3rd party which side is correct. The sides involved in the debate will never back down.

A discussion on the other hand is when both sides just try to reach the “best” conclusion. Unfortunately all too many things are debates and not discussions…

> In every case they said they were in a hurry and that they would “fix it later”.

This. We need to stop using time pressure as an excuse to do a bad job. Moving things out to a separate function might add 10 min but save 100x when everything comes crashing down.

Of course you shouldn’t overengineer but so much can be gained from spending a little time just thinking about how this should work.

I feel like the biggest reason why REST failed is because it’s just not useful from a business point of view. Like how will I put my logo and brand colors over all of this.

100% agree, both on your points and the article lacking a point.

> It's not your fault if nobody cared to mention that the user should be able to arbitrarily subdivide the pizza and select options sepatately for each subdivision - that's a feature update and it's OK if the original program hadn't though of that.

I would argue it’s part of your job most of the time to challenge whatever needs are presented and ask questions about the long-term vision to find a good middle ground of future proofing vs over-engineering. That is of course one of the hardest things to get right.

I think maybe more it’s the peak of platformization which all regress to the mean. There’s still a lot of interesting things to find, it’s just a lot harder and you have to venture off the main platforms quite a bit.

I agree with you. But I guess the problem stems from having to prioritize between building the next shiny thing or actually going back and fixing the problem. Even worse is that many of these problems have rather low short-term impact and a much larger long-term impact, which makes it even harder to justify/explain to the person making the prioritization. It's much easier to hide it behind the facade of "technical debt" to which everyone intuitively agrees it's a problem.

But yes having people with the competence to actually understand the clear cut issues also making the prioritization would be nice.