Why the last hour before a deadline always feels the same
Ask any UK design office what quietly eats into the week and you will hear the same list: renaming layers to match a client's standard, dropping the same title block into forty drawings, plotting a batch of sheets to PDF, exporting files for a contractor who uses different software. None of it is difficult. All of it is repetitive, and repetition is where both lost hours and silly mistakes live. The good news is that practically every CAD package has had automation built into it for decades. You do not need to be a programmer to use it. You just need to start small and build the habit.
Begin with the macro recorder
Most drafting platforms include some form of macro or action recorder, usually tucked away in a tools menu. It watches what you do, writes it down as a sequence, and lets you replay that sequence on another drawing. This is the gentlest possible introduction to automation because it requires no syntax, no debugging and no theory.
A few habits make recorded macros far more reliable:
- Drive the task from the keyboard. Type command names rather than clicking toolbar icons. Recorded clicks depend on screen position and dialog states, whereas typed commands replay cleanly on any machine.
- Record on a copy, never the live drawing. You will get the sequence wrong the first few times, and undoing a macro halfway through is rarely clean.
- Name and store macros immediately. A folder called macros on the project drive, with names like title-block-a1.scr, beats a mystery file on your desktop.
- Keep them short. One macro per job. A recorder is not the place for a five-stage workflow.
Even if you never write a line of code, half a dozen recorded macros will repay the afternoon you spent learning the recorder.
From macros to script files
The next step is the script file: usually a plain text document with a .scr extension that simply replays whatever you would type at the command line, one entry per line. A blank line usually means "press Enter", which is exactly how you confirm most commands. Comments, where supported, let you leave notes for the colleague who inherits the file in eighteen months.
What makes scripts powerful is that they can be run in a batch. Point the software at a folder of drawings, tell it to run the script on each one in turn, and go and make a cup of tea while two hundred files are renamed, purged and plotted. A task that would have taken a full day becomes a background job. Start by scripting something you already understand thoroughly — a layer rename, a standard viewport setup — and only then move on to something ambitious.
Five repetitive jobs worth automating this week
- Layer renaming and rationalising. Mapping a consultant's layer names onto your own standard is pure pattern-matching, and a script does it identically every time. This alone can save hours on a multi-disciplinary project.
- Block insertion and title block updates. Inserting the correct border, updating revision fields, swapping an old north point for the current one across a whole drawing set.
- Batch plotting and export. Producing PDFs, DWG or DXF files for issue, with the same paper size, plot style and file-naming convention every time.
- Drawing clean-up. Purging unused layers, running an audit, setting the correct units and layers before a file is issued. Tedious, invisible, and exactly the sort of thing that causes a query two weeks later.
- Data extraction. Pulling attribute values, areas or schedules out of many drawings into a single spreadsheet for costing or facilities management.
Learning a scripting language without derailing your week
When you are ready to go beyond recorded sequences, pick the language your platform favours rather than the one with the most exciting reputation. Some tools favour a Lisp-style dialect, others a variant of Basic, and an increasing number accept Python. Whichever you choose, the first month looks the same: variables, loops, conditionals and a few ways to read and write files.
Protect the learning time rather than hoping to find it:
- Set aside one hour a fortnight, ideally at a quiet point in the week, and treat it as a real commitment.
- Rewrite a recorded macro by hand. You will understand the file far better than if you only ever record.
- Keep a personal snippets file — the code that inserts a title block, the loop that walks a folder — so you are assembling rather than remembering.
- Solve a genuine problem from your own work. Abstract exercises rarely stick; the script that saved you a Monday afternoon always does.
Testing, standards and sharing the benefit
Automation multiplies whatever you feed it, including mistakes. Always test on a copy of a drawing, ideally one with awkward content such as xrefs, frozen layers and unusual units. Avoid hard-coded file paths and drive letters, because the person who runs your script next will almost certainly have a different folder structure. Add a comment block at the top of each file explaining what it does, who wrote it, and what it expects to find.
Then share it. A script kept to yourself saves one person's time; a script sitting in a documented, read-only folder on the practice network, with a short note on your intranet explaining what it does, lifts a whole team. Nominate someone to keep that folder tidy and to test scripts after a software upgrade. Do that, and the hour you spent recording your first macro quietly turns into hundreds of hours across the office.
Zhon Andarson
Coding is used in almost all aspects of life and work now, be it directly or indirectly. It’s not just for companies in the tech sector. “An increasing number of businesses rely on computer code,
Andro Smith Doe
Coding is used in almost all aspects of life and work now, be it directly or indirectly. It’s not just for companies in the tech sector. “An increasing number of businesses rely on computer code,