DEV Community: Kyle Pollich

Software Engineering Jobs: Product Teams vs Agencies

Kyle Pollich — Thu, 20 Dec 2018 16:56:22 +0000

Photo by Shridhar Gupta on Unsplash

In the software engineering industry, it's common to divide jobs into two broad classifications: product and agency. A product job involves working for a company who sells or actively develops some software product that's consumed by end users. The company owns the product, and the product in some way contributes to the company's bottom line. An agency job, conversely, involves working on a contractual basis for a multitude of clients. A development agency might specialize in a few smaller markets, but typically the work load is more broad and is spread across a number of clients.

Each of these classifications comes with its own set of benefits and detriments, of course, and you'll find developers that prefer one over the other. It can be hard to know exactly what each kind of job entails without a large amount of experience on both sides of the divide, but let's break down some key pros and cons for product and agency jobs.

Product Companies

Pros

Identity and Ownership

Because product teams focus on delivering core business functionality and impacting the company's bottom line, they typically encourage a strong sense of team identity and product ownership. It's easier to feel connected to the software you're building when there's a clear sense of how it impacts the company for which you work. Product teams are also typically more visible and in closer communication with core business stakeholders. Being closer to the "product owners" allows engineers a clearer vision of how their solutions further the mission of the company.

Stability

Product teams offer an environment with less variation than most agency jobs. Because there's one core product or business identity, there's less variation in the categorization of the solutions and products the engineers build. For example, a SaaS company that sells marketing and advertising software is typically going to create software solutions related to marketing and advertising software. There's less room for context shifts with product teams, and engineers are able to retain and transfer industry knowledge between teams and products.

Cons

Stagnation

Although some product companies encourage moving around between teams or projects, it's not always feasible for every engineer. A lot of engineers will work on a single project year after year for most of their tenure at a product company. To some degree, this affords the engineers stability as mentioned above. However, it's easy to fall into a rut and to feel stifled without a dynamic environment.

Legacy Code

Along with personal stagnation, product companies own their codebases for as long as they exist. This means, as an engineer, you'll likely be maintaining code that was written previously by current or former engineers from the company. "Legacy Code" can sometimes be misrepresented as a four letter word in the software engineering world - it's not always bad. There are plenty of well maintained, well documented "legacy" code bases serving enormous user bases across the world. That being said, there are just many spaghetti codebases without tests. Your mileage may vary here, but know that at a product company you will likely be inheriting at least some code.

A Static Stack

Since product companies have full ownership of their technology, the stack and solution architecture tend to be somewhat set in stone. A good product company will always strive to find the right tool for the job, but there will likely be less room for tinkering and working with bleeding edge technology. Whether this is truly a con might be subjective. Some developers lament "fatigue" and early adoption of new technology, but others relish in the opportunity to work on the cutting edge.

Agencies

Pros

Fast paced, dynamic environment

Agencies tend to work a lot faster than average product companies. When companies contract out work, they're typically looking for shorter implementation timelines in order to minimize their risk. Because of this, projects tends to move a lot faster. If you're someone who can be annoyed by overbearing working processes, meetings, and red tape, this might be a selling point for agency work.

Freedom of exploration and experimentation

Where product companies typically hold at least some loyalty to a specific toolchain or technology stack, agencies can be more willing to experiment and explore multiple technology options. Unless the agency is highly specialized (e.g a WordPress shop or a Rails consultancy), the technology choices will typically be more tailored to individual clients and projects, and so you might be exposed to a wider variety of technologies.

Cons

Difficulties with ownership

Since agencies work on a contractual basis, projects have a set end date. When projects are over, development stops. Some agencies will take on longer term maintenance work after a project's delivery, but this maintenance work is frequently contracted to another, often offshore, company instead. It can be hard to find a sense of ownership and pride in a project that will be handed off in the relatively near future.

Shorter timelines, tighter budgets

Another issue with contractual work is a more fixed budget - in terms of time and money. When projects have a concrete delivery date, it can lead to crunch time and overwork. A good agency with an effective working process won't run into these issues, but the environment around fixed budget and fixed timeline projects can be more conducive to "death marches" as deadlines draw near. Look out for unpaid overtime, lofty promises, and unreachable deadlines.

There are developers that prefer product companies and there are developers that prefer agency work. I'd recommend working a job from each paradigm if possible throughout your career, as each environment has a lot to offer in terms of skillsets and experience.

This is not an exhaustive or definitive list! I know there are product companies with tons of room for internal research and development, and I know there are agencies with iron clad working processes and solid contract hand offs. These are just a few things I've noticed in my few years of experience, and some things I've heard from other developers.

