21 ms·

Elitism as the mid-career growth engine

170 points by peterhunt 4y ago

gpvos 4y ago
> Technical excellence begins in wonder but is honed by disgust Now that is a quote for the ages.
heywhatupboys 4y ago
> 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
- rtodea 4y ago
  What makes you say that about Python?
  - fud101 4y ago
    it's become a complicated language with many different ways to do the same thing but none of them very good
    - butterNaN 4y ago
      To add to that, it's introduced as a 'simple' language. But, in 2023, the cumulative effort one puts into getting things "right" is bigger than effort you would put in learning something that's described as high learning curve. As an anecdote: Someone described elixir to be a "high learning curve" language if I wasn't exposed to Functional Programming. When I inquired how long they mean by that, the answer was 2-4 months. Which really says something about our attention spans.
      - mattgreenrocks 4y ago
        Popularity dooms the simplicity of almost every language. Re: Elixir, not surprising. Makes for more opportunities for some though.
        bitwize 4y ago
        Simplicity is for elitists. Maybe some of you remember Didier Verna's Lisp, Jazz, Aikido: https://www.didierverna.com/blog/index.php?post/2007/04/03/Lisp-Jazz-Aikido https://www.didierverna.com/blog/index.php?post/2007/04/03/L... It's not hard to sympathize with Verna's feelings. These are all based on a similar set of philosophical guideposts: maximal output for minimal input, maximal possibilities of self-expression from a minimal set of generative rules, and understanding the deep "essence" of the craft, so that when you add your own contributions, it is by finding the "essence" of the addition and harmonizing it with the essence of existing work. And these are appealing because they give the feeling of tremendous power and the sky being the limit. But the real world runs on the philosophy of Visual Basic, punk rock, and mixed martial arts, which are all based on a different set of philosophical guideposts: a) focus on practical solutions to real world problems; b) make getting started as easy as possible for everyone; c) it doesn't matter if added components harmonize with the original; what matters is if they contribute significant value on points a) and b), i.e., it's okay to get messy.
    - nevertoolate 4y ago
      unless you're Dutch
    - sanderjd 4y ago
      I don't have many complaints about the language itself, but I've found the packaging ecosystem to be the most complicated and frankly dysfunctional that I've used in the last decade.
      - noobker 4y ago
        I never understand this complaint when Javascript/Typescript is sitting there with a mess of .lock and .json files across multiple tools that sometimes interoperate and sometimes don't. Package management isn't a solved problem; Python employs standard patterns for it; Significantly better than chained Makefiles from my C-development days.
        hot_gril 4y ago
        NodeJS has NPM, which is simple. Usually when you want to run someone else's NodeJS project, you `npm install && npm start`. Most Python projects have a Dockerfile, which shows you how bad the actual package management is. TS is just JS but with extra things that can go wrong (Babel etc) and not being able to use simple `require` syntax anymore and some not-very-automatic type checking that you don't need; I don't use it. It's like taking a steak fresh off the grill and smothering it with mayonnaise.
        sanderjd 4y ago
        I didn't say it was a solved problem - it isn't! - but rather that I find python's solution particularly bad. The situation in C (and C++) is indeed even worse, I just haven't been doing that for the last decade. Things I've used in the last decade that all work better, in my opinion: Bundler, NPM, Maven, Cargo, and even Go's packaging. I always liked python, but I didn't use it at all really for a very long time until recently, and I've just honestly been surprised by the poor state its packaging seems to be in.
    - hot_gril 4y ago
      I came back to Python after several years, and there's type-checking now, which we're required to use at work. Way to ruin the entire point of Python. Also, Python's async stuff was always terrible until they introduced the new async/await feature, but I suppose that's part of the "many ways to do the same thing" you mention. They should've done it from the beginning IMO, but it was hard to predict maybe.
  - feoren 4y ago
    > Explicit is better than implicit Says the language whose code-block-endings are invisible! I will never understand the desire of people to make the important punctuation in their language invisible. Python, CoffeeScript, YAML. These people just hate being able to see the important flow-determining punctuation in their language!
- rkachowski 4y ago
  The fact that it's python is irrelevant, in the context it's about how beginners can read "wisdom" such as the Zen of Python and identify with the goals, whilst veterans can react to the opposite of such writings and consider what the goals prevent against.
