Introduction

The Programming Task Library is a collection of practical exercises designed to improve problem-solving, analytical thinking, and software design skills.

The library is intended both for developers who are beginning their software development journey and for experienced developers who want structured technical practice.

Although the tasks were originally designed with Go and Rust in mind, the underlying problems are language-independent and can be implemented in other programming languages as well.

Purpose

The main goal of this library is not only to produce a correct result.

Each task should encourage you to think about:

• algorithmic efficiency
• execution performance
• resource consumption
• simplicity of the solution
• flexibility
• abstraction
• code organization
• reusability

A working solution is only one part of the exercise.

You should also consider whether the same problem can be solved with fewer operations, less memory, clearer abstractions, or a design that can be reused in other scenarios.

Think Before You Code

Before starting an implementation, analyze the problem first.

For more complex tasks, especially modeling tasks, it is recommended to draw the possible execution flows, relationships, states, or outcomes before writing code.

Do not immediately implement the first solution that comes to mind.

Instead:

1. Understand the problem.
2. Identify the inputs and expected outputs.
3. Consider multiple possible solutions.
4. Compare their complexity and resource requirements.
5. Choose an approach.
6. Implement it.
7. Test and evaluate the result.

The objective is not to classify a task as easy or difficult.

The objective is to find an efficient and well-structured solution for the given scenario.

Library Structure

The library is divided into two major sections:

Algorithms

The Algorithms section contains seven groups.

Each group contains five tasks, for a total of 35 algorithmic exercises.

The tasks cover different types of problems involving data transformation, searching, filtering, grouping, sorting, combinations, validation, and other forms of algorithmic processing.

Modeling

The Modeling section contains six larger tasks.

These exercises focus on designing data structures, relationships, behavior, validation rules, queries, and complete domain models.

Compared with the algorithmic exercises, modeling tasks are intentionally broader and may require multiple types, components, and operations working together.

Programming Languages

The original task library was designed primarily for:

• Go
• Rust

However, unless a task explicitly depends on a language-specific feature, any programming language may be used.

When solving a task in another language, preserve the intended behavior, constraints, inputs, outputs, and validation requirements.

Approach

Treat every task as a small engineering problem rather than only as a coding exercise.

A good solution should aim to be:

• correct
• understandable
• efficient
• testable
• maintainable
• reusable where appropriate

Different implementations may solve the same task correctly.

The important part is being able to explain why a particular approach was chosen and what trade-offs it introduces.

About Author

Nikola Djurdjevic

Backend & Systems Software Architect

Go · Rust · Distributed Scalable Systems · Infrastructure

Nikola Djurdjevic is a backend and systems software architect focused on building infrastructure, distributed services, developer tooling, automation systems, benchmarking software, and internal engineering platforms. His primary development languages are Go & Rust, with previous development experience using C++ & Java.

His work is primarily centered around backend and infrastructure software rather than application frontend development.

The systems developed as part of this work include components for:

• service management
• remote execution
• infrastructure agents
• artifact distribution
• build orchestration
• release automation
• reverse proxying
• load balancing
• documentation distribution
• system benchmarking
• hardware analysis
• deployment
• monitoring
• authentication and authorization
• distributed resource management

The common objective behind these systems is to build infrastructure that remains understandable, deterministic, independently deployable, and operational without unnecessary external dependencies.

Engineering Focus

The primary engineering focus is on systems where several independent services cooperate through clearly defined protocols and responsibilities.

Typical areas include:

• Backend Services
• Distributed Systems
• Infrastructure Tooling
• Developer Tooling
• Remote Agents
• Artifact Distribution
• Build and Release Automation
• Service Management
• Reverse Proxies
• Load Balancing
• Documentation Infrastructure
• System Benchmarking
• Hardware Detection
• Monitoring
• Deployment
• Automation

The work frequently involves networking and communication technologies such as:

HTTP/1.1 HTTP/2 REST TCP UDP WebSocket TLS gRPC

The architecture of these systems generally favors small specialized services over one large application.

A typical Scalionix system may therefore consist of several independent components:

        Client => Gateway => Service / Engine
                                     |
                                     +-- Agent
                                     +-- Registry
                                     +-- Storage
                                     +-- Worker
                                     +-- External Services

Each component owns a clearly defined part of the system.

Engineering Philosophy

A recurring design principle throughout the Scalionix ecosystem is to build the required infrastructure directly when doing so provides better control, simpler deployment, or clearer operational behavior. This has resulted in custom systems for:

• artifact distribution
• service orchestration
• remote execution
• documentation serving
• benchmarking
• reverse proxying
• deployment
• build orchestration

rather than automatically introducing large infrastructure platforms for every problem.

This does not mean avoiding existing technologies.

The objective is to understand which infrastructure is actually required and to avoid introducing dependencies whose complexity is greater than the problem they solve.

Another important principle is separation of responsibilities. For example:

        [Build System] => [Artifact System] => [Deployment / Agent System]

are related systems, but they do not need to be the same service. Similarly:

        Documentation Source
                ↓
        Documentation Build
                ↓
        Artifact Distribution
                ↓
        Documentation Server

forms a pipeline composed of independent responsibilities.

This makes individual components easier to:

• develop
• test
• replace
• deploy
• scale
• debug
• version

Scalionix

Scalionix is the current ecosystem under which a collection of backend services, infrastructure tools, developer utilities, and experimental systems are being developed. The systems are designed around a service-oriented architecture in which individual components can be developed and deployed independently. Major areas currently represented in the ecosystem include:

• Agent Infrastructure
• Artifact Distribution
• Build Orchestration
• Release Management
• Reverse Proxy Infrastructure
• Documentation Infrastructure
• System Benchmarking
• Service Management
• Automation
• Monitoring

Agent Infrastructure

A major part of the infrastructure work has involved agent-based service management and remote execution.

The general architecture uses agents installed on target machines.

These agents provide a controlled interface between central infrastructure services and the operating system running the managed services.

Conceptually:

        Management Service
               ↓
             Agent
               |
               +-- Service Operations
               +-- Script Execution
               +-- Deployment Operations
               +-- Monitoring
               +-- System Information
               +-- Resource Information

The agent model allows infrastructure operations to be executed on remote machines without requiring the central management service to directly control the operating system.

Operations developed around this model include:

• start service
• stop service
• restart service
• remove service
• retrieve service status
• execute scripts
• execute deployment operations
• retrieve system information
• monitor resource usage

The design also supports environments containing multiple:

• servers
• groups
• regions
• services

This agent-based approach became one of the foundations for later infrastructure components.

Artifact Distribution System

The Scalionix Artifact system was designed to provide controlled distribution of service binaries, tools, scripts, documentation packages, and other release artifacts.

The system is divided into specialized components.

Conceptually:

        Artifact Engine
              |
              +-------------------+
              ↓                   ↓
        Artifact Server      Artifact Gateway
              ↓
        Artifact Storage

A registry component is also part of the broader architecture.

Artifact Engine

The Artifact Engine acts as an orchestration layer.

It is responsible for coordinating artifact-related operations across one or more targets.

Targets can be organized using concepts such as:

• Sectors
• Groups
• Targets
• Items

A sector represents a larger service or infrastructure grouping. Groups represent subsets within a sector. Targets represent destination systems such as:

• artifact servers
• artifact gateways
• managed infrastructure

Items represent deployable or executable resources such as:

• artifacts
• scripts
• service packages

The Engine supports different execution patterns. Examples include:

• single-target execution
• multi-target execution
• broadcast execution

Execution can therefore be directed toward one specific target or distributed across several infrastructure nodes.

The Engine also maintains execution history and supports snapshot-oriented operations for comparing or reproducing infrastructure state.

Artifact Server

The Artifact Server provides artifact storage and retrieval. Its responsibilities include:

• artifact upload
• artifact storage
• artifact download
• authorization
• release organization

Artifacts may be organized by:

• service
• version
• operating system
• architecture
• edition

This allows the same service release to contain several independently generated binaries.

For example:

        service
        ├── linux
        │   ├── amd64
        │   └── arm64
        ├── darwin
        │   ├── amd64
        │   └── arm64
        └── windows
            ├── amd64
            └── arm64

Artifact Gateway

The Artifact Gateway provides a distribution layer in front of artifact servers.

Instead of storing artifacts itself, it can redirect requests toward available storage nodes.

The gateway supports weighted distribution behavior, allowing several artifact servers to participate in release delivery.

Conceptually:

        Client
           ↓
        Artifact Gateway
           |
           +------> Artifact Server A
           |
           +------> Artifact Server B
           |
           +------> Artifact Server C

This separates artifact storage from artifact routing.

Artifact Registry

The broader Artifact architecture also includes the concept of a registry responsible for centralized metadata and infrastructure relationships.

The registry architecture includes concepts such as:

• users
• roles
• engines
• authentication keys
• snapshots
• online engine state

This provides a foundation for managing larger installations containing multiple Artifact Engines and infrastructure nodes.

Build Orchestration

Another part of the Scalionix infrastructure is a native build orchestration system.

The build system was created to automate compilation across a matrix of:

• services
• operating systems
• architectures
• editions

A single service may need artifacts for:

• Linux [AMD64/ARM64]
• Darwin [ARM64]
• Windows [AMD64/ARM64]

and may additionally provide editions such as [Community/Enterprise].

When applied across many services, a release can produce hundreds of individual artifacts. The build orchestrator automates this process. Its responsibilities include:

• repository preparation
• build-directory creation
• build cleanup
• dependency synchronization
• build-script generation
• parallel build execution
• version stamping
• artifact packaging
• release metadata generation
• tagging
• push operations

Builds may be selected by:

• Service
• Group
• Sector

allowing both individual service builds and larger ecosystem releases.

Build Metadata

Generated services contain build information such as:

• Version
• Commit
• Build Time

This allows a running binary to identify exactly which source revision produced it.

A typical release artifact follows a deterministic naming convention containing information such as:

• service
• edition
• operating system
• architecture
• version

This provides traceability between:

        Source => Commit => Build => Artifact => Release

Go and Rust Build Infrastructure

The build infrastructure supports both Go and Rust services.

Go services can be built using options for:

• trimpath
• symbol stripping
• empty build IDs
• build obfuscation
• version stamping

Rust services use a corresponding cross-platform build pipeline.

Rust targets include environments such as:

• Linux [AMD64/ARM64]
• Darwin [ARM64]
• Windows [AMD64/ARM64]

Cross-compilation environments were created where practical, while native builds are used where platform requirements make them preferable.

The objective is for Go and Rust services to participate in the same higher-level release process even though their underlying build systems are different.

Release Pipeline

The combination of the build and artifact systems creates a larger release pipeline.

Conceptually:

        Source Repository
               ↓
        Build Orchestrator
               ↓
        Build Matrix
               ↓
        Package Artifacts
               ↓
        Artifact Server
               ↓
        Artifact Gateway
               ↓
        Target Infrastructure

This architecture keeps compilation, storage, distribution, and deployment as separate responsibilities.

Scalionix Gateway

Scalionix also includes a native reverse-proxy and gateway service.

The gateway was developed to provide:

• TLS termination
• HTTP/2
• HTTP redirects
• reverse proxying
• backend routing
• load balancing
• health checking

It can route several public endpoints toward independent internal services. Conceptually:

        Internet
           ↓
        Scalionix Gateway
           |
           +------> Website
           |
           +------> Platform
           |
           +------> API
           |
           +------> Documentation

The gateway allows internal services to remain on independent ports while presenting a unified public interface.

Backend pools can contain multiple service instances. Requests can then be distributed between healthy backend nodes. This provides a foundation for:

• redundancy
• service replacement
• horizontal expansion
• maintenance
• backend failover

without requiring clients to know the internal infrastructure topology.

Scalionix Documentation Infrastructure

Scalionix documentation is built using mdBook.

Documentation is maintained separately from application source where independent versioning and release history are useful.

This makes it possible for each service or tool to maintain its own:

• documentation repository
• documentation versions
• release tags
• build history
• language separation

rather than placing every document in one monolithic repository.

The generated documentation is static HTML. A typical pipeline is:

        Documentation Repository
                ↓
             mdBook
                ↓
              book/
                ↓
        Documentation Artifact
                ↓
        Artifact Distribution
                ↓
        Scalionix Docs Server

Scalionix Docs Server

The Scalionix Docs Server is a Go service developed for serving documentation generated by systems such as mdBook.

The original implementation supported documentation embedded directly into the service binary.

This is useful for:

• local tools
• portable documentation
• single-book applications
• self-contained binaries

However, embedding every documentation version does not scale well for a centralized documentation service.

For example:

        100 projects × 100 documentation versions × 3 MB per book ≈ 30 GB

Embedding that data would also require rebuilding the Docs Server whenever a new documentation release was added.

The architecture was therefore expanded to support a filesystem-backed documentation library.

Conceptually:

        Scalionix Docs Server
                ↓
        Documentation Library
                |
                +-- service-a
                |     +-- 1.0
                |     +-- 1.1
                |     +-- 2.0
                |
                +-- service-b
                |     +-- 1.0
                |     +-- 2.0
                |
                +-- tool-a
                      +-- 3.0

The server can resolve documentation dynamically from the active library.

A central installation may therefore use a layout such as /srv/scalionix/docs/, with individual books organized by:

• project
• version
• book

This allows the Docs Server binary to remain unchanged when documentation is added. Documentation deployment becomes:

        Git Repository
              ↓
        mdbook build
              ↓
            book/
              ↓
           Package
              ↓
        Artifact Server
              ↓
        Documentation Deployment
              ↓
        /srv/scalionix/docs/<project>/<version>/

Version directories can remain immutable while aliases such as latest identify the currently recommended version.

This separates [Documentation Server Release] from [Documentation Content Release], which allows both to evolve independently.

Documentation Portal

The Docs Server also provides a central interface for discovering available documentation.

Instead of requiring users to manually know every documentation URL, the server maintains information about:

• services
• tools
• versions
• default versions
• documentation URLs

This allows one Docs Server instance to become an entry point for documentation across the Scalionix ecosystem.

Scalionix System Benchmark

Another major project is the Scalionix System Benchmark.

It is a cross-platform benchmark written in Rust for measuring system performance using workloads designed to resemble real software operations.

The benchmark targets [Linux/Darwin] and collects information about the system being tested.

The benchmark architecture contains several workload categories. These include:

• JSON
• Hashing
• Encryption
• Compression
• Collections
• Concurrency
• Compilation
• Storage

The benchmark is designed around repeatable scenarios rather than a single synthetic loop.

JSON Benchmarking

JSON workloads measure serialization, deserialization, memory processing, and filesystem interaction involving structured data.

Operations include scenarios such as:

• serialization
• deserialization
• memory processing
• file processing
• round trips
• raw file reads
• pre-serialized file writes

Scenarios are executed across different:

• dataset sizes
• object counts
• worker counts

This makes it possible to observe both single-thread and multi-thread behavior across workloads of different sizes.

Hashing Benchmarking

Hashing workloads measure the performance of commonly used cryptographic hash functions.

Algorithms include:

• BLAKE3
• SHA-256
• SHA-512

Execution styles include:

• chunked
• one-shot

These scenarios make it possible to compare hashing performance across different algorithms, data sizes, and execution strategies.

Encryption Benchmarking

Encryption workloads measure authenticated encryption performance using commonly used algorithms.

Algorithms include:

• AES-128-GCM
• AES-256-GCM
• ChaCha20-Poly1305

Operations include:

• encrypt
• decrypt
• round trip

The workloads are designed to measure both individual cryptographic operations and complete encrypt-decrypt processing paths.

Compression Benchmarking

Compression workloads measure the performance of data compression and decompression operations.

The scenarios are designed to observe the computational cost of processing data through compression workloads rather than measuring only raw memory throughput.

They can be used to evaluate behavior across different:

• dataset sizes
• compression operations
• decompression operations
• worker counts

This makes it possible to compare both single-thread and multi-thread compression performance under repeatable workloads.

Collections Benchmarking

Collections workloads measure operations performed on in-memory data structures.

The objective is to observe behavior that appears frequently in real applications, where data is inserted, accessed, searched, modified, iterated, or removed from collections.

Scenarios can exercise operations such as:

• insertion
• lookup
• iteration
• modification
• removal

The workloads can be executed with different collection sizes and execution configurations, allowing the benchmark to observe how performance changes as the amount of managed data increases.

Concurrency Benchmarking

Concurrency workloads measure the behavior of the system when work is distributed across multiple execution contexts.

The objective is not simply to maximize CPU utilization, but to observe the cost and scalability of concurrent processing.

Scenarios can evaluate behavior across different:

• worker counts
• task counts
• synchronization patterns
• shared workloads

This makes it possible to compare single-worker execution with increasingly parallel workloads and observe how effectively the system scales as concurrency increases.

Compilation Benchmarking

Compilation benchmarking measures real build workloads.

The objective is to measure production-style compilation rather than an artificial CPU loop.

Compilation scenarios can record:

• toolchain
• worker count
• iterations
• best duration
• worst duration
• duration spread
• throughput
• artifact verification

Generated artifacts are verified so that a failed or incomplete compilation cannot be treated as a successful benchmark result.

This allows compilation performance to represent an actual developer workload, including both execution time and successful artifact production.

Storage Benchmarking

Storage workloads measure filesystem behavior rather than only raw sequential throughput.

Operations include scenarios such as:

• file operations
• directory traversal
• metadata operations
• rename operations

The benchmark is designed to observe end-to-end storage behavior through the operating system and filesystem.

This provides a workload-oriented view of storage performance that is closer to application behavior than a simple sequential read or write benchmark.

Hardware Detection

The benchmark collects a hardware snapshot describing the machine on which the benchmark was executed.

Information may include:

• CPU
• physical cores
• logical processors
• memory
• storage devices
• operating system
• architecture

Platform-specific detection is used where necessary.

For example, hardware information may be obtained from operating-system facilities such as:

• SMBIOS
• udev
• APIs

The objective is to identify the tested hardware accurately enough for comparison and result validation.

Benchmark Concurrency

Benchmark scenarios are executed using multiple worker configurations.

This allows comparison of behavior at levels such as:

        [ 1 / 2 / 4 / 6 / 8 / 12 / 16 / 20 / 24 / 32 ] number of workers

The objective is not only to determine maximum throughput.

The benchmark can also show how efficiently a machine scales as additional concurrency is introduced.

Benchmark Scoring

Raw benchmark results are transformed into a structured scoring model.

Conceptually:

        Scenario Results => Workload Score => Category Score => Global Score

This produces several levels of comparison.

A machine can therefore be compared using:

• individual scenario performance
• workload performance
• category performance
• global performance

The scoring system uses versioned references so that score calculation can evolve while remaining identifiable.

Benchmark Reports

The benchmark produces structured reports containing:

• benchmark results
• hardware information
• scoring information
• verification data
• report identifiers

The reporting model separates detailed local benchmark data from the compact information required for global comparison.

This allows large raw benchmark reports to remain local while only the required Global Score Report is submitted to a ranking service.

Global Benchmark Ranking

The broader benchmark architecture includes a public ranking system for comparing hardware configurations.

The ranking system is designed to support comparisons across:

• Global Score
• Categories
• Workloads
• Hardware Classes

Rather than storing only one final number, the architecture can preserve enough information to understand where a system performs well or poorly.

The ranking architecture also considers:

• hardware fingerprints
• duplicate detection
• scoring versions
• historical results
• machine categories

This makes the benchmark useful for more than a single local performance test.

Native Infrastructure

A recurring characteristic of the Scalionix ecosystem is the preference for native service execution where appropriate.

Many services are designed to run directly as binaries rather than requiring a container runtime as part of their normal deployment model.

This keeps the operational path simple:

        Binary => Operating System

and allows the surrounding infrastructure to manage:

• service lifecycle
• configuration
• networking
• deployment
• monitoring
• artifact delivery

directly.

Containers and virtualized environments may still be useful for isolated build or compatibility scenarios, but they are not assumed to be a mandatory runtime dependency for the ecosystem.

Cross-Platform Development

The ecosystem targets several operating systems and architectures.

Common targets include [Linux/Darwin/Windows] and [AMD64/ARM64].

This influences the design of:

• build systems
• artifact naming
• hardware detection
• benchmarking
• filesystem handling
• service packaging

Cross-platform behavior is treated as an architectural concern rather than an afterthought.

Programming Task Library

The Programming Task Library was originally created in January 2024 as a practical training resource for software developers.

The library was designed to encourage developers to think beyond:

the code compiles

or:

the expected value was returned

and instead consider:

• correctness
• algorithm design
• data modeling
• performance
• resource consumption
• validation
• abstraction
• flexibility
• edge cases
• maintainability

The original library focused primarily on Go and Rust. The current version reorganizes and expands that material into structured documentation.

It contains two major sections: Algorithms & Modeling.

The Algorithm section focuses on problem-solving and data processing. The Modeling section focuses on transforming real-world requirements into software systems containing entities, relationships, state, resources, scheduling, transactions, failures, recovery, and domain invariants.

Technology

The primary technologies and engineering areas represented across the projects include:

• Go / Rust
• HTTP/1.1 - HTTP/2
• REST
• TCP / UDP
• WebSocket
• TLS
• Linux / Darwin / Windows
• AMD64 / ARM64
• Git / Gitea / mdBook

The exact technology is selected according to the requirements of each system.

Go is used extensively for network services, infrastructure components, and backend tooling.

Rust is used for systems where low-level control, performance, concurrency, hardware interaction, or systems-programming practice is particularly valuable.

Current Direction

The current Scalionix work is gradually forming a connected engineering platform.

Individual systems remain independent, but they can participate in larger workflows.

For example:

        Source
           ↓
        Build Orchestrator
           ↓
        Artifact System
           ↓
        Deployment Infrastructure
           ↓
        Agent
           ↓
        Running Service

Documentation follows a parallel lifecycle:

        Documentation Source
           ↓
        mdBook Build
           ↓
        Documentation Artifact
           ↓
        Artifact Distribution
           ↓
        Docs Server
           ↓
        Scalionix Gateway
           ↓
         User

Benchmarking forms another independent subsystem:

        Machine
           ↓
        System Benchmark
           |
           +-- Hardware Snapshot
           +-- Workload Results
           +-- Verification
           +-- Scoring
           ↓
        Global Score Report
           ↓
        Ranking Infrastructure

The common theme is not one specific technology or product.

It is the development of infrastructure where each layer has an explicit responsibility and can be understood independently while still participating in a larger system.

Original Publication

The original version of the Programming Task Library was published as:

Training Task Library — Scalionix Development Team

Created by: Nikola Djurdjevic [LinkedIn]
Published: January 2021
Original technology focus: Golang & Rust & C++

The current documentation preserves the original exercises while reorganizing, correcting, documenting, and extending the collection into a larger programming and software-modeling resource.

Terms of Use

Effective date: [28-01-21]
Last updated: [17-09-26]

These Terms of Use govern access to and use of the Scalionix Task Library, including its documentation, exercises, tasks, code examples, illustrations, diagrams, supporting materials, and any related content made available through the Scalionix platform.

By accessing or using the Scalionix Task Library, you agree to these Terms of Use.

If you do not agree with these terms, you should not access or use the Task Library.

1. Purpose of the Task Library

The Scalionix Task Library is an educational resource intended to help developers improve their technical knowledge, problem-solving ability, software engineering judgment, and practical development skills.

The material may include:

• technical explanations
• programming exercises
• engineering problems
• architectural scenarios
• debugging exercises
• code examples
• configuration examples
• command-line examples
• design discussions
• performance-related exercises
• security-related exercises
• questions intended to develop analytical and critical thinking

The Task Library is designed for education and professional development.

It is not intended to provide legal, financial, security, compliance, or other regulated professional advice.

2. License to Use the Task Library

Unless otherwise stated, Scalionix grants you a limited, non-exclusive, non-transferable, non-sublicensable, and revocable right to access and use the Task Library for:

• personal education
• professional education
• individual study
• internal learning
• research
• software development practice
• technical experimentation

Access to the Task Library does not transfer ownership of the Task Library or any intellectual property rights associated with it.

All rights not expressly granted are reserved.

3. What You May Do

You may:

• read and study the Task Library;
• complete the exercises and tasks;
• write your own solutions to the tasks;
• take reasonable personal notes;
• quote limited portions of the material where permitted by applicable law and with appropriate attribution;
• use the knowledge, concepts, techniques, and skills you learn in your own software projects;
• discuss the concepts covered by the Task Library in your own words;
• use individual code examples as permitted under the section below.

You may apply knowledge learned from the Task Library in both personal and commercial work.

These Terms are intended to protect the content of the Task Library, not to restrict your ability to use the knowledge and skills you acquire from it.

4. Code Examples

Unless a code example is explicitly marked with a different license or restriction, you may copy, modify, and adapt individual code examples from the Task Library for:

• learning;
• experimentation;
• personal software projects;
• internal company projects;
• commercial software projects.

This permission applies to individual technical examples, not to the Task Library as a collection.

It does not permit you to reproduce or redistribute a substantial collection of Scalionix examples, exercises, explanations, or tasks.

For example, using a code snippet demonstrating a concurrency pattern in your application is permitted.

Copying hundreds of Scalionix code examples into another tutorial, book, training platform, repository, dataset, or course is not.

Third-party code included in the Task Library may be subject to separate license terms. Where applicable, those terms take precedence for that specific material.

