TL;DR: AI made the coding part of software fast, and that speed didn’t create chaos so much as expose where your organization was already slow: the hand-offs between teams. The fix isn’t a better tool, it’s better wiring. We rewired Dev and Ops once already and called it DevOps. The next wall, between business and engineering, is coming down the same way. Here’s how to see it, and one thing you can do tomorrow.
TL;DR: The best “prompt engineering” technique isn’t engineering at all—it’s delegation. Transfer intent, not instructions. For quick tasks, tell the AI what success looks like and why (the Intent Prompt). For complex work, equip it with context, deliverables, and decision principles so it can navigate on its own (the Delegation Brief). You already have these skills. This post helps you apply them to AI.
According to media pundits, software stocks are “crashing”, and there’s a “SaaSpocalypse” going on. Recently, Noah Smith wrote about “The Fall of the Nerds,” painting a picture of software engineers as the new master weavers: skilled artisans about to be displaced by AI-powered looms. Meanwhile, I’m…
A few days ago, I had a conversation with a former colleague who interviewed for a new job because she couldn’t stand her current one. Getting a new offer made her feel relieved and optimistic again: She had escaped.
Many others may not be so lucky this year.
Tech layoffs are accelerating. The economy—if we’re honest and look past the AI boom—looks shaky. Gold prices are spiking, which historically signals uncertainty ahead. And if you’re reading this feeling worried about your job, your future, or the general state of things, I know well how you feel.
Over 27 years and five major crises, I’ve learned one thing: the difference between thriving and drowning isn’t luck—it’s knowing what you can change and what you can’t.
It’s December 2024. I’m at AWS re:Invent in Las Vegas, coaching speakers on how to communicate effectively with technical audiences. Meanwhile, 9,258 kilometers away in Munich, a room full of homeowners is debating whether my 7.6-kilogram solar panels will blow off my balcony in the wind. This story…
154 months of building solutions at AWS taught me something unexpected: the most resilient professionals are people who can build cloud architecture, debug a cultural problem, coach a group of executives, mentor a struggling colleague, and learn something entirely new by Thursday. Think Robert Heinl…
I’m a big fan of Cal Newport and his books. Currently, I’m reading his latest one: “A World Without Email”
Every email comes at a small cognitive cost to the sender, and a small cognitive cost to the recipient. It has become easier than ever to “just send an email”, instead of diving deeper, solving the issue, or using a more appropriate, more efficient, or less stressful way of communication. Multiplied by the amount of companies, employees, emails per employee, the wasted time and cognitive cost of (over)using email for everything has become enormous. And instant messaging only amplifies the problem again.
I’ve become very good at filtering and processing email over the last years. But this is just trying to solve the receiving end of the problem. Now I’m curious about learning ways to fix the problem at the source. Not just for me, but for my colleagues, too.
A while ago, I argued that the world of IT is changing, and that change is good. And that as a result of change, many people would need to change their jobs.
Well, I did it. Last Tuesday was my last working day at Oracle.
The universe is change; our life is what our thoughts make it. (Marcus Aurelius)
If you have a job in IT (and who among my readers hasn’t?), then it is going to fundamentally change soon.
Why?
In my own job, I see the full spectrum from where IT innovation is created to the very last laggards who are still depending a lot on mainframes and other ancient technology. Some things in IT are new (like, every week there’s a new startup/technology/trend that is shaking up the industry), and some things are just repetitions of stuff that has happened before, albeit in slightly different colors.
So now, the world of IT as we know it is changing (again) and this time, change will impact organizations, roles and jobs.
Let’s dive a little bit into what’s happening. Don’t worry, change is good, but only if you prepare for it.
If I had to formulate in one sentence what my job and that of my teammates is, I’d say something like:
“To show our customers the business value of Oracle’s Engineered Systems”
Because at the end of the day, customers pay real money only if there’s some real value they see in a solution.
And that is the problem most people in IT struggle with: How is what you do in IT related to your company’s total value chain?
Most of the time, people, both those working in IT and those selling and supporting into IT departments are consumed with functions and features, tech specs, standards and other tech stuff. Worse yet: Some people look at Oracle’s Engineered Systems like Exadata and Exalogic and they only see a bunch of servers in a rack, because all they know is components, servers, tech stuff.
This is dangerous terrain: Because if you can’t show the business value of your IT to your company, you’re going to be put on the list of cost centers to be squeezed, and budget cuts are never a good motivator for your job.
So what is the value of IT to the business? Or more specifically, what is the value of Engineered Systems for our customers’ businesses?
After having gone through TOGAF training and certification, I’ve now caught the Enterprise Architecture bug, as you can probably tell by this article. It is a really neat way to add structure to the IT development process and to better understand what it really means to solve business problems with IT.
One of the first things TOGAF recommends architects do when establishing an Enterprise Architecture practice within a company is to formulate Architecture Principles that guide the development of solutions. During the last few workshops and during some discussions with other architects, three principles in particular struck me as being key to successfully developing a Cloud solution:
Recently, I attended a customer workshop where the customer declared that they standardized on x86, VMware and Linux.
That got me and my colleague thinking about what standardization really means and whether that actually makes sense.
The workshop was actually about defining a PaaS platform for the customer, and early in the process they just said: Fine, but it’s gonna be x86, VMware and Linux, because that’s our standard. WTF?
One of the first things that customers and sales teams realize when dealing with Engineered Systems is: They fundamentally change the IT architecture of a business.
Change is good, it means progress. But change is sometimes seen as a bad thing: Change comes with fear.
The truth is that Engineered Systems really empower IT architects to add value to their business, application and data architectures, without worrying about the technology architecture.
To understand this, we need to dig a bit deeper into Enterprise Architecture, specifically the TOGAF flavor of it.
I changed into a new role at Oracle: I now work for the EMEA Engineered Systems Architecture Team (ESAT). We support Oracle’s EMEA Engineered Systems business by engaging with customers, enabling our field organization with trainings and through evangelization.
You can call me biased towards Engineered Systems (no link, page no longer exists) now, but that would be like accusing a Mac fanboy of suffering from the Stockholm Syndrome, when it’s actually the other way round.
The other side of the “biased” medal really is that I have a choice of where I want to work, and one of the reasons I changed from my cozy SPARC/Solaris Technology camp to the Engineered Systems crowd is: I believe the world of IT is changing.
Let me explain.
Over time, you tend to learn a Solaris performance trick or two. Or three. Or more. That’s cool, it’s how stuff works: You learn, you do, you remember.
Performance analysis and tuning is just like that: You learn a trick from a person that is more senior than you are, you apply it, you feel like a hero, you learn the next trick.
But having a bag of tricks is not enough. Because then you start trying out stuff without a system, and spend useless time hunting that problem with a hit-and-miss approach, gut-based only.
Therefore, I’m always glad to listen to Ulrich Gräf when he does one of his famous performance tuning workshops (if you’re lucky, you can catch Uli blogging in German here (no link, sun.com no longer exists)), because he’ll give you the full view, the context and the system too, when it comes to performance analysis.
So here’s my personal cheat sheet for Oracle Solaris Performance Analysis, including some guideance on how to systematically catch that elusive bottleneck.
Lots of speculation about Solaris and OpenSolaris is happening right now, with an allegedly leaked email being the latest generator of buzz, rumors and troll-ism.
But is that any useful? No.
So let’s cut through the shiitake, do some due diligence and focus on some real facts instead.
In this article, we’ll check out some real and authoritative sources of Solaris direction, mainly John Fowler’s recent webcast about Solaris 11. Then we’ll see what our future opportunities as members of the Solaris community are, and close with some pointers to other opinions on Solaris 11.
Ever since Oracle announced that they’ll buy Sun (no link, page no longer exists), there has been a lot of discussion about the future (some would say “fate”) of OpenSolaris in the “community”.
In fact, the last 15 months have been very instructive in terms of how communities work, or how they don’t.
Let’s check out what a community is supposed to do, and what it is not supposed to do, in the light of the latest OpenSolaris announcement: Illumos.
War is waging in the galaxy. This time it’s not the Rebels against the Empire, or Good vs. Evil.
No, this war is different, and it has been going on ever since products designs companies entities existed.
What I mean is the war between Quality and Popularity.
Let me explain:
(Drumroll, Roman fanfare, then dramatic Anime action trailer a la Mortal Kombat, etc.)
As of May 21st, Google officially declared war on the Apple iPhone.
Sure, there was some teasing here and there for weeks, if not months, but this is serious.