4 ms·

Man, I thought this was going to be an article on better code reviews and how to get better feedback from people you work with regarding your performance. Inst

Man, I thought this was going to be an article on better code reviews and how to get better feedback from people you work with regarding your performance. Instead the article is some strange "self-help"/"hustle-hard" blogspam, quoting Malcolm Gladwell and shading a picture of the normal distribution and pretending it's arrived at some brilliant insight.

herodotus 8y ago
Actually, I was sceptical to begin, and I agree that it is not an in-depth article, but I think the general principles outlined are good ones for someone to follow.
- vvanders 8y ago
  Yup, there's a fair bit of stuff that's intuitive to a seasoned engineer but it's great to have specific terms to talk about and describe it in. The "diffuse" vs "focused" thinking was a great example that I'm definitely going to use elsewhere.
  - kossmoboleat 8y ago
    I first heard about it in the excellent learning how to learn online course: https://www.coursera.org/learn/learning-how-to-learn https://www.coursera.org/learn/learning-how-to-learn
mcfunk 8y ago
I'm all for having THAT discussion. Things that come to mind - - treating PRs as communication and ensuring the person reviewing has the information they need to check for what you coded. - Building a culture where discussion around alternate ways of doing things ('this doesn't block merge, but...') is accepted and expected (without becoming hostile/nit-picky or devolving into bikeshedding -- if it's not blocking, the submitter can always just merge) - Have brown bags to talk about technology in freer, non-deadline-constrained setting (sparks ideas, gets people building tech communication skills) Really interested to hear what thoughts others have on this.
- derefr 8y ago
  > treating PRs as communication I kind of wish that there was a type of thing like a PR, but marked in a way where you couldn't actually merge it. It'd still get built by CI, if such a thing was configured; but the point of the submission of such a "proposal with prototype" object would be to discuss whether the design represented by the prototype implementation is a design worth going with. The actions applicable to such objects would be "accept and close" or "reject and close." You'd be able to have several of these objects that live under a given issue (i.e. several potential solution-designs to the same problem), and—as long as the issue has at least one proposal-with-prototype object under it—the issue would be in a "pending" state until one such proposal object was Approved, and Approving one proposal object would Reject the others. The point of this would be to replicate the thing that people go through with design discussions on mailing lists when they send in code samples to explain their designs—but with those code samples being working, buildable code, such that the properties of the design proposal can be tested against the current implementation and against any alternative proposals. You could call these objects "RFCs" :)
  - ChrisSD 8y ago
    I was just about to link to something like this[0] before I read your last sentence. [0]: https://github.com/rust-lang/rfcs/pull/911 https://github.com/rust-lang/rfcs/pull/911
  - nine_k 8y ago
    Hmm. I suppose your CI and code review tools allow code on branches different than master? So you can directly use them to show a what-if PR. I did; it worked, that is, sparked a discussion and led us to designing things in a better way.
    - derefr 8y ago
      Yeah, I was picturing GitLab's CI/CD workflow here, where the RFC objects would get Review Apps built from them. My objection to using PRs for this is that people think the point of a PR is to merge the code, and people tend to nitpick the code during code-review with the goal of making it clean enough to merge. The idea of a separate RFC object is that, unlike a PR, you literally cannot merge an RFC, so there's no temptation to nitpick, or really to talk about anything other than the design. It much more closely mimics the social mores of a mailing-list thread discussing a code snippet. Also, being able to explicitly track Approved and Rejected RFCs on a system level would be nice, to know what discussion needs to be referenced when doing the final implementation. If you just used "what-if" PRs, both the chosen and not-chosen designs' PRs would just end up in the Closed state, and would show up equally in search. Ideally, Rejected RFCs would be filtered out of search by default.

herodotus 8y ago

Actually, I was sceptical to begin, and I agree that it is not an in-depth article, but I think the general principles outlined are good ones for someone to follow.

vvanders 8y ago
Yup, there's a fair bit of stuff that's intuitive to a seasoned engineer but it's great to have specific terms to talk about and describe it in. The "diffuse" vs "focused" thinking was a great example that I'm definitely going to use elsewhere.
- kossmoboleat 8y ago
  I first heard about it in the excellent learning how to learn online course: https://www.coursera.org/learn/learning-how-to-learn https://www.coursera.org/learn/learning-how-to-learn

mcfunk 8y ago

I'm all for having THAT discussion. Things that come to mind - - treating PRs as communication and ensuring the person reviewing has the information they need to check for what you coded. - Building a culture where discussion around alternate ways of doing things ('this doesn't block merge, but...') is accepted and expected (without becoming hostile/nit-picky or devolving into bikeshedding -- if it's not blocking, the submitter can always just merge) - Have brown bags to talk about technology in freer, non-deadline-constrained setting (sparks ideas, gets people building tech communication skills) Really interested to hear what thoughts others have on this.

derefr 8y ago
> treating PRs as communication I kind of wish that there was a type of thing like a PR, but marked in a way where you couldn't actually merge it. It'd still get built by CI, if such a thing was configured; but the point of the submission of such a "proposal with prototype" object would be to discuss whether the design represented by the prototype implementation is a design worth going with. The actions applicable to such objects would be "accept and close" or "reject and close." You'd be able to have several of these objects that live under a given issue (i.e. several potential solution-designs to the same problem), and—as long as the issue has at least one proposal-with-prototype object under it—the issue would be in a "pending" state until one such proposal object was Approved, and Approving one proposal object would Reject the others. The point of this would be to replicate the thing that people go through with design discussions on mailing lists when they send in code samples to explain their designs—but with those code samples being working, buildable code, such that the properties of the design proposal can be tested against the current implementation and against any alternative proposals. You could call these objects "RFCs" :)
- ChrisSD 8y ago
  I was just about to link to something like this[0] before I read your last sentence. [0]: https://github.com/rust-lang/rfcs/pull/911 https://github.com/rust-lang/rfcs/pull/911
- nine_k 8y ago
  Hmm. I suppose your CI and code review tools allow code on branches different than master? So you can directly use them to show a what-if PR. I did; it worked, that is, sparked a discussion and led us to designing things in a better way.
  - derefr 8y ago
    Yeah, I was picturing GitLab's CI/CD workflow here, where the RFC objects would get Review Apps built from them. My objection to using PRs for this is that people think the point of a PR is to merge the code, and people tend to nitpick the code during code-review with the goal of making it clean enough to merge. The idea of a separate RFC object is that, unlike a PR, you literally cannot merge an RFC, so there's no temptation to nitpick, or really to talk about anything other than the design. It much more closely mimics the social mores of a mailing-list thread discussing a code snippet. Also, being able to explicitly track Approved and Rejected RFCs on a system level would be nice, to know what discussion needs to be referenced when doing the final implementation. If you just used "what-if" PRs, both the chosen and not-chosen designs' PRs would just end up in the Closed state, and would show up equally in search. Ideally, Rejected RFCs would be filtered out of search by default.