- RicoElectrico 4y ago
  I discussed this with my friend - with every release Python becomes more like C++ in that there's a million ways to do the same thing and you're struggling to choose the "correct" one.
shubb 4y ago
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.
- kbrannigan 4y ago
  like speaking we have awkward pauses, we go on tangents and repeat our words. But we deliver the message more or less. If we had to have perfectly rehearsed sentences, We'd never talk
- kuu 4y ago
  Realism vs idealism, I guess.
- awesomeMilou 4y ago
  Isn't this just cargo culting and then realizing when you're cargo culting vs when changes are actually necessary? I also don't like fawning over good code, or what makes good code, but I think it's actually a good thing to anticipate certain architectural changes. Idk, but I don't think you can tell a stakeholder that you can't implement a feature X because you didn't give enough of a shit about architecture and ran out of flexibility to change something.
  - arethuza 4y ago
    Over-architecting a design to be flexible in one way can be a huge problem when changes come along and they are for fundamentally different kinds of changes than were expected when the design was created - this can actually be worse than having an under-architected system.
nathias 4y ago
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.
- michaelt 4y ago
  > however in contexts where there are objective criteria of quality elitism is just being a professional good at his job. Imagine I look at the Linux kernel source code and I feel it's lacking in automated integration tests, and that C is a poor choice of language for security-critical code. Am I a competent professional, applying objective quality criteria? Or am I an arrogant dilettante, to imagine I know better than some of the most influential living programmers?
  - nathias 4y ago
    It depends on you and the context, are you actually working on Linux kernel and have worked on a lot of similar type projects? Objectivity does not imply that it's easy to discern adequate criteria or that they are easy to know or that there is a consensus about them, just that it isn't purely subjective, and code isn't.
  - ChrisMarshallNY 4y ago
    Tell Linus his code sucks. That should end well.
    - thefaux 4y ago
      Linus has a terrible attitude.
      - 4y ago
Tade0 4y ago
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.
- hef19898 4y ago
  +1 for read the documentation.
- nerdponx 4y ago
  > prefer pure functions and immutable data structures This sounds like common sense until it becomes common nonsense, because you use Python or Javascript or Ruby or whatever language where you don't have an optimizing compiler and optimized immutable data structures, so what could have been be a single-pass low-memory scan over a big dataset in 10 minutes that could run on a toaster is implemented as an inefficient clusterfuck that takes 12 hours and 4 GB of memory. It's absolutely important to treat mutability as either a side effect or a local optimization from a design perspective. But Python is not Clojure no matter how hard you try, and at some point you're going to want to mutate a dictionary. Anyway, the point is that what might seem like "common sense" in some situations is not always obvious or unambiguous in general.
  - stinkbutt 4y ago
    [dead]
Distozion 4y ago
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.
- AnimalMuppet 4y ago
  It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well. One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.
  - jacobyoder 4y ago
    Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!" My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs). Another guy (X) started was a year out of high school. X insists that 'tech XYZ' is the best. Current tech stack was partially rebuilt by my colleague, but wasn't finished (because... lots of reasons, mostly resourcing). XYZ is not only not a great fit, but the ecosystem supporting the problem space is small, especially considering what's already in place. Terabytes and years of data need to be migrated (both physically to new data centers and code-wise - new structure handling has to be added to accommodate current and future needs). In planning meetings, "all voices need to be heard"... so X pushes XYZ a lot. And randomly rebuilds small bits in XYZ. And when it doesn't work - blames everything else (it's the network, it's the supporting libraries, it's ...). The CTO will not push back. "That sounds great! That sounds like it'll solve all our issues!". There's a criminal deficiency in the understanding of the current tech stack or problems, along with no experience in migrating anything. But any criticism is taken as "we need to be more inclusive and let more people speak up - some of the best ideas can come from people who've not traditionally been heard". Up to a point, that can make sense. But when do you draw the line? 3 months? 6 months? 18 months? People insisting on promoting child-like understandings of problems and solutions - while not ever delivering anything resembling a working solution - at some point should not be listened to. Why does my colleague stay? He's only part time right now, and was close to leaving, but there's been some shift to refocus the CTO on something else, which may - over the next month or so - leave the few competent people there alone enough to get things back on track. I think if this was a 'full time' gig for him, he'd have left already.
Joel_Mckay 4y ago
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.
- deleted 4y ago
  [deleted]
