Grieving Software Engineering Complexity

When, after I spend months learning how to manually manage memory in Objective C, Apple released ARC update, I felt happy and crushed at the same time.

It was a relief to stop chasing random memory leaks after major overhauls. That time could be now spend improving the actual visible application.

But there was a ping of disappointment. I finally mastered the memory management. The crushes were dropping dramatically and when leaks did occur, I could locate them quite easily. That skill was now useless.

My career resulted in a collection of useless skills. Knowing how to create responsive UI on blackberry with nothing but few Java code lines, figuring out how to write sync server for offline updates, developing weighted document keyword search - to name just a few. I am sure any engineer who was around long enough have their own lists.

And I think this explains AI use paradox: while some engineers actively refuse to use code assistants, others make the usage their daily habit.

The pride of knowing how to do something quite difficult makes simplification of that effort feel like cheating, devaluing, making less then. If it’s easy, then what’s the value of the skill? If you giving out control to a machine, then what’s your real contribution?

A very small subset of engineers still write code in assembly - but there were times when all code was machine code; and arrival of compilers was met with a pushback and criticism. Similar arguments were brought out when interpreted languages entered the scene. Too slow, too unreliable, unnecessary, producing poor quality product.

AI is different because it affects every aspect of software development and brings up the question - what does it mean to be a skilled software developer?

If we are honest, most of the work of the past decade (outside of rare truly innovative companies) resembled a fancy factory job of creating CRUD apps, weaving together APIs and copying code from Stack Overflow posts. That’s because most pressing problems on how to make something had been solved, improved and automated.

Back in early 2000, not only you had to write your own libraries to parse a file, but even installing open source packages were painful exercises in patience and reading extensive documentation.

The usual answer - ‘I am good at software engineering because I can code in X language, create this type of app and fix bugs’ - no longer applies cleanly. But to discover our new identity, we have to get out of comfortable shell and do something many forgot or never got a chance to learn. We need to walk out of the factory and find a new destination and problems to solve.

Problems that do not have already written code to copy/paste.

The world needs much more software then it currently has (and frankly, some of the existing software is atrocious and we should throw it away and start over).

THe time I spend on writing the sync server was never about the code but figuring out and building something that did not exist before.

The days of writing proverbial assembly code at the factory are going away, but the time to find new horizons is just arriving.