29 ms·

How Developers Stop Learning: Rise of the Expert Beginner (2012)

• Amlan123 6y ago
  Hii
• Amlan123 6y ago
  From india
• plorntus 6y ago
  I feel like that article took way too long to get to the actual point of it then unfortunately abruptly ended as soon as it got interesting.
  • plorntus 6y ago
    Ah its first in a series, the first time Next up links hasn't just been completely irrelevant articles.
    • hyperman1 6y ago
      You know, I've seen this article a few times before, and I never even tried to click Next up. Thanks. PART 2 https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner/ https://daedtech.com/how-software-groups-rot-legacy-of-the-e... PART 3 https://daedtech.com/how-stagnation-is-justified-language-of-the-expert-beginner/ https://daedtech.com/how-stagnation-is-justified-language-of... PART 4 https://daedtech.com/up-or-not-ambition-of-the-expert-beginner/ https://daedtech.com/up-or-not-ambition-of-the-expert-beginn...
• Sniffnoy 6y ago
  (2012)
  • deleted 6y ago
    [deleted]
• zubspace 6y ago
  As such, Advanced Beginners can break one of two ways: they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert. I think, that viewpoint is a bit narrow. The example, where the author tells the story how he started bowling the wrong way and reached a plateau, where he could not further progress, is a good one. And I'm sure there are numerous examples each one of us can tell of own experiences made when learning new skills. In my opinion learning new skills fast is a great skill. And nowadays there are many resources available to us make this easy. But you will always reach a plateau, where further progression gets increasingly difficult. It's fascinating how this corresponds to larger patterns like the Gartner Hype Cycle [1]. The question is, what do you do when you reach a plateau? Do you invest more time and money? Maybe the skill level suits you well and you don't feel a need to progress further? Maybe deeper understanding is not necessary to do your job well? Maybe it's better to acquire different skills which you can combine instead of being an expert in one area alone? I think there are many nuanced answers to that question and simply put blame on the expert beginner is not useful. [1] https://blogs.gartner.com/smarterwithgartner/files/2019/08/CTMKT_741609_CTMKT_for_Emerging_Tech_Hype_Cycle_LargerText-1-1024x974.png https://blogs.gartner.com/smarterwithgartner/files/2019/08/C...
  • scarface74 6y ago
    But you will always reach a plateau, where further progression gets increasingly difficult. It's fascinating how this corresponds to larger patterns like the Gartner Hype Cycle [1] It’s not just about skill progression. To stay relevant and not be seen as an old out of touch developer, you have to know how and when to jump on the next hype cycle.
    • Chilinot 6y ago
      The question is, what do you do when you reach a plateau? Do you invest more time and money? Maybe the skill level suits you well and you don't feel a need to progress further? Maybe deeper understanding is not necessary to do your job well? Maybe it's better to acquire different skills which you can combine instead of being an expert in one area alone? Is an appropriate response to not getting out of touch.
• ferros 6y ago
  When interviewing new candidates it's interesting to see the difference between beginner/mid and seniors. The beginner/mid group seem to have a lot more confidence in their skills and not be as aware of what they don't know. The seniors seem to be more aware of what they don't know and maybe also a little harder on themselves.
  • deleted 6y ago
    [deleted]
  • _hao 6y ago
    That's what I've always done in interviews. I'm confident about the things I know well, but I'm extremely open about the things I don't know and would like to improve.
  • BossingAround 6y ago
    I think this is a common viewpoint, and a misconception. I've seen a number of juniors who were very humble, and this humility was perceived as lack of knowledge. I've interviewed some seniors who were not humble at all (nothing was an issue). In general, skill level has little to do with humility and other personal traits. However, we like to project our reasoning into other's emotions, and we love to pattern match, e.g. "she's humble because she has 20 years of experience". It's another bias you should look for when interviewing candidates. This one definitely does not serve you well.
    • codegladiator 6y ago
      > I think this is a common viewpoint, and a misconception. Probably a common viewpoint, but definitely not a misconception. I have had freshers tell me wrong answers which they know they are answering wrong with so much confidence. And you keep digging them on their answer and they would keep coming up with even more wrong stuff. It would probably be about 2 or 3 out of 10 freshers who can say "i don't know that".
      • maccard 6y ago
• kiba 6y ago
  On skill development: I mainly think of it as an exercise in emotional management, just like procrastination, or physical activities, and so forth. It doesn't seem to ever become easy for me. I am always running into challenges and difficult obstacles once I overcome the procrastination issue. I am bullhorned about it, so I'll eventually get through. That, more than any particular strategy for learning, is the most important in skill acquisition. Another component of skill acquisition is skill retention. You'll get rusty when you don't practice your skills, and in enough time, you'll lose your progress. This is probably more than anything else, a lifetime commitment so that you don't lose your progress in the knowledge or skills you picked up, so that in the long run you become better and better over time. Think of it this way: You learned 10,000 useful "stable" facts about the world one year. Next year, you learned another 10K facts. But retention is exponential. Practice it long enough, the facts will last a lifetime. Suppose a person have no strategy for retention. Let say he learned 10K facts, 75% decays away. Next year, he learned another 10K facts, but another 75% decays away. So he retained only 5,000 facts, but you retained 20,000 facts. Obviously, this is contrived, but it does illustrate why colleges and high schools aren't very effective. It's not that they don't teach, it's that the students forgot what they learned as soon as they finished a course. I often get interested in a subject matter and then drop it some point. This often result in surface understanding of the subject. Just enough to sound smart. However the knowledge is retained. Should I ever return to a subject, I'll retain the knowledge from scratch, as sometime I do. Sometime I was able to keep at a subject long enough to acquire some amount of true mastery.
  • nonbirithm 6y ago
    > the students forgot what they learned as soon as they finished a course A lot of times this is enough to dissuade me from learning about anything I have only a passing interest in. One time I blocked out an entire two months out of free time after school in an attempt to learn electronics, by assembling a commonly produced headphone amp. A month passed after classes ramped up and I forgot almost all of it, and moreover no longer cared. I still just don't care about electronics since then, honestly, and don't know why. So in my book that was just two months I spent doing nothing that would ultimately contribute to my future knowledge. I mean, it was an attempt, but only an attempt. I never got the circuit to work in the end either. If I had known that was the result ahead of time I would have just worked on a programming project instead because I was better at programming and I wanted to finish it, and also was competent enough to actually finish it. Unsurprisingly the majority of my college education turned out exactly like this also, but at least I got the paper in the end. Nowadays it feels like all I care about are the things I care too much about to ever forget, like the skills necessary for my job. As in, not knowing what the point of learning all this is if I don't care enough to remember it after a month. I feel this is a horribly limiting mindset for me to have, but I don't see any way around the "not caring" part. If I know I don't care, nothing I do to sweeten the deal like gamification or dreaming of the finished project will ever work, because I know I'm only doing that because I don't care, so my mind will defeat itself. I especially don't like it because all these people around me are learning about machine learning and all these bleeding edge technologies that are having a material impact on the world, and I just sit there unable to care, as if I'm somehow allergic to learning. It becomes a "so you're just going to deny the existence of the entire field of X because you don't care and sit around playing video games instead" kind of irrational thing. I don't know how to resolve this, or if I even should. One thing I will never forget is me talking to someone I knew for a long time and asking what they were doing, and they said "learning about nuclear fusion." For some reason I never felt brave enough to talk to them again since then.
