C0d3r

Push --force-with-lease is part of my muscle memory since I `rebase -i` so much in my workflow. Why do you think the article should mention it?

I'm sorry you're getting downvoted, but I think this question is legitimate because the book is peddling Kafka as if it's the only way to do event sourcing. Event sourcing is what you should compare with REST APIs, Kafka is one way of doing it, but you can do the same with any database, as long as you have a way to write things in and read things out and organize them, you can achieve event sourcing.

With REST APIs (first few pages of the book), services talk directly with each other, with event sourcing (the rest of the book) services talk with an event store (Kafka in the book) as the intermediary.

fzf can be used as a cool selector in the terminal, it just outputs what you picked from the list, so if you run `ls | fzf`, it will pass the list of files/dirs into fzf, where you can fuzzy search, select and it outputs to STDOUT.

So if you want to edit a file from inside a directory easily, you can do:

vim $(find | fzf)

It's exactly like that, the page runs itself on TiddlyWiki

Which tablet are you talking about just out of curiosity?

> To a large extent, becoming professional is about becoming less sensitive to being wrong.

I agree, but there's nothing to lose in trying to become a better communicator, you're not responsible for other people's sensitivity, but you are definitely in control of what and how you communicate.

I do, TDD gives me such a sense of confidence that now that I'm used to, it's hard not to use.

> Can you describe the practical benefit?

Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up.

> Do you happen to rewrite the tests completely while doing the implementation?

Not completely, depends on how you write your tests, I'm not testing each function individually, I'm testing behaviour, so unless there's a big architectural change or we need to change something drastic, the tests have minimal changes

> When does this approach work for you and when did it fail you?

It works better on layered architectures, when you can easily just test the business logic independently of the framework/glue code. It has failed me for exploratory work, that's the one scenario where I just prefer to write code and manually test it, since I don't know what I want it to do...yet

Interesting, I guess it depends on the person and on the thing you're learning like someone else mentioned. I do think you need some time by yourself to really go deep at your own speed to learn something.

Pairing and mobbing are not fads, they've been around for a while and in my experience they've been very useful, I'd recommend you try it with someone with experience with it.

> At the same time, real work is not getting done. Meaningful work is usually done quietly and in solitude.

You can do great work by pairing or mobbing too. Being isolated is good, but it's harder to learn new things working by yourself.

Easier on the eyes, at least for me.

Bat works the same way as ls when it's being piped. But it has better default features than cat, the syntax, numbers and the pager. if the file doesn't fit the screen, it becomes paged, so you don't have to do the whole: `cat file.txt` (too big), `view file.txt`