3 ms·
> What kind of software are you writing that this works? full-blown TDD-as-a-specification is both too detached from the domain and too bogged down in details a
by eropple 9y ago
> What kind of software are you writing that this works? full-blown TDD-as-a-specification is both too detached from the domain and too bogged down in details at the same time; you end up creating a Frankensteinian codebase that barely makes a coherent whole, but it's sure easy to test.
For clients, where I most often practice TDD? Libraries. Web applications (mostly services, occasionally web). DevOps tools. Personally, where I do it for core logic when I understand the problem fully going in? I have a React Native app in the Play Store which I basically proved working via tests before I ever built a UI. I've built a service-oriented authn/authz stack I'm looking to open-source soon, and it has 100% test coverage and the test cases have been looked over by much wiser heads than me to bulletproof it. All sorts of stuff. I naturally write code that's decoupled sufficiently to avoid mocking (except when forced to by writing sufficiently downstack stuff, but that's rare enough these days).
Specifications are in English from the client (either from them directly or written by me to their approval), I turn them into tests as I rough out an overall architecture, and I then make those tests turn green. And, because I actually know how to write tests in the large and in the small, I have a reasonable--not perfect but reasonable--expectation that my code will work.
(I don't do this as much as I should for personal projects, but that's because most of them are much more exploratory or are effectively plumbing over somebody else's API.)
> The thing that I believe 'SadWebDeveloper is aiming at is that hippie-devs mistake finger for the moon; they think of TDD and CI and other popular practices as dogmas to follow, instead of potentially useful techniques that may or may not be beneficial to any particular project.
This is the sort of in-your-own-head view that makes one old prematurely and unnecessarily both unwise and unlikeable.
I know that, because I used to say what you do, and I was wrong. It used to be Ruby, though, not just JavaScript. Things change too fast. It's all too reckless. Then I started using them in earnest--first Ruby a few years ago, then Node and JavaScript over the last year. And I realized that the things that draw external criticism are things that exist for a reason. These things are not discussed merely because they're "popular", it's because they make the end result better and they are transferable from project to project in a way that amortizes the cost even for small ones.
But, more importantly, the notion that these are somehow "hippie-devs" because they care about practices you don't is one, disrespectful, and two, kinda really often wrong. (I know this because I thought this, and I was full of shit.) These are not stupid, uncritical, or foolish people. There are problems and there are gaps--the Node ecosystem's general lack of understanding of underlying Unix is continually troubling--but when it comes to the platform and the practices of it, the notion of "change for change's sake" is mostly unfounded.
Anyway, the software ecosystem around the web is bonkers because the web is bonkers. Because people want the web to do stuff it wasn't built to do and is really hard to do effectively. That's why there's so much churn. Because people are learning new things and applying them. (Heaven forfend.) But it's working. If you step into this stuff, today, here and now, with React and ES6, you get an experience that is flat-out better than any I have had with any system, ever--with WPF being the closest, but not that close, I can think of, and miles better than any server-side HTML chewing that I can think of. Stuff is changing because stuff is improving. And it's also slowing down as practices gravitate towards what appear to be reasonable local maxima. It did for Ruby, it is now for JavaScript; you can write a frontend using React and be reasonably assured that it'll be supported for most of a decade and that you'll be able to find developers, and the JavaScript backend stack hasn't really changed much in a couple of years). It's part of the lifecycle. Whining about it is whining about the weather; nobody else cares, and nobody wants to hear it.
I run a devops consultancy. Sometimes this is marriage counseling for engineering teams; sometimes this is "come provide technical leadership." I am paid to have opinions and to lead people towards best practices. I have learned over time that holding those opinions so tightly that you say "fuck all JavaScript/NodeJS developers" doesn't make you good or wise or experienced or decent, it makes you a jerk, and it makes you unfit to interact with people, let alone mentor young adults. And it is unworthy of your defense.
- TeMPOraL 9y agoOuch. I guess I deserved it. -- Funny how you mention Ruby, because as I was writing the previous comment, I actually thought of it; I was a bit dismissive of the Ruby culture (that around Rails in particular) as well, but - unlike JS - it was entirely tangential to my work, so I didn't dwell on it. Maybe I'm projecting a bit when I talk about "hippie-devs", but that's because I used to be one too (more than once), and I remember being eventually disillusioned about the things I was in so much awe of. (Also, I don't call something "hippie-dev attitude" for just caring; the attitude I don't like is following and promoting popular trends without understanding the actual (not imagined) benefits and trade-offs they involve. Which is something I was both doing at times, and frequently witness on the web.) -- > If you step into this stuff, today, here and now, with React and ES6, you get an experience that is flat-out better than any I have had with any system, ever--with WPF being the closest, but not that close, I can think of, and miles better than any server-side HTML chewing that I can think of. I started playing with React recently and I admit, it seems to be great and living up to the hype (barring the broken setup process that suffers from ever-shifting JS dependencies, but that's orthogonal). > you can write a frontend using React and be reasonably assured that it'll be supported for most of a decade and that you'll be able to find developers, and the JavaScript backend stack hasn't really changed much in a couple of years). I don't feel confident about it. I mean, the last stable JS thing I remember was... jQuery. Everything else I've seen so far is shifting sands. Works today, broken tomorrow, works again next week, abandoned half a year later. But you have more experience there, so I'll take this as evidence toward "stability" hypothesis. I really do hope it's true - then maybe we can iterate on overall React performance, fix the damn unstable mess of underlying dependencies, and we'll have something solid for everyone to use. > I have learned over time that holding those opinions so tightly that you say "fuck all JavaScript/NodeJS developers" doesn't make you good or wise or experienced or decent, it makes you a jerk, and it makes you unfit to interact with people, let alone mentor young adults. And it is unworthy of your defense. Thinking about it more, I believe you're right. -- Thanks for calling me on my bullshit. Really. That's one of the reasons I come to HN - so that people can tell me where I'm wrong, especially in the opinions I hold strongly.
- eropple 9y agoHaha, hey, I appreciate your response - I recognized your posts, I figured you were an alright guy, so I gave you my honest take. =) Like I said, I've totally been there. I still rip on Golang more than I probably should, but that too is out of knowing how the whole thing works. (Before editing, I wrote "the whole tire fire" here. Old habits die hard.) I think being disillusioned with tech is also part of the cycle. You can't be frustrated by something until you really know it and really like it. Usually anyway--my exception is Golang, I got deep into it but never liked it. I haven't hit the frustration point with Ruby personally, but I also don't use it as a substrate on which Rails runs. I think I would be much more frustrated by it if I did, because Rails seems to have gone down some weird holes (ones that make a lot of sense--if you're writing a Basecamp framework), but Ruby-the-ecosystem, not so much. I do think React is going to be a Thing for at least five years. There's too much momentum behind it and, unlike Angular, it seems to have a straight-up smart basis for existence. Making the UI fundamentally stateless (or easily made stateless--I think component state is going to be left out of "React: The Good Parts") will age pretty well, and it's already really fast at DOM rewrites in ways I tend to think browsers can key in on with batch APIs down the line (to avoid context switches into/out of JS-land). Couple that with already having stuff like React Native out there, and it seems pretty open-and-shut that it'll be a worthy choice for a while even if Facebook abandoned it--which I don't expect them to do unless something clearly superior, and worth the cost of migrating a lot of stuff, comes up.