Programming and solving problems
It has been a terrifying year for almost all modern professions. Of course, I am talking about the implications of large AI models on our careers.
Language models come out monthly, competing in natural language understanding and creation.
New models are published weekly to optimize code, video, image, and sound generation.
Auto-generation models can iterate and increment over and over automatically to reach final objectives.
As someone who closely follows software development, I feel the storm is coming from everywhere. I didn’t say I am a soft dev; some team members no longer call me that. It hurts. Even technically, I have never been a pure software dev during my professional life (machine vision engineer, manager, etc.).
Two weeks ago, a company published a blog Introducing Devin, the first AI software engineer. To summarize, it uses GPT models to achieve the capabilities of an entry-level software developer. I don’t know who will sweat more at the moment, but from the productivity point of view, my heart races faster.
Recently, I have been spending quite a lot of time reading a book called The Art of Doing Science and Engineering. I will write about it another time. One concept immediately triggered me when the author discussed what a good programming language is.
What is wanted in the long run, of course, is that the man with the problem does the actual writing of the code with no human interface, as we all too often have these days, between the person who knows the problem and the person who knows the programming languages.
Why do I bring this up?
As an engineer turned manager, with my limited experience, I gradually realized that programming or any isolated engineering field within a multi-discipline project is generally much easier to handle. I will continue the following discussion from the perspective of Large-Scale Machine Vision system design, which includes both software and hardware components. However, I believe it holds true for more generic cases.
The difficulties lie in their interface, especially for a new product or an inexperienced team. This will require the product designer, system architect, or tech lead to break it down into comprehensible pieces.
The most common question and frustration between an architect and a specialist is that the design requirements for the individual field are either too vague or too strict. No matter the top-down or bottom-up approach, programmers and engineers want to solve a well-defined problem. This comes from our human nature: We love to use our mental shortcuts (professionally learned or human-inherent). However, it is rare that a problem is well-definable before the end of the project. There are assumptions to take, risks to assess, and parameters to tune.
This will not be a nice-to-have skill in the short future. Last year, I wrote a post, Don’t Be An Endpoint. I want to extend the argument a little more: An endpoint solves well-defined problems, and it is easy to replace by a machine.
What should we do then?
Well, sadly, there is no one-fix-for-all solution. However, there are some principles one should follow.
Think before starting programming or designing anything. Bashing the keyboard or swinging a hammer is exciting, but they are not the goal.
Define acceptance tests first. In other words, understand the overall system design objective. This should always be available. Try to derive the individual design scope backward.
Understand adjacent fields’ major design parameters and the impacts of your design on them.
Be open-minded in iterations.
Again, this is based on my limited experience. There is surely something missed.
When I wrote the three groups of people to break down an engineering problem, I unintentionally omitted the non-technical part. This turns out to be the last obstacle in solving a problem. One will not see the actual problem when the vision is limited. For many of our project failures, weak stakeholder management and business models are the leading causes. I had tunnel vision, defined by my position, experience, and capability. These two aspects are highly dependent on human factors compared to technical issues. Which means they are complicated to replace by a thinking machine.
I am not worried or afraid about AI evolving so fast. But I am breaking my head to figure out how well I adapt if there are no such professions as programmers or mechanical engineers.