В этом выпуске: сезон advent-календарей, React 19, Vite 6, TypeScript 5.7, Firefox 133, React Router 7, Astro 5 и Deno 2.1. Да, в этом выпуске много мажорных релизов. Кроме них мы, конечно, затронем интересные материалы: посмотрим на классный пример небольшого опенсорса, новые фичи CSS 2024 года, просветимся в теме создания современных пакетов, посмотрим на создание эффекта матового стекла и приобщимся к созданию плагинов для Obsidian.

---

**B**eing in charge of a team gives you a lot of energy, which originates both from people you work with and challenges you face. However, there comes the day when good vibes, coming from your teammates (even the best ones), are replaced by a bitter taste of apathy and indifference. If you’re seeing this, then you’ve most likely run into a wall of demotivation.

Yes, from time to time, employees become demotivated, and you have to find ways to raise their morale. In this blog post, we explore the signs, causes and dangers of demotivation, and 8 easy ways to improve the team spirit.

<Img imageName="sherlock" alt="sherlock" withBigMargin/>

##Know your enemy: what causes demotivation?

There are multiple factors that cause workplace demotivation. The key reason so far is the relationship between managers and their teams. As seen from the suggested points below, this is the biggest root cause of this transformation driving the people’s morale down.

### Feeling undervalued and useless

Your teammates always want to know that their efforts are valued and recognised. When they’re consistently performing and get no appreciation or recognition, employees start wondering, “what’s that all about”, nobody cares and notices anyway.

<ParagraphWithImage imageName="mencircle">
### Working without purpose
Living without goals or intent may be the biggest reason to feel demotivated. No purpose means no sense of direction, when things are done just for the sake of doing things, instead of working towards something desirable. This sense of direction often comes from a company vision. If your employees do not connect to the vision, they will not understand how they contribute to reaching it.
</ParagraphWithImage>

### Personal circumstances

There’s a life outside work, and there are innumerable events that can happen and impact a employees’ behaviour. Never expect that everyone will share their problems openly at workplace.

### Goals are too big

Your goals can also be a source of your current motivation problem. If they’re too large and vague, this might likely create the unrealistic workload that your employees will not handle. The excessive workload along with expecting too much from the team cause frustration and anxiety and can negatively affect the well-being and health of your employees.

### Broken trust level

Lack of trust decreases the speed and productivity of the team and increases the costs. Trust level breaks if a manager fails to keep his promises and commitments, which apply to promotion or other promised benefits, including advance of wages. If you are not delegating tasks because you believe only you can do them correctly, communicates a lack of trust as well.

<ParagraphWithImage imageName="menbla">
Poor time management can cause a wide range of problems such as inefficient time allocation, distraction and procrastination. Employees who don’t have control over their time end up letting tasks sit until the last minute, a lot of stress when they try to play catch up and finally miss the deadlines entirely.
</ParagraphWithImage>

### No development or/and career opportunities

Most employees are eager to develop, learn and grow. However, the opportunities to develop skills and expertise may be missing, which causes a team member to feel frustrated as he knows that he could have bring more value to the team.

Absence of career opportunities shadows the motivation and profession goals of your teammates. If a team leader doesn’t show the way their efforts can affect their career pump, this will definitely lead to demotivation.

<Note>
#### Dangers: what is the impact of a demotivated employee?

There’s one more thing you should consider if/when facing the problem. The demotivated employees are often distracted, and they start distracting and frustrating those around them affecting negatively the general working atmosphere inside the team. If they have a client-facing position, then the problem may have a killing impact on your relationship with both the existing and potential customers.
</Note>

<Img imageName="man-with-butterfly" alt="man with butterfly" withBigMargin/>

## “Fixing the bugs”: 8 steps to motivate your employees

After you realized that the lack of motivation is what’s haunting your team’s productivity and success, you have to re-energise the employee before the situation escalates into a bigger problem. To create an environment where your team members feel and work in comfort, follow these suggestions and see those demotivated team members become engaged and productive once again.

### 1. Investigate the problem

When you encounter a considerable demotivation problem, get to know the reasons. Carry out an anonymous survey or assemble a focus group to receive a feedback about conditions that are driving the spirit down. Don’t hesitate to ask pointed questions and encourage honest answers that may help to determine the problem areas. Also ask HR for potential solutions that could improve workplace conditions and increase morale.

### 2. Get involved

Take proactive steps based on the information you’ve found. Investigate the issues that affect workplace motivation and think of the actions that will help to resolve the problem. This will result in achieving tangible improvements and addressing team’s direct concerns.

### 3. Make every team member feel important