• Peckingjay 6y ago
  Links to previous discussions: https://news.ycombinator.com/item?id=11327669 https://news.ycombinator.com/item?id=11327669 https://news.ycombinator.com/item?id=19467367 https://news.ycombinator.com/item?id=19467367
• geuis 6y ago
  Look Mr Blogger, take this in the kind hearted intent it’s meant by a 40yr old engineer who doesn’t have time for bullshit anymore. Get to the point, fast and quick. I’m sure you have many valid and interesting points of view about your job, experiences, and wants. I’m interested to hear about them. You could offer some unique experiences I can learn from or maybe there’s some tidbit I can offer you. But unless you learn how to get to the point first, I don’t care. Even now after 3 minutes of perusing your entry I’ve lost any sense of what it was about. To finish up, I’m not trying to be evocative, negative, or anything. I just want to encourage better ways of writing, thinking, and publishing. Always consider your readers first. They don’t have as much time to parse what you write as it takes you to write it.
  • rmoriz 6y ago
    If one can't describe their thesis in 3-4 sentences, they will not be able to do it in a paper/book.
    • marcosdumay 6y ago
      The author of that article clearly can describe his thesis in 3-4 sentences. He does so on the middle of the text. But he decided not to add a summary at the beginning of the article. This is a perfectly valid option and helps him making his point, even though it did reduce his audience.
  • scarface74 6y ago
    The blog post is famous in technical circles. I’ve seen it cited about as much as some of Joel Spolsky’s most famous posts.
  • blickentwapft 6y ago
    Intolerance for long form writing is relatively new and an outcome of the Internet shortening attention spans. I used to do some long form writing and I still remember feeling offended when I first got “too long didn’t read” comments.
    • 6y ago
• blickentwapft 6y ago
  If you are a developer, what is the last significant thing you learned, and when did you learn it?
  • kiba 6y ago
    I am slowly learning pyqt5, and slowly accumulating a repository of minimum viable programs that demonstrate a GUI element in question.
  • Insanity 6y ago
    Define significant :P I'm currently into learning how computer audio works. Learning to program things like mono -> stereo conversion, panning the audio, normalizing, generating binary sound files,.. Currently going through a book (The Audio Programming Book) for all of this, doing it in C and then trying to make my own version in Go. The reason I say "define significant" is because these are all new skills I am acquiring - but I'm doing so just for the fun of it. It's not something I had to learn for my job.
  • muzani 6y ago
    I actually have it planned to do 2 things a day, even on weekends. One technical thing (new language, IDE, shortcut, etc) and one larger project based thing. It doesn't have to be much. Even 2 minutes is fine. That 2 minutes tends to lead to 30 minutes.
  • gitgud 6y ago
    The other day I learnt that in Chrome's Dev Tools you can easily replay requests. 1. Network -> Select Request -> "copy as fetch". 2. Then paste the fetch() statement in the JS console, and look at the network tab for results... Pretty easy and handy for replaying random requests during development.
  • Starwatcher2001 6y ago
    I'm 60 next month, and have been programming for 40 years (everything from Basic, Cobol... to C#). I'm currently having a blast learning Java and Android programming.
  • 6y ago
• austincheney 6y ago
  > As such, Advanced Beginners can break one of two ways Perhaps a more clear way to think of that is in terms of comfort and bell curves. The left extreme of the bell curve is easy to both identify and understand for anybody beyond the left end. Those are the people at the low end who perform below accepted baselines. Less well understood are people at the right end of the bell curve, who drastically out perform other developers. In all objectivity the people at the right end of a bell curve have as much as in common with the median population swelling into the middle of the curve as the supposedly incompetent people on the left end. Think of this in terms of risk and popularity. When you are below the middle of the bell curve everything to the right of you is better performing. You can increase your performance by moving closer to the middle of the curve by doing what is popular. Once you get to the middle of the curve you have to make a firm decision: remain comfortable in your current posture and let popularity dictate your approach or take risks to further increase performance beyond the population median. In that regard the populations at both the extreme left and right ends of the bell curve are doing things that are extremely unpopular. You cannot become an expert without fully embracing that reality. An expert beginner is a person at the median of the bell curve or just to the left of it. They have mastered their skills to that point and refuse to make changes or take risks necessary to advance further. As a front-end developer I frequently encounter expert beginners. People who have mastered some framework/convention, but doesn't really understand how their technology really works and are hostile to improvements that don't make use of their favorite framework/convention. To outside observers the expert beginner is clearly identifiable as performance is objectively measured with numbers without regard for approach.
• OJFord 6y ago
  Judging from the '7 years ago' comment 'dates', and the article's '30 Sept' 'date' (!), this is (2012)?
• heisenbit 6y ago
  Any discussion of software competency that does not take into account the rapid aging of some skills is incomplete.
  • rmoriz 6y ago
    Also any discussion of software competency without market analysis is incomplete. We have seen a big change from indy culture towards monopolies and their rules in the last 10 years. Almost all developers are required to play by the rules or Google (Chrome, Go, k8s), Apple, AWS.
