Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

Post reply on HN
Print view View original

211–220 of 347 posts

Re: Be Aware of the Makefile Effect

#211

Post by n_ary »

ajross wrote: post #160
Joker_vD wrote: post #129

Earlier quoted context omitted.

> I mean, sure, there's no time today to learn make to complete your C++ ticket or whatever. But yesterday? Last month? Last job? That seems like a weird way to think about this. Of course there was no time in the past to learn this stuff, if you still haven't learned it by the present moment. And even if there were, trying to figure out whether there perhaps was some free time in the past is largely pointless, as op…

To be clear: I'm not suggesting a time machine, and I'm not listing any particular set of skills everyone must have. I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.

> I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.

Or the whole chain of work culture is bad and people do not have adequate down time or brain juice to pursue these. Additionally, how many do you want to learn? I have dealt with Makefile, then recently someone decided to introduce taskfile and then someone else wanted to use build.please and someone tried to rewrite a lot of CI pipelines using python because shell scripting is too arcane, while someone decided that CI were super slow and must be hosted on premises using their favorite system(was it now drone or whatever I forgot). Eventually, things become so many and chaotic, your brain learns to copy-paste what works and hope for the best as the tool you have spent time learning will be replaced in few months.

Re: Be Aware of the Makefile Effect

#212

Post by lolinder »

godelski wrote: post #199
lolinder wrote: post #140

Earlier quoted context omitted.

I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that they only worked within a broader context that is now missing. It's about going through motions or rituals that are actually ineffective on their own in the hopes that you'll get the results that other companies got who also happened to perform those same moti…

> only worked within a broader context that is now missing > because the thing being copied—the code—actually is effectual in its own right. I don't understand how the second disproves the former. In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal…

> Just because your wooden plane glides doesn't mean it's AC an actual plane

But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island, what you're doing is definitely not cargo culting.

It might not be actual engineering, maybe you don't understand aerodynamics or how the engine works, and maybe the plane falls apart when it hits the runway on the return flight, but if you got the cargo back you are doing something very different from cargo culting.

That's why copypasta doesn't count as cargo culting. It accomplishes the same task once copied as it did before. It may do so less reliably and less legibly, but it does do what it used to do in its original context.

Re: Be Aware of the Makefile Effect

#213

Post by foobarchu »

kragen wrote: post #101
silver_silver wrote: post #81

Earlier quoted context omitted.

We can’t really call the field engineering if this is the standard. A fundamental understanding of what one’s code actually makes the machine do is necessary to write quality code regardless of how high up the abstraction stack it is

Steam engines predate the understanding of not just the crystalline structure of steel but even the basics of thermodynamics by quite a few decades.

I don't consider that an equal comparison. Obviously an engineer can never be omniscient and know things nobody else knows either. They can, and should, have an understanding of what they work with based on available state of the art, though.

If the steam engine was invented after those discoveries about steel, I would certainly hope it would be factored into the design (and perhaps used to make those early steam engines less prone to exploding).

Re: Be Aware of the Makefile Effect

#214

Post by lolinder »

foobarchu wrote: post #210
scubbo wrote: post #207

Earlier quoted context omitted.

> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a hel…

Concrete examples of what I think actually counts as cargo culting:

* Incorporating TDD because it's a "best practice".

* Using Kubernetes because Google does it.

* Moving onto AWS because it's what all the cool companies are doing.

The key thing that makes cargo cult development a cargo cult is that it's practices and rituals adopted without any concrete theory for what a bit is supposed to do for you in your context. You're just doing it because you've seen it done before.

This is different than small scale copypasta where people know exactly what they're trying to accomplish but don't take the time in any given instance to slow down and re-analyze why this bit of code looks the way that it does. They know that it works, and that's enough in that moment.

If we're going to go back to the original analogies that started it all, what you're describing as cargo cult would be more similar to islanders using machinery that was left behind without knowing how it works or how to maintain it. They don't strictly need to know that in order to gain actual concrete value from the machinery, but it would be better in the long term if they knew how to maintain it.

Re: Be Aware of the Makefile Effect

#215

Post by Joker_vD »

mdaniel wrote: post #183
tempodox wrote: post #150

Earlier quoted context omitted.

How is running those runners on our own hosts (locally) not self-hosting?

Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that -- back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally." However, as…

Not to mention that the rest of the environment is missing: e.g. you probably can't push to e.g. the organization's Docker registry/Artifactory/whatever from you local dev machine (if it's even visible from your machine in the first place). And those are arguably the most interesting parts that you want to test the integration with.

Re: Be Aware of the Makefile Effect

#217

Post by earnestinger »

o11c wrote: post #157
earnestinger wrote: post #118

> However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application. I interpret it in a bit of different way. Makefile is relatively simple and unopinionated like a brick. Also makefile defines/reflects project’s structure. From simple blocks one can build any shape one want. Total freedom. Problem is, make doesn’t impose best practice and doesn’t s…

To expand the illustration: * using out-of-source builds is a good idea * using fully automatic dependencies is a good idea * never committing generated files is a good idea (avoid hysteresis) It is fundamentally very difficult to get all three of these at once; automatic dependencies often require generating files ahead of time, but generating files often involves needing to know the dependencies or at least their p…

One more shower thought. Those inherited makefiles are a solution in a search for a standard.

Re: Be Aware of the Makefile Effect

#218

Post by skydhash »

n_ary wrote: post #211
ajross wrote: post #160

Earlier quoted context omitted.

To be clear: I'm not suggesting a time machine, and I'm not listing any particular set of skills everyone must have. I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.

> I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread. Or the whole chain of work culture is bad and people do not have adequate down time or brain juice to pursue these. Additionally, how many do…

A lot of these technologies share a common base that can be pretty small. Once you learn about Make and concepts like target, recipe, dependencies,... It'd be easier to learn Ansible or Github actions even though they don't solve the same problem. It's the same when learning programming language and whatever tools of the week. But that requires to spend a bit of effort to goes under the hood and understand the common abstractions instead of memorizing patterns and words.
Post reply on HN