> TDD is "wasting time", even though it's how you can actually specify software and then just knock out the issues to turn those tests green, increasing velocity once you're comfortable with the rhythm.
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.
> CI is "wasting time", even though it's how you avoid rolling broken stuff out to production (and thus have to, yanno, do it again).
You need CI if you're working on a big project that will get deployed to multiple places (counting dev, staging and production machines). You don't need CI if the project is small and limited in deployment - about all it does then is protect you from the lazy-ass developer who thinks committing code that doesn't build is a good idea.
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. Noticing the limits and the trade-offs comes with experience, I guess.
> Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.
Would they now? Paying structures in software companies have usually little to do with actual value provided to the project/company.
> And I have a little bit of extra oomph on that one, I think, because--lest we forget--your public-facing profile says fuck all JavaScript/NodeJS developers.
Maybe too strongly worded for my taste, but I can kind-of understand the sentiment. The software ecosystem around the web is just bonkers.
> 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.
wow, that's a really long reply for a couple of short rants on HN, you either have tons of free time (kinda implied now that you have explained that you work as a full time freelancer) or really take this site seriously; personally i don't take this site seriously for that kind of discussion because the vast majority of the audience here is not a developer, i even have a comment on my history asking this in a thread.
Anyways, i believe that all your comments/rants can be resumed on you getting offended by my profile motto on javascript/nodejs developers, my disdain for testing-all-the-things mentality and some out of context sarcasm that may or may not have hit hard on you (m guessing it hit, otherwise you won't even try to pull an ad hominem move like the one before), the only answer i can think to this is... sorry that my jokes/rants got you, it wasn't intended, was a rant i write when i first originally join HN almost 2 years ago.
Now that we have made that clear let's rewind to my original rant, the one talking about jr's pushing TDD+CI+Slack+Hot-New-Thing on everything and add that we were talking before about jr's trend to make everything on SPA's and OP rant on seniors not grasping the need for that tech.
In today "web development best practices", it is common to build things out of duck-tape, jr's like to bootstrap their environment with all the batteries included and by today "standards" this includes TDD+CI+Slack+Hot-New-Thing, which is fine if you are going to build the next-uber but not-so-fine if you get hired to built a simple webpage for a client (the boring stuff, nobody wants to work that jrs usually had to grind before touching business-critical infrastructure), webpage that barely has dynamic stuff but now requires a hole built process because jr's thought that in the future they might need it.
This trend leaves me or any other senior always talking to them on the good and bad things of being a "lego/duck-tape developer", because not all of the jrs are full engineers or have a PhD on computer science the vast majority join either fresh from college or just took a couple of online courses and were able to navigate the HR interview process.
That was is my original rant that you took it wrongfully as an attack on your belief (well kinda your main job as a devops consultant), maybe you have been working so many years in big projects that you forgot that not everyone is building the next uber.
Kindest Regards
PS: Why m not in your hall of shame? i don't deserve that honor yet? ;)
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.
Haha, 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.
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.
> CI is "wasting time", even though it's how you avoid rolling broken stuff out to production (and thus have to, yanno, do it again).
You need CI if you're working on a big project that will get deployed to multiple places (counting dev, staging and production machines). You don't need CI if the project is small and limited in deployment - about all it does then is protect you from the lazy-ass developer who thinks committing code that doesn't build is a good idea.
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. Noticing the limits and the trade-offs comes with experience, I guess.
> Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.
Would they now? Paying structures in software companies have usually little to do with actual value provided to the project/company.
> And I have a little bit of extra oomph on that one, I think, because--lest we forget--your public-facing profile says fuck all JavaScript/NodeJS developers.
Maybe too strongly worded for my taste, but I can kind-of understand the sentiment. The software ecosystem around the web is just bonkers.