271–280 of 308 posts
Earlier quoted context omitted.
The newbies who haven’t figured out that new projects = promotions will do it.
It's worth mentioning that this is a myth. Invisible maintenance work on old products can be very impactful if done correctly.
Earlier quoted context omitted.
You make it sound like those studies were bad because the sample size was too small. In reality bad study design or having an unrepresentative sample are more common issues.
I think they go hand-in-hand. People naively apply intro-level statistics to messy real-world problems and then think they need an orders of magnitude smaller sample than they would need to even hint at the possibility of an interesting effect.
Earlier quoted context omitted.
If you're performing a rigorous experiment, then you have a control group, and your null hypothesis is that the experimental group will be the same. In actuality you will find that many null hypotheses hold true and the experimental design has no effect on the outcome, at all. Of course in some fields, like psych, most everything has some effect. But it's absolutely not correct to blame p-values for helping you disti…
> In actuality you will find that many null hypotheses hold true I'm assuming you mean within the confines of the experiment, correct? I agree. The tweet author was eluding to the fact that "IRL" the null hypothesis is almost never true at the population level. Meaning if you grab a large enough sample you will detect very, very small differences. (This was her Lucky Charms ~ blood type example in the tweet). I also…
Lucky Charms does probably relate to blood type in some impossibly small way. It makes sense that a biological trait has some relation to dietary consumption. I don't think any sort of non-garbage tier journal with peer review would publish it, but good on p-values for helping us detect them though. Not bad on sample size for making it possible to discern this effect size with a high degree of confidence.
It's worth noting that we also have many other tools to help us. For example you can test, given an expected effect size and a sample size, what the probability is of getting a statistically significant result, or a non-significant result, or a significant result that erroneously goes in the wrong direction. Or what the range of likely true mean effect size is given a significant sample difference.
We want large samples. They enhance confidence in findings. The author's premise seems to be it's better not to know that small rocks exist if we're only looking for big rocks. But fails to mention that the tools to find small rocks also help us identify big rocks with more clarity.
Earlier quoted context omitted.
You make it sound like those studies were bad because the sample size was too small. In reality bad study design or having an unrepresentative sample are more common issues.
I think they go hand-in-hand. People naively apply intro-level statistics to messy real-world problems and then think they need an orders of magnitude smaller sample than they would need to even hint at the possibility of an interesting effect.
I think one of the biggest factors for dev burnout is processes and lack of ownership/input devs are subjected to. Most teams look at developers as just ticket takers and rarely involve them in the product or the decision making. Eventually you just tire of implementing the same stuff over and over like a code monkey.
Earlier quoted context omitted.
I think they go hand-in-hand. People naively apply intro-level statistics to messy real-world problems and then think they need an orders of magnitude smaller sample than they would need to even hint at the possibility of an interesting effect.
Neither a bad experiment nor an unrepresentative sample will be helped by a larger sample size, though.
I think one of the biggest factors for dev burnout is processes and lack of ownership/input devs are subjected to. Most teams look at developers as just ticket takers and rarely involve them in the product or the decision making. Eventually you just tire of implementing the same stuff over and over like a code monkey.
I have a job where I get to do a lot of the requirements in addition to the development and trust me, it is just more work and I am more burnt out for it.
Earlier quoted context omitted.
I wouldn’t go that far. I do think that, particularly for primary education, some people tend to overinflate the importance of teachers as academic experts and discount their social importance. The value that school provides kids, parents, and the community is multifaceted. If anything, primary educations are very important, but not because kids learn basic arithmetic, but because they learn the foundational social c…
I would go as far as to say school is industrial daycare. Asserting that schools provide value to society because people learn things within their boundaries is, in my opinion, like saying that caffeine pills provide value to tired people by helping them stay awake. It's not wrong per se, but it's a hackneyed solution that doesn't address the root cause of the problem. "Our citizens are illiterate and don't understan…
I disagree. Many (most) of the social concepts that children learn in school are not taught by teachers, they're taught through interactions with other students, with the teachers providing guard rails. They're completely orthogonal to the curriculum.
There are certainly plenty of myths repeated in classrooms by teachers, but I don't think the ratio is worse than the number of myths you hear in any other place. In fact, I would bet professional educators probably do a better job of not repeating myths than the general population, since they study formal pedagogical methods. Go read a public comment section on any news story -- you'll find plenty of examples of egregious myths repeated by average "productive adults".
A long time ago I was reading a text on burnout, and one factor that stood out was lack of closure. Think of an architect - they design a building, deliver blueprints and the building gets built. They're done. They can drive by the building and say "Look, I've designed that building". There's closure. A developer's job is rarely done. You do a fantastic job and fix 2 almost intractable bugs in a sprint. What happens…
You're a doctor and cure a patient; what do you get tomorrow, more patients. You're a automotive worker and assemble 100 cars today; what do you get tomorrow, more cars to build. You're a mechanical engineer and fix a customer's issue with the machinery; what do you get next week, more customer issues.
Jobs where you can regularly fully close a project and never hear about it again are the exception.
Earlier quoted context omitted.
It's important for managers to plan time for design, testing, feedback, meetings, administrative tasks, and context switching. In places I've worked that has planned this well, we usually allocated somewhere around 4 hours of development work per day to someone. I think most burnout is systematic, and caused by incomplete task breakdowns.
> I think most burnout is systematic, and caused by incomplete task breakdowns. As a counterpoint, I think burnout can contributed to by overly granular task breakdowns that remove individual developer creativity and autonomy.