Put Yourself Out There: The Myth of the Genius Programmer
joshldavis.com
joshldavis.com
Would you rather be thought of as the best developer, or actually be the best developer? The two aren't mutually exclusive, but I find it entirely suspicious that the rise in needing to "put yourself out there" has correlated so strongly with social media becoming pervasive. If I have a finite amount of time available for hacking, why do I want to spend a not-insignificant amount of it signaling?
Hacker culture has been corrupted by this 'need' for influence. Perhaps it isn't the same as the neckbeard culture I looked forward to joining in my youth.
"Being powerful is like being a lady. If you have to tell people you are, you aren't."
I think the type of blog you are referring to desires to engage others, while a blog that is indexable simply there to add value for other who might be trying to figure their way through the same random things that you have been.
What is interesting is when someone picks up a problem and simply solves it using the tools at hand, be it old, new, preferred, or trying out a new approach. I learn far more from the approaches than the results.
You do things, find something new or interesting, share it with the world so others can build on your work.
It's not about being the best programmer. After all, most of us are not the best - yet :) It's important not to discourage each other by pretending that only the best programmers matter. The whole point of the post is that it's sometimes important to "signal" that we're not perfect.
Intellectual humility is a good capsule summary of what I'm looking for (despite my username; I never claimed to be self-consistent). But intellectual humility can be at odds with the notion of always presenting the 'best' side of yourself to the market. I'm interested in an individuals steps and missteps, not a carefully-marketed image.
The whole article is against self-legend-making and you seem to be in violent agreement.
Seriously, humility is one of the most arrogant things I've ever come across. You do not ever "signal" and be humble at the same time, that isn't how people work.
Obviously if you aren't interested in any of that, there is nothing wrong with spending the time the way you want to spend it. But it's not about signaling or influence, at least as I interpret it.
The only reason I made a comment to this effect is that I've noticed an uptick in articles about how Github is your resume/marketing yourself/marketing your OSS/how you should only work on 'important' OSS/some other silly notion. I want to believe this isn't a problem, but with open source powering so much, it appears that people want to be the next DHH.
I think there is something to worrying about software shifting to a heavily reputation-based economy (as opposed to one oriented around making things). Namely, in that shift, it rewards people who generate noise, regardless of the amount of signal contained. Polluting the well, in this case, results in everyone having to output a certain amount of signaling just to keep up.
It's entirely possible I am projecting some here, as I've struggled with this myself. I just don't want to always concerned with this tripe, because it's not the same at all as actually making software.
So I completely understand the author's attempts to go public. It isn't about being the next DHH, it's about overcoming the fear of rejection. I have been considering "going public" for years for this very reason.
Seriously. What's the worst that could happen about pushing some open source code on GitHub? You don't have to start by contributing to openssl or something of similar magnitude. Just push some stuff to your personal one.
Trust me, I graduated college with an art degree and some of my earliest GitHub stuff shows this. But I keep pushing, literally. One of my babies has 1300+ stars and that's awesome to me. I don't think of it like validation, but more like "holy shit a lot of people like this." Some of my libraries are sitting at 0 stars, and that's ok.
I'm not sure if this describes you, but I can be pretty thin skinned on the internet, which often discourages me from posting. I write things and delete them more often than I hit submit.
One nice thing about going public is it's unlikely anyone will notice you for a while. Even patio11 says only his brother looked at his blog for a few years (IIRC).
If only getting visitors were as easy as being related to them!
No, seriously speaking, my blog had perhaps 200~300 visitors for the average article from 2006 through, hmm, late 2009 or so? (What changed? A combination of discovering HN, going full time, changing my writing style to exclusively focus on the 4k to 8k word essay that I feel is generally my best work, and a minor refocusing on topics.)
When I have something to share, I'll share; when I don't, I don't. Confidence has little to do with it.
There are a lot of useful blog posts and social media interactions and they're usually useful (especially with google), but no, I don't need another blog post saying how to install RabbitMQ
I don't see enough heresies entertained in a supposedly-progressive-minded crowd like HN. That is a problem, because it represents a real stumbling block to progress.
To learn somthing, is to 1. Read, 2. Do and 3. Teach. So blogging can be "teach" part.
Slightly annoying how that works.
Though depending where you are starting from and trying to head to, there are ways that you can try to short-circuit this. If trying to move sideways into a technical role from another (or something else entirely) for instance then taking professional certifications in your own time can be useful for proving to a potential new employer that you really know+understand the skill that you believe you might have. The trick is finding something that actually means something to your target, which can be a black art (in the Microsoft ecosystem for instance the MCSA and MCSE qualifications can mean a lot to some, but little to others, and sometimes nothing without some commercial experience to back it up).
> overconfidence
I don't think this is about promoting overconfidence, more avoiding the underconfidence that comes from misjudging how capable other people are relative to yourself.
I've had interviewers literally tell me that "Ya, that was a trick question to see if you thought you were god's gift to programming. The fact you didn't rate yourself a 9 or 10 proves that you are sensible."
So I'm not sure that is true.
I think it is a question of being confident enough that you don't second guess yourself yet humble enough that people don't think you have an ego that will cause workplace drama.
Anyone answering 9 or 10 is in for it.
I'm pretty sure the reason I elicited that reaction was I have a statement on my resume about a project I work on at my current job that handles as many transactions [in terms of $$] as that entire company does.
That is just a guess on my part tho.
It's intended to view their confidence. As someone else posted, the older they've gotten, the lower they'd score. That's because as they've gotten more experience, they've had more of those "...wow, this code someone else wrote is so much better than mine" and "Oh man, this code I wrote 6 months ago is -terrible-", etc.
Someone who says "I'm a ten!", it doesn't matter what they think the goalpost is, the are the best they can imagine, which either means they are great (hence seeing how they answer on the followup questions), or it means they aren't, but they've never seen better...which means they aren't out learning, be it from other devs they work with, open source code, whatever. Throw them some hard questions, see how they answer. If they do well, snap them up, as they're good and they know it; if they do poorly, you may want to pass (a lot of the worst performing candidates I've seen ranked themselves 8-10 in a technology).
Someone who says "I'm a 3 maybe" probably means they are passably fluent, but they haven't done much with it, and they recognize it. Feel them out some easy questions first, and expect that if you need them to use this language there will be some mentoring and/or time needed to get them up to speed, but they'll probably be willing to learn given that they applied, and recognize they don't know it well.
Someone who says "I'd like to think I'm an 8, but most days I probably code more at a 6" means they're probably quite good with that language, but also quite realistic, and have had experience with requirements changing, making hard decisions due to delivery dates, have worked with a lot of libraries and people and seen some who are better, some who are worse. Start with intermediate questions and go from there.
It has no direct bearing on passing/failing the interview, it's just used to set the tone and expectations of the interview. If we have multiple positions open, it might be taken in conjunction with how you do to determine what position is offered, as well.
He rated himself 10/10 for Javascript, so I asked what he'd done with the language.
He replied "I've validated forms."
I was expecting more to say the least.
Put another way, someone who rates himself a 10 because he's the best in his CS class is someone who doesn't know what he doesn't know, and is also likely to be a primadonna. Someone who shows some thoughtfulness, skepticism, and humility when answering this question is more mature and self-aware, and is much more likely to be an effective part of the team. The rest of the interview is supposed to establish how much they actually know.
Project the question into another domain - "I passed my intro Spanish class", "Oh yeah, on a scale of 1 to 10 how fluent are you in Spanish?", "I'm a 10". Nope.
It's like the difference between being fluent in Spanish and being able to use the language to write moving poetry or having a very extensive vocabulary.
I think it is much better to be as specific as possible about what skills you expect the candidate to have going in and what you expect them to be able to learn on the job.
I'm pointing out it does happen and its specifically intended to locate potentially overconfident people and needle them.
Obviously, yes, an interviewer prefers someone who knows the answers to every question asked. But an honest "I don't know/am not sure, but I think..." is a much, MUCH better answer than trying to bluff. If you're right after prefacing it with that, it's nearly as good as having bluffed correctly (the interviewer knows you didn't know or were not sure, but your knowledge of the tech is sufficiently good for you to deduce what unfamiliar constructs do), and if you're wrong, it counts nowhere nearly as badly against you as if you bluffed incorrectly (as you at least are showing you know and admit to what you don't know).
Now, obviously this is also partly dependent on the level of knowledge needed to answer the question. If you are, say, applying for a Java job and don't know what private means, you're probably not getting the job. But if you're applying for a Java job, and are asked for the difference between soft, weak, and phantom references, and respond "I'm not sure...I know the first two have to do with keeping references to objects that should not prevent garbage collection, like when adding items to a cache or something, but I don't remember the difference between them, I'd need to look that up. And I've never heard of a phantom reference", and then asking about them if there are no follow up questions, is still pretty damn good. And "I don't know; I'd imagine from the name they have to do with referencing an object in a way opaque to the garbage collector?" is also very good. "I don't know" is okay, it just might mean we'd not be willing to hire you on as a senior dev, but if you nail everything else maybe one level below that.
Coincidentally, this answer takes more confidence than bluffing. Bluffing is actually a signal of low confidence in a person. Too afraid to be wrong.
I only ever asked language familiarity questions if either, A. The job is explicitly frontend and we need someone already well informed (Javascript has a lot of gotchas, and HTML and CSS can be complex; backend experience doesn't directly translate), or B. It's about a technology (not just language) on the person's resume. If you put down you know X, you better expect questions about X. The questions were generally prefaced with asking the person how well they felt they knew the tech, too; it was as much a "does this person know what they say they know" as much as it was a "does this person know X".
Reference type in Java isn't some esoteric library knowledge, either. It's not "tell me everything that implements the List interface" or something else as equally useless. If you want to build any sort of caching mechanism, you -really- ought to know about it, and if you're claiming great Java knowledge, and want to be in charge of delivering a Java product, it's reasonable to expect you to be familiar at least to when you might need to go read the Javadocs on those classes.
If you were a junior programmer who just coded tasks as they were handed to you, and had code reviews, and you don't know it (and you admit that), that's not the kind of question I'd expect you to know. And if you don't claim to have much experience with Java, obviously asking you a Java question is silly; I'd ask you something about what you do use.
Any way I go back to my old posts from time to time and have a good laugh about them. Nothing is the best thing that has happened to my blog.
- Is the user interface intuitive?
- Will this library be efficient for its most common uses?
- Have I given the simplest explanation for what this thing I wrote does?
It helps to be able to say, "I can't know that yet, not until I ask someone." That might happen in use cases, watching over someone's shoulder, showing a conference poster, or getting complaints on a message board two years later, but it's always collaborative, even when I have my act together.
This seems especially weird seen most people here are using Git and many of the things we have wouldn't exist without these people.
If I'm not mistaken Rich Hickey took one or two years off, pulled the plug and went on to create Clojure.
Saying "But that's only one in ten million" ain't an argument: there are genius programmers out there and we're all using daily piece of code from these genius programmers.
Watching videos from Linus Torvalds (the talk about Git he gave at Google is amazing), Theo de Raadt (anything about security), Rich Hickey, Simon Peyton Jones, etc. is one of the thing I prefer to do.
I've also personally met several genius programmers: including one who had been working on at Adobe and who (while not at Adobe anymore) then single-handedly wrote a Java bytecode to Objective-C source code converter. I know for a fact that this converter allowed to write an app which reached top 3 in the appstore.
I've also competed ten years ago or so versus plain geniuses in the TopCoder algorithmic competition. Some of the best ranked coder there had incredible achievements, like for one of them having won the mathematics olympiad several times.
That's the thing: even "one in ten million" means that there are quite a few genius programmers out there among us. And we owe a lot to them: not only have we many great tools and projects which would never have existed without them, but they also let us get a glimpse inside their beautiful minds through the messages / blog they post and through the video they make.
Why downvote?
As a sidenote, I'd put Grace Hopper up there instead of DHH, and Dennis Ritchie and Ken Thomopson seem to be missing. ; )
He's not a hermit, but definitely a genius programmer who has built things by himself without putting himself "out there."
The second way is harder, particularly for the introverted. This involves self-marketing, being obviously and repeatedly correct. It also requires a bit of political adeptness and a bit of visionary helps as well. Both Joel and Rands have done very well here and there's a number of others who have made a name for themselves via the web. If you have a choice, choose this method as it yields better visibility. Although it also means that screw ups are magnified if and when they occur.
Am I the best programmer going? No. If you're reading this, I suspect you're not either... But I work hard at delivering the goods, and I'm good at what I do. People like this get remembered when new projects start. No matter how big or small your niche is or how many you fill, impress others. And don't needlessly piss them off - people remember assholes far longer than good 'uns.
I'd only add one thing to this approach: make sure that you are at least solving one of your own problems and that the solution is real -- i.e. it really benefits you in some measurable way.
I did this a few years ago with a relatively obscure gem that solved a real problem I actually had with refactoring business logic. I put it out there to get feedback on it and was rather disappointed with the initial reactions ("You don't understand MVC!" "You've done it all wrong!"). But I put myself aside and tried to understand the feedback from their point of view.
One thing that became obvious is that most people didn't see the solution as valid because they had completely different context and approach. Fair enough. There were also several that simply 'cargo-culted' mvc responses without realizing that my gem was a thin wrapper around methods that DHH had already put in Rails (so if I didn't understand MVC, neither did he! ;) And no one commented on the biggest problems I legitimately saw with my approach: thread-safety and closures on controller instances in a prod env.
But none of that stopped this gem from being incredibly useful as I tried to break apart a giant monolithic legacy app that challenged traditional refactoring approaches. Maybe it's not perfect, but at least it's a way forward.
So the moral of the story is: put your idea out there, expect feedback and criticism (maybe only criticism since the people who like things tend to keep quiet (e.g. the rvm story last year)) -- but so long as this thing is useful to one person (only you?), use it to make your life easier!
If it's useful to others, that's a bonus learning opportunity, but that shouldn't be your sole motivation.