Most active commenters
  • kragen(4)

←back to thread

Be Aware of the Makefile Effect

(blog.yossarian.net)
431 points thunderbong | 11 comments | 11 Jan 25 04:13 UTC | HN request time: 1.509s | 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 #
kragen ◴[11 Jan 25 10:57 UTC] No.42665008[source]▶
If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more battles per day than someone who spends 1% of their time learning new things.

Specifically for the examples at hand:

- at 20%, you will be able to write a Makefile from scratch within the first day of picking up the manual, rather than two or three weeks if you only invest 1%.

- if you don't know what the CPU registers are, the debugger won't be able to tell you why your C++ program dumped core, which will typically enable you to resolve the ticket in a few minutes (because most segfaults are stupid problems that are easy to fix when you see what the problem is, though the memorable ones are much hairier.) Without knowing how to use the disassembly in the debugger, you're often stuck debugging by printf or even binary search, incrementally tweaking the program until it stops crashing, incurring a dog-slow C++ build after every tweak. As often as not, a fix thus empirically derived will merely conceal the symptom of the bug, so you end up fixing it two or three times, taking several hours each time.

Sometimes the source-level debugger works well enough that you can just print out C++-level variable values, but often it doesn't, especially in release builds. And for performance regression tickets, reading disassembly is even more valuable.

(In C#, managed C++, or Python, the story is of course different. Until the Python interpreter is segfaulting.)

How long does it take to learn enough assembly to use the debugger effectively on C and C++ programs? Tens of hours, I think, not hundreds. At 20% you get there after a few dozen day-long debugging sessions, maybe a month or two. At 1% you may take years.

What's disturbing is how many programmers never get there. What's wrong with them? I don't understand it.

replies(2): >>42666717 #>>42667133 #
1. remus ◴[11 Jan 25 16:55 UTC] No.42667133[source]▶
You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time.

Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10% more, but again it's not obvious in advance that this will happen.

replies(4): >>42667199 #>>42667752 #>>42669793 #>>42670902 #
2. kragen ◴[11 Jan 25 17:05 UTC] No.42667199[source]▶
I agree. And there's no infallible algorithm. I think there are some good heuristics, though:

- invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful

- invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the Lindy Effect

- invest more of your time in skills that are broadly applicable (algorithms, software design, Python, JavaScript) rather than narrowly applicable (PARI/GP, Interactive Brokers)

- invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff.

- be willing to try things that may not turn out to be useful, and give them up if they don't

- spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective

replies(3): >>42670922 #>>42671161 #>>42674002 #
3. BurningFrog ◴[11 Jan 25 18:12 UTC] No.42667752[source]▶
One simple approach that the second, or at least third, time you deal with something, you invest time to learn it decently well. Then each time you come back to it, go a bit deeper.

This algorithm makes you learn the things you'll need quite well without having to understand and/or predict the future.

4. jppittma ◴[11 Jan 25 23:25 UTC] No.42669793[source]▶
If it’s a tool you use every day, it’s worth understanding on a deeper level. I’ve used the shell probably every day in my professional career, and knowing how to script has saved me and my team countless hours of tedious effort with super simple one liners.

The other thing that’s worth learning is that if you can find tools that everybody uses regularly, but nobody understands, then try to understand those, you can bring enormous value to your team/org.

5. aragilar ◴[12 Jan 25 02:56 UTC] No.42670902[source]▶
There's always the option of asking coworkers/friends/mentors/etc. what they found useful.
replies(1): >>42670914 #
6. kragen ◴[12 Jan 25 02:58 UTC] No.42670914[source]▶
I'm embarrassed I didn't mention this. Yes, collective mental effort can be orders of magnitude better than individual.
7. skydhash ◴[12 Jan 25 02:59 UTC] No.42670922[source]▶
> spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective

That's the most useful point. Sometimes just a few why-s can give you a clearer view on your activities and a direction for your efforts.

8. moregrist ◴[12 Jan 25 03:55 UTC] No.42671161[source]▶
> invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff.

The think you have a solid point with Postgres v Oracle and I haven’t followed game dev in a while, but your FreeCAD recommendation is so far from industry standard that I don’t think it’s good advice.

If you need to touch CAD design in a professional setting, learn SolidWorks or OnShape. They’re what every MechE I’ve ever worked with knows and uses, and they integrate product lifecycle aspects that FreeCAD does not.

replies(2): >>42672230 #>>42685694 #
9. kragen ◴[12 Jan 25 09:06 UTC] No.42672230{3}[source]▶
You could have said the same thing about Postgres vs. Oracle 30 years ago. But it's true that these heuristics are not always in agreement.
10. mkrajnak ◴[12 Jan 25 15:00 UTC] No.42674002[source]▶
I agree. An additional perspective that I have found useful came from a presentation I saw by one of the pragmatic programmers.

They suggested thinking about investing in skills like financial investments. That is, investments run on a spectrum from low risk, low return to high risk, high return.

Low risk investments will almost always pay out, but the return is usually modest. Their example: C#

High risk investments often fail to return anything, but sometimes will yield large returns. Their example: Leaning a foreign language.

Some key ideas I took away:

- Diversify.

- Focus on low risk to stay gainfully employed.

- Put some effort into high risk, but keep expectations safe.

- Your mix may vary based on your appetite for risk.

11. jononor ◴[13 Jan 25 17:05 UTC] No.42685694{3}[source]▶
10 years ago people said the same about KiCAD and Blender :) No guarantee that FreeCAD will be the same - but you can be pretty confident it will never go away.

However, if the goal is to be a full time employee doing CAD, I would of course going with one of the most established tools. Potentially even get some certifications.