waffleau's comments

I spent a lot of my career trying to find roles where I didn't have to deal with people. A lot of time in startups and small businesses, where my job was to just build. At a certain point, there weren't that many new technical problems I was running into, so I decided to work on team-building skills. Over the past few years, I've been managing engineering departments, something I never though I would do.

It's usually people. Sometimes it's opportunity. But it's usually people.

I've ended up with a lot of thoughts on the topic, but I'm not sure how best to convey them, so I'm doing to rant in dot points:

- People rarely leave because of technical decisions. Most people are appeased when you can explain the rationale, even if they disagree

- Good leaders make or break an organisation. They inspire people, they give them a cause to rally behind. A lack of good leaders will kill culture within a year

- Good leaders own problems and will find a way to solve them, they won't accept the status quo

- Bad leaders will tell you why a problem is not their fault, and do nothing to fix it

- Good leaders need good leaders - it starts at the top. A good CEO will change your worldview

- Good leaders-of-leaders know everything is kind of fucked, and appreciate leaders who are actually trying to improve things, without expecting they're going to get everything right

- Leaders need to really believe in their cause. People know when you're faking it

- Culture is not a by-product. It's the product. You work hard to create a good culture, and it can disappear very quickly. Building good culture is how you build good teams. You can't work around a bad culture

- Most of being a good leader is just turning up. Be there for your people, listen to them, try to make their lives better. Make time for them. Show them you care

- Regardless of all of this, people will leave. Sometimes because the company isn't a good fit, sometimes because they're at a different point in their career. Attrition is healthy, you just need to keep a pulse on whether it's happening for unhealthy reasons

In summary: yes, it's pretty much always people. Building software is easy. Building a healthy work environment is hard. Most people focus on the easy problem.

It definitely requires more work. If you're starting from scratch, you need to either read the API documentation or makes calls to the API to understand the data you're getting back. You then need to build correctly typed data models that match what you're expecting the API to give you. There's plenty of room to make mistakes as it's a manual process.

With GraphQL you can take the schema file from the server and use it to generate your data models. You get the data models for free, everything is correctly typed, and as long as the schema you're using is up to date you have a guarantee on correctness. It also makes finding changes to the schema easier in the future, as you can effectively do a diff.

We also use GraphQL on web (the exact same API as mobile) but we don't realise nearly as many of these benefits. This is probably in part because we haven't invested a lot in tooling, but also the team that maintains the API also maintains the web product, so some of the discoverability benefits of Graph aren't as valuable.

I didn't choose to adopt GraphQL, but I joined a company where an ex-developer had integrated into what was at that point a core codebase. They didn't add it due to any particular merit, they just wanted to play with shiny new technology. The codebase also had REST endpoints, but GraphQL made up the majority of the API, so we decided to just run with it and deprecate REST. At the time the decision we made was arbitrary.

This turned out in retrospect to be a good call. The primary consumers of the API were a set of Android and iOS apps, and integrating GraphQL into mobile apps is a pleasant experience. You can generate your data models from the graph schema. Tools like GraphiQL allow developers to explore and play with your API, substantially reducing the amount of documentation needed. The mobile team much preferred working with GraphQL over REST.

On the backend, GraphQL has a bit of a learning curve. The resolver pattern is powerful once you understand how to use it properly, but also easy to misuse. The most common source of problems is developers not understanding Graph's batch resolution mechanism. Developers accustomed to building REST APIs rely on preloading data, which is the wrong approach when dealing with GraphQL.

As a simple example, maybe you initially build a Graph query where you load comments like this:

  query Comments {
    user {
      posts {
        comments {
          message
        }
      }
    }
  }

But later on, you decide you want to allow a user to load their comment history directly:

  query Comments {
    user {
      comments {
        message
      }
    }
  }

In the first example, an equivalent REST API might load comments via something like posts.preload(:comments), and when the second query is built you'd use user.preload(:comments). But the way to solve this problem in Graph is batch resolution - get a list of comment IDs you want to load, then call Comment.where(id: comments_ids). Your comment loading is now context agnostic.

Another related problem is that it is easy to create N+1 queries. This also stems from a misunderstanding of batch resolution - reusing the above example it would be the equivalent of calling Comment.find(comment_id) for each ID instead of Comment.where(id: comments_ids). My first few months working with Graph were often spent fixing N+1 queries. As much as I try to explain this problem to new developers, it's one of those things that doesn't click for them until they cause the problem and end up having to fix it.

Once you understand GraphQL it's a nice technology to work with. In the early stages it can be fairly easy to shoot yourself in the foot, you just need to build up enough knowledge to avoid the common pitfalls. In general, GraphQL APIs are harder to build than REST APIs (mostly because REST is the default for most frameworks). If I had to start a new project today, my decision on whether to use GraphQL would be be determined by questions such as:

  1. How much control do I have over the clients
  2. Are the primary consumers native mobile applications 
  3. Is flexibility important
  4. Will API documentation be required

Hacker News has a pretty well educated community, so it's not surprising that the general response seems to be that this was an obvious outcome. But this story is not unique to this woman. There are a huge number of people that seem to be in the same situation, and it's dismissive to just say that people should be more educated.

People aren't rational agents. They suck at making decisions about their long term well being. They're told that the best way to support their future is to go to university, so they take out a loan under the assumption that once they're finished, they'll earn so much that paying it off won't be an issue. And if you're not particularly financially literate, you might assume that this is fine since everyone else seems to be doing it. And you might also assume that they wouldn't lend you money that you couldn't repay.

