DEV Community: Timo

Streamline Your LaTeX Workflow with Docker and VS Code: The Ultimate Setup Guide

Timo — Tue, 16 Sep 2025 13:30:00 +0000

As many other students I had to write my Bachelor thesis in Latex. So I had to choose between Overleaf, the complete integrated tool for Latex work, or setting up some local writing environment myself. As I wanted to have full control over my setup and sync my work across multiple devices using Git (which is also available in a paid subscription of Overleaf), and I also kinda hate myself a bit, I decided to go with the local setup.

As the work was growing more and more in terms of pages and the compilation got slower and slower, I had to think of some ways to improve and optimize the build process to make it more comfortable for me.

TL;DR

The general suggestion is to use as much precompilation as possible to avoid double compilation and therefore significantly speed up the document build process. Use the draft mode to avoid the need for rendering the entire document in the first compilation steps. A possible pipeline setup that performed really good for me is as follows:

pdflatex precompile preamble
pdflatex draft
bibtex
makeglossaries
pdflatex draft
pdflatex final

With that I was able to achieve about 1 second per page compilation time on a 60 page document with many large images.

Checkout the GitHub repository for the complete setup.

Compiling LaTeX Documents in the Earlier Days
The Standard Workflow Today
Measures and Benchmarks
Optimizations
Dockerizing the LaTeX Build
Setting up VS Code for LaTeX Development
Additional Notes
Summary and Results

🕰️ Compiling LaTeX Documents in the Earlier Days

As Martin Isaksson [1] described in his article, compiling LaTeX to PDF used to require several separate steps that are largely avoidable today. You would typically run latex to produce a DVI file, convert that to PostScript with dvips, and finally produce a PDF using ps2pdf.

Later dvipdfm and dvipdfmx simplified this process a bit by allowing direct conversion from DVI to PDF. The introduction of pdflatex and xelatex simplified the workflow even more by allowing the direct compilation of LaTeX files to PDF.

⚙️ The Standard Workflow Today

Today we usually use pdfLaTeX (or its alternatives) in a larger process that typically includes multiple compilation steps. The exact sequence depends on document complexity and packages, but a common pattern is: [1]

pdfLaTeX parses the source and generates an .aux file containing information about citations, cross-references, and glossary entries.
BibTeX processes bibliography data and generates a .bbl file with formatted references.
pdfLaTeX incorporates the generated .bbl into a full document, still containing unresolved citations and references "[?]".
One or more additional pdfLaTeX runs resolve cross-references and finalize the PDF output.

Fig.1 - The standard build steps today

📄 `pdfLaTeX`

This is the core tool in the described process. It uses pdftex under the hood to compile LaTeX documents directly to PDF files. Alternatives that you might now are XeLaTeX and LuaLaTeX. First of all it generates a structure of the document described in the .tex and .sty files If you don’t provide any other arguments, by default it will also generate images and markup information and output it to a PDF file.

📚 `BibTeX`

Also an important to note tool, that is used to manage bibliographies and citations in LaTeX documents. It reads the bibliography information from the .bib file and the citation information from the .aux file, and generates a .bbl file that contains the formatted bibliography. bibtex works well together with pdflatex to ensure that all citations are correctly formatted and included in the final document.

📊 Measures and Benchmarks

In order to evaluate the optimizations I propose, I created a small benchmark script based on the template that I will provide later. The benchmark is also included in the GitHub repository. It uses a Docker container that encapsulates all dependencies and ensures a consistent environment for the tests (as far as that is even possible). The benchmark script measures the time taken for each step of the LaTeX build process so we can quantify the impact of each optimization.

The machine used for the tests had the following specifications:

Hardware: AMD Ryzen 7 PRO 4750U with integrated Radeon GPU, 32 GB RAM, Samsung 980 1 TB NVMe.
Software: Windows 11 24H2, TeX Live 2024 Docker image with pdfTeX 3.141592653-2.6-1.40.26.

Using this system and the described benchmark we get the following results for the template document containing 18 pages:

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 30.778 seconds}\newline \textsf{\textbf{Average build time per page:} 1.710 seconds} \end{array}% }$

Thirty seconds are still pretty usable, but there is definitely room for improvement. And also keep in mind that these results will increase with growing document size.