5. Your Solutions

Code, notes, designs, or other material that you independently create while solving Scalionix tasks remain yours, subject to any third-party rights that may apply.

Scalionix does not claim ownership of an independently developed solution merely because it was created in response to a Task Library exercise.

However, the underlying Scalionix task statement, description, supporting explanation, diagrams, reference material, and other protected Task Library content remain subject to Scalionix intellectual property rights.

You may therefore publish your own independently written code where appropriate, but you may not reproduce substantial portions of the original Scalionix task or accompanying material without permission.

6. Prohibited Uses

Unless you have prior written permission from the copyright holder, you may not:

• reproduce substantial portions of the Task Library;
• republish the Task Library on another website or platform;
• create or operate a mirror of the Task Library;
• redistribute complete chapters, task collections, or substantial extracts;
• sell, sublicense, rent, or commercially distribute the Task Library;
• package the Task Library as part of another commercial product;
• create a competing book, course, training system, task library, or educational product by substantially reproducing protected Scalionix material;
• systematically copy or download the Task Library;
• use automated tools to harvest substantial portions of the content;
• remove copyright notices, attribution notices, watermarks, identifiers, or other rights-management information;
• falsely claim authorship or ownership of Scalionix material;
• falsely imply endorsement, partnership, certification, or affiliation with Scalionix;
• circumvent access controls, authentication systems, rate limits, or other technical restrictions;
• share access credentials where access is intended for an individual account;
• use the platform in violation of applicable law.

Nothing in these Terms is intended to prohibit an activity that cannot legally be restricted under applicable law.

7. Automated Extraction and Dataset Creation

Automated access intended to systematically collect substantial portions of the Task Library is prohibited unless explicitly authorized.

This includes, without limitation:

• scraping;
• crawling for content extraction;
• bulk downloading;
• systematic page harvesting;
• automated reconstruction of the Task Library;
• dataset generation;
• corpus generation.

Ordinary browser access and legitimate search-engine indexing authorized by Scalionix are not considered prohibited automated extraction.

8. Artificial Intelligence and Machine Learning

Unless expressly authorized in writing, substantial portions of the Task Library may not be collected or used as:

• machine-learning training data;
• fine-tuning data;
• retrieval-augmented generation corpora;
• embedding corpora;
• benchmark datasets;
• evaluation datasets;
• synthetic-data source material;
• datasets for reproducing or approximating the Task Library.

This restriction is directed at systematic ingestion or exploitation of the Task Library as a dataset.

It is not intended to prohibit ordinary personal use of development tools or assistants involving limited excerpts during legitimate study, unless a specific part of the Task Library states otherwise.

9. Educational Products and Training

The Task Library may not be substantially reproduced or incorporated into:

• university or school course materials;
• commercial training programs;
• corporate training packages;
• certification programs;
• online courses;
• books;
• tutorials;
• coding challenge platforms;
• interview preparation platforms;
• educational datasets

without prior written permission.

Educators, universities, companies, and training organizations interested in using the Task Library may contact Scalionix to request permission or a separate license.

Independent teaching of the same general subject matter is not prohibited.

The restriction applies to protected Scalionix content, expression, selection, organization, and materials.

10. Accounts and Access

Where access to the Task Library requires an account, you are responsible for maintaining the confidentiality and security of your account credentials.

You may not provide another person with access through your account where access is licensed or granted on an individual basis.

Scalionix may restrict, suspend, or terminate access where there is reasonable evidence of:

• unauthorized redistribution;
• credential sharing;
• systematic content extraction;
• attempts to circumvent technical restrictions;
• abuse of the platform;
• serious or repeated violations of these Terms.

11. Intellectual Property

The Scalionix Task Library and its protected contents remain the property of their respective copyright holders.

Protected material may include, where applicable:

• written explanations;
• task descriptions;
• exercises;
• examples;
• illustrations;
• diagrams;
• graphics;
• original tables;
• original datasets;
• original code;
• chapter organization;
• selection and arrangement of material;
• educational progression;
• accompanying documentation.

Additional information is available on the Copyright & Intellectual Property page.

12. Scalionix Name and Branding

The Scalionix name, logos, visual identity, product names, and related branding may be protected by trademark or other applicable law.

Nothing in these Terms grants permission to use Scalionix branding in a manner that suggests:

• endorsement;
• sponsorship;
• partnership;
• certification;
• affiliation;
• official status

unless such permission has been granted in writing.

Referencing Scalionix for legitimate identification, discussion, citation, or review is not prohibited where allowed by applicable law.

13. Third-Party Material

The Task Library may reference or link to:

• third-party software;
• programming languages;
• frameworks;
• libraries;
• standards;
• documentation;
• websites;
• publications;
• trademarks.

Such references do not imply ownership by Scalionix.

Third-party materials remain subject to their respective licenses, copyright terms, trademarks, and terms of use.

14. Accuracy of Technical Information

The Task Library is developed with the goal of providing accurate and useful technical material.

However, software engineering evolves continuously.

Programming languages, libraries, operating systems, APIs, security practices, tools, standards, and implementation details may change over time.

Scalionix does not guarantee that every example or statement will remain accurate, complete, secure, or suitable for every environment.

You are responsible for independently evaluating material before using it in production systems.

15. Security-Sensitive Material

Some exercises may involve topics related to:

• security;
• networking;
• cryptography;
• authentication;
• authorization;
• operating systems;
• system administration;
• infrastructure.

Examples are provided for educational purposes.

You are responsible for testing and reviewing any implementation before using it in a security-sensitive or production environment.

16. No Warranty

To the maximum extent permitted by applicable law, the Task Library and Scalionix platform are provided on an “as is” and “as available” basis.

No guarantee is made that the Task Library will:

• satisfy a particular requirement;
• be error-free;
• remain continuously available;
• be suitable for a particular project;
• produce a specific educational or professional outcome.

17. Limitation of Liability

To the maximum extent permitted by applicable law, Scalionix and the respective authors and right holders shall not be liable for indirect, incidental, consequential, special, or similar damages resulting from the use of, inability to use, or reliance upon the Task Library.

You remain responsible for decisions made based on the material and for verifying software before deploying it in real systems.

Nothing in these Terms excludes or limits liability where such exclusion or limitation is prohibited by applicable law.

18. Changes to the Task Library

The Task Library is an evolving publication.

Scalionix may:

• add new material;
• remove material;
• reorganize chapters;
• revise exercises;
• correct errors;
• change examples;
• introduce new editions or versions;
• discontinue older versions.

Different versions of the Task Library may therefore contain different material.

19. Changes to These Terms

These Terms may be updated when necessary to reflect:

• changes to the Task Library;
• changes to the Scalionix platform;
• new platform functionality;
• changes in applicable law;
• changes in licensing or intellectual property policy.

The current version will identify its effective or last-updated date.

Material changes will apply prospectively as required by applicable law.

20. Governing Law

Unless mandatory law requires otherwise, these Terms are governed by the laws of the Republic of Serbia.

Any dispute relating to these Terms or use of the Task Library shall be handled by the competent courts of the Republic of Serbia, subject to any mandatory jurisdiction or consumer-protection rules that may apply.

21. Severability

If any provision of these Terms is found to be invalid or unenforceable, the remaining provisions shall continue in effect to the extent permitted by law.

22. Contact

Questions regarding:

• permitted use;
• licensing;
• educational use;
• commercial use;
• republication;
• copyright;
• partnerships

may be directed to: Nikola Djurdjevic [LinkedIn]

Written permission should be obtained before undertaking any use for which these Terms require authorization.

Copyright & Intellectual Property

Copyright Notice

© [2021]–[2026] [Nikola Djurdjevic / Scalionix]. All rights reserved.

The Scalionix Task Library, including its original written material, exercises, task descriptions, explanations, examples, illustrations, diagrams, organization, and other protected content, is protected by applicable copyright and intellectual property law.

Unless otherwise stated, no ownership rights are transferred to users by providing access to the Task Library.

Access grants only the rights expressly described in the Terms of Use.

Ownership

The original content of the Scalionix Task Library is owned by its respective author or right holder.

Depending on the material, protected content may include:

• chapter text;
• technical explanations;
• task descriptions;
• exercise descriptions;
• problem statements;
• original examples;
• original source code;
• diagrams;
• illustrations;
• graphics;
• tables;
• original datasets;
• reference material;
• original classifications;
• educational sequences;
• selection and arrangement of material.

Individual components may also contain third-party material subject to separate rights or licenses.

Where third-party material is used, its respective copyright, license, and attribution requirements continue to apply.

Copyright Exists From Creation

Copyright protection does not depend on the presence of this notice.

The copyright notice is provided to clearly communicate ownership and permitted use.

The omission of a copyright notice from a particular page, example, illustration, file, or earlier version does not mean that the material is in the public domain or may be freely reproduced.

What Copyright Protects

Copyright protects original expression fixed in a particular form.

Within the Task Library, this can include the particular way in which a technical subject is:

• explained;
• written;
• illustrated;
• organized;
• demonstrated;
• presented through exercises;
• structured into chapters;
• arranged into a progression of tasks.

A task may therefore contain protected expression even when the underlying programming concept itself is widely known.

The same applies to original collections and arrangements of material where the selection or organization reflects original intellectual creation.

What Copyright Does Not Protect

Copyright does not grant ownership over general knowledge.

It does not prevent others from independently using:

• ideas;
• programming concepts;
• algorithms as abstract concepts where not otherwise legally protected;
• general engineering principles;
• mathematical concepts;
• general methods of work;
• programming languages;
• public APIs;
• generally known software patterns;
• facts.

For example, Scalionix does not claim ownership of concepts such as:

• concurrency;
• serialization;
• hashing;
• encryption;
• caching;
• distributed systems;
• dependency injection;
• data structures;
• REST;
• networking;
• benchmarking.

You are free to learn these subjects and apply that knowledge independently.

What may be protected is the specific Scalionix expression, explanation, task design, illustration, example, selection, or arrangement used to teach them.

Task Design and Educational Structure

A significant part of the Scalionix Task Library is the design and progression of its tasks.

Individual tasks may be intentionally selected and ordered to develop specific abilities, including:

• analytical reasoning;
• debugging;
• problem decomposition;
• architectural judgment;
• performance reasoning;
• concurrency reasoning;
• code review;
• failure analysis;
• systems thinking.

The value of the Task Library therefore does not consist only of individual paragraphs or code examples.

The selection, formulation, organization, progression, and relationship between tasks may form part of the protected work.

This means that reproducing the overall Task Library by rewriting individual sentences while substantially preserving its protected structure or content may still raise intellectual property concerns.

This statement does not claim ownership over general educational methods, ideas, or programming concepts themselves.

Personal and Educational Use

Users may access and study the Task Library in accordance with the Terms of Use.

Reasonable personal activities are permitted, including:

• reading;
• studying;
• taking personal notes;
• solving tasks;
• experimenting with examples;
• discussing concepts in your own words;
• applying acquired knowledge.

Learning from the Task Library does not create any obligation to Scalionix regarding software or other work that you later develop independently.

Quotation and Reference

Limited quotation may be permitted where allowed by applicable law.

When quoting Scalionix material, attribution should identify the source clearly.

A recommended attribution format is:

Scalionix Task Library, “[Chapter or Task Title],” version [VERSION].

Where technically practical, a reference to the official Scalionix publication should also be included.

A citation does not by itself authorize reproduction of an otherwise substantial portion of the work.

Use in Books, Publications, and Educational Material

Scalionix content may not be reproduced in books, publications, articles, training material, course material, documentation, educational platforms, or similar works merely by providing attribution.

Attribution does not replace the requirement to obtain permission where permission is required.

Limited quotation may be permitted where allowed by applicable law, provided that the Scalionix Task Library is clearly identified as the source.

Any reproduction beyond a limited quotation, including reproduction of substantial passages, complete tasks, exercises, diagrams, examples, chapter structures, or collections of material, requires prior written permission from the copyright holder.

Where permission is granted, the resulting publication must include the attribution specified by Scalionix.

A recommended attribution format is:

Scalionix Task Library, “[Chapter or Task Title],” version [VERSION], © [YEAR] [Copyright holder].

Permission to reproduce one specific portion of the Task Library does not grant permission to reproduce other portions or the Task Library as a whole.

Commercial Exploitation and Paid Educational Use

Unless expressly authorized in writing by the copyright holder, Scalionix material may not be used to generate revenue for another person, organization, company, educator, training provider, or platform.

This includes using protected Scalionix content, in whole or in substantial part, within:

• paid online courses;
• classroom courses for which tuition or participation fees are charged;
• commercial workshops;
• corporate training programs;
• bootcamps;
• certification programs;
• paid mentoring programs;
• subscription-based educational platforms;
• books or publications offered for sale;
• paid newsletters;
• premium documentation;
• commercial coding challenge platforms;
• interview-preparation services;
• consulting or training packages;
• any other product or service for which payment, subscription fees, licensing fees, advertising revenue, sponsorship revenue, or other commercial benefit is received.

Providing attribution to Scalionix does not grant permission for commercial use.

For example, the following is not permitted without prior written authorization:

A training provider reproduces Scalionix tasks, explanations, diagrams, examples, or educational sequences inside a paid course and identifies Scalionix as the original source.

Attribution is required where applicable, but attribution does not replace the requirement to obtain permission.

A person may use the knowledge and skills learned from the Task Library in professional or commercial work.

A person may also independently teach the same general technical subjects using independently created explanations, exercises, examples, and course structures.

The restriction applies to the commercial reuse of protected Scalionix material, not to the independent use of knowledge acquired from it.

Any commercial licensing of Scalionix material requires a separate written agreement or explicit written permission from the copyright holder.

Code Examples

Technical documentation must remain practical.

Accordingly, unless otherwise stated, users may copy and adapt individual code examples for their own software projects.

This includes commercial software development.

This permission does not authorize reproduction of the Task Library itself.

In particular, it does not authorize someone to collect substantial numbers of examples and redistribute them as:

• another documentation set;
• a tutorial collection;
• a code-example repository;
• a book;
• a training course;
• an educational website;
• a coding challenge platform;
• a dataset.

Code carrying a separate license notice remains governed by that license.

Your Own Solutions

Solutions independently written by a user in response to a Task Library exercise generally remain the user’s own work, subject to applicable law and third-party rights.

Scalionix does not claim ownership of a user’s independently written implementation merely because the Task Library inspired or requested it.

However, publishing your own solution does not automatically grant permission to reproduce the original Scalionix:

• task statement;
• explanation;
• diagrams;
• test data;
• accompanying text;
• protected examples.

Where necessary, describe the problem in your own words rather than reproducing substantial protected material.

Redistribution

Unless prior written permission has been obtained, the Task Library may not be substantially:

• copied;
• reproduced;
• mirrored;
• republished;
• translated;
• redistributed;
• resold;
• sublicensed;
• commercially exploited;
• incorporated into another educational publication.

This includes redistribution that is provided free of charge.

The absence of a commercial purpose does not automatically authorize reproduction.

Applicable statutory exceptions remain unaffected.

Translations

Official translations of the Scalionix Task Library remain protected works.

Creating or distributing an unofficial translation of a substantial portion of the Task Library requires permission unless applicable law provides otherwise.

When Scalionix publishes the same material in multiple languages, copyright applies to the respective original and translated expression as applicable.

Derivative Educational Material

You may create your own original educational material about the same technical subjects.

You may explain the same programming concepts.

You may teach similar technologies.

You may create your own exercises independently.

You may not, without authorization, reproduce protected Scalionix content or create another publication that substantially copies protected elements of the Task Library.

This distinction is important:

Knowledge is meant to be learned and used.
The publication itself is not being placed into the public domain.

Automated Collection

Systematic automated extraction of Scalionix content is not authorized unless explicitly permitted.

Examples include:

• scraping entire sections;
• bulk chapter collection;
• automated task harvesting;
• rebuilding the Task Library from downloaded pages;
• creating large text corpora from the Task Library.

Normal human use of the website is unaffected.

AI, Machine Learning, and Dataset Use

The publication of the Task Library does not grant permission to systematically use its protected content for:

• model training;
• model fine-tuning;
• retrieval databases;
• embedding corpora;
• evaluation datasets;
• benchmark datasets;
• synthetic-data generation;
• commercial data products.

Separate permission may be requested for such uses.

This restriction concerns systematic use of the protected corpus and does not prohibit ordinary limited use of assistive software during personal study where otherwise permitted.

Copyright Records and Evidence

Scalionix may maintain records relating to published versions of the Task Library.

These records may include:

• source-control history;
• publication dates;
• version numbers;
• release tags;
• archived source packages;
• cryptographic hashes;
• digitally signed manifests;
• publication logs;
• deposited copies of published editions.

These records may be used to establish the provenance, integrity, publication history, or authorship of particular versions of the work.

Where an edition has been formally deposited or recorded with an intellectual property authority, additional identifying information may be provided here.

Deposit / record reference: [optional]

Versioned Publications

The Scalionix Task Library is maintained as a versioned publication.

Content may change between releases.

A specific copyright claim or attribution should therefore refer, where relevant, to the applicable version.

For example:

Scalionix Task Library
Version: 1.4.0
Published: 2026-09-17

Historical releases may be preserved for evidentiary, archival, compatibility, or educational purposes.

Integrity of the Work

Unauthorized modification of Scalionix material must not be presented as an official Scalionix publication.

Modified copies must not use Scalionix branding in a way that could reasonably cause users to believe that they are authentic or officially maintained versions.

Scalionix Branding

Copyright permission does not automatically grant trademark permission.

The Scalionix name, logos, product names, graphical identity, and other branding may be protected separately.

They may not be used to falsely imply:

• official status;
• endorsement;
• sponsorship;
• partnership;
• certification;
• authorship;
• affiliation.

Legitimate references to Scalionix for identification, commentary, attribution, or discussion remain subject to applicable law.

Reporting Copyright Infringement

If you believe Scalionix material has been reproduced or distributed without authorization, please contact:

Scalionix
Email: [copyright contact email]

Where possible, include:

• the Scalionix material involved;
• the location of the suspected unauthorized copy;
• the relevant URL or platform;
• screenshots or other evidence;
• the date on which the material was observed.

Permission and Licensing Requests

Permission may be requested for uses including:

• university teaching;
• commercial training;
• corporate education;
• translation;
• republication;
• substantial quotation;
• book publication;
• course development;
• platform integration;
• dataset use;
• other commercial licensing.

Contact:

Scalionix
Email: [licensing contact email]

Permission is valid only when granted by an authorized right holder or representative.

Reservation of Rights

Except for rights expressly granted by the Terms of Use or required by applicable law, all rights are reserved.

Nothing in the publication of the Scalionix Task Library should be interpreted as a waiver, abandonment, or transfer of intellectual property rights.

AI Models and Software Engineering

One of the most important subjects in modern software engineering is the influence of Large Language Models, generative AI systems, and increasingly autonomous AI agents on the way software is designed, implemented, reviewed, tested, and operated.

For people entering this profession, one question appears almost immediately:

Does it still make sense to learn programming and software engineering if AI systems can already generate code?

This question is understandable.

The public discussion around AI is often dominated by extreme positions.

One side presents AI agents as systems that will replace almost every developer and engineer.

The other side treats them as useless toys that have no serious place in professional engineering.

I do not believe either position is useful.

AI systems are already capable of producing meaningful software, accelerating certain tasks, generating useful technical material, assisting with debugging, navigating repositories, writing tests, and automating parts of development workflows.

That capability should be taken seriously.

But generating code is not the same thing as owning an engineering problem.

Producing a locally correct implementation is not the same thing as designing, operating, evolving, and taking responsibility for a system over years.

That distinction is the starting point of this chapter.

Is Software Engineering Still Worth Learning?

Absolutely, YES.

But the reason is not that AI systems are weak or that they will stop improving. They will improve.

The reason is that software engineering has never been only about typing source code.

Code is one representation of a much larger process. A real engineering process may include:

• understanding incomplete requirements;
• identifying the actual problem;
• rejecting unnecessary complexity;
• designing system boundaries;
• selecting technologies;
• reasoning about failure;
• understanding security consequences;
• planning migrations;
• preserving compatibility;
• operating production systems;
• debugging behavior that was never expected;
• controlling cost;
• communicating across teams;
• making trade-offs;
• deciding what should not be built;
• taking responsibility for the final result.

An AI system may participate in many of these activities. That does not automatically make it the owner of those activities.

A useful mental model is:

Code generation ≠ Software engineering.

and:

Producing an answer ≠ Owning the consequences of that answer.

If your entire professional value is based on manually producing predictable boilerplate, then AI will place increasing pressure on that part of your work.

If your value comes from understanding systems, making decisions, solving unfamiliar problems, validating results, designing for change, and taking responsibility for technical consequences, then the profession remains much broader than code generation.

The correct response to AI is not to stop learning. The correct response is to learn more deeply.

AI Models, Infrastructure, and Intellectual Property

One of the biggest problems surrounding AI models is the violation of intellectual property.

If you give any AI agent access to your infrastructure, your network, or your source code base, then every later discussion about security, data protection, and intellectual property becomes largely pointless. The moment you give an AI model access, you have already allowed a third party into your infrastructure.

At that point, if an unwanted scenario happens, you cannot act as though that access appeared out of nowhere.

You gave it permission. You gave it access. And you accepted that risk yourself.

We have already seen situations where all kinds of things happen in environments like this:

• A problem suddenly appears and nobody inside the technical teams knows how to fix it.
• A part of a database disappears.
• Certain permissions suddenly exist even though nobody knows how they got there.
• A system is modified in a way nobody clearly remembers authorizing.

And then everyone starts asking:

How did this happen?

The better question is:

Why was a third-party agent given access to that part of the infrastructure in the first place?

Do not think that absolutely everyone, from every technical environment, is enthusiastic about AI models or willing to give them access.

That is simply not true.

Our environment, as well as the environments of the partners we work with, has strict rules and conventions written into agreements with technical personnel.

One of many such rules is that technical staff are strictly forbidden from using AI agents for writing code.

Giving any AI agent access to any part of company intellectual property is also treated extremely seriously.

We will see what happens when legal cases begin appearing around questions such as:

• who created what;
• how something was created;
• who owns a specific implementation;
• what part was written by a human;
• what part was generated by an AI system;
• what data was exposed during that process;
• who can prove the origin of the implementation.

And then another question appears. What happens when:

• the companies operating AI models start claiming that they have evidence showing that their system generated a certain implementation inside someone else’s infrastructure?
• arguments begin over intellectual property ownership because a third-party model participated in building part of a proprietary system?
• nobody can clearly prove where one part ends and another begins?

Think about that.

Intellectual property around generative AI is still an active legal and regulatory area.

The correct response is not to invent certainty where certainty does not yet exist. Training datasets can involve combinations of:

• publicly available material;
• licensed material;
• proprietary material;
• synthetic data;
• other sources depending on the provider.

There are ongoing legal disputes and policy questions concerning the use of copyrighted works in AI training.

The U.S. Copyright Office has published a multi-part AI study addressing copyrightability and generative AI training. In the European Union, obligations for providers of general-purpose AI models include maintaining a copyright compliance policy and publishing a sufficiently detailed summary of training content. The legal environment is therefore actively evolving.

For engineering organizations, this creates practical questions:

• Are we allowed to send this source code to this provider?
• What does our customer contract allow?
• What does the provider’s agreement say about submitted data?
• Can generated code contain material that creates licensing concerns?
• Can we prove which parts of a product were human-authored?
• Do we maintain provenance for important generated artifacts?
• Are we exposing trade secrets?

These are governance questions. They should be answered before an agent is connected to sensitive systems.

AI-Assisted Work and Copyright

Another point needs precision.

Using AI during development does not automatically mean that the resulting software has no copyright protection.

For example, the U.S. Copyright Office has stated that human-authored expressive contributions can remain protected even when AI is used as an assistive tool.

The difficult questions concern the amount and nature of human authorship, the provenance of generated material, training-data rights, and the contractual terms under which specific tools are used.

Therefore, organizations should not rely on simplistic statements such as:

        AI touched the code
                ↓
        nobody owns it

or:

        AI wrote part of the code
                ↓
        the AI provider owns part of the product

Those conclusions do not follow automatically. The responsible approach is:

• define company policy;
• understand provider terms;
• preserve provenance where important;
• protect confidential material;
• obtain legal advice where the risk justifies it.

Application Development and Technology Development

At the beginning of this discussion, we need to separate software development sharply into two different areas.

There is:

• application development
• technology development

Application development is the kind of development in which engineers use existing technologies to create new services and applications.

Technology development is the kind of development in which developers create new technologies and systems that engineers and other technical people will later use when building services and applications. A practical example of application development would be building infrastructure for aviation traffic.

Technology development made it possible to create things such as:

• different types of software communication systems;
• different programming languages;
• different database architectures;
• different mechanisms and standardized protocols;
• different security systems;
• different operating systems;
• different server models and runtime environments.

All of these are then used by the application layer under the hood. There are AI agents that can help in certain areas of application development.

That is not the problem. The point is that their role is that of an assisting tool.

They should not become the mechanism that a technical person depends on.

And they should not become the foundation of an engineering process where the person becomes incapable of functioning without them.

LLM and AI systems build their outputs from statistical patterns, metrics, and previously existing data.

