Comments by "Tiago D\x27Agostini" (@tiagodagostini) on "If Your Code Looks Like This... You're A GOOD Programmer" video.

The problem of partitioning code for business is that you enforce the result that your architecture will be a copy of the organization internal department scheme and that usually is HORRIBLE to mantain and horrible to scale. Develoeprs do need to understand the business but the oens that define where to partition things shoudl be senior DEVELOPERS.
4
@pawelhyzopski6456 That is not as easy to say when your field for eaxmple is healthcare.. and not opoenign meansw peopel will die in emergency waiting for the PACS or HIS to proccess their data. There are some moments where you NEED to do what is needed. And as soon as that is done you start doing what you SHOULD have done.
2
@mariusg8824 Sound very cool until your company needs to pivot into a field and the new field is completely incompatible with the way your organization is structured. I have seen companies crumble exactly due to that. Try to make an organization match with an operating system.. I bet microsoft suffered a lot with the Conway's effect.
2
Yes, but both things should live side by side. Worst thing is when you find a method whsoe name implies it does A, but in fact it does B.
2
Before that there is the step of EXPLAINING your code to someone else. IFyou cannot make another person understand.. you probably need to throw it away and re do it.
2
@octomancer My own opinion is not so positive of unit testing. In my 30 year career I have seen so many mistakes created by unity testing focus (instead of thinking in the problem, the developers think in tests only and fail to see real complex interactions, that are the SERIOUS issues in several type of systems). I do near zero UNITY testing a the very definition, yet my systems have operated for decades in healthcare with very high reliability in healthcare. You need testing, automated AND manual (depending on the tool type) but not always unity testing is the way to make the best tests. IF your field of operation tranlates well over a math base, a lot that unit test aims is already acomplished by the underlying reliability of a math model.
2
@gronki1 yes, when you are writting a stop gap feature whose lifetime is expected to be 2 weeks and only need to convert some data from system A to B 1 time per day when a secretary push a certain button and the worst it can happen is someone having to do something by hand. Then it is not monetarily worth to spend resources into achieving the same safety that you should employ in a system that controls something in a passengers plane.
1
@RaMz00z What kill companies is market , management, regulation and govnnrment shenannigans. Abstraction cannot do that. Bad abstractions make a company SLOW. Alone they are not enough to kill a company. Obviously you want good ones, but engineers tend to overestimate how much their critical path is ALL the critical path of a company.
1
The end result is the same. The strongly typed language has a chaperone that points when you make a mistake. But the mistake is still you that make. It has been years sicne last time I had an error in python of an entity of wrong type reaching a location. But that is mostly the developer developing the paranoia needed for that tool (i.e the damn parameters indicate very clearly what should be passed). Strong typing is very useful helper tool, but all mistakes are always made by a developer.
1
@a0flj0 But that has always been my critic.. TDD preachers draw it as a holy salvation that by itself can assure nothign ever goes wrong. I hate when people put techniques in front of the main objective.. delivering a good product.
1
@Immudzen That is the correct approach (unless you are designign a library as a product, then forethinking on the interface is warranted)
1
@a0flj0 Some 30 years of career here.. and I never found a TDD preacher that did not treat it as the holy path of salvation, at the level that "junior developers that do TDD do better code than senior ones without TDD." I blame the universities here, they teach content as if it were gospel and not technique. Sad byproduct of bad education system in places where universities are public and the teachers cannot ever be fired.. so they never update and keep repeating the same last thing they learned jsut before they go their job.
1
@a0flj0 Well my 20+ years in the field have been basically only repetitions fo these anecdotals. I never seen anything different from that (I know they do exist, but my point is that it is NOT TDD that makes it work.. it is a set of more relevant maturity and education aspects).
1