Fig.2 - Today's build steps on a timeline

🛠️ Optimizations

So now let’s go through all the optimizations I tested and adopted to speed up the LaTeX build process step by step.

📑 Introduction to `makeglossaries`

makeglossaries is a Perl script that generates an index of glossary entries for later generation of the glossary itself, but also the list of acronyms and all necessary cross-references. The tool is part of the glossaries package and will be executed automatically during the LaTeX build process.

Calling makeglossaries explicitly during the build lets us pre-generate these indices and avoid re-generating them during repeated pdfLaTeX runs, which speeds up the overall process. To use it we just have to use other declaration commands for the creation of glossaries and of course call the makeglossaries command in our build process.

Typical changes when switching from the no-index approach are:

Replace \makenoidxglossaries with \makeglossaries.
Replace \printnoidxglossary with \printglossary.

So of course I ran the benchmark with this change and produced the following results:

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 16.710 seconds}\newline \textsf{\textbf{Average build time per page:} 0.928 seconds}\newline \textsf{\textbf{Speed increase:} 45.7\%} \end{array}% }$

📋 Preamble Precompilation

Precompiling the preamble is one of the most effective ways to speed up LaTeX compilation [2]. The preamble (everything before \begin{document}) usually contains many package imports and definitions. Compiling these takes most of the time. So by precompiling them beforehand we save us some time in the later repeating steps. [3]

The preamble can be stored in a separate file or kept in the main document and dumped into a format file (.fmt) using format-dumping utilities. The resulting .fmt file is then loaded by pdfLaTeX, which avoids reprocessing package code on each run. [1]

pdflatex -ini -jobname="thesis" "&pdflatex" mylatexformat.ltx thesis.tex
pdflatex "&thesis" thesis.tex
Listing.1 - PdfLaTeX commands for using a preamble precompilation

Note that not every package is compatible with precompilation; test your document thoroughly after adopting this strategy.

As described before, this precompilation speeds up the overall process significantly. This is also shown by the following benchmark results:

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 13.160 seconds}\newline \textsf{\textbf{Average build time per page:} 0.731 seconds}\newline \textsf{\textbf{Speed increase:} 57.2\%} \end{array}% }$

So we already achieved a reduction in build time by the half of the original time. Not that bad.

🎛️ pdfLaTeX Commandline Arguments

There are some special command line arguments for pdfLaTeX that we can utilize to make our doument compilation faster and more efficient.

One of them is the "-interaction=batchmode" argument, which suppresses all interaction with the user [1], [2], [3]. This means that if there are any errors or prompts, pdfLaTeX will not stop to ask for input, making it suitable for automated builds. If you want to see the errors, you will have to open the log file, which will be generated nevertheless. But all the writing to the user terminal takes so much time that we can save by suppressing it. This leads to the following benchmark results:

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 13.225 seconds}\newline \textsf{\textbf{Average build time per page:} 0.735 seconds}\newline \textsf{\textbf{Speed increase:} 57.0\%} \end{array}% }$

Another useful flag is the "-draftmode" argument [1], [2], [3]. It tells pdfLaTeX to compile the document only draft wise, which means that it won’t generate the whole document. Instead it just generates some auxiliary files and uses the constraints of the document class to create a fast preview. This significantly reduces the compilation time as you can see:

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 16.171 seconds}\newline \textsf{\textbf{Average build time per page:} 0.898 seconds}\newline \textsf{\textbf{Speed increase:} 47.5\%} \end{array}% }$

📚 Using `biblatex`

Replacing BibTeX with biber as the backend for bibliography processing via the biblatex package is another avenue for optimization. biblatex offers a more modern and flexible interface for bibliographies and can reduce the number of required compilation steps in many cases.

I did not pursue this approach for the current project because it would have required restructuring bibliography handling across the document. Still, it is a promising option for future improvements.

🚀 New Compilation Process

After trying out all the different approaches, combining the techniques above yields a new compilation pipeline that balances speed and reliability. The adopted steps are as follows:

pdflatex precompile preamble
pdflatex -interaction=batchmode -draftmode
bibtex
makeglossaries
pdflatex -interaction=batchmode -draftmode
pdflatex

How these steps are connected together can be seen in the following process overview:

