I didn’t read much this week, due to a project I’m working on that I’ll write more about soon. One evening, I sat down to work through a couple things that popped up, thoguh.

A plea for product engineers

Link: on BuiltIn

Author: Meriam Kharbat

This article makes a call for “product engineers,” or developers with a strong understanding of the business. When asked to do something, they’ll break down the request to try to understand the underlying problem. This doesn’t have to be a job description, either; product engineers can be garden variety software engineers with a knack for product.

Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context and they are able to leverage technology to figure out the best solution to the problem.

Including engineers in the product decisions being made is important for this goal. The author writes that if the first time engineers see a product idea is during sprint planning, then the company has failed to empower engineers in this way.

This is a great quote, too:

In my experience, software projects that fail proceed similarly: The product owner wants to build a particular solution without explicitly identifying the problem they are trying to solve.

This has happened at my current company, too. I work on a research team, and our largest barrier to producing something concrete is the inability to articulate the product problems we’re facing. Sure, we can build new methodologies, but without being able to collaborate with our “product teams,” or understanding what problems our products and customers have, it’s impossible to get anything out.

Programming is not a goal

Author*: Roberto Alsina

This blog post breaks down this feeling that beginners might have—or at least that I certainly did—of being stuck in a loop of toy problems and basic assignments. The reason, the author claims, is because programming itself isn’t the goal; solving problems is.

To get out of this loop, sit down and build something real. Get stuck, ask for help, work through the problems, and learn as you go. Building something that you one personally finds interesting is the best way to grow.

The author was quite argumentative on Reddit, and while I certainly disagree with a lot of his opinions, there is truth to this post. There’s a part of it that resonates with me, and I’ll try to unpack it below.

This resonates with me greatly. When I think of the projects I’ve worked on, the projects that stand out are:

  • when I studied my college sleep habits using data from my Fitbit
  • when I asked how political polarization changed on Twitter in 2017, when Trump fired the FBI director James Comey
  • when I build Chrome extensions for a problem I faced at work and for improving / my / experience on a website that I play

What don’t stand out are any Kaggle competition, the association rules / basket analysis that I completed for a class, implementing collaborative filtering on the MovieLens dataset, any time I closely followed a tutorial, or 90% of the projects that I did for classes.

That’s not to say that those aren’t useful; learning the basics of a technology are important, and tutorials are still great resources. And if those are still interesting, and if I’m still learning, then by all means I’ll keep doing them. But when I felt stuck, building something new is what helped me get past that feeling.

This, incidentally, is also what I give as advice to people trying to get into data science. By all means, learn the basics: do the Titanic competition to see what some of the landscape looks like. Read other people’s analyses and study their code. Go through Elements of Statistical Learning and study common algorithms. You have to start somewhere!

But where it gets most interesting is when you think about a question you have, and try to answer it. (Note that asking good questions is itself a skill to develop.) Maybe that’s through machine learning. Maybe the hardest part is collecting the data. Maybe your question needs you to make predictions in real time, or build a website to show off the results.

The goal doesn’t even have to be to finish it: learning how to attack new problems or interesting questions is valuable, too. The best projects to do, I think, are the ones that you find most interesting.

Other reads

Things I wish more developers knew about databases is a Medium article breaking down some assumptions and commonly-held beliefs that developers have about databases. That ACID has different meanings, that UUIDs can be better than autoincrementing (when locks are expensive or otherwise challenging), that stale data can be useful (because, by definition, it doesn’t change), and that time consistency is a very hard problem are some of the highlights. It’s quite detailed, and though a lot is over my head, I can tell it is high quality.


Spotify’s Failed #SquadGoals is a post describing how Spotify’s aspirational organization structure—of having cross-functional, mini-startup “squads” and other unconventional structures—failed them. Spotify itself no longer follows it, and it never fully worked for them, the author writes. Yet companies aim to adopt it without realizing that (1) solving the problems that this model attempts to solve (which are themselves poorly defined) requires engineering and organizational culture changes, and not just a neat-looking org structure, and (2) that collaboration is a skill to be practiced, not necessarily a basic competency.

Note that I used Firefox’s Reader Mode to get past the abhorrent website design. I’m glad that I did, as the author calls out that there are no quick fixes and that organizational structure is a really hard problem. It’s a thoughtful criticism of how the fabled Spotify Model fails, and how companies jumping to adopt it are often misguided.