A mechanism built around existing patterns can be useful when working with things that have a generic form or that contain relatively small automated processes. A simple informational website is a good example. In that kind of work, an AI agent can be extremely useful. It can generate layouts, components, basic backend logic, configuration, boilerplate, and repetitive structures very quickly. But only up to a certain point.

As complexity increases, as the number of features increases, and as the amount of required context grows, the system becomes harder and harder for the model to hold together coherently.

At some point, the agent stops being useful. After that point, it can become actively dysfunctional.

Then it can:

• starts losing track of earlier decisions.
• begins introducing contradictions.
• changes one part of the system without understanding what that change breaks somewhere else.
• starts inventing things that were never defined.
• begins presenting unverified assumptions as though they were facts.
• eventually, instead of reducing work, it starts generating additional work.

We started with the most basic possible form: A website. Now take a much larger infrastructure.

Imagine a platform containing many services and applications, built by many teams:

• Different teams are building different parts.
• Some teams operate in completely separate environments.
• Services depend on other services.
• Internal protocols exist.
• Different databases exist.
• Different security rules exist.
• bDifferent deployment environments exist.
• Different versions exist.
• Different migration paths exist.

Now the situation changes completely. At that point it becomes very obvious what an AI agent actually is:

A tool. It can be useful. It can be functional.

It can be extremely powerful in the right hands.

AI model is not the initiator, owner, or creator of the entire engineering process.

The context limit of an AI system represents a numerical limitation on how much information the system can actively process within a given interaction. Once the amount of relevant information becomes too large, the model begins losing parts of the conversation and system context.

The larger that problem becomes, the easier it is for the model to start hallucinating, contradicting earlier information, or writing things that were never verified and may never have existed in the first place. Now increase the size of the infrastructure. Think about:

• financial systems;
• stock exchanges;
• electrical power systems;
• security systems;
• operating systems;
• cloud infrastructure;
• distributed storage systems;
• large internal platforms.

The operational scope, complexity, number of dependencies, and long-term development of systems like these are far beyond what can be treated as one simple AI conversation. And in environments like these, some of the most important properties are:

• flexibility;
• modularity;
• scalability.

Only after that do we start talking about:

• performance;
• resource usage.

Large infrastructure has to be designed many steps ahead. Sometimes fifty steps. Sometimes a hundred. You have to think about what happens after:

• the next feature;
• the next service;
• the next migration;
• the next operating-system version;
• the next protocol change;
• the next security requirement;
• the next scaling problem;
• the next five years of development.

AI agents naturally tend to satisfy the current request. You give the system a problem. It attempts to produce something that works for that problem now. If the current context allows it, it generates a solution that appears correct at that moment.

That is a terrible way to design serious long-term infrastructure.

Infrastructure built to the highest technical standards does not work like that.

It requires:

• planning;
• sketching;
• designing;
• rejecting ideas;
• redesigning;
• thinking through future interactions;
• thinking through failure cases;
• considering changes that have not happened yet.

The problem is that an AI agent does not have an independent understanding of what will happen in future iterations of your system. It knows what you give it now. If every future update or upgrade requires large parts of the generated code to be rewritten, then the original design was not good. A system that constantly requires massive refactoring because every new feature breaks the previous assumptions was badly designed from the beginning.

That is not scalability. That is not modularity. That is not good engineering.

This becomes even more obvious in very large infrastructures and technical conglomerates. AI models can be strongly promoted internally. They can be introduced aggressively. They can be used everywhere people believe they may reduce cost or increase speed. But once the work reaches a certain level of complexity, teams very quickly discover the difference between:

Generating code and Understanding the entire system.

Those are not the same thing.

AI models begin losing the overall picture as the amount of code, dependencies, interaction, historical decisions, and system-specific knowledge grows.

Now imagine an infrastructure like ours.

Eighteen services. More than twenty thousand lines of code per service on average. A large number of interactions between those services.

Multiple factors on infrastructure level:

• Shared behavior.
• Dependencies.
• Protocols.
• Versioning.
• Deployment logic.
• Internal assumptions.
• Future development.

And that is still a relatively small infrastructure compared with the systems operated by the largest technology companies in the world. Now imagine what happens at that scale. The idea that one AI agent simply “understands the whole thing” because it can generate code inside one part of it is completely unrealistic. That is exactly where the distinction has to be made:

• AI can assist development.
• AI can automate repetitive work.
• AI can generate useful implementation.
• AI can help experienced engineers move faster.

But a tool that generates code should never be confused with the engineering system, the engineering process, or the people responsible for designing and owning the infrastructure.

The Mental Effect of Constant AI Dependency

Another subject that needs to be discussed much more openly is the effect that frequent AI use can have on technical people themselves.

Not only technically. Mentally as well.

AI models can be extremely useful for generating generic structures and reducing the amount of repetitive work that does not require much creativity, design, or deep technical reasoning.

That is useful, but there is another side to it.

The more frequently people delegate even basic technical thinking to AI systems, the easier it becomes to become mentally lazy about things that they previously would have solved themselves.

And if you become lazy about basic problems, you will not suddenly become disciplined when a truly difficult problem appears.

You gradually lose patience. You gradually lose tolerance for uncertainty.

You become less willing to sit with a problem for hours or days.

You become accustomed to receiving some form of result almost immediately.

That is completely incompatible with serious engineering.

No serious science, engineering discipline, or long-term technical development works on the assumption that every meaningful problem must produce a visible result within several hours.

Real work often does not behave like that.

Sometimes you will spend:

4 hours

and achieve almost nothing visible.

Sometimes:

3 days

Sometimes:

3 weeks

And sometimes you will work on a problem for months before the pieces finally connect into something functional.

That process develops:

• patience;
• endurance;
• analytical depth;
• problem decomposition;
• emotional stability;
• technical intuition;
• the ability to remain functional while the answer is still unknown.

If every difficult moment immediately becomes [Ask the AI].

you can slowly destroy your tolerance for exactly the kind of mental state that serious engineering requires.

There is also another effect.

People begin to feel less capable without the tool. They become less confident in their own ability to investigate.

They become less satisfied with their own work. They stop feeling productive unless something visible is generated quickly.

Anything that cannot be completed within a few hours or within a single working day starts to feel mentally heavy.

This is dangerous. You are conditioning yourself to expect immediate output. But immediate output does not automatically have:

• depth;
• quality;
• reliability;
• technical weight;
• maintainability;
• credibility.

A large amount of generated output can look impressive while containing very little actual engineering value.

This problem can become even more obvious in technical areas, ecosystems, or programming languages where there is less high-quality public information available.

AI systems are strongly dependent on the quality and quantity of the material from which they have learned and the context they are given.

Where the public technical ecosystem is weaker, narrower, poorly documented, or dominated by repetitive material, the quality of generated output may also degrade significantly.

That is another reason why you need your own technical judgment.

Do not measure yourself by how quickly an AI agent can produce something.

Measure yourself by whether you understand what was produced.

Whether you can verify it. Whether you can improve it. Whether you can repair it when it fails.

And whether you can continue working when the tool is removed.

If you cannot function without the AI system, then the AI system is no longer helping your engineering ability.

It has replaced part of it. That is dependency and dependency should never be confused with productivity.

Generation Is Not Verification

One of the biggest changes created by AI-assisted development is that generating code can become much faster than validating code.

Before widespread generative AI, one bottleneck was often: Writing the implementation.

With AI assistance, the bottleneck can move:

        Understanding the requirement
                ↓
        Reviewing generated code
                ↓
             Testing
                ↓
        Security verification
                ↓
           Integration
                ↓
        Operational validation
                ↓
        Long-term maintenance

This gives us an important equation:

10× faster code generation ≠ 10× faster software engineering.

DORA’s 2026 analysis describes a similar tension: AI can reduce friction during initial code generation, while part of the time saved is later reallocated to auditing and verification.

That does not mean AI is ineffective.

It means that measuring only the speed of code production can be misleading.

The final unit of value is not:

How many lines were generated?

The useful questions are:

• Was the correct system built?
• How much review was required?
• How many defects were introduced?
• How maintainable is the result?
• How much operational risk was created?
• How easily can the system evolve?
• Can the team explain what was produced?

Context Windows Are Not System Understanding

Every LLM has a finite working context.

A context window defines how much information can be made available to the model during a particular interaction.

But one thing needs to be made absolutely clear:

Being able to receive information is not the same thing as understanding the entire system that information belongs to.

A model can technically accept a very large amount of text and still fail to correctly connect every relevant dependency, architectural decision, historical assumption, or interaction inside that material.

As the amount of information grows, the problem is no longer simply:

    Can the model read this?

The real question becomes:

    Can the model preserve the correct relationships between all relevant parts of the system?

Those are completely different problems.

A large context window does not automatically mean that the model has a complete and coherent understanding of everything inside it.

It may receive:

• source code;
• documentation;
• configuration;
• logs;
• database schemas;
• API definitions;
• architectural descriptions.

That still does not mean it understands all of the interactions between them correctly.

And the larger and more interconnected the system becomes, the harder that problem becomes.

Modern agents can partially compensate for this through:

• repository search;
• retrieval systems;
• code indexes;
• tools;
• subagents;
• summaries;
• external memory;
• iterative exploration.

That absolutely makes them more capable.

But none of those mechanisms change the fundamental problem.

A repository is not the same thing as a complete system.

And a complete system is not only source code. It is also:

        source code
        +
        service dependencies
        +
        database behavior
        +
        deployment rules
        +
        network topology
        +
        security assumptions
        +
        historical decisions
        +
        production incidents
        +
        migration plans
        +
        internal conventions
        +
        future requirements
        +
        knowledge that exists only inside engineers' heads

That is the real context of a serious infrastructure.

So the deeper limitation is not simply the number of tokens that fit inside a context window.

The deeper limitation is system knowledge.

An AI agent may be able to inspect thousands of files. It may search them efficiently. It may summarize them. It may even make useful changes across many of them.

But that should never be confused with having complete ownership and understanding of the entire technical system. Those are not the same thing.

Large Systems Are Designed for Change

In large infrastructure, immediate functionality is only one requirement.

A system also needs to survive change. Some of the most important qualities are:

• modularity;
• clear boundaries;
• flexibility;
• scalability;
• observability;
• maintainability;
• recoverability;
• compatibility.

Performance and resource consumption matter as well, but optimizing those properties without preserving the ability to evolve can produce a system that is fast today and extremely expensive to change tomorrow. A locally functional implementation may still be a poor engineering decision. For example:

        Requirement satisfied today
                ↓
               but
                ↓
        every future feature requires rewriting three services

That is not a good design. This is why experienced engineers frequently spend significant time on:

• diagrams;
• interfaces;
• data ownership;
• failure boundaries;
• migration paths;
• future extension points;
• operational behavior.

AI can assist with all of these, but it cannot know requirements that nobody has communicated to it.

It cannot reliably optimize for future constraints that the organization itself has not yet identified.

And it cannot take responsibility for strategic decisions that were never made explicit.

The Problem of Future Iterations

Engineering is rarely a single interaction. A production system may live for:

• 5 years
• 10 years
• 20 years

During that period:

• teams change;
• requirements change;
• dependencies change;
• security threats change;
• regulations change;
• traffic changes;
• hardware changes;
• business priorities change.

A design must therefore have some ability to absorb unknown future changes.

No human architect can predict every future requirement in 100% of the cases. AI cannot either.

The goal is not prediction. The goal is designing systems with boundaries and abstractions that make future change less destructive. That requires judgment. And judgment is built from:

• theory;
• implementation experience;
• failed designs;
• production incidents;
• migrations;
• performance problems;
• security failures;
• maintenance experience.

An AI system may encode patterns derived from enormous amounts of technical material.

But an engineering organization still needs people who can evaluate whether those patterns fit its actual environment.

Benchmarks Are Not Production

AI coding benchmarks are useful. They tell us something. They do not tell us everything. A benchmark normally defines:

• an input;
• a task;
• an evaluation method;
• a success condition.

Real software engineering often has none of those properties clearly defined. The specification may be incomplete. The tests may be wrong.

The correct behavior may depend on undocumented business knowledge. Two technically valid solutions may have completely different operational consequences. A system may pass every available test and still be unacceptable in production. A useful 2026 METR study examined AI-generated pull requests that had already passed the automated SWE-bench Verified grader. Maintainers reviewing those patches would reject roughly half of the test-passing AI pull requests in the studied sample. The researchers explicitly caution that this does not establish a fundamental capability limit, because real agents could iterate after code review feedback.

The important lesson is simpler:

Passing an automated benchmark is not equivalent to passing real engineering review.

That difference matters.

Developer Sentiment Is More Complicated Than the Marketing

The 2025 Stack Overflow Developer Survey provides another useful perspective.

AI adoption is very high. At the same time, trust is significantly lower than adoption.

Among respondents:

• 84% were using or planning to use AI tools in development;
• more developers reported distrusting AI output accuracy than trusting it;
• 66% identified “almost right” AI solutions as a major frustration;
• 45% reported that debugging AI-generated code could take more time;
• developers showed especially strong resistance to delegating high-responsibility areas such as deployment and monitoring.

This is a useful reminder: High adoption ≠ High trust.

A tool can be useful enough to use every day while still requiring constant verification.

AI Should Amplify Knowledge, Not Replace It

This is the rule I would strongly recommend during learning:

Never allow a tool to become the owner of a thought process that you are still supposed to be learning.

There is a major difference between these two scenarios.

Scenario A

An experienced engineer understands:

• the problem;
• the implementation;
• the failure modes;
• the architecture.

They ask an AI system to generate repetitive code.

The engineer reviews it, modifies it, tests it, and accepts responsibility for it.

AI reduced mechanical work.

Scenario B

A beginner does not understand:

• the problem;
• the implementation;
• the failure modes;
• the architecture.

They ask an AI system for the complete solution.

The code runs.

They move to the next task.

These two people may produce the same visible output today.

They are not building the same capability.

The first person automated something they already understood.

The second person may have automated the exact cognitive process that was supposed to develop their understanding.

This is where AI can become dangerous for learning.

Not because asking AI a question is bad.

Not because generated code is automatically bad.

The danger is dependency.

Cognitive Dependency

If every obstacle immediately becomes [Ask the model] your tolerance for unresolved problems can gradually decrease.

You can become accustomed to: [question => immediate answer].

But serious engineering often looks like:

        problem
            ↓
        wrong hypothesis
            ↓
        investigation
            ↓
        new evidence
            ↓
        another wrong hypothesis
            ↓
        documentation
            ↓
        experiment
            ↓
        partial understanding
            ↓
        more investigation
            ↓
        solution

Sometimes that process takes twenty minutes. Sometimes it takes three days. Sometimes it takes months.

Your ability to remain calm inside an unresolved problem is part of your engineering ability.

If every unresolved state becomes psychologically uncomfortable because you are used to immediate generated answers, that can become a real weakness.

I am not presenting this as proof that AI necessarily makes engineers mentally weaker.

Research on the human effects of AI-assisted work is still developing, and some studies report positive effects on developer well-being and flow.

My point is narrower:

Using AI without discipline can remove exactly the friction from which some forms of technical ability are developed.

Use the tool. Do not surrender the learning process to it.

Ask Yourself One Question

When AI gives you an implementation, ask yourself:

Could I explain why this works without asking the model again?

Then go further:

• Can I explain every important dependency?
• Can I explain the failure paths?
• Can I modify it safely?
• Can I debug it when the model is unavailable?
• Can I recognize when the answer is wrong?
• Can I defend the architectural decision?
• Can I operate it in production?

If the answer is no, then the AI has probably moved faster than your understanding.

That may be acceptable for a temporary experiment. It is dangerous as a permanent engineering model.

AI-Generated Code Still Requires Ownership

Imagine that an agent generates:

• service
• database migration
• deployment configuration
• tests
• monitoring

Everything passes. Three months later, the migration fails under a production edge case and corrupts data.

Who owns the incident? Not the prompt. Not the token stream. Not the model. The engineering organization owns it.

Responsibility cannot be delegated simply by delegating implementation.

This is why high-responsibility environments require human verification.

NIST’s DevSecOps guidance explicitly recommends that AI-generated software content be monitored and validated by humans, with verifiable processes to prevent uncritical acceptance of insecure or non-functional code. That is exactly the right mental model.

AI Access Creates a New Trust Boundary

Another major issue is not code quality at all. It is access.

If you connect an AI system or agent to:

• private source code;
• production systems;
• databases;
• internal documentation;
• issue trackers;
• logs;
• credentials;
• deployment systems;
• customer data

you have created a new trust boundary.

That does not mean that you automatically lose ownership of your intellectual property.

It means that your threat model has changed.

You now need to understand:

• what information is transmitted;
• where it is processed;
• how long it is retained;
• whether it is used for training;
• which subprocessors can access it;
• which jurisdictions are involved;
• what contractual protections exist;
• what permissions the agent has;
• whether actions are logged;
• whether actions require approval;
• how secrets are protected;
• how access is revoked.

This should be treated like any other serious external dependency. The correct question is not:

Is AI secure?

That question is too vague.

The correct questions are:

Which model?
Which provider?
Which contract?
Which data?
Which permissions?
Which environment?
Which retention policy?
Which actions?
Which audit controls?

Least Privilege Applies to Agents Too

An AI agent should not receive more access merely because giving it broad access is convenient.

The same security principles used for human users and services should apply:

• least privilege;
• separation of duties;
• explicit authorization;
• environment isolation;
• secret management;
• audit logging;
• approval gates.

For example:

    Read repository

does not automatically imply:

    Write repository

and:

    Write repository

does not automatically imply:

    Deploy production

and:

    Inspect database schema

does not automatically imply:

    Modify production data

Tool capability should never be confused with appropriate permission.

AI Can Increase the Value of Strong Engineers

There is another side of this discussion that should not be ignored.

AI does not only help beginners.

A strong engineer can use AI as a multiplier.

Why?

Because the engineer already has the ability to:

• specify the problem precisely;
• recognize incorrect assumptions;
• review generated code quickly;
• reject poor architecture;
• test adversarial cases;
• ask better questions;
• integrate the result into a larger system.

The AI can therefore remove lower-value mechanical work while the engineer remains responsible for higher-value decisions.

This is one reason I do not see AI as an argument against learning fundamentals.

I see the opposite.

The better your fundamentals are, the more safely and effectively you can use increasingly powerful tools.

The Skill Moves Upward

As tools improve, the value distribution changes.

At one time, manually writing assembly code was a large part of programming.

Higher-level languages automated much of that work.

Compilers became better.

Frameworks automated recurring application structures.

Cloud platforms automated infrastructure primitives.

None of these changes eliminated the need for engineering.

They moved the abstraction boundary.

AI may do the same thing to a much larger portion of implementation work.

The consequence may be that more value moves toward:

• specification;
• architecture;
• integration;
• validation;
• security;
• systems thinking;
• domain knowledge;
• technical judgment.

That does not guarantee that every current job survives unchanged.

It means that learning only the easiest mechanical layer of development is an increasingly weak career strategy.

Do Not Become an AI Operator Who Cannot Engineer

There is a new failure mode that I believe students should take seriously.

A person can become highly skilled at:

• prompting;
• selecting models;
• running agents;
• copying generated patches;
• iterating until tests pass

while remaining unable to independently explain the system being produced.

That can create an illusion of rapid progress. The repository becomes larger. Features appear. Tests become green.

But the person’s internal technical model remains shallow.

Eventually something happens outside the patterns the agent can resolve immediately.

At that point, the apparent productivity collapses.

Your goal should be [Engineer using AI] not AI operator dependent on generated engineering.

The difference is ownership of understanding.

A Practical Rule for Learning

During the learning phase, I recommend dividing AI use into three categories.

Green — Usually Safe

AI can help you with:

• explaining terminology;
• generating additional examples;
• checking grammar;
• creating practice questions;
• comparing approaches after you have attempted the problem;
• explaining compiler errors;
• finding relevant documentation;
• producing boilerplate you already understand.

Yellow — Use Carefully

AI can help with:

• debugging;
• refactoring;
• test generation;
• architecture brainstorming;
• unfamiliar libraries;
• performance ideas.

But you should independently verify the result.

Red — Do Not Delegate Your Learning

Be very careful about asking AI to:

• solve every task before you try;
• design complete systems you do not understand;
• make security decisions for you;
• perform destructive operations without review;
• choose architecture only because the answer sounds convincing;
• write code that you cannot explain;
• replace your own investigation every time you become stuck.

The purpose of learning is not to produce the final file.

The purpose is to build the mind that can produce, understand, and repair the file.

What I Expect From You in This Task Library

Using AI while working through this Task Library is not automatically wrong.

But the purpose of the Task Library is to develop your own technical capability.

If you give every task to an agent and copy the result, you can technically complete hundreds of tasks while learning very little.

That defeats the entire purpose.

When you use AI, I want you to be able to answer:

• What did the model contribute?
• What did you contribute?
• What did you verify?
• What did you reject?
• What did you change?
• Why does the final implementation work?
• What would you do if the model were unavailable?

The final question is especially important.

If removing access to an AI tool completely removes your ability to continue working, you have created dependency rather than leverage.

The Goal Is Leverage Without Dependency

This is the balance I recommend:

Knowledge + Experience + Judgment + AI = Leverage

Not:

AI = Substitute for knowledge

AI should allow a capable engineer to explore more possibilities, automate repetitive work, access information faster, and reduce mechanical effort.

It should not remove the requirement to think.

Public Research: What the Evidence Currently Suggests

The current evidence is not consistent with either extreme claim:

AI does nothing useful.

or:

AI has already made software engineers obsolete.

Research currently shows a more complicated picture.

AI Can Substantially Accelerate Bounded Tasks

A controlled GitHub Copilot experiment reported a large speedup on a specific JavaScript HTTP-server implementation task.

This demonstrates that AI assistance can have very real productivity value.

AI Can Also Slow Experienced Engineers in Some Environments

METR’s early-2025 randomized study found experienced developers were slower with AI on the mature open-source repositories studied.

The same researchers later reported that newer tools probably improved productivity, but measurement became difficult because developers increasingly did not want to work without AI.

Benchmark Performance Can Overstate Production Usefulness

METR’s 2026 maintainer-review experiment found a substantial gap between automated SWE-bench success and whether maintainers would merge the resulting patches.

Agents Can Already Complete Some Substantial Long-Horizon Implementation Tasks

MirrorCode provides evidence that modern agents can autonomously perform some implementations estimated to require humans weeks.

This means we should expect capability to continue expanding.

Organizational Quality Still Matters

DORA’s research suggests AI behaves as an amplifier of the engineering environment around it.

Strong processes can capture more benefit.

Weak processes can produce more instability.

Developers Use AI Heavily but Do Not Blindly Trust It

The Stack Overflow 2025 survey shows widespread adoption together with substantial distrust of output accuracy and significant concern around AI-agent security and privacy.

These findings are not contradictory.

They describe a technology that is already extremely useful, improving rapidly, and still dependent on careful human integration.

Final Perspective

I do not recommend fearing AI. I also do not recommend worshipping it. Learn to use it.

Learn where it is strong. Learn where it is weak.

Learn how to verify it. Learn how to restrict it.

Learn how to measure whether it is actually helping you.

And most importantly:

build enough knowledge that you remain the engineer in the relationship.

The future of software engineering will almost certainly involve increasingly capable AI systems.

That makes deep understanding more valuable, not less.

The person who understands the system can use the tool.

The person who only understands the tool remains dependent on whatever the tool produces.

My recommendation is simple:

Use AI to increase the reach of your engineering ability.
Do not use AI to avoid developing engineering ability.

Public Research and References

The sources below are included because AI capability and AI-assisted development are changing rapidly. Results should always be interpreted in the context of the models, tools, tasks, and time period studied.

1. DORA — State of AI-assisted Software Development 2025
   AI is described primarily as an amplifier of existing organizational strengths and weaknesses.
   https://dora.dev/research/2025/dora-report/

2. DORA — Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use (2026)
   Discusses the trade-off between faster generation and increased auditing and verification work.
   https://dora.dev/insights/balancing-ai-tensions/

3. DORA — Impact of Generative AI in Software Development
   Reports individual productivity and well-being benefits alongside software-delivery trade-offs.
   https://dora.dev/ai/gen-ai-report/report/

4. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
   Randomized study in which experienced developers working on mature repositories took approximately 19% longer when AI tools were allowed.
   https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

5. METR — We Are Changing Our Developer Productivity Experiment Design (2026)
   Follow-up explaining why newer data suggests greater AI productivity benefits but cannot provide a clean estimate because of selection effects.
   https://metr.org/blog/2026-02-24-uplift-update/

6. METR — Many SWE-bench-Passing PRs Would Not Be Merged into Main (2026)
   Maintainer review showed a substantial gap between automated benchmark success and merge-quality code.
   https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/

7. Epoch AI / METR — MirrorCode: Evidence AI Can Already Do Some Weeks-Long Coding Tasks (2026)
   Demonstrates that frontier agents can autonomously complete some substantial, checkable software reimplementation tasks.
   https://epoch.ai/publications/mirrorcode-preliminary-results

8. Stack Overflow — 2025 Developer Survey: AI
   Reports widespread AI adoption alongside low trust, accuracy concerns, debugging friction, and security/privacy concerns.
   https://survey.stackoverflow.co/2025/ai

