Are you interested in working on a text editor? If so, I have an idea I plan on implementing myself for fun: a clone of HeyNote with some added functionality. HeyNote is a simple buffer that consists of blocks. It's useful when you just want to note a simple block of text (an SQL query, log output, test data) but you are not interested in structuring it. What HeyNote lacks is the ability to add title and tags to blocks. It's not an alternative to other note taking applications. It is just a buffer with unrelated blocks in it.
That's explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I'm sure he knows about hg bisect) there must be a reason he is not preferring "bisect debugging," for example.
Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it "bisect debugging."
Watching Brandolini is fun. He always have fun slides to look at and a humorous way to express his ideas. This talk is no exception. There are two things I would like to highlight:
- Brandolini thinks using Lo-Fi tools (like sticky notes, pen and paper) is superior to digital alternatives because when using them you focus is modelling instead of tidying the diagram. He says: "Digital tools are changing your brain priorities. I enter a session to model, and I find myself aligning rectangles and making arrows clear."
- Following the domain expert wherever they go is not necessarily a good idea. In many cases, the domain expert will push for a quick fix in the system instead of aligning the code base with the business and that will not be beneficial in the long run.
Great news! Looking forward to testing it.
The book was published in 2010. And for a 13 year old book it certainly feels old. This is a compilation of short articles written by several people. And they generally do a good job of articulating their thoughts, but I cannot say it's full of gems, or anything. There is obviously some good advice. After all they are all experienced people with a good understanding of the field. But there are also sentences like "Do not only measure test coverage, but automatically check the results, too. Again, break the build if test coverage is too low." or "Have a regular code review day each week. Spend a couple of hours in a review meeting." So... I think it makes good light reading. You can read a single of these 97 "things" in a couple of minutes. But I wouldn't keep my hopes very high.
BTW: The book is available in GitHub: https://github.com/97-things/97-things-every-programmer-should-know
Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message
Doesn't happen very often, but I'm glad we have a better solution to this now.
Please consider posting language specific questions to language specific communities in the future. For example, [email protected]
I think what Cargill is saying is that the last 10% of the code takes as much effort as the first 90%. And he is humorously referring to all the overtime people have to put in to get things done on time. That's why it adds to 180%.
This sounds more like a Github question.
Reading the manual? That's cheating!
I’m not sure you realize how “engineering disciplines” operate as crafts.
From the comment you are replying to:
[...] it’s not because what we do doesn’t have an element of craft in it, it’s because the concept of craftsmanship is not enough to explain what we do.
these comments on “operate like an engineering discipline” are mostly sourced from a cargo cult mentality
I have nothing to say to this. Have a nice day.