5 Questions Web Developers Always Need Answers For

Published on Apr 9, 2014 (updated Feb 5, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

This post is partially outdated.

In web development, just as in other fields, it can easily appear as if there are clear-cut solutions for everything. That’s at least the case for many of us neurotic perfectionists, as our world is built on clear-cut solutions. In more cases than one thinks there actually is a definite and also correct answer—still, alas, not in all.

There are some things that are often if not always variable. These we often if not always need to address anew. Here are some of these things, the ones I consider the most important higher level questions more senior developers need to have answers for. Some of them with every new client or employer, some of them with every project; some of them through inquiry, some of them through research.

What Are the Goals—for Company, Team, Project, Individual?
What Are Company and Team Like—Size, Composition, Culture, Geography?
How Good Are We—Company, Team, Individual?
Who Else Is Going to Work on the Project?
What’s the Probability for x?

1. What Are the Goals—for Company, Team, Project, Individual?

What are we doing, and for what purpose? Is this just a small side thing that’s going to be on life support the minute we’ve launched it? Or are we aiming for the stars, building something that should be considered a model for excellence, something we intend to show the world, and with that invite scrutiny? We need to have and we need to know our goals. It’s hard to hit a target if one doesn’t have one, and it’s hard to make smart decisions without a goal, either.

2. What Are Company and Team Like—Size, Composition, Culture, Geography?

The smaller the team, the more drastic changes may be. The more junior, the more hand-holding and the more guardrails are needed. The more ambitious, the easier to advocate quality. The more spread-out, the more discipline and process is necessary. &c. We need to know our team, and we need to base our course of action on our team. The same holds for the company, yet as web developers we’re more likely to engage on a team level.

3. How Good Are We—Company, Team, Individual?

We need to know our company’s but especially our team’s profile and strengths. Without knowing these we can’t work effectively. Having a rockstar designer on the team gives us more options on that front. On the other hand, having no Ruby specialist means no Ruby projects. Everyone copying and pasting code means we have to build our coding expertise, possibly from scratch. &c. Only through knowledge of our qualities can we compensate for weaknesses and tailor our services. And put effective policies in place, like coding guidelines.

4. Who Else Is Going to Work on the Project?

This one I believe to be the most underestimated factor in web development, though it’s not a real question. Or maybe it’s a trick question. The point here is, someone is always going to touch a project again. And be it to pull the plug. In “one man shows” that may be ourselves, but there’s always someone who’s going to touch the project again. We don’t need to know who that person is. Hence not a real question. But we do need to keep in mind that there’s always someone else who’s going to touch the work again, and that means extra responsibility that should be reflected in our decisions.

5. What’s the Probability for `x`?

Lastly, a good general purpose question which borrows from my own guiding principle, “web development is all about probabilities”—unless our job is to do only one thing, we always need to weigh probabilities. How likely is this feature going to stay? How likely is it that we’re going to grow it? How likely is it that more people are going to use it? &c. There are variables for any step of every project. We need to be good in judging and weighing probabilities.

❧ These are five ideas that I’ve found useful in my work. Though they may not appear technical at first, they all, decidedly, have an impact on very technical concerns. Being able to understand goals, environment, abilities, and probabilities have all been important during my career, and I’ve not so far met another experienced web developer who wouldn’t have a grasp, that is answers, for these items, either. There’s certainly more though, and I look forward to your comments.

Thanks to Arquay Harris for the idea for this post (Arquay and I used to work together at Google). I miss our discussions a little.

(Not to come up with excuses, but I’m literally all over the place lately. I’m unsure and need your assistance in determining whether what you read here lately is useful and makes sense, or whether it’s lacking, and what. Thank you.)

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)