ionwake 4y ago
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.
- feoren 4y ago
  > eg I remember there being a strongly negative bias against bitcoin in the early days So, in the one example you gave, they were right. And yet I get downvoted for suggesting: hey, guys, that senior developer who's insisting on doing something a certain way? Sorry you have to hear this, but they're often right.
  - ionwake 4y ago
    I think there is some confusion here. I will clarify, but please don't get offended. For your first point, no, they were wrong, I did very well on bitcoin - hence my example. For your second point - I am confused - I agree senior developers know what they are talking about, I was one for nearly 2 decades. I was referring to peers not superiors. I was saying I have encountered narrow mindedness and ignorance. I did not say that is all I encountered. I also encountered kind, intelligent, superior and inspirational people. Edit> On second thoughts - I re read your comment - Who downvoted you? When? Was it in regards to this article? What on earth are you talking about? Are you chatgpt?
plaguepilled 4y ago
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.
- noobker 4y ago
  This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities. The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap. This stance and boundary provides a clear decision space to the learning junior members: "if you think you see a mistake, those here will be happy to hear it; no sacred cows". Bringing this practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.
  - dgb23 4y ago
    My mantra related to that is "be mean to the code and nice with to programmer". In order to learn and make things better you _have to_ be critical. But the way things are communicated is very important so everyone is on board. "We could do better here" - no matter who exactly was responsible in the past. "This made sense at the time but with what we learned..." - remind each other that improvement and learning is part of the whole deal. "I like the simple and expressive core idea of this, but if we expand this further..." - elevate and develop the good stuff that's already there. I make jokes about my mistakes, bring them up early and often. Everything is a bit lighter and easier with a bit of humor and without the fear of making mistakes. And vice versa it is just as detrimental to be afraid to bring mistakes and inadequacies up and criticize them. It's much more fun and productive if things are continuously improving.
NotYourLawyer 4y ago
I see a lot more elitism in relative beginners. Mid-career people tend to be more understanding and less judgmental.
- MichaelZuo 4y ago
  Which matches my observations. Folks may pretend otherwise but nearly all mid-career people intuitively understand there's lots of bigger fish in this world.
- thwayunion 4y ago
  The elitism tends to show up once you've been around the block a few times but before your ego and position is secure. Years 6-8 or so; ie, post-doc age. Not really properly mid-career, at least outside of "retire at 35" FAANG world.
HybridCurve 4y ago
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.
sailfast 4y ago
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)
AndrewPGameDev 4y ago
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.
twobitshifter 4y ago
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.
- feoren 4y ago
  Sure, we should all make an effort to be diplomatic and not unnecessarily negative. But you're making a huge assumption: that the "smartest person in the room" is wrong. That's a nice, convenient, simple world where you can just ignore people that you disagree with by a-priori assuming they're wrong. Sorry to burst your bubble: sometimes (often?), these people are right. People with decades of experience are often integrating thousands of lessons they've learned, in order to satisfy hundreds of individual constraints as best as they can. Consider the "Thinking Fast and Slow" anecdote about the fire chief who orders everyone out of the building, despite nothing obvious being wrong, because they have a gut feeling. If there's a culture of "Who made you the boss? Look at this guy, acting like he's the smartest guy in the room. If you're so smart, you should be able to explain to me why you believe we should all leave the building. All voices deserve to be heard. Sometimes the best ideas can come from ..." then everyone dies. Look, I know we hate it when that arrogant sportsman is actually good at his sport. It's a bruising to our ego when the senior developer seemingly arrogantly insists on some standard or some change that isn't immediately obvious to you, and she doesn't immediately have the time to explain to you the 600 reasons why. She's probably a hell of a lot more critical of the idea than you are! She's already thought of, and worked through, every single objection you're raising, plus 100 more, and still decided this was the way to go. Yes, mentoring is important, and she probably does spend a lot of time doing that. (Maybe you're not willing to listen?) But not every moment has to be a healthy-debate all-ideas-welcome teaching moment. Sometimes you just fucking listen to the smartest guy in the room before the building collapses.
deleted 4y ago
[deleted]
deweywsu 4y ago
[dead]
tracer4201 4y ago
> 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.
jonnycomputer 4y ago
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.
7402 4y ago
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.
majikaja 4y ago
This sounds like the kind of thing people in a stagnant industry who aren't creative enough to branch out say.

170 points by peterhunt 4y ago

