Google I/O 2009 - The Myth of the Genius Programmer

I recommend The Myth of The Genius Programmer: [VIDEO] What you see on Github is people's polished code - you don't see what they are throwing away. They might be better, but you are probably looking at some of the code they are most proud of. (Actually, for my github/bitbucket page this is no longer the case. After I watched this video, I started publishing as much of my code as possible, if it actually did what it was supposed to)

It's open source insofar as the code, when it is released, will be released under an open licence. However, it fails the 'unofficial' criterion of a project that is developed in the open . See also: [VIDEO]

So, just as a reference: "Google I/O 2009 - The Myth of the Genius Programmer": [VIDEO] There are quite a couple of possible views in IT, which makes it hard for us

"I hated discussing what OO pattern should be used" "they submit patches to major frameworks, writes things in assembly for fun" You don't have to do this kind of things to be a programmer. Of course discussing OO patterns with your team is a need but submitting patches to major frameworks is on your free time! If every programmer would do so we wouldn't have so many incomplete open software. Try not to be chased by the "The Myth of the Genius Programmer" and keep enjoying creating things. A google talk: [VIDEO]

Google I/O 2009 - The Myth of the Genius Programmer One of the best talks about code reviews and similiar things [VIDEO]

Most people are average, thats kind of the meaning of average. I consider myself an average programmer advancing on an average career path and had plenty of recruiters contact me with interesting opportunities recently. Sure its not Google or Facebook, but so what, I wouln't like to work for a mega coorporation like that anyway. If you doubt yourself because you consider yourself average, consider that the constant talk of excellence, highest skilled people and so forth is mostly HR PR bullshit. Sure, there are extremeley talented people out there, but they are pretty rare. Interesting video, that touches the issue: "The myth of the genius programmer"[0]. [0]: [VIDEO]

Some basic heuristics I use for determining the capability of other programmers and myself: 1.) Does the code have a good bus factor i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: [VIDEO] 2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments. 3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: [LINK]

Two talks given by Ben Collins-Sussman absolutely changed my career path from being a hot headed programmer to thinking like a professional engineer. The Myth of the Genius Programmer: [VIDEO] The Art of Organizational Manipulation: [LINK] I rewatch these every few years, or before an interview. Puts me back in the right headspace. If you're reading this Ben, thank you.