from Hacker News

Elitism as the mid-career growth engine

by peterhunt on 2/20/23, 3:31 PM with 108 comments

• by shubb on 2/21/23, 10:56 AM

  Earlier in my career I felt a lot of disgust at bad code and bad solutions.

  Sometimes it tye badness was really effort due to unfamiliarity or not instantly understanding what I was looking at.my laziness.

  Sometimes it was because it disagreed with what ever framework or methodology I was using to give me confidence in the face of ignorance. I feel like an imposter but at least I know design patterns so this guy who did MVC wrong is worse.

  Sometimes it was looking at something genuinely bad.

  Now, later on, maybe my emphasis is more on business outcome than perfect implementation or maybe I've been involved in making enough abominations due to time pressures and architectural compromises that I can read those forces in other people's work.

  Either way, I don't feel that kind of disgust anymore. It's code. No one is going to read it. It will be replaced next year. It works or it doesn't. Having to rip stuff out when the business changes or someone ways to use a different stack for resume reasons is part of life.

  I wonder if this is an adaption or a maladaption.

• by plaguepilled on 2/21/23, 2:47 PM

  Interestingly, I feel like this sort of attitude is a real issue at the precise moment the author describes it as a boon.

  When you are early to mid career, it is crucial to look for ways to amplify the good you can do in your workplace and solidify your brand as an individual. To do this, you should be looking, ironically, to elevate others. Doing so is the only way to build a reputation that people are going to actively WANT to talk about (e.g. "oh, having trouble? You should call in Jim, he helped me with a related thing"). This is invaluable.

  Perhaps I am speaking through a lens, but had I taken the authors advice and taken a more combative role at such a juncture, I believe I would have far fewer opportunities now.

• by Tade0 on 2/21/23, 11:45 AM

  I get where the author is coming from, but at the same time, having spent most of my career to date as a front-end developer, I can tell you many stories of how hilariously off the rails this approach can go.

  With a decade under my belt I'm feeling that I recently finally started learning and the conclusion so far is that half of the effectiveness of software engineering comes from obeying ultimately simple and common sense rules that anyone can follow, like "use idiomatic expressions", "read the documentation", "prefer pure functions and immutable data structures".

  I'm an average(and kind of lazy) developer, but I found early on that I have an edge over more talented and hard-working people - I gather knowledge instead of compensating for the lack of it with hard work.

  Can you frame it as elitism? I hope not, because I deeply believe the worst and laziest developers can use some of those rules so that they're both effective and still bad and lazy.

• by Distozion on 2/21/23, 11:54 AM

  I had a similar experience when I got into software. As a junior, more than once I wished to just to quit the field - even after years of CS studies & it being one of the best opportunities one can have in my area.

  The draining nature of the "this is shit, we need to do clean code" and "TDD is the way" discussions being constantly repeated day-in day-out, can quickly kill any interest in working on code. It's not that far from being forced to write a book using a 100 most common word list and if you use any word outside of that, you're a shit writer because it will make it harder for others to read, because you used a word that's not in the most common word list...

  I'm quite glad that I moved away from that corporate environment into startup space a year later, which showed a whole different perspective. Where code itself is useless and what mattered is if it delivered value. If your hacky solution can deliver value - then you can justify making it better. Otherwise - who cares.

  I do think there's way too much attachment to code & its perceived quality in the dev community. On the other hand, if you work in a team where majority of people are well into their careers - there's a lot more nuance when it comes to the extremes such as "TDD all day all night" and "daily pair programming". They are seen as tools to utilise when appropriate, rather than mantras to be repeated mindlessly.

• by gpvos on 2/21/23, 11:08 AM

  > Technical excellence begins in wonder but is honed by disgust

  Now that is a quote for the ages.

• by ionwake on 2/21/23, 2:35 PM

  Having spent 2 decades programming I feel I was indeed surrounded by opinionated people who were narrow minded and combative, and often I felt looked down upon regarding my tech stack or code or interests ( eg I remember there being a strongly negative bias against bitcoin in the early days). Now I know according to research most would have been on the autism spectrum and generally less socially adjusted as others with other careers.

  I think my point is engineering may lend itself to strong opinions in people with poor social skills.

• by NotYourLawyer on 2/21/23, 3:15 PM

  I see a lot more elitism in relative beginners. Mid-career people tend to be more understanding and less judgmental.