9. Peng, Kalliamvakou, Cihon, Demirer — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
   Controlled experiment reporting a 55.8% completion-time improvement on a bounded JavaScript implementation task.
   https://arxiv.org/abs/2302.06590

10. Liu et al. — Lost in the Middle: How Language Models Use Long Contexts
    Research demonstrating that having a long context window does not guarantee equally reliable use of all information within it.
    https://arxiv.org/abs/2307.03172

11. NIST — Secure Software Development, Security, and Operations Practices: The Role of AI in Software Development
    Recommends human monitoring, validation, and scrutiny of AI-generated software content.
    https://pages.nist.gov/nccoe-devsecops/introduction.html

12. NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
    Provides a risk-management framework covering security, privacy, reliability, intellectual property, and other generative-AI risks.
    https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

13. European Commission — General-Purpose AI Obligations Under the AI Act
    Describes GPAI-provider obligations including copyright policies and publication of training-content summaries.
    https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act

14. U.S. Copyright Office — Artificial Intelligence Study
    Public work covering AI-generated outputs, copyrightability, digital replicas, and generative-AI training.
    https://www.copyright.gov/policy/artificial-intelligence/

Preserve The Engineering Development Chain

We Must Preserve the Engineering Development Chain

There is another problem that is rarely discussed seriously enough.

Software engineering has a development chain.

That chain looks approximately like this:

          Training
              ↓
          Internship
              ↓
        Junior Engineer
              ↓
        Mid-Level Engineer
              ↓
        Senior Engineer
              ↓
        Technical Lead      
              ↓
        Technical Principal      
              ↓
          Architect

You cannot permanently remove one part of that chain and expect the rest of it to continue existing. There are no new architects without new senior engineers. There are no new senior engineers without new junior engineers. And there is no architect in the world who somehow appeared at the architect level without previously going through earlier stages of development. Every architect was once a junior. Every senior engineer was once a junior. Every experienced engineer once had questions that today may appear completely basic. That is how technical development works.

A junior engineer is not simply a cheaper version of a senior engineer.

A junior engineer is a future senior engineer in development.

If companies stop hiring and training junior engineers because they believe AI can perform the simpler parts of their work, they are not solving the problem. They are postponing it. For several years, everything may appear completely fine. Existing senior engineers still exist. Architects still exist. Technical leads still exist.

The organization continues working. But then time passes. People leave. People retire. People move into management. People change industries. Some stop working completely. And suddenly the organization discovers that it has created no new generation capable of replacing them.

The pipeline has been broken. The situation then looks like this:

        Existing Architects
        Existing Seniors
                ↓
                ↓
                ↓
        No new Juniors
                ↓
        No new Mid-Level Engineers
                ↓
        No new Seniors
                ↓
        No new Architects

You cannot solve that problem later by simply deciding:

Now we need more senior engineers.

Senior engineers are not manufactured in six months.

Architects are not created by changing someone’s job title.

Technical depth requires years of:

• implementation;
• debugging;
• failure;
• production incidents;
• bad decisions;
• good decisions;
• refactoring;
• migrations;
• system design;
• maintenance;
• learning from more experienced people.

That process cannot begin if there is nobody at the beginning of the chain.

Junior Work Is Part of the Training Process

Another mistake is to look at junior-level work and conclude:

AI can do this task, therefore we no longer need juniors.

That completely misses the point.

Some tasks given to junior engineers are not important only because the organization needs the task completed.

They are important because the engineer needs to go through the process of completing them.

There is a major difference.

A junior may spend hours understanding:

• why a test fails;
• how an HTTP request works;
• why a database query behaves differently;
• how a race condition appears;
• why a process cannot open a file;
• why an interface was designed in a certain way.

A senior engineer may solve the same problem in ten minutes.

An AI agent may generate a working answer in several seconds.

But the junior’s purpose is not merely to compete with either of them on speed.

The junior is building the mental models that will later allow them to solve much larger problems.

If AI removes every small problem before the junior has the opportunity to struggle with it, investigate it, understand it, and finally solve it, then we may be removing part of the mechanism through which future expertise is created.

The output may appear faster.

The engineer may develop more slowly.

Those are two completely different measurements.

Someone Has to Train the Next Generation

Engineering knowledge does not transfer automatically. Someone has to:

• review code;
• explain mistakes;
• show alternatives;
• explain why a solution is dangerous;
• demonstrate debugging;
• teach system thinking;
• expose less experienced engineers to real problems.

That responsibility usually belongs to people further along the development chain.

A healthy engineering organization therefore has something like:

        Architects
            ↓ mentor and guide
        Senior Engineers
            ↓ mentor and guide
        Mid-Level Engineers
            ↓ help and guide
        Junior Engineers

But knowledge also moves upward. Junior engineers ask questions. They challenge assumptions. They encounter problems from a different perspective. They force experienced engineers to explain decisions that may have become automatic after many years. A healthy technical organization is not simply a collection of isolated experts.

It is a continuous transfer of knowledge between generations of engineers.

AI Cannot Be Allowed to Break That Chain

AI can absolutely become part of that development process. It can:

• explain concepts;
• provide additional examples;
• generate practice tasks;
• assist debugging;
• reduce repetitive work;
• provide another perspective.

But it should not become an excuse for removing the beginning of the engineering career path.

If the industry reaches the conclusion:

        AI can perform junior tasks
                ↓
        therefore we stop hiring juniors

then several years later the same industry may discover:

        we cannot find enough seniors

And several years after that:

        we cannot find enough architects

At that point, the cause should not be difficult to understand. The chain was broken at the beginning.

There Is No Shortcut to Experience

Experience is accumulated. You cannot prompt your way into ten years of production experience.

You cannot skip [Junior/Mid-Level/Senior] and simply become [Architect], because an AI model can generate architecture diagrams and code.

An architect needs to understand the consequences behind those diagrams. A senior engineer needs to recognize why something that appears correct today may create a serious problem two years later. That ability comes from accumulated exposure to real systems.

And that exposure begins somewhere. Usually, it begins with small problems. Junior problems.

Tasks that look insignificant to an architect today but were once necessary steps in that architect’s own development. Do not forget that.

There is no architect who was never a junior.

If we want future senior engineers, we need junior engineers today.

If we want future architects, we need future senior engineers.

If we want software engineering to remain a serious profession, we have to preserve the complete development chain.

AI can become part of that chain. It should not be allowed to destroy it.

Programming and Software Engineering

Programming and software engineering are closely related.

But they are not the same thing. Programming is one part of software engineering.

And this distinction becomes more important as the size, lifetime, complexity, and responsibility of a system increase.

A programmer primarily asks:

How do I make this work?

A software engineer eventually has to ask:

How do I make this work correctly, safely, predictably, maintainably, and as part of a much larger system that will continue changing for years?

Those are different levels of responsibility.

Programming

Programming is the act of creating instructions that a computer can execute.

At its most basic level, programming includes:

• variables;
• conditions;
• loops;
• functions;
• data structures;
• algorithms;
• file operations;
• network calls;
• database operations;
• error handling;
• concurrency;
• interaction with operating systems and libraries.

A programming problem may look like:

Read a file, parse the data, calculate a result, and write the output.

Or:

Accept an HTTP request, validate it, store something in a database, and return a response.

Or:

Sort this collection efficiently.

Or:

Process these jobs concurrently.

The central concern is usually the implementation itself. You are given a problem. You write code that solves it. At that level, success may be defined very simply:

          Input
            ↓
         Program
            ↓
        Expected Output

If the output is correct, the program may be considered successful. For small and isolated problems, that can be completely sufficient.

Software Engineering

Software engineering begins when the problem is no longer only:

Can I make this code work?

The questions become much broader. For example:

• Should this functionality exist in this service?
• Who owns this data?
• What happens if the database is unavailable?
• What happens if the same request arrives twice?
• Can the operation be safely retried?
• What happens under concurrent access?
• How does the system behave under load?
• How do we deploy this change?
• How do we roll it back?
• How do we migrate old data?
• How do we maintain backward compatibility?
• How do we monitor failures?
• How do we debug the system in production?
• What happens when requirements change next year?
• Can another team understand and maintain this?
• How much will this cost to operate?
• What security assumptions are we making?

At this point, code becomes only one part of the problem.

Software engineering is concerned with the complete lifecycle of a software system. That includes:

        Requirements
            ↓
        Analysis
            ↓
         Design
            ↓
        Implementation
            ↓
        Testing
            ↓
        Deployment
            ↓
        Operation
            ↓
        Monitoring
            ↓
        Failure handling
            ↓
        Maintenance
            ↓
        Evolution

A programmer can write a correct function.

A software engineer/developer has to understand what that function means inside the system around it.

A Simple Example

Imagine that the requirement is:

Save a user into a database.

At a programming level, the solution may look like this:

        Receive request
            ↓
        Validate fields
            ↓
        INSERT INTO users
            ↓
        Return success

That may work perfectly.

But software engineering starts asking questions that are not visible in that four-step implementation.

For example:

What makes a user unique?

Can two requests create the same user concurrently?

What happens if the client retries the request?

Do we need idempotency?

Which service owns user data?

Can another service modify it?

What happens when the database is temporarily unavailable?

Do we retry?

How many times?

What happens if the database write succeeds
but the response never reaches the client?

How is this audited?

Who is allowed to perform the operation?

How do we migrate the schema later?

How do we delete the data if required?

How do we restore it after failure?

The code may still be only twenty lines.

The engineering problem may be much larger than those twenty lines.

Working Code Is Not Necessarily Good Software

This is one of the first important distinctions you need to understand.

Code can work and still be bad.

A system can produce the correct output and still have serious problems.

For example, it may be:

• impossible to maintain;
• insecure;
• inefficient;
• tightly coupled;
• difficult to test;
• impossible to scale;
• unreliable;
• difficult to deploy;
• difficult to observe;
• impossible to modify without breaking something else.

The statement:

It works.

is therefore not the end of an engineering discussion.

It is often only the beginning.

A stronger question is:

Under which conditions does it work, and what happens when those conditions are no longer true?

Programming Solves the Immediate Problem

Programming often focuses on the current implementation.

For example:

I need to parse this JSON.

I need to send this HTTP request.

I need to process these records concurrently.

I need to write this file.

Those are valid technical problems.

Software engineering asks how those solutions interact with a larger system.

For example:

Why are we using JSON here?

What is the contract between these services?

What happens if the schema changes?

How do we preserve compatibility?

What happens if one worker fails?

What happens if the file is partially written?

How do we detect corruption?

The programmer is often solving the visible task.

The engineer is also responsible for the consequences around that task.

Software Engineering Is About Trade-Offs

Programming problems often have answers that are clearly correct or incorrect.

Software engineering frequently does not.

Instead, you work with trade-offs.

For example:

Performance
    vs
Readability

Consistency
    vs
Availability

Development speed
    vs
Long-term maintainability

Flexibility
    vs
Complexity

Redundancy
    vs
Cost

Abstraction
    vs
Simplicity

There is rarely one perfect answer.

The correct solution depends on:

• requirements;
• constraints;
• scale;
• risk;
• cost;
• expected lifetime;
• team structure;
• operational environment.

That is why experience becomes increasingly important.

Syntax alone cannot teach judgment.

Scale Changes the Nature of the Problem

A program with:

500 lines of code

and an infrastructure with:

20 services
+
multiple databases
+
several environments
+
many teams
+
years of development

are not the same engineering problem at different sizes.

At some point, scale changes the nature of the work itself.

New problems appear:

• ownership;
• coordination;
• contracts between teams;
• versioning;
• compatibility;
• observability;
• distributed failure;
• deployment sequencing;
• data migration;
• operational responsibility.

The complexity does not increase only because there is more code.

It increases because there are more relationships.

This is extremely important.

A system with ten components does not simply have ten independent things to understand.

Those components may interact in dozens or hundreds of different ways.

That interaction is where much of software engineering begins.

Engineering Includes Failure

Programming education often focuses on the success path.

For example:

Open file
Read file
Process file
Close file

Engineering asks:

What if the file does not exist?

What if permission is denied?

What if the disk is full?

What if the process crashes during the write?

What if two processes modify the file?

What if the data is corrupted?

What if the machine loses power?

Real systems fail.

Networks fail.

Disks fail.

Processes crash.

Dependencies become unavailable.

Humans make mistakes.

Configurations drift.

Certificates expire.

The ability to think about failure is one of the major differences between simply writing code and engineering systems.

Engineering Includes Time

A program may be written once and used once.

Software systems often live for years.

That changes everything.

You now have to think about:

• upgrades;
• migrations;
• compatibility;
• deprecations;
• old clients;
• changing dependencies;
• new team members;
• historical data;
• evolving requirements.

Something that looks elegant today may become a serious problem after five years.

Engineering therefore requires you to think not only about:

Does it work now?

but also:

Can it evolve later?

That is a completely different question.

Engineering Includes Other People

Programming can be an individual activity.

Software engineering usually is not.

A production system may involve:

• developers;
• engineers;
• QA;
• DevOps;
• SysOps;
• security teams;
• database teams;
• product teams;
• architects;
• operations;
• customers.

Your code has to coexist with the work of other people.

That means software engineering also includes:

• documentation;
• code review;
• naming;
• interfaces;
• standards;
• communication;
• predictable behavior.

Code that only its author understands may technically work.

It is still poor engineering if ten other people need to maintain it.

Engineering Includes Responsibility

This is probably the most important distinction.

Programming asks whether the implementation is correct.

Engineering also asks:

Who is responsible when it fails?

If you write software for:

• banking;
• healthcare;
• aviation;
• electrical infrastructure;
• authentication;
• security;
• large cloud systems

the consequences of bad decisions can become serious.

At that point, software is no longer simply an intellectual exercise.

It has operational consequences.

An engineer must understand that.

Knowing a Programming Language Is Not Software Engineering

Knowing:

Go

or:

Rust

or:

Java

does not automatically make someone a software engineer.

A language is a tool.

The same applies to frameworks.

Knowing:

React
Kubernetes
PostgreSQL
Docker

does not by itself create engineering ability.

Engineering ability appears when you understand:

• when to use something;
• why to use it;
• when not to use it;
• what consequences it introduces;
• what alternatives exist.

The difference is significant.

A programmer may know how to use Kafka.

An engineer should also be able to ask:

Do we actually need Kafka?

That question can be more valuable than knowing every Kafka configuration option.

Software Engineering Does Not Mean Writing Less Code

Do not misunderstand this distinction.

Software engineering does not mean that you become “too senior” to write code.

Quite the opposite.

Strong engineering is usually built on strong implementation experience.

It is difficult to make good architectural decisions if you do not understand what those decisions mean at code level.

Drawing:

Service A
    ↓
Queue
    ↓
Service B

takes seconds.

Implementing that correctly may involve:

• retries;
• ordering;
• deduplication;
• serialization;
• backpressure;
• monitoring;
• dead-letter queues;
• failure recovery;
• deployment;
• schema evolution.

Architecture without implementation understanding is dangerous.

The Progression

A useful way to visualize the difference is through progression.

At the beginning, you may focus primarily on:

How do I write this?

Then:

How do I write this correctly?

Then:

How does this interact with the rest of the application?

Then:

How does this behave inside the service?

Then:

How does this service behave inside the system?

And eventually:

Should this system be designed this way at all?

That progression is software engineering.

Programming Is Necessary

None of this means programming is somehow less important.

You cannot become a strong software engineer without knowing how software is actually built.

Programming is the foundation.

If you cannot:

• write code;
• debug code;
• read code;
• understand memory;
• understand concurrency;
• understand data structures;
• understand networking;
• understand operating-system behavior

then higher-level engineering discussions quickly become theoretical.

Software engineering builds on programming. It does not replace it.

The Simplest Difference

If I had to reduce the entire distinction to one statement, it would be this:

Programming is primarily about creating software that works. Software engineering is about creating software that continues to work as the system, requirements, environment, teams, and time around it change.

That difference is enormous.

Do not rush to call yourself an engineer because you learned a programming language. And do not think that programming is somehow beneath engineering. They are parts of the same progression:

• First, learn to make things work.
• Then learn why they work.
• Then learn how they fail.
• Then learn how they interact with other systems.
• Then learn how to maintain them.
• Then learn how to design them for change.
• Then learn how to make decisions that other people can depend on.
• That is the path from programming toward software engineering.

Programming Languages Are Not Interchangeable

You will often hear the following statement:

The programming language does not matter. A programming language is only a tool.

The second sentence is partially true.

A programming language is a tool.

But the conclusion that the choice of language therefore does not matter is completely wrong.

Tools are chosen according to the problem.

A hammer and a microscope are both tools.

That does not make them interchangeable.

Programming languages are the same.

The language you choose affects:

• performance;
• memory consumption;
• memory safety;
• concurrency;
• latency;
• startup time;
• runtime requirements;
• deployment;
• binary size;
• portability;
• hardware access;
• operating-system integration;
• development speed;
• type safety;
• failure modes;
• maintainability;
• available libraries;
• ecosystem maturity.

Different languages were designed around different priorities.

Because of that, there is no serious engineering environment in which language choice is completely irrelevant.

The Problem Determines the Language

If you are building:

a small internal automation script

your priorities may be completely different from those of someone building:

a database engine

or:

an operating-system component

or:

a real-time rendering engine

or:

a distributed infrastructure platform processing millions of concurrent operations

Using the same language for all of those problems simply because:

language does not matter

is not technical flexibility.

It is refusing to understand the problem.

The correct approach is:

Problem
   ↓
Requirements
   ↓
Constraints
   ↓
Runtime characteristics
   ↓
Operational environment
   ↓
Programming language

Not:

I know language X
   ↓
therefore every problem will be solved with X

Low-Level and High-Level Programming Languages

The distinction between low-level and high-level programming languages is important because different languages expose very different levels of control over the machine, runtime, memory, and execution model.

This is not a question of which group is better.

It is a question of:

How much responsibility remains in the hands of the programmer, and how much is handled by the language, compiler, runtime, virtual machine, or framework?

There is also one important thing to understand:

Low-level and high-level are not perfectly separated categories. They exist on a spectrum.

Some languages expose direct control over memory and hardware.

Some hide almost all of that complexity.

Some sit somewhere in between.

The engineering value comes from understanding what each language gives you, what it hides from you, and where those trade-offs become useful or dangerous.

Low-Level Languages

Low-level languages give the programmer much more direct control over:

• memory;
• pointers;
• allocation;
• deallocation;
• data layout;
• resource lifetime;
• system calls;
• operating-system interfaces;
• hardware interaction;
• synchronization;
• CPU-level behavior.

With that control comes responsibility.

You gain the ability to optimize deeply.

You also gain the ability to create very serious failures.

The clearest examples in modern software engineering are:

• C;
• C++;
• Rust.

C

C is one of the foundational low-level languages of modern computing.

It gives the programmer direct control over:

• memory;
• pointers;
• data representation;
• system calls;
• hardware access;
• resource management.

C is heavily used in:

• operating systems;
• kernels;
• device drivers;
• firmware;
• embedded systems;
• networking stacks;
• database engines;
• compilers;
• runtime libraries;
• hardware interfaces.

Its strength is simplicity and directness.

There is very little between your code and the machine.

Its weakness is the same thing.

C allows you to create extremely efficient software, but it also allows you to create:

• buffer overflows;
• use-after-free bugs;
• memory corruption;
• undefined behavior;
• security vulnerabilities.

C gives you control.

It does not protect you from incorrect use of that control.

C++

C++ keeps the low-level capabilities of C while adding much more abstraction.

It allows you to work with:

• pointers;
• manual memory management;
• RAII;
• templates;
• classes;
• generic programming;
• metaprogramming;
• low-level optimization;
• high-performance libraries.

C++ is especially strong in areas where performance, latency, graphics, or hardware control are critical.

Typical examples include:

• game engines;
• graphics engines;
• browsers;
• rendering systems;
• simulation;
• computer vision;
• databases;
• high-frequency trading;
• CAD systems;
• audio engines;
• native desktop applications.

C++ remains especially important in graphics because the surrounding ecosystem has decades of maturity.

If you work with:

• Vulkan;
• DirectX;
• OpenGL;
• rendering engines;
• physics engines;
• graphics drivers;
• large native game engines

C++ remains one of the strongest choices available.

Rust

Rust belongs to the systems-programming category.

It is designed to provide performance and low-level control comparable to C and C++, while preventing many classes of memory-safety bugs at compile time.

Rust provides:

• native performance;
• memory safety without a garbage collector;
• explicit ownership;
• predictable resource lifetime;
• strong type safety;
• strong concurrency guarantees;
• low-level control.

Rust is increasingly used for:

• system services;
• high-performance backend components;
• distributed infrastructure;
• networking;
• security-sensitive software;
• storage systems;
• command-line tools;
• WebAssembly;
• embedded systems;
• developer tooling.

Rust is especially attractive when the system requires:

        performance
        +
        memory safety
        +
        predictable resource control
        +
        concurrency

The cost is complexity.

Rust forces the programmer to understand ownership, borrowing, lifetimes, and resource relationships that many other languages hide.

That can make development harder at the beginning.

But it can also eliminate entire classes of runtime failures.

High-Level Languages

High-level languages hide more machine-level complexity from the programmer.

Instead of constantly thinking about:

• raw memory addresses;
• manual allocation;
• pointer arithmetic;
• resource lifetime;
• machine instructions;

the programmer can focus more on:

• application logic;
• business rules;
• service communication;
• data processing;
• user-facing behavior;
• product functionality.

High-level languages often rely on:

• garbage collectors;
• virtual machines;
• managed runtimes;
• interpreters;
• runtime type systems;
• large standard libraries.

Examples include:

• Go;
• Java;
• C#;
• Python;
• JavaScript.

These languages are not identical.

Some are much closer to systems programming than others.

Go

Go is a high-level compiled language with a strong systems and infrastructure orientation.

It was designed around:

• simplicity;
• networking;
• concurrency;
• fast compilation;
• easy deployment;
• server-side software;
• infrastructure development.

Go provides:

• garbage collection;
• native compilation;
• goroutines;
• channels;
• strong networking support;
• a large standard library;
• easy single-binary deployment.

Go is extremely common in:

• backend services;
• distributed systems;
• cloud infrastructure;
• microservices;
• networking systems;
• DevOps tooling;
• observability platforms;
• infrastructure automation;
• control planes.

Go became one of the dominant languages of the cloud-native ecosystem because it gives developers a very strong balance between:

        development speed
        +
        concurrency
        +
        networking
        +
        deployment simplicity

Compared with Rust:

           Go
            ↓
        simpler development
        garbage collection
        excellent networking
        fast iteration
        easy deployment

while:

          Rust
            ↓
        more control
        no garbage collector
        stronger memory guarantees
        predictable resource lifetime
        lower-level systems work

Both are extremely strong for modern infrastructure. They simply solve the problem from different positions on the abstraction spectrum.

Java

Java is a high-level language built around the Java Virtual Machine.

It provides:

• garbage collection;
• strong static typing;
• mature concurrency support;
• JIT compilation;
• large library ecosystems;
• mature profiling;
• mature observability;
• portability through the JVM.

Java is extremely common in:

• enterprise systems;
• banking;
• financial infrastructure;
• large backend systems;
• distributed systems;
• data platforms;
• messaging systems;
• long-lived business applications.

Its strength comes from:

• ecosystem maturity;
• runtime optimization;
• tooling;
• long-term stability;
• massive industry adoption.

C#

C# is a high-level language primarily associated with the .NET ecosystem.

It provides:

• garbage collection;
• strong static typing;
• async programming;
• mature tooling;
• a cross-platform runtime;
• a strong enterprise ecosystem.

C# is widely used for:

• enterprise applications;
• backend services;
• APIs;
• cloud systems;
• business applications;
• desktop applications;
• Microsoft-oriented infrastructure;
• game development through Unity.

Python

Python is a very high-level language designed around:

• simplicity;
• readability;
• development speed;
• rapid experimentation.

Python hides a large amount of low-level system complexity. It is especially strong for:

• automation;
• scripting;
• data science;
• machine learning;
• AI;
• scientific computing;
• testing;
• backend applications;
• data processing;
• prototyping.

Python is not primarily chosen for raw execution performance.

Its value comes from how quickly developers can build, test, and change things.

An important detail is that much of the high-performance work in the Python ecosystem is actually executed by native code written in:

• C;
• C++;
• CUDA;
• Rust;
• Fortran.

Python often acts as the high-level control layer. That is a perfect example of how different levels of programming languages can work together.

JavaScript

JavaScript is a high-level language that became dominant because it is the native programming language of the web browser.

Its strongest areas include:

• frontend development;
• browser applications;
• interactive websites;
• web interfaces;
• Node.js backend services;
• full-stack web applications;
• desktop applications built on web technologies.

Modern JavaScript runtimes are highly optimized.

But JavaScript is still designed around a completely different problem space from C, C++, or Rust.

JavaScript is an obvious choice for:

browser application

It is not an obvious choice for:

operating-system kernel

The fact that both are programming languages does not make them interchangeable.

Practical Comparison

A simplified overview looks like this:

Low-Level Does Not Mean Better

One of the worst conclusions you can make is:

Low-level languages are better because they are closer to the machine.

No.

They are better when the problem requires that level of control.

If you need to write:

a short automation script

using C++ may be completely pointless.

