hmeh

12 ms·

61.
You can't be receptive while being defensive(twitter.com)
2 points by hmeh 3y ago|1 comments
62.
Purported Advantages of Monolithic Repositories (Monorepos)(github.com)
3 points by hmeh 3y ago|0 comments
63.
by hmeh 3y ago
sbellware's reply says just about everything of import, but from a tactical perspective, yes, we do push to master. Sometimes we push regular commits and sometimes (if we branched) we push merge commits. We have hundreds of repos and i
64.
by hmeh 3y ago
This and other concurrency problems often fall into the “you just have to know how to not get it wrong” camp. If you know to write an automated test for it, you probably know enough to reason about it and get it right. For very important th
65.
by hmeh 3y ago
Relevant, not all logs are ledgers. https://twitter.com/sbellware/status/1742653635387941099
66.
by hmeh 3y ago
Totally agree that it has lost its meaning. We call things “incomplete work” that are, well, incomplete work. I wrote more about it here: https://github.com/aaronjensen/software-development/blob/mas... Also t
67.
by hmeh 3y ago
In case you are interested: https://www.nngroup.com/articles/first-2-words-a-signal-for-... https://www.nngroup.com/articles/text-scanning-patterns-eyet... https://www.nngroup.com/
68.
by hmeh 3y ago
> Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. One has to be able to understand an analogy for the point the person is trying to make -- it's not an equivalence. Obviously most softwar
69.
by hmeh 3y ago
sbellware may have more to add, but there isn't a name for it. We focus more on the "it" than the branding of it. We do use the word "continuity" to describe our goal: https://github.com/aaronjensen&
70.
by hmeh 3y ago
> I like to be able to read the commit line following the sentence: "This commit shall ...". I'd guess there's a near zero chance you do this when looking at (scanning) a list of commits. This is a mnemonic for writin
71.
by hmeh 3y ago
> you acknowledge that you hold a minority opinion An opinion being minority has no reflection on whether or not it is correct. See hand washing in the medical profession before it was understood, or batch sizes in the automobile industr
72.
by hmeh 3y ago
Again, I was responding to this particular text: "And the work does an action on the code." You can interpret that the way that you interpret it. I saw it as a part of a wider tendency in the development community and responded to
73.
by hmeh 3y ago
I was responding to the author of the comment I was responding to, who was anthropomorphizing the commit itself claiming that it did something. I agree that the person who write the code is irrelevant, though I realize that in a different
74.
by hmeh 3y ago
Very much agree. I've seen it leak into conversation in slack too... "Hey, I have a question about JIRA123, should we use blue for the button?". There's no greater way to tell someone you don't care about their time
75.
by hmeh 3y ago
> What's your evidence or supporting research? We didn't need it. It was based on a-priori knowledge. For example, we don't write email subjects like: "Convey information about new release", or "Ask question
76.
by hmeh 3y ago
What if there was another way to handle things like #2? What if you got everyone that needed to be there in the same "room" and had a synchronous conversation in order to resolve all ambiguity? We don't call them tickets, bec
77.
by hmeh 3y ago
Point of order, PRs get lost too. Git repositories can be moved from GitHub to GitLab, or tar'd up and sent in an email when a project gets handed off to its new maintainers. We try to keep things that matter in text files in repositor
78.
by hmeh 3y ago
I'll offer a perhaps controversial perspective. What if only people that had context did reviewing? As in, what if when someone needed a review, it was their job to ensure that the reviewer had the context necessary. That is, it was &q
79.
by hmeh 3y ago
Author here. I chose two real sets of commit messages rather than to fabricate one. Fabricating one may have made the second list easier to scan -- you'd already know what you were looking for and you would have some familiarity with t
80.
by hmeh 3y ago
Author here. Thank you, updated. We don't tend to put much in the commit messages themselves. The code often speaks for itself (and if it doesn't, it isn't likely that the author would have had much more to say about it at th
81.
by hmeh 3y ago
Honestly, we have so many repositories and such high communication between work cells that merge conflicts are exceedingly rare. If someone did change something out from under me, I could very well see myself doing my work over on top of th
82.
by hmeh 3y ago
Indeed, and since we don’t do pull requests (we pair, mob, and/or do live code reviews), the after-the-fact git blame or the git log to see what has changed recently is what tends to matter. I agree that when I did PRs I didn’t tend to
83.
by hmeh 3y ago
Oh, we’d be fine without it. It just augments.
84.
by hmeh 3y ago
I'm trying to imagine my commits coming alive and doing things to my code. I think you may be taking the "When this commit is merged..." thing a bit far, as commits don't actually do anything. They just are. We don'
85.
by hmeh 3y ago
Got it, thank you for the links. As I suspected, we just don't have these problems. Rather, we have other things that cover these needs when they arise that we have full ownership of (i.e., it won't matter if our issue tracker is
86.
by hmeh 3y ago
It was a design decision, and like most design decisions, it was based on first principles and a-priori knowledge. If we had to base all of our design decisions on data and benchmarks, we wouldn’t be able to design anything. I can assure yo
87.
by hmeh 3y ago
I tend to think it's better to have merge conflict changes be in a merge commit. That way the original commits are still present and if there was a mistake made, it'll be in its own commit. Contrast that w/ rebasing, where th
88.
by hmeh 3y ago
Author here. We have actually managed to use the same task tracking tool for the three years our project has been running: Linear. We don't do pull requests, and we don't put our work item number in our commit messages. I can coun
89.
by hmeh 3y ago
Author here. You're well within your rights to believe it is personal preference, but it's somewhat hard to refute the fact that it's easier to scan lists when you put the most significant (i.e., the part that varies the most
90.
by hmeh 3y ago
Author here. The psychology portion isn't subjective -- things are easier to scan if the more important part is first. One would have a hard time refuting that. Also, there is some familiarity bias that comes into play when reading a c

More ›