Patches from way back when

I'm cleaning up my repos, inlining them here.

patch1 (visual diff), click to expand for text diff

```patch From f5e27885caf014d5d0dcfc8214ed430ba076a1eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=B3bert=20Papp=20=28TWiStErRob=29?= Date: Sat, 9 Mar 2019 13:09:43 +0000 Subject: [PATCH] typo --- content/post/how-we-misuse-mock-for-android-tests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/post/how-we-misuse-mock-for-android-tests.md b/content/post/how-we-misuse-mock-for-android-tests.md index e22c173..ab0c7bc 100644 --- a/content/post/how-we-misuse-mock-for-android-tests.md +++ b/content/post/how-we-misuse-mock-for-android-tests.md @@ -79,4 +79,4 @@ So, don't make too many verifications on your mocks and don't mock types you don 1. "Growing Object Oriented Software Guided by Tests," 319. -1. I actually think following these two pieces of advice leads to a virtuous circle: if you only mock types you own, then you have to define types in the language of your application. This makes your test less coupled to implementation details, as stubbing these types in the arrange step of your unit test will actually just feel like you're declaratively specifying preconditions in the language of your application. Conversely, there's a vicious cycle caused by mocking types you don't own. You're tests are going to be more tied to implementation details and because mocking types we don't own winds up being complicated, its especially painful to change tests when implementation details need to change. +1. I actually think following these two pieces of advice leads to a virtuous circle: if you only mock types you own, then you have to define types in the language of your application. This makes your test less coupled to implementation details, as stubbing these types in the arrange step of your unit test will actually just feel like you're declaratively specifying preconditions in the language of your application. Conversely, there's a vicious cycle caused by mocking types you don't own. Your tests are going to be more tied to implementation details and because mocking types we don't own winds up being complicated, its especially painful to change tests when implementation details need to change. ```

patch2 (visual diff), click to expand for text diff

```patch From b4c394c1fa98bc2b69b83fc5df2f18d6802f51a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=B3bert=20Papp=20=28TWiStErRob=29?= Date: Sat, 23 Mar 2019 12:44:03 +0000 Subject: [PATCH] Fix some typos in "programmer-passion-worse" --- .../post/how-passion-for-programming-can-make-us-worse.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/post/how-passion-for-programming-can-make-us-worse.md b/content/post/how-passion-for-programming-can-make-us-worse.md index 7e7eb9b..07ad50f 100644 --- a/content/post/how-passion-for-programming-can-make-us-worse.md +++ b/content/post/how-passion-for-programming-can-make-us-worse.md @@ -58,7 +58,7 @@ The claim isn't that technical debt doesn't matter. It matters. The claim here i Consider two views on how involved programmers should be in non-programming activities. -On Joel Spolsky's view, developers ought to isolated from the business via a "developer abstraction layer." In fact, he says, "Management’s primary responsibility to create the illusion that a software company can be run by writing code, because that’s what programmers do." +On Joel Spolsky's view, developers ought to be isolated from the business via a "developer abstraction layer." In fact, he says, "Management’s primary responsibility to create the illusion that a software company can be run by writing code, because that’s what programmers do." Marty Cagan has a _very_ different view. He says, "if your programmers are only programming, you're only getting half their value." Support-driven development --- where software developers actually do customer support --- has even become a thing at companies like Zapier[^1] and Wufoo[^2]. @@ -88,11 +88,11 @@ Some are fine with this. I once met an engineer at Yahoo! who said that "develop >"We all tend to tie our self-esteem strongly to the quality of the product we produce…A market-derived quality standard seems to make good sense **only as long as you ignore the effect on the builder’s attitude and effectiveness…"** -This is a strong claim that I doubt is entirely true, but to the extent that it is true, it would mean the company wastes money satisfying our desire quality insofar as our quality standard outstrips the market demand for quality. +This is a strong claim that I doubt is entirely true, but to the extent that it is true, it would mean the company wastes money satisfying our desire for quality insofar as our quality standard outstrips the market demand for quality. This is especially problematic in a startup. An early stage startup is a war to survive, so when our passion for programming drives us to insist on higher quality than our customers demand, we wind up acting like soldiers who have gotten stuck in the trenches polishing our rifles because it makes us feel better. ✨ 🔫 ✨ -I’m not saying that there’s anything wrong with caring about quality or interesting problems. I just think that at a startup, its tough if programmers are focusing on these things over survival. +I’m not saying that there’s anything wrong with caring about quality or interesting problems. I just think that at a startup, it's tough if programmers are focusing on these things over survival. ### Excessive Specialization @@ -104,7 +104,7 @@ This is because preparing the egg takes the most time of all the steps. 🍳 Reg An employee at the above diner who believed that improving her coffee prepping skills would actually help the business would be mistaken. The same applies to programmers who think that specializing in their non-limiting-step discipline is good for the business. Programmer passion for her "favorite stack" can blind her to this. -There are _plenty_ of cases where continued specialization will in fact yield benefits to the business, even if programmers are specializing in a non-limiting-step discipline/stack.[^3] A specialist may be able to product higher quality code in less time that contains less bugs, which could lead to increased referrals for your software product. Moreover, deeper knowledge can lead to a richer view of what's possible with a given stack, which can better inform product and project management decisions. +There are _plenty_ of cases where continued specialization will in fact yield benefits to the business, even if programmers are specializing in a non-limiting-step discipline/stack.[^3] A specialist may be able to produce higher quality code in less time that contains less bugs, which could lead to increased referrals for your software product. Moreover, deeper knowledge can lead to a richer view of what's possible with a given stack, which can better inform product and project management decisions. _However_, at some point, further investments in quality and keeping up with all the newest approaches to solving problems with our stacks will yield diminishing returns 📉, and I suspect that this point occurs much sooner than a lot of us realize. ```

kmdupr33 / kmdupr33.github.io

Patches from way back when #1