• knorker 6y ago
  I really hate it when articles exactly date their stories, but don't provide a year. "Sep 30", this one says. Hmm… can't be 2019, because I read this years ago, I'm sure. The only indicator of year I could find is that the comments to the article are 7 years old.
  • PikachuEXE 6y ago
    Yup it's like an address with detail up to room number but missing city / country We might be able to guess the missing city via street name search but impossible for dates
  • jasode 6y ago
    If you "view source", there's a JSON blob that has this: ,"datePublished":"2012-09-30T23:48:21+00:00","dateModified":"2019-06-06T01:20:40+00:00", Looking at raw html source isn't always a reliable indicator but the older date looks legit in this case. [Can someone explain the downvotes? I'd like to know if my information is incorrect.]
    • nicoburns 6y ago
      I've no idea why you're getting downvoted. This seems correct and useful to me.
    • khamba 6y ago
      > Can someone explain the downvotes? Someone may have taken your comment as a defense of the article not publishing year (which is a ridiculous defense) and hence the downvotes. It is definitely really bad UX if you have to "view source" to find information.
    • jansan 6y ago
      Nice hack, but this should not be the preferred way to find the year of an article, even for a nerd.
      • deleted 6y ago
        [deleted]
• barrkel 6y ago
  I don't really buy the analogy. Writing software is a bit like playing multiple sports. You can be good at one thing and poor at another, and as a result do great work on one project and be mediocre on another. Writing code in the small, optimizing; architecting for change; architecting for scale in development; architecting for scale under load; architecting for scaling out vs up; all different skills. Writing code functionally, vs procedurally, vs message oriented. Writing code with control flow vs data flow, and toggling between them. Crafting abstractions vs composing them. Many small parts put together elegantly vs one straightforward transparent monolith. Some skills are alternates, you can go either way and get as good results. There are people who only know a few things. But on a suitably scoped project, that may be fine.
  • superdeeda 6y ago
    100%
  • alecmg 6y ago
    nicely put and it doesn't contradict the article. If you have always worked in one paradigm and think you are an expert in it, learning new development skills can make you see you were not that good in your previous area.
    • barrkel 6y ago
      I don't really agree with your characterization. I consider the most reliable evaluation of expertise is working code. Something can be beautiful, but if it doesn't work, or doesn't solve the business problem, it doesn't count. If something objectively scales, I believe that the people responsible for building it are able to build that thing that scales. If those people learn new things, they might learn how to do the job better. But maybe better isn't what the business needed. Maybe it would be better to invest that extra talent in something else, and hire people with the original skill level (who may be cheaper) to do the original thing. This all might sound like an apologia for not learning new things, or limited developers who can only build a few things. In some ways, indirectly, I'm arguing against an unfounded arrogance or feeling of superiority which is driven by following the fashions of programming as a pop culture. But more of what I'm trying to get at is that the "best" isn't actually required, a lot of the time. And sometimes the best can be the enemy of the good; doing things the "right" way, according to an orthodoxy, can actually interfere with getting things done. And newcomers to orthodoxies can be - usually are - the most religious.
• marcus_holmes 6y ago
  This really hit me. Am I an Expert Beginner suffering from Dunning-Kruger and delusions of competence? Or am I an actual Expert suffering from Imposter Syndrome? I'm working as tech co-founder in a small team with junior devs, and I do some things "differently" for what seem to me to be good reasons. How do I tell?
  • titzer 6y ago
    If you have less than 5 years experience doing anything, it's safe to conclude you are not an expert. If you can't identify a single person who is better than you at something important you need to do, then you are a probably a terrible judge of competency and therefore not an expert. If you haven't failed, you're not an expert.
    • marcus_holmes 6y ago
      I have over 25 years of experience. Is it 25 years of experience, or the same year 25 times? How do I tell?
      • solraph 6y ago
        From my personal experience, are you still writing things the same way you were six months, a a year, two years ago? I look at code I wrote a couple of years ago, and not only can I identify how I would write it differently, I can identify /why/ I would write it differently - both what technique, concept, or methodology I have since learned, and how that would make the code better. If you cannot, you have probably plateaued, like I did for a (far too long) while.
        • marcus_holmes 6y ago
          I noticed yesterday that I've implemented the same type of CRUD API call in 3 different ways in code I've written in the last 2 years. And I can see why I did that and what I was trying to optimise for in each case. I'm sure I would write it differently now, but would I write it better? I have no idea what "better" is any more. Faster? Easier to read/maintain? More loosely coupled? All of these? I spent two weeks building a Go version of Webpack last month because it was either that or implement Webpack because the Vue components we're writing needed unit tests. Was that wise? It works fine, I don't have the gajillion shitty dependencies of Webpack, and it compiles, bundles, uglifies and minifies our entire Vue front end in <200ms but is that a good thing? Was I an idiot reinventing the wheel, or was I wise avoiding exposing us to the insanity of npm? When it needs maintenance in a few months and I have to spend a few days fixing it, is that time wasted, or have I saved time because every time Webpack updates a version everything breaks and we don't have that hassle? How do I tell?
• greatgib 6y ago
  As said in one comment, PART2 (link at the bottom of the page), is where this begin to be added value compared to the existing theory. That being said, very great article that describe well and nicely what I have personally experienced in a sme company that was bought by a big tech group at some point: - when I arrived, the core team was already there with some having personal ties. A few beginners that took the mediocre manager as mentor, that took himself his manager as mentor - they learnt by themselves, mostly there, they were responding to diverging opinion with anger. - over the years, a few 'outsiders' arrived and try to change things by showing the problems and explaining that outside world do differently. - but each of them had to face the seniority argument reinforced by the group effect to justify that they can't be wrong. (Listen, we are 3, you are 1, it means that we are right and you are a pain in the ass to think otherwise. Doesn't count that you say that out of the company are unanimous on the subject...) The worst (almost funny) case I remember was that: - Person 1 (p1) and person 2 (p2) have a disagreement on how something has to be implemented. - p1 is the boss favorite, so he is always right... so his solution will be implemented. No one listen to p2 that says that it is an inefficient idea, possibly problematic and that is why no-one does it this way outside. (No-one? In fact they found one case over 100 of outside projects that did that, so that gave them confirmation that they were right...) - p1 engine solution is implemented and p2 has to do a component working with that, but that does not work well at all, very slow for basic operations, lots of unexpected deadlocks and issues like that. Another manager complains about the issues. - P2 decides to give a try reimplementing the engine with his solution. That is completed is no time and it is excellent: performance x1000, no lockup, no more issues with basic operations. - results are shown to mediocre manager. But instead of accepting and going this way, he blocks the thing and can't accept that his favorite was wrong. So says that there should be a bug in P1 implementation and give him as much time as needed to test and look at it. - after 1 months, P1 did everything he could with his solution to fix it without using the solution of P2. He comes proudly with his engine is now 10x faster than initially. - but so, 10x vs 1000x is a no match, and P1 solution was still rigged with issues. So it is finally P2 solution that is used 'out of choices'. BUT... as manager still does not accept that he and P1 were not right. He said: ok we use P2 solution, but you will have to embed and support P1 implementation in the final product. Not to be used but maybe one day... - conclusion of the story? Evaluation time arrived. Did P2 got a good eval? That would be logic, he saved the product, gave an important perf and stability boost to the solution. But no, he got the worst! Manager said that P1 had to take depression pills because of P2... Not because his solution was wrong and couldn't accept, learn and improve from it. Buuuut: P1 got the maximum grade!
• lmilcin 6y ago
  I personally think there are multiple reasons for this situation. * It is fun to learn initially, to see something new working. Once you get something working not many people see fun in spending a lot of time in getting it to work better. * There is huge amount of introductory materials (guides, tutorials, examples) but the amount of available materials falls drastically as you start to progress. * Only some people are able to actually think in abstract terms required to "create" new knowledge based on existing facts. Beginners can advance quickly by "recreating" -- executing tutorials, copying existing code, etc. It is relatively easy to use these as building blocks for a simple application. But as you progress you have to figure out more and more new knowledge, understand underlying principles. This is what many people either don't feel comfortable doing or don't feel is necessary to do or are just plainly incapable. * It gets more difficult to work with other people in your team as you create knowledge in a given topic. There is tendency to push back when team member tries to introduce something new that is not clearly recreation of accomplishment of somebody else available on the Internet. * Creating new knowledge in the topic is a huge risk in that it is unknown payoff for large amount of honest work. There is not much risk in following existing tutorials, it is pretty much guaranteed that it is possible to recreate accomplishment others did. When you create new knowledge (for example new patterns, principles, guidelines) it is likely you are going to make mistakes. This fact may cause people uneasy and dissuade them from further advancement in the topic. * Getting mediocre in any specific topic is frequently seen as good return on investment. For example, as an architect I would maybe not want to get expert at any of the frameworks I know. I see this as a reasonable tradeoff which allows me to tackle other problems as soon as I think I know "enough" about particular topic.
  • blaser-waffle 6y ago
    > * There is huge amount of introductory materials (guides, tutorials, examples) but the amount of available materials falls drastically as you start to progress. Aye. My coworker described it as being able to find 100 guides on how to hammer nails and build a small bench. "Shed building for beginners" or something. But then the next exercise is "build a house" and the one after that is "build a shopping mall".
    • 6y ago