Fig.3 - Build process with optimizations

Of course the most important thing in this comparison are the benchmark results. These results clearly show the improvements achieved by the new process.

$\small \boxed{% \begin{array}{l} \textsf{\textbf{Total build time:} 9.212 seconds}\newline \textsf{\textbf{Average build time per page:} 0.512 seconds}\newline \textsf{\textbf{Speed increase:} 70.1\%} \end{array}% }$

Fig.4 - The optimized build steps on a timeline

🚢 Dockerizing the LaTeX Build

A very important point is the topic of installing all tools and dependencies for Latex. As I wanted to make the setup as reproducible and easy as possible (and didn’t want to install all those programs manually), I decided to use Docker for this purpose. You probably already know Docker. It’s a technique to encapsulate a whole environment, including all dependencies, you need for running an application inside a container. These container use images that define the environment’s configuration and structure. For Latex there are already some prebuilt Docker images you could use [4]. I chose the texlive/texlive:latest image from Docker Hub. This delivers for example pdflatex, bibtex and makeglossaries already installed. So instead of using the tools locally, I can run the docker container providing the same command that would normally execute in commandline [4].

docker run --rm -v "%WORKSPACE_FOLDER%:/workdir" -w /workdir texlive/texlive:latest pdflatex thesis
Listing.2 - Example for running PdfLaTeX through Docker

🧑‍💻 Setting up VS Code for LaTeX Development

So now that we have a Docker container set up for our LaTeX development, we need some text editor or IDE to write in it. For this purpose, I chose Visual Studio Code (VS Code) as it has excellent support for LaTeX through extensions. The main extension for overall Latex support is LaTeX Workshop [5]. Using it you can setup pipelines and shortcuts for building your LaTeX documents efficiently. [6]

VS Code provides an easy solution for managing settings and configurations for your projects. You can configure project-specific settings to customize the behavior of the editor and the LaTeX Workshop extension by creating a .vscode/settings.json file in the repository [6]. This settings file can be transferred to other computers and shared with collaborators, ensuring a consistent development environment with the same configuration across different machines.

📝 Additional Notes

For easy reuse I created a template in a GitHub repository that you can fork or clone and use by yourself. It comes with some special additional scripts and tools to enhance your LaTeX development experience even further:

Automatic PlantUML diagram generation using the FileWatcher extension for VS Code.
Scripts that detect unused/unreferenced labels and figures in your document.
A script for PDF compression using pdfsizeopt.
Scripts for Markdown conversion using either Pandoc or Poppler utilities.

🔎 Further Possibilities for Experimentation

There are some topics that might be worth looking into them deeper.

For example some other build drivers like latexmk or arara could be explored to see if they offer any advantages over the current setup. They might provide more flexibility or additional features that could further optimize the build process. [1]

For users of TikZ and PGFPlots, consider precompiling heavy diagrams to PDF. The pre-generated graphics can then be reused in subsequent runs to speed up compilation. [2], [3]

If you include many large images, add an image-processing pipeline: Downscale images to the display size used in the document and convert raster images to appropriately compressed JPEGs, or prefer vector formats (PDF/SVG) where possible. These changes could significantly reduce build time. [2]

💡 Tips and Tricks collection

A brief set of miscellaneous suggestions from the literature. I did not need all of these, but they may be helpful in your contexts [2].

Consider removing todonotes for performance-sensitive builds as it relies on TikZ and can noticeably slow compilation.
Maintain two image variants (high-resolution for final builds, low-resolution for drafts) and switch between them in your build pipeline to speed iteration.
Avoid loading heavy math packages unless your document requires their specific features.
Be cautious mixing inputenc and fontenc as it results in slower compilation.

🧾 Summary and Results

This article addresses a common and stubborn problem: a growing LaTeX project whose edit-compile cycle becomes progressively slower as content accumulates. Rather than resigning ourselves to perpetual waiting (and an unhealthy relationship with coffee), we instrumented the build, measured bottlenecks, and evaluated targeted, low-risk optimizations. In brief: precompiling the preamble and indices, applying a few well-chosen pdfLaTeX flags, and using a reproducible, containerized build yield substantial time savings.

Key numerical results from the template benchmark (18 pages):