> Technical excellence begins in wonder but is honed by disgust Now that is a quote for the ages.

> 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

rtodea 4y ago
What makes you say that about Python?
- fud101 4y ago
  it's become a complicated language with many different ways to do the same thing but none of them very good
  - butterNaN 4y ago
    To add to that, it's introduced as a 'simple' language. But, in 2023, the cumulative effort one puts into getting things "right" is bigger than effort you would put in learning something that's described as high learning curve. As an anecdote: Someone described elixir to be a "high learning curve" language if I wasn't exposed to Functional Programming. When I inquired how long they mean by that, the answer was 2-4 months. Which really says something about our attention spans.
    - mattgreenrocks 4y ago
      Popularity dooms the simplicity of almost every language. Re: Elixir, not surprising. Makes for more opportunities for some though.
      - bitwize 4y ago
        Simplicity is for elitists. Maybe some of you remember Didier Verna's Lisp, Jazz, Aikido: https://www.didierverna.com/blog/index.php?post/2007/04/03/Lisp-Jazz-Aikido https://www.didierverna.com/blog/index.php?post/2007/04/03/L... It's not hard to sympathize with Verna's feelings. These are all based on a similar set of philosophical guideposts: maximal output for minimal input, maximal possibilities of self-expression from a minimal set of generative rules, and understanding the deep "essence" of the craft, so that when you add your own contributions, it is by finding the "essence" of the addition and harmonizing it with the essence of existing work. And these are appealing because they give the feeling of tremendous power and the sky being the limit. But the real world runs on the philosophy of Visual Basic, punk rock, and mixed martial arts, which are all based on a different set of philosophical guideposts: a) focus on practical solutions to real world problems; b) make getting started as easy as possible for everyone; c) it doesn't matter if added components harmonize with the original; what matters is if they contribute significant value on points a) and b), i.e., it's okay to get messy.
  - nevertoolate 4y ago
    unless you're Dutch
  - sanderjd 4y ago
    I don't have many complaints about the language itself, but I've found the packaging ecosystem to be the most complicated and frankly dysfunctional that I've used in the last decade.
    - noobker 4y ago
      I never understand this complaint when Javascript/Typescript is sitting there with a mess of .lock and .json files across multiple tools that sometimes interoperate and sometimes don't. Package management isn't a solved problem; Python employs standard patterns for it; Significantly better than chained Makefiles from my C-development days.
      - hot_gril 4y ago
        NodeJS has NPM, which is simple. Usually when you want to run someone else's NodeJS project, you `npm install && npm start`. Most Python projects have a Dockerfile, which shows you how bad the actual package management is. TS is just JS but with extra things that can go wrong (Babel etc) and not being able to use simple `require` syntax anymore and some not-very-automatic type checking that you don't need; I don't use it. It's like taking a steak fresh off the grill and smothering it with mayonnaise.
      - sanderjd 4y ago
        I didn't say it was a solved problem - it isn't! - but rather that I find python's solution particularly bad. The situation in C (and C++) is indeed even worse, I just haven't been doing that for the last decade. Things I've used in the last decade that all work better, in my opinion: Bundler, NPM, Maven, Cargo, and even Go's packaging. I always liked python, but I didn't use it at all really for a very long time until recently, and I've just honestly been surprised by the poor state its packaging seems to be in.
  - hot_gril 4y ago
    I came back to Python after several years, and there's type-checking now, which we're required to use at work. Way to ruin the entire point of Python. Also, Python's async stuff was always terrible until they introduced the new async/await feature, but I suppose that's part of the "many ways to do the same thing" you mention. They should've done it from the beginning IMO, but it was hard to predict maybe.
- feoren 4y ago
  > Explicit is better than implicit Says the language whose code-block-endings are invisible! I will never understand the desire of people to make the important punctuation in their language invisible. Python, CoffeeScript, YAML. These people just hate being able to see the important flow-determining punctuation in their language!
rkachowski 4y ago
The fact that it's python is irrelevant, in the context it's about how beginners can read "wisdom" such as the Zen of Python and identify with the goals, whilst veterans can react to the opposite of such writings and consider what the goals prevent against.
RicoElectrico 4y ago
I discussed this with my friend - with every release Python becomes more like C++ in that there's a million ways to do the same thing and you're struggling to choose the "correct" one.

shubb 4y ago

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.

