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

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: ▶ this 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.

in “FAQ on Leaving Google” · View on HN

Google I/O 2009 - The Myth of the Genius Programmer One of the best talks about code reviews and similiar things ▶ this video

in “Ask HN: What's your favorite tech talk?” · View on HN

I recommend The Myth of The Genius Programmer: ▶ this 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)

in “Your taste is why your work disappoints you.” · View on HN

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]: ▶ this video

in “Ask HN: Is there no place for people, who are average at something?” · View on HN

"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: ▶ this video

in “Ask HN: What do you do when you realize you are not a programmer?” · View on HN

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: ▶ this 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]

in “Ask HN: As a programmer, how do you know if you're a good one or not?” · View on HN