$\boxed{% \begin{array}{l} \textsf{\textbf{Baseline total build time:} 30.778 seconds (1.710 s/page)}\newline \textsf{\textbf{Combined new pipeline} (precompile + flags}\newline \textsf{+ prebuilt indices): 9.212 seconds (0.512 s/page);}\newline \text{roughly a 70\% speedup compared to baseline.} \end{array}% }$

Practical takeaways (what to do now):

Precompile the preamble where possible. It removes repeated package processing and usually gives the largest single win.
Pre-generate indices and glossaries (makeglossaries) instead of regenerating them on each run.
Use pdfLaTeX flags in automated builds (-interaction=batchmode) and -draftmode during interactive iteration for faster feedback.
Consider modern bibliography tooling (biblatex+biber) and precompiling heavy TikZ/PGFPlots figures into PDFs for repeatable speed improvements.
Containerize the build (Docker) to make results reproducible across machines and CI.

See the repository README for the LaTeX template, Docker instructions, and the benchmark scripts.

tim0-12432 / latex-vscode-docker-template

A template implementing some optimizations to the standard Latex compilation process using VS Code and Docker containers

Latex Template

implementing some build process optimizations using VS Code and Docker.

Usage

Requirements: VS Code, Docker, Python

Clone or download the repository
Open folder with VS Code
Copy the keybindings from within .vscode/keybindings.json into the VS Code shortcuts (Ctrl+K Ctrl+S)
Apply changes to the LaTeX document
Hit Ctrl+Alt+S
Observe the build process
Open the generated PDF to view the results

You can also use this template directly through GitHub.

Implemented features

Pregenerate glossaries separately
Precompile the preamble
Use draft mode the first runs
Disable console output

Change requests, proposals or other contributions

Feel free to contribute by opening issues or pull requests if you see some ways for further improvement.

View on GitHub

I hope this deep dive into LaTeX compilation helps you speed up local LaTeX writing and provides a practical alternative to Overleaf.

Happy compiling.

[1] M. Isaksson, “Optimizing Your LaTeX Workflow: A Guide to Choosing a Build System,” Martin’s blog. Oct. 2023. Accessed: May 04, 2025. [Online]. Available: https://blog.martisak.se/2023/10/01/compiling/.
[2] L. B. Tables, “Speeding up LaTeX compilation,” TeX - LaTeX Stack Exchange. Jul. 2016. Accessed: May 04, 2025. [Online]. Available: https://tex.stackexchange.com/questions/8791/speeding-up-latex-compilation.
[3] T. Zorman, “Speeding up LaTeX compilation.” Jan. 30, 2025. Accessed: May 04, 2025. [Online]. Available: https://tony-zorman.com/posts/speeding-up-latex.html.
[4] M. Isaksson, “How to annoy your co-authors: A Gitlab CI pipeline for LaTeX,” Martin’s blog. May 2020. Accessed: May 04, 2025. [Online]. Available: https://blog.martisak.se/2020/05/11/gitlab-ci-latex-pipeline/.
[5] Fabian, “VS Code + Docker + LaTeX Setup,” Medium. Jan. 2020. Accessed: May 04, 2025. [Online]. Available: https://medium.com/@kombustor/vs-code-docker-latex-setup-f84128c6f790.
[6] T. J, “LaTeX + VS Code + Docker = 🚀. How to use LaTeX without installing…,” Medium. Sep. 11, 2025. Accessed: May 04, 2025. [Online]. Available: https://medium.com/@timju/latex-setup-with-vs-code-and-docker-612f998e1f23.

Markdown blog with Appwrite connection

Timo — Thu, 05 May 2022 21:55:44 +0000

Overview of My Submission

I wanted to learn NextJS for a longer time now and started the development of a concept of a markdown blog. When the team of appwrite and dev.to came up with this hackathon I decided to participate by adding an appwrite functionality to this blog. My idea was to store the mdx files, which are originally stored in the posts directory, in the appwrite storage database. I am programming for nearly a month now and it's finally done. You just need an appwrite container and my markdown-blog image containerized. Additional information about configuration and setup can be found in the README.md

On the technological hand I am using NextJS with dynamic frontend rendering, next-MDX-remote for mdx parsing and TailwindCss for styling.

