Why I created TechEditor. A developer's story

My name is Vitalii Artomov. I am the founder of Dystlab and the chief architect of TechEditor. But I'm not a programmer in the traditional sense. I am an engineer who, for over 20 years, faced the same problems you do — routine, calculation errors, and constant switching between different software. At some point, I decided to create the tool that my team and I so desperately needed.

This article isn't just a description of TechEditor. It's my story and the answer to the main questions: what is the purpose of this program, and why was it created?

How It All Began

The development of TechEditor, this hybrid text-and-math editor, started in late 2018. But the idea was born much earlier — I just didn't know how to approach it for a long time.

My professional journey began in the fall of 2004. As I was finishing university, I already knew I wouldn't work in construction or a design firm but would pursue a postgraduate degree. So, for the next 10 years, I worked at the university department — researching the mechanics of civil structures (bridges), writing my dissertation, speaking at scientific conferences, and teaching students. And, of course, I continued to learn myself.

I worked in a small team of enthusiasts and self-taught individuals, studying the dynamics of bridges and their interaction with trains. Over 10 years, we processed a vast amount of scientific and technical information. We used a wide range of software tools: CAD, CAE, mathematical packages, spreadsheets, and programming languages. And office software, of course.

Department of Bridges, Dnipropetrovsk National University of Railway Transport named after Academician V. Lazarian (now UDUNT), 2013

Software Doesn't Save You from Manual Labor

Despite the powerful functionality of the programs we used in our scientific work, I was surprised (and sometimes annoyed) by the amount of manual labor that couldn't be automated.

For example, the data we obtained from calculation programs had to be manually transferred to spreadsheets. Or the formulas we used in mathematical packages had to be retyped from scratch in an office program (partly to meet the requirements of scientific journals and standards control). In short, there was a lot of manual work.

Things weren't smooth with office suites either. For instance, I had to abandon automatic section and formula numbering in my dissertation and redo it all manually because a third-party plugin I relied on failed at a certain point, corrupting the entire structure in Word. This taught me a lesson that some technologies do more harm than good.

The more scientific work I did, the more I thought about the need for a universal environment that would integrate at least text and basic calculations.

In the early 2010s, technological development became increasingly noticeable, partly due to vendors moving online. Updated versions of many classic engineering and scientific programs were released. But the dream editor for full-fledged development of text documentation with built-in mathematics was still not on the horizon.

Engineering Practice

In 2014, I started my own business and began to practice actively. I participated in various engineering projects in Ukraine, Europe, and Canada. I taught, consulted, and managed.

There were projects involving residential buildings, shopping centers, retaining walls, pedestrian and road bridges. New construction and reconstruction. And surprisingly, almost every task required manual calculations. Yes, not CAE (or rather, NOT ONLY CAE), but the classic, manual approach — traditional formulas from mechanics of materials, theoretical and structural mechanics. But the most "manual labor" was required for implementing empirical dependencies specified in design codes. Plus, report preparation.

These requirements became particularly noticeable during my company's work in the Canadian construction market, where we completed over 100 projects.

Observing the work of my own design department and consulting other engineering businesses, I noticed a clear difference in the work approaches between specialists of different levels. More experienced specialists are generally quite versatile: they use specialized software and easily switch to Excel or other tools. Less experienced engineers, on the contrary, almost always rely on CAE and try to avoid manual analysis.

Both approaches have their merits and seem capable of yielding positive results. In the first case, the advantage is provided by the specialist's experience; in the second, by the reliability of the software tool. That is, the engineer is safeguarded either by their expertise or by the software. But is this really the case?

As it turned out, not always. Relying on the qualification of an individual engineer, just like relying on the power of a specific program, is a pitfall that can create (and does create!) serious risks for an engineering company.

Maximum Automation — Minimum Errors

My team and I began to delve into the topic and analyzed a series of projects done in spreadsheets. The results clearly showed: even documents created by experienced specialists mostly contained inaccuracies of varying degrees of "severity".

But the issue is not just about spreadsheets.

A Gap in the Processes

The problem is systemic and doesn't matter who executes the project or where they are located — in Ukraine, Germany, Canada, or Australia. It arises from breaks in automation, switching between different tools, disruptions in the continuity of data exchange, and so on.

For example, you:

• calculated correctly in CAE but made a mistake in the spreadsheet calculations;
• wrote the algorithm correctly in the spreadsheet but made a mistake when transferring data from CAE;
• calculated correctly in CAE and wrote the formulas correctly in the spreadsheet, but made a mistake in the units of measurement;
• …

This list can be continued, but I think the general message is clear: by breaking the automation chain, an engineer, without realizing it, creates a "portal" for various kinds of errors. Some of them are not critical, while others can cause considerable damage.

The Problem Hides in the Shadows

Why is this problem not always noticeable? Because engineering calculations are a highly specialized field.