Python may be the better engineering choice.

If you are writing:

a high-performance storage engine

Python may be a poor choice.

C++, Rust, or another systems language may make much more sense.

The problem determines the language.

High-Level Does Not Mean Weak

The opposite mistake is also wrong.

High-level languages are not automatically weak.

Java powers enormous financial and enterprise systems.

Go powers a huge part of modern cloud infrastructure.

C# powers large enterprise platforms.

Python powers a large part of the AI and data ecosystem.

JavaScript powers almost the entire interactive web.

High-level languages remove certain responsibilities from the programmer so that effort can be spent elsewhere.

That is often exactly what you want.

The Real Difference

The simplest way to understand the distinction is:

Low-level languages
        ↓
more machine control
more explicit resource management
more responsibility
more opportunity for optimization

while:

High-level languages
        ↓
more abstraction
more runtime assistance
less manual resource management
faster application development

Neither side wins universally. The question is always:

What does this system actually require?

That is the engineering decision.

Clean Code and a Quality Engineering Environment

Clean and high-quality software is not defined only by whether the code compiles or whether the application currently works.

A serious engineering environment is defined by the complete system around the code.

That includes:

• clean and understandable code;
• flexibility;
• modularity;
• scalability;
• level of testing;
• migrations;
• backup and recovery;
• automation processes;
• CI/CD;
• documentation.

A system can be technically functional and still be a terrible engineering environment.

The goal is not only:

Make it work.

The goal is:

Make it understandable, changeable, testable, recoverable, deployable, scalable, and maintainable.

Clean and Understandable Code

Clean code is not code that looks clever.

It is code that other people can understand.

A clean codebase should make it relatively easy to answer:

• What does this component do?
• Why does it exist?
• Where does this data come from?
• What depends on this function?
• What can fail here?
• What happens when it fails?
• Where should I make a change?
• What should not be changed?

Clean code usually has:

• clear naming;
• small and understandable responsibilities;
• predictable structure;
• limited hidden behavior;
• minimal unnecessary abstraction;
• consistent error handling;
• clear dependencies;
• understandable control flow.

A function should not require archaeology.

A developer should not need hours to understand why a variable exists.

Complex systems are already difficult enough.

The code should not make them more difficult.

Clean code is not about style for the sake of style.

It is about reducing unnecessary mental load.

Flexibility

Flexibility means that the system can absorb change without requiring destructive rewrites:

• Requirements change.
• Business rules change.
• Protocols change.
• Dependencies change.
• Infrastructure changes.
• A rigid system turns every change into a large refactor.
• A flexible system allows change to remain local.

For example:

new storage backend

should not require rewriting the entire application.

new authentication provider

should not require changing every service.

Flexibility comes from:

• good boundaries;
• clear interfaces;
• limited coupling;
• replaceable components;
• separation of responsibilities.

The goal is not infinite abstraction.

The goal is controlled change.

Modularity

Modularity means splitting a system into components with clear responsibilities.

A good module should have:

• a clear purpose;
• a clear interface;
• controlled dependencies;
• limited knowledge of other modules.

Bad modularity looks like:

        Module A
        depends on
        Module B
        depends on
        Module C
        depends on
        Module A

Everything knows about everything.

At that point, the system is not modular.

It is only divided into files.

Good modularity allows you to:

• change one part without breaking everything;
• test components independently;
• replace components;
• understand boundaries;
• assign ownership.

A thousand directories do not automatically create modularity.

The boundaries must be real.

Scalability

Scalability means that the system can handle growth without collapsing. Growth may mean:

• more users;
• more requests;
• more data;
• more services;
• more teams;
• more regions;
• more infrastructure.

Scalability is not only about CPU performance. A system may scale technically and still fail operationally or organizationally. For example:

100 services

are useless if every small change requires coordination between thirty teams.

Scalability includes:

• technical scalability;
• operational scalability;
• organizational scalability.

You should think about:

• horizontal scaling;
• vertical scaling;
• bottlenecks;
• database limits;
• network limits;
• lock contention;
• queue behavior;
• storage growth;
• deployment complexity;
• team ownership.

A scalable system is not simply a fast system. It is a system that can grow without becoming unmanageable.

Level of Testing

Testing is one of the clearest indicators of engineering maturity. A system without serious testing forces every change to depend on hope. Testing should exist on several levels.

Unit Tests

Unit tests validate isolated pieces of logic.

They should be:

• fast;
• deterministic;
• easy to run;
• focused.

Integration Tests

Integration tests validate that multiple components work together.

Examples include:

• service and database;
• service and message broker;
• client and API;
• storage and migration logic.

End-to-End Tests

End-to-end tests validate complete workflows.

They answer:

Does the system actually work from the user’s perspective?

Regression Tests

Regression tests protect against bugs that have already happened once.

If a production bug is fixed and no regression test is added, the organization has learned very little from that incident.

Performance Tests

Performance tests validate:

• latency;
• throughput;
• resource consumption;
• behavior under load.

Failure Tests

Serious systems should also test failure.

For example:

• dependency unavailable;
• network timeout;
• partial response;
• corrupted data;
• process crash;
• retry behavior.

A high-quality engineering environment does not test only the success path.

It tests how the system behaves when reality becomes ugly.

Migrations

Systems evolve. Schemas change. Data formats change. Protocols change. APIs change. Infrastructure changes. Migration strategy is therefore part of engineering.

A good migration process should consider:

• backward compatibility;
• rollback;
• partial deployment;
• old clients;
• data conversion;
• versioning;
• failure recovery.

One of the worst migration strategies is to deploy everything at once and hope for the best.

A better migration may look like:

        introduce new schema
                ↓
        support old and new format
                ↓
          migrate data
                ↓
          move clients
                ↓
             verify
                ↓
        remove old path

Migration is not some maintenance task that happens after engineering. Migration is engineering.

Backup and Recovery

A backup that has never been restored is not a proven backup.

A backup strategy should answer:

• What is backed up?
• How often?
• Where is it stored?
• How long is it retained?
• Is it encrypted?
• Who can access it?
• Can it actually be restored?
• How long does restoration take?

Two important concepts are:

Recovery Point Objective

How much data can we afford to lose?

Recovery Time Objective

How long can the system remain unavailable?

A production system needs both backup and recovery planning.

The worst time to discover that your backup process is broken is after the primary database has already been lost.

Automation Processes

Repeated manual work creates repeated human error.

If a process is:

• predictable;
• repetitive;
• frequent;
• important;

it should probably be automated.

Examples include:

• builds;
• tests;
• packaging;
• artifact generation;
• versioning;
• deployments;
• environment provisioning;
• database migrations;
• security checks;
• backups;
• report generation.

Automation should reduce:

        manual steps
        +
        human error
        +
        inconsistent execution

The goal is not to automate everything blindly.

The goal is to automate processes where repetition creates unnecessary risk.

CI/CD

CI/CD is not simply:

Push code and automatically deploy production.

That is a shallow interpretation.

Continuous Integration should continuously validate changes.

A CI pipeline may include:

        checkout
            ↓
        dependency validation
            ↓
          build
            ↓
        unit tests
            ↓
        integration tests
            ↓
        static analysis
            ↓
        security checks
            ↓
        artifact creation

Continuous Delivery or Continuous Deployment adds controlled release processes.

That may include:

        artifact verification
                ↓
        staging deployment
                ↓
        smoke tests
                ↓
        migration checks
                ↓
        production deployment
                ↓
        health verification
                ↓
        rollback if required

A good CI/CD system should make deployments:

• repeatable;
• predictable;
• traceable;
• reversible.

The goal is to remove improvisation from the release process.

Documentation

Documentation is part of the system.

It is not decoration around the system.

A codebase without documentation forces knowledge to exist only inside people’s heads.

That is dangerous.

Documentation should exist on several levels.

Code Documentation

Explains:

• non-obvious behavior;
• public interfaces;
• important invariants;
• complex algorithms.

Service Documentation

Explains:

• what the service does;
• how to configure it;
• dependencies;
• APIs;
• deployment;
• monitoring;
• failure behavior.

Architecture Documentation

Explains:

• system boundaries;
• service relationships;
• data flows;
• important technical decisions;
• security boundaries.

Operational Documentation

Explains:

• deployment;
• recovery;
• incident procedures;
• backup restoration;
• maintenance.

Documentation should answer one very simple question:

If the person who built this system disappears tomorrow, can someone else understand, operate, and continue developing it?

If the answer is no, the system has a knowledge problem.

These Properties Are Connected

These qualities do not exist independently.

For example:

        poor modularity
                ↓
        difficult testing
                ↓
        dangerous migrations
                ↓
        fragile CI/CD
                ↓
        fear of deployment

Or:

        poor documentation
                ↓
        slow onboarding
                ↓
        incorrect changes
                ↓
        production incidents

Or:

        manual processes
                ↓
        inconsistent execution
                ↓
        human error
                ↓
        unreliable releases

Engineering quality is the result of the complete environment.

A Useful Quality Model

You can think about a mature engineering environment like this:

        Clean Code
            +
        Flexibility
            +
        Modularity
            +
        Scalability
            +
        Testing
            +
        Migration Strategy
            +
        Backup and Recovery
            +
        Automation
            +
        CI/CD
            +
        Documentation
            =
        Maintainable Engineering Environment

Every missing part increases risk.

Final Perspective

A professional engineering environment should not depend on heroics.

It should not require one specific person to remember everything.

It should not depend on manual rituals that only one engineer understands.

It should not create fear every time something is deployed.

The system should be designed so that:

• code is understandable;
• components are isolated;
• change is controlled;
• growth is possible;
• tests provide confidence;
• migrations are planned;
• data can be recovered;
• repetitive work is automated;
• releases are predictable;
• knowledge is documented.

That is the difference between:

software that currently works

and:

an engineering environment that can survive change

Getting Started

This section explains how to approach and work with the exercises in the Programming Task Library.

The library contains two main types of exercises:

• Algorithms — focused problems with defined inputs, processing requirements, and expected outputs.
• Modeling — larger scenarios focused on data modeling, relationships, behavior, validation, and system design.

The tasks were originally designed for Go and Rust, but most exercises can be implemented in other programming languages as well.

Before You Start

Do not begin by immediately writing code.

First, analyze the task and make sure you understand:

1. What data is provided as input?
2. What result is expected?
3. What conditions must be satisfied?
4. What edge cases may exist?
5. What validation is required?
6. Are there restrictions on the implementation?
7. Can the problem be divided into smaller operations?

For more complex tasks, especially modeling exercises, draw the relationships, execution flow, or possible outcomes before starting the implementation.

The goal is to understand the problem before choosing the solution.

Solving Algorithm Tasks

Algorithm tasks usually define:

• input data
• one or more function arguments
• processing rules
• expected return values
• example cases
• implementation constraints

Read the complete task before implementing the function.

Some requirements may depend on several conditions at the same time.

When examples are provided, use them to understand the expected behavior of the implementation.

Function Signatures

Function names and signatures shown in the tasks should be treated as part of the exercise when they are explicitly specified.

For example:

FindAllGreaterThen(data, 4.8)

or:

CreateGroups(list, 30, 90, 40, 70)

The exact type definitions and signatures will be shown on individual task pages when they are part of the original task specification.

Solving Modeling Tasks

Modeling tasks are intentionally broader than algorithm tasks.

Instead of implementing only a single function, you may need to design multiple structures and define relationships between them.

Before implementing a modeling task, identify the main entities in the scenario.

Then determine:

• what data belongs to each entity
• how entities are related
• what operations are required
• what validation rules exist
• what information must be searchable or queryable
• how data should be loaded, stored, or transformed

Do not create the complete model immediately.

Start with the domain and relationships, then build the implementation around them.

Validation and Error Handling

When a task explicitly requires validation or error handling, those requirements are part of the exercise and should not be ignored.

Consider situations such as:

• invalid input values
• malformed data
• failed type conversions
• missing values
• unsupported operators or options
• invalid ranges
• inconsistent input collections

The exact validation requirements depend on the individual task.

Do not assume additional restrictions unless they are stated or logically required by the task.

Expected Results

Many tasks provide one or more example inputs together with an expected result.

For example:

Input:
data = [[3.2, 5.4], [6.3, 1.4], [2.5, 6.5]]
threshold = 4.8

Expected Result:
[
    {5.4, 1, 2},
    {6.3, 2, 1},
    {6.5, 3, 2}
]

Your implementation should produce behavior consistent with the examples and requirements described by the task.

Examples should be treated as reference cases, not as the only possible inputs.

Implementation Restrictions

Always check whether a task or an entire group defines additional implementation restrictions.

Some exercises intentionally remove convenient language features in order to practice implementing the underlying algorithm manually.

For example, Algorithm Group 5 prohibits the use of built-in functions from the language core.

Such restrictions are part of the exercise.

Performance and Resource Usage

A correct result does not automatically mean that an implementation is efficient.

When solving a task, consider:

• time complexity
• memory usage
• unnecessary allocations
• repeated iterations
• unnecessary data copies
• appropriate data structures
• opportunities to simplify processing

You do not always need the theoretically fastest possible implementation.

The objective is to understand the trade-offs and avoid unnecessary work.

Testing

Use the examples provided by each task as initial test cases.

When appropriate, also test additional cases that may expose problems in the implementation.

Depending on the task, these may include:

• empty inputs
• boundary values
• duplicate values
• invalid values
• values outside expected ranges
• single-element collections
• large inputs

For modeling tasks, testing may also include validation of relationships, queries, state changes, and data-loading behavior.

If a task explicitly defines testing requirements, those requirements take priority.

Language Choice

Go, Rust and C++ are the primary languages associated with this library.

You are free to solve the exercises using either language.

Unless a task explicitly depends on a particular language feature, another programming language may also be used.

The important part is preserving the behavior and constraints defined by the task.

Recommended Workflow

A practical workflow for each exercise is:

        Read
          ↓
        Analyze
          ↓
        Model the problem
          ↓
        Identify edge cases
          ↓
        Choose an approach
          ↓
        Implement
          ↓
        Test
          ↓
        Review

After the implementation works, review it again.

Ask whether the solution can be made simpler, clearer, more efficient, or more reusable without unnecessarily increasing its complexity.

The purpose of the library is not only to complete the exercises.

The purpose is to practice the engineering process used to arrive at a good solution.

Mental Preparation

Before we begin with the technical side of things, we need to define something that is, in my opinion, even more important at the very beginning: mental preparation.

Unfortunately, this is something that is discussed very little, if at all.

You need to know what to expect. You need to have at least some understanding of what kind of profession you are entering, or what kind of profession you have just started building yourself into, and what you should be prepared for along the way.

This kind of training, learning, and mentorship is primarily intended for people who aim, at least theoretically, for some of the highest and most ambitious goals in software engineering, and for people who want to pursue this field because they are deeply interested in it and genuinely care about it.

What do I mean by genuinely caring about it? Very simply.

From my perspective, there is a fundamental difference between liking someone or something and loving someone or something. Those two things are not comparable.

I love what I do, and personally, I would not want to choose any other profession.

I think this is important for you to know from the beginning.

You should know who you are speaking with, how that person thinks, and how much this profession actually means to them.

The starting point of our conversation is based on three factors that, in my opinion, should form the foundation of any serious learning and development process:

• there are no easy and difficult tasks;
• do not compare yourself to others;
• exponential learning.

There Are No Easy and Difficult Tasks

There are no easy and difficult tasks.

There are tasks that you can currently do and tasks that you currently cannot do, depending on your goals, ambitions, needs, affinities, natural tendencies, general level of ability, and intellectual capacity. Do not begin by asking yourself questions such as:

• How difficult is this?
• How long will it take me to learn this?
• Will I be functional in three to six months?

When you approach learning this way, you unnecessarily create mental limits for yourself.

At that point, you almost do not need an external enemy anymore, because you have already started limiting yourself before the real work has even begun.

Instead, ask yourself questions such as:

• How strongly do I want to commit to this?
• At what level do I want to pursue this?
• What am I willing to give up in order to reach that level?
• How much do I need to change my current way of life in order to align it with my goals, and how ready am I to do that?
• How patient and calm am I?
• How much endurance do I have?
• How strong is my focus?
• What are my working habits like?

These questions force you into a much more objective analysis of your current position.

They help you understand what your next steps in the learning process should actually be.

Of course, this requires a certain level of self-awareness and self-criticism.

But those are also necessary parts of development and progress.

You need to be aware of what you can currently do, what you cannot yet do, and what exactly is missing between those two points.

Do Not Compare Yourself to Others

Do not compare yourself to other people.

Do not compare yourself to colleagues who are approximately at your level, or to people who started at roughly the same time as you in terms of functionality and productivity.

Focus on yourself. Focus on what you are doing, not on what everyone else is doing.

Comparison will usually bring very little value during the learning process and the early stages of development.

In many cases, it can become counterproductive or even self-destructive.

Be especially careful when looking at people who have ten, fifteen, or twenty years of experience.

Do not spend too much time observing or researching things that normally require years, and sometimes decades, of experience to fully understand.

From the perspective of someone who is still at an early stage of development, the level of complexity involved can easily appear completely unreachable.

That impression is often misleading. Instead, focus on what you are doing right now. Focus on your next step.

Focus on gradually expanding the range of things you are capable of understanding and doing.

Linear and Exponential Learning

There are linear and exponential ways of learning.

Linear learning means that, approximately speaking, every new unit of invested time or effort gives you a similar amount of new knowledge.

You learn one subject after another, but your previous knowledge does not dramatically accelerate your ability to understand the next thing.

In many cases, each new piece of information can also be learned and applied to a particular scenario relatively quickly.

You process the information, understand the basic mechanism, apply it, and very soon you can see a functional result.

Learning how to drive a car is one example. Learning how to prepare a specific meal is another.

You learn a sequence of actions, practice them, and relatively quickly you can produce a visible and functional result.

In practical software engineering, however, learning rarely works this way.

Software engineering is exponential learning.

You will not usually encounter one isolated thing, understand it immediately, and then apply it functionally to a real situation.

Instead, the process often looks more like this:

• You encounter ten different things.
• After some time, three of them begin to make sense.
• Eventually, those three things connect in a way that produces one functional result.
• As your knowledge grows, the number of possible connections between concepts grows as well.
• The learning process begins to branch.
• And as the branches expand, the overall level of complexity increases with them.

This applies to almost every field and subfield within software engineering.

That is something you need to understand from the beginning, because it directly affects the amount of patience, calmness, and mental stability you will need.

You may work on something for two months before you see a meaningful result. For some things, it may take a year.

There will be situations where you spend days or weeks preparing, drawing diagrams, analyzing systems, designing structures, or thinking through different approaches before you write any meaningful implementation at all.

And that is completely normal.

The important thing is to understand that lack of immediate visible output does not necessarily mean that nothing is happening.

A large part of software engineering learning happens before the result becomes visible.

You are building connections. You are building mental models.

You are gradually creating the internal structure that will later allow many different pieces of knowledge to work together.

That is why patience is not an optional quality in this profession. It is one of the foundations.

Time and Energy Management

The next step in our discussion is how you distribute your time and energy.

Of course, enthusiasm, ambition, motivation, and excitement about something new are important.

But it is equally important to understand how you spend and distribute your energy, time, and effort.

When you are absorbing a new type of information and learning how to analyze that information in a new way, maintaining a high level of focus over a relatively short period of time is one of the keys to adapting effectively and absorbing new knowledge.

People often say:

I currently have seven or eight free hours every day. I am going to spend all of that time learning.

Theoretically, you can do that.

The much more important question is how effective those seven or eight hours are actually going to be.

And this applies regardless of whether you have previously worked in a technical field or are entering one for the first time.

Instead, my suggestion is to begin with shorter and more focused sessions.

During the first week, experiment with schedules such as:

• 3 × 30 minutes
• 2 × 45 minutes
• 4 × 30 minutes
• 3 × 45 minutes
• 5 × 30 minutes
• 3 × 60 minutes
• 4 × 45 minutes

These are not rigid rules.

They are examples of different ways to distribute focused work while your mind is adapting to a new type of workload.

Alongside intensity, another extremely important factor is continuity.

During the adaptation period, you should work every day.

That does not mean that every day must be equally productive.

If there is a day when you can only manage two focused sessions of thirty minutes, that is completely acceptable.

What I would strongly avoid is a pattern such as:

• working for three days;
• stopping for two;
• working for five days;
• stopping for another three.

That kind of inconsistency can make adaptation significantly more difficult and can negatively affect both efficiency and productivity. During the first several days, observe yourself. Analyze which pace works best for you at the beginning. Once you understand that, gradually increase the intensity over time. Think about it in the same way you would think about starting physical training.

If you begin going to the gym, there is a period of adjustment, adaptation, and progressive loading. The principle here is similar. The difference is that sustained intellectual work can eventually become extremely demanding in its own way. Do not compare your initial working intervals with those of someone who works nine or ten hours a day and has ten or fifteen years of experience in the field. That comparison gives you almost nothing useful.

Continuity has to exist. Intensity increases over time.

A good approach is to create several different schedules and use them depending on the type of day you are having. Some days you will have more energy. Some days you will have less. The important thing is to preserve continuity while gradually increasing your capacity for concentrated work.

Health, Lifestyle, and Quality of Work

At the highest levels of development, software engineering can become more of a way of life than simply a choice of profession.

But health is far more important than software engineering.

From my personal perspective, I think about health and long-term functioning through five major areas:

• what is eating away at you mentally — stress, nervousness, and internal pressure;
• what you eat and consume;
• your general lifestyle and habits;
• your level of physical activity;
• how you sleep and how well you recover.

The quality of your work depends on many things:

• continuity;
• focus;
• persistence;
• determination;
• calmness;
• composure;
• attention to detail;
• patience;
• quality of adaptation;
• quality of analysis.

Your health and overall quality of life can influence every one of these factors.

I will give you an example from my own life:

• I try to reduce unnecessary distractions and disruptions to my focus as much as possible.
• I do not watch television.
• I do not spend time on social media.
• I try not to involve myself in conversations that I already know are likely to be unproductive, pointless, or mentally draining.
• I do not drink alcohol. I do not smoke. I do not use psychoactive substances.
• I do not drink carbonated soft drinks. I do not eat sweets.
• The sugars I consume come almost entirely from fruit, together with some honey that I occasionally put into tea.
• In general, I don’t eat highly processed foods.
• I try as much as possible to prepare my own food.
• I train 4-5 times a week, physical activity is very important for health.

That is essentially it. When written as a list, it may sound as though I have given up many things, but once those choices become normal habits and you live with them for a long enough period of time, you begin to notice how they affect you and how they influence different parts of your life.

I am not trying to act as a doctor here, and none of this should be interpreted as medical advice.

I am simply pointing out how important lifestyle can be for many different factors, including the quality of your work.

My own way of working, and the quality of work I am capable of producing, would not be anywhere near what it is today without the habits I have developed.

Some of those habits have always been part of my life. Others were developed gradually over time.

Mentorship or Courses?

One of the important questions in any technical field is:

Is it better to learn through mentorship or through courses?

My personal experience is strongly on the side of mentorship.

I have always been willing to invest my time in people who are stable, composed, calm, patient, and understanding. People in whose eyes I could see a genuine desire to transfer knowledge. People who were visibly satisfied when something they had taught me was later understood, applied, or successfully used somewhere else.

I have always been drawn to people who genuinely enjoy what they do and who have a certain amount of passion and enthusiasm for it. That does not mean that every mentor will have the same level of knowledge or experience. They will not. If a mentor gives you the maximum value they can provide from the knowledge and experience they currently possess, that relationship can be far more functional and effective than almost any course.

Unfortunately, I have met many people with extremely broad technical knowledge who simply did not know how to transfer that knowledge to someone else. They knew the subject. But they could not bring it closer to another person. They could not explain the same concept in several different ways. They could not adapt the explanation depending on who was sitting in front of them.

Part of this may depend on how developed someone’s social and interpersonal abilities are.

But ultimately, it is entirely up to you to decide who deserves your time and energy.

I have never particularly preferred courses. The courses I completed rarely gave me any significant long-term benefit, especially compared with what I gained by learning directly from experienced people. I always tried to spend time around people who had been working directly in the industry for ten years or more and who were dealing with problems significantly more complex than the ones I was working on at the time. I did not spend much time worrying about the complexity of what they were doing.

My focus was always much simpler:

What can I learn from this person that I can understand and apply at my current level?

That was what mattered to me. I also never placed much weight or credibility on people who primarily copied existing solutions, rarely created anything of their own and whose industry experience existed more on paper than in the depth of the work they had actually done.

Experience is not defined by the amount of time that has passed.

It is defined by the quality of the time that was spent.

Someone can say that they have twenty years of experience. They can call themselves a senior engineer or an architect. But if they have spent those twenty years repeating essentially the same type of work, often relying heavily on existing solutions without significantly expanding the scope or complexity of what they do, then the number itself tells you very little. On the other hand, someone may have ten years of experience and spend those ten years constantly entering unfamiliar territory, solving new problems, working with increasingly complex systems, and continuously pushing themselves toward a higher technical level.

Decide for yourself which of those two people would likely be the more suitable mentor.

Keep in mind that real mentorship has to be earned through effort, persistence, and attitude.

You also need to become someone worth investing time in.

A mentor needs to feel that their effort matters and that you are serious enough for them to want to continue training you.

