7 ms·

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 alway

• f1shy 2y ago
  I would just change the percentages, but is about as true as it gets.
  • mianos 2y ago
    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 what they don’t know. It’s often absolutely clear that certain juniors will be very good just from a small contribution.
    • f1shy 2y ago
      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 little. Probably do the work just because they need the money. That applies for doctors, contractors, developers, taxi drivers, just about anything and everything. Those felt percentages had been consistent across 5 countries, 3 continents and 1/2 a century of life PS: results are corrected for seniority. Even in the apprentice level I could tell who was in each category.
      • mianos 2y ago
        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.
• sebazzz 2y ago
  > 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. Who likely wouldn't have a job if it weren't for LLMs.
  • raziel2p 2y ago
    pretty sure we've made this complaint about a subset of developers since way before chatgpt and the like.
    • f1shy 2y ago
      And that happens not only with developers, but in any profession, which gives me shivers when I go to the doctor!
• huijzer 2y ago
  > 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.
  • silver_silver 2y ago
    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
    • cudgy 2y ago
      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?
      • kragen 2y ago
        Maybe switch to less frequently updated dependencies and rewrite the easy ones in-house?
        • pdimitar 2y ago
          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.
• Loic 2y ago
  I like Makefiles, but just for me. Each time I create a new personal project, I add a Makefile at the root, even if the only target is the most basic of the corresponding language. This is because I can't remember all the variations of all the languages and frameworks build "sequences". But "$ make" is easy.
  • choeger 2y ago
    You're probably using the wrong tool and should consider a simple plain shell script (or a handful of them) for your tasks. test.sh, build.sh, etc.
    • poincaredisk 2y ago
      I disagree. Make is - at it's simplest form - exactly a "simple plain shell script" for your tasks, with some very nice bonus features like dependency resolution. Not the parent, bit I usually start with a two line makefile and add new commands/variables/rules when necessary.
    • nrclark 2y ago
      (not the parent) Make is - at its core - a tool for expressing and running short shell-scripts ("recipes", in Make parlance) with optional dependency relationships between each other. Why would I want to spread out my build logic across a bunch of shell scripts that I have to stitch together, when Make is a nicely integrated solution to this exact problem?
      • dwaltrip 2y ago
        Any modern attempts to do this better than make? I often write small “infra” bash scripts in my projects, maybe I could use a tool like that.
        • TheTaytay 2y ago
          I haven’t used them yet, but I keep seeing people touting alternatives, and in particular “just”: https://github.com/casey/just https://github.com/casey/just This is primarily aimed at a “task runner” replacement rather than a “compilation with automatic file timestamp comparison replacement” Others I stumbled across: Taskfile Mage XcFile None of them have tempted me enough to move away from a set of bash scripts or scripts written in the language of my repo (yet).
• adrian_b 2y ago
  Actually it is trivial to write a very simple Makefile for a 10,000 file project, despite the fact that almost all Makefiles that I have ever seen in open-source projects are ridiculously complicated, far more complicated than a good Makefile would be. In my opinion, it is a mistake almost always when you see in a Makefile an individual rule for making a single file. Normally, there should be only generic building rules that should be used for building any file of a given type. A Makefile should almost never contain lists of source files or of their dependencies. It should contain only a list with the directories where the source files are located. Make should search the source directories, find the source files, classify them by type, create their dependency lists and invoke appropriate building rules. At least with GNU make, this is very simple and described in its user manual. If you write a Makefile like this, it does not matter whether a project has 1 file or 10,000 files, the effort in creating or modifying the Makefile is equally negligible. Moreover, there is no need to update the Makefile whenever source files are created, renamed, moved or deleted.
  • mianos 2y ago
    If everything in your tree is similar, yes. I agree that's going to be a very small Makefile. While this is true, for much larger projects, that have lived for a long time, you will have many parts, all with slight differences. For example, over time the language flavour of the day comes and goes. Structure changes in new code. Often different subtrees are there for different platforms or environments. The Linux kernel is a good, maybe extreme, but clear example. There are hundreds of Makefiles.
    • adrian_b 2y ago
      Different platforms and environments are handled easily by Make "variables" (actually constants), which have platform-specific definitions, and which are sequestered into a platform-specific Makefile that contains only definitions. Then the Makefiles that build a target file, e.g. executable or library, include the appropriate platform-specific Makefile, to get all the platform-specific definitions. Most of my work is directed towards embedded computers with various architectures and operating systems, so multi-platform projects are the norm, not the exception. A Makefile contains 3 kinds of lines: definitions, rules and targets (typical targets may be "all", "release", "debug", "clean" and so on). I prefer to keep these in separate files. If you parametrize your rules and targets with enough Make variables to allow their customization for any environment and project, you must almost never touch the Makefiles with rules and targets. For each platform/environment, you write a file with appropriate definitions, like the names of the tools and their command-line options. The simplest way to build a complex project is to build it in a directory with a subdirectory for each file that must be created. In the parent directory you put a Makefile that is the same for all projects, which just invokes all the Makefiles from the subdirectories that it finds below, passing any CLI options. In the subdirectory for each generated file, you just put a minimal Makefile, with only a few lines, which includes the Makefiles with generic rules and targets and the Makefile with platform-specific definitions, adding the only information that is special for the generated file, i.e. what kind of file it is, e.g. executable, static library, dynamic library etc., a list of directories where to search for source files, the strings that should be passed to compilers for their include directory list and their preprocessor definition list, and optionally and infrequently you may override some Make definitions, e.g. for providing some special tool options, e.g. when you generate from a single source multiple object files.
• afiori 2y ago
  Being able to set up things and truly understanding how they work are quite different imo. I agree with the idea that a lot of productive app developers would not be able to set up a new project ex novo but often it is not about particularly true understanding but rather knowing the correct set of magic rules and incantations to make many tools work well together
• znpy 2y ago
  > They can be a bad choice for a 10,000-file monster Whether they are a bad choice really depends on what are the alternatives though