• irrational 6y ago
  My problem is that I’m expected to learn so many things that I never have time to become an expert in any of them. Html, css, sass, JS, Vue, Vue router, vuex, react, other react libraries, lodash, jest, webpack, Python, node.js, Java, sql, Oracle, Postgres, bash, regex, docker, kubernetes, aws, azure, etc. ad infinitium.
  • SahAssar 6y ago
    Looking at that list I’d say learn html, css, js, js browser apis like DOM, one backend language, sql, and Linux sysadmin. IMO if you understand those you get a lot of the rest by looking at where they fit and you can build a solution without having to use a lot of product-specific APIs.
    • irrational 6y ago
      Oh, I already “know” all of these things (I’ve been doing web development since the mid 90s). But it seems like as soon as I start to get a decent grasp on a technology, a new version comes along, or it is replaced by something new, or my boss/company directs me to use this other technology, or the industry as a whole moves. SVN > GIT, jQuery > Angular > Vue/React, JS > ES2015, managing our own servers > the cloud, etc. Jack of all trades, master of none.
  • balfirevic 6y ago
    > My problem is that I’m expected Expected by whom?
    • irrational 6y ago
      My boss/company.
  • rimliu 6y ago
    It's like saying you are expected to ride a bicycle, electric bike, a scooter, a car, a truck, a minivan… Not exactly, of course, but there is a huge overlap, especially in concepts.
• tarsinge 6y ago
  What is a good developer? Isn't there more than one axis? For my case over the years I have honed my skills at problem solving, seeing the big picture, and finding the most efficient technical solution from a business perspective (not GAFAM scale obviously, but that's the exception). As a result, I can save companies a lot of time and money because I will help reshape the problem and rework the scope to find the max added value / work ratio, to deliver in days a working solution, instead of a big year long project with all the overhead. My productivity is high because I know where to cut the crap. More than once I have seen a peer or a whole engineering department of brilliant people going down a technical rabbit hole for weeks for intellectual satisfaction, where instead I will just take a step back, walk to the manager and try to work a different take for a solution that can be implemented in a few hours/days even if the business goal is slightly moved. Yet I'm definitely not a good professional software developer in terms of code "quality", and don't consider myself very smart compared to my peers. Edit: formating
  • fimdomeio 6y ago
    That were exactly my thougts when I started reading the article. If you have a great developer that will leave on the first sign of trouble, maybe you're better off with an average developer that will understand the business needs and will "averagely" do it's part in solving whatever problems exist.
    • lawik 6y ago
      Most businesses don't need "great" developers. They just need to get the work done. Getting someone who is really skilled can of course be beneficial but it certainly has the problems of retention, things like providing interesting challenges, high compensation. Not all businesses have deeply interesting technical problems. That's fine. There is plenty of use for the wide parts of the bell curve fpr both businesses and developers.
      • SamuelAdams 6y ago
        Yep. I once worked at a manufacturing company. Their clients sent order information via an FTP server. The orders were formatted as flat files, aka just simple text files. I had to create code that painsakingly looked through each format and imported it into the new ERP system. Every vendor was different in each flat file. I'm sure some had similarities, but abstracting the logic was more dangerous in this case. A lot of business software is boring. It does not take skill to do. It only requires someone to know a handful of tools and be willing to put in the time. So my advice to non-FAANG developers: if you want to make development your career, learn to be bored. Still work on marketable skills, learn new languages, etc. But remember that not every task will be an interesting new technical issue, it's probably going to be something you've seen a hundred times before.
• microcolonel 6y ago
  I think that there's often something simpler going on here. Some people are simple and small-minded, they simply do not enjoy learning new technical knowledge and skills, and would rather run what they have to failure even if it means losing out on a lot of income. A fine example of this is a new hire getting anxious and defensive because the git branching strategy at the company isn't the branded one they're accustomed to (e.g. git flow).
• ChrisRR 6y ago
  I work with an expert beginner and I don't know how he's survived. He's got about 30 years of experience, but writes code like he's got 1 year of experience. His code has absolutely no sense of quality, doesn't employ any sort of standard design patterns or style, has no semblance of architecture and is an absolute hacky rats nest of code that falls apart with any change because of how interdependent it is. The other day I was sent some of his updated code, which had no version control and had randomly added an extra 150 files to the project. It turns out the majority of those files where duplicated from elsewhere in the project and apparently it was my job to find where the changes were among that mess. It's like he learnt to program decades ago and then never opened a book or looked at anyone else's code since.
  • BossingAround 6y ago
    "If it ain't broke"... :))
  • ohazi 6y ago
    In flying, logged hours are often used as an indicator of experience. A quip I've heard from at least two instructors: "You can fly 400 hours, or you can fly the same hour 400 times." Sounds like your coworker has had the same first year of experience 30 times...
  • twic 6y ago
    And he's still got a job. So who's the real genius here? I don't want to be that guy, and i don't want to work with that guy, but i have to confess to a certain jealousy that people like him have figured out how to sit back and just phone it in and collect pay cheques for thirty years.
    • cyberdrunk 6y ago
      If he has any degree of self-awareness then perhaps those 30 years were riddled with anxiety over losing the job and not being able to find another one.
      • 6y ago
• classics2 6y ago
  Hiring is not a meritocracy and programming is not bowling.
• gitgud 6y ago
  Similar to the rise of the StackOverflow programmer. You can get pretty far just by Googling error-codes and brute-forcing a problem in a domain without any experience (I should know). Maybe not the best way to learn, but in such a technologically complex world, it can sometimes be more effective...
  • kypro 6y ago
    Even when I know how to potentially solve a problem I often search it on StackOverflow anyway because I know often I'll find a much better solution from developers who are either more talented than myself or have simply spent longer thinking about all the edge cases.
  • overgard 6y ago
    This is how you end up with a mess.
• cjfd 6y ago
  Identifying the good developer with the frequent job hopper and the expert beginner with the developer who stays at the same place seems rather unfounded. I have also seen the job hopper who left just before it became clear that his architecture was actually not all that great. Also, wanting to use the standard stuff vs. rolling out your own is more a thing of incentives. If you are a frequent job hopper it is nice to learn something standard. If you stay at the same place you will have to suffer from the standard boilerplate that the not-so-great framework requires and that has to be typed over-and-over. It is more a matter of incentives than that one thing is necessarily better than the other, I think. One great advantage of the programmer who stays is that his decisions are backed by skin-in-the-game. S/he has to suffer through the consequences of his choices.
• netcan 6y ago
  I like these sorts of analysis, whether I agree or not. I've come to believe though, that they need humour. There's always a tendency to over-extrapolate, get hung up on typologies which crack under weight and to assume the model is the main thing going on. Humour gives them a productive "playing with ideas" vibe, keeps it honest. In software development, for example, I always think that demographics play a big role. Every decade we get more young programmers than the last. Many older programmers "graduate out" one way or another. The resulting demographics are unusual, with a years of experience pyramid more like the military than most professions. Technology, methods and philosophy change rapidly. This is both exasperated by and causal to the demographics, and the youth/pace of the field itself. A lot of software culture has this relationship with the demographics. Maybe 60yo developers are more likely to produce important new things, but they are outnumbered 100-1 by 20-somethings... enforcing youth biases, etc. I think a lot of this essays thoughts on learning might be affected by software demographics. A lawyer, accountant or aviation engineer's thoughts on learning and career progression probably encompasses much longer time periods. In software, we think in much shorter timescales. Between the age of 22 & 27, a programmer has progressed through a "career." Between the age of 22 & 27, an accountant has progressed through a cadetship.
  • partyboat1586 6y ago
    The difference is no accountant does accountancy in their bedroom for fun as a teenager. The software engineer who has significantly progressed their career by 27 probably started as a teenager, not as a 22 year old. It's more like being a musician than being a lawyer or an accountant.
    • netcan 6y ago
      There are plenty of cases where programmers only start programming for real at a post-college job. The majority case, even. That said, sure. There are differences in substance, history, everything. Those might be the reason for differences between professions, but the question is "how much?" I think we overemphasize legible, logical reasons for culture, but often it's incidental reasons path dependence, demographics, etc.