I never waited for five minutes before the end of the workday so I could shut down my machine and leave.

I never found it difficult to work through a weekend or skip going out so that I could sit down and study, especially when someone had already invested their own time in helping me learn.

Those things are noticed. They are valued. And the right people will appreciate them.

When someone gives you their time, experience, patience, and attention, the best way to respect that is to show through your own actions that their effort is not being wasted.

Train Creativity and Intuition

There is another thing that I consider extremely important.

Do not train only memory. Do not train only repetition.

Do not spend your entire development process trying to become better at remembering patterns that can already be repeated mechanically. Train what is, in my opinion, far more valuable:

• creativity;
• intuition;
• the ability to connect things that initially appear unrelated;
• the ability to look at the same problem from several different directions;
• the ability to recognize that something is wrong even before you can fully explain why.

These are some of the areas where human thinking is fundamentally different from mechanical repetition.

A machine can:

• process enormous amounts of information.
• reproduce patterns.
• generate variations of things that already exist.

But your job should not be to compete with a machine in memorization. That is the wrong competition.

The goal should be to develop the parts of your thinking that become stronger through diversity of experience.

That means:

• Doing different things.
• Learning different things.
• Solving different kinds of problems.
• Reading outside of your immediate technical area.
• Building things.
• Breaking things.
• Fixing things.
• Talking to people from completely different professions.
• Learning music.
• Drawing.
• Training.
• Traveling.
• Studying science.
• Working with hardware.
• Writing.
• Designing.
• Observing.
• Thinking.

Not everything you do has to produce an immediate and measurable software-engineering result. That is an extremely important point. We have become too accustomed to asking:

What is the direct benefit of this?

Sometimes there is no immediate visible benefit. That does not mean there was no benefit.

A large amount of personal and intellectual development happens indirectly. Some experiences influence:

• how you think;
• how you organize information;
• how you recognize patterns;
• how patient you are;
• how creative you become;
• how quickly you notice relationships between things;
• how well you remain mentally balanced.

You may not be able to measure those effects immediately. They may become visible years later.

Not Everything Valuable Produces an Instant Result

We should be very careful with the idea that something has value only if it immediately produces an efficient and visible result.

That way of thinking can become extremely limiting.

Imagine that you spend three hours learning something and at the end of those three hours you cannot point to:

• a completed feature
• a new service
• a finished application
• a measurable performance improvement

Does that automatically mean those three hours were wasted? No.

Maybe you in that case:

• developed a new way of thinking about a problem.
• encountered a concept that will become useful six months later.
• improved your patience.
• improved your ability to concentrate.
• created a connection between two completely different areas that will later lead to a solution you would otherwise never see.

Not every useful process has an immediate output. This becomes especially important when developing creativity and intuition.

Those qualities are not built through one isolated exercise. They are built through accumulated experience.

Diversity of Experience Matters

If you do the same thing every day, you may become extremely efficient at that one thing. But efficiency and creativity are not the same thing.

Creativity often comes from connecting things that were previously separate. You see something in one field and realize that the same principle can be applied somewhere completely different:

• You recognize a structure.
• A rhythm.
• A relationship.
• A pattern.

That is why I believe people should expose themselves to more than one narrow area of activity.

You do not need to become an expert in everything. That is not the point.

The point is to give your mind enough different material to work with.

The more different forms of experience you have, the more possible connections your mind can create between them. That is where a large part of creativity comes from.

My Personal Example: Piano

I have played the piano throughout my life. Someone could reasonably ask me:

What benefit does playing the piano give you as a software engineer?

My answer would be: Directly related to programming? Almost none.

Playing the piano has practically almost nothing to do with programming.

I do not become directly better at Go or Rust because I can play the piano. I do not understand distributed systems because I know how to play a piece of music. There is no direct technical relationship, but that does not mean there is no benefit.

Playing the piano can completely change my mental state.

It can clear my head. It can reduce mental pressure after hours of concentrated technical work. It helps me maintain balance. From my own experience, it strongly affects my creativity and intuition.

When you spend a large part of your day solving technical problems, your brain does not always need another technical problem.

Sometimes it needs something completely different. Something that uses attention differently. Something that changes rhythm. Something that allows the mind to move away from the problem without becoming completely inactive. Music does that for me.

And very often, after stepping away from a technical problem for some time, I return to it and see something that I did not see before. The problem did not change. My perspective did.

Intuition Is Built Through Experience

People sometimes talk about intuition as though it were something mystical. I do not see it that way. In engineering, intuition is often accumulated experience that has become so deeply internalized that you recognize patterns before you consciously reconstruct every step of the reasoning. An experienced engineer may look at a system and say:

Something about this design does not feel right.

At that moment, they may not immediately be able to explain exactly why, but after deeper analysis, the reason often becomes visible:

• Maybe they have seen a similar dependency pattern before.
• Maybe they have experienced a similar failure.
• Maybe the system reminds them of an architecture that became impossible to maintain.
• Maybe the interaction between components creates a pattern they have encountered in another context.

That intuition did not appear from nowhere. It was built through:

• different systems;
• different failures;
• different technologies;
• different people;
• different problems;
• different experiences.

The broader the experience, the more material intuition has to work with.

Do Not Reduce Yourself to Repetition

There is little value in spending your entire development process becoming better at repeating something that can already be automated:

• Memorizing every command is not the goal.
• Memorizing every API is not the goal.
• Memorizing every syntax detail is not the goal.

Those things can be looked up. What matters much more is whether you understand:

• what problem you are solving;
• why the problem exists;
• which information matters;
• which information does not matter;
• what is missing;
• what could fail;
• what could be done differently;
• what connection others may not have noticed.

That is where engineering becomes creative work. And that is where human development should be focused.

Give Your Mind More Than One Direction

Do not be afraid to spend time on things that appear unrelated to your primary profession. Not everything needs to:

• become a business.
• become a portfolio project.
• improve your CV.
• produce money.
• produce an immediate result.

Some things exist simply because they make you a more complete person. And a more complete person can become a better engineer.

That relationship is not always direct. But direct relationships are not the only relationships that matter.

A person who has experienced more things has more perspectives from which to observe a problem. A person who has created in several different forms has more ways to approach creation. A person who knows how to move away from work and return mentally refreshed can often work better than someone who spends every available hour forcing the same type of concentration.

Creativity Cannot Be Scheduled Like a Build

You can schedule:

• build
• test
• deploy
• backup
• benchmark

You cannot schedule:

        14:00 — have a genuinely original idea

Creativity does not work like that. Sometimes an idea appears while you are:

• walking;
• playing music;
• exercising;
• reading something unrelated;
• talking to someone;
• doing absolutely nothing technical.

That does not mean the technical work stopped. Very often, part of the problem is still being processed in the background.

This is another reason why I do not believe every useful activity needs to have an immediate measurable output. Some of the most valuable results appear indirectly.

Do Not Compete With Machines at Being Machines

This is particularly important in the age of AI. If machines become increasingly good at:

• memorization;
• pattern reproduction;
• repetitive implementation;
• rapid information retrieval;
• mechanical transformation;

then your response should not be:

I need to become even better at behaving like a machine.

That makes no sense. Develop the things that make your thinking more valuable. Develop:

• judgment;
• creativity;
• intuition;
• adaptability;
• curiosity;
• originality;
• the ability to connect unrelated concepts;
• the ability to work with incomplete information;
• the ability to recognize a problem before it has been formally described.

Use machines for what machines are good at. Do not reduce yourself to the same category of work.

Final Perspective

Do not judge every activity by whether it gives you an immediate technical result:

• Some things improve you indirectly
• Some experiences will make sense only years later
• Some things will never have a measurable professional return and will still be worth doing

Your mind is not only a storage system. Do not train it only to remember.

Train it to:

• create
• connect
• recognize
• imagine
• observe
• analyze
• refactor

Train your intuition. Give yourself enough different experiences for that intuition and creativity to have something to grow from.

Do not spend your life training yourself to become better at the things machines already do well.

Train the parts of your mind that allow you to see what the machine does not.

Developing an Engineering Mindset

Learn to Stay With a Problem

One of the most valuable abilities you can develop as an engineer is the ability to remain with a problem even when the solution is not immediately visible.

Many people are comfortable while progress is obvious. The real difference appears when progress disappears.

You may spend an hour investigating something and still not understand what is happening. You may test five hypotheses and discover that all five were wrong. You may read documentation, inspect logs, change the implementation, go back to the previous version, and still have no final answer. That is normal. Engineering does not reward you immediately.

You need to become comfortable with periods in which you are working seriously but cannot yet see the result. This does not mean repeating the same action for five hours without thinking. Persistence is not stubborn repetition. If an approach does not work, change the approach:

• Ask another question.
• Reduce the problem.
• Create a smaller reproduction.
• Inspect another layer.
• Read the source.
• Measure something.
• Remove assumptions.

The important thing is that you do not mentally collapse simply because the answer has not appeared yet.

A large part of engineering consists of working in a state where:

        I know that something is wrong.
        I do not yet know why.

You need to remain functional inside that state. That is a skill. And like every skill, it can be trained. If every difficult moment immediately results in:

• ask someone
• ask AI
• copy a solution
• abandon the problem

you remove one of the most important mechanisms through which engineering ability develops. Sometimes you need help. There is nothing wrong with that, but before asking for the answer, give yourself enough time to actually encounter the problem.

Form hypotheses. Be wrong. Investigate. Try again. The objective is not to suffer unnecessarily. The objective is to develop the ability to continue thinking when certainty disappears.

Your ability to remain functional while you do not yet understand the problem is one of the most valuable engineering skills you can develop.

Learn to Work With Uncertainty

Real engineering rarely gives you perfect information. In training exercises, the problem may be clearly defined. You may know:

• the exact input;
• the exact expected output;
• the constraints;
• the environment;
• what the system is supposed to do.

Real systems are often different. You may have:

• incomplete logs
• partial documentation
• unclear requirements
• unknown historical decisions
• missing reproduction steps
• multiple possible causes

And you still have to move forward. You cannot always wait until you know everything. Sometimes knowing everything is impossible. A good engineer learns how to reason with incomplete information. That means separating:

• what I know
• what I assume
• what I suspect
• what I can verify
• what I still need to discover

This separation is extremely important. One of the easiest ways to make a bad technical decision is to treat an assumption as a fact. Instead, create hypotheses. For example:

• The database may be slow.
• The network may be dropping requests.
• The application may be blocking.
• The cache may contain stale data.

Then test them. One by one.

A hypothesis is not a conclusion. It is a direction for investigation.

As information increases, your understanding changes. Your responsibility is to adapt with it. Engineering is not always:

        Problem
            ↓
        Known Solution

Very often it is:

        Incomplete Problem
               ↓
        Hypothesis
               ↓
        Experiment
               ↓
        New Information
               ↓
        Better Hypothesis
               ↓
        Solution

Train yourself to work inside that process. Because the more complex the system becomes, the less likely it is that every important fact will be available to you at the beginning.

Think Before You Act

One of the easiest habits to develop in programming is starting implementation too early:

• You receive a task.
• You open the editor.
• You create a package.
• You add a dependency.

You start writing functions. And only later do you discover that the actual problem was not properly understood. Writing code feels productive because something visible is happening. But visible activity is not automatically progress. Before implementation, ask:

• What exactly are we trying to solve?
• Why does this problem exist?
• What do we already know?
• What do we not know?
• What are the constraints?
• What is allowed to change?
• What must remain compatible?
• What happens when this fails?
• What is the simplest valid solution?
• What are we probably going to need later?

Sometimes five minutes of thinking prevents five hours of unnecessary implementation. Sometimes one diagram prevents an entire incorrect architecture. Sometimes asking one question changes the task completely.

This becomes more important as your responsibility grows, when you are:

• modifying one isolated function, a local mistake may be easy to fix.
• defining an API, database model, communication protocol, migration strategy, or service boundary, your decisions may affect many other parts of the system.

Implementation is important, but implementation should follow understanding.

Do not use planning as an excuse never to act. Overanalysis can become another form of avoidance. The objective is not to predict the entire future.

The objective is to understand enough of the problem that your first action has a reason behind it.

Do not start by asking what code you should write. Start by asking what problem the code is supposed to solve.

Remove Ambiguity From Your Technical Vocabulary

During both learning and professional work, remove vague and undefined expressions from your technical vocabulary whenever they are being used as a substitute for analysis. Expressions such as:

• maybe
• probably
• most likely
• it should
• it should probably
• possibly
• I think it will
• it should work

are not technical explanations.

If you do not know something, say that you do not know it. If something has not been verified, say that it has not been verified.

If there are several possible outcomes, identify them. If a conclusion depends on a condition, define the condition.

Instead of saying:

It should probably work.

say:

I have not verified this yet. Based on the current implementation, I expect it to work if conditions A and B are satisfied. I still need to test condition C.

Instead of:

Maybe the database is causing the problem.

say:

The database is one of three current hypotheses. I need to measure query latency and connection saturation before I can confirm or reject it.

Instead of:

This will most likely scale.

say:

We have tested this implementation up to 5,000 concurrent requests. Behavior beyond that point has not yet been measured.

There is nothing wrong with uncertainty.

Engineering is full of uncertainty. The problem is undefined uncertainty.

Do not hide a lack of information behind vague language. Make uncertainty explicit. Define what is known. Define what is unknown. Define what still needs to be tested. Technical communication should reduce ambiguity, not create more of it.

When someone says:

• maybe
• probably
• most likely
• it should

my next question is usually:

Based on what?

If there is no clear answer to that question, then the statement has very little technical value.

Train yourself to speak in terms of:

• known
• unknown
• verified
• unverified
• measured
• assumed
• expected
• required
• observed

The objective is not to sound more confident than you really are.

The objective is to be precise about the level of confidence you actually have.

Uncertainty is acceptable. Ambiguity is not.

Learn to Explain What You Know

Technical understanding and technical communication are closely connected. You may believe that you understand something because it feels familiar. But try to explain it clearly. Explain:

• how it works;
• why it works;
• what problem it solves;
• what assumptions it depends on;
• where it can fail;
• why you chose it over another approach.

Very often, the moment you attempt to explain something, you discover gaps in your own understanding. That is useful. Explanation forces structure. It forces you to turn:

        I kind of understand this.

into:

        I can describe exactly what is happening.

A strong engineer should be able to explain the same system at different levels. To another engineer, you may discuss:

• consistency
• latency
• failure modes
• locking
• replication

To someone less experienced, you may need a simpler explanation. That does not mean making the explanation incorrect. It means understanding the subject well enough to choose the right level of abstraction.

This skill becomes increasingly important as you progress:

• Senior engineers explain decisions.
• Architects explain systems.
• Mentors explain concepts.
• Teams explain failures.
• Documentation explains knowledge to people who may not even be present today.

If knowledge exists only inside your head, its value to the organization is limited.

Practice explaining your work. Write documentation. Describe your architecture. Explain why you rejected an alternative. Teach someone else. A useful test is:

Can I explain this clearly without hiding behind terminology?

If the answer is no, investigate whether you actually understand it as well as you think.

Draw the Model Before You Implement It

Before writing any serious model, draw it.

Before creating structures, interfaces, database entities, relationships, services, communication flows, or larger architectural components, first create a diagram or at least a rough sketch.

It does not need to be beautiful. It does not need to be created with professional diagramming software. A piece of paper is enough.

The important thing is that the idea exists visually before implementation begins. For example:

        Client
           ↓
        Gateway
           |
           +------> Service A
           |
           +------> Service B
                        ↓
                     Database

Or for a data model:

        User
          |
          +---- has many ----> Project
                                  |
                                  +---- contains ----> Task

The purpose of the diagram is not decoration. The purpose is to force you to answer questions before code starts hiding the weaknesses in your idea.

A diagram immediately exposes things such as:

• missing relationships;
• unclear ownership;
• incorrect dependencies;
• circular dependencies;
• missing data flows;
• undefined responsibilities;
• unnecessary components;
• unclear boundaries;
• inconsistent cardinality;
• missing failure paths.

Code can create the illusion of progress. A diagram forces you to look at the whole thing.

Personally, if someone comes to me with a serious model and cannot show me even a basic diagram or sketch, I do not want to hear the implementation yet. For me, that immediately raises several questions:

• Do you actually know what the final structure should look like?
• Have you thought through the relationships?
• Do you understand where the boundaries are?
• Have you analyzed how information moves through the system?
• Can you explain the model clearly to another person?
• Or did you simply start implementing and allow the model to emerge accidentally?

If you cannot draw the idea, there is a good chance that the idea is not yet sufficiently developed. That does not mean the first diagram must be correct. It probably will not be.

That is exactly why you draw it before implementation:

• Change the boxes
• Move the arrows
• Remove components
• Add missing relationships
• Destroy the first version
• Draw another one

Doing that on paper takes minutes. Doing the same thing after thousands of lines of implementation may take days or weeks. The diagram is also one of the simplest tests of whether you can communicate your idea.

If you need twenty minutes of verbal explanation before another engineer can understand where the components are and how they interact, the model may not yet be clear enough. A good diagram gives the conversation a common starting point. You can:

• point to a component.
• question a relationship.
• identify a missing dependency.
• discuss the same system instead of two different mental interpretations of it.

The workflow should therefore be:

        Problem
           ↓
        Analysis
           ↓
        Sketch
           ↓
        Diagram
           ↓
        Review
           ↓
        Model
           ↓
        Implementation

not:

        Problem
           ↓
        Start Coding
           ↓
        Discover the Architecture While Implementing

There are cases where small, trivial changes do not require formal modeling. Use judgment, but as soon as you are designing something with meaningful relationships, responsibilities, states, dependencies, or data flow, draw it first.

If you cannot draw the model, you are probably not ready to implement the model.

Review Your Own Decisions

Experience alone does not automatically create good judgment. You can repeat the same mistake for ten years and call it ten years of experience. What matters is whether you learn from what happened. One of the best ways to improve engineering intuition is to review your own decisions.

When making an important decision, record:

• Problem
• Assumptions
• Available Information
• Decision
• Alternatives
• Expected Result

Then return to it later and add:

• Actual Result
• What Was Correct
• What Was Wrong
• What I Would Change
• What I Learned

This can be extremely valuable. Imagine that you selected a specific database architecture because you expected a certain traffic pattern. Six months later, the traffic pattern is different and the design causes problems. You can simply fix it and move on.

Or you can ask:

Why did I believe this was the right choice six months ago?

Use cases can be:

• your reasoning was good and reality changed.
• the data was incomplete.
• you ignored an important signal.
• you overestimated one risk and underestimated another.

Those distinctions matter. The objective is not to judge your past self unfairly. You made the decision with the information you had at the time.

The objective is to improve the process through which future decisions are made. This is one of the ways intuition becomes stronger. Intuition is not only created by experiencing many situations. It is strengthened by reflecting on those situations afterward.

If you never review your reasoning, you may remember the result but forget why you arrived there.

Experience gives you events. Reflection turns those events into judgment.

Separate Your Ego From Your Solution

Your code is not you. Your architecture is not you. Your idea is not you.

This sounds simple, but it is extremely important. You will make bad decisions. Everyone does. Someone less experienced than you may occasionally have a better idea. Someone may find a serious problem in something you designed. A code review may completely reject your approach. That should not become a personal conflict. If your objective is to create the best possible system, then discovering that your current solution is wrong is useful information.

The problem begins when the objective changes from:

        Find the best solution.

to:

        Prove that my solution was correct.

At that point, engineering becomes ego defense. You start ignoring evidence. You interpret criticism of the implementation as criticism of yourself. You defend complexity because you created it. You resist removing code because you spent three weeks writing it. That is dangerous.

A strong engineer should be able to say: "I was wrong" and continue working normally. That sentence does not reduce your value. Very often, the opposite is true. The ability to change your opinion when better evidence appears is a sign of technical maturity. You should defend ideas with reasoning, but once the reasoning no longer holds, let the idea go.

The objective is not to win an argument. The objective is to improve the system.

Do Not Confuse Speed With Progress

Software engineering has an unhealthy relationship with visible activity:

• More commits.
• More lines of code.
• More tickets closed.
• More generated output.
• More features.
• More speed.

Those numbers can mean something, but they can also mean almost nothing.

Imagine two engineers. The first engineer writes 5,000 lines of code in two days. The second spends one day analyzing the problem and writes 300 lines on the second day.

Who made more progress?

You cannot answer that from the numbers. The 5,000 lines can create unnecessary complexity. The 300 lines can solve the problem completely. You have to inspect the result. This becomes especially important with AI. If a model generates:

        10,000 lines in ten minutes

that is an impressive generation rate. It does not automatically mean:

        10,000 lines of engineering value

Generated output still needs to fit the system:

• It needs to be correct
• Maintainable
• Secure
• Testable
• Compatible
• Useful

Speed is valuable when you are moving in the right direction. Moving quickly in the wrong direction only increases the distance you later need to travel back. Do not measure your development only through visible volume. Sometimes:

• deleting 2,000 lines is progress.
• spending a day without writing code is progress.
• discovering that a feature should not exist is progress.

Remember:

activity ≠ progress
output ≠ value
speed ≠ quality

Train Observation

A large part of engineering begins with noticing something:

• strange line in a log.
• small latency increase.
• function that has a name that does not match what it actually does.
• dependency that seems to point in the wrong direction.
• recurring failure every few hours.
• memory pattern that looks slightly unusual.
• database query that should not be executed that often.

None of those things may initially look like a major problem, but someone has to notice them. Good engineers develop observation. They do not only wait for SYSTEM FAILED before becoming interested. They notice smaller signals. Observation leads to questions:

• Why is this happening?
• Has it always behaved this way?
• Why does this service depend on that service?
• Why is this request slower only sometimes?
• Why does memory usage increase but never return?

Questions lead to investigation. Investigation produces understanding.

This is also strongly connected with intuition. You cannot build intuition about systems if you do not pay attention to how systems behave.

Train yourself to observe:

• Read logs even when nothing is broken
• Look at metrics
• Inspect generated files
• Watch network traffic
• Read code you did not write

Compare expected behavior with actual behavior. Pay attention to things that seem slightly inconsistent. You do not need to investigate every unusual detail forever, but you should develop the habit of noticing them. Sometimes the first sign of a serious problem is simply:

Something here does not look right.

Create More Than You Consume

There is an enormous amount of technical content available today:

• courses
• videos
• books
• articles
• documentation
• tutorials
• AI explanations

All of them can be useful, but there is a danger in consuming technical information continuously without creating anything yourself.

Watching someone build a system creates familiarity.

Building the system yourself exposes understanding.

Those are not the same thing. You may watch a two-hour tutorial and understand every step. Then close the tutorial. Open an empty directory. And discover that you do not know where to begin. That is valuable information. Creation exposes the gaps that passive consumption can hide.

Instead of only reading about:

• networking
• databases
• concurrency
• Git
• Linux
• APIs

build something with them:

• Write a small server
• Create a protocol
• Break it
• Measure it
• Document it
• Delete it
• Build another version

If you are learning an algorithm, do not only read the solution.

Implement it. Change the constraints. Create new form.

Create another problem that requires the same idea. If you are learning architecture, design a system yourself before reading someone else’s architecture. Then compare.

Technical education should not become endless consumption. At some point, close the material and create something from nothing. That is where understanding becomes visible.

Consumption creates familiarity. Creation exposes understanding.

The purpose of learning is not to collect information.

The purpose is to become capable of doing something with it.

Learn to Finish

During the learning process, a crucial factor for progress is gradation:

• Starting something is easy.
• Finishing it is a different skill.
• The beginning of a project is exciting.
• You choose technologies.
• You create architecture.
• You write the first clean implementation.

Everything is new. Then comes the part that is usually less exciting:

• edge cases
• tests
• error handling
• migration
• documentation
• cleanup
• deployment
• monitoring
• performance problems
• compatibility
• bug fixing
• maintenance

This is where many projects become difficult and this is where a large part of engineering actually happens:

• feature is not finished because the primary happy path works.
• service is not finished because it starts successfully on your machine.
• system is not finished because the architecture diagram looks good.

You have to ask:

• Can it fail safely?
• Can we deploy it?
• Can we upgrade it?
• Can we monitor it?
• Can someone else understand it?
• Can we recover it?
• Can we maintain it six months later?

People who constantly move from one new idea to another can accumulate enormous amounts of beginnings and very little completed work. That creates familiarity with starting. It does not create experience with the complete lifecycle.

Finishing teaches you things that starting never will. It:

• exposes assumptions
• reveals edge cases
• forces compromises
• introduces maintenance
• teaches responsibility

Starting teaches enthusiasm. Finishing teaches engineering.

Learn to finish what deserves to be finished.

An Idea Without Execution Is Just Another Illusion

Ideas are easy to produce. Execution is what gives them value.

You can imagine:

• a new product;
• a better architecture;
• a new service;
• a business;
• a platform;
• a library;
• a completely different way of solving a problem.

But until you execute the idea, it exists only in your head. It has not:

• been tested
• met reality

nor been forced to deal with:

• constraints
• time
• cost
• failure
• complexity
• people
• maintenance
• unexpected behavior

That is why I do not place much value on an idea by itself. An idea can sound brilliant while it remains theoretical. Execution is the point where the idea is forced to prove itself. Reality starts asking questions:

