1,116 karma · joined September 24, 2012
I have followed closely the research for many years and there has been false promise of good diagnostic tests previously. What I'm arguing for is that we need a test that is specific for ME/CFS. E.g. it will test positive for a patient with ME/CFS regardless of they are obese or not, but more importantly it will not test positive for everyone who is obese. This is known as the sensitivity and specificity of the test.
What I've seen in the past is some previous ME/CFS tests show positive for groups with related symptoms but who don't have ME/CFS. This then becomes a worthless diagnostic tool. For example this would not have helped your aunt.
Hope this explains my thoughts!
This is well intentioned. But in a large old codebase finding things to improve is trivial - there are thousands of them. Finding and judging which things to improve that will actually have a real positive impact is the real skill.
The terminal case of this is developers who in the midst of another task try improve one little bit but pulling on that thread leads to them attempting bigger and bigger fixes that are never completed.
Knowing what to fix and when to stop is invaluable.
https://pmc.ncbi.nlm.nih.gov/articles/PMC4843861/
Incidentally there are some studies that show you get better at it with more frequent exposure. I have kayaked for many years and have found this to be the case - if my hands get cold now, dipping them into the water to further cool then hence opening the veins is very effective if counterintuitive way of warming my hands up.
This is a great book for larger team sizes.
I wonder why the power of Tensor G3 is needed to upload your video to the cloud...
*https://blog.google/products/pixel/pixel-feature-drop-decemb...
This is true for fairly simple cases. But when something is complex or very serious you want a true multidisciplinary team that sees the most cases per annum - that is the NHS.
A private consultant in a nice office with a very nice efficient secretary is great for their particular expertise but outside of that poor. This is based on more experience personally and with family than I would wish anyone to have.
I think the second sentence is true for everyone's code and that's what makes the job interesting.
Also jobs rarely aim for perfection, they aim to create value efficiently for the business. If the best way of getting there is producing code with a few mistakes that are when later picked up in a code review then that's fine too.
If this resonates with you at all, then when something annoys you repeating to yourself "It's just code" might help. Best of luck!
While this may be true, it still doesn't take away two strengths consultants can bring: - never underestimate the value an independent view can bring, especially to a big company suffering from group think - secondly, a common consulting practice is to re-sell successful projects to other clients. Obviously not the exact IP, but the experience and general approach. This can be invaluable.
https://www.piquenewsmagazine.com/whistler-news/ice-jacking-...
Here is my personal opinion of some Pros and Cons for the types of jobs that are in the fuzzy area of overlapping functionality.
Jenkins gui and interface handles lots of standalone jobs more nicely.
Jenkins has much better support for parameterised jobs that can be kicked off manually.
Airflow can handle dependencies between jobs in a much better way. Nicely defining and visualising dags of job really is the killer feature.
Browsing task/job logs is nicer in Airflow IMO.
Airflow scheduler is flaky - hopefully better in 2.0.
Airflow has much more “magic” than Jenkins this is often infuriating.
All that said, my preference is to move jobs to Airflow. Getting a nice gui for manually triggered jobs in airflow is/was the only large missing piece for me.