1. 7
    Don't Learn Too Many Things education codingunicorn.dev
  1.  

  2. 26

    While spreading yourself overly thin is definitely a bad idea, this article is basically about the generalist vs specialist debate, and goes all-in on the specialist side.

    While there is value in being very knowledgeable in a certain domain or technology, it also makes you less flexible with regards to possible employers or different projects within a single company. I’ve worked with plenty of developers who refuse to learn a new technology stack, because they think they’ll start as beginners again and it will hamper their career growth (more specifically, they fear that they will not grow their income at the same rate they would if they continued working with the same thing).

    However, the technology landscape changes, perhaps not overnight but definitely over the course of an entire career. Sticking to what you’re experienced at may lead to a dead end some years in the future.

    Additionally, I believe that many of the important skills that make a developer more valuable are not related to using specific technologies or tools, but rather in generic skills that are transferable across languages, tools and frameworks.

    Using and learning new technologies might also prevent you from forming tunnel vision. If all you have is classes and inheritance, everything starts looking like it should be an object, for example.

    You probably shouldn’t use a different language for every project, the same way you shouldn’t use a different Javascript framework for every project just because it’s the hot new thing. But I also think you shouldn’t bet the house on a single language and/or framework just because you consider yourself an expert in that niche.

    1. 10

      While spreading yourself overly thin is definitely a bad idea, this article is basically about the generalist vs specialist debate, and goes all-in on the specialist side.

      I don’t agree. I think the article is trying to signpost a danger for new folks coming to our field - that is the temptation to feel like I MUST LEARN ALL THE THINGS! rather than realizing that there is tremendous depth at play here and that while having a broad skillset is good, you MUST be able to go deep on some small subset of things, whether or not you’re a specialist or a generalist.

      I’d also argue that being a generalist can make it damn hard to stay employed, because the entire recruiting machine wants to plug discrete shapes into discretely shaped holes, and if you don’t fit that model you’re gonna have to work 10 times as hard to make it past said machine rather than working with it.

      That’s my experience, anyway.

      1. 3

        Yes, recruiting machines want developers with specific boxes checked on their resume. But I generally find it pretty easy to write a resume for a specific position highlighting the stuff I’ve done they want to hear while only mentioning others in passing.

        There is also a shortage of qualified workers in our field, at least for now, so as soon as you can match a few of the qualities they’re looking for, you can land an interview, and from there it’s easier to convince a hiring manager that you’re a capable worker.

        1. 2

          I think it’s possible we’re talking about two different things here.

          Landing a job is one set of skills - thriving in a job is quite another.

          I’m talking about the latter.

          1. 2

            I’m replying specifically to your remark about recruitement looking for specific profile features to fill certain positions in your parent comment.

        2. 3

          Breadth & depth are not in contradiction, once you get beyond a very beginner level – particularly in terms of the kind of tech that gets used in our industry, since programming language design for ‘general purpose’ languages & best practices for ‘enterprise’ system is extremely intellectually incestuous. If you know two C-like languages, you can read and write fifty more without actually learning them, or learn them as well in an afternoon as a beginner could in two months.

          It’s possible to go deep into a domain that doesn’t have broad applicability, but you have to look hard for such a thing. Extremely deep and seemingly-disconnected subjects like cryptography & type / category theory are having a big impact, and weird and previously-obscure languages like haskell are starting to influence how normies write their java.

          The strangest statement here is where OP says that “even experienced developers don’t know that much”, for a list of technologies that looks like what somebody would put down as the minimum requirements for applying for a junior web dev position. It’s one thing to go all-in on specialist knowledge, but it’s another thing entirely to define the domain so narrowly that everybody with a bachelor’s degree and a vague interest counts as expert.

          Since this article is aimed at junior devs & folks who are still in college, let me be clear: at this stage of development, you lack the background to determine what is and is not likely to be relevant to future tasks and projects, so your job (first and foremost) is to learn everything. Doing ‘professional’ work with the kind of attenuated understanding that comes from only studying things that are obviously applicable to outsiders is the source of many problems, ranging from merely wasteful and stupid to actually dangerous.

          1. 1

            Since this article is aimed at junior devs & folks who are still in college, let me be clear: at this stage of development, you lack the background to determine what is and is not likely to be relevant to future tasks and projects, so your job (first and foremost) is to learn everything. Doing ‘professional’ work with the kind of attenuated understanding that comes from only studying things that are obviously applicable to outsiders is the source of many problems, ranging from merely wasteful and stupid to actually dangerous.

            I don’t disagree, but I also think it’s super important to learn how to learn the necessary skills to accomplish your goals.

            Maybe that’s key - create goals for yourself. Build things. Meaningful things, not just variations of Hello World or examples of the particular pony tricks your new pet language can do well.

            In learning what you need to actually build projects that you can be proud of, you’ll achieve many goals people have stated here - learning the important stuff that’s not language or tech driven, and learning how to learn in a focused way to achieve a particular task / goal, and also getting used to the idea of having projects for yourself that you design, build, test and “ship” for whatever values of “ship” you’re comfortable with - maybe putting them on your github page for example.

            1. 2

              not just variations of Hello World or examples of the particular pony tricks your new pet language can do well.

              This is a good point. You don’t learn much by catering to a toolset’s strengths.

              In college (and, to a lesser extent, as a junior dev – and to a greater extent, before college, if you are lucky enough to get coding that early) you’ve got time to do things the hard way, and there are a lot of lessons that are best learned by doing things the hard way. So, this is the time to intentionally use the wrong tool for the job, be perverse, and jump into projects that are way above your skill level and way outside your comfort zone. The more you do this, the better you’ll become at not being discouraged by technical and social hurdles, & the bigger your comfort zone will become.

              A pattern I see with colleagues who learned to code in college is that they’re very precious about sticking to their preferred tools & idioms. They did all their exploration in four years, and ever since, they’ve been under pressure to perform, so new tools and techniques are not just alien but represent a (only mostly imaginary) threat to their livelihoods. They become hyper-specialists. They have never learned the lessons that can only be gained from doing the maximally-wrong thing, because they have never been secure enough to be willing to waste their time, and as a result they’re stuck in a lower grade of expertise than they could attain.

              The case I typically make for being a generalist, which all these things feed back into, is that the utility of knowledge is weighted by rarity, and rarity is affected by expected utility. Utility and expected utility have little to do with each other outside of situations where nothing is being discovered – if you’re a code monkey writing trivial mashups of big existing libraries, insulated from users, it’s possible to do your work for years and never be surprised or need to learn a new concept, but if you’re doing non-trivial work then you will frequently run into problems that you couldn’t have predicted, and those problems will be ones whose best solutions rely upon knowledge that you couldn’t have previously predicted you would have needed. General knowledge (like a background in common data structures and algorithms) is broad enough to solve a lot of problems, but it’s also standardized – everybody with a CS degree has at least vague familiarity with a bunch of sorting algorithms & their time complexity, can implement a linked list or a binary tree, knows that tree rebalancing is a thing and can look up how to do it, has some basic graph theory under their belt & can write a greedy graph traversal algorithm, etc. So, your value as a developer (whether you are somebody’s employee or just writing your own projects) is based around how you’ve deviated from the norm: if you know MUMPS or J or Idris, or you can write a bootloader or a prover or a compiler, or you know category theory or fast fourier transform or fast inverse square root, or you can write professional-quality prose or can translate between russian and korean.

              It’s a high bar to set, for every programmer to know enough things that nobody else knows as to be sure, statistically, that at least a couple of them will unexpectedly come in handy. But, we don’t need as many professional programmers as we have, and folks who pass this bar are going to be a lot more useful (not in the ‘10x programmer’ sense of straight linear productivity but in the sense that some obvious-but-ultimately-bad plans will never be attempted). Anyway, such folks have more opportunities & are less replacable, so I recommend everybody endevour to become such a person.

              1. 1

                The case I typically make for being a generalist, which all these things feed back into, is that the utility of knowledge is weighted by rarity, and rarity is affected by expected utility. Utility and expected utility have little to do with each other outside of situations where nothing is being discovered – if you’re a code monkey writing trivial mashups of big existing libraries, insulated from users, it’s possible to do your work for years and never be surprised or need to learn a new concept

                This is the danger of over-specialization. You don’t learn how to learn quickly and effectively, and never gain that intellectual suppleness which will allow you to adversity and new situations.

                It’s a high bar to set, for every programmer to know enough things that nobody else knows as to be sure, statistically, that at least a couple of them will unexpectedly come in handy. But, we don’t need as many professional programmers as we have, and folks who pass this bar are going to be a lot more useful (not in the ‘10x programmer’ sense of straight linear productivity but in the sense that some obvious-but-ultimately-bad plans will never be attempted). Anyway, such folks have more opportunities & are less replacable, so I recommend everybody endevour to become such a person.

                So there’s how you build your skill set and how you market yourself. These do not necessarily need to correlate closely :)

                I am definitely in favor of priming ones self to be a generalist, but I also think it’s important to be able to market yourself to at least a particular broad area of our industry.

                For instance, I tend towards “Devops” work which is a CRAPPY designation for anything involving infrastructure and not generally solving hard computer science problems, but still code-centric.

                So, yes build a generalist’s skill set, but be prepared to sail your career ship in a particular direction or you may find that there are no winds to propel you.

                1. 2

                  Sure. Few companies will give roles to junior devs that entail broad responsibilities. I don’t think that means you need to hide those skills. The broader your skillset, the more likely it is that any given narrow specialization will fall within your wheelhouse.

                  That said, I’ve been at the same place since my intership so maybe the market for candidates is allergic to the ‘overqualified’ & I’m just unaware.

          2. 2

            you MUST be able to go deep on some small subset of things, whether or not you’re a specialist or a generalist.

            Where do you find this “MUST”? As far as I can tell, speaking at such a level of generality, the only must is what is needed to do a job, solve a problem, achieve an aim, etc. One needs to be as specialized as the circumstance requires. But I’m struggling to make the leap from that to some categorical imperative of depth, your MUST.

            1. 1

              And how might one attain the level of depth needed to do a given job if one spends one’s time chasing bright shiny new languages and tools?

              You’re right, we’re speaking in generalities, and I’m sorry my use of the word MUST seems to have triggered you, but my general point still holds, even if you downgrade the word in question to, say, a lowercase ‘need to’?

              1. 1

                Haha, I’m not triggered. I think you’re setting up a false dilemma. If I have a job that requires a superficial understanding of a bunch of tools, then I would not be “thriving” in my job if I was trying to cultivate specialization in a few of those tools. I think the real distinction is between stuff that is necessary to do the job and stuff that isn’t. It’s not between depth and breadth. For example, I was recently talking to a friend who just founded a consulting company. In the past few months, he’s worked with several new languages, none of which he plans to specialize in. Working with those languages is what he needed to do to get the job done. Beyond getting the job done, learning more about those languages has diminishing returns. Specializing in anything is only a good idea if the specialization has utility. I think a better principle is to invest time in things proportional to their utility. That really depends on the context and could result in specialization or generalization.

          3. 2

            many of the important skills that make a developer more valuable are not related to using specific technologies or tools, but rather in generic skills that are transferable across languages, tools and frameworks.

            This ^.

            Or, as they say, “learn weightier shit”.

            1. 1

              This is something different again - you can’t learn “the weightier shit” unless you choose a language or two and stick there. Humans, even the most intelligent ones, can only learn so many things at once.

              So, my point stands. Choose a subset of tools and go deep. Go deep means, in addition to mastery of that particular tool or language, that you learn “the weighty shit” :)

              1. 2

                Oh no, no, no, it’s the other “weightier” stuff. It’s things that make sense in engineering in general. Like, a function that does one thing and doesn’t affect surroundings in unexpected ways is as good a thing in Java, as it is in Scheme. Or, say, the idea that you need a queue in between producers and consumers. Or various implications of forks vs. threads vs. polling loops. Or understanding why you can’t parse HTML with a regex.

                Knowledge like this weighs more than knowing how do you sort an array in your current language/framework.

          4. 12

            I am surprised such a short article created such a large response (currently 18 comments plus mine).

            And I think it’s because the title is strongly polarizing (the default human behavior is to go without having to learn new things) and the post just throws in a personal list (from the author’s POV) of things someone should know, a memey photo, and an ending statement. Is that enough for being worthy of discussion?

            Obviously this like so many other topics has both a “it depends” and “we need both in the world” answer. So, why is this not being downvoted away?

            So please fellow Lobsteriañitos, don’t fall for these low effort, polarising and unresearched submissions. It’s there to trick you into, obviously, providing your take on the subject.

            1. 6

              I’m seeing a lot of blind leading the blind posts on here in the last couple of days. Flagging these as spam is taking far to long to have them removed.

              1. 8

                This is coming from a particularly spammy account too. I am rather annoyed by the author spamming a load of low-quality posts in rapid succession — supposedly because this is how social media marketing is done or something — and using her sexuality to market herself as a programmer too.

                https://www.instagram.com/p/BlYV1b-n8K9/?igshid=q1cw4umuiizt

                Like, here’s a book, but also — what a coincidence — here’s my tits!

                This is just bad.

                1. 4

                  Yes, there used to be a time when this kind of stuff didn’t make it to the front page of lobsters, but the social media arms race never stops :\

                2. 1

                  I wonder if there’s a case to remove or demote short posts in general. A short post isn’t necessarily low-information, and long posts can be mostly pointless fluff, but 80-90% of the time anything under 2,000 words isn’t worth reading (and wasn’t worth writing) for a technical audience like ours.

                  Not that it would be trivial to automate detecting the length of blog posts… I guess we could support a tag like ‘short’, & expect folks to tag in good faith.

                  In cases like OP, a 50k-word post on this subject would be interesting, and the author wrote a short paragraph instead because they hadn’t put more than a minute’s thought into the subject and could not have written a post worth reading. In fact, if the same author wrote 50k words on the same subject, the result would probably be more interesting even if the thesis didn’t change, simply because complications arise with that sort of depth. (I’d still consider OP to be wrong, but I would no longer consider the post a low-effort click-grab.)

                  1. 3

                    I semi-suggested a “low-info” flag a few months ago. I guess “off-topic” is a better catch-all

                    https://lobste.rs/s/nqntbn/ban_filter_submissions_from_twitter_com#c_dwuhdo

                    1. 4

                      I think a low-info flag is better, tbh. OP is a case in point: the post is on-topic – it just doesn’t say anything of value, because it’s not the product of more than a minute of thought or work. The ‘spam’ flag appears to be doing double-duty as a ‘low-info’ flag, though (as opposed to merely flagging self-promotion and promotion of products).

                      The reason I think the ‘short’ tag is valuable is that there’s difference of opinion about whether or not a blog post of this length can ever be interesting enough to justify a lobste.rs post. Some folks are going to want to filter out short posts entirely, weighing the value of their time over the miniscule chance that a short post will say something interesting. Obviously, other people have lower standards – at the time of this writing, even though it’s been downvoted & flagged as spam nearly 20 times, its ranking is positive. Those folks can have their cake – we could treat the ‘short’ tag the way we treat other tags of dubious average information content (like ‘rant’, ‘satire’, and ‘show’) and demote short posts by default, while allowing them to rise to the front page if they’re actually high-quality, and allowing folks like you and me to block them entirely.

                    2. 1

                      I don’t think it’s quite as simple as post length. Someone smart and worth listening to can distil a compelling idea even into 140 characters. The problem here really is that the author’s articles are just spammy garbage. The formula is transparent — offer up some programming-themed platitudes accompanied by emoji and a photo of the author trying to look cute. It’s particularly egregious when many of the author’s posts are tagged with some variation of the #girlswhocode theme. Like, is that helping any of the many women who want to be taken seriously in our field purely on the basis of their intellectual merit? Of course it isn’t. It’s plain harmful.

                      1. 2

                        Someone smart can write a good short post – on occasion. Even then, it’s rare. Most short blog posts are of a comparable quality to this one, even if they are by folks who usually write high-quality long posts.

                        I’m not recommending banning short posts, but tagging them so that folks who would like to avoid trudging through the swamps of low-quality content (or would like to temper their expectations upon encountering a juicy headline like this one) have better tools for avoiding wasting their time.

                  2. 12

                    This has a bunch of active discussion, so I feel compelled to mention that @CodingUnicorn/coding_unicorn/co.ding.unicorn was a sockpuppet of @eduardsi. The logs were unambiguous. I banned both accounts.

                    1. 5

                      How about a compromise position: Lazy Learning

                      Get the basics of most things, and don’t even necessarily aspire to be an expert, knowing you don’t have the time, the tools or the means do be one. But try to understand the important lessons, or the benefits, practical use cases, etc – generally when it would be worth diving deeper into the subject, and then having just that bit easier, since you know what you’re getting into, than having to spontaneously learn everything you encounter.

                      1. 5

                        This concisely frames the biggest regret of my career life. Rather than getting distracted by bright shiny things I should have doubled down and mastered fewer of them. The fact that I didn’t really hurt my career in subtle ways.

                        I was mostly able to work around it by applying a lot of effort at crunch time and leveraging collaboration, but it was a chink in my armor and I knew it.

                        I’m fixing it now but it’s a bit of a slog given the intensity of my current job. I wish I’d taken the time to do this when I was more junior when that kind of time is budgeted in.

                        1. 3

                          It’s better to be good at something, instead of mediocre at everything.

                          The saying goes.

                          Jack of all trades, master of none, but oftentimes better than master of one

                          That said. I went down the too spread out route through early years of my career. It’s still hard to tell if that was a general net gain or a net loss. I did everything from Common Lisp, concatenative languages like forth, prolog, smalltalk, erlang up to backend web development in perl, python, ruby, frontend javascript and embedded development on ARM boards in C, Ada and C++.

                          The only time I had a chance to really specialize was with databases while working at a corporation (7 years). I’m tired of switching tech and I realized I can’t get a deep understanding of everything so focusing down the list of stuff I touch is my goal for the past several years.

                          I’m now only doing C, Shell, Python, PostgreSQL on BSD in netsec setting. Nothing more, nothing less.

                          1. 3

                            My main criticism is that this view is to simplistic.

                            1. 5 out of 8 technologies listed are closely related.
                            2. AWS is simply a cloud of virtual machines and/or a storage network. Nothing new and nothing to see here.
                            3. The Rust and Go ecosystems are relatively small.

                            As someone with a degree in CS, I have a firm grasp of Java, Haskell, SQL, R, HTML/CSS and PHP (yes also up to version 7.2). They even made us build our own compilers!

                            As a consequence of this, I’ve never had any trouble when I had to “work on something” in languages like Python, C#, C/C++, TCL/TK, Prolog and Ada. The only real dent in my armor is JavaScript, with which I can only just get by (hello 14x14 equality operator matrix!).

                            And the “tremendous depth at play”? I don’t think most things listed here are that deep.

                            I’ve mostly learned fundamentals, like algorithms, data-structures, complexity theory and a few completely different programming paradigms. But the overall fundamental which is the main thread of which you have to keep a firm grasp is just simply “fundamental skills, maths and algebra’s”.

                            If you can get those into your head, you can out-program nearly everyone who has focussed on just a singular technology only. In fact when you’ve hit that mark, it doesn’t matter all that much which specific language you are using. You just simply adapt. You’ll also discover that you won’t need 95% of the tools which are provided to you in a production setting.

                            1. 2

                              I think this can be good advice for people. Expecting to learn a ton of things quickly and being unable to can be discouraging.

                              But at the same time, I’m glad I wasn’t given this advice early on. Learning lots of different technologies made me become more and more interested in diving deeper. Seeing the differences between various things (javascript vs python vs java vs php) compelled me to explore further and led me things outside the mainstream.

                              The author of this posts knows the person in question and so is in a much better position to give them advice. But for other people I think learning lots of technologies can be really beneficial, especially learning things that are very different from what you already know. Programming is fun, playing with technology is fun. Sometimes it is much more fun to dabble in lots of things than becoming an expert at one.

                              So my advice is don’t over burden yourself by feeling like you have to know everything at the beginning. But have fun, explore, and be open to new ways of doing things.

                              1. 2

                                I’m not sure that focusing on a few items on the list is any better than attempting to address them all. The preface to How to Design Programs discusses an idea of “transferable skills”, problem solving strategies which aren’t domain specific. Tools come and go, but these skills remain applicable. That’s the kind of thing I’m interested in. The quantity of things I’m learning about is no indication of how useful those things are, how much more effective they make me. If I’m learning a lot of things that make me much more effective, it would be counterproductive to cut back in observation of a rule about quantity. I’m not sure there’s anything inherently better about focusing on one language for a year or focusing on 8 languages for a year. The outcome can be shallow in both cases. The important question is how fundamental, how transferable are the skills I’m building using the tools I’m working with.

                                1. 2

                                  I think it’s worth differentiating between learning things as specific tools, and things as ideas. You can probably get by with only knowing one or two languages very well, and having a passing knowledge in others. But there’s things like “gathering requirements”, “debugging”, “ontologies”, “organizing work for the week” that are incredibly valuable skills that you can go both broad and deep in, that help you much more than a given language will.

                                  1. 2

                                    Even experienced developers don’t know that much stuff. And you shouldn’t.

                                    This is often my biggest issue with so-called “experience developers” – unwillingness to learn anything new. Just stick to whatever mediocre tool you already know and call it a life. I don’t understand how these people remain employed.

                                    1. 2

                                      I know a good deal more topics in programming than that list, and I know most of that list excl Rails/Node.

                                      This is good very junior dev advice; I expect a senior developer, particularly in my subarea, to be a square: know a metric ton about a metric ton.

                                      1. 2

                                        She’s pretty on point here. Learning about things, and learning things are quite different. If you’re looking to apply something you’re going to learn, it’s probably good to learn about a thing before you learn it. If these were “Learn about rust, ruby, etc” that would be fine, but yeah it’s possible to really squander learning time by learning too broad and too shallow to apply anything.

                                        1. 1

                                          It depends. Purely looking at the programming field, then yes, I agree: in practice you will usually work on a specialized software component that communicates with components made by other teams over an agreed protocol or interface. So, the better you are at that specific thing, the better your career.

                                          I’m studying to become an engineer, and I think it’s a bit different in that field. I confess that I haven’t actually entered the job market there yet, but from the stories I hear from people who have, it seems large amounts of time are wasted on a lack of mutual understanding between multiple disciplines. Therefore I think having at least a basic insight into other specializations would be very helpful.

                                          Or maybe I’m just looking for excuses for the fact I’m going in a fairly broad direction myself ;-)

                                          1. 1

                                            What was the timeline on this roadmap? That’s a LOT of stuff, especially if they’re coming from no prior knowledge.

                                            I would say that I am a specialist in the JavaScript ecosystem, but I also am proficient in a lot of other things (including AWS, Docker, plain server setup with apache/nginx, a bunch of programming languages). If this was like a 10-year plan, it’s not a bad idea. If they were trying to do it in 6 months or something nutty, then it’s pointless.

                                            If you have real interest in tinkering, you’re naturally going to learn a bunch about more than one language. And really, a lot of it (other than ecosystem) is not very difficult to learn from one language to another. If you understand the fundamentals of CS, you’re already ahead of the game.

                                            1. 1

                                              My approach is to try to keep getting a better understanding of foundational stuff (including history), and lazily relate back the new stuff back to that. I don’t go too deep unless I need to, but it really helps cut down the churn if you have a general idea where certain ideas and approaches come from, or can easily look it up if you need to. Not in a ‘hey look, that’s already been done before!’ kind of way, but more a ‘hey cool, somebody is doing that again - I wonder what is the same/different!’ kind of way. It’s not something you can learn all at once, but investing in it over time seems to make things easier.