The reality is there's an information asymmetry in favour of lenders. They know better than you how likely you are to repay your debt. And their incentives are structured to maximise their return, not clear your debt. So if the best way for them to make money is for you to not be able to pay off your debt, that's what they'll try to do. The harder it is for you to understand what you're getting into, the better for them. The less financial literacy you possess, the better for them.

I'm not arguing that the author shouldn't bear responsibility for her decisions. Of course people should understand the things that they agree to and meet their obligations. But there is a calibration problem when the pursuit of an education can lead to three decades of financial hardship.

From a historical perspective your reservation is totally fair. But I think the issue is a lot more complex than just looking at the impact automation has had in the past. Here are a few points worth mulling over:

1. Automation in the past has been good at increasing worker productivity, and making new avenues of work possible. This is true going forward too. But each new generation of technology isn't "something we've seen before", it's a new thing with new consequences. Technological development isn't cyclical, so estimating the impact a new technology will have on the impact previous technologies have had is a poor model. This isn't to say the consequences will be bad, just that they're hard to anticipate. For the most part, the historical perspective is probably right though.

2. Automation in the past has been very effective in improving worker productivity, but developments in AI and robotics are looking at ways to supplant workers (i.e. electric cars don't improve our ability to drive, it removes our need for drivers). While in the broad sense this trend is good, and people will over time shift into new industries, it is going to be disruptive. Timelines will have a big impact on the shock. New industries won't spring up over night.

3. The timeline for this level of automation is much shorter than previous automation trends. The shift in agriculture happened over generations. The shift caused by driverless cars will likely happen in less than a decade. Add to that the efficiency of market pressures we have today - once one business is able to shift entirely to an autonomous fleet and save money over their competitors, all their competitors will have to follow suite to remain competitive. Entire industries could be displaced, and those workers will need to move somewhere.

4. This is more hypothetical and longer term, but it gets at what I think is the general fear around automation. Imagine we develop the ability to automate any unskilled job (whether through broad automation improvements or development of an actual general-purpose automaton). The primary factor in whether a business would choose to employ that automaton over a human is cost. The automaton is a once-off fixed cost, whereas a human is an ongoing cost. Once the cost of the automation is lower than paying a salary, humans will no longer be employed in that role.

5. Following from this, if it's the unskilled jobs that get automated, where do those workers go? At this stage, even if automation is creating new lines of work, why wouldn't that work also be automated? Basically, once we automate unskilled work, we never need unskilled workers again. In order to find work they'll need to skill up, which takes time and money. And if it takes a year to train a worker to a level that they're a net benefit, why not invest that money instead into automating the skilled work too?

This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong. Separation of concerns refers to responsibilities, not languages.

If you're building a static website, sure, you probably don't need React - the old tools and techniques handle that use case well. But if you're building a webapp, something with complex, dynamic client-side behaviour, it doesn't make sense to pretend that CSS, HTML and JS aren't already heavily coupled by the nature of what you're building. React just embraces that idea, rather than pretending it doesn't exist.

The reality of modern apps is that JS is going to transform your HTML and CSS at runtime, and most of the bugs you'll end up tracking down will be related to it being transformed in ways you weren't expecting. React's component model and declarative rendering are far more effective at addressing this problem than any other tool I've tried.

The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.

https://flowtype.org

Coming from a startup background:

1. Senior people leaving (as has been said by pretty much everyone else in this thread).

2. Not having a clearly defined problem to solve, or a well understood target audience.

3. Not knowing who the competition are, or just dismissing them as "not being as amazing as us."

4. Little or no customer research - if you hear the phrase "customers don't know what they want" and it's not immediately followed by "so we need to do research and find out" - run.

5. Building solutions that don't really map back to problems. This can manifest in a lot of ways, but the most common ones I've seen: projects constantly changing in priority (entire projects materialise and become urgent overnight), features that are arbitrarily demanded, or in an over-emphasis on polish and minutia.

6. Departments not collaborating, things getting thrown over the fence. Workflows that move in the wrong direction.

7. Lack of autonomy - a handful of people make all of the decisions.

8. Micromanagement. People tend to micromanage when things aren't going well, which tends to make them worse. It's a downward spiral.

9. Being afraid to talk to management about problems; being chastised for suggesting ways to improve things.

10. When mistakes are made, focusing on blame rather than resolution and prevention.

This is something that tripped me up when I first started learning Redux too, and it would be great if there were more articles about what to do with the bits that don't really fit nicely into the model.

My personal take is that the Redux state tree is for managing state that other components care about, i.e. if this changes, does something outside of this need to know? In the form example, there are few cases where we care about what is being typed as it is being typed (maybe autocomplete). We generally only care about the complete input. This could even be taken to the next level and we could say we only really care about the contents of a form once it has been submitted.

To think about it another way,: what state would we like to keep if the page was refreshed? Many UI elements may contain state we don't really care about outside of the component, such as drop-down menus, accordions, etc. There are things which constitute global state, and there are things that really are just local state. Why make them global?

Ultimately, the goal of Redux is to make reasoning about the state of an application easier, and to encourage better architecture. If pushing certain bits of state into the tree makes this harder, there's no reason to try to force it to fit the pattern.

I'm sure there are good arguments for why everything should be in the global state, but I just haven't found it to be practically beneficial.