5 ms·

Not every developer. I'm not trying to be snarky. I think there's an unhelpful compunction to want to know everything about everything among STEM types like pr

• Jiro 3y ago
  Over-specialization is hard on your ability to find another job if you lose your current one.
  • Jeff_Brown 3y ago
    Completely true. The analogy to hydration holds, I think -- too much and too little can both be problematic. But I see seem to run into much more under-specialization than over-specialization. More than 90% of the wildest successes I know went really deep on something pretty narrow.
    • HPsquared 3y ago
      Specialization is like putting everything on one number in roulette. It's great if you win (i.e. your specialty is in demand), but you're more likely to lose everything you invested.
      • Jeff_Brown 3y ago
        It is a risk, but not as bad as you suggest, because (1) in work you can get an incremental sense of what is worth specializing in, and (2) there's always some degree to which skills are transferrable and experience is impressive even to someone who doesn't need you to do what you did again.
  • andrewSC 3y ago
    And so it’s a balance :^) I personally take the approach of specializing in what I believe to be my natural talents (i.e. seemingly able to pick up X much easier than whoever) while just being generally aware of new technologies or other spaces/sectors. Also tinkering and/or having a general interest in tech helps lol.. IME doing this has helped me pivot into a new tech or other areas where I may not be specialized in, but may need to eventually be for a new role. Also worth mentioning is taking a pragmatic approach to problem solving in general.. I’ve personally found that if you’re able to demonstrate solid reasoning and/or problem solving, generally learning a new lang or specializing in something different than what you’re used to, isn’t too too bad. I’m not really sure how specialists outside of tech/in other sectors can transition into other roles “easily” though… hm. Edit: I wanted to mention that IME in STEM, most? More often than not? are goal oriented… It is _completely_ okay to not have any “working” thing at the end of your tinkering/learning… The journey into that “thing” can be a learning experience in and of itself. I’ve often started to learn things but after a certain point have told myself “I’m gonna stop here and that’s okay. I don’t need to have a solid understanding of this, at this time”. YMMV…
• nabla9 3y ago
  This is just minimum for those don't need to know details. Even general knowledge has depth. Even if you are generalist, or specialist in different area you should deepen your knowledge at every area gradually.
  • abhi9u 3y ago
    True. This is probably what first few lectures of a first course on GPU computing would cover. The nitty gritty of how to write parallel algorithms for maximum throughput on the GPU is where things become too specific. :)
• cratermoon 3y ago
  I dunno. The section "Latency Tolerance, High Throughput and Little’s Law" has many applications in programming. Ever need to scale your cache, or size a connection pool? Little's Law.
  • abhi9u 3y ago
    Thank you for reading! :)
    • cratermoon 3y ago
      Thanks for writing this. I note you mention that GPUs are massively parallel, and I think it would strengthen the article to add a paragraph or two discussing what kinds of loads lend themselves to GPU computing. The sort of "embarrassingly parallel" things like linear algebra vs inherently serial example of numerical analysis.
      • abhi9u 3y ago
        Yes, that's a good feedback. Few other people also mentioned this. I was trying to save space, to spend time more on the "how things work" part. But I see your point that some motivation behind parallelization would make it a more interesting read.