Submission Category:

Web2 Wizards

Link to Code

tim0-12432 / markdown-blog

Markdown blog

Markdown Blog

Motivation

I wanted to learn NextJS for a few months. Now the time have come and I created a server for displaying markdown blog posts. So this is my first project using NextJS.

When noticing the new appwrite hackathon, I decided to add a feature to store your markdown post files in a appwrite database.

Installation and usage

Prerequisites

If you are planning to add posts via the Appwrite Database capability, you need to have a Appwrite instance running on your local machine or on a server.

Files should be stored in a bucket in the storage and their ids must match the file name in order to be found!

Configuration

configuration.json in config
- Example AppwriteDB

    "appwriteDatabase": {
        "url": {
            "host": "localhost"
            "port": 3000
        },
        "projectId": "YOUR_PROJECT_ID",
        "postBucketId": "YOUR_POST_BUCKET_ID",
        "apiKey": "YOUR_API_KEY

…

View on GitHub

Additional Resources / Info

License

MIT

Appwrite dashboard

Storage bucket

Markdown files

Homescreen

TimoFollow

Quickstart template with CI for React project

Timo — Fri, 12 Nov 2021 16:59:48 +0000

My Workflow

I created a template project for using the GitHub workflow with a example React project.
The workflow itself is inside the repository: production.yml

Input:

pull-request on main branch
manual dispatch

Output:

1.0.0-information.zip containing coverage and license report
deploys build files directly on GitHub Pages
creates a tag and a release and pushes the build files to the release

Submission Category:

DIY Deployments

Yaml File or Link to Code

tim0-12432 / react-ci-template

A template for react projects with includes linting and github actions workflow.

CReactApp Template with CI

This project was bootstrapped with Create React App.

Usage

To change the content of the page, just change the files in the public and src directories.

Available Scripts

In the project directory, you can run:

`npm start`

Runs the app in the development mode on http://localhost:3000.

`npm test`

Launches the test runner in the interactive watch mode.

`npm run build`

Builds the app for production to the build folder.

`npm run eject`

Note: this is a one-way operation. Once you eject, you can’t go back!

If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.

`npm run ci:test`

CI: Runs the test runner in the continuous integration mode.

`npm run ci:licenses`

CI: Generates the license report as a csv-file.

`npm run lint:es`

CI: Runs the…

View on GitHub

name: Production

on:
  workflow_dispatch:
  pull_request:
    branches:
      - main

jobs:
  Linting_and_tests:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node: [14.x, 15.x, 16.x]

    steps:
      - name: git checkout
        uses: actions/checkout@v2

      - name: install node
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node }}

      - name: get version
        id: package-version
        uses: martinbeentjes/npm-get-version-action@master

      - name: install dependencies
        run: |
          npm install
          npm install -g license-report

      - name: eslint
        run: npm run lint:es

      - name: stylelint
        run: npm run lint:style

      - name: run tests
        run: npm run ci:test

      - name: licenses
        run: npm run ci:licenses

      - name: upload artifacts
        uses: actions/upload-artifact@v2
        with:
          name: ${{ steps.package-version.outputs.current-version }}-information
          path: |
            coverage/
            licenses.csv
          if-no-files-found: error

  Build_and_deploy:
    runs-on: ubuntu-latest

    steps:
      - name: git checkout
        uses: actions/checkout@v2

      - name: install node
        uses: actions/setup-node@v2
        with:
          node-version: 16.x

      - name: get version
        id: package-version
        uses: martinbeentjes/npm-get-version-action@master

      - name: install dependencies
        run: npm install

      - name: build
        run: npm run build

      - name: zip build files
        uses: montudor/action-zip@v1
        with:
          args: zip -qq -r build.zip build

      - name: deploy
        uses: JamesIves/github-pages-deploy-action@4.1.1
        with:
          branch: built-page
          folder: build

      - name: release
        uses: avakar/tag-and-release@v1
        with:
          tag_name: v${{ steps.package-version.outputs.current-version }}
          release_name: v${{ steps.package-version.outputs.current-version }}
        id: release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: upload binaries to release
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          asset_path: build.zip
          asset_name: built-page-ready-to-deploy-v${{ steps.package-version.outputs.current-version }}.zip
          asset_content_type: application/zip
          upload_url: ${{ steps.release.outputs.upload_url }}

