AlexanderNull

Neither Github Copilot nor GPT4 are worth your time. At best they partially guess the name of a function you're thinking about typing, at worst they give you almost a correct answer. I've been shocked by how close those models will get to almost understanding what you're attempting to do, while still fundamentally getting it wrong. Last month, after a while of realizing I was spending more time correcting suggestions than I was saving I stopped using them and will need to see some major improvements before I can feel comfortable using them again.

The 15mg/d they used in that study is just the standard dietary intake (top end, europeans). Looked a number of other studies that also used just regular intake levels as "supplementation". Weird how they all stay small when the no observable adverse effects level is much higher.

This research doesn't claim to show any cause of ADHD, it's only showing potential exacerbating influences on, or at least confounding factors of, the severity of symptoms those with ADHD present later in life. Children who expressed more negative emotional outbursts were more likely to be mistreated later, and those that were mistreated were more likely to express ADHD symptoms, and those those expressed more ADHD symptoms were more likely to be mistreated. There's no causal explanation expressed there, simply correlations that could be used to identify at risk factors earlier on in life. Everyone expresses their ADHD differently and identifying patterns in life that may either aggravate or alleviate the difficulties of the condition can potentially be helpful in the long run.

Good luck finding high quality cheap developers in any language really. Very few good developers are language specific so unless your HM is an idiot and actively screens out candidates without 10 years of previous experience in the specific framework you're using it won't be a limitation. If you want quality developers you need to offer either 1) lots of money, 2) amazing benefits, 3) interesting problems to work on. For many, an interesting language can provide an edge. I chose my current company because I would be working on Scala here as opposed to Java with the other offers I had. The quality of life improvement of the Scala position was enough to take it over the prospect of writing AbstractFactoryBeanImpl for the next few years.

<- a loose associate of this "everyone" here. (10+ years exp, proficient in FP and OOP languages.) Primarily Scala dev now so I write code that's both functional and object oriented. I'd say my code leans more towards the functional side of things, favoring composition, type inheritance over class inheritance, separation of data structures from behavior that acts on data, and a reduction of shared state to the bare minimum. However when it comes to persisting state throughout a programs lifecycle then objects/actors become a great way of handling that data in an easy to reason about structure. They're great for encapsulating data after all.

Seeing code that goes all in on OOP absolutely makes me cringe as I know it generally means the unit tests are going to be more complex than they would be in an FP environment, the code's likely going to be harder to extend as there's no amount of class inheritance planning that can prepare you for all future business requirements, and in most cases it's just going to be so much more verbose than an FP solution would be (I know this last point is a bit of a personal issue).

Code that goes all in on FP I absolutely love on a pure nerd level, but absolutely hate on a practical level. Pure FP is neat in the same way that seeing someone who can calculate out pi to a hundred digits is neat. Sure it's impressive, but like... I got this calculator that will handle it much easier.

> most of the time if one assertion fails, rest of the code is useless anyway

You either don't write tests or you're already writing them in the right way (sounds like the later). I've seen my fair share of what I would consider compound tests that have multiple asserts in tests that would crash execution of that test even though 3 lines down in that same test is a completely different bit of state being tested. This is hopefully less of an issue in unit tests but my gosh I've seen it way too much in integration tests.

It can get worse still when one of these initial assertions starts failing, a lazy dev goes in to address the problem, finds that one assertion isn't an issue worth addressing for now, labels the whole test as a KnownIssue and moves on leaving us at risk for the other issues covered in the later asserts to break without warning at a later point in time! (only seen this twice luckily)

I was doing the double red donation for a while before running out of hematocrit. Read about this study and decided to go back to donating but this time just doing the standard whole blood so I could dilute plasma a bit. Will update this post with results in 200 years if this works!

I work in a predominantly Scrum division with rigidly set iteration lengths (technically not scrum as this should be decided by each team, I know). It is horrible, so much wasted time trying to play by the book on this.

Every once and a while we have to break out special teams for a cross group project, a special POC, or something super important with a tight deadline. In those cases the team becomes much more engineer led than management led and in most cases we revert immediately to Kanban style. Not surprisingly for me, we always get more done in a faster manner with Kanban.

Things get done when they're done, not when an arbitrary sprint end day has occurred. Kanban allows you to move work along as needed and instead of focusing on meeting that arbitrary end day, we all get to focus on continuously getting stories closed out. All we needed for this was a kanban board in whatever tracking system we were using at that time along with a reliable form of communication between team members.

Yeah, if you're not programming your models in binary then gtfo imposters!!

On a more serious note, yes understanding this and anything really takes time and investment. The problem for me at least originally not only with ML but originally with engineering back when I was trying to learn (and couldn't afford school), was finding quality sources for getting started in that process of learning. By providing simplified resources like this google one, the hope is that many beginners can get that one "aha!" moment where they start the basic understanding that allows them to start tinkering and learning.

People without a decent understanding shouldn't be submitting research papers, full on agree there. It's basically a waste of everyone's time and harmful for the field of research as a whole as it dilutes the overall signal to noise ratio. However there's so much space in the ML world that doesn't involve research, not only for fun hobby projects, but also even professionally. Resources like this are critical to reducing the knowledge gap out there between researchers and the programmers in the field that work on little ML projects for doing things like sentiment analysis for their company.

These sub-research projects are mission critical at a lot of companies yet are held up at the majority of non-FAANG companies because there's only one data scientist while the teams of engineers are clueless as to how to assist.

I did uberman in grad school, kept it up for a few months. It technically did give me more hours in the day, however most of that free time was spent on either making sure my schedule was arranged well enough for my sleep times, or sitting around reading a book quietly at 3am because everyone else including my roommate is asleep and all businesses are closed.

The benefits weren't really as pronounced as I was hoping for. Then if you end up missing one of your scheduled sleep times it really effects you and throws you off for a day or two.

Videos on YouTube are selling advertisements so wouldn't this apply here?

Great write up on the nature of fear! It's amazing how much the mind can fight to deny the reality of the situation you're in during such episodes.

The dull chest pain sticks around for a surprisingly long amount of time. I'm at day 25 now since my ER visit and just noticed that I haven't felt any of that dull pressure in at least 2 or 3 days at this point.