1. Seeing a list of people associated with a product is kind of useful, but I specifically want to know what their role was / what they did, vs. just a generic quote.
2. I like the idea of having versions under a larger high-level product (like Mac → Apple Macintosh 128K) but this doesn't seem to be expressed in the navigation anywhere when you're on a specific version. There should be some form of breadcrumbing / indicating the parent.
3. I'd reconsider the tabs as distinct pages vs. a single page, Wikipedia style where the tabs just act as anchors. Possibly use an accordion pattern with a preview for each section. Right now I have to click through 8 different tabs to see if there's possibly content which is usually pretty sparse.
4. Product pages should look distinct from the homepage. The hero section with the tagline / search field is really prominent (and autofocused) when you're looking at a specific product / version. The main focus should be the product title, and the header should be secondary.
5. Not crazy about the quotes as the lead-in for the product pages. It feels like it should be a succinct summary of what the product was. Information like release date, size of team, etc... should be above the fold. I think Wikipedia is again instructive.
6. As a more meta comment, lack of data is definitely an issue and at the same it seems tough to encourage people to contribute data to a (sorry) unknown entity. I tried to edit an article to see how the data's being captured but didn't want to create an account — are you familiar with Wikidata, RDF, Linked Data, etc...? If you can't find this data already in a structured way, I've spent some time parsing wikitext somewhat successfully and if you look at e.g. the Credits section https://en.wikipedia.org/wiki/Macintosh_128K#Credits you might be able to bootstrap some data (or at least provide draft pages that someone can then vet / fill out).
7. From what I understand, scraping LinkedIn is pretty challenging, but could you gather data from there / cross-reference to infer who worked on what products? LinkedIn specifically has "Projects" and "Creators", but I don't know what its adoption is like. Basically vs. just expecting me (the general user) to crowdsource this for you, what initial work have you put in.
Linear and logistic regression, gradient descent, clustering, support vector machines, bias and variance (one of the slides was taken from the course), neural networks, etc...
He goes into why he started exploring the idea at first (students got 5's on their AP physics exams and had strong problem-solving skills — plug-and-chug — but poor conceptual understanding), the many iterations of the approach, and the data he collected on the way (significant increases in open-ended, conceptual problems, including at other schools that adopted the approach). Really fascinating.
I think it depends on what you're trying to achieve. For example if you're trying to pull off the iPhone in one year with 5 guys, it makes sense to spend time finding the best guys.
You can also try to find 15-20 decent guys, but there are benefits to smaller teams — lower communication cost, a potential compounding effect when smart people work together, etc…
I don't know the details, but to your and latchkey's point, I think the reason they support these SDKs (in addition to their generic Graph API) is that they're consumers of those SDKs. They have an iPhone app, an Android app, use JavaScript and probably the PHP SDK for internal stuff. So they're just making these public since they're good enough for internal use.
They could probably easily hire a Python coder to maintain a Python API (and Ruby, or whatever language), but it would be unrelated to the main work they're doing and probably lag behind since those languages are either little used or not used at all in house.
I think this might be overly optimistic. Really smart people can also have really large egos and no patience for common courtesy. When they're sure of something, they have no problem calling someone out on it.
I didn't vote you down, but people are probably considering the difference between design and aesthetics/taste. Design should be a solution to a problem.
In this case, the problem as defined is readability. Having lines of text one after the other with no leading (line-spacing) can be difficult to read.
Having text that's too wide requires you to turn your head which can be uncomfortable.
Text that's too small can be... too small. The article was arguing for an optimal font size which may or may not be correct, but the argument was that 16pt/72dpi font is effectively the same size as most printed books, which are optimized for reading.
Text with poor contrast — light gray on gray is going to be difficult to read no matter the subject matter.
His individual arguments may be wrong (although I don't think they are), but the scope of design, for a given problem can be more absolute than just taste or aesthetics.
Taste is more about liking 10pt fonts even if you're designing for something to be readable.
I think one of the key words here that the OP didn't use was "for." I.e. he never said "I live for the present."
Rather, I think the word he was going for (correct me if I'm wrong) was "in." I.e. "Live in the present moment." Don't live in the past, don't live in the future, etc...
And that to truly live in the present moment, you have to take the wisdom of the past, and consider the weight your actions will hold in the future, but ultimately all you have is now. So I don't think what you said goes against what the OP said, it just highlights a different aspect. The past was lived, the future will be lived, but your decisions will be most important when they happen. You're not living if you're stuck in the past or displacing the present for some hazy future (a young investment banker working 100 hours a week for...).
Also, there are "present" qualities in all the examples you gave. Assistive brain/spine implants improves the present moment living conditions of other humans. We can use programming and the skills we have to build tools that help people better live their lives.
Also, things like love and other people are strongest in the present moment. Ultimately we likely invest and we study because so that we can make ourselves happy or search outside of ourselves, but a lot of times it's a lot closer (both physically and temporally) than we might think.
It depends on who you're working for (how top-down or bottom-up the company is) and how autonomous you are. Doing things cheaply and quickly, even in a web startup is shortsighted. Sometimes you have to spend money to make money. Sometimes big, interesting projects take time (think IBM developing Watson). I'm not discounting agile methods — the things you choose to do should be done efficiently, but they shouldn't be done poorly.
Perhaps I don't disagree with your comment that "most" developers have to do things cheaply and quickly, but I think most anyone has ability to speak up in their environment and push for the changes they think are important. I've worked at a big, sprawling company and was still able to work against the grain and push back on requirements and things I didn't think made sense. I'm working at a company now where I can do the same things (this time with less pushback).
If you change your perspective from controlling your job or your company to controlling yourself and your career, then it makes it easier to pull back and make the decisions that make sense for you and the things you want to work on. Then the places you work at are just the vessels and opportunities to turn your ideas into reality. The onus is on you to determine your career — not your company's.
Depends whether you're innovating in the frontend or the backend. The user interface for the iPhone was completely designed before any of the frontend was coded. There's a great comment by tlrobinson somewhere about how the iPhone was designed and developed but I can't seem to find it.
Also consider New Twitter. I don't understand how you'd start coding the HTML and the JavaScript without understanding the visual design for how the dynamic, two-pane interface was expected to work.
But if you're building a search engine, then you can probably put off the design until later. The analog is that you really wouldn't (or shouldn't) start writing code until you had an idea (a design or an architecture) of what you were trying to write. Same way you wouldn't start to code an interaction (HTML+JavaScript+CSS) if you had no idea what that interaction looked like.
Your resume usually serves two different audiences — the screener, and the person interviewing you. You should optimize for both audiences, and possibly work on breaking up "Skills" a bit. Your resume should be scannable, and most of the English before the important info can probably be dropped:
Developing applications leveraging
Parsing, querying, scraping, and transforming
Object-Oriented Programming with
Worked with and developed for
You're mixing technologies with programming languages with disciplines with applications. I prefer just seeing:
Programming languages (fluent): C#, Java, and VB.NET
Programming languages (studied): C, C++, VBA, VB6, classic ASP
Disciplines: Database administration, GIS programming, unit testing, mobile development
IDEs: Eclipse, Visual Studios
I might just drop things like Eclipse, Firebug.
--
Re: experience. In general you want to highlight the things that are different. In particular seeing "VB.NET Programmer" and "C# Programmer" over and over isn't illuminating. I want to know the places you've worked, so swap the company and position, and put the company and bold. You're working at Amazon which looks fantastic. So that should stand out.
Similarly in your projects, "URL:" is redundant and not the piece of data that's changing. Drop it and put the project names in bold instead.
Formatting things:
In education, the list of classes don't need to be on separate lines.
The choice of green checkmarks is a little strange. Simple dots might work better.
The blue subheadings don't line up with the text, which is distracting.
Are you copyrighting your design or the resume? Either way it seems unnecessary.
In addition to my normal commit and mailing filters, I set up one filter called "Non-direct" that's effectively "something that's not addressed directly to me and doesn't fall under any other filter." That means that the only things that show up in my inbox are emails directly relevant to me.
It turns out I only get around 5 personal e-mails a day out of the 100+ I actually get. Which could be read either way :).