coding

Coding and AI: Programmer Evolution.

~ Taran ~ 1 Comment

Non technical people may not realize that every bit of software they use, each ‘app’, has it’s own life cycle. It’s called the software development life cycle, and we call it that because the focus is not on the software but on the business model that supports it.

There are some that argue that Agile programming has made the software development life cycle antiquated or even obsolete, but I believe that they have that wrong because Agile Programming is just a different approach to the software development life cycle.

Software is developed based on need, or expected need. It is planned based on requirements given by someone – generally the person who is funding the project – and developed and eventually maintained. Most software developers spend their time maintaining existing projects rather than creating that ‘killer app’ that just about every developer wishes to do.

Eventually, the software becomes obsolete for some reason, and generally speaking it means it’s making less money than it costs to support it. Free Software and Open Source software defy obsolescence because it’s generally about interest.

Artificial intelligence isn’t going to end life cycles, or programming. In fact, it’s just changing the face of programming because when you write a prompt, you’re really… programming. Programming has evolved from the lower level languages where we flipped ones and zeroes to increasingly higher level languages so that more people could program. Software development has constantly evolved and artificial intelligence is not that different.

What is kind of interesting is potentially being able to throw away some of these high level programming languages and replace them with lower level programming languages (that tend to be more efficient for a computing device to run) and just have a large language model write the code.

Regardless, people who write code will need to evolve. When I started out decades ago, a single person could write a game or application, then the needs became more complex and software development became increasingly social and multidisciplinary – and even specialized. Coders simply have to adapt again to writing better prompts – which also means better communication skills with those who want the code in the first place, as flawed as their requirements generally are.

Even as people write about the artificial intelligence life cycles, the core concepts aren’t different. In fact, for someone who has experience with software processes (not just one life cycle), it looks pretty much the same.

Coding For Fun.

~ Taran ~ Leave a comment

Here I am, waiting for the errant landlord to show up at 7 a.m. when it’s now 8 a.m. (where is he? Who knows), to fix a breaker issue, when… suddenly… I think of something to code – not that I was looking anymore, but probably exactly because I wasn’t looking anymore.

It’s an exercise, I suppose – an idea – and following it up in Python is probably going to be more interesting than anything else you can do when stuck at home. In Trinidad and Tobago, if you have human dependencies, you’re pretty much stuck waiting on someone who is waiting on someone who is – well, you get the point.

And so – Python on Windows reinstalling; Anaconda of course (because you found this entry, I fully expect you can find Anaconda and the installation documentation).

Now, here’s the thing. Unlike when I was running my own company, and unlike when I was working for other companies, there’s no race. There’s no need for me to worry about whether or not a competitor will get to it in time, and whether they can do it better, or what have you.

And oddly, it allows me to leverage some pre-existing code I’d been working on. You’ll note I didn’t say re-use – that code reuse thing is a trap, much as using code from Stack Overflow can be for plug and pray ‘coders’.

Anyway, back to a little coding fun again after about a year without, nose firmly thumbed at corporate coding.

The Study Of What Others Do.

~ Taran ~ Leave a comment

Taran Rampersad
Courtesy Mark Lyndersay, LyndersayDigital

I hate having my picture taken. Over the years, I have found the best defense from cameras is to hold one. This has weakened in a day and age where every phone has a camera, and everyone wants to be seen with someone – but Mark Lyndersay needed a picture of me for TechNewsTT, where the majority of my writing has been published this year outside of my own websites.

In going to his studio, it was a rare glimpse for me into the world of professional photography. It was clear to me almost immediately, this amateur photographer, that it would take me at least a decade to do the editing I watched Mark do quickly, about how he managed his photos, and about why he did the things he did  – a matter of simple experience that cannot be replaced with meetings and requirements discovery.

You see, I had been thinking of writing my own photo management software in Python – something to automate a lot of things. I had briefly considered this when I had begun selling some of my prints in Florida, and it was latent in my mind as a project to ‘get to’. In conversation with Sarita Rampersad, another professional photographer (unrelated), I had asked her what she used last year and why. It was clear that it would take more than a passing effort on my part to build something more useful than the tools she was using. The visit to Mark’s studio underlined this.