• ChrisMarshallNY 6y ago
  I’m not sure the “10,000 hours/5 years” rule is a particularly relevant one, these days. Tech mutates so quickly, it's near impossible to become an "expert." Also, many developers are...how can I put this...a wee bit obsessive. It’s quite possible to hit 10K hours well before 5 years. I liked the analogy about the quirky bowling style. That has happened to me -several times. I’m primarily self-taught in most of my tech. It has tended to result in very highly-developed, but narrow, skillsets. Not necessarily a bad thing, but “brittle.” It has happened so many times, that I no longer feel that I am an “expert.” I am now “experienced.” At least the first five letters match. But it has been a long road to where I am now. Humility has been forced upon me, and I now have a lot of “narrow skillsets,” to the point that they inform each other. For example, a lot of the stuff I did in PHP has helped inform my work in Swift, and vice-versa. I’m choosing to specialize in a specific discipline and tech stack, which, just by itself, gives me a lot to learn. I am working to develop a “broad base” in a small-ish venue, with a lot of “sharp peaks.” It’s really humbling. The more I know, the more I know I don’t know. Also, since I am constantly trying out stuff I don’t already know, I’m a perennial “n00b.” Usually, this manifests by not always being aware of the jargon (I know the tech, but not the name). This may result, I suspect, in my being treated rather shabbily by folks in the field (It may also have to do with my age. I have found that the way people treat me changes radically, as soon as they find out that I'm "long in the tooth," so I now make it obvious to avoid that). This has helped me to just keep my damn mouth shut, and open it only to eat my humble pie. I write about that here: https://medium.com/chrismarshallny/thats-not-what-ships-are-built-for-595f4ae2c284 https://medium.com/chrismarshallny/thats-not-what-ships-are-...
  • rimliu 6y ago
    There is a point in your development where you realize that tech _does not_ mutate as quickly as it may seem.
    • ChrisMarshallNY 6y ago
      Good point. An awful lot of "Büzzwürd du jour" is repackaged old stuff. It does not make me friends, to point that out. That said, sometimes, the "new way" does help add something to the "classic" way.
• john4534243 6y ago
  The author does not have public contributions to verify his coding skills(no github), think before you invest your time to read the long article.
  • paulchap 6y ago
    He does have a GitHub account[0]. He successfully founded his own company. Entries from his blog also made the frontpage on HN several times[1]. You, on the other hand, do not have a GitHub account tied to your HN account, or any other records of your achievements, for that matter. You also don't seem to have made any meaningful contributions. But people still took the time to read this comment. The author's history of contributing to OSS projects shouldn't be relevant here. You shouldn't use it to attack his claims. If someone wants to read the article, they can read/evaluate it based on their personal opinions/knowledge. [0] https://github.com/erikdietrich https://github.com/erikdietrich [1] https://news.ycombinator.com/from?site=daedtech.com https://news.ycombinator.com/from?site=daedtech.com P.S.: No, I'm not the user registered with GitHub as PaulChap.
• gerland 6y ago
  I don't really buy the "expert beginner" thing. How does it relate to having the "T-shaped" skills? One is the frowned upon and the other is desired for some reason. The reality of programming is that most often than not you do not need to be an expert to do a job well. I would even say that being an expert programmer is all about sticking to only basic things. The more you try to be smart and "on the edge" the more you or someone who inherits your code will fail. If I would get 1$ for every trendy abstraction or framework, then I would not retire, but probably could buy a new PC or something. IMHO it all boils down to ego trips. Everyone thinks he is the superstar, ninja or 10x and everyone else just a poser. "I'm the smartest one" should be the motto of IT. If you think that you are the one that can push the whole community forward then you are probably delusional. I think I'm a moderately advanced developer, but some of the people that I met along the way were just crazy smart, highly productive and - here is the surprise - nowhere near the top. This delusion of grandeur is especially common in people that are pampered in the business. If I would name them, then I would be instantly downvoted, but just stop and try to imagine what people I mean. I'm guessing you won't have any problem. In the end, your project does not need you to be an expert, your team does not need it, the business does not as well. Only your ego. Long live the "expert beginner"!
  • zomglings 6y ago
    I have no idea what people you mean. Best guess - developers at Google, Amazon, Facebook, etc. Second best guess - people working on machine learning.
  • partyboat1586 6y ago
    The problem is people in industry like to massage developers egos because they need them for their own ends. You need to learn to judge yourself objectively rather than what people say to you. Measurable stuff like how many times does your feature come back from QA? How many times did you come up with a creative solution during a project that lead to a net positive effect? How long did it take you to be productive in X framework vs your peers? On the micro scale compete on the codewars website and look at other solutions to the problem. Often you will see creative things that hadn't even crossed your mind. This contact with reality is harsh and you can always make up excuses but it's necessary because people around you don't tell the truth. Then after this it's important to realise that your technical skill isn't your only asset and working on interpersonal skills is just as valuable if not more valuable above a certain threshold of technical skill.
• deltron3030 6y ago
  Developer = programmer, or are devs expected to have more general and higher level big picture knowledge? Is every carpenter without interest in furniture design an expert beginner, or just a carpenter? Aren't developers who aren't into design/business just programmers? Why is this bad?
• twicetwice 6y ago
  This is a really neat article. I feel like just this week I reverted from Expert Beginner to Advanced Beginner—or maybe glimmers of Competent—as working on my current project has revealed to me just how much I don't know about what I thought I knew well.
• cosmodisk 6y ago
  I think the main problem is that most businesses are more than OK with mediocre developers. There's only a small number of companies on this planet where boundaries beimg pushed to extremes and it requires the top devs to keep going further and further. It's like football: there are lots of kids playing football,but we only need a few hundred,maybe a thousand that are at the very top of it. And to get and to keep yourself at the top does require very different mental capabilities than to get from a mediocre one to a good developer.
  • randcraw 6y ago
    I agree, except instead of 'mediocre' I'd use 'competent'. As long as technical wizardry doesn't add significant value, or it isn't essential to the business, most companies would rather not pay for it. They believe they don't need experts. And most computing folks at most companies know that rising technically is not the way to advance your career. If it were, more companies would be crying out to hire experienced 'expert' 50 year olds. But they're not. From what I've seen, expertise is overrated. And competence is underrated. Adding real value to an enterprise comes from achieving multiple avenues of competence (technical, business, social, etc), and then anticipating the needs of the enterprise before experts have to be drafted to rescue a misdirected effort (or a disaster that never should have happened if sufficient competence had been employed). A lack of emphasis on expertise is probably a good thing. Answering clever interview questions well, like taking tests well, is at best a surrogate measure for street smarts -- the skills that really matter outside academe.
    • 1tCKV3QfIo 6y ago
      You conflate misunderstanding project requirements with competence. So you think the most efficient solution _and_ implementation will come from someone technically mediocre? Go ahead and implement your high-level business solution - see how many resources you waste implementing it because you are unaware of a better way.
    • partyboat1586 6y ago
      Very true. I knew a C++ developer who knew the language inside and out, incredible skill, 100% on a written test where most people get hired with a score of 60%+. He offered very little to the company other than optimising the build to run faster. He just wasn't motivated to solve the problems the company needed solving or engage in the product. Unsurprisingly he wanted to play with C++ all day long. I also knew a developer who came from a coding bootcamp, adequate CS fundamentals and basic knowledge of JavaScript and Java. He was the most productive developer I've ever worked with. Laser like focus and great social skills. He occasionally needed guidance from more technical developers but he knew when to ask for help and he got the job done.
