synotic
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.
Google WiFi Beats Eero, Luma
Gmail will now support CSS media queries
http://techcrunch.com/2016/04/11/lytro-cinema-is-giving-film...
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 haven't watched the shorter version, but someone edited they key points down to 18 minutes: https://www.youtube.com/watch?v=rvw68sLlfF8
The Talk Show: Live from WWDC 2015 with Phil Schiller
A video of Tom Parsey talking about Yahoo! and design: http://vimeo.com/61682055
The Disappearing Package — Experimental Package Design
https://developers.facebook.com/docs/opengraphprotocol/
under "Domain Insights."
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…
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.
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.
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.
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.
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.
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 :).
Re: refactoring and other comments. Of course optimizing and re-working your code for new use cases and scale issues is critical to support your product, but unless people are using it, you're not going to know what those use cases are and what parts of your product you need to scale.
There's a difference between "I support this product and you should check them out" and "click on these ads." Google's ads are targeted and beyond them being about sailing, he doesn't necessarily know what's being shown.
So it's pretty difficult for him to personally recommend particular ads or companies. I'd like to see the exact messaging he sent to his subscribers.