Additional Resources / Info

So what actions did I use in my workflow and what do the different steps in my yaml file?

Linting and tests

actions/checkout@v2: checks out the current branch
actions/setup-node@v2: installs few versions of NodeJS
martinbeentjes/npm-get-version-action: gets the current version of the package
npm install: install the dependencies used by the package
npm run lint:es: runs linter for JS-files
npm run lint:style: runs linter for stylesheets
npm run ci:test: runs tests
npm run ci:licenses: gets the licenses from used packages
actions/upload-artifact@v2: uploads the generated reports as an artifact

Build and deploy

actions/checkout@v2: checks out the current branch
actions/setup-node@v2: installs NodeJS 16
martinbeentjes/npm-get-version-action: gets the current version of the package
npm install: install the dependencies used by the package
npm run build: builds the app for production
montudor/action-zip@v1: zips the build folder
JamesIves/github-pages-deploy-action@4.1.1: deploys the build to GitHub Pages
avakar/tag-and-release@v1: creates a tag and release
actions/upload-release-asset@v1: uploads the build files to the release

.ltag__user__id__687996 .follow-action-button { background-color: #000000 !important; color: #b8ffff !important; border-color: #000000 !important; }

TimoFollow

Created with ❤️ by Timo

Do not put skill bars on your resume!

Timo — Wed, 10 Nov 2021 21:10:00 +0000

I see a lot of programming beginners doing webdev-projects building skill bars. When I was starting and done programming for about one or two years, in my perception skill bars were common sense to show your skill level. So in a result, something similar to this (Fig.1) had found its way onto my first real resume.

Fig.1 - Skill section on my resume

Nowadays, I think skill bars are an illogical style of presentation and completely meaningless.

Visually attracting

A few years ago, my opinion was completely different. I thought, skill bars are a cute-looking point system and a creative way to visualize your skills.

Meaningless

But even if it looks cute, it is completely meaningless.
When creating a skill bar you are also creating some kind of point scale system, e.g. 10 points, 5 points or 100 percent.
But how do you compare your skills to that? To rate your skills equally on your scale, you would need to create some sort of criteria and equal tests for each one which measures the skill on your 10 point - or whatever - scale.

When not showing your criteria, the employer will not know what the criteria for your rating were. Do you even know?
Also, the point system makes no sense.

Example: English 4/5

Answer one question: What is the difference between 3/5 and 4/5?
I don't know, probably there is no difference because the points mean nothing.

Equal difficulty

Seeing such skill bars gives the impression that every skill has the same difficulty.

Example:
    Java 4/5
    Python 3/5
    HTML 5/5

Basically saying it's a unique point scale comparing completely different languages or skills on that scale, no matter of difference in quality and difficulty.
It makes no sense!

Shows design skills

Some people say skill bars show web-development or design skills because
graphics like skill bars stand out of the application or resume and maybe bias the employer positively.
But even people on Reddit dislike this trend!

Waste of space

Skill bars use a lot of space which could be used much better, e.g. to provide more information about your skill set. When considering graphics can't be read by machines (ATS systems), skill bars seem to be quite a large waste of space.
Also, graphics on a resume distract from the professional appearance of your resume and make it look more like a flyer - what you probably not want.

Subjective and unreliable

But the biggest issue with skill bars is that they are subjective and unreliable because people are bad in rating themselves.

According to Emilie Thewon, a Marketing and Business Development Director,"self-evaluating their own performance, competences and skills is flawed and inaccurate" for the most people.
Studies show that intelligent people often think deeper about the problem and rather rate themselves lower for tasks they are good at, where less intelligent persons or people who have less expertise in a certain topic rather rate themselves higher than an objective rating would be.

Fig.2 - Most common lies on job applications according to CNBC (https://www.cnbc.com/2020/02/19/how-many-job-seekers-lie-on-their-job-application.html) originally from Checkster (https://www.checkster.com/are_you_hiring_charlatans)

To accomplish this, many people cheat in their resume to have a favorable effect on the employer. As you can see in Fig.2 misrepresenting yourself in the application seems to be almost normal nowadays.

Solutions

In my opinion the only thing what matters in the skill section is what you have worked with before.
So a better practice is just listing your skills and show your exact skill level suitable to the type of skill, e.g. "basic", "proficiency level" or "experienced". Also, you can add facts like certifications, degree or licenses.
If your resume is online you can show projects, link them and maybe add what you used to complete that projects.

People using skill bars are "generally quite intelligent but have very poor social skills and lack self-awareness" ~ Brian Grubba, District Manager

Please feel free to write your opinion in the comment section!

TimoFollow

GitHub: tim0-12432

Why it is not important what programming languages you know in 2021

Timo — Sat, 23 Oct 2021 18:52:27 +0000

There are about 8945 programming languages out there existing. When speaking of notable widely used languages, there are about 245 of them. According to Wikipedia there are about 130 web-frameworks extending the feature set of the most used languages.

If you know every language and are able to use it properly, you are a genius. In my opinion, it is even impossible to know every framework. So let's think the other way round. When it does not matter what programming language you know, it might be better to learn understanding technical patterns and paradigms and adapt these learning languages or techniques quickly, because they are too many to know all.

The amount of languages and frameworks is simply too large that it is even impossible to achieve basic knowledge in every one of them.

Fig.1 - Most important programming languages over time according to tiobe at https://www.tiobe.com/tiobe-index

Even if it were possible, the feature set and diversity of languages evolves so fast you would have to learn more than 24/7 to keep being updated. As you can see in figure 2 the average update amount of the three languages is one per year. Java gets even two new versions per year since 2018. The updates add new features and paradigms, and let old features deprecate by changing the compiler or the structure of the standard library. So you will constantly have to stay up-to-date and learn these new things anyway, but in the same way this constant stream of new versions makes it difficult to keep updated on multiple languages or frameworks.

Fig.2 - Releases of updates for Java, Python and C# over the last 11 years

But that in my opinion is not important. All languages are pretty similar in structure and coding patterns, e.g. statements and loops. Some of them are even similar in syntax, especially if they are descended from each other.
So if you start with one language and know it well, you will feel pretty familiar with other languages as well.

# Bash if statement
if [ $1 gt 100 ]
then
    echo Your param is greater than 100!
fi

// C++ if statement
std::cin >> number;
if (number > 100)
{
    std::cout << "Your param is greater than 100!";
}

// C# if statement
int number = Convert.ToInt32(Console.ReadLine());
if (number > 100)
{
    Console.WriteLine("Your param is greater than 100!");
}

// Java if statement
int number = Integer.parseInt(System.console().readLine());
if (number > 100) {
    System.out.println("Your param is greater than 100!");
}

# Python if statement
number: int = int(input());
if number > 100:
    print("Your param is greater than 100!")

Decisions whether to learn this language or that are really pointless and self-defeating.
Later, you may have to use the other language anyway.
So just learn the one which seems more suitable to you at the moment - also good advice for beginners.

It makes more sense just to learn the technique you need at the moment for a specific task. So start with the language you need for the project you want to work on and try to understand the rules and patterns of programming more than just learning the syntax of the languages.

So overall when you think about it, it is nonsense to say: "I know this language, this and that". If you ever want to say which languages or frameworks you worked with, express that you have experience in working with it. In my opinion, it's the experience that matters. If you are programming for years, you will be quite an expert in one language and adjust to a new language quickly, or you are the one who has tried a lot of languages and switched between them, so you have experience in adjusting to a new language. But from my point of view both types are on an equal level of experience and probably skills. This implies that apparently the language does not matter and what they had programmed with.

But that's good news for beginners, too.
It implies, as well, that it doesn't matter that you have no experience. By just programming, you will gain experience and expertise.

Summary

It does not matter what programming languages you know or what frameworks you are able to use or not. What matters is that you are able to learn concepts quickly and adapt them to learn new languages and techniques.

Please feel free to write your opinion in the comment section!

TimoFollow

GitHub: tim0-12432

Why copying tutorial projects does not help you to learn React

Timo — Wed, 13 Oct 2021 06:13:31 +0000

One year ago I needed React for a Project at work. I have wanted to learn it before, but I never had the time to do it. Now the time has come and I decided to dive deeper into web development with the React framework.

First of all I decided to watch some tutorials on YouTube because that's what you usually do when learning new programming things.

Fig.1 - YouTube search results for React Tutorials

My first decision was a very informative tutorial by DevEd where he shows how to develop a simple to-do app.
After that, I watched more and more tutorials and copied their projects.

In my opinion that was not the best start I could have had. By just copying and following a tutorial, you do not learn the basics. It would be better to learn concepts and understand how the framework itself works than just copy lines of code.

Comparison

Todo App

My first ever React project.
Obviously not only mine.

Fig.2 - TodoList by Chirag

Fig.3 - TodoList by Auxfuse

Fig.4 - My version of the TodoList

As you see, the difference between the compared screenshots of to-do apps is not wide.
Even if I conquered my weaker self and extended the feature set, it seems like they are a one to one copy of each other. No wonder.

Corona Tracker

In Covid-19 pandemic, I wanted to create a page where I can find all important key numbers for Germany.
For that I followed a tutorial by Javascript Mastery and extended it.

Fig.5 - Corona Tracker by JavascriptMastery

Fig.6 - My version of the Corona Tracker

The difference is a bit wider than in the above example. Most likely because of the added dark mode (#hateAgainstLightMode xD). But with a closer look you can see the components are very similar.

Better approach

Search for a good project at the skill level that suits you
Implement the idea in the way you image it
Search for solutions or best practices on the internet whenever you don't know how to achieve a certain behavior, or you want a better way of implementation
As a sideline you can watch videos explaining little concepts such as states, context and so on

Conclusion

For a first entry point to learning a new framework or language, it could help to copy a tutorial and enhance it a bit afterwards.
But after copying one or two projects, copying does not lead you to getting better, learning the technique really or understanding basic principles.
Try to write code yourself.

Please feel free to write your opinion in the comment section!

TimoFollow

GitHub: tim0-12432

DEV Community: Timo

Streamline Your LaTeX Workflow with Docker and VS Code: The Ultimate Setup Guide

TL;DR

Table of Contents

🕰️ Compiling LaTeX Documents in the Earlier Days

⚙️ The Standard Workflow Today

📄 pdfLaTeX

📚 BibTeX

📊 Measures and Benchmarks

🛠️ Optimizations

📑 Introduction to makeglossaries

📋 Preamble Precompilation

🎛️ pdfLaTeX Commandline Arguments

📚 Using biblatex

🚀 New Compilation Process

🚢 Dockerizing the LaTeX Build

🧑‍💻 Setting up VS Code for LaTeX Development

📝 Additional Notes

🔎 Further Possibilities for Experimentation

💡 Tips and Tricks collection

🧾 Summary and Results

tim0-12432 / latex-vscode-docker-template

A template implementing some optimizations to the standard Latex compilation process using VS Code and Docker containers

Latex Template

Usage

Implemented features

Change requests, proposals or other contributions

Markdown blog with Appwrite connection

Overview of My Submission

Submission Category:

Link to Code

tim0-12432 / markdown-blog

Markdown blog

Markdown Blog

Motivation

Installation and usage

Prerequisites

Configuration

Additional Resources / Info

License

Appwrite dashboard

Storage bucket

Markdown files

Homescreen

TimoFollow

Quickstart template with CI for React project

My Workflow

Input:

Output:

Submission Category:

Yaml File or Link to Code

tim0-12432 / react-ci-template

A template for react projects with includes linting and github actions workflow.

CReactApp Template with CI

Usage

Available Scripts

npm start

npm test

npm run build

npm run eject

npm run ci:test

npm run ci:licenses

npm run lint:es

Additional Resources / Info

Linting and tests

Build and deploy

TimoFollow

Do not put skill bars on your resume!

Visually attracting

Meaningless

Equal difficulty

Shows design skills

Waste of space

Subjective and unreliable

Solutions

TimoFollow

Why it is not important what programming languages you know in 2021

Summary

TimoFollow

Why copying tutorial projects does not help you to learn React

📄 `pdfLaTeX`

📚 `BibTeX`

📑 Introduction to `makeglossaries`

📚 Using `biblatex`

`npm start`

`npm test`

`npm run build`

`npm run eject`

`npm run ci:test`

`npm run ci:licenses`

`npm run lint:es`