←back to thread

Be Aware of the Makefile Effect

(blog.yossarian.net)
431 points thunderbong | 9 comments | 11 Jan 25 04:13 UTC | HN request time: 0.002s | source | bottom
Show context
mianos ◴[11 Jan 25 07:31 UTC] No.42664066[source]▶
I have an alternate theory: about 10% of developers can actually start something from scratch because they truly understand how things work (not that they always do it, but they could if needed). Another 40% can get the daily job done by copying and pasting code from local sources, Stack Overflow, GitHub, or an LLM—while kinda knowing what’s going on. That leaves 50% who don’t really know much beyond a few LeetCode puzzles and have no real grasp of what they’re copying and pasting.

Given that distribution, I’d guess that well over 50% of Makefiles are just random chunks of copied and pasted code that kinda work. If they’re lifted from something that already works, job done—next ticket.

I’m not blaming the tools themselves. Makefiles are well-known and not too verbose for smaller projects. They can be a bad choice for a 10,000-file monster—though I’ve seen some cleanly written Makefiles even for huge projects. Personally, it wouldn’t be my first choice. That said, I like Makefiles and have been using them on and off for at least 30 years.

replies(7): >>42664103 #>>42664461 #>>42664526 #>>42664536 #>>42664757 #>>42672850 #>>42676540 #
huijzer ◴[11 Jan 25 09:01 UTC] No.42664461[source]▶
> That leaves 50% who don’t really know much beyond a few LeetCode puzzles and have no real grasp of what they’re copying and pasting.

Small nuance: I think people often don’t know because they don’t have the time to figure it out. There are only so many battles you can fight during a day. For example if I’m a C++ programmer working on a ticket, how many layers of the stack should I know? For example, should I know how the CPU registers are called? And what should an AI researcher working always in Jupyter know? I completely encourage anyone to learn as much about the tools and stack as possible, but there is only so much time.

replies(6): >>42664760 #>>42664847 #>>42665008 #>>42665319 #>>42666573 #>>42670611 #
silver_silver ◴[11 Jan 25 10:13 UTC] No.42664760[source]▶
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
replies(3): >>42664887 #>>42665077 #>>42681706 #
cudgy ◴[11 Jan 25 10:35 UTC] No.42664887[source]▶
Sure if you are doing embedded programming in C. How does one do this in web development though where there are hundreds of dependencies that get updated monthly and still add functionality and keep their job?
replies(2): >>42665083 #>>42665438 #
1. kragen ◴[11 Jan 25 11:13 UTC] No.42665083[source]▶
Maybe switch to less frequently updated dependencies and rewrite the easy ones in-house?
replies(1): >>42665537 #
2. pdimitar ◴[11 Jan 25 12:55 UTC] No.42665537[source]▶
Yes, and I should overrule half the business decisions of the company while I am at it. Oh, and I'll push back on "we need the next feature next week" and I'll calmly respond "we need to do excellent engineering practices in this company".

And everybody will clap and will listen to me, and I will get promoted.

...Get real, dude. Your comments come across a bit tone-deaf. I am glad you are in a privileged position but you seem to have fell for the filter bubble effect and are unaware to how most programmers out there have to work if they want to pay the bills.

replies(2): >>42666493 #>>42667215 #
3. ori_b ◴[11 Jan 25 15:31 UTC] No.42666493[source]▶
Yes, sometimes things are unfixably broken, and it's impossible to build anything good.

For everything else, there's MasterCard.

replies(3): >>42667991 #>>42668906 #>>42671852 #
4. kragen ◴[11 Jan 25 17:07 UTC] No.42667215[source]▶
I know a lot of people have terrible jobs at profoundly dysfunctional companies. I've had those too. That situation doesn't improve unless you, as they say, have the serenity to accept the things you cannot change, the courage to change the things you can, and the wisdom to know the difference.

Not everyone has a position where they have the autonomy to spend a lot of effort on paying down technical debt, but some people do, and almost every programmer has a little.

I think it's important to keep in view both your personal incentive system (which your boss may be lying to you about) and the interests of the company.

replies(1): >>42667971 #
5. pdimitar ◴[11 Jan 25 18:38 UTC] No.42667971{3}[source]▶
The serenity in question boils down to "I'll never make enough money to live peacefully and being able to take a two years sabbatical so let's just accept I'll be on the hamster wheel for life and I can never do anything about it".

No. I'll let my body wither and get spent before my spirit breaks. I refuse to just "accept" things. There's always something you can do.

BTW is that not what HN usually preaches? "Change your job to a better one" and all that generic motivational drivel [that's severely disconnected from reality]? Not throwing shade at you here in particular, just being a bit snarky for a minute. :)

RE: your final point, I lost the desire to keep view of both my personal and my company's incentive systems. Most "incentive systems" are basically "fall in line or GTFO".

Before you ask, I am working super hard to change my bubble and get a bit closer to yours. To say it's not easy would be so understated so as to compare the description of a lightning hit on you and you enduring the said lightning hit. But as said above, I am never giving up.

But... it's extremely difficult, man. Locality and your own marketing matter a lot, and when you have been focused on technical skills all your life and marketing is as foreign to you as are the musical notes of an alien civilization... it's difficult.

replies(1): >>42668158 #
6. pdimitar ◴[11 Jan 25 18:40 UTC] No.42667991{3}[source]▶
Any golden MasterCards with $50M one-time limit you could offer for free? I can think of a few things to fix with those.

RE: unfixably broken, well, not necessarily in concept but de facto you are sadly correct. Most people resist even the provably good changes.

7. kragen ◴[11 Jan 25 19:06 UTC] No.42668158{4}[source]▶
I can't recommend others follow my path. Some of the results have been pretty bad. Hopefully your path works out well. We all die in the end.
8. klibertp ◴[11 Jan 25 21:02 UTC] No.42668906{3}[source]▶
> For everything else, there's...

...the very definition of brokenness :D Not much of a (good) choice there...

9. inkyoto ◴[12 Jan 25 07:20 UTC] No.42671852{3}[source]▶
> For everything else, there's MasterCard.

I'm pretty sure that the original meme was «In God we trust; for everything else, there’s American Express» (with or without cocaine).