DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

Backend developer

The server side: data, APIs, integrations, reliability under load.

Roles and moves Self-assessment

Step 2 of 2 · Backend developer

Which level inside the role?

Where people go from here: SRE and platform engineering, Data and machine learning, Architect, Team lead, tech lead, engineering manager, Frontend developer

Not sure — open the whole role card Pick another role

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Junior

Straight to the self-check

Compared with studying, the person setting the task changes: it is now somebody else's code and the people next to you, not a teacher.

Do now

  • I build a small service from scratch and hand it over so that it starts up on machines other than mineA colleague brings my project up from the README and does not ask a single question.
  • I take every bug of mine down to its cause, not down to the symptom disappearingI can name the place that broke everything and explain why it used to work.
  • I ask about what I do not understand at the start of a task, not on the day it is dueMy questions arrive before the code that would have to be thrown away is written.
  • I read other people's pull requests and leave at least one question of substance in themI know what happens in the neighbouring parts of the service, not only in my own.

Where next

Middle

Sideways out of the role

What this step asks of you

  • I write and run code in my working language without looking up the syntaxI can assemble a small service from scratch: dependencies, running it, formatting, linter.
  • I understand what happens between the browser's request and the service's responseI can explain why a request returned 502, instead of saying the server is broken.
  • I write SQL queries and understand what a transaction isI put together a query with a join and grouping without googling it, and I know how a transaction differs from separate queries.
  • I work in a shared branch without breaking the history for everyone elseI resolve a conflict, open a meaningful pull request, recover a lost commit.
  • I pin a bug down from logs and a stack trace, not by trial and errorI state a hypothesis and test it instead of changing lines at random.

Common mistakes

  • Staying silent until the task is done: the silence ends in a rewrite from scratch.
  • Treating a task as finished once the code is written: without tests and a deployment somebody else finishes it off.
  • Learning the framework instead of the language and the protocol: on the next project everything starts again from nothing.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Middle

Straight to the self-check

The subject grows from a task to a whole feature: you used to be told what to build, and now deciding what done means here falls to you.

Do now

  • I take the next feature to production myself: the statement of work, the code, the tests, the deployment, the watching afterwardsNobody finishes anything off behind me after my release.
  • I send a statement of work back to its author when it says nothing about behaviour on errorsThe task says what to do when the neighbouring service is unavailable.
  • I look at the query plan before the table growsI know which indexes my queries use, and I can see it in the plan.
  • I take on a task in an old module whose author has leftThe change is made, and I can explain why I did not rewrite the module wholesale.

Where next

Senior

Sideways out of the role

What this step asks of you

  • I take a feature all the way: requirements, code, tests, deployment, watching it runAfter my release there are no loose ends left for somebody else to finish.
  • I write tests that catch regressions instead of repeating the codeI can explain what exactly each test checks and why deleting it would be no loss.
  • I read a query plan and fix a slow queryI spot a seq scan where an index belongs, and I know what an insert pays for every extra index.
  • I design an API that will survive the next versionI can add a field without breaking old clients, and I know the price of the API style we chose.
  • I work in old code written by other people without rewriting all of itI can change a module whose author has left, and explain why I did not refactor everything.

Common mistakes

  • Rewriting somebody else's module instead of fixing it: the deadline slips and the cause of the bug stays where it was.
  • Writing tests against the implementation: any refactoring turns into repairing tests.
  • Treating deployment as somebody else's job: you find out how your feature lives in production from support.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Senior

Straight to the self-check

The horizon of a mistake changes: the price of a decision shows up not at review but when the system is too late to rewrite.

Do now

  • I write the next large decision down together with the options rejected and the conditions for revisiting itThe argument about the decision runs off the document and without me.
  • I take my turn on call and run the incident review myselfAfter the review there is a change in the system or in the process, not a note saying be more careful.
  • I walk through my own feature with an attacker's eyes before the releaseI know what can be done with my data and what it would take.
  • I review so that the person is left understanding the reason behind the commentMy comments carry a why, not only a redo this.

Where next

Further on: a branching, not a rung

Sideways out of the role

What this step asks of you

  • I choose a solution by its consequences rather than by fashion, and I write the choice downDecisions have an ADR: what we considered, what we gave up, and on what conditions we revisit it.
  • I design for failure: retries, idempotency, consistencyI know what happens to the data when the network drops in the middle of an operation, and I have accounted for it in advance.
  • I run an incident and write the post-mortem without hunting for someone to blameA post-mortem leaves behind a change in the system or in the process, not a line saying be more careful.
  • I review in a way that leaves the other person stronger than beforeMy comments carry the why, not only the redo this; the team has a shared standard.
  • I see the attack surface inside my own featureI sort out authorisation and secrets before the release, not after the pentest report.

Common mistakes

  • Becoming the only person who understands the system: your holiday turns into a risk for the team.
  • Arguing about technologies instead of consequences: the decision goes to whoever is loudest rather than to the lower price.
  • Designing with no failures in mind: a connection dropping in the middle of an operation gets found by users, not by you.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Further on: a branching, not a rung

Straight to the self-check

There is no rung upwards any more: what changes is not the height but the subject — influence without authority, the platform, architecture or people.

Do now

  • I take on work that has neither an owner nor a statement of work and see it throughThe task is closed although nobody handed it to me.
  • I carry a change of practice through teams that do not report to meMy idea has been adopted where I cannot order anything.
  • I count the money my system costs, not only draw its diagramI can name what it costs us and which option is cheaper as the load grows.
  • I try the neighbouring job on my own task before changing rolesI have run a user interview or covered an on-call shift for the platform, and I know whether it is for me.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I take on work that does not fit inside one teamI carried through a piece of work that had neither an owner nor a clear statement.
  • I change practices without formal authorityMy idea was adopted by teams that do not report to me.
  • I optimise by measurement, not by feelI start with a profile and a load test and finish with a number saying how much faster it got.
  • I count the money a system costs, not only its architectureI can say what the service costs per month and which option is cheaper when it doubles in size.

Common mistakes

  • Treating management as a promotion: it is different work with different measures, and coming back later costs more than it looks.
  • Waiting for a title before starting to have influence: influence comes from work done across boundaries, not from a line in the org chart.
  • Staying the only carrier of knowledge about the old system: that is not influence but a trap.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents