5 Questions Web Developers Always Need Answers For

Published on April 9, 2014 (↻ February 5, 2024), filed under (RSS feed).

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.

Contents

  1. What Are the Goals—for Company, Team, Project, Individual?
  2. What Are Company and Team Like—Size, Composition, Culture, Geography?
  3. How Good Are We—Company, Team, Individual?
  4. Who Else Is Going to Work on the Project?
  5. 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.)

Toot about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (where applicable) or a message.

Comments (Closed)

  1. On April 9, 2014, 16:45 CEST, Damian said:

    Hello Jens,
    I enjoyed reading this post and i agree with these questions.
    You asked general - company/team questions, though and did not address project/customer related questions for which the answer needs to known by web developers.
    I believe that devs need to know the answers to questions like “What does the customer actually need?’, “What does the customer actually expect?”, “Who will be the targeted user for this project?” and others like these.

  2. On April 9, 2014, 20:39 CEST, Jens Oliver Meiert said:

    Damian, that’s a great point—developers certainly need to know about client needs and expectations. This here comes from the angle of the company as the client, as not all developers work with external clients.