• by nathias on 2/21/23, 11:11 AM

  Elitism is usually meant as an insult for snobs pretending to have better tastes than anyone else. This is wrong because in questions of taste there can be no criteria other than subjective taste, however in contexts where there are objective criteria of quality elitism is just being a professional good at his job. When you open up a horrible spaghetti codebase that's inconsistent in style and full of nonsensical abstractions with 90% of bloat you should feel digust. Of course all bad code has a reason behind it, some more justified than others, but no reason should ever make a bad codbase feel good.

• by twobitshifter on 2/21/23, 5:09 PM

  Maybe this helps in some places, but the negativity described here will not win you any friends when the subject is your coworker’s pull request and not a random journal article. I always try to see other perspectives and understand why a choice was made and get people to think instead of judging what’s been done. Working with “the smartest person in the room” who believes there’s only one right way to accomplish a goal can be hell. People often mistake confidence for leadership.

• by HybridCurve on 2/21/23, 3:56 PM

  I do not agree with the author marketing elitism here as a desirable characteristic. There is nothing wrong with raising your standards for quality or working to be excellent within your profession but elitism generally tends embody arrogance, social stratification or other exclusionary attitudes.

  You might inclined to disagree with "Well, he said 'this technical elitism' and then gave his own definitions so... ". Yes, he said that, and then proceeded to suggest it's not just acceptable, but desirable to view efforts below your standards with disgust.

  There was no implication of mindfulness or humility in this process, only that it was an effective way to self motivate. There is a difference between what is sufficient and what is unacceptable. If you set your standard at excellence then anything less would be unacceptable. Tempting a mechanism as it may be for self judgement, it is a slippery slope because we often judge others to the standards we set for ourselves.

• by jonnycomputer on 2/21/23, 7:01 PM

  This doesn't really reflect my experience. Sure, some people (me) may not have read the paper, but the presenter sure as hell has, and by the end of the hour, I do have a good idea what the paper is about, and about its strengths and weaknesses.

• by heywhatupboys on 2/21/23, 10:09 AM

  > Consider the Zen of Python:

  if I had only one wish, it would be the end of this reference. Python has no zen, at least not anymore, and if you just want to refer to some abstract moral or best concept, please pick another quote

• by AndrewPGameDev on 2/21/23, 4:26 PM

  The reason why I can agree with this post, and find it useful, is that the author purposefully limits it to the "mid-career" phase. I think that if you want to grow from the "mid-career" phase to the "end-career" phase you have to put aside your elitism more and more. When you read the Nature papers as an expert you do so in a way that is both extremely directed and, at the same time, extremely open-minded to what you find. You can't truly grasp open-mindedness if you think you are better than other people.

• by 7402 on 2/21/23, 11:54 PM

  Um, a post-doc is not "mid-career." A post-doc is a beginning researcher. Just like having a black-belt does not mean you are an "expert," it means you have achieved satisfactory competence in the basics of the art and can now begin your serious study.

• by sailfast on 2/21/23, 4:00 PM

  I didn’t read the article but my infant is teething and I didn’t sleep last night - but this article is terrible right? Hand-drawn charts?

  Discuss.

  (I did read the article)

• by majikaja on 2/22/23, 12:55 AM

  This sounds like the kind of thing people in a stagnant industry who aren't creative enough to branch out say.

• by tracer4201 on 2/21/23, 6:54 PM

  > But elitism only becomes useful at a particular stage of development. Earning the white belt is almost purely knowledge and a bit of practice. Getting to the black belt requires not just skills, but a mindset: determination, resolution, and yes, snobbiness. You must believe that having a black belt is worth the effort and that having a black belt is better than not having one.

  I think it’s even simpler than this white/black belt metaphor.

  Driving your career forward requires delegation, scaling yourself through others. Doing this effectively requires having strong opinions. The author is referring to these opinions as elitism, which is jarring to me. It could be elitism or simple pragmatism.

  Quite a few posts here are referring to code quality. People often forget that programmers aren’t paid to write the prettiest code or have the most beautiful abstractions. VALUE is what we want to produce.

  I once found myself insulting a monolithic code base only to later realize that mess of a code base has shipped in over 10 million devices and a product rated over 4.5 stars on Bestbuy, Amazon, and many more retailers. It’s entire ecosystem had directly and indirectly generated billions of dollars in sales.

  Meanwhile, my own teams’ clean code with well thought abstractions hadn’t generated any revenue at all. In fact, this other “piece of shit” that came before paid for all our compensation.

• by Joel_Mckay on 2/21/23, 1:16 PM

  The guise of a Meritocracy is often just a flimsy pretext for competitive Nepotism.

  However, the ethics of posting a poorly written chat bots nonsense points to a deeper issue, We must consider if derivative copyrighted material when misappropriated by users is still plagiarism due to missing citations.