From Mechanical Engineering to Software Automation

My background is in mechanical design and manufacturing, with more than nine years of experience. Software became relevant because many engineering workflows involve structured information, repeated decisions, and checks that benefit from well-designed tools.

Start with the engineering process

Automation is not the first step. Before writing code, I want to understand the inputs, constraints, decisions, and expected output of the existing process.

A useful first model can be written without choosing a programming language:

input → validate → transform → review → output

This makes assumptions visible. It also helps identify the steps that still require engineering judgement and should not be automated blindly.

Choose tools that fit the work

Different constraints call for different tools. Python and Excel VBA can support focused data or spreadsheet workflows. C# and WinForms can provide a practical desktop interface, while SQLite offers local structured storage. CAD tools remain central when the output is an engineering design rather than software.

The aim is not to replace one discipline with another. It is to use software where it can reduce repetitive handling, make validation clearer, or support a more consistent workflow.

Keep the feedback loop short

Small internal tools benefit from the same discipline as mechanical design: explicit requirements, controlled changes, testing, and feedback from real use. A narrow tool that reliably supports a known process is often more valuable than a broad system built around untested assumptions.

For me, software automation is an extension of practical engineering: understand the system, respect its constraints, and improve it in measured steps.