Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
The "best practices" in this case are just well known principles, they're not absolutes, and don't apply in every condition.
Many developers learn to drop things that don't contribute to quality of life and focus on what does. It's all about your level of certainty; the PM and managers don't give a shit about test coverage or how the sausage is made, they care about the extra 2 story points. Do what you have to do to deliver quality, and get as close to the margin as possible.
Once you understand how to derive those principles, you can make educated decisions about when and where they apply and how things should be engineered.
In regards to the customer facing product (docs, api, sdks, etc), you put out there what you know people need, then you collect data to determine what should be prioritized based on customer usage and feedback. The end goal is to be able to build intuition about your customers and predict their needs. That's also a continuous cycle that feeds testing and prioritization.
don't you become what you always loathed? for example most of us said that they never become like their parents. But they became like their parents over the time because that's just how it goes in life?
although if you stopped becoming better you stoped beeing good. And those who slack off for 30 years they're in for crying bitter tears in the government job center when they've reached the age of 50.
But then again it's not your fault as neoliberal capitalism is hardwired to make you miserable. Doing stuff you dont love for buying stuff you don't need.
C0D4557507dYea and no, In my experience anyway.
Yes you start to care less and feel the urge to just throw TDD out the window just because you know feature X works and will take you 2-3 times longer to cover it then it took to build it in the first place, but at the same time you get that urge of... this fucker over here is going to change this at some point and god knows what is going to break.
If there's one thing I've learnt in my years, redoing something after it hits prod is far more tiring then taking that much longer the first time. I'm very "anti" agile in the regard of deploying quality over quantity.
I don't do unit tests because the amount of code they require dwarfs the actual code, and it only gets worse with changes - which in turn creates tech debt in itself. I don't think they bring enough to the table to justify the money spent on them.
@C0D4 well the team doesn't do TDD so I don't have experience with that at all. We write enough to get coverage...after the feature is built. Part of it is the requirements keep changing during dev. I'm building a new app basically right now to generate a report and got the initial design but it gets massaged and the ultimate validation ends up being a functional test: does the final report match what the user says it should? Yes, good. No: something is wrong, need to debug.
Right now I'm at something is wrong but got pulled into another project...