Elitism as the mid-career growth engine
11–20 of 115 posts
Re: Elitism as the mid-career growth engine
#12Earlier quoted context omitted.
What makes you say that about Python?
it's become a complicated language with many different ways to do the same thing but none of them very good
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.
Re: Elitism as the mid-career growth engine
#13Re: Elitism as the mid-career growth engine
#14> 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
Re: Elitism as the mid-career growth engine
#15Elitism 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 abs…
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?
Re: Elitism as the mid-career growth engine
#16With 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.
Re: Elitism as the mid-career growth engine
#17Elitism 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 abs…
> 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 th…
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.
Re: Elitism as the mid-career growth engine
#18The 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.
Re: Elitism as the mid-career growth engine
#19Earlier quoted context omitted.
it's become a complicated language with many different ways to do the same thing but none of them very good
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 mo…
Re: Elixir, not surprising. Makes for more opportunities for some though.
Re: Elitism as the mid-career growth engine
#20Elitism 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 abs…
> 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 th…
That should end well.