I'd love to hear from the DEV community about your experiences with product and agency jobs, and which you prefer. Thanks!

Intro to Asynchronous Patterns in JavaScript

Kyle Pollich — Thu, 20 Dec 2018 02:41:26 +0000

A brief history of asynchronous programming in JavaScript

JavaScript is regularly referred to as "async by default", but the way in which async code is commonly handled has changed over JavaScript's lifetime. We've moved from callbacks to promises to async/await over the years, but each of these approaches in related to its predecessors in one way or another.

Asynchronous vs Synchronous

To begin, let's quickly make clear the difference between asynchronous and synchronous code. When code is synchronous, it's executed in "line order", meaning each task defined by your code is executed to completion before moving onto the next task. In JavaScript, that might mean something like this.

console.log("Hello world")

const name = "kyle";
console.log("It's me, " + name)

console.log("Some lovely code :)")

All of this code executes synchronously - each line is executed to completion before the program moves to the next line.

Asynchronous programming works in the opposite way though: the program moves to the next line before the previous line has executed to completion. We'll dig into some example throughout this post, but common cases involving asynchronous code are database connections, HTTP requests, and other instances where your program might have to wait for a response from some other source.

Here's a great StackOverflow answer that does a good ELI5 for the difference:

SYNCHRONOUS

You are in a queue to get a movie ticket. You cannot get one until everybody in front of you gets one, and the same applies to the people queued behind you.

ASYNCHRONOUS

You are in a restaurant with many other people. You order your food. Other people can also order their food, they don't have to wait for your food to be cooked and served to you before they can order. In the kitchen restaurant workers are continuously cooking, serving, and taking orders. People will get their food served as soon as it is cooked.

With (hopefully) a good baseline understanding of these programming concepts, let's dive into how JavaScript has handled asynchronous code throughout its lifetime as a programming language.

Callbacks

Callbacks are an essential concept in JavaScript and other asynchronous languages. Because JavaScript relies heavily on event and asynchronous processing, callbacks are core to the language. JavaScript implements higher order functions, meaning that functions can be stored in named variables and passed as arguments to other functions. A function passed as an argument to another function is typically referred to as a callback. Callbacks are the original and oldest way to handle async calls in JavaScript.

setTimeout is one of the simplest examples of a function that accepts a callback:

setTimeout(function () {
  console.log('It has been a second!')
}, 1000)

Here's an example of how you might implement your own method that accepts a callback:

function validateInput (input, callback) {
  var result = { errors: [] }

  if (!input.name || input.name.length < 6) {
    result.errors.push('Invalid name')
  }

  if (!input.email) {
    result.errors.push('Email must be provided')
  }

  callback(result)
}

validateInput({ name: 'Kyle', email: 'kyle@example.com' }, function (result) {
  if (result.errors.length) {
    console.error('Whoops')
  } else {
    console.log('Hooray')
  }
})

It's very easy to fall into "callback hell" when you have to chain several functions together that all accept callbacks. Consider some Node code where we connect to MySQL and use standard callbacks to run some queries that depend on return values from other queries.

var config = require('./config.json')
var mysql = require('mysql')

