Huggernaut

Is what you're describing different from the idea of Terraform Workspaces?

https://www.terraform.io/docs/language/state/workspaces.html

> Certain backends support multiple named workspaces, allowing multiple states to be associated with a single configuration. The configuration still has only one backend, but multiple distinct instances of that configuration to be deployed without configuring a new backend or changing authentication credentials.

This is probably the best resource I've come across for discussing this subject: https://fsharpforfunandprofit.com/posts/elevated-world/

> So if in another company a man discriminated against a woman, it increases the probability that the same thing is happening to the OP?

This is clearly not what anyone here is saying you should really take a moment to reevaluate your position. We're not talking about one man in one company but a historical and systemic suppression.

Additionally, you'll notice that the person you are responding to does not act or treat their colleagues differently, only that they consider where these noticed actions come from.

It might be silly without evidence. The threshold for silliness would become a lot lower if there were a history of systemic problems and extensive evidence of similar scenarios in the present.

At http://story.ai the editor makes use of an ECS (Shipyard Crate in WASM). The flexibility it affords us has been super powerful particularly in support of constructs that are close to a programming language (values in and out of scope, suggestions and autocompletions, determining whether a "skill" is fully formed for publishing etc)

I haven't given extensive thought to where we diverge from Notion as the comment below mentions them moving away from it, but just wanted to say that your armchair analysis fits with our view.

> Apparently, pair programming places no value on flow.

There are certainly times where flow can be difficult. However I'll offer a few other thoughts.

Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.

I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).

> I just don't see how it's effective

I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:

- I am less easily distracted because I am in flow with someone else

- I am forced to consider my thoughts more carefully because I need to explain them to someone else

- I am confident that someone else can continue this work if I am unavailable

- I enjoy the camaraderie and friendships built with my pairs

- I quickly learn new tools, tricks and ideas from others

- I am able to practice my teaching or coaching skills

- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed

- I take more breaks throughout the day

- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature

- I'm likely to discover something I've missed with a different set of eyes

- I'm likely to take fewer shortcuts, or to be called up on them

- I've become a more effective verbal communicator in the rest of my life

Of course, I can also give you a list of reasons why I don't like pairing, to even it out!

Can you share this research data?

> Is it really true that Pivotal had only n/2 workstations for the n devs?

By and large yes this is true. There were some teams that experimented with odd numbered sizes and others that were split remotely that required more to facilitate all pairing rotations.

> How does such a wonky culture take root in a fairly large organization anyway?

I suppose wonkiness is in the eye of the beholder. The company was simply built around XP, with pairing being a core part of that. I went to Pivotal (2015-2019) because I wanted among other things, to try pair programming from some of the most committed to it. In that way, it's self-selecting. It was baked in throughout the interview process. Sure, there are a lot of senior engineers who will never get on board with pairing, but there also are far fewer companies that commit to it in the same way.

No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.

In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said:

> No, one person is doing things, and another is watching and talking while the other person is doing things.

I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.

In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.

Right, I don't really agree with your interpretation, though I can understand how you might read it that way. As I wrote above, I read it as "take this as a learning opportunity to empathise with others", which I would think leads to a _more_ humane society.

I imagine the downvotes are mainly because the comparison seems pretty off base, regardless of whether one agrees with the good or bad of the original post.

Comparing "you are now in a situation where you may have an opportunity to empathise with difficulties others have had" to "you are trying to build a society where more fortunate people are harmed in the name of sameness" doesn't resonate at all.

Super great write up. This really took me back to my days of working on the container platform behind CloudFoundry.

In particular, we also used to use loop devices [1] but with AUFS mounted on them.

Later we moved over to BTRFS and then Overlay on XFS [2] to help with our unprivileged (security) story.

Also, this was a great piece of technical writing. Thanks for sharing!

1: https://github.com/cloudfoundry-attic/garden-shed/blob/6c5b0...

2: https://github.com/cloudfoundry/grootfs

For anyone looking for a smaller introduction to this book, the author Scott Wlaschin has a talk with the same name: https://youtu.be/2JB1_e5wZmU

It doesn't cover a lot of good topics in the book, but it might whet your appetite.

I might have misunderstood your want but perhaps you'd be interested in where we're going with Storyscript? [1]

We're working on a primarily text, multi-modal "low-code" experience.

Or maybe you're suggesting the other way round, that you want primarily visual but with a way to interact with it in a text based format?

1. https://storyscript.com

I agree with this. I have tried briefly to make use of Result and Option types from https://github.com/cognitedata/Expression, and using match from pampy, in a personal project and while they are quite nice, it just wasn't fun at all compared to Rust.

Rust has a tool called, you guessed it, Clippy, that does very similar things to what you suggest: https://github.com/rust-lang/rust-clippy

The Rust compiler exposes a lot of information, so it's actually quite powerful in my experience.

The person you are responding to is only making the point that the OP's rebase flow is a very different workflow from git-flow. The pros and cons of each approach are significantly different, and the commit history will demonstrate the two different approaches.

What exactly about this incident would scare someone into following the "SJW Agenda", when you can't even guarantee that following the "SJW Agenda" in the CoC would actually protect you?

Nickolas Means has an absolutely wonderful set of talks on themes like this. Particularly relevant here I think, is his talk: "Who Destroyed Three Mile Island?" - which goes through the events that occurred at the nuclear power plant, the systemic problems, and how to find the "second stories" of why failures occurred.

https://www.youtube.com/watch?v=1xQeXOz0Ncs

This reminds me of a time when a colleague and I were investigating some persistent D-State processes that were occurring when container processes were being exec-ed.

Once on the box, we wanted to create a container with utilities in the fs but didn't want to download an image tarball or look through the rootfs layer directories for one to use, so we just bind mounted host root onto another directory, beside the config file we were using.

This worked like a charm. Until we rm -rf'd the config directory and deleted host root in the process.

In our case, fortunately the consequences were minimal as all workloads were stateless. The container scheduler moved all the workloads to other hosts and the host scheduler noticed this VM wasn't responding any more and rolled a new one. The whole thing resolved itself in about 5 minutes with no interaction from us - so that was pretty neat.

I think Gary shared a Twitter related project that was written in this way, but do you have any examples of other projects by any chance?

I agree with you on the stacktrace. The libraries that provide context via wrapping are good but woefully underused.

> Error handling in Go is tedious and there's no visible indication if you forget to do it or don't do it properly so sometimes it goes AWOL

This is also true, though I would expect teams to fail on linting so I don't share the concern. Is there an equivalent for unchecked exceptions (honest question)?

I'll take your word on the performance being better for exceptions, but I'm less convinced that Go's performance is a significant sticking point for the language.

And for me having worked in both, errors as return values have been hands down better. The complexity added by an entirely different flow control has resulted in far more bugs for me to track down than anything else.

Similarly, it's for good reason that there's a whole other class of languages using things like the Result monad over throwing up all over everything.

That's not to say that there isn't better code written in exception based languages, but that your view is pretty myopic. The ergonomics are different in each approach, with different tradeoffs.

I'm in strong agreement with this summary.

Although I don't write Go so much anymore, I had the benefit of working in Go for a few years on a team that developed a strongly shared style. A few years later, one of those team members sent me a package they had been working on, and it was an absolute breeze to understand in comparison to the Rust and TypeScript I had been working on. This is not to knock on Rust or TypeScript, as there are absolutely solutions that are better expressed in those languages, but if I'm honest, the vast majority of software is "plumbing" - get data, manipulate data, put data - and Go is an extremely pragmatic choice for this in my opinion.

A few other thoughts...

I really don't take issue with `if err != nil` and though I like Monadic types, I'll take errors as values over exceptions 100% of the time.

I've also written a lot of CLIs and Go's build process here is superb.

I think the Go community has a strong testing culture, and although I like BDD, the work put into the std test tooling has really helped form that.

> Then they will finally know peace.

No one's claiming that.

More likely the uncivil behaviours go unnoticed by you.

You may enjoy this write up on testing taxonomy: https://blog.7mind.io/constructive-test-taxonomy.html

> Instead create an architectural boundry with a clear public interface. Exercise the interfaces in tests and then check for results on the otherside of the boundary. You might do that with a mock or a fake.

I think mockist (test-doublist really) TDDers would suggest that the architectural boundaries derived from the design pressure are the "correct" public interfaces you're describing here, they just often happen to coincide with class (or your favourite languages equivalent) boundaries.

The pattern often ends up with many one-function role interfaces, orchestrated by collaborators down the dependency tree until you hit value structures, pure functions or external integrations at the edge of the system. In many ways, mockist TDD is a gateway to functional programming.

> And you know this from a job post in a job board/website how?

I don't need to know it from a job board or website because I don't apply to companies that I'm not already familiar with. When I apply to those listings, I already know how I will answer this question, because that's why I'm applying to the company.

> Has anyone been 6, day dreaming in school, 'when I grow up, I want to help people create digital experiences their customers love.'?

No but that's a strawman and I'd be surprised if you don't recognise that.

> My interest in the role is it matches my experience

I doubt that's the only reason. You could have experience doing a billion things but you probably enjoy what you do a lot more than that, and when we break it down, there are almost certainly subsections within what you do now that you enjoy and hope that the company aligns with that. When a listing asks "why are you interested in working here", you hopefully already know and can express that.

There are a large number of ways from location, culture, processes, technical decisions, people, problem domain, etc that you can discover about a company before applying.