• Does it actually work?
• Can it be built?
• Can it be maintained?
• Can someone else understand it?
• Does it solve the problem you thought it solved?
• Is the complexity justified?
• What happens when the assumptions are wrong?

Until those questions are answered, you do not really know what you have. You have a possibility. Not a result.

There is also a psychological trap here:

• Thinking about an idea can create a feeling of progress.
• Talking about it can create a feeling of progress.
• Drawing the architecture can create a feeling of progress.
• Explaining what you are going to build can create a feeling of progress.

But none of those things are the execution itself. At some point, you have to build. You have to test, fail, correct, finish. That is where the idea becomes real.

This is also why unfinished projects are not only unfinished products. They are unfinished lessons. If you:

• stop before deployment, you do not learn deployment.
• if you stop before real usage, you do not learn what users actually do.
• if you stop before maintenance, you do not learn what your decisions cost over time.
• if you stop before failure, you do not learn whether your recovery strategy was real or theoretical.

Execution closes the loop between imagination and reality. Without that loop, you can spend years believing that your ideas are better than they actually are, simply because they were never tested hard enough to prove otherwise.

An idea without execution is just another illusion.

The value is not in having the idea. The value is in turning the idea into something that survives contact with reality.

Setup Your Environment

Before we start writing code, we need to prepare the environment in which you are going to work.

You do not need an expensive workstation. You do not need the latest processor. You do not need a powerful graphics card.

And you definitely do not need to spend several thousand dollars before you can start learning software engineering.

What you need is a machine that is fast enough not to become an obstacle.

The purpose of your development machine is simple:

It should allow you to focus on learning and engineering instead of constantly fighting your hardware.

Hardware

For the beginning, almost any reasonably modern desktop or laptop computer will be sufficient.

Our general recommendation is:

CPU:     6–8 modern CPU cores
RAM:     16 GB minimum
         32 GB recommended
Storage: SSD strongly recommended
GPU:     no dedicated GPU required

You can absolutely begin with less.

But there is a difference between:

Can this machine run the software?

and:

Is this machine comfortable to work on every day?

Those are not the same question.

CPU

A modern processor with approximately six or eight physical cores is more than enough for the majority of tasks you will encounter at the beginning.

You will use the CPU for things such as:

• compiling software;
• running tests;
• running multiple services;
• compression;
• local databases;
• containers;
• development tools;
• virtual machines;
• benchmarks.

You do not need a high-end workstation CPU.

A reasonable modern desktop or laptop processor is enough.

As your work becomes more complex, stronger hardware can reduce build times and make larger local environments more comfortable.

But hardware should not become an excuse for postponing learning.

Start with what you have if it is reasonably functional.

Upgrade when you actually understand what limitation you are trying to remove.

Memory

We consider:

16 GB RAM

a practical minimum for a comfortable modern development environment.

If possible, use:

32 GB RAM

With 32 GB you have significantly more space for running:

• your IDE or editor;
• browser sessions;
• multiple terminals;
• databases;
• several services;
• containers;
• build processes;
• documentation;
• debugging tools

at the same time.

You do not need 64 GB or 128 GB of memory to learn software engineering.

There are workloads where those amounts become useful.

You are not starting there.

Storage

Use an SSD. Preferably, use an NVMe SSD if your machine supports one.

Development environments perform a huge number of small filesystem operations.

Compilers read and write files.

Git works with thousands of files.

Package managers create caches.

Databases write data.

Build systems constantly create and remove artifacts.

The difference between an old mechanical hard drive and an SSD is very noticeable in development work.

For a dedicated learning machine, something around [512 GB] is enough to start comfortably.

Graphics Card

For the work we are going to do initially, you do not need a dedicated graphics card.

Integrated graphics are completely sufficient.

A powerful GPU becomes relevant if you later move into areas such as:

• graphics programming;
• game development;
• GPU computing;
• CUDA;
• local machine-learning workloads;
• 3D rendering;
• computer vision workloads.

Do not buy hardware for problems you do not currently have.

Operating System

For this Task Library, we recommend using Linux from the beginning.

More specifically, our recommendation for a first Linux development environment is:

Linux Mint — Cinnamon Edition

Use the latest stable release available when you prepare your machine.

Linux will eventually become necessary or extremely useful if you move deeper into areas such as:

• backend engineering;
• distributed systems;
• networking;
• DevOps;
• SysOps;
• cloud infrastructure;
• containers;
• databases;
• security;
• operating systems;
• automation;
• CI/CD.

A very large part of modern server infrastructure runs on Linux.

You are going to encounter it sooner or later. Our recommendation is simple:

Encounter it sooner.

Do not wait until you are already expected to know it professionally.

Why Linux Mint?

Linux has many distributions. You will eventually hear discussions about:

• Debian;
• Ubuntu;
• Fedora;
• Arch Linux;
• openSUSE;
• Linux Mint;
• and many others.

Do not waste your energy on distribution wars at the beginning. The operating system is here to provide you with a development environment. You are not choosing a religion.

For beginners, we recommend Linux Mint because it provides a very good balance between:

• stability;
• simplicity;
• hardware support;
• desktop usability;
• package availability;
• documentation;
• compatibility with the wider Ubuntu ecosystem.

The Cinnamon desktop is also familiar enough that people coming from Windows usually adapt to it quickly.

That matters. At this stage, we want you learning Linux and software engineering.

We do not want you spending three days configuring a desktop because someone on the Internet told you that a more complicated distribution makes you a better engineer.

It does not.

Dedicated Linux Installation or Dual Boot?

If you have a machine dedicated to learning and development, our preferred setup is simple:

        Machine
            ↓
        Linux Mint

Nothing else.

This gives you the cleanest environment and removes unnecessary complexity.

If the machine is also your personal computer and you still need Windows for other software, gaming, or other obligations, dual boot is completely acceptable.

That setup may look like:

        Computer
            │
            ├── Windows
            │
            └── Linux Mint

When the computer starts, you select which operating system you want to use.

If you decide to dual boot, install Windows first and Linux Mint afterward.

Linux Mint can detect the existing Windows installation and configure the boot menu accordingly.

Before Installing Linux

Before changing operating systems or disk partitions:

Back up everything important.

Do not continue until important files exist somewhere other than the machine you are about to modify.

That may be:

• another computer;
• an external SSD;
• an external hard drive;
• network storage;
• cloud storage.

Partitioning mistakes can destroy data.

Choosing the wrong drive during installation can destroy data.

Formatting the wrong partition can destroy data.

The installation process itself is not particularly difficult.

But storage operations deserve attention.

Installing Linux Mint

The general installation process is straightforward.

You will need:

• your computer;
• a USB flash drive;
• the Linux Mint ISO image;
• a tool for creating a bootable USB drive.

1. Download Linux Mint

Download the latest stable Linux Mint Cinnamon Edition from the official Linux Mint website.

Avoid random download websites.

Operating-system installation images should come from the official source.

Where possible, verify the downloaded image using the checksums provided by the Linux Mint project.

2. Create a Bootable USB Drive

Write the Linux Mint ISO image to a USB flash drive.

If you are creating the installation USB from Windows, macOS, or another Linux distribution, tools such as Etcher can be used.

The process is essentially:

Linux Mint ISO
        ↓
USB imaging tool
        ↓
USB flash drive

Be careful when selecting the destination device.

The USB drive will be overwritten.

3. Boot From the USB Drive

Insert the USB drive and restart the machine.

Open your computer’s boot-device menu.

Depending on the manufacturer, the key may be something such as:

F2
F8
F10
F11
F12
Esc
Delete

Select the USB drive.

Linux Mint will start in a live environment.

4. Test the Live Environment

Before installing anything, spend several minutes inside the live Linux Mint environment.

Check that important hardware works:

• keyboard;
• mouse;
• display;
• Wi-Fi;
• Ethernet;
• audio;
• touchpad;
• external monitors if you use them.

This gives you an opportunity to detect obvious hardware problems before modifying the disk.

5. Start the Installation

Start the Linux Mint installer from the desktop.

You will be asked to configure things such as:

• language;
• keyboard layout;
• timezone;
• user account;
• installation disk.

If this is a dedicated Linux machine and you have already backed up everything important, the simplest installation option is usually to allow Linux Mint to use the entire disk.

If you are configuring dual boot, pay much more attention to disk and partition selection.

Do not confirm disk changes until you understand which disk and partitions are being modified.

6. Create Your User

During installation, create your normal user account.

Choose:

• a simple username;
• a sensible hostname;
• a strong password.

For example:

username: developer
hostname: dev-machine

Avoid unnecessarily complicated hostnames and usernames.

You will type and see them frequently.

7. Complete the Installation

When installation is complete:

1. restart the computer;
2. remove the installation USB when requested;
3. boot into the installed Linux Mint system.

You now have your development operating system.

First System Update

One of the first things you should do after installation is update the system.

Open the terminal and run:

sudo apt update
sudo apt upgrade -y

The first command updates information about available packages.

The second installs available updates.

You will see sudo constantly in Linux.

Do not worry if you do not understand all of this yet.

We are going to cover the terminal separately.

Basic Development Packages

You can also install several tools that will be useful almost immediately:

sudo apt install -y \
    build-essential \
    git \
    curl \
    wget \
    ca-certificates \
    zip \
    unzip

This gives you several fundamental development and system tools.

We will configure Git properly in the dedicated Git section.

Do Not Be Afraid of the Terminal

If you are coming from Windows and have mostly used graphical applications, the Linux terminal may initially feel uncomfortable.

That is normal.

Do not avoid it.

The terminal will become one of your primary tools.

Eventually, operations such as:

cd
ls
mkdir
cp
mv
rm
grep
find
ps
kill
ssh
git

should feel completely normal.

You do not need to memorize everything immediately.

You need to use it.

Repeated use creates familiarity.

Do Not Try to Customize Everything Immediately

Another common beginner mistake is spending enormous amounts of time customizing the environment before doing any actual work.

You do not need:

• twenty shell plugins;
• a heavily customized terminal;
• hundreds of aliases;
• a custom window manager;
• ten development environments;
• a complicated dotfiles repository.

You need a working machine.

Start simple.

Your environment should evolve because you discover a real need.

Not because somebody else’s desktop screenshot looked impressive.

Your Initial Environment

At the end of this setup, your basic environment should look approximately like this:

        Development Machine
                │
                ├── Linux Mint
                │
                ├── Terminal
                │
                ├── Git
                │
                ├── Code Editor / IDE
                │
                ├── Browser
                │
                └── Development Toolchains

That is enough. Everything else can be added when it becomes necessary.

What Comes Next

Once Linux is installed, the next two things you need to understand are:

1. The Linux Terminal
2. Git

The terminal is how you will interact directly with a large part of your development environment.

Git is how you will manage source code, track changes, work with repositories, and eventually collaborate with other developers.

Neither of these is optional knowledge for the direction we are taking.

We will cover both separately. Do not rush through them. They will become part of your everyday work.

Fundamental Linux Terminal

The Linux terminal is one of the most important parts of a Linux development environment.

Almost everything that can be done through a graphical interface can also be performed from the terminal. In many engineering workflows, the terminal is faster, easier to automate, easier to reproduce, and more practical for remote systems.

From the terminal, you can:

• install software and development tools;
• create, copy, move, rename, and delete files and directories;
• inspect files and directory trees;
• modify permissions and ownership;
• create users and groups;
• archive and compress data;
• redirect and combine command output;
• execute scripts;
• transfer files;
• configure environment variables;
• schedule work;
• inspect system state;
• manage packages;
• work with remote machines.

The goal of this chapter is not to memorize every Linux command.

The goal is to become comfortable enough with the terminal that it stops feeling like a special tool and becomes a normal part of everyday engineering work.

Important: Many Linux commands can modify or permanently delete data. Read commands carefully before executing them, especially when using sudo, rm -rf, recursive permission changes, disk tools, or administrative commands.

Opening the Terminal

On Linux Mint and many other Linux desktop environments, a common shortcut is:

Ctrl + Alt + T

You can also open the terminal from the application menu or define your own shortcut in system settings.

A shell prompt may look similar to:

developer@machine:~$

The exact username, hostname, colors, and symbols depend on your environment.

Navigation and Directory Inspection

ls - List Directory Contents

The ls command lists files and directories in the current working directory.

ls

A more detailed listing can be shown with:

ls -la

Common options include:

Use:

ls --help

or:

man ls

to explore the full option list.

Understanding ls -l

Example:

drwxr-xr-x  3 developer developers 4096 Sep 17 12:10 project
-rw-r--r--  1 developer developers 3890 Sep 17 11:50 .bashrc

The first character describes the object type:

d    directory
-    regular file
l    symbolic link

The next nine characters describe permissions:

rwxr-xr-x

They are divided into three groups:

rwx  r-x  r-x
│    │    │
│    │    └── others
│    └────── group
└─────────── user / owner

Permission symbols are:

r    read
w    write
x    execute
-    permission not granted

The remaining columns normally show information such as:

• number of hard links;
• owner;
• group;
• size;
• modification time;
• file or directory name.

pwd - Print Working Directory

To see your current location:

pwd

Example:

/home/developer/projects

cd - Change Directory

Move into a directory:

cd projects

Move to an absolute path:

cd /home/developer/projects

Move one level upward:

cd ..

Move two levels upward:

cd ../..

Go to your home directory:

cd ~

or simply:

cd

Absolute and Relative Paths

An absolute path starts from the filesystem root:

/home/developer/projects/demo

A relative path starts from your current working directory:

projects/demo

Example:

cd /home/developer/projects/demo

and:

cd projects/demo

can point to the same location depending on your current directory.

Understanding the difference between absolute and relative paths is fundamental because almost every Linux command accepts paths.

Creating and Removing Directories

mkdir - Create Directories

Create one directory:

mkdir project

Create multiple directories:

mkdir project-a project-b project-c

Brace expansion can also be used:

mkdir {project-a,project-b,project-c}

Creating Parent Directories With mkdir -p

If intermediate directories do not yet exist:

mkdir -p projects/backend/api

Linux creates the missing parent directories as needed.

This works with both relative and absolute paths.

Creating a Directory With Permissions

mkdir -m can assign a mode when creating a directory:

mkdir -m 750 private-project

We will explain numeric permission modes in the next section.

rmdir - Remove Empty Directories

Remove an empty directory:

rmdir project

Remove multiple empty directories:

rmdir project-a project-b

rmdir does not remove non-empty directories.

rm - Remove Files and Directory Trees

Remove a file:

rm file.txt

Remove a directory recursively:

rm -r project

Useful options include:

Be Extremely Careful With rm -rf

This command:

rm -rf some-directory

can permanently remove an entire directory tree without confirmation.

Always verify the path first.

For learning, prefer:

rm -ri some-directory

when you want interactive confirmation.

Never copy and execute an rm -rf command without understanding exactly what it targets.

Permission Modes

Linux permissions can be represented symbolically:

rwxr-xr--

or numerically.

Values are:

r = 4
w = 2
x = 1

Examples:

rwx = 4 + 2 + 1 = 7
r-x = 4 + 0 + 1 = 5
rw- = 4 + 2 + 0 = 6
r-- = 4 + 0 + 0 = 4
--- = 0 + 0 + 0 = 0

Three numbers represent:

user  group  others

Examples:

777 = rwxrwxrwx
750 = rwxr-x---
644 = rw-r--r--
600 = rw-------

Do not automatically use 777.

Permissions should be only as broad as necessary.

Terminal Keyboard Shortcuts

Useful shell shortcuts include:

These shortcuts become extremely useful once the terminal becomes part of your daily workflow.

Working With Files

touch - Create Files

Create an empty file:

touch example.txt

Create multiple files:

touch file1.txt file2.txt file3.txt

You can use either relative or absolute paths:

touch /home/developer/example.txt

mv - Move and Rename

General form:

mv SOURCE DESTINATION

Move a file:

mv example.txt archive/

Move multiple files:

mv file1.txt file2.txt archive/

Rename a file:

mv old-name.txt new-name.txt

Useful options include:

For learning and important files, -i can be useful:

mv -iv source destination

cp - Copy Files and Directories

General form:

cp [OPTIONS] SOURCE DESTINATION

Copy a file:

cp file.txt backup/

Copy several files:

cp file1.txt file2.txt backup/

Copy a directory recursively:

cp -R project/ backup/

Useful options include:

Changing Permissions and Ownership

chmod - Change Permissions

Set numeric permissions:

chmod 750 script.sh

Add execute permission for the current user:

chmod u+x script.sh

Apply permissions recursively:

chmod -R 750 project/

Warning: Recursive permission changes can affect every file and directory below a path. Also remember that directories need execute (x) permission to be entered/traversed.

chown - Change Ownership

General form:

chown USER:GROUP FILE

Example:

sudo chown developer:developers file.txt

Recursive ownership change:

sudo chown -R developer:developers project/

Ownership changes usually require administrative privileges when changing objects to another user.

Editing Text With Nano

nano - Terminal Text Editor

Open a file:

nano file.txt

Use sudo nano only when the file genuinely requires administrative privileges:

sudo nano /etc/hosts

Useful Nano shortcuts:

Standard Output and Redirection

Linux commands normally write output to streams.

The two most important are:

stdout    standard output
stderr    standard error

echo

Print text:

echo "Hello Linux World!"

Redirect output into a file:

echo "Hello Linux World!" > message.txt

Append to an existing file:

echo "Second line" >> message.txt

> - Overwrite Redirection

command > file.txt

The destination file is replaced with the new output.

Example:

echo "new content" > example.txt

>> - Append Redirection

command >> file.txt

New output is added to the end of the file.

Example:

echo "another line" >> example.txt

Redirecting Errors

Redirect standard error:

command 2> errors.txt

Append standard error:

command 2>> errors.txt

Redirect stdout and stderr into the same file:

command > output.txt 2>&1

Bash also supports:

command &> output.txt

Append both streams:

command &>> output.txt

Text Inspection Commands

cat

Print file content:

cat file.txt

Combine several files:

cat file1.txt file2.txt

Redirect combined output:

cat file1.txt file2.txt > combined.txt

wc

Count lines:

wc -l file.txt

You will also commonly see:

cat file.txt | wc -l

but the direct form is simpler when only one file is involved.

head

Show the first ten lines:

head file.txt

Show a specific number of lines:

head -n 5 file.txt

tail

Show the last ten lines:

tail file.txt

Show the last two lines:

tail -n 2 file.txt

Follow a growing log file:

tail -f application.log

diff

Compare two files:

diff file-a.txt file-b.txt

This is useful for quickly inspecting textual differences.

split

Split a file after a number of lines per output file:

split -l 100 large-file.txt

The original file remains unchanged.

Pipes

The pipe operator:

|

sends the output of one command into the input of another.

Example:

ls -la | grep ".txt"

Conceptually:

command A
    ↓ stdout
command B

Pipes are one of the most important ideas in Unix-like environments.

Small commands can be combined into larger workflows.

Shell Scripts

A shell script is a text file containing shell commands.

Create one:

nano script.sh

Example content:

#!/usr/bin/env bash

ls -la
pwd

Make it executable:

chmod u+x script.sh

Run it:

./script.sh

You can also explicitly invoke Bash:

bash script.sh

The .sh extension is conventional but not what makes a file executable. Permissions and the interpreter determine execution.

Archiving and Compression

tar

Create a tar archive:

tar -cvf archive.tar project/ file1.txt file2.txt

List archive contents:

tar -tf archive.tar

Extract:

tar -xvf archive.tar

tar.gz

Create a gzip-compressed tar archive:

tar -cvzf archive.tar.gz project/

Extract:

tar -xzvf archive.tar.gz

For less verbose output, omit v:

tar -czf archive.tar.gz project/
tar -xzf archive.tar.gz

gzip

Compress a file:

gzip archive.tar

Decompress:

gzip -d archive.tar.gz

Show gzip information:

gzip -l archive.tar.gz

Users and Groups

Inspect the Current User

whoami

Detailed identity information:

id

Show group membership:

groups

Create a User

On Linux Mint and other Debian/Ubuntu-based systems:

sudo adduser student

Add the user to the sudo group when administrative access is intentionally required:

sudo usermod -aG sudo student

Change a Password

sudo passwd student

Delete a User

Keep the user’s home directory:

sudo deluser student

Remove the user’s home directory too:

sudo deluser --remove-home student

Administrative user management can destroy user data. Verify the username before executing removal commands.

Create and Manage Groups

Create a group:

sudo groupadd developers

Append a user to a supplementary group:

sudo usermod -aG developers student

Inspect the group:

getent group developers

Change a user’s primary group:

sudo usermod -g developers student

Important User and Group Files

Linux user and group information is represented through system files including:

/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow

Do not modify these files manually unless you understand the consequences.

For learning, inspect them read-only:

cat /etc/passwd
getent passwd
getent group

/etc/shadow contains protected password-related information and normally requires administrative access.

Soft and Hard Links

Symbolic / Soft Link

Create a symbolic link:

ln -s source.file softlink.file

A symbolic link stores a path to another object.

If the target disappears, the symbolic link becomes broken.

Symbolic links:

• can cross filesystem boundaries;
• can point to directories;
• have their own inode;
• refer to a path.

Hard Link

Create a hard link:

ln source.file hardlink.file

A hard link refers to the same underlying inode/data as the original directory entry.

Both names reference the same file data.

If one name is removed, the data remains accessible through the other name as long as another hard link still exists.

Hard links normally:

• remain within the same filesystem;
• cannot normally be created for directories by ordinary users;
• share the same inode;
• reflect content and permission changes because they refer to the same underlying file.

Inspect inode numbers with:

ls -li

Downloading Files With wget

wget is a non-interactive command-line download utility.

Example:

wget https://example.com/file.tar.gz

It supports common protocols such as HTTP and HTTPS and is useful in scripts and remote sessions.

Running Multiple Commands

;

Commands separated with ; are executed sequentially regardless of whether the previous command succeeded:

mkdir demo; cd demo; touch file.txt

&&

The next command runs only if the previous command succeeds:

mkdir demo && cd demo && touch file.txt

This is usually safer when later steps depend on earlier steps.

Multi-Line Commands

Use a backslash at the end of a shell line to continue:

mkdir project \
    && cd project \
    && touch README.md

Aliases

Aliases create short names for commands.

Temporary alias:

alias ll="ls -la"

List aliases:

alias

Remove one:

unalias ll

Permanent Bash Aliases

For Bash, add aliases to:

~/.bashrc

Example:

echo 'alias ll="ls -la"' >> ~/.bashrc

Reload:

source ~/.bashrc

Avoid aliases that make destructive commands easier to execute accidentally.

For example, an alias wrapping rm -rf is a poor default for a learning environment.

The $PATH Environment Variable

When you type:

git

or:

go

the shell needs to find the executable.

The $PATH variable contains directories that the shell searches.

Inspect it:

echo "$PATH"

Find the executable resolved for a command:

which git

A modern shell also provides:

command -v git

Common executable locations include:

/usr/bin
/usr/local/bin
/usr/sbin
/usr/local/sbin

Extending $PATH

Example:

export PATH="$PATH:$HOME/bin"

To persist it for Bash:

echo 'export PATH="$PATH:$HOME/bin"' >> ~/.bashrc
source ~/.bashrc

Always quote $PATH expansions in shell configuration when practical.

Package Management With APT

Linux Mint uses the Debian/Ubuntu package-management ecosystem.

Refresh package information:

sudo apt update

Upgrade installed packages:

sudo apt upgrade

Install a package:

sudo apt install git

Search:

apt search package-name

Remove:

sudo apt remove package-name

apt-get remains available and is widely used in scripts:

sudo apt-get update
sudo apt-get install git

For interactive use, apt is usually more convenient.

sudo

sudo allows an authorized user to execute commands with elevated privileges.

Example:

sudo apt update

Administrative privileges should be used only when necessary.

Do not place sudo in front of commands automatically.

Ask:

Does this operation really need root privileges?

About /etc/sudoers

The original Team413 terminal guide demonstrates passwordless sudo through a NOPASSWD sudoers entry.

For a normal learning workstation, this edition does not recommend disabling sudo password prompts globally.

If you ever need to modify sudo policy, use:

sudo visudo

rather than editing /etc/sudoers directly with a general-purpose editor.

visudo validates the configuration before saving and reduces the chance of breaking administrative access.

Use the Built-In Documentation

Linux commands usually document themselves.

Try:

command --help

or:

man command

Examples:

ls --help
man chmod
man tar
man usermod

Learning how to read command documentation is more valuable than trying to memorize every option.

Fundamental Command Checklist

You should become comfortable with at least these commands and concepts:

ls
pwd
cd
mkdir
rmdir
rm
touch
mv
cp
chmod
chown
nano
cat
echo
wc
head
tail
diff
split
tar
gzip
ln
wget
id
whoami
groups
adduser
usermod
groupadd
apt
sudo
man
--help
PATH
stdout
stderr
>
>>
2>
|
&&
;

You do not need to memorize them in one day.

Use them repeatedly.

The terminal becomes natural through repetition.

Final Perspective

The Linux terminal is not a list of commands.

It is an environment for combining small tools.

The real power appears when you understand:

files
+
paths
+
permissions
+
streams
+
processes
+
shell syntax
+
small commands

and begin combining them.

At that point, the terminal stops being something you “learn for Linux”.

It becomes one of the primary interfaces through which you understand and operate a computer.