Take proactive steps Remind your employees about the reasons you’ve hired them — their skills and knowledge. Show them, that you do appreciate their input to the company’ development and the team’s progress. You can also make up some traditions that you and your employees will keep. If your corporate culture allows informal crew meetings then choose a weekend to go out and have a chat with the team.

Learn to respect your teammates’ personalities: listen to their ideas and fails, share your thoughts and take theirs into account. Make them feel involved in business processes and, most important, show your people you treat them equally. on the information you’ve found. Investigate the issues that affect workplace motivation and think of the actions that will help to resolve the problem. This will result in achieving tangible improvements and addressing team’s direct concerns.

### 4. Be technology-driven

Introduce new tools to set up proper time management. A time tracking app is an essential time management tool that can help you and your team become more organized, efficient, and get more things done.

Time tracker is a simple-to-use app that combines two crucial features — project management and productivity analysis. Additionally, time tracker is designed to help managers and their teams identify their unproductive habits and eliminate distraction. In fact, this tool doesn’t just tell you how long you’ve spent working, but how long you’ve been productive.

### 5. Create development opportunities

Work with each team member to create opportunities outside their day-to-day role. It really matters for an employee to see that a manager cares about his career and tries to find where they can develop their knowledge and learn new skills. Mentoring, coaching, suggesting additional training or coursework — all of these can be helpful and highly valued. This will also allow to delegate and create new development opportunities for yourself.

### 6. Keep on talking

Have a conversation with your demotivated team members. Share the behaviours that you have noticed that are different to how they usually are and give them the opportunity to explore what the underlying cause is. Maybe they want some autonomy or want to feel in control. Communicate your expectations, let them know what the desired goal is and then give them the space to go and achieve it.

### 7. Reward and encourage

Dealing with budgeting is hard. Yet, if there’s a need to increase your team members wages, think of budgetary reallocations. Analyze the expenses and optimize the resources. Reward brilliant and helpful ideas from your employees. Offer encouragement for the upcoming successes or rally the team by providing non-tangible benefits, like flex time or additional time off.

### 8. Monitor Morale Levels

Finally, implement various morale-building programs or spirit-lifting team initiatives. These may be employee appreciation plans and company/team awards. Celebrate birthdays, acknowledge even small contributions and encourage staffers to continually submit ideas for how to improve the overall workplace dynamic. Regularly ask for feedback to help maintain morale.

<ParagraphWithImage imageName="red-pants">
## Keep in mind

Even the best employees become demotivated but it is necessary to get back their drive to push forward. These 8 points above will help you to find the reasons behind your lack of motivation and the next steps you need to take to recover that drive and passion. Follow simple rules to handle the demotivation problem and never forget to:

1\. Identify and evaluate the reasons

2\. Talk, discuss and get a feedback to find the best solution

3\. Introduce new methods, techniques, technologies, tools and solutions

4\. Pay attention and monitor morale levels to prevent demotivation problem

Keep this in mind and don’t forget to subscribe to our social media to get more tips on the project management and human resources.

</ParagraphWithImage>

Eight Ways to Improve Staff Motivation or How&nbsp;to Mend Broken&nbsp;Morale

---

**T**ask estimating and time planning are both stress and responsibility, and some developers even come up with ideological excuses against them. However, whether they want it or not, it is all about terms and estimates in the IT-world, rather than code quality. Faster development provides certain advantage over competitors, while an adequate task estimation allows to calculate the costs more accurately. The customer is primarily interested in timing and the exact cost of work. Each of these parameters depends directly on the estimation done by a developer who has been digging into the project during presale. No doubt, the manager will include additional risks, but this will be useless if the developer has miscalculated 3 times before.

Let’s face it — you can’t avoid task estimating, and if you do not estimate the tasks within a given project, then most likely someone else is doing it instead of you. At the same time, the developer able to estimate adequately and precisely is a sort of a godsend for his employer. Such specialists are valuable, they grow faster than those with poor estimating skills.

Our team has travelled a lengthy and bumpy path dealing with poor-quality estimates. These prevented us from staying within budget limits, spoiled our relations with customers, and made us look not that smart. By trial and error, we have come up with a set of rules (tips) that helped to enhance the accuracy of our estimates. Hope you’ll find them useful as well.

<Img imageName="man-on-unicorn" alt="man-on-unicorn" withBigMargin/>

## Secure the Conditions

To begin with, wrong estimates made systematically, along with significant delays, are not always your fault. To make a top-level task estimate, a number of conditions should be met.

### Enough time is allocated for estimation

