Skip to main content

Context, Curiosity and Care - a Human Developer's 3 C's over AI

3 C's Humans bring: Curiosity, Care and Context
3 C's: Curiosity, Care and Context

Like surely every team of software engineers in the world, my team has been discussing, exploring, integrating, benefiting from AI over the past year. I am working on a series of posts for the coming weeks, exploring our successes and lessons.

As their manager, I have reassured countless times that their jobs are not in danger, that we need their intelligence, insights and skills to make the best use possible of the new AI power and direct it toward our many system challenges and company goals.

Almost as an aside in our meeting the other day, one team member summarized what the Human Dev brings as: Initiative, Diligence and Wisdom. His almost-throwaway comment in a larger discussion stuck with me and got me thinking.

Today, I want to rephrase and slightly broaden his terms in this reflection. Why are none of the Devs on my team at risk of losing their jobs to AI? Because they bring at least three key traits that the team and the company needs, and that are outside the wheelhouse of AI:

Curiosity, Care and Context.

AI tools absolutely are making amazing contributions to the world of software development. We use them now to review code, write both unit and end to end tests, help turn product requirements into tech specs, manage infrastructure, analyze root causes and more.

We even call some of our AI interfaces Associate team members, spelled AIssociate of course.

As amazing as the pace, quality, capabilities of AI have become, our AIssociate only uses its capabilities in response to goals set by people. It's the humans on the team or in the company that bring the sense of enduring purpose, responsibility, ownership, desired outcomes and consequences.

In short, we bring the Curiosity, Care and Context.

Curiosity

Curiosity, what my team member called Initiative, is the root of the scientific mindset that sees something and reacts by saying "huh, that's interesting / unexpected." It is the drive to explore, to learn, to figure out a puzzle, to make the world a better place.

Software Engineering is a career that is about solving problems. Targeted problems land in the Dev's lap from the company's goals and objectives or from the Product Manager's vision and roadmap.

The traits of Curiosity and Initiative are the ability to identify puzzles within other puzzles, and then seek to solve them.

A developer notices that too many new features need an awkward workaround and asks whether the underlying architecture should change. A QA engineer sees some apparently unrelated issues and suspects that they point to some deeper weakness. Support notices that customers struggle too often with a feature that technically works as designed and starts to question the design itself.

Curiosity overlaps with initiative and intuition in these examples. Most importantly, none of them begins with an assigned ticket or task. It is the very human characteristic to see something that is less than perfect, wonder why or what could be done, and then decide to act on it.

AI tools are super useful once given the task. Have an architectural problem? it can suggest alternatives. Defective data? it can identify patterns. A large volume of customer feedback? it can summarize recurring complaints. 

AI can even be instructed to look proactively for such opportunities. Perform a security analysis to identify weaknesses. And more.

But of course the instruction itself matters. Someone decided that the architecture was worth a rethink, or that those defects might have a hidden connection, or that customer frustration was growing.

Human curiosity is not limited to its own lane, either. It crosses boundaries not just between systems within your architecture, but between external systems. A software engineer realizes that their technical challenge is actually fundamentally a communication problem, or that the most important thing to work on this week is not in the ticketing system at all, leaving a critical blind spot.

This Curiosity, encompassing Initiative and Intuition ultimately provides more than productivity: It offers direction. While AI can dramatically increase the speed at which a team travels, we humans still have an essential role in noticing when the team should start traveling somewhere new.

Care

I would rephrase my team member's word, Diligence, as: Caring whether the job is actually finished. In fact, I would go a step further: it means owning the result, the sense of responsibility to do a job well, all the way to the end.

I want my software engineering team to care enough to have the diligence and follow a problem all the way through to its conclusion. Don't stop with the happy-path; check the edge cases, even the unusual ones that are maybe more of a stretch. Care enough to notice that a test is passing for the wrong reason. Or to verify the deployment with a quick smoke-test rather than merely assuming that a successful pipeline means the release is healthy. Or to take Production events and feeds them back into a continuous improvement cycle.

AI excels at doing large amounts of work quickly. But volume and speed to not equal Diligence and can in fact be the opposite of Care.

An AI tool can produce a reasonable implementation, add accompanying unit tests, handle all the documentation that engineers groan about going. AI can review its own work. Each of these skills and emerging abilities can save us a lot of time. 

Yet someone still needs to ask whether the original requirement was correct, or if the generated tests actually demonstrate the appropriate outcome, or whether an important integration was overlooked. One danger of increasingly capable AI in software development is not that it will do poor work. It is that the AI's work can look so complete that people stop looking closely.

That means our human Care becomes more critically important, not less. AI can perform so much work and so many checks. The human trait of Care means taking responsibility for that work and for what those checks mean.

 

Context

I would expand my team member's word, Wisdom, to Context. With Wisdom, he had in mind the human ability to know what matters; to bring one's intelligence, experiences and lifelong learning to the problem at hand.

