Comments by "" (@adambickford8720) on "Continuous Delivery" channel.

Wait until they learn about deployments, rollbacks, versioning and having their entire 'design' destroyed by an edge case that can't be wysiwyg'ed. Then another, and another... then the dev has to make the boxes and click+drag them together.
1
The problem with the imperative version is it allows arbitrary complexity far too easily. In practice i haven't seen the typical map/filter/reduce type functions end up quite as complex as some of the multiple nested looping structures I've seen where every iteration sets booleans at various scopes to control the flow of the whole thing. For non blocking contexts writing imperative code can quickly get very complex without specific language support. For the functional version, its more an implementation detail.
1
@JojOatXGME I meant it more as a thought experiment than anything.
1
@rosstempo3765 You clearly missed the point.
1
@rosstempo3765 I've been using git for a decade, this has NOTHING to do with technology. My question is 100% methodology based to the unrealistic degree that technology doesn't limit at all. Does 'stress testing' the idea fall down and where? Specifically, "if we could theoretically create a deployment artifact on every keystroke instantly". This implies its so continuously merged that the concept of a 'branch' is meaningless. I'm not convinced that's a good (manageable) thing.
1
I'm fighting this now. "Lets just share a .jar of the DTOs". Works great until you get into versioned endpoints, mixing and matching versions (we have to upgrade the WHOLE API to version 2.0? i just need 1 endpoint right now!) and so on.
1
@michaelbourke8967 homebuilding isn't agile, a flooring layout is about as waterfall as it gets. if the customer only has a vague idea of what they want to do w/the house and build it ad-hoc, it'll be a money pit too.
1
@ComradeOgilvy1984 But if they are willing to do comments, then they will be willing to do well maintained code, at which point it isn't needed. It goes both ways.
1
And yet most technical interviews are all about space/time complexity, language features/apis, frameworks, etc
1
@leftaroundabout now i'm picturing GLaDOS getting someone to read it gift card numbers 🤭
1
Same here. You can have a 'monolith' that isn't overly coupled to itself, it just takes discipline vs a physical boundary.
1
My boss wants metrics and code coverage is the 'nobody was ever fired for buying IBM' answer. So, for my use case, code coverage definitely solves problems.
1
@guilhermebencke8525 been watching that strategy fail for 2+ decades now. gl w/that.
1
If you tap 'shift' 2x (search everywhere) and type 'productivity' you'll find how much all this has actually saved you And ty for not making this an AI upsell
1
"RAD" tools have been doomsaying development for years; turns out the actual logic isn't that hard. Managing change, coordinating people, trouble shooting, etc are why devs are valuable.
1
I couldn't care less about certs; employers disagree.
1
If you think automated tests suck at intermittent failures I have some bad news about manual testing...
1
I suspect its like leather belts; your experience w/them might be very different depending on the 'culture' of your org(s) and you may draw very different conclusions. I've only seen metrics used as a weapon for productivity or tool for self-promotion. I get thats not the only way they are used, but its hard not to believe your own experiences.
1
Test IFoo, not FooBarImpl.
1
@ModernSoftwareEngineeringYT I meant more that people shouldn't be testing implementation details, never mind adding methods that exist only for the purpose of testing. Do your implementations behave as specified by the IFoo contact?
1
@jboss1073 I'd like to see a link
1
Its an estimate, not a promise. Stop pretending you're agile when in practice you function as waterfall. If you need an exact feature set by a specific date then get your Gantt chart and like it. I've seen multiple companies commit to a deadline w/a third party without even meeting w/engineering to see if it was *possible*. They still ask for estimates, but anything above what they committed to is unacceptable. But they still refuse to sequence the events and back into it because they are 'agile', as if agile just increases productivity and reduces waste by magic with no trade-offs.
1
@ContinuousDelivery Would you like to hear my anecdote about how it is?
1
@ContinuousDelivery I don't see how that's possible. If you have 2 components that are coupled via an MQ, mocking both sides isn't enough. You also have to verify all the configs/permissions etc are in place as well. Further, how do you test that those permissions have the desired effect on the system w/o an environment to do so?
1
I was annoyed when i had to skip the second embedded ad :-/
1
You're viewing it wrong; FP is easier because it's explicit. When you call a function with 1 arg in OOP, it's actually implicitly passing every single field that's in scope, where even the caller doesn't know what that means. Might be nothing, might be dozens of (async mutating!) fields.
1
@ Its almost always what you want. In OOP when you call `user.doIt()` it's impossible to reason about (this is sold as good) because it implicitly takes every field in its scope as an argument. That's a bad thing. Its far better to just pass in what's needed. If you have some values that are unchanging over the life of a function, you probably are looking for partial application.
1
That's not how bad management works IME. That cowboy coder coworker will give < 1/2 your estimate with a manually tested hack and get the promotion based on 'productivity'. Bad management never connects the dots on the long term maintenance and tech debt, which is exactly why they are bad management! The sad part is that engineers that care about craftsmanship don't stick around so it snowballs.
1
The embedded upselling/ads feel like it's coming up on half the content here. Might want to tone that down.
1