I remember an old mentor programmer I had who basically described his job as building an addition to an addition to an addition on a tree house built in a twig.
Chr prints the unicode symbol associated with the inputted value (in python). The team name uses several operators to have the inputted value be the amogus character
not()…See comment below for this one, I was tricked is a base function that negates what’s inside (turning True to False and vice versa) giving it no parameter returns “True” (because no parameter counts as False)
str(x) turns x into a string, in this case it turns the boolean True into the text string 'True’
min(x) returns the minimal element of an iterable. In this case the character ‘T’ because capital letters come before non-capital letters, otherwise it would return ‘e’ (I’m not entirely sure if it uses unicode, ascii or something else to compare characters, but usually capitals have a lower value than non-capitals and otherwise in alphabetical order ascending)
ord(x) returns the unicode number of x, in this case turning ‘T’ into the integer 84
range(x) creates an iterable from 0 to x (non-inclusive), in this case you can think of it as the list [0, 1, 2, …82, 83] (it’s technically an object of type range but details…)
sum(x) sums up all elements of a list, summing all numbers between 0 and 84 (non-inclusive) is 3486
chr(x) is the inverse of ord(x) and returns the character at position x, which, you guessed it, is ‘ඞ’ at position 3486.
The huge coincidental part is that ඞ lies at a position that can be reached by a cumulative sum of integers between 0 and a given integer. From there on it’s only a question of finding a way to feed that integer into chr(sum(range(x)))
not() is a base function that negates what’s inside (turning True to False and vice versa) giving it no parameter returns “True” (because no parameter counts as False)
Actually, not is an operator. It makes more sense if you write not() as not () - the () is an empty tuple. An empty tuple is falsy in Python, so not () evaluates to True.
Based on what I know of Imposter Syndrome and the Dunning-Kruger effect, it seems you’re at your most competent when you feel like you’re at your least.
So if you’re feeling badly because you feel like you don’t know enough to do your job, take some time to remind yourself that other people who appear to be confident have no idea what they’re doing.
I felt like that early in my career. I used to think that being a rockstar developer was a good thing, and I’d be happy to describe myself as one.
The thing is, a lot of rockstars are really just churning out heaps of unmaintainable code. They think they have a high degree of proficiency, they’re confident in their competence, but there’s a disconnect between what they think and what they produce.
It can be a sign of personal improvement to question yourself when you think you’re doing great. We owe it to ourselves to ask ourselves critically if we can be doing better. Because if we don’t, and we just assume we’re awesome, then we’ll happily churn out sub-awesome cruft.
The insidious thing is that self-criticism leads to self-doubt, and imposter syndrome can be quite paralyzing. But if you learn to control your criticism instead of allowing your criticism to control you, you can achieve higher heights than rockstardom.
A rockstar developer doesn’t churn out unmaintainable, by definition.
The number of people who think they are rockstar developers but clearly aren’t is probably close to the number of cover bands who see themselves as undiscovered rockstars.
I’ve worked with people like this, their best hope is to fail upwards into management.
The only way to know if you are competent coder is for other coders to tell you. If none are telling you, your imposter syndrome isn’t.
There are other signs as well but these aren’t taught in formal education. An example being the ability to recognize how your old code could be improved. The way requirements stack over time makes this a certainty in any product.
Based on what I know of Imposter Syndrome and the Dunning-Kruger effect, it seems you’re at your most competent when you feel like you’re at your least.
I’m not sure how you come to that conclusion, even with the internet meme version of the Dunning-Kruger effect. In the meme version, the incompetent think they are most competent, but I don’t think it follows that the most competent would think they are least competent.
I would summarize the actual Dunning-Kruger effect as: people tend to think they are a bit above average, and actual skill factors in only slightly. Worth emphasizing that these results are over groups of people, and individuals have extreme variation.
Well, I’m not a psychologist, so I suppose my interpretation might not be correct - the irony mounts.
But from the graphs you shared, it looks to me like the only people who underestimated themselves were the top performers. And from what I know firsthand with imposter syndrome, a competent person underestimates themselves.
I used hyperbole for effect, so I don’t think that if you believe you have zero competence in something because you actually have zero competence means that you’re secretly good at something. If you know nothing about plumbing, don’t try to install a toilet.
But if you’re working in the software factory then you don’t actually have zero competence, you probably have formal education and some experience. Having that feeling that you might not be good enough is a sign that you’re on the right track.
That graph is what the herd behavior looks like. But if you break down, take 2 people who are actually on bottom quartile. While on average they think they’re 3rd quartile aka a bit above average, one of them will have impostor syndrome and the other one will think they’re the smartest person around. Then for the top 2 smartest people around, one will know it for sure and the other will think of themselves less than the overconfident newbie described above.
The reason C becomes relevant to Python users isn’t typically because the interpreter is written in C, but because so many important libraries (especially numpy) are implemented in C.
Extension modules are implemented in C because the interpreter is written in C. If it were written in another language, folks would write extension modules for that language instead. Also, it would be less relevant if people used portable C bindings like cffi, which are portable to PyPy and other interpreters… but they don’t.
Extension modules can be, and are, written in Rust and C++. And PyPy has a compatibility layer to run extensions (such as numpy) that are written for CPython.
The reason extension modules are typically in C is of course the API is in C, but that’s true of cffi as well (though you’re right that cffi is more portable). And the reason the API is in C is more fundamental than “CPython is written in C”.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.