Compared to the total volume of project work (developing BIM models, preparing drawings, detailing, etc.), this is a relatively small piece of the pie. Small, and therefore often not perceived by company management as something serious. "A 10-page report? 20 formulas? Are you serious? Do it on a calculator, drop it into Word, and get the drawings ready, the client is waiting..." — unfortunately, such messages are not uncommon in many engineering companies.

Yes, there are few engineers responsible for calculations and preparing reports. Usually, this work is done by a few "lone warriors" in the company. They are rarely checked. Well, because there is simply no one to do it. This microcosm can be the sole responsibility of one person who works on the principle of "I'm used to doing it this way". And they are not very open to change.

We came to these conclusions in 2018, which was the last year of my search for a miracle tool to meet these and other needs. Of course, the search failed once again, so I decided to act. This was the start of TechEditor's development.

"An Office for an Engineer": The All-in-One Solution

Even before TechEditor’s public launch, I set quite strict requirements for it:

• a convenient and highly intuitive text editor (we are all very used to Word);
• high quality and convenience of formula input (ideally, formulas should look like they do in a textbook);
• built-in automatic calculations (for any analytical formulas, not tied to a specific industry);
• support for units of measurement;
• support for programming languages;
• the ability to build algorithmic schemes, graphs, diagrams;
• and more.

Of course, initially, TechEditor did not have most of these features — they were added gradually. The first versions were used only for my company's internal tasks, but eventually, we presented this software product to the general public.

The TechEditor Word Processor

Since TechEditor is designed for developing text documentation, I tried to make its interface as close as possible to existing office programs. The idea was simple: an engineer shouldn't have to spend time learning the program — they should be able to start writing a report as soon as the program is on the screen.

Formulas in LaTeX

Remembering the problems with formulas in Word and other office suites, we at Dystlab looked for a more reliable solution. And it already existed in the tech world even before personal computers appeared in the post-Soviet space: LaTeX.

I recall being skeptical about LaTeX at first: would a user want to dive into this scripting language just to type a few formulas? But I was wrong. We conducted a series of tests that clearly showed that LaTeX is learned very quickly: even unprepared (non-technical) specialists could generate formulas in the required notation in minutes.

Formulas created in LaTeX do not change their position or formatting; they "don't fly off." They are, in the literal sense, "rock-solid" formulas.

So the bet on reliability paid off 100%, but another advantage was added — interoperability. Since LaTeX is the de facto world standard for formatting technical and scientific documentation, such formulas are easy to transfer and view in other programs. And in the context of neural networks and large language models, we have another bonus: artificial intelligence is fluent in LaTeX syntax and can generate formulas of almost any complexity in this language.

Calculations Within the Document Body: Excel vs. Mathcad

As a long-time user of Excel and Mathcad, I have immense respect for these tools. They have been trusted tools for engineers for decades. But there are nuances.

In spreadsheets, I personally lack "flexibility". When you work with large volumes of text, cells become a significant limitation. Yet, the main obstacle for teamwork (and often for individual work) is their address-oriented nature — it's hard to see the expression for calculating stress in a beam, "N/A+M/W," behind the formula "C3/C4+C5*100/C6":

But we want it to be like this:

N=10 kN
A=16 cm^2
M=25 kN m
W=300 cm^3
σ=N/A+M/W

This appearance is provided by another tool — Mathcad.

Mathcad has a powerful and intuitive mathematical engine, which is why users all over the world love it. It works with standard mathematical notation, not cell addresses, so it's no wonder this program is still considered one of the industry leaders.

But Mathcad still has a limitation related to data format.

If we enter a parameter into a calculation (x=1), it always appears on the screen explicitly. And you can't display something else instead (perhaps something more appropriate). This limits the user in naming: from a readability and general understanding perspective, instead of "σ," it would be logical to write something like "total_stress" (as is done in programming). But turning a technical report into program code with long variable names is not acceptable, so users of Mathcad and similar products denote variables and functions according to generally accepted rules in science and engineering, i.e., with a single letter.

The Principle of Information Separation

The main problem with many existing programs is that they force us to adapt the report to the program's logic, not the other way around. You get a technically correct but "lifeless," unreadable document. Which, moreover, often does not comply with the corporate style or contradicts documentation standards (e.g., local or industry codes). Or both.

I wanted to change that, so I based TechEditor on the principle of information separation. In short, it allows you to fully control the appearance of the report, making it exactly as experts and clients are used to seeing it. The "internal kitchen" of the calculations remains inside, while a perfect, canonical result is displayed on the outside.

Here is what the calculation structure in TechEditor might look like:

AXIAL_FORCE=10 kN
BENDING_MOMENT=25 kN m
SECTION_AREA=16 cm^2
SECTION_MODULUS=300 cm^3
σ = AXIAL_FORCE/SECTION_AREA + BENDING_MOMENT/SECTION_MODULUS

