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

261–270 of 347 posts

Re: Be Aware of the Makefile Effect

#261

Post by mianos »

f1shy wrote: post #119
mianos wrote: post #107

Earlier quoted context omitted.

I’d be curious to hear your ratio. It really varies. In some small teams with talented people, there are hardly any “fake” developers. But in larger companies, they can make up a huge chunk. Where I am now, it’s easily over 50%, and most of the real developers have already left. PS: The fakes aren’t always juniors. Sometimes you have junior folks who are actually really good—they just haven’t had time yet to discover…

My personal experience: - 5% geniuses. This are people who are passionate about what they do, they are always up to date. Typically humble, not loud people. - 15% good, can do it properly. Not passionate, but at least have a strong sense of responsibility. Want to do “the right thing” or do it right. Sometimes average intelligence, but really committed. - 80% I would not hire. People who talk a lot, and know very lit…

From my 40 years in the field, I see much the same trend. I wouldn’t call 5% of developers “genius”—maybe 1% are true geniuses. Those folks can be an order of magnitude better at certain tasks—doing things no one else can—but only within a limited sphere. They also bring their own baggage, like unique personalities. Still, I believe there’s always room for genius on a big team, even with all the complications.

Typically, upper management wants smooth, steady output. But the better your people are, the bumpier that output gets—and those “one-percenters” can produce some pretty extreme spikes. If you think of it like a graph, the area under the curve (the total productivity) can be way bigger for a spiky output than for a flat, low-level one. So even if those spikes look messy, they often deliver a ton of long-term value.

Re: Be Aware of the Makefile Effect

#262

Post by loglog »

brabel wrote: post #97
imoverclocked wrote: post #90

Earlier quoted context omitted.

That wasn’t my experience a few years ago with a large groovy-dsl project. Since groovy will take a look in several different namespaces to automatically resolve things in a script, editors I tried had no hope of telling me what anything was. Also, groovy allows modification of private instance variables which leads to … un-fun situations. I converted tens of thousands of lines of groovy to Kotlin. A lot of those lin…

Groovy closure delegates' type can be declared, giving as much information as with Kotlin. The reason you couldn't follow the code was that the people who wrote those things either didn't declare types, or IntelliJ wasn't using the type declarations (I believe Groovy support in Gradle files is less good than in general Groovy files, where the IDE does support this). You're correct that some plugins will resolve thing…

"Can" is the key word here. If types are optional, _someone_ will always fail to declare them, and _you_ will suffer.

Re: Be Aware of the Makefile Effect

#263

Post by DrNosferatu »

myhf wrote: post #204

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975) Systemantics: How Systems Really Work and How They Fail https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

What about the divine watchmak - sorry - developer?

Re: Be Aware of the Makefile Effect

#264

Post by xeonmc »

DrNosferatu wrote: post #263
myhf wrote: post #204

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975) Systemantics: How Systems Really Work and How They Fail https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

What about the divine watchmak - sorry - developer?

The 10x watchmaker, perhaps?

Re: Be Aware of the Makefile Effect

#265

Post by RHSeeger »

Quekid5 wrote: post #244
IgorPartola wrote: post #234

Make and Makefiles are incredibly simple when they are not autogenerated by autoconf. If they are generated by autoconf, don’t modify them, they are a build artifact. But also, ditch autoconf if you can. In the broader sense: yes this effect is very real. You can fall to it or you can exploit it. How I exploit it: write a bit of code (or copy/paste it from somewhere). Use it in a project. Refine as needed. When start…

They are simple but very often wrong . It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)

I use makefiles all the time for my projects; projects that are actually built with something else (ex, gradle, maven, whatever). My makefiles have targets for build, clean, dependencies, and a variety of other things. And they also have inputs (like "NOTEST=true") for altering how they run. And then I use make to actually build the project; so I don't need to remember how the specific build tool for _this_ project (or the one of many build tools in a project) happens to work. It works pretty well.

Re: Be Aware of the Makefile Effect

#266

Post by RHSeeger »

withinboredom wrote: post #255
mauvehaus wrote: post #251

Earlier quoted context omitted.

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is . That's sort essential to serving its purpose, after all. I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usual…

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files. If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`. Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or what…

This. I have no urge to have git "clean" my project, because I'll lose a ton of files I have created locally. Rather, I want the project know what it creates when it builds and have the ability to clean/purge them. It's a never ending source of frustration for me that "gradlew clean" only cleans _some_ stuff, and there's no real "gradlew distclean".

Re: Be Aware of the Makefile Effect

#267

Post by hedora »

Make has to be one of the more unfairly maligned languages out there. Most “replacements” purport to solve problems make doesn’t have, and are strictly worse than make at what they do.

Anyway, the GNU make manual is a good read for anyone that needs to edit a makefile or design a project build. So is “recursive make considered harmful”.

Re: Be Aware of the Makefile Effect

#268

Post by jppittma »

remus wrote: post #166
kragen wrote: post #99

Earlier quoted context omitted.

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 y…

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…

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.

Re: Be Aware of the Makefile Effect

#269

Post by jppittma »

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…

Skill issue. Time spent learning make will help you understand bazel etc.

Re: Be Aware of the Makefile Effect

#270

Post by johnnyanmac »

mrcsd wrote: post #253
oblio wrote: post #247

Earlier quoted context omitted.

Probably slower and with more respect for existing tech. But hey, now we have npm, so who cares anymore? :-)

Disrespect is part of progress, respectful humans are liable to blindness of flaws. Just as part of youthful creativity is disregard for what has come before.

I can't agree with that take. Criticism is a part of progress. You can be a critic but still be respectful.

Disrespect is simply to belittle and look down upon. I don't see many situations where such an attitude leads to progress.

Post reply on HN