The Roots.

Reflecting on this on the way home, I went back to the very core of how I started working with technology. From an early age, I was encouraged – by rote and by whip, as it were – to observe what was being done to understand how it was being done. This was the root of the family business, the now gone Rampersad’s Electrical Engineering, a company that was built on fixing industrial electro-mechanical equipment with clients ranging from the U.S. Navy to someone who just needed their water pump repaired (Even WASA).

This background served me well over the years, and understandably frustrated managers and CEOs. Knowing the context of how things were used allowed for for useful processes and code; it allowed for things to become more efficient and allowed things to be written to last instead of a constant evolution of, “Wouldn’t it be nice if?”. In a world of agile processes, the closest thing to this is the DevOps iteration of Agile which even people who practice Agile haven’t heard of (because they are soundly in the Agile Cave).

DevOps is a form of Agile where every stakeholder is directly involved. And that, to me, is also a problem because of the implicit hierarchies and office (if only office) politics is involved. It’s a bleeding mess of tissue to sew together to form a frankensystem, but at least that frankensystem is closer to what people actually need. Assuming, of course, they understand what they need.

To me, it boils down to studying what other people do.

Observe, Analyze, Communicate, Build.

When I started as an ‘apprentice’ programmer, this was drilled into me by an Uncle who was a Systems Analyst, and ‘allowed’ me to write the code for projects that he was working on. He didn’t boil it down to observe, analyze, communicate and build; I refined that myself over the course of the years.

No matter the process, it all boils down to someone able to bridge how people work/play to get something done to understand what is needed, and how to make their lives easier through automation and information structure. Observing people do their jobs is important, analyzing it secondary, but the most important part is the one thing that an AI cannot yet do: Communicate, the process of listening, speaking (or writing, or…), and then feedback. This process is most important. In priority of importance, software engineering and I believe any form of process or structural engineering is:

  1. Communication
  2. Observation
  3. Analysis
  4. Build

This is not the order in which things are done, of course, but the emphasis that is most important in understanding how present systems work and how future systems should work.

So often over the years, I’ve seen software engineers relegated to the role of code monkeys with emphasis only on ‘Build’, when the most important parts are about ‘building what is needed’. This is where business analysts got introduced somewhere along the way, but they too are put into silos. This is underlined by HR departments focusing only on the ability to ‘build’, where analysts are expected to be a different sort of role. When these roles were split, I cannot say, but to be both is something that is too large and round to fit in small square holes of the modern enterprise.

It is lost, eroded, and there is a part of me that wonders if this is a good thing. Studying what other people do has allowed me to do so many things within and without technology, and it worries me that in a future where AI will be taking over the ‘Build’ that software engineers aren’t being required to focus more on the soft skills that they will need in the coming years.

Sure, the AI can build it – but is ‘it’ what needs to be built?

The Coding Precarity

~ Taran ~ 5 Comments

Decoding Alan TuringThere’s a brave new world coming, and it’s something I’ve been considering for the past few years. As artificial intelligence begins writing more and more code, and troubleshooting it, the women and men who have made their money speaking to machines are slowly joining the precariat.

It’s not a bad thing or a good thing. It’s not a matter of the sky falling. It’s a simple reality that the precariat needs to consider and find a way past.

Coding is a part of the Software Engineering discipline – wherever it actually exists as a discipline. Coding, on the other hand, is not the entirety of Software Engineering despite what the market appears to think.

HR departments all over the world are trying to fill what are really glorified code monkey positions. And that’s not the future of Software Engineering as I see it, or as circumspection will show. We’re seeing more and more code generated by AIs, and really, if you actually

It’s going to be about ‘soft skills‘. It’s going to be about getting the right requirements to hand off to the coders, because the coders in time are less and less likely  to be human. It’s going to be about interacting with the people in dealing with what they want and making sure that they get what they want.

Of course, wanting what they actually need is something that they still need to get better at.