5 ms·

First, thanks for taking time in checking my profile and comment history, m quite honored that you have devoted that much time before replying my comment but us

First, thanks for taking time in checking my profile and comment history, m quite honored that you have devoted that much time before replying my comment but usually when somebody does this is because they are trying to appeal to authority or a plain ad hominem. Second, i didn't said TDD/CI is trendy, i said "you don't need them", probably should have add "at all times" to clarify. Each year it's becoming a increasingly difficult to keep jr's from wasting time implementing TDD+CI+Slack+Hot-New-Thing on all the projects, wasting resources and time from devops for the projects that do need them. Not all the projects that you built on your lifetime need the same amount of bureaucracy as those that clearly are business-critical.

eropple 9y ago
Let's think a little about this post and your prior one. Juniors don't like to work on "boring stuff" like testing and ensuring that your builds correctly complete, hmm? While you're complaining that they "don't need" stuff like TDD or CI. 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. 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). What I'm saying is that your post was incoherent (and this reply is worse), which is why I read deeper into your comment history. There's a lot more incoherence there, too. Frankly? It reads like a junior who's found what they think is a local maximum and is insufficiently humble to realize it's not a global maximum either. 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. Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.
- TeMPOraL 9y ago
  > 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.
  - 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.

eropple 9y ago

Let's think a little about this post and your prior one. Juniors don't like to work on "boring stuff" like testing and ensuring that your builds correctly complete, hmm? While you're complaining that they "don't need" stuff like TDD or CI. 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. 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). What I'm saying is that your post was incoherent (and this reply is worse), which is why I read deeper into your comment history. There's a lot more incoherence there, too. Frankly? It reads like a junior who's found what they think is a local maximum and is insufficiently humble to realize it's not a global maximum either. 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. Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.

TeMPOraL 9y ago
> 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.
- 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.