lame88

I had to integrate Azure Pipelines and wanted to shoot myself in the face. The idea that you are simply configuring a pipeline yaml is just one big lie; it's code, in the world's shittiest programming language using YML syntax - code that you have no local runtime for, so you have to submit to the cloud like a set of punch cards to see that 10 minutes later it didn't work and to try again. Pipelines are code, pure and simple. The sooner we stop pretending it isn't, the better off we'll be.

I do have a bias against front end development being from my perspective quite a mess, in the same way that physical scientists often look at the social sciences, though the social sciences are still quite important. But for what it's worth, I consider myself somewhere in that median band, and my perspective is motivated by and applies to front end as much as other parts of software dev/delivery.

I agree you can tell the difference, though I would place blame for those situations more on an organization than the developers who get shifted toward that work out of their specialization. It could be some dubious values, but it also could be project budgets.

Plenty of discussion has been had around incentives and I agree with all that, but also there's another angle here: aside from dark patterns, I think the problems of terrible front-end experiences are most prevalent in the middle of the bell curve - the front-end products developed by rather mediocre skill levels and budgets. Which is usually a pejorative, but thinking of it as literally in the middle, not great but not terrible, a wide range of skill levels where people are more or less competent at their jobs. These are where I start to notice the worst effects of the median trying to adopt the technologies and practices that high skilled developers at good companies with huge budgets are able to utilize effectively, or outright make themselves, especially when there is so much churn that being "up to date" with technology is like a pipe dream to most people. These median teams inherit all the complexity, but due to budget or time pressures, etc. aren't able to overcome it effectively to produce a product with high quality, and users feel the sluggish experience and bloat that comes as a result. This pertains to more than UI of course but eventually manifests to users that way.

Something feels wrong. The median should be able to inherit the benefits of technology produced at the high end without such inheriting massive costs.

I was a little underwhelmed by Tarkovsky's take on Solaris; the book was written with a lot more evocative prose, especially with respect to color, which made the film seem just so plain. But I really liked Stalker - then again I hadn't read Roadside Picnic. My understanding is that Tarkovsky's adaptations are usually quite different from the source material.

One small error (I think) - I noticed your link to pathfinder linked to someone's 2020 fork of the repository rather than the upstream servo repository.

Every time I am unfortunate enough to do something front-end it's just as bad as I remember.

Edit: professionally, that is; when I do front-end related stuff for myself, it's fine, but they are small and I keep things simple - vanilla JS where needed, etc.

I was thinking the same thing as I was reading. Seems like feedback lag while drawing brush strokes would be frustrating for an artist. But then again, we have examples of surprisingly good response time in the game streaming world.

Motivation from within is the strongest, and requires that work be aligned with personal goals, either in developing skills or making something happen. In these conditions, I've found that I'm at my most productive no matter where - I'm working against the clock to realize my own ambitions within the many constraints of my job.

However, this could simply be a mental health thing in anyone's case. There is nothing to lose and nothing to be ashamed of by consulting a professional about it.

How much of this is specific to Kubernetes and how much is more accurately because you moved from managing your own VM infrastructure to using managed services? Cloud providers have (often long had) ways of saying "run this code" without managing a VM and without involving kubernetes, including with docker support. And they are often very easy to use though not without their faults. An example being Azure app service.

I do agree that kubernetes is a pleasant experience from an application developer perspective with an existing cluster, but in my experience it was not without excessive pain and long hours by those administering the cluster. A year doesn't surprise me in your case, which brings to mind this question.

My experience is that the support is shit. Azure has good parts but if the grass isn't greener elsewhere then I weep for the state of the field.

I originally read this as question of whether any startups are hiring that are "solving for software engineering" and was very confused.

The right answer to this, as usual, is probably somewhere in the middle. Perspectives like this are pessimistic, but important because the industry has age bias and yet we need to understand where technology might be going full circle. But instead of taking that as a bad thing and stopping there, we need to understand why and how the context is different this time and what that means. Managed services in general seem to be the ultimate cloud computing offering so far, and aren't reinventing the wheel. They are expensive and costs can be hard to reason about (probably on purpose), and cloud computing companies are profiting greatly from inefficiencies, but they take care of entire categories of operational concerns. This feels like the natural progression of the field. We can take advantage of these things selectively while being conservative in when and how we adopt them.

Complexity is a difficult topic, not the least because the many ambiguous meanings it has taken on. When people bring this up, they talk about it like it's a fixed thing that could go to 0 if only someone actually tried hard enough. Yes, complexity is a problem, but that complexity is always increasing is inevitable as long as technology advances. The first episode of the 70s series "Connections" comes to mind. We need to be able to identify and eliminate waste while dealing with this fact.

Specifically, performance optimizations and reliability improvements. More generally, applying my most unique and valuable skill set compared to the people I work with and advocating for good design decisions toward those ends.

I think you've been a role model in how to build and maintain a popular software project while keeping the spirit of FOSS and promoting a positive community around it. I look forward to seeing what you get up to next.