• HugoDias 6y ago
  Not sure if its just me but its very hard to read this website font. Had to bookmark and read it on Pocket.
• r34 6y ago
  Maybe developers stop learning because they realize that that to learn how to do the same thing with 167 technologies is not a real development. Maybe they realize (they should) that self-development should be we well balanced, so after programming workday they should invest their time into sports and work with their emotions and take care of interpersonal aspect of their lives. The older I am the more I'm convinced that development is not individual thing - it's a team sport. Hey, company: divide your workday into 4h work for external projects and 4h work for team development. Smart, mature developer, will realize that the most inhibiting phenomenon for him is usually the job itself.
  • dustingetz 6y ago
    167 tech that does the same thing is a failure of abstraction Idea: what we're actually measuring is the speed of human reasoning vs the business value of time-to-market.
    • r34 6y ago
      Personally I measure happiness and fullness of life :)
      • dustingetz 6y ago
        So that's kind of the root of the problem – "sufficiently strong optimization of a specific target destroys all external value"
  • deleted 6y ago
    [deleted]
  • christiansakai 6y ago
    This. Agree with all that you said. I wonder if this will keep me stagnant in my programming chops. But at the same time I realize that expanding the chops is diminishing returns for my life from all angles, including satisfaction and finance. I have hobbies, families, communities that I serve and are expanding other non programming skills. That being said, at the same time I also kinda don't know what is fun anymore about programming. I think for me, creating real stuffs that real people can use is always fun, but at the same time I don't have ideas. Many (useless) ideas are already reiterated over and over again by people posted on Github/Reddit. I tried to go deeper into a specific implementation, like for example database engine or compiler. But I realized that wasn't as fun as I thought it to be. In terms of programming, I always liked learning programming languages, but it gets old real fast. Once that is over, I don't know what else should I do. I'm thinking of learning OCaml next. Or maybe I should try other field of programming like game development. Or maybe I should just be content not doing any programming related hobbies anymore and just stick with my other hobbies.
• deleted 6y ago
  [deleted]
• aneutron 6y ago
  Or maybe they stop learning because at some point, you realize your employer doesn't give two shits about doing incremental changes to your infrastructure / code, let alone breaking changes, but instead pursues paying outside contractors to do broken shit you'll add the pile of things to fix. Or maybe that's just me. Also, I'm not going to work on mathematical proofs for something good, just to see my work disregarded because it's "too complicated".
• netcan 6y ago
  I think there is long term culture clash between old and new ways of learning, in the "over a career" sense. The old way is the formal, with external motivations and structures. Maybe there's a curriculum, like accountancy has. Maybe there's a coach, like in sports. One can spend a long time in the "infant stage," learning by mimicry. A young karateka spends years practicing motions in the air, with form carefully observed and corrected by a teacher. This lets learners access the knowledge of karate as a whole, without needing an intuitive understanding of why this elbow must point that way while performing kick two in exercise X. To jive with the author's bowling analogy... Imagine a child bowling with just a ball. No pins. No aley. A teacher corrects form: posture, the swing of the arm, the final position. Once the child starts bowling for real, all their habits will be good. The known deficiencies of poor form are avoided, and the risk of hitting an "expert beginner" dead end is low. This kind of formality is only possible when the domain is well known, and "correct form" is well understood. I suspect that these systems require generations to build. They also run the risk of devolving into ritual, superstition even. The informal, more autodidactic culture does risk an "expert beginner trap," a premature peaks in skill that requires formal (or intentional) training to defeat. OTOH, "expert beginner" is not just a trap. It's a useful goal, for a lot of situations. If you are going to fight the bully next week, karate is not a good answer. Those highly refined skills have little intrinsic short term roi.
• brianolson 6y ago
  Some people have 10 years experience. Some people have the same year of experience 10 times.
• jart 6y ago
  Sounds like fake it until you make it. People, especially self-taught ones, aren't going to pursue something if they believe they're bad at it. Be nice.
• dadoge 6y ago
  Most “Super Senior Principal” engineers I see at larger companies are ones that have been there for 5+ yrs, so I disagree that the best engineers always run to greener pastures.
  • valuearb 6y ago
    The point is the most talented ones left and you are seeing the dregs that got rush promoted to replace them. And he was talking about companies going through hard times, good companies should be able to keep their best employees.
• zoomablemind 6y ago
  I find the article while thoughtful and provoking, paints a myopic view of self-advancement. The analogy with sports is what throws it off. Sports can be individual and could be team-based. There's an importance to individual skill, no doubt, but the team apect is what lets one not only assess own standing, but have a chance at advancing it without the adversarial pressure. If you choose to retool, the team would pick up the slack meanwhile until you're back (hopefully stronger). The skill degrees indeed are relative, and in the field of programming are dynamic. Of any one skill to put in permanence is perhaps an open-mindedness. It is a readiness to learn, not much an ability to master. Lots of excellent programmers don't stop learning, they just discover the wisdom of 'good enough for the time-being'. Expertship is lonely, beginnership is open an dynamic. The author projected the whole skill advancement spectrum onto the single grade of Beginner, as if beyond Expert lied a void or infinity. I believe, paradoxically, beyond Expert is ... a Beginner. Either by humbleness, or by need to discover a new field, or by age, or boredom, or wisdom. Programming has to be a team activity. If you happen to handle a project part by yourself, your future self or someone to work on your code after you is your current team. If you're on the team already, then you keep learning from your mates as long as you let your mind stay open to it.
• softwaredoug 6y ago
  It feels like self-admitted beginnerism is actually the mark of a great developer (not assumed expert). Regardless of whether the “expert” is genuinely earned or not. Indeed this is the idea behind the beginners mindset[1], where we assume our knowledge and experience may be faulty. That we have to unlearn our skills to make a further leap. That when you assume you’re an expert, you’ve already lost. So I tend to question the Dreyfus model in general. I want to see how capable people are at getting skills, but also how readily they can discard hard won skills. Similar to a sunk cost trap, we can needlessly hold onto our skills and hesitant to think we need to let them go and rethink the whole approach. [1] - https://en.m.wikipedia.org/wiki/Shoshin https://en.m.wikipedia.org/wiki/Shoshin
  • redisman 6y ago
    Self-admitted yes but I think the OP article is talking about ignorance about your own beginnerism. Definitely as someone who invested heavily into "getting" OOP early in my career, I can now see that I have a lot to unlearn and mold my understanding of software in a less dogmatic way.