This is an important and painstaking thing, and if a developer has only 15 minutes to estimate a major feature, then, unsurprisingly, something will drop out. If this is what really happens to you, your duty is to communicate the concerns to the management and try to convince that an extra hour spent on the estimation process can prevent 100 hours of further delay.

### Estimation is integrated into your workflow

You will fail to upgrade your estimating skills to a top-level being in the middle of a complete mess: i.e. when tasks are estimated on a case-by-case basis, or you are suddenly forced to estimate one task while working on another, or it is generally unclear whether you should estimate any or not. The first step towards effective task estimating would be fostering the culture of estimation within your team. A high-level team discipline, among other factors, guaranteers efficiency. Having precise regulation of estimation stages can be helpful, and if the developer can draw the conclusions about the quality of his estimate in the end of the project, then the confusion will be minimal resulting in work efficiency increase. In this case, quality improvement will be just a matter of time.

<ParagraphWithImage imageName="man-and-astronauts">
### Tasks are set correctly
No matter how vast your experience is, you cannot include an estimate into those parts of the functionality that you don’t even have an idea of. To consider the task in detail (both hidden at the initial stage, and those that will emerge later) you need to have a third eye, which is, unfortunately, unrealistic. Nevertheless, you can minimize these risks by preparing reasonable (if not brilliant) Terms of Reference (ToR).
</ParagraphWithImage>

If ToR leave no hope for an accurate estimation, never be afraid to ask questions, even if it takes additional time.

### Ideally, task estimating consists of two phases:

- You carefully read ToR, ask questions to the analyst/customer’s representative.

- Get the answers and estimate the task.

But the truth would be more like this:

- You carefully read ToR and ask questions to the author of the original idea.

- You get the answers that generate even more questions.

- Again.

- And again.

The process can be delayed, however, these time costs will bring more value. By the way, at this stage we often involve testers instead of developers. Mistakes made while stating the problem are expensive, and the more people participate in bugs hunting, the better results you would achieve.

<ParagraphWithImage imageName="man-and-ladder">
## Work on Yourself
Let’s move on to the estimation rules and focus on what you, personally, can do to improve the team’s performance.
</ParagraphWithImage>

### Break the task into sections and do it properly

Eat an elephant one bite at a time. A good decomposition gives a powerful boost to fit into an estimate. This is worth doing, even if you do not plan to distribute tasks between different developers. First, when decomposing, you look at the task a little closer, from either side, you think of an implementation plan, which means you see new features and also those requiring extra time. Secondly, this is an additional possibility of self-control. If you are implementing a monolith task designed for 120 hours, there’s a risk of spending 30 hours on one of its parts instead of 12 that were really worth spending. This works another way with decomposition.

### Compare your estimates and time actually spent

To upgrade the estimating skill, you need to receive feedback on how close to reality your previous estimates really were. You can set a special filter in Jira, or at least create a dedicated Google table.

### Mind the risks

Discuss separately everything that can significantly affect the final estimate. These factors include:

- Unfinished task setting (unprepared layouts and ToR, API issues and everything “to be provided later”);

- Technology that you have not used before;

- Gaps in the description and lack of answers to your questions.

Report these when evaluating the task, make it clear that changes made to task setting would result in labor costs increase.

### Be realistic

When your manager or a team leader is asking you this “how long will it take?” question, he is actually not interested in the amount of time you’ll spend on writing the code. Everyone (well, almost everyone) has come across this. The exact figure will be useless here, since it doesn’t correlate with reality. Count the time you will spend on writing the code, add the time you will spend on smoking, drinking coffee, napping, asking your neighbor for advice, waiting for an answer from the analyst, corrections to layout from the designer, getting stalled with the back-end, falling ten times and rising eleven times. How much time should be put into risks? My advice is to start from 20% when dealing with large tasks and 50% for smaller ones. Then look at the result and, if necessary, adjust the figure.

### Don’t bend

Do not agree to lower your estimate, especially if you are 100% sure this will not work. Teach your colleagues that it will take as much time as it should take. Learn to defend your estimates in a reasoned manner, as people will always try to haggle with you.

### Do not overestimate (significantly)

If it is more or less clear with an underestimation, so what is wrong with overestimation? Wouldn’t it be a nice surprise to complete a task twice as fast as expected? Maybe somewhere, for someone. With some reservations:

This is harmful to discipline. Parkinson’s law says work expands so as to fill the time available for its completion: maybe more, but almost never less. In our experience, only a few can normally complete the task ahead of schedule. The rest use up all the time provided. Therefore, when overestimating (“just in case”) without real risks, bid farewell to this time, because, most likely, it will be simply wasted.

