zacman85

I mean what I said when I use the term Front-End Engineer. The people who have built the parts of YouTube that you touch on a daily basis fit very nicely within the traits I have outlined and I would most certainly call them engineers through-and-through. They sometimes have to design elements on a page. They sometimes have to code back-end services and infrastructure. They have to run the gamut between the disciplines of web design and computer science on a daily basis. I would NOT say that Google lacks respect for web design. I am saying that finding people who are hybrids of web design and computer science IS extremely challenging, even for Google.

Yes. This is exactly what I intended. Thank you for clarifying.

If I had been more definitive, I would risk making the same mistakes that the people who inspired this article were making. That is, to rigidly define what a front-end engineer is in terms of completely arbitrary constraints. I wanted to provide a set of commonalities that I have found through my experiences, but not to explicitly say "this is what a front-end engineer has to be." A good front-end engineer can come from ANYWHERE and I state that by saying that there are clearly going to be exceptions to whatever I write.

While I understand your point, I feel like mine was missed. Perhaps I should have worded it differently. The fact is, the web is a constantly evolving ecosystem that as a front-end engineer, you do not get much control over. Yes of course the code YOU produce should be predictable and stable and so forth. However, at any time, the rug can be pulled out from underneath you by a browser update, the uptake of a particular device (e.g. iPhone), etc. When you are working on a website where the WebKit nightlies compose more of your traffic per day than most of the sites on the rest of the Internet get in their lifetime, you have to be extremely flexible in your interpretation of what a successful feature looks like when applied across the board. I do not feel that one faces this same level of constant uncertainty in backend environments where the engineers have much more say in what is running their software.

Inspired by: probably. Stolen: absolutely not.

Someone mentioned a while back about using distributed Javascript to generate Mandelbrot sets. This was something I built sometime last year when I messing around with the idea. Please note, I misspelled "Mandelbrot" in the AppEngine name and then could not figure out how to change it.

I understand you are right in the context of today. A few years from now, however, I would imagine that gains in the efficiency of the business model as well as competitive pressures will drive prices down below the costs of running your own infrastructure.

It is hard for me to even imagine what the world was like before Amazon Web Services, despite having only used them for half of a year. I truly hope Amazon is making ungodly sums of money with this increasingly powerful platform. Why Google is laser-focused on social and local, yet letting Amazon eat their lunch in this space is beyond me. I know Google has AppEngine and Storage, but they seem to be lacking the full-featured, cohesive collection of cloud services that Amazon has so clearly invested themselves in. I truly wonder if we will wake up five years from now and the vast majority of the web will be running on Amazon infrastructure.

Think and Grow Rich - Napoleon Hill

It is owned by the Boy Scouts. You pay 5 dollars at the bike shop to get a day pass that you put on your bike.

If you are into mountain biking, there's a fun trail up in Fairfax (five minutes north of Golden Gate Bridge) called Tamarancho (approx. 11 miles). I'd be down for heading up there with a few people on Sunday if people are interested. There's a place to rent mountain bikes right at the base of the trail.

I have started working on something similar. I have 3-4 ideas of apps I would like to do. I figure it would be far easier and way cheaper to launch landing pages for each, with mocked up "screenshots" of the apps. I plan to include on each of the apps a form to provide your email address in exchange for an invite. Then, I would do some simple SEO and word-of-mouth marketing and see what kind of response rates I would get back through this form. I figure in the end, this would help identify which application has the lowest barrier to adoption (e.g. easier discoverability, more user interest).

I think there are blind spots in this argument. The web will never be a stable environment. The technologies that have afforded its existence are notably fluid, and often leaky. These are characteristics that do not fit standard computer science.

To engineers who are accustomed to rigid runtimes, compilers, and so forth, this opinion that HTML is object code will resonate. However, it makes the assumption that by abstracting away the underlying HTML, you stand a better chance of delivering your program to the intended audience. I don't believe this is the case.

If you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create, and leverage this accordingly, you will write code that will more easily adapt to best fit the environment in which it is run.

The power of web technologies is their resiliency. Programs written in compiled or runtime-based languages either run or they fail. Web code is much more dynamic. We should appreciate this characteristic, even when faced the frustrations of immature, misimplemented, and unsupported standards.

One goal means you have no choice in what you are focusing on. At least with two goals, I can pick the better of the two to fit a specific mood or situation I am in (e.g. maker's versus manager's time per Paul's recent essay).

Not arbitrary per se. I like having two goals because then I can directly compare the goals when making a decision on what to try to accomplish. It becomes an either-or decision. If I am in the mood to complete something quickly, I can look at both goals and pick the one with the shorter time investment. I actively try to position goals against each other so that they help me stay balanced (e.g. one goal is fitness related, one goal is work related). Having 3 goals tends to introduce too many points of comparison for me.