My mentor used say it is the difference between a screw and glue.
You can glue some things together and prove that it works, but eventually you learn that anytime you had to break something to fix it, you should've used a screw.
It is trade off in coupling - the glue binds tightly over the entire surface but a screw concentrates the loads, so needs maintenance to stay tight.
You only really know which is "right" it if you test it to destruction.
All of that advice is probably sounding date now, even in material science the glue might be winning (see the Tesla bumper or Lotus Elise bonding videos - every screw is extra grams).
Making it work can be a hacky, tech debt laden implementation. Making it right involves refactoring/rewriting with an eye towards maintainability, testability, etc etc
In ML, often it does work to a degree even if it's not 100% correct. So getting it working at all is all about hacking b/c most ideas are bad and don't work. Then you'll find wins by incrementally correcting issues with the math / data / floating point precision / etc.
Depends on your definition of "right" and "work". It could be a big ball of mud that always returns exactly the required response (so it 'works'), but be hellish hard change and very picky about dependencies and environment (so it's not 'right').
It’s also the name of the software they, and others, use. Though I guess the actual software has the generic name "Analyzer": https://corp.dxomark.com/analyzer/
Hello! I'm Abhishek. I am a team lead with broad knowledge of development tools and processes; excellent written and oral communication with enthusiasm for learning new technologies, I am looking for contributor/lead roles to deepen my knowledge of analytics &
data warehousing.
Location: Gujarat, India
Remote: Yes
Willing to relocate: Yes, if sponsorship available
Technologies: Python, Django, React, Javascript, SQL, Selenium, Git, HTML, Power BI, ASP.NET, Java, Enovia PLM, Spring and open to learning more.
Résumé/CV: https://drive dot google dot com/file/d/1FatOidojYj1ozz_v6Oa1n9wPxYtzelHc/
Two instances, in two different companies that I can share.
In one case the developer was hostile to working with anyone else. This was a project that involved close co-operation with teams across three countries, so his attitude was a no-go.
In another case, the engineer was constantly slacking off, dumping his work on the other devs in the team.
In both cases I'd have several 1:1's with the engineers, and first try and understand what was going on.
I usually trust people, and when something like this turns up, there are often other serious problems, for example at home with family or with the developer's health. We settle these issues quickly through flexi-time, reduced workloads, sabbaticals, coaching, changing their scope of work, etc, and things turn around very nicely. However the engineers I wrote about above didn't fall into this category.
In both cases I had extensive 1:1's with them, to help both of us understand what was going on. In this process I'd get insights into the nature of each person, and that helped define the right approach to resolve the problems. I then set clear expectations that we would review each week. We unfortunately got no progress for both the devs after 4 weeks, and at this point I had to involve HR and turn this into a probation. Both flunked and were asked to leave the companies.
There's no set formula here. If faced with this situation today, I'd handle it slightly differently and more quickly.