Context includes all of that, and extends it to our understanding of the larger world, other systems, company history and institutional memory, competing internal goals and incentives and more.

AI tools have made impressive gains in how they handle their own context scopes and frames. It is a thing of beauty to watch them reach the limits of their context window then reformulate and pack its contents in order to enlarge it.

Yet if you ask a follow up question tomorrow, in a new context window, will it remember and pick up the thread? Depends - did it commit yesterday's lessons to  permanent memory?

As a people-manager, I expect better than this from even my most raw junior employees. I tire easily of repeating myself to them; part of their job is to learn and remember what they learned. The AI tools are not up to even the junior employee level yet in this aspect. 

They may get there, and sooner than I think. They may expand their context windows and their ability to compact and retain such things. But I believe we are still a very long way from their context frame being large enough to answer the Wisdom questions. 

For Wisdom seeks, in the largest possible context of the project, the team, the individual personalities, the company objectives, the client's job to be done, to ask: was this the right thing to do in the first place?

In doing our engineering work, individuals, teams and companies must choose among competing benefits and costs. Some frequent examples: Should we buy or build? deliver the feature quickly or invest in a more sustainable architecture?automate this process, or rely on human judgment here?

AI can bring so much information, so many inputs into these decisions. It can identify trade-offs, find precedents, model scenarios, summarize evidence, and challenge assumptions.

But information is not wisdom.

Wisdom grows from experience distilled from specific contexts. Your Senior Dev will have war stories of when an apparently harmless shortcut blew up and become a long-term headache. Or invested so much time and effort into a beautiful system that no one uses because it failed to solve a meaningful problem. 

The full Context that we humans bring inform those times when two practically identical problems may need different solutions because the customers, people, history, finances, or organizational constraints are different.

Conclusion 

AI can help people explore an idea quickly enough that experimentation becomes inexpensive. It can automate repetitive checks and analyze far more data than a person could. It can bring information and alternatives into a decision.

People provide the larger framework in which those capabilities have meaning. The Context. The Care. The Curiosity.

By taking on more of the mechanical work of software development, AI frees us from the mechanics of building software and allows these human qualities to become more visible and central.

The most valuable engineer of an AI-enabled team will not be the person who can crank out the most or best code the fastest. It will be the person who notices the problem nobody assigned, who makes sure that a job is genuinely complete, and who understands when the technically obvious solution is not actually the right answer.

The cool thing about AI in software development, then, is not that it will replace human effort with machine effort. It is how it shifts human effort toward the parts of engineering where human participation matters most.

Where our Curiosity, Care and Context shine. 

Popular posts from this blog

Trigger Windows Scheduled Task from Remote Computer via Jenkins

One thing I love about working in Information Technology is the opportunity - the NEED - to constantly learn new things. If a week goes by in which I have not looked up something on StackOverflow or other message boards, I start lobbying my team for more challenges. This week, I learned the power of running " SCHTASKS.exe " from a command-line script for a remote server in a Microsoft Windows environment. If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one. Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we ...

Abort a Git Merge or Cherry-Pick

Recently a colleague of mine used the Git Cherry-pick feature to bring one of their commits from one branch of our repository to another. They hit a somewhat complex merge conflict and, in trying to resolve all of the conflicts in the file, they got confused about what needed to be done. They came to see me with the question: can they cancel their cherry-pick and partial merge, and start over? The answer is Yes: it is possible to abort a merge or a cherry-pick Git operation. Most of the time it is not needed; with a little work and human intelligence, the merge conflicts can be resolved without too much trouble. But sometimes, in cases like my colleague faced, a more complex merge winds up confusing the developer, and they want to go back and start over. If you use git from the command-line, it’s as simple as: git cherry-pick --abort or git reset --merge On my team, about a quarter of us use Git from the command line, but most - like my colleague in this story -...

How to do Git Rebase in Eclipse

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here : One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like: The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon). Check out this extreme-case history:  http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time. Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit. Git Rebase offers us 2 benefits over Git Merge: First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For ...

Updating Oracle javapath symlinks on Windows

A Java-based application on my Windows 10 machine recently started prompting me to upgrade my version of Java. Since I wanted to control it myself, I declined the app's offer to upgrade for me, and downloaded and installed the latest Java 8 from Oracle. In my case, Java 1.8.0_171, 64-bit version. The upgrade went fine. But when I launched the app, it again said I needed to upgrade. Why was it still looking at the old location? I made the change using Settings, to change the JAVA_HOME environment variable to point to the location of the new upgrade. But no change, the app still insisted that I needed to upgrade. A little research into the app's execution path showed that it was using c:\ProgramData\Oracle\Java\javapath to find Java. When I looked in that folder, I found symbolic links to my old Java installation. Normally, this hidden bit of information gets updated automatically in the upgrade or installation process. I have read of cases where, when downg...

Git Reset in Eclipse

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.