It can also ruin the entire planning and other processes within your team. Developer’s workload is planned in advance for a certain period. If somehow the work designed for a two-week sprint is done in 3-4 days, the rest of the team will be left perplexed, while the “top performer” will find himself without tasks. This seems ridiculous, not heroic. Besides, it makes one seriously doubt the skills of such developer. Secondly, the software development process is not limited to coding. There are other processes for the teammates to participate, including analytics, planning, testing, code review. Since your backlog is empty, all these guys need to drop their current (possibly urgent) work and rush to feed you new tasks and test the old ones. Thus, the efficiency of planning and team interaction are smoothly tending toward zero, generating chaos and destruction.

Perhaps the last tip below.

### Relax 🙂

Mess-ups are inevitable. Sometimes we still mess up ourselves. No surprise here — so many things can go wrong! However, it’s important not to give up and analyze your successes and failures, adapt other people’s processes and rules and invent your own — those that will work specifically for your team.

We hope that these tips above will help to avoid frequent rookie mistakes on this long and fascinating journey.

Ten Tips and Best Practices for Accurate Task Estimating

---

In the picture down below is Stonehenge, one of the most famous architectural monuments in the world!

<Img imageName='stonehenge' alt='Stonehenge photo' />

<Caption size='s'>
 © 2007 by thegarethwiscombe
</Caption>

It's hard to find anyone who hasn't heard of Stonehenge, yet nobody can say for sure what was the original purpose pursued by the ancient people who built it. In fact, the scientists would be grateful for any text or graphical description from the builders of this monument.

When it comes to “Stonehenges” in a codebase, it can be a great architectural solution that we use every day, building a whole system on top of it without really understanding why we or previous developers built it as they did. Perhaps, they had their reasons, but these are now completely irrelevant. We can't be sure.

However, a lack of understanding regarding the original reason behind implementing a specific element can lead to an occasional increase of complexity.

## The importance of documentation

While many developers truly enjoy making and working with projects that have good documentation, they still tend to feel reluctant to write it. This paradox of a situation exists despite us, developers, understanding the importance of documentation. Still, the difficulty of writing and supporting a detailed description of the code does bear its burden. But is there a way to make it easier? I think there is! Let me show you it in this article!