Looks a lot like program code, doesn't it? But look what happens on the screen:

For skeptics of this approach, there is always the option to work with short names. I will only note that TechEditor uses Unicode, so Greek, Cyrillic and other names for variables and units (even in combinations from different alphabets) are perfectly acceptable:

I want to emphasize again — in the vast majority of mathematical packages, we cannot "intervene" in the data presentation format. TechEditor solves this problem by separating input and output expressions. In the input blocks, variables and functions are defined, and the output is what we see on the screen.

Therefore, in TechEditor, we can:

• Display the variable, its formula, intermediate values, and the result — in any combination of these elements;
• Display the result and intermediate values with arbitrary units of measurement or without them at all;
• Display only part of the expression, shortening it to the required format.

This approach allows for a canonical, literally "textbook" format for the report

Arbitrary Data Representation

I actively use the input/output separation mechanism to make the parameters in the report look as "natural" as possible — the way most engineers and scientists are used to and expect to see them.

For example, our document may feature coefficients that are usually denoted in the literature by the letter "γ". The coefficients are different, but the notation is the same. To distinguish these coefficients in the calculations, it is enough to give them different names in the "input" section:

γ1=1.1
γ2=1.2
γ3=1.3

But the reader of the report does not expect to see such coefficients — they are used to a simple "γ." The presence of indices or other symbols would create an additional burden and force them to spend time understanding the developer's logic. We shouldn't mislead the reader just because our software can't do it any other way!

This is the difference between TechEditor and other programs. We write the expressions "γ1=1.1", "γ2=1.2", "γ3=1.3" in the "input" sections, and the "output" section in all three cases contains the familiar symbol "γ." Visually, it looks as if the same coefficient "γ" appears in different places in the report with the required value.

This seems like a simple and expected "behavior" of a document, but surprisingly, it is so difficult to achieve in the absolute majority of programs for creating technical documentation.

Programming, Diagrams, and Other Unique Features of TechEditor

Having a mathematical engine in our technological age does not make a program unique. What truly distinguishes TechEditor from its counterparts are the automation elements.

Once, engineers calculated on arithmometers, and electronic calculators were considered a real breakthrough. Later, computers allowed for the calculation of complex algorithms, chains, and sequences. We began to manage data through convenient automation elements and achieved significant results in this.

But the engineering documentation itself did not benefit from this: its quality worsened. A paradox, but a fact: the speed, convenience, and efficiency of calculations lead to a decrease in the quality of report preparation.

A simple example: by adding a trackbar to our document in Mathcad, we can quickly change the value of a parameter, instantly updating the entire document. Very convenient! But this element is not "natural" for materials that will be printed or exported to PDF. The same goes for screenshots, which engineers massively add to their reports without any explanations or comments, creating a real "graphical hell" in text documents.

I am convinced that now that we have finally reached the required technological power, it is time to look back and remember the times when text documentation was prepared thoughtfully and did not contain unnecessary, extraneous objects.

TechEditor is based on the concept of "nothing superfluous in the report." That is why automation objects such as a slider, selector, or checkbox look like ordinary variables in the report. To activate, for example, a slider, the user double-clicks on the parameter — the slider appears on the screen in a separate window. Then the user can control the value by moving the slider with the mouse cursor or keyboard arrows. After finishing such a convenient "tuning," the user closes the window, and the slider disappears, while the variable remembers the current value and remains in the report in its place. The "nothing superfluous in the report" concept works!

The Future of TechEditor: Artificial Intelligence and What to Do with It

We had barely managed to comprehend and systematize our technological achievements when we received a new shock. The rise of Artificial Intelligence took us all by surprise.

As an engineer and scientist, I already see the problems of the primary, thoughtless, and superficial use of ChatGPT and other language models in engineering projects. By generating content based on a probabilistic approach, many specialists around the world risk falling for beautifully designed but erroneous content. This is a huge problem that requires our attention.

As a software developer, I understand the inevitability of progress and the incredibly high potential of neural networks. Therefore, the latest versions of TechEditor already include integration with the most famous language models — ChatGPT, Gemini, Grok, Claude, and others. But we are focusing not so much on automatic content generation (chats can do that anyway) as on the verification of algorithms, formulas, units of measurement, and other "hard" tasks generated by artificial intelligence. The new positioning is: generate with AI, verify with TechEditor.

But the quality of report preparation in the AI era remains in question. Do language models help engineers to better prepare text materials, or do they, on the contrary, push them towards quick copy-pasting? And will engineering reports as such make sense in the future?

We will explore these and other questions further. After all, the story of TechEditor does not end here — we have a long and interesting journey ahead. I invite you to join this journey with us!

If my story resonated with you or you have your own thoughts on this matter, I invite you to a discussion in our Discord community. I would be happy to continue the dialogue.