Introduction

Engineering begins with a practical question:

How can we make something work reliably in the real world?

Programming begins with a related question:

How can we describe a process clearly enough that a computer can carry it out?

Leadership begins with a third question:

How can people work together responsibly to solve problems that are too large for one person alone?

This book connects those three questions. You will learn Python, but not as a collection of isolated commands. You will learn Python as a tool for engineering thinking: measuring, calculating, modeling, testing, automating, communicating, and improving technical work with other people.

Python is a widely used general-purpose programming language. “General-purpose” means it is not limited to one kind of task. It can be used for small scripts, data analysis, web applications, automation, scientific computing, and many other forms of software. The official Python tutorial describes Python as a language that supports both quick scripting and larger programs, with a standard library that helps with many common tasks (Python Software Foundation, n.d.). In this book, we will use Python mainly for engineering-style problems: handling measurements, processing files, building small simulations, making plots, and creating useful tools.

You do not need to know programming before starting. You do need patience, attention, and willingness to test your own thinking. Beginners often believe that programming is mainly about memorizing syntax. Syntax means the formal rules for writing code so the computer can understand it. Syntax matters, but it is only the surface. The deeper skill is learning to turn an unclear problem into clear steps.

For example, suppose someone says:

“Can you make a program that checks whether a water tank is safe?”

That request is too vague for code. A computer cannot understand “safe” unless we define it. We need to ask engineering questions:

• What measurement tells us the tank level?
• What is the maximum safe level?
• What unit is being used: liters, cubic meters, or percent full?
• How often should the measurement be checked?
• What should happen if the level is too high?
• How should errors or missing readings be handled?

After asking those questions, we might express a simple rule:

If the measured level is greater than the maximum safe level, show a warning.

In Python, a beginner version might look like this:

level_percent = 87
maximum_safe_percent = 80

if level_percent > maximum_safe_percent:
    print("Warning: tank level is above the safe limit.")
else:
    print("Tank level is within the safe limit.")

This small program is not just “coding.” It contains a simple engineering decision rule. It uses data, comparison, and communication. Later in the book, you will learn how to make examples like this more realistic by reading data from files, checking for invalid measurements, plotting trends, writing tests, and documenting the assumptions.

What programming really is

A program is a set of instructions written for a computer to execute. To execute a program means to run its instructions step by step. A computer is fast, but it is not wise. It does not understand your intention unless that intention is expressed precisely enough.

An algorithm is a finite, ordered procedure for solving a problem or completing a task. “Finite” means it eventually stops. “Ordered” means the steps have a sequence. A recipe is an everyday example of an algorithm: first measure the ingredients, then mix them, then bake for a stated time. In programming, an algorithm might describe how to compute an average, sort a list of readings, or decide whether a sensor value is outside an acceptable range.

Consider this simple algorithm for finding the average of three temperature readings:

1. Add the three readings.
2. Divide the total by 3.
3. Report the result.

In Python:

t1 = 22.4
t2 = 23.1
t3 = 22.8

average_temperature = (t1 + t2 + t3) / 3

print(average_temperature)

The code is short, but several important ideas are already present. The names t1, t2, and t3 store values. The expression (t1 + t2 + t3) / 3 performs a calculation. The name average_temperature stores the result. The print() function displays information to the user.

A function is a reusable piece of code that performs a defined task. For example, later you will learn to write the averaging logic like this:

def average_three(a, b, c):
    return (a + b + c) / 3

Now the same idea can be reused with different values:

print(average_three(22.4, 23.1, 22.8))
print(average_three(101.2, 100.8, 101.5))

This is one of the most important habits in programming: when a useful idea appears more than once, we try to name it, test it, and reuse it.

What engineering adds to programming

Engineering is not only calculation. It is the disciplined design and improvement of systems under real constraints. A constraint is a limit or requirement that affects a solution. Engineering design commonly involves constraints such as cost, safety, reliability, manufacturability, sustainability, usability, and standards; ABET’s engineering accreditation criteria describe engineering design as a process of creating solutions while considering factors such as public health, safety, welfare, and other practical constraints (ABET, 2024).