kbrannigan 4y ago
like speaking we have awkward pauses, we go on tangents and repeat our words. But we deliver the message more or less. If we had to have perfectly rehearsed sentences, We'd never talk
kuu 4y ago
Realism vs idealism, I guess.
awesomeMilou 4y ago
Isn't this just cargo culting and then realizing when you're cargo culting vs when changes are actually necessary? I also don't like fawning over good code, or what makes good code, but I think it's actually a good thing to anticipate certain architectural changes. Idk, but I don't think you can tell a stakeholder that you can't implement a feature X because you didn't give enough of a shit about architecture and ran out of flexibility to change something.
- arethuza 4y ago
  Over-architecting a design to be flexible in one way can be a huge problem when changes come along and they are for fundamentally different kinds of changes than were expected when the design was created - this can actually be worse than having an under-architected system.

nathias 4y ago

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.

michaelt 4y ago
> however in contexts where there are objective criteria of quality elitism is just being a professional good at his job. Imagine I look at the Linux kernel source code and I feel it's lacking in automated integration tests, and that C is a poor choice of language for security-critical code. Am I a competent professional, applying objective quality criteria? Or am I an arrogant dilettante, to imagine I know better than some of the most influential living programmers?
- nathias 4y ago
  It depends on you and the context, are you actually working on Linux kernel and have worked on a lot of similar type projects? Objectivity does not imply that it's easy to discern adequate criteria or that they are easy to know or that there is a consensus about them, just that it isn't purely subjective, and code isn't.
- ChrisMarshallNY 4y ago
  Tell Linus his code sucks. That should end well.
  - thefaux 4y ago
    Linus has a terrible attitude.
    - 4y ago

Tade0 4y ago

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.

hef19898 4y ago
+1 for read the documentation.
nerdponx 4y ago
> prefer pure functions and immutable data structures This sounds like common sense until it becomes common nonsense, because you use Python or Javascript or Ruby or whatever language where you don't have an optimizing compiler and optimized immutable data structures, so what could have been be a single-pass low-memory scan over a big dataset in 10 minutes that could run on a toaster is implemented as an inefficient clusterfuck that takes 12 hours and 4 GB of memory. It's absolutely important to treat mutability as either a side effect or a local optimization from a design perspective. But Python is not Clojure no matter how hard you try, and at some point you're going to want to mutate a dictionary. Anyway, the point is that what might seem like "common sense" in some situations is not always obvious or unambiguous in general.
- stinkbutt 4y ago
  [dead]

Distozion 4y ago

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.

AnimalMuppet 4y ago
It's almost like children versus grown-ups. Children have simplistic, almost magical thinking. Adults know the world is more complicated, and the childrens' simplistic solutions don't actually work very well. One of the reasons is small sample size. Children don't have the sample size to see why their simplistic solutions don't work. Neither does a programmer with two years of experience.
- jacobyoder 4y ago
  Colleague of mine working in small company. New 'CTO' hired last year. He's very much of the "everyone's voice deserves to be heard... all input is valid!" My colleague has 22 years of engineering experience across a wide range of problem spaces and industries and team sizes (large bigco to mom/pop orgs). Another guy (X) started was a year out of high school. X insists that 'tech XYZ' is the best. Current tech stack was partially rebuilt by my colleague, but wasn't finished (because... lots of reasons, mostly resourcing). XYZ is not only not a great fit, but the ecosystem supporting the problem space is small, especially considering what's already in place. Terabytes and years of data need to be migrated (both physically to new data centers and code-wise - new structure handling has to be added to accommodate current and future needs). In planning meetings, "all voices need to be heard"... so X pushes XYZ a lot. And randomly rebuilds small bits in XYZ. And when it doesn't work - blames everything else (it's the network, it's the supporting libraries, it's ...). The CTO will not push back. "That sounds great! That sounds like it'll solve all our issues!". There's a criminal deficiency in the understanding of the current tech stack or problems, along with no experience in migrating anything. But any criticism is taken as "we need to be more inclusive and let more people speak up - some of the best ideas can come from people who've not traditionally been heard". Up to a point, that can make sense. But when do you draw the line? 3 months? 6 months? 18 months? People insisting on promoting child-like understandings of problems and solutions - while not ever delivering anything resembling a working solution - at some point should not be listened to. Why does my colleague stay? He's only part time right now, and was close to leaving, but there's been some shift to refocus the CTO on something else, which may - over the next month or so - leave the few competent people there alone enough to get things back on track. I think if this was a 'full time' gig for him, he'd have left already.

