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
> “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".
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.
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
it really sucks and I feel it's gotten worse with zoom. Sitting in retro meetings in the past year I've definitely noticed an uptick in people just talking and not actually responding to what someone just said. very frustrating.
> One may argue that a motivated and smart student can overcome such obstacles and get her foot in the door by attending such schools. But then the challenge is flipped: not many such students need to attend such schools.
i guess it question is is there enough such students who can overcome these obstacles who are also willing to fork over X tuition? they may not need it per-se, but I think you may be discounting the value of the pre-existing networking leverage these schools have over individuals that may have no network in data science related work
what I've seen a lot over the years is that an engineer gets asked about timeline, thinks for about 10 seconds, blurts something out, then if it's off (too short) they bust their asses / cut corners trying to hit their own estimate. Since estimates are usually optimistic, I tend to see a lot of over time and/or corners cut.
there's certainly an element of personal pride in that dynamic I think. You're asked to give an estimate. You give it. You now feel like you've staked your professional rep to it.
the author shares his method for coming up with estimates, and it looks like an offline process that involves more than a gut check. I think for sufficiently large features we (eng managers, eng peers) should encourage engineers to _not_ give on the spot estimates given we know how difficult it is to estimate.
it seems to come from the same place of wanting a simple rule to pattern match against some problem space so we don't have to think too hard about it every time.
also ... the author cites sam altman as evidence that his thinking is on the right track, but can you really argue against a statement like "Almost everyone I’ve ever met would be well-served by spending more time thinking about what to focus on"? that's about as close to a one size fits all statement as "almost everyone who succeeds thinks"
i sometimes wonder if this comes from a place of fear. Maybe we're scared of really listening to customers / users / colleagues / stakeholders and so we invent these rules to hold ourselves accountable for what's probably pretty obvious from the outside
I can relate to a lot of this. One thing I learned about myself recently is that I tend to default to programming because it practically guarantees that I'll feel good (dopamine from making things work, fixing bugs). Since I don't have many other hobbies that guarantee similar reward, there's not much of an incentive for me to do anything different whenever I'm feeling antsy about sitting around and not feeling productive.
one thing I've been doing with the help of some therapy recently that's somewhat helping is scheduling time (1 hour) to NOT program. No expectation of actually doing anything and accepting any uneasy feelings that arise. Just making sure that I make the time to tune in to feelings / thoughts without the option of picking up my computer as a sort of pacifier.
first time I did this, I just sat nervously for 30 minutes until I got bored and then looked for problems around my house to fix (which took 2 hours and was pretty satisfying). After a few rounds of this I noticed myself acting on small, non-programming interests outside my scheduled times.
just figured I shared in case others are feeling same and want something to try :)
agree with the adaptability of change requests from clients, but i would say only insofar as the design issues you're mentioning are actually addressed as quickly as they are surfaced. Otherwise this type of building eventually grinds to a halt.
another commenter sort of hinted at this, but this type of process has a downside of prioritizing short term design decisions that lead to working code. It takes time and sometimes a lot of thought to think about the system and the problems deeply and ask yourself if you've created the right primitives.
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