Advanced Linux Terminal

Once basic terminal navigation, files, permissions, streams, users, packages, and shell execution are familiar, the next step is learning how to search, transform, automate, inspect, and control a Linux system from the command line.

This chapter focuses on:

• grep and regular expressions;
• sed;
• awk;
• password aging with chage;
• find, locate, which, man, and --help;
• process and network inspection;
• scheduling with cron and at;
• firewall configuration with UFW.

These tools are fundamental for backend engineering, DevOps, SysOps, infrastructure, server administration, debugging, and automation.

Important: Advanced terminal commands frequently operate over large file trees, user accounts, running processes, scheduled jobs, and network access. Test commands in a controlled environment before using them on production systems.

Searching Text With grep

grep searches text for lines that match a pattern.

Basic example:

grep "hello" test.txt

The same idea can be expressed through a pipe:

cat test.txt | grep "hello"

When reading a file directly, the first form is simpler:

grep "hello" test.txt

Useful grep Patterns

Count matching lines:

grep -c "hello" test.txt

Lines beginning with hello:

grep '^hello' test.txt

Lines ending with hello:

grep 'hello$' test.txt

Case-insensitive search:

grep -i 'linuxacademy' test.txt

Invert the match:

grep -v '^#' test.txt

Match either lowercase or uppercase first character:

grep '[lL]inuxacademy' test.txt

Extended regular expressions:

grep -E 'hello.*world' test.txt

Case-insensitive extended expression:

grep -Ei 'hello.*world' test.txt

Logical OR:

grep -Ei 'hello|world' test.txt

Historically, egrep was commonly used for extended regular expressions. Modern usage generally prefers:

grep -E

instead of:

egrep

Regular Expressions Overview

Regular expressions describe text patterns.

Common symbols include:

Example:

grep -E '^(error|warning):' application.log

Regular expressions are used by many Linux tools, not only grep.

sed - Stream Editor

sed is a stream editor used for operations such as:

• searching;
• substitution;
• insertion;
• deletion;
• filtering.

General syntax:

sed [OPTIONS] 'SCRIPT' INPUT_FILE

Replace the First Match on Each Line

sed 's/unix/linux/' file.txt

This prints transformed output.

It does not modify the file unless an in-place option is used.

Replace the Second Match

sed 's/unix/linux/2' file.txt

Replace All Matches on Each Line

sed 's/unix/linux/g' file.txt

Replace From the Third Match Onward

sed 's/unix/linux/3g' file.txt

Replace on a Specific Line

sed '3s/unix/linux/' file.txt

Replace Within a Line Range

sed '1,3s/unix/linux/' file.txt

From line 2 to the end:

sed '2,$s/unix/linux/' file.txt

Print Only Matching/Replaced Lines

sed -n 's/unix/linux/p' file.txt

Delete Lines

Delete line 3:

sed '3d' file.txt

Delete the last line:

sed '$d' file.txt

Delete a range:

sed '2,3d' file.txt

Delete from line 3 to the end:

sed '3,$d' file.txt

Delete lines containing a pattern:

sed '/unix/d' file.txt

In-Place Editing

When you intentionally want to modify the file:

sed -i 's/unix/linux/g' file.txt

For important data, create a backup first:

cp file.txt file.txt.backup
sed -i 's/unix/linux/g' file.txt

Or use GNU sed backup suffix syntax:

sed -i.bak 's/unix/linux/g' file.txt

awk - Pattern Scanning and Data Processing

awk is a small programming language designed for text and structured field processing.

It can:

• scan input line by line;
• split lines into fields;
• match patterns;
• perform actions;
• calculate values;
• generate reports;
• use variables;
• use conditions and loops.

General form:

awk 'PATTERN { ACTION }' FILE

Print Every Line

awk '{print}' employee.txt

Print Lines Matching a Pattern

awk '/manager/ {print}' employee.txt

Fields

By default, whitespace separates fields.

For a line like:

ajay manager account 45000

the fields are:

$1 = ajay
$2 = manager
$3 = account
$4 = 45000
$0 = entire line

Print name and salary:

awk '{print $1, $4}' employee.txt

Important awk Built-In Variables

NR

Current record/line number:

awk '{print NR, $0}' employee.txt

NF

Number of fields in the current record.

Print the first and last fields:

awk '{print $1, $NF}' employee.txt

FS

Input field separator.

Example CSV-like separator:

awk -F',' '{print $1, $3}' file.csv

OFS

Output field separator:

awk 'BEGIN {OFS=" | "} {print $1, $4}' employee.txt

RS

Input record separator.

The default is a newline.

ORS

Output record separator.

The default is a newline.

More awk Examples

Print lines 3 through 6:

awk 'NR==3,NR==6 {print NR, $0}' employee.txt

Print the second field:

awk '{print $2}' employee.txt

Print non-empty lines:

awk 'NF > 0' employee.txt

Find the longest line length:

awk '{if (length($0) > max) max = length($0)} END {print max}' employee.txt

Count lines:

awk 'END {print NR}' employee.txt

Print lines longer than 25 characters:

awk 'length($0) > 25' employee.txt

chage - Password Aging

chage manages password-expiration and account-aging information.

Inspect a user:

sudo chage -l student

Common options include:

Examples:

Set account expiration:

sudo chage -E 2027-01-31 student

Maximum password age of 90 days:

sudo chage -M 90 student

Remove account expiration:

sudo chage -E -1 student

Force a password change at next login:

sudo chage -d 0 student

Set a warning five days before expiration:

sudo chage -W 5 student

Account policy is an administrative and security decision. Do not apply expiration rules blindly.

Finding Files and Commands

find

General form:

find START_PATH EXPRESSIONS

Find by name:

find /home/developer -name 'test7000'

Find Go files:

find ./project -name '*.go'

Always quote wildcard patterns so that the shell does not expand them before find receives them.

Limit Search Depth

Maximum depth:

find ./project -maxdepth 2 -name '*.go'

Minimum depth:

find ./project -mindepth 2 -name '*.go'

Search Only Files

find ./project -type f -name 'abc*'

Only directories:

find ./project -type d -name 'abc*'

Search by Other Properties

Empty objects:

find ./project -empty

Files owned by a user:

find ./project -user developer

Files with exact permissions:

find ./project -perm 664

Files newer than another file:

find ./project -newer reference.file

find -exec

Run a command on results:

find ./project -type f -name '*.txt' -exec grep 'error' {} \;

Delete matching files interactively:

find ./project -type f -name 'sample.txt' -exec rm -i {} \;

Be extremely careful when combining find with deletion or permission changes.

First inspect the result:

find ./project -type f -name '*.tmp' -print

Only after confirming the target set should you consider a modifying command.

locate

locate searches an indexed database rather than walking the filesystem in real time.

Example:

locate test7000

Limit results:

locate -n 20 '*.html'

Ignore case:

locate -i 'readme.md'

Because locate depends on an index, very recent filesystem changes may not appear until the database is refreshed.

which, command -v, man, and --help

Locate a command found through $PATH:

which go

A shell-friendly alternative:

command -v go

Read manual pages:

man find

Command help:

find --help

These tools should become part of your normal workflow.

Do not memorize every option.

Learn how to discover the option you need.

Processes and Network Inspection

ps

Inspect running processes:

ps aux

Search within them:

ps aux | grep postgres

kill

Send the default termination signal:

kill PID

Example:

kill 1512

A forceful termination:

kill -9 1512

SIGKILL (-9) should not be the first choice.

It prevents the target process from performing normal cleanup.

Try normal termination first.

Listening Ports and Sockets

The original guide uses netstat.

It may still be available through the net-tools package:

sudo netstat -plntu

On modern Linux systems, ss is generally preferred:

sudo ss -plntu

Inspect port 80:

sudo ss -plnt | grep ':80'

lsof

Inspect processes using a port:

sudo lsof -i :5432

Extract a PID using awk:

sudo lsof -i :5432 | grep LISTEN | awk '{print $2}'

When scripting, prefer robust machine-readable output when a tool provides it instead of depending heavily on column formatting.

Network Interfaces

The original guide uses:

ifconfig

On modern Linux, use:

ip addr

or:

ip a

Routes:

ip route

The legacy ifconfig command may still exist when net-tools is installed.

/etc/hosts

Local hostname mappings are stored in:

/etc/hosts

Inspect:

cat /etc/hosts

Edit only when required:

sudo nano /etc/hosts

Incorrect entries can break local name resolution.

Memory Inspection

Display memory usage:

free -m

Human-readable format:

free -h

Linux intentionally uses available memory for filesystem caching.

High cache usage does not automatically mean the machine has a memory problem.

The original guide demonstrates manually dropping kernel caches through /proc/sys/vm/drop_caches.

That should not be used as routine memory optimization.

For normal development and administration, allow the Linux kernel to manage caches unless you are performing a controlled benchmark or diagnostic procedure and understand why cache dropping is necessary.

Scheduling Repeated Work With cron

Cron executes commands on recurring schedules.

Edit your user crontab:

crontab -e

General syntax:

MINUTE HOUR DAY_OF_MONTH MONTH DAY_OF_WEEK COMMAND

Visual form:

* * * * * command
│ │ │ │ │
│ │ │ │ └── day of week
│ │ │ └──── month
│ │ └────── day of month
│ └──────── hour
└────────── minute

Cron Examples

Every day at 03:00:

0 3 * * * /path/to/backup.sh

Five minutes after midnight every day:

5 0 * * * /path/to/command

At 14:15 on the first day of every month:

15 14 1 * * /path/to/script.sh

At 22:00 Monday through Friday:

0 22 * * 1-5 /path/to/script.sh

Every two hours at minute 23:

23 */2 * * * /path/to/script.sh

Sunday at 04:05:

5 4 * * 0 /path/to/command

Cron Special Strings

Example:

@daily /path/to/backup.sh

Removing Cron Jobs

List jobs:

crontab -l

Edit selectively:

crontab -e

Remove all jobs for the current user:

crontab -r

Warning: crontab -r removes the entire crontab. Prefer crontab -e when you only need to remove one entry.

One-Time Scheduling With at

at schedules a command for one future execution.

Install when needed:

sudo apt update
sudo apt install at

Schedule a command for 09:00:

echo "command_to_be_run" | at 09:00

One hour from now:

at now + 1 hour

At 13:00 two days from now:

at 1pm + 2 days

Inspect available jobs:

atq

Remove a scheduled job:

atrm JOB_ID

Use:

man at

for supported time formats.

UFW - Uncomplicated Firewall

UFW provides a simpler interface for Linux firewall configuration.

Install:

sudo apt update
sudo apt install ufw

Check status:

sudo ufw status

Verbose status:

sudo ufw status verbose

Default Policy

A common server policy is:

sudo ufw default deny incoming
sudo ufw default allow outgoing

This blocks unsolicited incoming connections unless explicitly allowed.

SSH Safety

Before enabling a firewall on a remote machine, make sure your SSH access is allowed.

Standard SSH:

sudo ufw allow ssh

Equivalent default port:

sudo ufw allow 22/tcp

If SSH runs on a custom port:

sudo ufw allow 2222/tcp

Critical: Enabling a firewall on a remote server without allowing the management connection can lock you out of the machine.

Allow HTTP

sudo ufw allow 80/tcp

HTTPS:

sudo ufw allow 443/tcp

Port Ranges

TCP:

sudo ufw allow 1000:2000/tcp

UDP:

sudo ufw allow 1000:2000/udp

Allow a Specific Source Address

sudo ufw allow from 192.168.1.50

Allow a source only to SSH:

sudo ufw allow from 192.168.1.50 to any port 22 proto tcp

Allow a subnet:

sudo ufw allow from 192.168.1.0/24

Deny Traffic

sudo ufw deny 80/tcp

Use deny rules deliberately and understand rule ordering.

Delete Rules

Delete by rule expression:

sudo ufw delete allow 80/tcp

Or list numbered rules:

sudo ufw status numbered

Then remove one:

sudo ufw delete RULE_NUMBER

Enable and Disable

Enable:

sudo ufw enable

Disable:

sudo ufw disable

Reset all UFW rules:

sudo ufw reset

reset removes your existing UFW configuration. Use it only when that is intentional.

Combining Advanced Tools

The real value of terminal knowledge appears when commands are combined.

Example:

sudo lsof -i :5432 \
    | grep LISTEN \
    | awk '{print $2}'

Conceptually:

inspect sockets
      ↓
filter listening entry
      ↓
extract PID field

Another example:

find ./logs -type f -name '*.log' \
    -exec grep -H 'ERROR' {} \;

Another:

grep -E '^ERROR|^WARN' application.log \
    | awk '{print $1, $2, $0}'

This is the Unix philosophy in practice:

Build larger workflows by combining small tools.

Advanced Command Checklist

You should become comfortable with:

grep
grep -E
regular expressions
sed
awk
NR
NF
FS
OFS
chage
find
locate
which
command -v
man
--help
ps
kill
ss
netstat
lsof
ip
free
cron
crontab
at
atq
atrm
ufw

You do not need to memorize every syntax form.

You need to understand what class of problem each tool solves and how to find its documentation.

Final Perspective

Advanced terminal work is not about typing complicated commands to look experienced.

It is about understanding how Linux represents:

text
files
processes
users
time
network sockets
permissions
system state

and then using small tools to inspect and manipulate those objects precisely.

A strong engineer should eventually be able to enter a remote Linux machine with nothing more than a shell and begin answering questions such as:

What process is running?
Which port is it using?
Who owns the file?
Where is the executable?
Which lines match this pattern?
Which files changed?
What job runs at 03:00?
Which firewall rule blocks the connection?

That ability is one of the foundations of backend, infrastructure, DevOps, SysOps, and cloud engineering.

Fundamentals of Git

Git is a distributed version control system used to track changes in files and to manage the history of a software project.

In software engineering, Git allows us to:

• create repositories;
• track changes over time;
• create checkpoints of development;
• compare different states of a project;
• create independent branches of development;
• merge completed work;
• undo changes;
• inspect project history;
• recover previous states;
• temporarily store unfinished work;
• mark important versions with tags.

Git is not only a tool for collaboration.

Even when you are working completely alone, Git gives you something extremely important:

A structured history of how your project changed.

That history allows you to experiment without constantly being afraid of destroying the previous working state.

Installing Git on Linux Mint

On Linux Mint, Git can be installed directly through APT:

sudo apt update
sudo apt install git

Verify the installation:

git --version

Display general Git help:

git help

Useful built-in help commands include:

git help -a
git help -g
git help init
git help commit
git help branch
git help merge

You can also use:

git <command> --help

For example:

git commit --help
git status --help
git log --help

Do not try to memorize every Git flag.

Learn the concepts first.

Then use Git’s own documentation when you need a specific option.

Initial Git Configuration

Before creating commits, configure the identity that Git will store in commit metadata.

Set your name:

git config --global user.name "Your Name"

Set your email:

git config --global user.email "you@example.com"

Inspect global configuration:

git config --global --list

Your global Git configuration is normally stored in:

~/.gitconfig

You can inspect it with:

cat ~/.gitconfig

or:

nano ~/.gitconfig

You normally do not need to create this file manually. Git creates or updates it when configuration values are written.

Creating a Working Directory

For the examples in this guide, create a directory that will contain Git repositories:

mkdir -p ~/gitLib
cd ~/gitLib

Now create the first project:

mkdir first_repo
cd first_repo

git init - Initialize a Repository

A normal directory is not automatically a Git repository.

To initialize Git inside the current directory:

git init

Example output may look similar to:

Initialized empty Git repository in /home/developer/gitLib/first_repo/.git/

Inspect hidden files:

ls -la

You will now see:

.git/

The .git directory contains Git’s repository metadata and object database.

That directory is what turns the project directory into a Git repository.

Do not manually edit or delete files inside .git unless you understand Git internals and know exactly what you are doing.

The Fundamental Git Cycle

A basic Git workflow looks like this:

Initialize repository
        ↓
Modify files
        ↓
Inspect status
        ↓
Stage selected changes
        ↓
Commit staged changes
        ↓
Inspect history
        ↓
Continue development

The most important commands at the beginning are:

git init
git status
git add
git commit
git log

Everything else builds on these concepts.

Working Tree, Staging Area, and Repository

Before going further, understand the three main states involved in normal Git work.

Working Tree
    ↓
Staging Area
    ↓
Repository History

The working tree contains the files you are currently editing.

The staging area contains the exact changes selected for the next commit.

The repository history contains commits that have already been recorded.

A useful mental model is:

edit
  ↓
git add
  ↓
stage
  ↓
git commit
  ↓
history

git status

Immediately after initialization:

git status

A new repository may report:

On branch master

No commits yet

nothing to commit

Depending on your Git configuration, the default branch may be named master or main.

This guide uses:

master

because that is the branch name used throughout the original Team413 material.

The Git concepts are identical regardless of the branch name.

Creating an Untracked File

Create a file:

touch message1.txt

Now inspect status:

git status

Git will report the file as untracked.

Conceptually:

message1.txt
    ↓
exists in working tree
    ↓
Git is not tracking it yet

git add - Add Changes to the Staging Area

Stage one file:

git add message1.txt

Inspect status:

git status

The file is now prepared for the next commit.

You can stage all current changes with:

git add .

But do not use git add . automatically without looking at what changed.

A better habit is:

git status
git diff
git add <specific-files>

when you want precise control over the next commit.

Removing a File From the Staging Area

The original guide demonstrates:

git rm --cached message1.txt

That command removes the file from Git’s index while leaving the working-tree file present.

For a file that you merely staged accidentally and still want Git to track later, modern Git also provides:

git restore --staged message1.txt

The important concept is:

Staging can be changed before committing.

A commit should contain the exact change you intend to record.

git commit - Create a Checkpoint

A commit records the staged state of the project.

Think of a commit as a checkpoint.

Stage the file:

git add message1.txt

Create the first commit:

git commit -m "Our first system message"

Git creates a commit with its own unique identifier.

Afterward:

git status

should show:

nothing to commit, working tree clean

The Three Common Change States

A tracked file may conceptually move through:

modified
    ↓
staged
    ↓
committed

Modified - The file differs from the last committed version.

Staged - The change has been selected for the next commit.

Committed - The staged change has been stored in repository history.

Short Status

Use:

git status -s

or:

git status --short

Typical status letters include:

??    untracked
M     modified
A     added
D     deleted
R     renamed

The short format is useful once you understand what the symbols represent.

git log - Commit History

Display commit history:

git log

A normal entry contains:

• commit ID;
• author;
• timestamp;
• commit message.

A compact view:

git log --oneline

Example:

0ef0242 Our first system message

The value:

0ef0242

is a shortened form of the commit ID.

Git commit IDs allow us to reference exact historical states.

Limiting Log Output

Show the last three commits:

git log -n 3 --oneline

Show commits between two revisions:

git log <older>..<newer> --oneline

Example:

git log d110129..74d91c --oneline

Visualizing History

A very useful command is:

git log --oneline --decorate --graph --all

This shows:

• compact commit IDs;
• branch and tag names;
• branch relationships;
• the commit graph.

Use this frequently while learning branches and merges.

Branches

A branch represents an independent line of development.

Branches allow us to isolate:

• new features;
• bug fixes;
• experiments;
• refactoring;
• temporary work.

A common workflow is:

stable branch
      ↓
create feature branch
      ↓
develop and commit
      ↓
test
      ↓
merge
      ↓
remove feature branch when finished

Listing Branches

git branch

The active branch is marked with:

*

Example:

* master

Creating a Branch

git branch feature/task2

List again:

git branch

Example:

  feature/task2
* master

The branch exists, but we have not switched to it yet.

Switching Branches

The original guide uses:

git checkout feature/task2

Modern Git also provides:

git switch feature/task2

Both concepts mean:

Move HEAD to another branch and update the working tree to that branch’s state.

Create and Switch in One Command

Using checkout:

git checkout -b feature/task3

Modern equivalent:

git switch -c feature/task3

Rename a Branch

git branch -m old-name new-name

Example:

git branch -m small-feature quick-feature

Commit Changes on a Feature Branch

Switch to the feature branch:

git checkout feature/task2

Modify a file:

echo "This is the first system message!" >> message1.txt

Inspect:

git status

Stage:

git add message1.txt

Commit:

git commit -m "First system message has been modified"

Inspect history:

git log --oneline --decorate --graph --all

You should now see that the feature branch contains a commit that the original branch does not yet contain.

git diff Between Branches

Before merging, inspect the difference:

git diff master feature/task2

Git displays what changes would distinguish one branch state from the other.

Merging a Branch

To merge feature/task2 into master, first switch to the branch that should receive the changes:

git checkout master

Then:

git merge feature/task2

This direction matters.

Conceptually:

current branch
    +
incoming branch
    ↓
merged current branch

Fast-Forward Merge

If master has not changed since the feature branch was created, Git may perform a fast-forward merge.

Before:

A---B   master
     \
      C---D   feature

After fast-forward:

A---B---C---D   master, feature

Git does not need a new merge commit.

It simply moves the master branch pointer forward.

Deleting a Merged Branch

After a feature has been merged:

git branch -d feature/task2

The lowercase -d performs a safe deletion and refuses when the branch contains work that Git considers unmerged.

Force deletion:

git branch -D feature/task2

Use -D carefully. It can remove a branch that contains commits not reachable from another branch.

git commit -a

For already tracked files, Git can stage modifications and deletions as part of commit:

git commit -am "Fourth system message has been added"

This is effectively useful for tracked files only.

It does not automatically include brand-new untracked files.

For new files, use:

git add new-file
git commit -m "Add new file"

Creating Several Commits

Create another modification:

echo "Second system message: Welcome!" >> message1.txt
git add message1.txt
git commit -m "Second system message has been added"

Then another:

echo "Third system message: Analyze!" >> message1.txt
git add message1.txt
git commit -m "Third system message has been added"

And another:

echo "Fourth system message: Proceed!" >> message1.txt
git commit -am "Fourth system message has been added"

Inspect:

git log --oneline

Now the project history contains multiple checkpoints.

Checking Out a Specific Commit

Suppose the history contains:

e0c20e6 Fourth system message has been added
24af2fa Third system message has been added
aba3bd9 Second system message has been added
650bf2c First system message has been modified
0ef0242 Our first system message

To inspect the repository at the second-message commit:

git checkout aba3bd9

Git will enter a detached HEAD state.

Understanding HEAD

HEAD represents the currently checked-out position.

Normally:

HEAD
 ↓
branch
 ↓
commit

For example:

HEAD -> master -> e0c20e6

In detached HEAD state:

HEAD -> aba3bd9

HEAD points directly to a commit rather than to a normal branch.

Detached HEAD

Detached HEAD is useful for:

• inspecting old states;
• testing old commits;
• temporary experiments;
• comparing historical versions.

Example:

git status

may show:

HEAD detached at aba3bd9

The working tree now represents the selected historical commit.

Creating Commits in Detached HEAD

You can modify files and commit while detached.

For example:

echo "Experimental message" >> message1.txt
git commit -am "Experimental detached commit"

But that commit is not automatically attached to a normal branch.

If you later switch away, Git may warn that you are leaving the commit behind.

To preserve it, create a branch:

git branch experiment <commit-id>

or while currently detached:

git switch -c experiment

Creating a Branch From an Older Commit

Checkout the historical commit:

git checkout aba3bd9

Create a new branch from that point:

git checkout -b feature/task5

Now any new commits belong to feature/task5.

This is one of Git’s most powerful properties:

Any historical commit can become the starting point of a new line of development.

git revert - Safely Undo a Commit

Suppose the latest commit added something that should be removed.

Use:

git revert HEAD

Git creates a new commit that reverses the effect of the selected commit.

History remains intact.

Conceptually:

A---B---C
        ↓
   incorrect change

git revert C

A---B---C---D
            ↓
       inverse of C

Both the original commit and the revert remain visible.

This makes revert especially useful when history should remain traceable.

Revert a Specific Commit

git revert <commit-id>

Example:

git revert 140c7a6

git reset - Move Repository State

git reset is different from git revert.

Revert adds a new inverse commit.

Reset moves a branch reference and can change the staging area and working tree depending on the mode.

This makes reset powerful, but potentially destructive.

Unstage Changes With Reset

A plain:

git reset

moves staged changes out of the staging area while normally leaving the working-tree modifications present.

Conceptually:

staged
  ↓
git reset
  ↓
modified but unstaged

Modern Git also provides:

git restore --staged <file>

for explicit unstaging.

Reset to a Commit

git reset <commit-id>

By default this is a mixed reset.

The branch moves to the specified commit, while later file changes normally remain in the working tree as unstaged modifications.

git reset --hard

Example:

git reset --hard 24af2fa

This moves the branch and resets both:

• staging area;
• working tree.

Changes after the target state may disappear from the visible branch and working tree.

Treat git reset --hard as destructive. Always inspect git status and git log first.

Do not use it casually on work you have not protected.

Revert vs Reset

A simple comparison:

A useful rule:

Use revert when history should remain intact. Use reset when you intentionally want to rewrite or reposition local history.

git clean - Remove Untracked Files

git reset primarily affects tracked repository state.

git clean deals with untracked files.

Preview first:

git clean -n

or:

git clean --dry-run

This is extremely important.

It shows what Git would delete.

Remove Untracked Files

git clean -f

Remove untracked directories too:

git clean -df

Remove ignored files as well: