The Anatomy of a Hexlet Project
2026-02-21 02:48 Diff
https://hexlet.io/blog/posts/anatomy-of-hexlet-projects

According to our students, projects are one of Hexlet's strongest features. These are special tasks that closely mimic real-world tasks, and they're done on your own computer, outside of Hexlet tasks. This article outlines how projects work, how long they take to complete, and why poorly written code doesn't work, and it also contains thoughts from our students about our projects.

Each project is a complete program, such as a console utility or full-fledged website. The projects are publicly available on GitHub and are included in our students' employment portfolios. Projects are reviewed by our tutors, so the codes are of high quality.

A little technical information: there are up to four projects in total in each profession. Each project is based on certain courses, but technically you can start without taking them. This will help you to assess the task's complexity and start taking the courses more seriously. The only restriction is that the projects must be taken in order.

Contents

Why are projects so important?

Independence

Courses do not provide all the tasks you will face as a future developer. Programmers are constantly searching online for the necessary libraries and documentation on them. Projects offer a lot of independent work. You'll have to think a lot, google and get into situations where you feel stuck.

This does not mean that students are left alone to do projects. You can ask questions on the website and chat about the project in our #hexlet-projects Slack channel as you go along.

Environment

Practicing on Hexlet allows you to focus on the task at hand without getting distracted by organizational and technical details. This is handy for beginners who are overwhelmed with a lot of information. But the longer this goes on, the more it gets in the way. It is impossible to learn how to develop full-fledged programs without independent and comprehensive coding. Programming is much more than just writing code - it's also interacting with the operating system, version control, tool configuration, testing, managing external libraries, and doing maintenance.

It is impossible to grasp all this theoretically, just by reading books or taking courses. You need real practice in a real environment. Projects are your chance to mess around with the proper setup of the development process tools and organization.

The Brain Games project is a good example. It requires installing packages, dependencies, eslint, makefile, working with git, creating proper names for commits and executable files, pre-publishing packages, writing instructions and modules, and performing import and export operations. But most importantly, refactoring. All these points are an indispensable part of a programmer's work, but you can only understand them through practice.

Many students discover how difficult it is for them to work outside of Hexlet at their knowledge level, and how long a simple installation of an interpreter or language compiler can take. Various problems arise with Windows, package managers, and even setting up a linter for the editor.

You have to be prepared for this. Infrastructure is an essential part of development. No one else will do it; the developer is alone responsible for quickly and efficiently setting up the environment, working with git, and interacting with the operating system. You have to be willing to do this at all times - it'll be difficult at first, and sometimes it'll be brutally difficult (and also long).

Refactoring

Projects work as follows: each of them is broken down into small steps of 3 to 11. Each step is a complete part of the project and may only concern a function's customization or implementation. It's important that you cannot go to the next step without finishing the previous one.

On the one hand, this approach helps reduce the stress of a large task that is difficult to start. On the other, it brings projects closer to real life. In the real world, projects that follow ready-made specifications and don't change mid-development are fantastic. This isn't the case for 'live' projects, not ones that you just tinker with at home (as happens for projects that aren't in demand). Real projects are like living organisms - they constantly change, taking on new requirements and obsolete code (legacy). Making changes in the project leads to either duplicating the code or rewriting the old code since it no longer fits the current requirements. This process is called refactoring.

Having several steps in a project encourages refactoring. This is a common scenario where a student decides to rewrite the existing code since it has become inconvenient to work with. It's not always easy to accept, but this approach makes it possible to distinguish bad solutions from good ones.

Tutors

You can complete a project either by yourself or with a tutor. For the former, it is checked automatically, which does not guarantee quality code. If with a tutor, they will take the project and evaluate its quality after all steps have been completed. Review is one of the most challenging and yet rewarding parts of a project. Let's talk about the tutor verification steps in more detail:

The review process looks like this:

  1. The tutor examines the project setup and code
  2. They leave comments on the website
  3. The student is notified and corrects according to the comments
  4. If a student doesn't understand something, he contacts the tutor in Slack to ask clarifying questions
  5. The student submits the project for review, and we go back to step one.

How many times can this go on? On average, three to four times, and on rare occasions two or three times (often due to cheating). Needless to say, the process of turning in a project can take a long time. As a rule, it takes longer to fix a project than to write it. Some students will think their code is perfect and become upset when they get comments on it. You have to be prepared for this, because nobody writes perfect code.

Sending a project in for review is always a source of anxiety. On the one hand, it feels like you considered everything and your code is perfect. On the other, you want the tutor to tear it down so that you gain valuable experience, which is essentially what ended up happening.

Why are there so many checks? A tutor's job at Hexlet is not just to point out flaws, but to bring the solution to an acceptable level. Everyone is different, and all projects turn out a little differently. This is normal - in programming, there are many ways to solve the same problem. Pointing out shortcomings isn't enough - the gap between "can read and understand" and "could implement" is huge.

Another reason is to do with what and how many notes the tutor gives during the review. Any project is divided into levels: for example, on the second project it's setup -> tests -> general logic -> output logic. The logic here is that if there are problems on the basic levels, there is no point in moving on to the next.

For example, if there is no linter configured, then you will most likely have to fix almost the entire code. If there are no tests, or they are written incorrectly, it means that development was not done through tests. In other words, further fixes will be made without being test-oriented. The same is true about the project's architecture - if it's built incorrectly, there's no sense parsing it in detail. In this case, most of the code will almost certainly be rewritten after the architecture is changed. This is why tutors never give out a complete list of comments. This is simply useless, allowing the student to relax and shift all responsibility for the result onto the reviewer.

The remarks themselves are rarely "do this" instructions. Tutors point out problems in the code, but do not suggest a way to solve them. This is important for forming the right attitude to the task - at work, no one will tell you how to do it.

Rewriting a project three or four times while working with a tutor is perfectly normal. This is where most of the growth happens, and therein lies the project's hidden power, which forces you to develop yourself. It's painful, but without pain there's no progress.

When I first took on a project, I thought: "This is easy, I solved problems like these on CodeBasics". It took me two days to write the whole project. Then my tutor wrote to me, and at first I did not understand their complaints - it still worked. I corrected it once, then again, and then I began to understand why I really needed to.

Despite all of the above, don't forget that tutors are people, and they may physically miss something and only see it the next time they check.

An interesting fact is that students who have actual experience working or studying on other platforms often take longer to complete projects. This is due to forming habits and approaches to code that are not useful to them (e.g., overengineering).

How are projects evaluated?

Working code is not the same as well-written code. While in real life the quality of code may not be very high (due to time constraints or developer level), projects are an entirely different story. It is an opportunity, in the absence of deadlines, to accomplish a task to a high level.

One of the key criteria for projects is simplicity and clarity. This includes a few different things:

  • directory structure
  • adherence to coding standards
  • list text hereproject architecture
  • naming of functions and variables
  • simple solutions to simple problems

Despite the complexity of projects, they are quite small compared to real applications. Real code comes out to tens or hundreds of thousands of lines. In such a situation, it's incredibly important to build abstractions correctly and name variables, classes, functions, and other entities well. We read other people's code much more often than we write our own. This is why Hexlet projects place so much emphasis on things that are not directly related to the code's workability.

Conclusions

  • Projects are not just something to pass. Be prepared to dive in and work hard. You can't finish it quickly
  • No one writes perfect code. Even writing good code takes years of experience
  • Not only must the code work, but it must also be easy to understand and maintain