sodapopcan

It's pretty common, but I guess just for English people (or maybe just in Canada as hinted in another post?)? Either way I'm all for eliminating acronyms in public posts!

So fun.

Photography is neither cheap nor low effort. Ask AI about it.

Not in the case of Elixir. It’s a play on BEAM processes being revived.

I do have a blog post about this sitting around along with all my other mostly completed posts. Finishing this one would be great as it's a topic I'm very passionate about!

Our stories were broken up to take worst-case-scenario 5 days, the ideal was 1-3, of course. Maybe would be multi-day stories so yes, if something ended up taking 5 days it was possible the whole team could have touched it (our team was only 6 devs so never more than 6).

In short, there are the usual hurdles with pairing, the first one being that it takes some time to catch your stride but once you do, things start flying. It is of course not perfect and you run into scenarios where something takes longer because as a new person joins the ticket, they want to tweak the implementation, and it can get pulled in different directions the longer it takes. But this also gets better the longer you keep at it.

There are lots of pros AFAIC but a couple I like: you develop shared ownership of the codebase (as well as a shared style which I think is neat), ie, every part of the app had at least a few people with lots of context so there was never any, "Oh, Alice knows the most about that part of so let's wait until she's back to fix it" kinda thing. There is no "junior work." When a junior joins the team they are always pairing so they ramp up really quickly (ideally they always drive for the first several months so they actually learn).

Another downside would be it's bad for resume-driven-development. You don't "own" as many projects so you have to get creative when you're asked about big projects you've led recently, especially if you're happily in an IC role.

And also yes, if there is a super small task that is too small to pair on, we'd have a reviewer, but often these were like literal one-line config changes.

We'd also have an independent reviewer whenever migrations were involved or anything risky task that needed to be run.

This is what I assumed and starting with the comments was very confusing.

The problem with most people's experience with pairing is that they are given no guidance on how it should be done outside of "just work with someone."

In terms of under-documentation, I didn't really find that. Most of my jobs have either been way under-documented, way over-documented (no one reads it and it gets outdated). Again I'll say that I find switching pairs daily is key with no one person stay on for more than 2 days in a row (so if a story takes three days to complete, the two people who finished it are not the same two who started it). This keeps that internal knowledge well-spread.

But you're right, if you're dealing with overly excited/stubborn folk who refuse to play ball, that's obviously not going to work. Conversely, if you have a trusting team and someone is having one of those days where they feel useless and unmotivated, pairing can turn it into some kind of useful day. This could be because your colleague gets you excited or, if you have high trust, I've literally said and had people say, "I'm not feeling it today... can you drive all day?" and you're still able to offer good support as a navigator and not have a total write-off of a day.

To the point of improving an otherwise bad day, one of the more interesting arguments against pairing I've heard is that companies use it to make sure everyone is always working. That would indeed be sad if that was the motivation.

Again, if you rotate pairs daily this doesn't happen. You could argue that creates a "team bias" but I call that cohesion.

Ah ya, death-by-a-thousand-cuts is certainly a charitable take!

> It does not eliminate code reviews.

Yes it does. There are many ways to do things, of course, and you can institute that there must be an independent reviewer, but I see this is a colossal waste of time and takes away one of the many benefits of pairing. Switch pairs frequently, and by frequently I really mean "daily," and there is no need for review. This also covers "no fixed responsibilities" you mentioned (which I absolutely agree with).

Again, there are no rules for how things must be done, but this is my experience of three straight years working this way and it was highly effective.

Complaining about including a ticket number in the commit is a new one for me. Good grief.

Yep, eliminates code reviews altogether. Unfortunately it remains wisely unpopular with perle even saying “AI” can be the pair.

haha, you've never seen any? It's pretty classic HN. If someone thinks a comment is false the reply will look something like: "No. What you really meant to say is..." and often times the "No." will be its own paragraph.

That and replies that start with "No"

What if someone else uploads your work?

"Everyone is different" is my point. Face to face once in a while is nice, though I don't care so much about having it very often with my colleagues in a professional setting.

For me, electronic chat is better most of the time.

Like the post overall, but the last section is a bit weird for "confessions" as it's all HIGHLY subjective. For example, I worked at a company where no one worked from home and we paired 100% of the time. When COVID hit, we started pairing over Tuple and I found it to be a superior experience to pairing in person (Tuple's drawing and attention drawing tools are far more accurate than my finger, I can use my own keyboard the odd time I want to control my pair's computer, and there are no office distractions of other pairs in the same room are benefits that come to mind). I continued to enjoy (and prefer) it for the 1.5 years I stayed after lockdown.

So long as you are enabling folks to pump out AI garbage, I'll be pumping out my garbage predictions, thank you much.

That's not what they're saying.

The easier "AI" gets to use (as it is being "promised" it will), the quicker a skilled engineered is going to be able to adapt to it whenever they give up and start using it. They'll likely be ahead of any of those previous adopters who just couldn't resist the allure of simply accepting whatever is spit out without thoroughly reviewing it first.

This is one of my favourite talks ever! Glad to see it here (probably again).

Also, Erlang (non-explicitly) mentioned!

Also, I'm super glad we never got those "APIs" he was talking about. What a horrid thought.

Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.

So don't use Google products. I'm not trying to be snarky but, other than at work I suppose, it's not that hard to avoid them.

> Of course, that assumes that you write your functions so that they can be converted into iteration!

I was indeed assuming this, however due to my lack of compiler knowledge, not explicitly writing your functions--at least in the classic way--doesn't necessarily mean you Erlang functions won't be optimized. See section 2.3 [0]

Though again, I don't know shit about compilers and while I can imagine what callER optimized calls could look like, I would need some examples!

[0] https://www.erlang.org/docs/19/efficiency_guide/myths

It's quality isn't your main metric then ya, knock yourself out.

> just as long as you don't run out of call stack

And with tail-call you don't even need to worry about that :)

It depends on how technical you want to get. It's certainly not a loop in the classic sense, like a for loop etc. Like there are no `continue` or `break` semantics and you can't return out of it (and yes yes of course you can still do all that stuff, just not with dedicated keywords). I call it a loop, though. Whenever I make a lil' server in Elixir (mostly always for teaching) I always call the function `loop`:

    defmodule Server do
      def start_link do
        spawn_link(&loop/0)
      end

      defp loop do
        receive do
          msg ->
            IO.puts(msg)

            loop()
        end
      end
    end

Although in Erlang it's closer to an equation with assignment being a side effect. `=` is the pattern matching operator.

    Eshell V15.2.6 (press Ctrl+G to abort, type help(). for help)
    1> X = 1.
    1
    2> X = X.
    1
    3> 1 = X.
    1
    4> X = 2.
    ** exception error: no match of right hand side value 2
    5>

In my experience it's still very possible to write many, many lines lines or utterly shit FP code, but I know what you're saying.

Ha, great answer! Of course there are a lot of nuances to that but I don't want to get into beating dead horses.

> There are also times where it isn't.

Should this have the "Significantly so" qualifier as well?