A beginner may write a program that gives the correct answer for one example. An engineering-minded beginner asks more questions:

• What happens if the input data is missing?
• What happens if the units are wrong?
• Is the result accurate enough for the decision being made?
• Can another person understand the code next month?
• Can we test the program before using it in a real workflow?
• What are the risks if the program fails?

Suppose you write a script that converts pressure from kilopascals to pascals:

pressure_kpa = 250
pressure_pa = pressure_kpa * 1000

print(pressure_pa)

The arithmetic is correct because 1 kilopascal equals 1000 pascals. But the engineering concerns do not stop there. You should also ask:

• Is the input definitely in kilopascals?
• Should the program label the output?
• Should it reject negative pressure if negative values are impossible in this context?
• Should it store the result in a file?
• Should someone review the calculation?

A more communicative version might be:

pressure_kpa = 250
pressure_pa = pressure_kpa * 1000

print(f"Pressure: {pressure_pa} Pa")

This is still simple, but it is already better because the output includes a unit. In engineering work, numbers without units are often dangerous because they invite misunderstanding.

Computational thinking: the bridge between problem and code

Before writing code, you need a way to think. Computational thinking is a way of formulating problems and solutions so that a computer, human, or combination of both can carry them out. Jeannette Wing’s influential article describes computational thinking as a fundamental skill involving concepts such as problem decomposition, abstraction, and algorithmic thinking (Wing, 2006).

Three ideas will appear throughout this book.

First, decomposition means breaking a large problem into smaller parts. If your goal is “analyze a machine’s vibration data,” the smaller parts might be:

1. Load the data file.
2. Check whether the data has missing values.
3. Convert units if needed.
4. Compute summary statistics.
5. Plot vibration over time.
6. Flag readings above a threshold.
7. Write a short report.

Each part is easier to understand and test than the whole problem at once.

Second, abstraction means focusing on the details that matter for the current purpose while temporarily ignoring details that do not. A map is an abstraction of a city. It does not show every stone, tree, or wire, but it shows enough to help you navigate. In programming, a function can be an abstraction. If you write a function called convert_kpa_to_pa(), you can use it without rethinking the multiplication every time.

def convert_kpa_to_pa(pressure_kpa):
    return pressure_kpa * 1000

The name tells the purpose. The body contains the details.

Third, algorithmic thinking means describing a solution as a clear sequence of steps. For example, to check whether a temperature reading is acceptable, we can describe the algorithm in plain English:

1. Receive the temperature.
2. Compare it with the lower limit.
3. Compare it with the upper limit.
4. Report whether it is too low, acceptable, or too high.

Then we can write Python:

temperature = 74
lower_limit = 60
upper_limit = 80

if temperature < lower_limit:
    print("Too low")
elif temperature > upper_limit:
    print("Too high")
else:
    print("Acceptable")

This book will repeatedly move between plain-language reasoning and Python code. That movement is intentional. Good programmers do not jump blindly into code. They clarify the problem, sketch a solution, write a small version, test it, and improve it.

Why leadership belongs in a programming book

At first, leadership may seem separate from coding. It is not.

Technical work usually happens with other people: classmates, technicians, engineers, managers, clients, users, reviewers, and future maintainers. Even when you write code alone, you are often serving someone else’s need. Your code may be read, trusted, modified, or questioned by another person.

In this book, leadership does not mean having a title. It means taking responsibility for helping useful work move forward. A beginner can practice leadership by:

• asking clarifying questions,
• writing understandable notes,
• admitting uncertainty early,
• sharing progress honestly,
• helping teammates debug a problem,
• listening carefully before disagreeing,
• making decisions visible instead of hidden.

A key leadership concept is psychological safety. In team research, Amy Edmondson defined team psychological safety as a shared belief that a team is safe for interpersonal risk-taking, such as asking questions, admitting mistakes, or raising concerns (Edmondson, 1999). This matters in technical work because hidden mistakes can become serious failures. A team where people are afraid to speak up may move quickly for a while, but it becomes fragile.

Imagine a small project team building a Python script to process laboratory measurements. One student notices that the units in one file might be different from the others. If the team culture punishes questions, the student may stay silent. If the team culture welcomes careful concerns, the student can say:

“I may be wrong, but I think this column is in millimeters, not meters. Can we check before using it?”

That sentence is both technical and leadership behavior. It protects the work.

Confidence comes from process, not guessing

Many beginners think confident programmers simply know the answer immediately. In reality, reliable technical people use processes that reduce guessing.

When a program fails, they read the error message. When a calculation looks strange, they check the inputs. When a function becomes confusing, they simplify it. When a project becomes too large, they divide it into tasks. When a team becomes misaligned, they clarify the goal and next action.

This book will teach you practical processes:

• how to trace code line by line,
• how to test a small piece before trusting a large program,
• how to use files and libraries without losing track of your environment,
• how to name variables so your code explains itself,
• how to use Git to record changes,
• how to communicate status without hiding problems,
• how to lead a small project from idea to prototype.

A prototype is an early working version of a solution. It is not final. Its purpose is to help you learn. For example, if you want to build a tool that analyzes energy use in a building, a prototype might read one CSV file, compute daily total energy, and make one plot. Later versions may support many files, better error handling, configuration options, and a polished report.

The prototype mindset is important because it prevents paralysis. You do not need to design the perfect system before writing any code. You need to build a small honest version, learn from it, and improve it carefully.

What you will be able to do

By the end of this book, you should be able to write small Python programs that solve practical problems. You will understand values, variables, expressions, conditionals, loops, functions, data structures, files, libraries, numerical arrays, tables, plots, simulations, classes, tests, Git workflows, automation scripts, and project structure.

More importantly, you should understand how these tools fit together.

For example, a complete beginner might first learn this:

distance_m = 120
time_s = 10

speed_m_per_s = distance_m / time_s

print(speed_m_per_s)

Later, the same learner can grow that idea into a more useful engineering tool:

• read many distance and time measurements from a CSV file,
• check for invalid or missing values,
• compute speed for each test,
• summarize the results with pandas,
• plot the speeds with Matplotlib,
• write tests for the calculation,
• save the analysis in a reproducible project folder,
• document assumptions and units,
• present the results to a team.

That growth is the path of the book: from small correct steps to larger trustworthy work.

How to approach the chapters

Do not rush the early chapters. The basics are not “baby material.” Values, variables, conditionals, loops, and functions are the foundation for nearly everything else. If you understand them deeply, later tools such as NumPy, pandas, Matplotlib, simulations, and object-oriented programming will make much more sense.

When you see code, do not only read it. Run it if you can. Change one line and predict what will happen. Then run it again and compare the result with your prediction. This practice builds an internal model of how Python behaves.

For example, if you see:

x = 5
x = x + 2
print(x)

Pause and predict the output. The answer is 7, because the second line takes the current value of x, adds 2, and stores the new value back into x.

Then try changing it:

x = 5
y = x + 2
print(x)
print(y)

Now x remains 5, and y becomes 7. This tiny example teaches an important distinction: assigning a new value to y does not automatically change x.

Programming skill grows through many such small moments of accurate understanding.

A promise and a responsibility

This book will not pretend that programming is always easy. You will meet error messages. You will write code that does not work the first time. You will misunderstand something and then correct it. That is normal. Debugging is not a sign that you are bad at programming; debugging is part of programming.

The promise of this book is that the path will be clear. Each new concept will be introduced from first principles, practiced with examples, and connected to engineering work. You will not be expected to become an expert instantly.

Your responsibility is to be active. Type code. Trace code. Ask what each line means. Keep notes. When something works, ask why it works. When something fails, slow down and investigate. When working with others, communicate early and respectfully.

If you do that, you will not merely “learn Python.” You will begin to develop the habits of a technical problem-solver: precise thinking, careful testing, honest communication, and responsible leadership.

That is where we begin.

References

ABET. (2024). Criteria for Accrediting Engineering Programs, 2024–2025. ABET. https://www.abet.org/accreditation/accreditation-criteria/criteria-for-accrediting-engineering-programs-2024-2025/

Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.

Python Software Foundation. (n.d.). The Python Tutorial. Python documentation. https://docs.python.org/3/tutorial/

Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33–35.