// Note: this is inefficient and bad on purpose to prove a point :)
function updateUserEmail (oldEmail, newEmail, callback) {
  var connection = mysql.createConnection(config)

  connection.connect()

  connection.query('SELECT id FROM users WHERE email = ?', [oldEmail], function (error, results) {
    if (error) {
      throw(error)
    }

    var userId = results[0].id

    connection.query('SELECT is_active FROM users WHERE user_id = ?', [userId], function (error, results) {
      if (error) {
        throw(error)
      }

      var isActive = results[0].is_active

      if (!isActive) {
        throw new Error('Error - user is inactive')
      }

      connection.query('UPDATE users SET email = ? WHERE id = ?', [newEmail, userId], function (error, results) {
        if (error) {
          throw(error)
        }

        if (results[0].affectedRows === 0) {
          throw new Error('Error - failed to update user')
        }

        connection.query('SELECT * FROM users WHERE id = ?' [userId], function (error, results) {
          if (error) {
            throw(error)
          }

          callback(results[0])
        })
      })
    }
  })

  connection.end()
}

try {
  updateUserEmail('kyle@example.com', 'kyle2@example.com', function(changedUser) {
    console.log(changedUser)
  })
} catch (error) {
  console.error(error)
}

Promises

A Promise is an object that represents the eventual result of an async operation. Promises can be resolved or rejected with values, and they're similar to Tasks or Futures in other languages like C# or Java.

We can instantiate a Promise with a constructor that takes a function like so

new Promise((resolve, reject) => {
  if (foo) {
    return resolve('foo')
  }

  reject('not foo')
})

Promises transition through three states: pending, fulfilled, and rejected. We can chain onto Promises to perform meaningful operations with the then method. The catch method is used to catch rejections.

somePromise(foo)
  .then(data => {
    console.log(data)
  })
  .catch(error => {
    console.error(error)
  })

Promises can be chained, and errors will "bubble up" to a single catch handler at the end, which makes them very powerful for reducing nesting and unifying your scope.

somePromise(foo)
  .then(data => {
    return transformData(data)
  })
  .then(newData => {
    if (newData.bar) {
      return logData(newData)
    }

    return logSomethingElse(newData)
  })
  .catch(error => {
    console.error(error)
  })

Promises are a powerful pattern for cleaning up callback-laden code. Here's the example with the MySQL calls from above rewritten with Promises.

const config = require('./config.json')
const mysql = require('mysql2/promise')

function updateUserEmail (oldEmail, newEmail ) {
  mysql.createConnection(config)
    .then(connection => connection.execute('SELECT id FROM users WHERE email = ?', [oldEmail])
    .then([{ id }] => {
      this.userId = id

      return connection.execute('SELECT is_active FROM users WHERE user_id = ?', [userId])
    })
    .then([{ is_active }] => {
      if (!is_active) {
        throw new Error('Error - user is inactive')
      }

      return connection.execute('UPDATE users SET email = ? WHERE id = ?', [newEmail. this.userId])
    })
    .then(() => connection.execute('SELECT * FROM users WHERE id = ?', [this.userId])
    .then([user] => user)
}

updateUserEmail('kyle@example.com', 'kyle2@example.com')
  .then(changedUser => console.log(changedUser))
  .catch(error => console.error(error))

Async/Await

Async/Await is a layer of syntactic sugar on top of Promises that eliminates another layer of nesting. By marking a function as async, we gain access to the await keyword. await lets us "unwrap" Promises inline, and treat pending Promises as if they were resolved sychronously. You can only await functions that return Promises. If you await a function that does not return a Promise, it's result will be wrapped in a Promise.resolve call.

// With a Promise
function getData() {
  return fetch('example.com/api/data')
    .then(body => body.json())
    .then(data => console.log(JSON.stringify(data)))
}

// With async/await
async function getData() {
  const body = await fetch('example.com/api/data')
  const data = await body.json()

  console.log(JSON.stringify(data))
}

Catching errors in async/await blocks is a matter of using JavaScript's standard try/catch construct. Similar to Promises, this error will "bubble up", so you only need one catch block for a given block of async code.

async function getData() {
  try {
    const body = await fetch('example.com/api/data')
    const data = await body.json()

    console.log(JSON.stringify(data))
  } catch (error) {
    console.error(error)
  }
}

Here's our MySQL example rewritten with async/await. By leveraging libraries and interfaces that return Promises (like MySQL2), you can wind up with some really concise async code.

const config = require('./config.json')
const mysql = require('mysql2/promise')

async function updateUserEmail (oldEmail, newEmail ) {
  const connection = await mysql.createConnection(config)

  const userId = (await connection.execute('SELECT id FROM users WHERE email = ?', [oldEmail]))[0].id

  const isActive = (await connection.execute('SELECT is_active FROM users WHERE user_id = ?', [userId])[0].is_active)

  await connection.execute('UPDATE users SET email = ? WHERE id = ?', [newEmail. userId])

  return (await connection.execute('SELECT * FROM users WHERE id = ?', [this.userId]))[0]
}

// You actually can't use `await` in the top level scope, so you'd need to put this
// into a separate  `async` function or something in the real world
try {
  const user = await updateUserEmail('kyle@example.com', 'kyle2@example.com')
  console.log(user)
} catch (error) {
  console.error(error)
}

And that's that! Now you've seen a few practical examples of asynchronous code and how JavaScript is equipped to handle these use cases. In modern JavaScript, it's helpful to have an understanding of each of these async patterns and how they relate to one another. async/await is definitely the most modern approach to async code, but you'll still run into plenty of callbacks, and having a good understanding of Promises is important to effectively utlize async/await.

DEV Community: Kyle Pollich

Software Engineering Jobs: Product Teams vs Agencies

Product Companies

Pros

Identity and Ownership

Stability

Cons

Stagnation

Legacy Code

A Static Stack

Agencies

Pros

Fast paced, dynamic environment

Freedom of exploration and experimentation

Cons

Difficulties with ownership

Shorter timelines, tighter budgets

Intro to Asynchronous Patterns in JavaScript

Asynchronous vs Synchronous

Callbacks

Promises

Async/Await

Further Reading