Joel_Mckay 4y ago

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.

deleted 4y ago
[deleted]

ionwake 4y ago

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.

feoren 4y ago
> eg I remember there being a strongly negative bias against bitcoin in the early days So, in the one example you gave, they were right. And yet I get downvoted for suggesting: hey, guys, that senior developer who's insisting on doing something a certain way? Sorry you have to hear this, but they're often right.
- ionwake 4y ago
  I think there is some confusion here. I will clarify, but please don't get offended. For your first point, no, they were wrong, I did very well on bitcoin - hence my example. For your second point - I am confused - I agree senior developers know what they are talking about, I was one for nearly 2 decades. I was referring to peers not superiors. I was saying I have encountered narrow mindedness and ignorance. I did not say that is all I encountered. I also encountered kind, intelligent, superior and inspirational people. Edit> On second thoughts - I re read your comment - Who downvoted you? When? Was it in regards to this article? What on earth are you talking about? Are you chatgpt?

plaguepilled 4y ago

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.

noobker 4y ago
This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities. The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap. This stance and boundary provides a clear decision space to the learning junior members: "if you think you see a mistake, those here will be happy to hear it; no sacred cows". Bringing this practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.
- dgb23 4y ago
  My mantra related to that is "be mean to the code and nice with to programmer". In order to learn and make things better you _have to_ be critical. But the way things are communicated is very important so everyone is on board. "We could do better here" - no matter who exactly was responsible in the past. "This made sense at the time but with what we learned..." - remind each other that improvement and learning is part of the whole deal. "I like the simple and expressive core idea of this, but if we expand this further..." - elevate and develop the good stuff that's already there. I make jokes about my mistakes, bring them up early and often. Everything is a bit lighter and easier with a bit of humor and without the fear of making mistakes. And vice versa it is just as detrimental to be afraid to bring mistakes and inadequacies up and criticize them. It's much more fun and productive if things are continuously improving.

NotYourLawyer 4y ago

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

MichaelZuo 4y ago
Which matches my observations. Folks may pretend otherwise but nearly all mid-career people intuitively understand there's lots of bigger fish in this world.
thwayunion 4y ago
The elitism tends to show up once you've been around the block a few times but before your ego and position is secure. Years 6-8 or so; ie, post-doc age. Not really properly mid-career, at least outside of "retire at 35" FAANG world.

HybridCurve 4y ago

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.

sailfast 4y ago

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)

AndrewPGameDev 4y ago

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.

twobitshifter 4y ago

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.

feoren 4y ago
Sure, we should all make an effort to be diplomatic and not unnecessarily negative. But you're making a huge assumption: that the "smartest person in the room" is wrong. That's a nice, convenient, simple world where you can just ignore people that you disagree with by a-priori assuming they're wrong. Sorry to burst your bubble: sometimes (often?), these people are right. People with decades of experience are often integrating thousands of lessons they've learned, in order to satisfy hundreds of individual constraints as best as they can. Consider the "Thinking Fast and Slow" anecdote about the fire chief who orders everyone out of the building, despite nothing obvious being wrong, because they have a gut feeling. If there's a culture of "Who made you the boss? Look at this guy, acting like he's the smartest guy in the room. If you're so smart, you should be able to explain to me why you believe we should all leave the building. All voices deserve to be heard. Sometimes the best ideas can come from ..." then everyone dies. Look, I know we hate it when that arrogant sportsman is actually good at his sport. It's a bruising to our ego when the senior developer seemingly arrogantly insists on some standard or some change that isn't immediately obvious to you, and she doesn't immediately have the time to explain to you the 600 reasons why. She's probably a hell of a lot more critical of the idea than you are! She's already thought of, and worked through, every single objection you're raising, plus 100 more, and still decided this was the way to go. Yes, mentoring is important, and she probably does spend a lot of time doing that. (Maybe you're not willing to listen?) But not every moment has to be a healthy-debate all-ideas-welcome teaching moment. Sometimes you just fucking listen to the smartest guy in the room before the building collapses.

deleted 4y ago

[deleted]

deweywsu 4y ago

[dead]

tracer4201 4y ago

> 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.

jonnycomputer 4y ago

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.

7402 4y ago

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.

majikaja 4y ago

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