10 mistakes to avoid when starting a new job

Experienced people make every mistake on this list. They arrive with habits that worked at another company, and the habits outlive the place they came from. Each one costs time the client pays for, and some of the client's trust. So we say it plainly: here is what we expect, and what we hold people to.

This is the list we hand a new person at FSH in their first week, and ask them to read again a month in.

What we hold you to

• The priority you were given, delivered. Not the number of things you finished.
• How fast you turn feedback around.
• Sticking to the agreed order of work, including "spec before code" when we ask for it.
• Visible progress every day on whatever is the priority.
• Time against a sane budget, and whether you warned us before you went over it.

1. You can't tell the priority from the extras

You get A, B and C and hear "A is the priority, B and C if there's time." That means exactly this:

• You do A as well as you can, and you deliver it. That is what you are measured on.
• B and C exist so you are never sitting blocked. Waiting on review of A, on an answer from the client, on CI → you pick up B.
• Extras are upside, but only on a delivered A. B and C finished with A still open is not "I got a lot done." It is "I did something other than what we asked for."

2. You treat "spec first" as a suggestion

When we say the spec comes first and implementation waits for spec review, that is an instruction, not advice. Especially at the start of a project, and at the start of your time with us. The order:

1. Research: how it works today. Code, models, tables, existing endpoints, similar modules.
2. Options: two or three possible implementations, with the trade-offs.
3. Spec: markdown in the repo, a PR with the spec alone.
4. Spec review, then revisions.
5. Only now, implementation — then fixes after code review.

A correction in a spec costs minutes. In finished code it costs days. Code written before the spec is agreed usually goes in the bin.

3. You propose a solution before you know how the current one works

The most expensive mistake on this list. The systems we work on already have entities, tables and extension points. Designing something from scratch that already exists in another form means days of work thrown away, and a signal to the client that we do not know their system.

• Before you design, find what is already there: read the models and the migrations, ask the agent "where does this repo keep X", run /prior-art — it is in our public skills repo.
• A new table, module or dependency has to justify itself in the spec: what you looked for, and why what exists is not enough. Without that, the spec does not pass review.
• Half a day in and you still cannot say where the data for your task lives → you ask. That is a five-minute question, not a week-long topic.

4. Review feedback sits

Feedback on your PR comes before any new work. An open PR blocks a merge, and usually blocks a person too.

• Feedback arrives → it is the first thing you touch the next day.
• You disagree with a comment → reply in the thread the same day. No reaction reads as "nothing is happening."
• By noon the next day there is movement, at the latest: a commit, an answer or a question. A whole day with no response to feedback is a signal something is wrong, and we will talk about it.

5. You do not know your task's budget

Every task has a reasonable duration. A typical endpoint in an existing module is a day — spec, spec review, implementation and fixes included. A few days is the ceiling. Not weeks.

• Before you start, estimate how long it should take. You cannot → ask.
• Going over budget → you say so immediately, not afterwards. "This was meant to be a day, it is day two, because X" is a normal message. A week of silence on a three-day task is not.

6. You disappear and come back with "done"

You show progress as you go: draft PR early, short updates on the project channel, a task status that matches reality. If nothing is visible from you all day, then from where the team and the client sit, nothing happened that day.

7. You are stuck and you are quiet

The ceiling rule: 30–45 minutes without progress, or a decision that is hard to reverse — an API, a schema, a UX direction — and you write on the project channel. A question costs us two minutes. A day in the wrong direction costs a day. A question is not a sign of weakness. A lengthening silence is.

8. You confuse "done" with "I opened a PR"

A task is finished when:

• the PR is merged, CI is green, feedback is closed,
• the change works where it was meant to work (preview / staging / prod), checked by you, not by your reviewer,
• the task carries the right status.

An open PR with unresolved comments is work in progress, not a result.

9. You pass on what the agent wrote without understanding it

We use AI heavily and we expect you to. But a spec or a PR you cannot defend sentence by sentence is your problem, not the agent's. It acts in your name: what it sends is what you sent. And it will cheerfully propose new tables and modules, so check whether they already exist (see 3).

10. You do not see the client behind the task

The client does not see your effort. They see results, or their absence. Work that an experienced person does in a few days and that drags on for weeks is a question we have to answer, and the answer depends on you.

• Every day ends with visible progress on whatever is the priority.
• Before each day, ask yourself: what will the client see this evening?

In short

Priority first, research before solution, spec before code, feedback before new work, visible progress every day. Being senior exempts you from none of these. If anything it raises the bar. Something is unclear — ask. That is what we are here for.