I guess since the workflow (very almost) requires the use of force pushing (with or without lease), it feels like the article hasn't presented a complete workflow people can follow, and so is a bit incomplete.
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:
> 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.
Yes but in this discussion it’s quickly become obvious that the listener is responsible for assuming good faith on the part of the questioner, because any phrasing can be interpreted as “I’m smart and you’re dumb.” Being professional is having the maturity to listen to answers when you ask questions.
Now, in the case of unsolicited advice, it may just be the questioner showing off. There’s no phrasing that will help make a person feel good that they were used to stroke someone’s ego.
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
> 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
Totally with you on this, when I am clueless about the what/how, I throw a bit of exploratory code and test it manually or semi-automated fashion. But once the learning has happened I will use the acquired knowledge to feed a proper TDD cycle to do it properly now that I know a little better.
> 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.
Isn't this just the benefit of tests, not necessarily TDD?
Yes, it's a welcomed side effect of TDD'ing, TDD is more of a design tool. But also I have experimented with writing tests before/after the implementation. Code with tests written first seemed to always be just to the point and get one in the mindset of thinking ahead of your edge cases and pin them down
Depends on the things. Another person might be able to share a few tricks with you: you may not know that you can drag the lower corner of an excel spreadsheet cell to copy formulas, for example, or that you can use "cw" to change a word in vi. On the other hand, learning something like relational database modeling or functional programming requires dedicated focus that another person is probably going to get in the way of.
Some people thrive in that kind of environment (XP and all that), I know it sucked the soul out of me the one time it was forced on my team at a prior employer.
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.
I generally do not work well if there's someone staring at me as I work. I also have my own, high-productivity, quirky ways of using computers that mostly only work for me in solitude.
>Being isolated is good, but it's harder to learn new things working by yourself.
Code reviews I feel provide a good avenue for learning how others have done things.
I've hit blocks in the past while working by myself however I feel part of learning is hitting a block over and over. Only once you truly grasp why other solutions don't work does a new novel solution really fit in completely. Moreover unless you truly try to solve it yourself you don't develop the skills to solve problems.