[<Img imageName='tweet-about-documentation' alt='A tweet about documentation' />](https://twitter.com/mit_csail/status/1405559612326105090?s=28)


## Main problems of documentation writing

The main problem and, perhaps, the root of the rest of the problems is the separation of code and documentation. When we write our code and documentation in different systems (e.g. GitHub and Confluence), we have two different versioning systems for code and documentation. But what does this mean? Well, it can lead to the growth of project support complexity. For instance, every single change in a source code should be manually synchronized with documentation, while every single change in the documentation is to be connected to the source code.

This complexity often stops people from writing documentation at all, they may ask, "Why should we spend our time trying to write documentation for a project in development status?", adding, "We'll write the documentation when we get the completed product". This is possible, but, unfortunately, in real life, a "completed" project is a dead project. All live projects are in continuous development status. Thus, the only way to have good documentation is to write it in parallel with development, making this process as easy as possible with minimal overhead.


Take for example this, at different times and in different places, developers tried to solve this. For instance, Racket language has its own way to keep source code and documentation as close as possible by using [Scribble](https://docs.racket-lang.org/scribble/), which allows us to integrate Racket code, including evaluating it inside the documentation:

```racket
#lang scribble/manual
@(require (for-label racket))
 
@title{My Library}
 
An example of the Racket code:
 
@racketblock[

(define (nobody-understands-me what)
 (list "When I think of all the"
 what
 "I've tried so hard to explain!"))
(nobody-understands-me "glorble snop")

]
```

In another example, if you're an Emacs enthusiast, you can use the awesome tool/language called [Org Mode](https://orgmode.org/), which allows one to write complex documents, evaluate source code of different programming languages, and use the [Literate Programming](https://en.wikipedia.org/wiki/Literate_programming) paradigm to keep all your source code within the documentation. Here's an example from its home page.

```org
#+title: Example Org File
#+author: TEC
#+date: 2020-10-27

* Revamp orgmode.org website

The /beauty/ of org *must* be shared.
[[https://upload.wikimedia.org/wikipedia/commons/b/bd/Share_Icon.svg]]
** DONE Make screenshots
 CLOSED: [2020-09-03 Thu 18:24]

** DONE Restyle Site CSS

Go through [[file:style.scss][stylesheet]]


** TODO Check CSS on main pages 

* Learn Org

Org makes easy things trivial and complex things practical.

You don't need to learn Org before using Org: read the quickstart
page and you should be good to go. If you need more, Org will be
here for you as well: dive into the manual and join the community!
 
** Feedback

#+include: "other/feedback.org*manual" :only-contents t
* Check CSS minification ratios

#+begin_src python
from pathlib import Path
cssRatios = []
for css_min in Path("resources/style").glob("*.min.css"):
 css = css_min.with_suffix('').with_suffix('.css')
 cssRatios.append([css.name,
 "{:.0f}% minified ({:4.1f} KiB)".format( 100 *
 css_min.stat().st_size / css.stat().st_size,
 css_min.stat().st_size / 1000)])
return cssRatios
#+end_src

#+RESULTS:
| index.css | 76% minified ( 1.4 KiB) |
| org-demo.css | 77% minified ( 2.8 KiB) |
| errors.css | 74% minified ( 4.9 KiB) |
| org.css | 75% minified (10.7 KiB) |
```

Org Mode is a great solution if your team is familiar with Org Mode and Emacs. Even Github supports Org Mode, and you can use `*.org` files instead of `*.md` ones.

On the other hand, another problem arising from the separation of code and documentation is the weak cohesion between code and documentation parts. For example, we can describe a feature in our system, but every single part of the description is about different parts in our source files. This issue leads us to an inability to update certain parts of documentation after changing files connected to the source code or editing specific parts of those source files. Vice versa, while reading documentation, it's difficult to quickly find related source code for a certain paragraph of documentation. Without solving this issue, the complexity of documentation support will grow increasingly with the growth of project size.

But you may disagree and say, "That’s not true.Our API documentation doesn't have problems like that!" and you'll be right! You don't have such problems with API documentation or your Storybook documentation because it's generated from source code or with huge involvement of your source code in it. It has strong cohesion with source code and uses the same version control system as your source code. The only way to make writing project documentation easier, is to use the same set of tools as for code writing.

You can still solve this issue with tools like Scribble or Org Mode, but you'll need to combine different parts of documentation manually, which can be hard in big projects.

## Documentation as code

Keeping documentation and code together allows to achieve better control of changes and to make support of documentation easier. But without proper tools, it can be awkward to work with documentation for anybody other than the developers. For example, we can use markdown files for writing documentation, but if we place them near related source files, it will be difficult for managers, analysts, QAs, and designers to find something in this documentation. On the other hand, if we place them into a separate directory with its structure, we will not solve the issue with weak cohesion. In addition, with markdown files, we can't automatically create references from `*.md` files to particular parts of a source file, or we can't automatically combine all `*.md` files about the whole feature but written in the perspective of different source files. Let's look at the following example:

```bash
.
└── src
 ├── api
 │ ├── auth.js
 │ ├── news.js
 │ └── offers.js
 ├── components
 │ ├── auth.js
 │ ├── header.js
 │ ├── news.js
 │ └── offers.js
 ├── index.js
 └── reducers
 ├── auth.js
 ├── news.js
 └── offers.js
```

The example shows a simple project. Let's imagine we want to write documentation for our `auth` feature. The whole feature is implemented in three different files, but by "auth's implementation", all source files, not only `api/auth.js` or `components/auth.js`. So, to achieve strong cohesion between code and documentation, we should somehow place different parts of an article about authentication in different files and generate a single article from these parts.

If we do that, and even better, we add links to source code from a generated article, we can solve both problems with weak cohesion and using different versioning tools. But it'll still be a little awkward to use because good documentation should allow you to search through it and edit it.

## The solution

I tried finding something which could solve all of these problems, but unfortunately, I hadn't found it. So I wrote my own tool called [Fundoc](https://github.com/CSSSR/fundoc) to achieve all described goals and even more. The tool can:

- Keep documentation and source code as close as possible.
- Use the same version control system for documentation as for code.
- Be language agnostic.
- Collect all documentation from different repositories in one particular place.
- Allow non-programmers to read and write documentation.

So what can Fundoc do? It can generate documentation in two formats: raw markdown files (maybe later I'll add Org Mode support) and [mdBook](https://github.com/rust-lang/mdBook). The main idea behind this tool is to be as straightforward and uncomplicated to use as possible while providing all of the required functionality like search through documentation, documentation editing without the necessity to know the structure of a project, using one version control system, and so on.

<Img imageName='fundoc-example' alt='An example that shows how Fundoc generates documentation from different files' />

But what do I use to keep the simplicity of a tool and the possibility to work with it for non-programmers? I use Github, that's it. Of course, in the future, it's possible to extend support of different services like GitLab, Bitbucket, or something like that. Let me explain how it works. Developers write documentation in source files or in markdown files marking every single documentation part with a simple marker that describes a result article title such as:

```javascript
// src/api/auth.js

/**
* @Article Authentication
*
* To get authenticated, you should use the `login` function, which returns auth-token to pass it with API requests that require authentication.
*/
const login = (username, password) => {
 // some code here
}

/**
* @Article Authentication
* 
* To log out, use the `logout` method. It will invalidate the auth-token and delete it from cookies.
*/
const logout = () => {
 // some code here
}
```

And some description for a UI-part:

```javascript
// src/components/header.js

const Header = props => {
 const { isUserAuthorized } = props
 
 /**
 * @Article Authentication
 *
 * Only authorized users can see their balance in the header
 */
 return (
 <div>
 ...
 {isUserAuthorized && <UserBalance />}
 ...
 </div>
 )
}
```

This rather simple example will be compiled into one markdown file:

```markdown
# Authentication

To get authenticated, you should use the `login` function, which returns auth-token to pass it with API requests which require authentication. [[~]](https://github.com/username/repository/blob/master/src/api/auth.js#L3-L7)

To log out, use the `logout` method. It will invalidate the auth-token and delete it from cookies. [[~]](https://github.com/username/repository/blob/master/src/api/auth.js#L12-L16)

Only authorized users can see their balance in the header. [[~]](https://github.com/username/repository/blob/master/src/components/header.js#L6-L10)
```

> To see more realistic documentation examples you can check out [documentation of Fundoc itself](https://csssr.github.io/fundoc/) or [another project](https://github.com/CSSSR/linters) that used Fundoc.

In the compiled markdown file, you can see references to the particular parts of the source code. It allows you to find the exact source of every single part of the documentation. It can be useful for non-programmers if they want to edit documentation. If you believe they should still work with git to push their changes, they actually should not. Here's the example of editing documentation in the repository of Fundoc:

![Process of documentation editing](/images/dont-resize/en/problems-with-documentation-writing/fundoc-gif/all.gif)

So on the gif, we can see that the only thing we need to edit our documentation is GitHub itself. Yes, it still requires an understanding of what GitHub is and the fundamental terms like "commit" and "branch". As practice shows, QAs, managers, designers, and analysts can handle it without any problems. At the same time, this way of working with documentation doesn't require knowing the file structure of a project from non-developers. It's definitely much easier than working with CLI-tools and dramatically easier than trying to synchronize Confluence and source code.

At the end of the article, I wanted to remind you that Fundoc now is in the beta state, and some APIs can change in the future. Otherwise, it already solves many problems and is used in different projects, so you can try to use it as well. If you have any questions or suggestions, feel free to send me them via Github issues or PRs. I'll be glad to make it better with your help!

It's hard to find anyone who hasn't heard of Stonehenge, yet nobody can say for sure what was the original purpose pursued by the ancient people who built it. In fact, the scientists would be grateful for any text or graphical description from the builders of this monument.

Problems with documentation writing

---

**F**irst and foremost, you should know that there’s no one right way to build a website. What you use in the end all depends on your needs and business demands. Sometimes a basic HTML site is all you need, other times you may need to develop a completely bespoke site to appeal to your customer base, while standard CMS sites allow you to make basic updates easily.

To help you decide which web development strategy is best for you, let’s look at the advantages and disadvantages of each.

<ParagraphWithImage imageName="html">
## HTML

Description: HTML sites are best for the most basic types of sites. Static in nature, they offer a quick and cheap way to build an online presence that you can use to market your company. Development skills for this type of website are relatively simple, meaning you can hire a relatively junior developer to maintain the site as you grow. However, HTML really only works for smaller sites, and isn’t an effective tool for e-commerce. To get an idea of how much it would cost to build a basic HTML site, you can use this quick calculation tool.

Pros: cheap, quick to build, low level programming skills to update

Cons: static website that requires programming skills to update, can’t be used for e-commerce, difficult to use for complex sites.

Who it’s best for: companies looking for a basic online presence with company description and contact details.
</ParagraphWithImage>

<ParagraphWithImage imageName="cms">
## Standard CMS

Description: A Content Management System (CMS) website is quite simple to set up. There are standard site layouts that you can purchase and you can buy a design to fill it in. You can hire a company to do this for you, but they’ll charge quite a high premium to develop them for you. However, CMS sites can be good for standard e-commerce sites, and it can be useful to hire a developer to help you with this. You should also remember that because most e-commerce sites have some custom elements, CMS is usually best for MVPs, while you’d have to hire a developer to build your final product from scratch.

Another key advantage to CMS sites is that once you’ve set them up, you can change content relatively simply, although if you want to make major changes, you’ll need a custom site. Standard CMS can also be useful for blogs, because the content can be so easily updated

Pros: some adaptable content with no developer, can build MVPs for e-commerce, cheaper than custom sites

Cons: more expensive than HTML, no customization, often need to build new site from scratch as company grows, mostly only suitable for MVPs

Who it’s best for: companies building MVPs to be rebuilt once bigger investment is secured, basic e-commerce, blogs
</ParagraphWithImage>

<ParagraphWithImage imageName="custom-development">
## Custom Development

Description: custom web development is the most useful way of building a website if you want to build a long-term business through an internet presence — basically everyone these days. For some businesses, like a local car dealership, this may be too much, because you sell most of your cars in person. However, if you want to make sales over the internet, you need at least a CMS website.

One of the advantages of developing a custom site as opposed to a basic CMS design is that there are no limitations based on the standard layout. You can build whatever elements you want to help increase your sales and build elements that give your company a real unique selling point. You can also update parts of your website, like a standard CMS site.

Another major benefit of building your own custom website is that they can be easily scaled. It’s important to note that how well the site can scale is largely dependent on the quality of the code. Standard CMS sites or low-quality code custom sites can get buggy and have delays as users increase. If you’re building a site to handle a large load of clients, it’s best to find a skilled team of developers to do it for you.

However, skilled developers can be quite expensive, which is difficult for some newer and smaller businesses to handle. If you’re just starting out and don’t have much funding, it might be expensive for you to build the site you want from the beginning, but it will save you time and money down the road.

Pros: completely customizable, scalable, can update content, better presentation of unique selling points,

Cons: can be pricey, requires experienced professional team, major updates more complex

Who it’s best for: established companies looking to build an online store, aggregators, startups looking to build an online company, news sites
</ParagraphWithImage>

<Separator type="color-line" lineColor="#D3D3FF" imageTitle="peopleWithBasket" imageName="peopleWithBasket"/>

## Conclusion

If you’re looking to build a new website, you have several options to choose from, and the one that’s right for you depends on many factors. As you grow your business, you may decide to change what you originally built. Choosing the right model to start with can save you time and money and help you grow faster.

HTML, CMS or Custom Development: Which is Better?

---

**T**hose days when you could seriously argue whether it’s a bad or a good idea to bring outsourcers in your business are gone. Now the question is different: how to choose an outsourcing team so as to get maximum benefit and minimum risks. 
First of all, you should consider from where exactly this team will be working.

If you classify outsourcing by location, you can distinguish three main types:

- A team works together with yours in the same office. All communications — face to face, external and internal developers participate in meetings and brainstorms together.
- A team works from its own office. Communication within the team takes place offline, and interaction with your team are done through regular meetings and the Internet.
- A team is fully distributed, all interaction is remote.

Each type has its own peculiarities. At a contractor’s search stage, your key task is to correctly define the terms of interaction with the future outsourced team and select the most suitable way of working so that these features become advantages.

If one collects opinions about working with outsourced teams from different companies, he or she can learn that sometimes the same initial conditions may result in the opposite outcomes. Some say that a fully distributed outsourced team shows a higher result than a team working from an office. Others recall their experience with remote developers as a complete failure, but note the increase in productivity after inviting the outsourcers to work in their office. The easiest way is to blame the professionalism of the outsourced team for everything. But in fact the truth is that the environment and conditions play a significant role in how effectively a team can work. Let us look into what those conditions are and how to take them into account when choosing a contractor.

<ParagraphWithImage imageName="skydiving-people">
## Team Goals
The correctly defined goals are 90% of success. Make your mind what you would like to achieve outsourcing some job from your in-house IT department: to speed up on-going development, to launch a new one, or to ease the pressure on the supporting team of an already operating product.

In any case, it is important to remember that it will take time for a new team to adapt to your processes and get familiar with the context. The more “legacy” there is in the tasks they will have to perform, the longer this period will be. In critical situations, it can be greatly reduced by placing the developers in the epicenter of events right in the office. This is especially true for a pre-release stage products or those at support, i.e. in all cases when information exchange between yours and the outsourced team should be as fast as possible. However, if you are only planning to launch development, this option may bring no benefits, as new information will be distributed as it generated, but the office costs will certainly increase.
</ParagraphWithImage>

<ParagraphWithImage imageName="skydiving-man">
## Special Teams
If you need a team of HTML developers to quickly launch a batch of typical landings, you can find suitable candidates almost anywhere in the world. But if you’re looking for developers with deep expertise by choosing a team to be located in the office, you limit your choice. Professional distributed teams are able to recruit the best specialists from all over the world, which means you can engage in your project, for example, five signor-developers within one team.
</ParagraphWithImage>

## Company Procedures

You would like the outsourced team to follow your internal procedures. The following shall be taken into consideration:

- Level of control. If your management keeps a strict record of all your employees’ activities, and this is critical for you, the most convenient option would be an outsourced team working in your office. Alternatively, desktop monitoring systems for employees can be considered, but such solutions are often expensive and greatly reduce motivation.
- Well-tuned, clear and structured processes. The clearer the mechanisms within your team work, the less risk of losing time, data and information when working with outsourcers. In small teams, where processes are not yet regulated, outsourcers working close to their office colleagues will be able to handle tasks more efficiently.
- Documentation. Although a project coverage with up-to-date and comprehensive documentation is the generally recognized best practice, reality is not ideal. If your project lacks well-functioning documentation support — the farther the developers are from the team, the more painful their work will be.
- Main communication channels. Take note how your employees communicate. Nowadays, many companies use messengers and video communication inside the office — it is quick, convenient, saves the history of communication, and does not knock out of the “stream” the developers deeply immersed in the problem. If this is your story, then the connection with a distributed team will go seamless. And vice versa, teams that meet three times a day in a meeting room will hardly work smoothly with remote developers or a team from another office.

These points are a “quick test” of your in-house IT department’s readiness for expansion through outsourcing. In order to get the full picture you need to analyze a lot more factors and we’re ready to help with that. Email us and we will give you free advice on all the particulars of connecting the outsourcing team to your development.

One argument against outsourcing often heard from CTOs or team leaders is that “our processes are not adapted to include outsiders at all”. Unfortunately, sometimes this is really true.

The good news is that including the team “inside” your processes is not always necessary. If it has to work on the whole project or the selected particular parts, so you can organize the work in the way that the teams are synchronized only at key points. Experienced professional outsourced teams do not need to be controlled at every stage.

There’s a security issue worths mentioned separately. We can assume that distributed teams definitely lose out when it comes to working on projects that require a high level of data access control. But in reality, it’s a question of experience and the right tools: we’ve been working with banks and companies dealing with cybersecurity for many years and have learned to adjust to almost any requirements.

<ParagraphWithImage imageName="laptop-work">
## Project Completion
Any project comes to an end at some point and at that point one have to decide what to do with the people who no longer have assignments. Having an outsourced team is like an insurance against the necessity to fire or transfer employees to other departments. The costs of “shutting down” distributed teams or those in own office are lower — one doesn’t have to think about abandoned workplaces, passes cancellation and empty spaces. This also applies to putting work on hold: for your in-house developers such standstill is often too much to bear and it is definitely expensive for you.
</ParagraphWithImage>

## Costs

Often the choice of outsourcing development is a choice in favor of economy. In this light, distributed teams look the most advantageous: it is cheaper to have them, and therefore the cost of hiring them is much lower. However, recruiting a team with its own office also creates a lower financial burden than your office outstaffing.

So, to sum it up.

<Table color='purple' withBorders>
 <thead>
 <tr>
 <th />
 <th>Your office outstaffing</th>
 <th>Outsource in its own office</th>
 <th>Distributed team</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <th colspan="4" data-text="Aim">Aim</th>
 </tr>
 <tr>
 <th>Emergency help to your project</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Development support or upgrades with new functions</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Launch of new development</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Specialists Qualification">Specialists Qualification</th>
 </tr>
 <tr>
 <th>Regular specialists</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Unique specialists</th>
 <td>--</td>
 <td>-</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Processes">Processes</th>
 </tr>
 <tr>
 <th>Firm control</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Strict processes</th>
 <td>+</td>
 <td>+</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Documentations</th>
 <td>+</td>
 <td>++</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Personal communication</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Communication via messengers</th>
 <td>+</td>
 <td>+</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Security concerns</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Miscellaneous">Miscellaneous</th>
 </tr>
 <tr>
 <th>Project completion</th>
 <td>-</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Low cost</th>
 <td>--</td>
 <td>-</td>
 <td>++</td>
 </tr>
 </tbody>
</Table>

There are no one-size-fits-all solutions, but proper planning and risk assessment at the start of cooperation will help avoid many mistakes. Be honest with yourself and the team your hired — this will make your outsourcing experience the most productive.

Blog | CSSSR

Problems with documentation writing

HTML, CMS or Custom Development: Which is Better?

How Close Your Outsourced Team Should Be Located? Pros and Cons

Eight Ways to Improve Staff Motivation or How to Mend Broken Morale

Ten Tips and Best Practices for Accurate Task Estimating