• Garlef 6y ago
  I think blaming this all on learners not realizing their missing potential is a bit one sided. Other influences: * Skill level of coworkers * No time is dedicated by the team to abstractions / refactoring due to deadlines, or personal preference etc. * The technology being used is limiting or used in a limiting way. If you never push your boundaries you'll never get better. Going to 100% one time will have a lasting effect. If you instead only go to 80% all the time you'll only get better at doing a mediocre job. However, the goals might be misaligned here: Your employer and coworkers might not be interested in your personal growth. Instead they want you to "Get stuff done."
• deleted 6y ago
  [deleted]
• ragona 6y ago
  I didn’t really find anything I felt like specializing in for the first decade-ish of my career. I was working on games, I don’t think 3D math is that cool, and I wasn’t excited. I was tired of coding games over and over. I don’t think I was an expert beginner but I wasn’t an expert in anything I wanted to continue doing. I took a break to be a manager for a while, which turned out to both be an incredible learning experience AND enough pressure relieved from the daily code grind that I was able to rekindle my passion for code. Started writing a lot outside of work, realized I really like cryptography, studied that, became competent enough to even figure out what TYPE of beginner I want to be, etc. it’s very satisfying. I’m around four years into that journey now, I’ve returned to a coding path where I get to actually learn while building, and I’m excited. The expert beginner is a surprisingly easy trap to fall into. I also think we do this TO people when we trap them in a role and give them very little flexibility in execution. They will begin to specialize in doing a bad thing well without understanding what they’re doing, especially if they aren’t given mentorship.
  • redisman 6y ago
    It's easy to fall into since it's usually what's expected day-to-day. Not that many people have a chance to dive really deep into a topic at most companies. Usually you're churning out fairly similar stuff for most of your tickets. It's also dangerous for your career if you pick your specialization wrong. Maybe 5 or 10 years later that technology is obsolete. Earlier in my career I was something of a (Adobe) Flash expert but there's no way I would even mention that these days. Much of it translates to other technologies but not in a way that makes me an expert in them.
    • ragona 6y ago
      YO, same, I bet we hung out on Kirupa at the same time haha. I worked on flash games at Disney, PopCap, Sony and Amazon. That was the shit for a while for 2D games. But I actually went from social to mobile to PC games and found myself less and less interested. Don’t get me wrong it’s very cool code and quaternions solve a lot of the pain so some of the math is frankly less fiddly than 2D, but I wasn’t in love. It’s been nice to fully pivot towards cryptography and security since I get to work on a lot more projects and do a better job on them. No one cares about bugs in games. Everyone cares about bugs in crypto. It’s nicer for the engineers. Plus it’s frankly so deep that I have very little risk of mistaking myself for an expert. Even PhD’s only have a narrow specialty, it’s very comforting how hard it is.
• one2know 6y ago
  Bleh. All I see here are all the same old ageism tropes and noob programmers trying to rationalize their age bias.
• mgrennan 6y ago
  After 40+ years as in electronic, software developer, OS and App, Networking, SysAdmin, DBA and DevOps I see it all as a multi discipline. Knowledge in Electronics, CPU design, Compiler development, OS design, communications, Business management and user interfaces all relate and a "Rock Star" would need to be an expert in them all. Most Dev's stop with App dev and business design. Some go on to UI or compiler performance. System a little and communications and electronics almost never.
  • PaulStatezny 6y ago
    Sounds like you have a pretty impressive set of competencies. Well done! > and a "Rock Star" would need to be an expert in them all. Need... in order to do what? Run a business? Be qualified to make every decision for... a chip manufacturer that also does OS development and application development? (Apple?) I agree that it's worthwhile to become proficient in many areas, but your comment seems too specific and absolute to be useful. It discounts the value that people (who aren't your definition of "Rock Star") can bring.
• monksy 6y ago
  1. It's a lack of discipline (If it's anything from the testing post we saw yesterday) 2. Aggressive pushes to deliver over creating something solid or experimenting with different archs 3. The selection process doesn't look for experience.. they have been looking for leetcoders that haven't changed since college
• SMAAART 6y ago
  Expert Beginner? That's not just a Developers' phenomenon, it's actually more prevalent in business where "I have X years of experience...." what if they have been doing it wrong for x-years?
• honkycat 6y ago
  This article addresses a very particular person who definitely does exist. Expert beginners are absolutely a thing and things have only gotten worse with the "HIRE EVERYBODY! NO TRAINING REQUIRED" approach to hiring a lot of shops moved to. I had not experienced it until the past year. If this article does not resonate, if you have not worked with one, count yourself lucky. I am regularly astounded by the lack of extremely basic skills I have seen in the places I have worked recently. For the love of god, just read a single book or take a single class on software development. People argue: "Well, most shops don't really need good developers." I call BS on this. Every place I have worked at are trying to make money and keep the team from getting canned, and a bad developer will take you two steps back for every one step forward. There was a person at my last job, nobody knew why they kept him around. He had a good 10 years on most of the team, but his code was easily the lowest quality, and he constantly fought with the rest of the team around attempts to improve code quality. We hated him. He was totally stale and had given up on self improvement. We wanted him GONE. What happened? Most of the team quit and he is still there.
• kuharich 6y ago
  Prior comments: https://news.ycombinator.com/item?id=11327669 https://news.ycombinator.com/item?id=11327669
• adverbly 6y ago
  Good article but I disagree. "Bowling is like Software" does a good job at pointing out a common problem(You can develop and get stuck using a style which has a lower ceiling than other styles). I still think "Bowling is like Software" is a bad analogy though. Bowling is a one-dimensional task: Its the same problem every time, so some styles will likely have much higher ceilings than others. Software is far more complex: some styles work well for some problems but poorly for others. If there is actually a generic fix-all style, its likely very abstract, difficult to grock, and probably involves a lot more math than we'd like to admit. So I don't think theres anything wrong with getting good at one style, even if it has a low ceiling because even if you learn another style later, you will probably want to go back in your toolbox at some point in the future to mix in some of the original style.
  • redisman 6y ago
    Software and business are also too human unlike something artificial like bowling. Creating beautifully architected and amazing abstractions with full test coverage at a startup churning out MVPs is actually a very bad approach even if it's objectively following "best" practices.
• ErikAugust 6y ago
  People respond to incentives. As the author puts it, many a developer gets hired and eventually they "entrench themselves into some niche in an organization and collect a huge paycheck because no one around them, including them, realizes that they can do a lot better". In my experience, that is what does happen. There is no incentive to do better, and the paychecks in IT happen to be pretty large. I progressed the most as a software developer when I wanted to be hired again after striking out on my own for a bit. What I learned from striking out on my own was that my software development knowledge and abilities may have worked in previous contexts but not where I wanted to be as a next step of my career. While I could have been promoted at a previous job that wouldn't have proven anything on the open job market. This is probably where a lot of dissonance often occurs. People are Senior or Lead developers at one place for a long time then suddenly are out of a job and cannot find another one. So I worked hard to improve in a number of ways because I was highly incentivized to do so - there was no "current position" to fall back on.
• raiflip 6y ago
  I've dealt with whole teams of these kinds of people. They also get extremely defensive about anything they don't know. Even worse, this was particularly the case around proper testing. Suffice to say the team committed a lot of bugs to production.
