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

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 :)

mixed feelings about this not being the top comment

fantastic :)

agree with this ^. Pretty sure the book was written with STEM (but really, comp sci) new grads in mind

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.

this made me chuckle

When tech debt sand gets in the software delivery gears, the allure of vendors increases

Well put. Could not have said this better myself. I've experienced situations where the tech debt sand is a consequence of fairly unique business and internal system constraints. The allure of vendors did increase and the company did eventually research vendors, but nothing addressed our snowflake use cases perfectly.

I don't think that's necessarily a positive reflection on our product though. If anything, the lesson I take from that is to build your business processes and teams to reduce as much accidental complexity as possible.

Looks great! :thumbsup:

different companies need different skills and it changes even as a company grows. Part of the frustration about this entire process is that it feels very cookie cutter and sort of like a lowest-common-denominator type effort on behalf of companies.

Huge companies like google are for the most part hiring people they can slot into almost any team in the org so it makes sense for them to place less emphasis on tooling expertise. They have plenty of time and money to upskill employees.

The same can't be said for the vast majority of consumer start ups that really just need people who can rapidly prototype.

Of course those groups are not mutually exclusive, I just think it's sad that everyone has adopted the approach that works for a select few companies

Most places will also probably have you spending a good chunk of time maintaining legacy code rather than inventing entirely new business units / products / platforms. I can't imagine what the maintenance burden is like at huge companies for existing / mature products. Anyone care to shed some light?

I see - just curious, in what way is it mostly misused and can you be specific about how I've misuse it? I'm still not convinced I've misused it but would like to know so I don't do it again

The problem is they've kept making it worse and worse to unanimous dissent

Where's your data on "unanimous dissent"? Also, there's often a silent majority of your products where people are totally happy with it and have zero complaints. You don't want to accidentally cater to the loud minority.

It's not as simple as saying "well, someones gonna be upset but we should do it anyway because we know better". Knowing exactly what most of your users want is hard for everyone, even google.

This is a great answer - and this doesn't just affect products with hundreds of millions of users. It's a classic case of Innovators Dilemma (https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma).

https://formium.io/ is the company behind react's popular formik library

Not at all - I still favor vanillajs if only to avoid the bloat of the whole modern js toolchain (webpack...babel...extra compile times)

There's also a big difference for us within the form world between forms with ephemeral state and forms that need to persist state through many interactions and sessions. The former is perfectly fine for us to handle with vanilla js, the latter just becomes easier for developers with a declarative model.

I still have reservations about moving too heavily towards an SPA - we still mostly have server-side rendered pages that render with react components so we don't have to deal with things like client side routing. It's also still important for us we render most of the page server-side for performance reasons, but I'm not too informed about the specific trade-offs there in load times if we did push more rendering to the client.

I feel like there's some opportunity in the space to create a truly re-usable form library that can hook into your backend and be themed / customized to suite the look and feel of your app. There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap. What's challenging about this problem though (as I'm sure you're also aware) is that there are a ton of variability in requirements when it comes to forms - it's something I wish were more standardized but at times it feels like one of those bikeshedding topics where everyone has an opinion on how inputs show be displayed, how errors are shown, etc.