What CNC Programmers Actually Do All Day (It's Not Just Pressing Cycle Start)

What CNC Programmers Actually Do All Day (It's Not Just Pressing Cycle Start) — ThirdShiftPress

What CNC Programmers Actually Do All Day (It's Not Just Pressing Cycle Start)

Your uncle thinks you push a green button. Your mother-in-law tells people at church that you "do computers with metal." The kid at the family barbecue asked if you build robots, and when you said no, he lost interest in roughly 0.4 seconds. Meanwhile you spent eleven hours yesterday arguing with a post processor about whether G43.4 was a real cycle on this machine or a suggestion. The gap between what people think CNC programming is and what it actually is could swallow a Bridgeport.

So here's the rundown. Not the LinkedIn version. The version where you've already had three cups of coffee and the second-shift guy left a sticky note that just says "spindle weird."

The Morning Briefing: Inheriting Other People's Problems

The shift starts with a walk. Not for your health. You're walking the floor because three machines ran overnight and at least one of them did something interesting. "Interesting" is a word programmers use when they don't want to say what actually happened in front of the owner.

You check the parts. You check the chips. Long stringy chips on a steel job mean somebody changed an insert without telling you and now the chipbreaker geometry is wrong. Blue chips mean you're running too hot. Purple chips mean you're running way too hot and the operator already knows and is hoping you won't notice.

You check the setup sheets. The setup sheets are wrong. They have been wrong since 2019. Everyone knows they are wrong. Updating them is on the list, somewhere below "find a 5/8 collet that isn't seized" and "respond to the email about Q3 ergonomic goals."

Then you get to your desk and there are seven emails from engineering. Two of them are revisions to a part that's already running. One of them is a new print where the GD&T callout for true position references a datum that doesn't exist on the drawing. The other four are meeting invites. You decline all four. They will be rescheduled.

Writing the Program (The Part People Think Is the Whole Job)

Civilians imagine CNC programming as typing G-code into a black screen like you're hacking the Pentagon. Some of us still do write by hand, especially for lathe work or simple mill ops where firing up CAM is more trouble than it's worth. But most of the day, real programming looks like this:

Open the model. Discover the model is a STEP file from 2014 that was exported with sloppy tolerances and has a 0.0003" gap between two surfaces that should be tangent. Email the engineer. Get told the gap "shouldn't matter." Make it matter anyway, because the toolpath is going to gouge that edge and you don't feel like grinding a $400 endmill out of a fixture later.

Lay out your workholding. Decide whether you're soft-jawing it, using a vise with parallels, building a fixture plate, or — on those special days — clamping it directly to the table with strap clamps like an animal. Workholding decisions are 60% of the job and 5% of the credit.

Pick your tools. Walk to the crib. Discover the 1/4" carbide ball you wanted has one left, it's chipped, and the new ones won't be here until Thursday. Adjust the program for a 3/16" ball. Adjust the stepover. Adjust the leftover stock. Adjust your expectations.

Post the code. The post processor will, with the cheerful confidence of a six-year-old, output something that looks correct but contains a single rogue G91 that will, if you don't catch it, send the spindle into the chuck at rapid. You catch it. You always catch it. The one time you don't catch it is the day you get a shirt that says "I survived the crash on the Mori."

Setups, Probes, and the Long Slow Truth About First Articles

A program isn't real until it cuts a part. Until then, it's a hypothesis.

Setup is where the programming actually gets tested against physics. You touch off tools. You probe the part. You discover that the probe is 0.0008" out of calibration in X because somebody used it as a hammer. You re-master the probe. You re-touch. You set work offsets. You walk through the program in single-block at 5% rapid, hand hovering over the feed hold like it's a defibrillator paddle.

The first part comes off. You bring it to the CMM. The CMM operator looks at you the way pharmacists look at people refilling Adderall too early. You wait. The report prints. Three features are out: a bore is 0.0006" undersize, a chamfer is 0.005" oversize, and somehow a feature that wasn't even machined this op is flagged because the fixture moved between operations.

You adjust offsets. You re-cut. You re-measure. This is what "first article" means. Not "the first article." The first seventeen articles, depending on the part.

The Documentation Nobody Reads (But You Write Anyway)

Setup sheets. Tool lists. Inspection plans. Op sheets with photos of the workholding. Probe routines documented. Custom macros explained in plain English at the top so the night-shift guy doesn't have to call you at 2 a.m. about an alarm.

Nobody reads any of this until something goes wrong. Then everyone reads it, very carefully, looking for someone to blame. So you write it like a lawyer. Every assumption. Every reason. Every "do not change this offset, ask first." You include the part number, the revision, the date, the post version, and a small prayer.

You also maintain the tool library. The real one. Not the one in the software — that one is for show. The real one is a spreadsheet, or a notebook, or a series of grunts you exchange with the toolroom guy. It tracks which inserts work in which materials, which holders run out, which collets have started slipping, and which endmills are mysteriously 0.012" shorter than they were yesterday.

Babysitting Production Without Looking Like You're Babysitting

Once a job is running, you're supposed to be programming the next one. In practice, you're standing six feet from the machine pretending to look at your phone while listening to the spindle. You know what it should sound like. You know what it sounds like when a tool is going dull. You know what it sounds like a half-second before something breaks.

The operator knows too. Good operators know their machines better than you do. The relationship between programmer and operator is the most important professional relationship in the shop, and it's almost entirely built on small acts of not being a jerk. Don't blame them when your program is wrong. Don't take credit when their setup is what saved the day. Bring coffee occasionally. Listen when they tell you the feed feels off.

When something does break, you don't say "the program is fine." You go look. You always go look. Half the time it's a tool. A quarter of the time it's a fixture. The remaining quarter is your program, and it's better to find that out before anyone else does.

Q&A: The Questions You're Tired of Answering

"So you just program robots?"

Sure. If by "program robots" you mean writing motion code for a $400,000 machine that can ruin a $2,000 piece of stock in 0.8 seconds and then deciding the cause was probably a thermal expansion issue in a fixture you designed last Tuesday.

"Could AI do your job?"

It can already generate toolpaths that almost work. The "almost" part is where careers live. AI cannot smell coolant going bad. AI cannot tell you the chuck jaws are worn from the sound the bar makes loading. AI does not know that this particular Haas pretends to be okay until exactly 4:15 p.m.

"Is it hard to learn?"

The G-code is easy. The machines are easy. The CAM software is medium. The materials, the tooling, the workholding, the inspection, the tribal knowledge of every shop you walk into — that takes a decade and you're never finished.

"Why are you so tired? You sit at a computer."

Programmers walk. A lot. Between the desk, the floor, the toolroom, the inspection bench, engineering, the toolroom again, the floor again, the desk, and then back to the floor because someone changed something. Count your steps for one shift and report back.

The Part Where the Day Ends and Doesn't

You don't really finish a programmer's day so much as abandon it in progress. There's always a job queued, a print to review, a fixture to design, a macro to clean up. You walk past the machine on your way out. It's mid-cycle. The chips are the right color. The operator nods. You nod. The night-shift guy comes in and asks what's running. You tell him. You tell him about the offset on tool 7. You tell him the part likes to ring on the second op so back the feed off if it gets loud. You tell him not to touch the macro at line 240.

He nods. He won't touch it. Probably.

Then you go home and your kid asks what you did at work today and you say "programming," and they go back to their tablet, and you stand in the kitchen for a minute thinking about whether a different lead angle would solve the chatter on that titanium bracket, and your spouse asks if you're listening, and you weren't, and you apologize, and somewhere across town a spindle hums in the dark, cutting a part you wrote.

Related from ThirdShiftPress