• oldandboring 6y ago
  I'm going to risk echoing what other like-minded contrarians here have posted. This essay makes some good observations about what happens to developers in their careers, but colors those observations with opinions about what's good and bad. And, as is usual in the developer community, continuously learning new technologies and layering in more "best practice" structure (presumably in one's own free time) is always king when it comes to these folks. It's hard not to read this and sense a bit of bellyaching about how the market for software engineers isn't a pure meritocracy where those who are using all the latest tools with pitch-perfect architecture are the only ones who get hired and promoted. And it seems to totally ignore the real world in which legacy software, with all its warts, does exist and can't be thrown out.
• courtf 6y ago
  I remember this one, there are lots of good articles on this blog. This one is a little aggressive, but this is a real phenomenon. In many companies, styles and expectations fluctuate too much for anyone to get comfortable for long. Lots of others move glacially, and within those walls, the outside world can barely be heard. I've bounced around quite a bit myself, but some of the best work I've done has been in situations where I could have slacked off and phoned it in. That was typically prevented by the opportunity to perform challenging work that allowed me to learn, not by fear of falling behind some imaginary peer. The problem with many workplaces is that challenging, interesting problems are few and far between and that is by design. Why take on the risk to the business by having technical knowledge in-house to solve the hard stuff? It's expensive, and large chunks of that investment can just walk out the door. Most companies would happily pay for solutions from other businesses that specialize, and then ask devs to glue these mismatched pieces into a semi-cohesive whole. This sort of glue-work is ubiquitous, even in companies that ostensibly specialize in making their own software. How much time is spent wrangling all those amazing, productivity-enhancing dev tools that have proliferated? The goal is typically to offload work for a fraction of what it costs to keep a dev employed. New businesses are cropping up all the time trying to sell tools to the big boys, so they can in turn keep their devs focused on core competencies. The companies that specialize in tooling of course all sell to each other as well, it's a little bit of a cartel, but this endless cycle of tool churn is nothing new. If you approach this environment as a newbie, and you are concerned about becoming an expert, it's likely that you'll only make progress on that goal in fits and starts. Companies grow, job roles become both over-specified in their requirements and narrower in their responsibilities, and all the while you are expected to learn new tools that allow your employer to save on skilled labor. It's rare to find a job where mentoring and career advancement are given genuine care. Employers have an incentive to keep employees tuned for specific, ever-narrowing roles. One of the few consistent places I've been able to find learning opportunities has been in start-ups. The overarching trend is the same there too, but at the beginning those roles are not yet so clearly defined and you can bite off as much as you want. You probably won't be rewarded for doing so, and it's a bit of a crapshoot, but it is one small advantage to those environments.
• imnotlost 6y ago
  Developers are supposed to do all this learning on their own time as well, right? No budget or time for training. In fact, why don't you do some overtime paid in pizza? Learn new stuff at home on your own time, put it on github, it'll be fun, ignore your family and your friends. And the helpful comments here for someone who is doing 12-hour days is to meditate and go for a walk? Work 7 hours and go home, your life will be better.
• bobobob420 6y ago
  In my opinion experienced developers are mostly pretty dumb even at top firms. Yes they are GREAT at the particular thing they have invested the most into labeling themselves but are often stuck in some tunnel vision or just do not care to learn new things. Many young developers are eager, learning multiple technologies/languages at once, work across back-end, front-end, network, dev ops..to be a successful new developer the wall is much much higher than it was for developers 20 years ago. These old guys can't do much tbh and are so slow at adapting, they don't even have excitement in meetings or anything. So boring. You can do what you want in life but don't complain if you are replaced.
• ivanhoe 6y ago
  The only problem here is that building things, unlike bowling, is a team effort, and also goals are very different, you don't win the game by having the highest score in the end. IMHO big question is if it's worth to invest into "getting your score over 160" in terms of benefits for you and/or company? Can that time be better used? Will your project benefit more from moving your bowling from 160 to 200 - or you can get your role covered just fine with 160, so perhaps invest time instead into getting at least 1600 ELO in chess which will be needed on the next project, and will also give you a wider perspective?
• dorkwood 6y ago
  I feel like a lot of people here are missing the point of the article. I've worked with several 'expert beginners' over my career. They think they're near the skill ceiling, but they're actually much closer to the bottom. They rose through the ranks despite not being particularly great at their jobs, and now find themselves having to indoctrinate others into their way of doing things. Any suggestion on how to improve the process is usually met with some form of "that's not how we do things around here", since the expert beginner feels threatened. Preventing yourself from becoming an expert beginner doesn't mean you have to dedicate all your spare time to learning 200 different technologies, as some here have suggested. It's more about accepting that learning is a life-long practice. Knowing that less experienced coworkers still have things they can teach you. Understanding that there is still so much out there for you to learn, and being humble about that fact.
  • lliamander 6y ago
    Indeed. For every new job, new project, and new professional relationship, you have to be willing to ask yourself "what can I learn from this experience?" Learning is often best done when you are working on problems you don't yet know how to solve. But there is a countervailing force, which is the pressure to appear confident and that you know what you are doing. Being transparent about your ignorance, but confident in you're ability to learn is a difficult balance to pull off.
• tracerbulletx 6y ago
  This is a valid interpretation of a trap that people can fall in to but there is also a positive interpretation of being an "expert beginner". Developers encounter so many new technologies at such a rapid pace over their careers, especially recently. People who are constantly trying new technologies at a shallow level can have access to more tools to solve problems and be successful in a rapidly changing environment as long as they don't over do it, and narrow their scope to relevant topics that support each other. I think there is a line to walk between falling into a lack of mastery, vs not absorbing new things at a beneficial rate.
• Discombulator 6y ago
  While the topic is interesting, I don’t think the analysis presented in the article series (at least in the first two articles) is particularly compelling. For one, it relies much on hypotheses about internal though processes, which makes it basically unfalsifiable. Then the author is in my view shooting himself in the foot with the bowling analogy, namely by describing how he noted that he didn’t improve anymore and went to ask a colleague for advice. How would the same not be possible or even likely for the “expert beginner”? All of this is much more easily and briefly explained by motivation - for many people in technology, technology is simply not a passion! For them it is just a tool and like also the article mentions, there are few reasons in many companies to spend more time on perfecting your craft - in fact, it might be strictly worse than building career-enhancing relationships. This is especially true as someone not in a technical position is often not able to assess the quality of the output.
• musicale 6y ago
  This essay seems to be short on specifics.
• ai_ja_nai 6y ago
  Very lucid analysis, nice piece
• Tomis02 6y ago
  > On the other hand, the least talented developers are more likely to stay put since they’ll have a hard time convincing other companies to hire them. Terrible fallacy on so many levels. "I can't convince you to hire me, therefore I'm bad". "I can convince you to hire me, therefore I'm great".
• pontifier 6y ago
  This hits hard. I know that I'm missing some truly fundamental techniques in my development such as testing and ORMs, but I can't seem to bring myself to take the massive steps to abandon the way I'm doing things now. Every time I try to start doing things "The Right Way" I end up getting nothing done. In frustration, I revert back to my old technical debt building ways just to try to move forward at all. -side note- I didn't even know it was possible to bowl without sticking your fingers in the holes... it's almost as absurd as not doing any automated testing.