catwind7

formalized expression is detail and while that detail may not be complex for a programmer it can be completely meaningless to a user. I agree with you in part but i think worth recognizing that if we all had this attitude then we wouldn't be building business applications / consumer apps for non-developers

whether you think it's complex or not, we're hiding information on procedural tasks from users in the products we build because information to someone who is not a programmer IS complex

This line stood out to me:

> “As it stands now, there seems to be a tradeoff between ease-of-use and control, and until someone figures out how to remove that tradeoff, there will always be a need for engineers who can fully manipulate software to meet the full range of use cases businesses (and individuals) need.”

we're constantly making this type of tradeoff as developers. It's not just a decision we make at the beginning of a project where we look at the requirements and say hey no-code might be the way to go here.

have you written a function for a library to hide information / details of how something works? that's a tradeoff between ease and control for the client.

now expose that through a GUI with some params and now you have "no-code".

sometimes that's ok. it's nice to have options!

wow, this is scary

i better not tell employers that I haven't touched a physics text book in the last 10 years

I really like how she connects the necessity of the software for customers to release risk management. It's a very user-centric view which I like. Helps me understand release processes I've experienced much better from a business angle too. It makes sense that with few vendors who will experience high degrees of pain from bad releases that it tends to encourage more conservative, move-slow-and-don't-break-shit mentality.

what if you have plenty of ideas but you run out of money because you can't ship fast enough? :D sorry couldn't help it

on more serious note - I'm curious what you mean by run out of ideas. do you mean product literally not having any ideas? that seems hard to believe. Or do you mean ideas just don't gain traction? I've seen that happen a lot more.

this convo has made me realize that our terms for testing do not pair well with actual testing practices, which i find easier to conceptualize in terms of "coarseness" relative to fundamental units of work in a system as opposed to this binary notion of unit versus integration.

i might write a blog post about this!

by claiming when something stops being a unit test, you have to define what a unit test is. Now, I do think there is a good, reasonable definition of a unit test and it's looser than yours. A single function that reaches out for an API call via another function and does N other steps of compute that has the API call mocked is still a unit test.

can it be a smell? maybe, that depends. Does it break your idea of single responsibility? maybe. Is it an integration test? not ... really because the test is primarily designed to verify the behavior of the rules of the function and not its interaction with a third party system.

so while you can argue that mocking is a smell in that context, that doesn't change the fact that it's still a unit test!

all that said, one can still make a case that the fundamental unit of work for a given context is not really a function, and so testing functions are actually integration tests! so I'll also grant that these definitions can be very context sensitive..

what does unit testing have to do with whether or not you instrument the test with fake responses? those points of contact that you're mocking out at the perimeter, that data will sometimes need to reach a particular function through a collaborator...which you may want to mock?

sometimes the dependency is not a third party, but it may be code that requires a ton of setup (as mentioned in article) that's not worth the cost. it may make sense to just mock at that point to actually test the rest of the business logic in a function. I don't think i'd say "well, that's no longer a unit test!". You can argue that it's a more brittle test, sure.

update: also, i'll be honest that comments like this really rub me the wrong way. This type of dogmatism around what is or isn't unit testing (which is a pretty ill-defined phrase in industry) is something that needs to stop. I think it hurts new practioners in the field who are mislead into black and white thinking.

I agree with the first part of what you said, but I don't think plain listening is a "new paradigm", albeit I'll grant that it's probably a skill that can be improved.

to circle back to the original topic of understanding the problem, a big part of that is being observant and attentive to the needs of users. In that context and using your framing of this in terms of cost and resistance, I agree that simply talking and stating opinions is far easier than shutting up, talking to users, and gathering real information about what they actually want