• yodsanklai 3y ago
  > It can feel like a paintful sacrifice to admit that you'll never (have time to) learn And even if you do have time, you'll probably forget most of it if you don't make use of it in your daily job. Also if you do want to learn about a new topic, it'll take commitment. I remember going through an MIT OS project, it took me something like 50 hours of hours to complete the project. Pretty much impossible when you have a full time job (I didn't at the time). And despite that, I still consider myself a newbie in OS development. That being said, a little extra knowledge can come handy and make a difference in an interview for instance, or reduce ramp-up time when changing teams. This is also what school is for. Give you full time and a structured program to pick the fundamentals. There's only so much you can learn once you have a demanding job. It's actually pretty sad we don't get to go back to school in the middle of our career. Edit: still an interesting article ;)
  • abhi9u 3y ago
    Thank you :)
  • owl57 3y ago
    > I remember going through an MIT OS project, it took me something like 50 hours of hours to complete the project. Pretty much impossible when you have a full time job (I didn't at the time). And despite that, I still consider myself a newbie in OS development. I took an OS course loosely based on MIT one, and of course wouldn't consider myself an experienced OS developer as well, but I think the residual knowledge is sometimes really helpful when debugging bad application performance at work.
• pjmlp 3y ago
  Indeed, one thing that most seniors learn is humility and being able to say I don't know, without caring about consequences.
  • bobwaycott 3y ago
    An invaluable life skill, as well.
• loeg 3y ago
  At this point, I think the running shtick / inside joke of "Every Developer Should Know ..." headlines is that of course every developer doesn't need to know the contents of the article that follows.
  • bachmeier 3y ago
    Not true. Anyone experienced in programming discussions knows that "software development" overlaps exactly with the programming done by the commenter, and everything else is solving toy problems with tools that don't scale.
  • wongarsu 3y ago
    > of course every developer doesn't need to know the contents of the article that follows. Things every developer should know about English, part 1: why word order matters in negation /s Obviously you meant "not every developer needs to know" instead of "every developer doesn't need to know", but I see this switch so often lately that I'm beginning to wonder if it's a dialect thing (similar to double negative implying a positive to some and an emphasis of the negative to others)
    • deleted 3y ago
      [deleted]
    • a1369209993 3y ago
      Actually, that seems to be a legitimate precedence ambiguity. The probably more common way to parse/interpret it is: > [Foreach developer D, D] needs to know this. > [Foreach developer D, D] doesn't need to know this. (No developers.) But you could also have: > [The logical conjuction of all developers[0]] needs to know this. > [The logical conjuction of all developers] doesn't need to know this. (Not all developers.) The former convention is clearly better unless I've missed something rather significant, but inherently broken features in a number of programming languages (eg perl 6 'junctive' operators) suggest the latter is well-established as a thing that exists. 0: ie, a linguistic fiction that has only those properties / needs only those things that are common to every developer.
  • 3y ago
• cj 3y ago
  One thing I find interesting about the software industry is our lack of descriptive job titles. At big companies you have SWE L1, L2, L3, senior, staff, principal, etc. You also have SRE and maybe some devops or architect roles. Smaller companies you have lots of people generic “engineer” titles or “full stack engineers”, etc. Why don’t we encode people’s specialties in their titles if most engineers are working on narrow sections of software? E.g. “React & Node Developer” instead of “Full stack engineer” … etc I suppose the easiest rationale is generic titles allow for easier mobility between disciplines.
• crabbone 3y ago
  You are interpreting the title literally, while all this article is trying to do is to give an introduction to anyone who wants to get into GPU programming. Now, about every developer. Ideally, developers should know something, in general, about all fields related to programming. Similar to how in medicine you need to learn about different branches of medicine, even though you'll specialize in one, and so it is in mathematics, physics and so on. Presently, the demand for quality professionals in programming is very low. There aren't any good testing or certification programs that can tell a good programmer from a bad one. The industry is generally happy with "specialists" who perhaps only know to do one thing, somewhat. So, presently you don't need to know anything about GPU or any other field that's not directly related to your job description. ---- Now, about the article itself. While it gives a lot of valuable factual information, it's missing the forest for the trees. It's very dedicated to how CUDA works or some other particular aspects of NVidia's GPUs. The part that's missing is the part that could make it, potentially, a candidate for the kind of introduction to GPU programming that would make it worth reading to expand your general understanding of how computers work. If you ever paid attention to how encyclopedic articles are written: the structure of a definition given by encyclopedia often has two components. First puts the object of the definition into the more general category, second explains how the object of the definition is different from other elements of the category. What the GPU article is missing is the first component: putting GPU programming into the more general category. This, in practical terms, means that questions like "is DPU programming anything like GPU programming?" or "can `smart' SSDs (with FPGAs) be treated similar to GPUs?" unanswered.
• deleted 3y ago
  [deleted]
• nativeit 3y ago
  I can appreciate what you’re getting at in mourning the absence of greater opportunities for in-depth learning, but I personally value and appreciate the learning process such that I am overwhelmed by gratitude that I will likely never be without something to hold my interest. I have a deep understanding of the things I use in my daily work, but I think holding a breadth of knowledge is also useful in that you have a higher appreciation for what other specialists know and do, and in the event you need something novel, you may have a head start in getting to the knowledge you need at the time. I view it as unreservedly positive to audit many subjects even if you cannot engage with them further.
• Agingcoder 3y ago
  I’d say very few actually ( and I say this from the perspective of someone who used to work in hpc ). If they need to know about hw, most devs need to know about their primary platform, ie cpu. Gpus for general purpose computing ( I’m deliberately excluding games here, and even then it’s not obvious ) and programmed by people who don’t write ml/hpc libraries are far from ubiquitous. Yes, you want to know as much as possible ( helps debugging/zooming in on issues since you don’t need to introduce an outsider to your problem, helps avoid errors), yes you need to specialize somewhere, no you can’t know everything and often don’t need to