Open Questions (on tech, growth, and life..well, not life)

I'm back! After months of ignoring this blog, I'm ready to re-commit myself to the frustration of staring at a white screen. Ready to introspect and navigate my thought-space, searching for topics I care deeply enough to pound on a keyboard for. I'm ready to feel my eyes glaze over as I come to the one rational explanation: I'm a boring, knowledge-less, vacuum of a human being. So, full disclosure, this blog post is a result of one such depression session. Upon realizing that I know nothing, I've decided to ask the community some of my many questions.

Question 1: How can React be so powerful and intuitive while Flux just...isn't

Consider the following simple set of React components:

const TodoListRow = React.createClass({
  render: function() { 
    return <div>{this.props.value}</div>
})

const TodoListBody = React.createClass({
  render: function() { 
    var rows = this.props.items.map(function(item) { 
      return <TodoListRow value={item} />
    });

    return (
      <div>
        {rows}
      </div>
    )
  }
})

// show the currently selected todo list item
const TodoListHeader = React.createClass({
  render: function() {
    return <h1>{this.props.item}</h1>
  }
})

const TodoList = React.createClass({
  getInitialState: function() {
    return {selected: ""}
  },

  render: function() {
    var items = ['get a job', 'dont eat soap', 'try not to be the worst']

    return (
      <div>
        <TodoListBody items={items} />
        <TodoListHeader item={this.state.selected} />
      </div>  
    ) 
  }
});

Ah, the perennial 'TodoList'. Ubiquitous, unoriginal, precursor to many an uninteresting example, and now our subject of study. Now, the basic React way of updating the header to stay in sync with the selected list item could be accomplished via callback like so:

const TodoListRow = React.createClass({
  onSelected: function() {
    this.props.onClick(this.props.value);
  },

  render: function() { 
    return <div onClick={this.onSelected}>{this.props.value}</div>
})

const TodoListBody = React.createClass({
  render: function() { 
    var rows = this.props.items.map(function(item) { 
      return <TodoListRow value={item} onClick={this.props.onClick} />
    }.bind(this));

    return (
      <div>
        {rows}
      </div>
    )
  }
})

// show the currently selected todo list item
const TodoListHeader = React.createClass({
  render: function() {
    return <h1>{this.props.item}</h1>
  }
})

const TodoList = React.createClass({
  getInitialState: function() {
    return {selected: ""}
  },

  onItemSelected: function(item) {
    this.setState({selected: item});
  },

  render: function() {
    var items = ['get a job', 'dont eat soap', 'try not to be the worst']

    return (
      <div>
        <TodoListBody items={items} onClick={this.onItemSelected} />
        <TodoListHeader item={this.state.selected} />
      </div>  
    ) 
  }
});

But why do I feel inexplicably...dirty...after writing that? Well, with deeply nested components or components tracking multiple event types, this process feels deeply and personally repetitive. It feels like the opposite of DRY, or YRD (You're Repeating, Dumbass). Enter Flux, the answer to inter-component communication.

While in theory Flux brings some much needed Backbone (<- eh?) to the View heavy React, it drags with it some topics that seem ambiguous at best and vestigial at worst. Here's the basic structure of a Flux application.

Actions, Dispatchers, Stores...wut

For most MVC programmers the "Store" and "View" components of this model should feel familiar. As for the "Action" and "Dispatcher" components, presumably these together comprise the controller. So far so good. However, this is where things take a turn for the worst. Rather than fold the Action, Dispatcher, and Store into a library then calling into these abstractions in our React views, these components are instead left as abstract interfaces, requiring implementation by anyone wishing to use them. Don't believe me? Check out the Todo example given by Flux here (simple fiddle here) and compare it to it's knockout and angular counterparts. To me, the most immediately obvious difference between the three is the relative lack of clarity found in the Flux variation.

Now, I know the naysayers will respond with the (fair) argument that Flux explicitly states it is not a framework, but rather an architecture for building applications. To this I respond: I know that dummy! But, Flux really ought to be a framework in the same way that Angular, Knockout, and the multitude of other JS frameworks are. Javascript development is such that uniformity, conciseness, and best practice should rule paramount, all things provided by a good framework. Without these tenants, Javascript has a particular propensity for dissolving into a formless goo.

Open Question
What am I doing wrong? Why does Flux feel so awkward and how should I be using it better?

After a day learning Flux

Question 2: Why is Adwords so skewed to favor big spenders?

This one in particular really grinds my gears.

Obligatory

Truly, organic results are one thing (of course it should take time to build an organic profile, seeing as people trust names they recognize, therefore they're more likely to click on recognizable names, therefore the most relevant results should be the most recognizable) and paid results are another. That distinction made, how can a young company hope to compete in the heavy-hitting world of PPC while monstrous enterprises are freely allowed to throw money at the problem?

Yes, before the torches come out and the crowd pulls out their pitchforks, I know what long-tail marketing is. I know these results are a viable target for PPC due to their relatively low CPC and sparser bid landscape. But, and there is a big but, for a company that needs to grow - and do so quickly - settling for .5, 1, or 2% of traffic as the titans devour the remaining 98% just doesn't cut it.

So what's my proposed solution? That's a damn good question. Perhaps in order to answer that question, it's important to first consider what Adwords must deem relevant when deciding which ads to serve. Presumably the 3 factors that matter most when deciding Ad visibility are:

1. Bid price. This is the easy one and most easily exploited by the giants.
2. Session / Bounce rate and time on site. What percent of people click through and then bounce? How long is the average visitor session upon click through?
3. Device type + site compatibility. Is the user navigating on a mobile device? If so, is the site mobile friendly?

Phew, glad we got that out of the way. So those points laid out, what would I propose as a way to counteract Adwords monopoly by larger companies? The answer is actually quite simple: Provide a heavier weight to points (2) and (3) than (1). Now, I have no doubt there is some weight already placed on these items, however it is my opinion that the order of preference currently goes (1), (2), (3) where it really ought to be (2), (3), (1). C'mon Google, give the little guy a chance.

Open Question

For the companies that aren't Amazon, how do you compete on Adwords? What does your ROAS look like and what have you done to evolve your ad spend technique?

Question 3: When will demand for engineers be outpaced by job seekers seeing the wealth of opportunity in tech?

I have this "friend" let's call John. John has worked in tech as a web and Android developer since he graduated from a respectable university with a Computer Science degree 2 years ago. Many of John's friends have had trouble finding jobs since graduation. Of John's friends that have found jobs, most of those jobs pay well below John's. John isn't an idiot, so John wonders: How can this trend possibly continue? At what point will undergraduates and their parents, seeing the difficulty obtaining a job upon graduation, flock to engineering tracks? Has this process already started?

Open Question

How many switched jobs explicitly to exploit the current demand for engineers? How much worry is there that the market will quickly be saturated by new graduates / industry switchers, thereby making the process of getting an engineering job much more competitive (specifically in tech)?

So people, looks like you have your work cut out for you. If you have answers to any of these questions or want to pose your own, comment below or shoot me an email at steinbach.rj@gmail.com.