When a task looked slow, I tended to look for a different way to organise it. Sometimes the obstacle was not a shortage of ability or equipment. It was the assumption that I had to work in the same sequence and with the same tools as everyone else.
But a method is not efficient merely because it feels fast to me. It must produce a useful result without hiding mistakes or making other people bear its costs.
Decide what the work needs to reveal
At polytechnic, I was assigned an individual logistics project using computer simulations. I wanted to find out systematically how changing the inputs affected the result.
Instead of repeatedly trying combinations without a clear plan, I drew a grid on the laboratory whiteboard and reduced the investigation to about ten experiments. I varied one input while keeping the others constant so I could see what difference that change made.
The first saving came before any computer ran. I had decided what each experiment was for and removed some aimless trial and error.
For a similar project, begin with the question rather than the machinery. What do I need to learn? Which comparison would answer it? What result would make me change my current view? An impressive quantity of output is not useful if I cannot explain what it establishes.
Changing one input at a time can make an initial comparison clearer. It does not prove that the best settings have been found: the effect of one input may depend on another. The next experiment should address what remains uncertain, rather than simply repeating the first method indefinitely.
Use waiting time without multiplying confusion
My classmates generally used one workstation each. I used six, synchronised the datasets and ran the simulations in batches. About an hour later, I left while others were still working. The lecturer was impressed by the report and described it as university-level work.
This was not six times as much thinking at once. The machines could perform separate runs while I kept track of the investigation. The opportunity was in making use of time during which one computer would otherwise leave me waiting.
That distinction matters when applying the idea elsewhere. Several independent processes may run alongside one another. Several tasks that all require my close attention may instead interrupt and slow each other down.
Before running work in parallel, I would check that the inputs, filenames and outputs are clearly identified. Otherwise, the time saved in running the work can disappear while I try to discover which result belongs to which experiment. More equipment also means more opportunities to start one run with the wrong settings.
Shared resources require agreement. An apparently idle computer may be reserved, needed by someone else or subject to restrictions. My example is a reason to look for available capacity, not permission to claim it without asking. If several people need the same resource, arranging batches or different time slots may improve the overall result more than giving everything to one person.
Improve the whole process
As a child on classroom-cleaning duty, I divided the floor into zones and swept each one carefully. I then aligned the tables with no deviation. I could take an hour over a task that occupied classmates for only a few minutes.
The precision felt right, but I had not distinguished a clean, usable classroom from an arrangement perfected beyond its purpose. Effort was being spent on the wrong standard.
The opposite error is to remove a check because it slows me down. During National Service, insufficient checking left a name out of a survey and some results incomplete. The work looked quicker until the omission mattered.
Together, these experiences give me a more useful definition of efficiency: remove effort that does not improve the required result, while preserving the checks that protect it. A faster failure is not an improvement.
Make a small improvement easy to understand
A classmate asked what I was doing with the simulation grid, then lost interest when I began explaining the technicalities. I could understand the method without knowing how to make it understandable to somebody else.
For a proposed improvement, start with its practical effect: “These runs are independent, so using available computers together could reduce waiting. Each output will be labelled so we can still check it.” Then explain the technical detail to whoever needs it.
Show a small working example before demanding a large change. State what resources it needs, what could go wrong and how to return to the previous arrangement. That makes the idea easier to evaluate than a claim that my method is obviously superior.
Use a strength where it earns its place
I did not obtain the IT course I wanted, but a logistics assignment still gave me an opportunity to use computing and experimental design. The course label did not prevent me from bringing those abilities to the work.
This is worth remembering when the available situation is not the ideal one. Ask where an existing strength can solve a real problem within it. Preserve the result so the improvement can be explained and repeated. Innovation becomes useful to other people when they can see not only that it worked once, but what they would need to make it work again.