If they understood the problem, they wouldn't be hiring you,
they'd have fixed it themselves. Simple is complicated enough,
especially at scale. There's a lot of people trying
to adopt new technology just for the sake of it, and that is
something that a good engineer doesn't do.
The good architects are usually the ones where magically
everything goes well and nobody knows exactly why.
What is your advice for people that really want to become great
software engineers? What do they need to do?
What is your advice for people that really want to become great
software engineers? What do they need to do?
Increase your breadth. There's a lot of focus on the
depth early on in your career, which is important, and there's
an advice that perpetuates which says focus, true focus.
But at the same time don't dismiss everything else that's
happening. Increase your breadth.
Personally, I optimised one thing that really got me far,
which is having the ability to learn effectively in very short
periods of time. And that's why whenever I tackle
a problem, I don't have a problem digging really deep into
anything UI encounter from quantum mechanics all the way to
any technical problem that I face on a day-to-day basis.
I'm a, you know, I'm a university dropout.
I never finished my computer science education, but that did
not deter me from picking up that education myself and really
digging deep into all sorts of theoretical topics, but also
practical areas and topics. And I'm a perpetual learner.
So in my opinion, the next phase where we're heading, it's going
to require people to be able to learn really fast, get out of
their comfort zone really fast, dig deep really fast, and attain
high levels of functional proficiency in any new area.
And then attaining mastery is not always required in
everything. So just pick a few topics where
you attain mastery in but also increase your breadth.
And if we are talking about the skills that are for the future,
you're saying technology accelerates quite quickly.
What are some of the skills that you think people should focus on
specifically for their career but also for like peace of
fulfilment and looking towards the future?
The ability to learn first and foremost.
None of the tools I work with I I learned I learned SPSS people
back in the day, some some people in the audience will be
cringing right now. SPSS taught myself R to scrape
Twitter back before it became shitter to to model the 2013
fourteen Syrian refugee crisis. I hated Putin before I knew
where Ukraine was on the map, but from our I went into Python
And now Python is the end all be all.
But I'm from an era where people were still asking like Are you
sure? Should you be learning SAS?
Because SAS is better in the market right now.
So God knows what we'll be using in 10 in 10 years.
Unless all the all the LLM start over fitting on on just
languages that are already in use.
We might actually see a stagnation in the development,
in the development of coding languages now, since Claude and
Gemini will not be able to adopt to new languages as much as
produce more Java horrors, meaning we will be stuck with
Java until the he death of the universe, I'm pretty sure.
But what I'm trying to show here is that those tools, those
techniques, cloud platforms, they change so fast that you
can't focus on learning a technique.
You got to learn a method to learn new stuff.
That is the most single and most important skill in the entire
tech field to be able to learn, not even master, but just work
with new tech. Anytime I have a new project, oh
God, it's a new cloud platform I haven't worked with.
OK, well AWS, Google, Azure, I'm pretty sure it has most of the
same functionalities. They they just call every damn
button differently and that's how they vendor lock.
So, so you can't go go to the other cloud platform because the
names is different, which is less of a hurdle than you would
think. And then there's of course
nuance, like the billing models are different, the scaling is
different. The, the, the type of servers
you can run it in is different. You cannot local host, I mean
sovereign this this version. Remember that people sovereignty
is the new local host. You're just running your own
damn model on your own damn computer.
But you don't call it local host you you call it sovereign.
The client will love it, thank me later.
So it's the and that's the other thing.
And I mentioned that before understanding the words because
buzzwords will come, but they usually mean something that
wasn't new at all. Again, sovereignty is just local
host but new. Everybody screams as as was
screaming AI, but we mainly meant just deep learning on
steroids with a lot a lot of GPU and compute.
Big data was just data that you store on multiple different
servers because you don't have a single server that can contain
it all. But nowadays my laptop has more
storage than a whole complex of servers a decade ago.
Big data is dead. Long live big data.
The core problem here is the core problem of humanity, which
is that sometimes we say the same words but we mean different
things, and sometimes we say different words but we mean the
same thing. And all of miscommunication
stems from this. And in our field, it is
important to figure out not just what words people are using,
which is what sales heavily focuses on, but what their
actual problem is and what they actually mean, which can be,
which can be completely different from the words they're
actually using. Because I've had clients that
that ask for AI and it can mean a random tree, a random forest,
It can mean you have some kind of image recognition model.
It can mean some type of speech synthesis.
It can mean producing synthetic data of bananas using 3D models.
It can mean so many different things, but they all use the
same word and it's our job to figure out what the heck they
want and then to build that. Not just to receive orders and
build something, because that job will be outsourced and
automated to hell him back by whatever cloud copilot thing
they they buy and or consume. But the core skill to figure out
what the fluff they actually want and need and what is the
problem behind the problem. Because if they understood the
problem, they wouldn't be hiring you, they'd have fixed it
themselves. But they do not understand the
problem, do not understand the solution.
It's our job to figure out that solution, then do that.
And to do that we need to be able to learn new tech and learn
new stuff. And that's why learning is key.
What have you seen in how architects execute that makes
them really good architects for the people that actually go on
that career path? Yeah, I always say, I mean,
first comment would be it's not a sort of binary choice or I
don't think that being an architect is determined by
what's on your business card. So I think you can be a
technical product person with a very architecture mindset, right
for me. Well, let me start the other way
around. The the bad architects are
easier to spot. The good architects are usually
the ones where magically everything goes well and nobody
knows exactly why the bad architects are easier to spot.
And it's like people who spew out a lot of buzzwords, you
know, it's like, oh, everything must be cloud native or loosely
coupled. Now I don't need an architect to
tell me that. I can just put a poster on the
wall. And then why?
Why do I need this? This person or people who
believe they should have all the decision power.
It's like, oh developers, I'm here to guide you.
You should make 3 components, right?
No more, no less. And those I find the not so
stellar architects, the mantra that we have in the workshop and
that I, that I very much follow is that architects shouldn't try
to be the smartest people, but they should make everybody else
smarter. All right, that's an amplifier.
You don't want to be a kind of Oracle.
When people come with the questions and look for magic
answers, Oh, what should we do? People come to me, right?
And I'm like, well, it's kind of charming, but how, how do I know
it's your project? It's your application, right?
How can I make all the decisions for you?
But what I can do is help you make a, a better decision.
And I think to me, that is one of the characteristics of a, of
a great architect. You can absorb the context,
things that people explain to you, but you can uncover blind
spots or maybe help people see different points of view,
different angles, distilled trade-offs that they might be
implicitly making, but they're not aware of those kind of
examples. I think that makes a great
architect and it makes a nice architect if you wish, because
you're not trying to be the the ivory tower big boss, but he
actually an amplifier to the team.
Any other foundations or fundamentals you want to
highlight that distinguishes great engineers from not so
great ones? If I look at what is happening
in, in, in picnic context again, what what really strikes me is
that our our engineering culture is relatively uniform in the
sense that we started only 10 years ago.
We have a very strong developer platform that was developed from
the get go. And there, what I see in some
other companies and other contexts is that there's a lot
of people trying to adopt new technology just for the sake of
it. And that is something that I
feel that a good engineer doesn't do right.
So if you adopt new technology, if you find out about a new
technology, you need to understand whether it's actually
an improvement of what you have. Make very clear also why that is
the case and not just jump on any, any bandwagon.
And that's something that I feel that very good engineers are
good at, right? So they there's this sites, I'm
not sure if you know it, the boring technology dot COP.
I don't know it, but that sounds really funny.
Yeah, yeah. Which sort of advocates for use
what works, use what is proven use and then use it in a very
effective way. As you mentioned that that is I
think what what good engineers do and discerning between OK,
but what new technology is that interesting to jump onto
etcetera. And that is super hard, of
course, and also maybe a bit more of an art than than a
science sometimes. But it's precisely that's kind
of gut feeling, I would say that's that that knowledge, that
wisdom that you have as a, as a, as a Craftsman, as an engineer,
that sets you apart from people who, yeah, who don't have that
taste or who don't have that knowledge to, to make a good
decision. And then sometimes you end up in
situations where there's companies that are much smaller
than than the company I work at that have like dozens of
different technology stacks because, well, people decided
that in some kind of context, it was better to use Rust or to use
Go or to. And then you end up with this
fantastic collection of technologies that nobody really
knows how to manage anymore, really know how to, how to
operate anymore, really knows how to, how to bring this
together. And yeah, that's, I think one of
the hallmarks to come back to your question of a good engineer
is to actually also limit this and, and, and, and stick to,
yeah, proven things and what works.
Yeah. Is this then your advice as
well? So to stick with what you have,
start with the initial design that is simple and then stick
with it until you actually reach certain limits and you can kind
of based on your usage, forecast what the next.
Iteration would precisely if I was a start up founder or acto
of a start up right? I would never go and start
building for 100 X scale. Even if I'm like a firm believer
in my idea and know that it's going to reach the masses and
it's going to be global. I would never design for that.
I would design for getting 100 users or maybe even 1000, right?
And I would just run everything on a single VM, to be honest.
Maybe 2, make it a bit more available.
I would not go and build massive database clusters.
Just start with one, maybe 2 nodes tops.
Replication, that's it. And this will like carry you
really, really far. To be honest, once I attain or
I'm get, I'm like close to 80% of these limits of what my
resources can do. And by the way, vertical scaling
can take you a long way. Like you have no idea.
We have my SQL nodes that have hundreds of CP us on them.
So you don't really need to go and start sharding and doing all
sorts of fancy stuff when vertical scaling can still carry
you. And right now with cloud native
solutions, you can go pretty far.
Like you can get a one VM with 120 CP cores, right?
You can get terabytes of memory, Yeah.
And that can do a lot for you. You don't need to start doing
horizontal scaling before you get you really start hitting
these limits. That's what I've seen where it's
challenging for people, where they say OK, I'm a little bit of
a perfectionist. I value quality in what I do on
a day-to-day. My job is basically part of who
I am. And if I don't deliver the
highest quality that I can in this aspect, like I'm doing
myself with this justice. And it's very like, if I lay it
out like that, it might sound selfish, but those people have
no clue that what they're saying is selfish.
They genuinely think it's best for the organization.
There's just some misinformation and misunderstanding.
Because there's a dogmatic aspect of software engineering
and it was perpetuated in the previous era into two thousands.
2000 I when I ventured in working professionals of Engine
2007 8-9, there was a lot of dogma.
Like there's a lot of this is how you do things and this is
how you should do things. And if you do things any other
way, you're wrong. And part of that is elegance of
code, code cleanliness, code quality.
You're all raised on this, these these concepts, right?
And they're important. And everybody always complained
about bad code and horrible code because it was difficult to
maintain. Nobody enjoys that.
You're going to make it very difficult for the future
engineers to solve these problems.
But sometimes, you know, you don't have future engineers to
solve these problems. Sometimes nobody's going to
touch this code for decades to come.
It's OK if it's just, it just works.
And then we ended up on the complete other end of the
spectrum where we tried to clean up everything that we started
adopting all sorts of design overcomplicated abstractions
that are are just horrible to read, horrible to reason about.
It takes you decades to become proficient in just reading that
type of code. And then when you write it, it
gets even more complicated and it's very difficult to maintain.
And big tech and I always tell my colleagues and the juniors
that report to me, simple is complicated enough, especially
at scale. So just write it in the dumbest,
most simple way possible. This is why I also love Go, for
example as a language. Right.
It's amazing. It's dumb.
You don't have to think too much, it's just all in your
face. Whenever you want to understand
how something is built, just trace it around.
It's there. It's there, fantastic.
I love that. And when the situations where
we're building at scale, I don't want to reason about
abstractions, I don't want to think about edge cases, I don't
want to think about complicated memory allocations and
complicated memory structures. You know, I just want things to
be simple. Memory leaks happen often and
they are very catastrophic at scale.
I don't want to think about these things.
I don't want to think about how my garbage collector is going
to, you know, shut down the whole world and start causing
multi second latency on my API requests, which at scale again,
become a gigantic problem for me.
I just want things to be simple, easy to reason about and that's
it. What is then your perspective on
building systems that can evolve?
Because some people you can say, OK, this is the system designed
that we have and we're going to continue on this until we reach
a certain level of scale, and then we're going to revamp and
say this would be the next iteration.
But some people also say, OK, we have a system now and this is
evolvable to whatever skill we need.
And then they put in the extra effort to make sure that that is
there from the beginning. In our industry, very few
technologies last for like a decade plus and the rest is
changing often and that's why I personally don't invest or I
wouldn't design a solution that will last like 1020, thirty
years, unlike what we did in the 80s or 90s.
That's why that's how they that was the design mentality.
But things were way less complicated than they are today
and the scale was different. So I would always come with the
mindset that I'm just going to design for the next order of
magnitude and then I'm going to evolve it from there.
And that's going to require another round of investment.
There's going to be continual investments in this and that.
Business people are not going to love this because that makes
accounting much harder. That makes strategic finance
much harder because they cannot predict or anticipate the costs
that might come in the future. They cannot extrapolate from
today. You know they don't like this
fuzziness. Of software, it's all risk.
Yes. So and, and also like they
cannot calculate like their bottom line or projections for
the future, which are things that are very realistic.
Like public, publicly traded companies want to be able to do
these projections and they want to be able to say that, hey,
we're not going to be spending more here in on evolving our
software, but we're going to make much more revenue and
increase our bottom line and margin.
That's what businesses look for. So it's understandable.
But from a software perspective, there's needs to be regular
investments. And I think the only
approachable way, which is something we do at GitHub is to
continuously revisit these investments on a quarterly by
quarterly, half a year or a year basis, right?
We can make projections for the next 3-4, five years, but the
confidence in these projections is less and less and less the
more time grows and I think a lot more companies need to start
doing the same. We're always working in teams.
Also from a business standpoint, how would I, for example, say
we're going to design for this until we reach scale and then
we're going to need to revamp? And this is what that's going to
entail for people that don't understand how to build
software. Understand the business
constraints. So you're never going to be able
to convince the business folks about of something technically.
They're just. It's too abstract.
Even if it feels too intuitive for us, for them it's.
Magic. Yeah.
And even if they try to understand how things work,
they're never going to comprehend the magnitude of
problems and they're never going to have have this intuition
about how software is and how not hard, you know how how
evolvable it is. So it's our job to get closer to
their side. Some people say, no, we want the
business to understand they're not gonna it's trickier.
It's easier for you to acquire or assimilate some of the not
everything, some of the business constraints and discuss them
from that perspective. And that's why a lot of
engineers who grow are very good at understanding the business
constraints and then discussing the technical solutions within
those constraints. So for example, I used to work
in the container terminal industry for a while.
We built a huge container terminal.
We furnished everything from the fibre optics layer all the way
to the three tier data centre with all of the enterprise
applications running, running on it and the operating system for
the container terminal. And it's one of the most massive
operations you can ever imagine, one of the most hazardous as
well. So the folks there, they're as
far away from tech as possible. You're not never going to find
the terminal operator who's going to understand what it
means that your database is running hot and you cannot
support their keys. All they care about is, I have a
ship here who's docked. There's like 10,000 containers
on it. I need to empty them into my
yard. I have a very fixed window of
time and if I don't do it in that window of time, this is
going to cost me money. We were operating at 12%
capacity. That terminal was generating
about $50,000 per hour, so 12%. So you can imagine if we get
delayed, every minute of delay is actually money that's
disappearing. So this is how you need to
discuss problems with and and investments and solutions.
You need to understand what the impact is, what the impact is on
the operators. And sometimes it's life
threatening impact, right, If your software fails when ASTS,
when the crane is offloading a container, this can be a very
life threatening situation. You cannot really have your
software malfunction at these points.
So snappiness of the software, sub millisecond latencies, all
of these things matter, right? So you need to approach the
discussions with the stakeholders by understanding
them first. So what I've done for example,
in that industry is I've literally sat on a truck and
went there and I sat with every single individual who works in
that terminal to really understand what they go through
on a daily basis. So a truck driver who's driving
a truck for a six 7-8 hours and it was in Saudi Arabia in
scorching heat is not going to understand why the button that
they clicked is just is so slow. Doesn't matter.
Doesn't he doesn't care, right? He just wants it to just work.
So you got to understand all of these perspectives and then when
you do, you can start approaching discussions from
that vantage point. And this applies to banks, this
applies to hospitals, to any other industry.
So understand the industry, understand the business
constraints, and then any technical solution you want to
discuss an investment, you can approach it from that vantage
point and you're going to have much more success in these
conversations. When you were speaking about
hard skills, how much of enterprise architecture or being
an architect in essence has changed nowadays?
Because I feel like I get bombarded with tools.
There's a lot more possible, specifically with large language
models, but in essence, like the Phantom sketch Artist,
everything underneath kind of still holds true.
From your perspective, does architecture evolve quickly?
Because I feel like tooling does at a more rapid.
Pace, definitely the environment in which you operate has
changed. So there's a couple of
assumptions that architects used to be able to make to make their
lives easier that no longer hold right.
And the one is like snapshotting, like the world is
moving too fast to be able to pretend.
It's like, OK, let's just assume nothing changes.
Well, that turns out to be a very poor assumption in today's
environment. So that, for example, means
exercises like trying to draw a giant ID landscape, you know, or
cataloguing all the applications you have and putting that into
some tools. Taking a few months for that,
yeah. And then a few months, by the
time you're done, this has already changed.
So for me, the assumption of being able to snapshot and
being, I call this the cartographer, being the person
who makes all the great landscapes, that is very useful,
but it's no longer practical because stuff changes too
quickly. So one of the metaphors I use
which captures the change in role for Enterprise Architects
is rather than trying to be the cartographer who walks around
with a giant map of all the pieces, you need to be much more
like a scout. You have a objective in mind.
You want to cross the river or beat the enemy or like move
somewhere or like whatever, right?
You have some objective, you send some scouts, right?
They're going to go look at things.
They figure out what works, what won't work, right?
And they come back to you with a very simple map, but a very
timely and very expressive map, right?
So you want to cross the river. It's like, oh, here's the
mountain, here's the enemy, the bridge is gone, but here's not
so deep. We can cross there, we can go
around whatever it is, right? But they have a very
situational, they have a sort of purpose driven map.
The map is not trying to be like the perfect map of all the exact
landscape. They only depict what's it's
relevant to your move and I think that is becoming a more
viable metaphor. What enterprise architects
should do. It's no longer plausible to like
maintain this giant map where everything is on and everything
is up to date. Rather you need to have a
purpose. You need to have a direction of
mind. Like LLMS Gen.
EI is a great example. I don't get de enterprise
architects, what's our strategy for this?
Where should we find the best first use cases?
How do we integrate this with the rest of our system?
We know LMS have super high rate of evolution, right?
So how do we keep that change out of other systems, right?
What are we doing with with Agents and Agentec, right?
Is that just another form of workflow integration or is that
something novel, right? Give me a point of view.
But it's very purpose driven. And as you will quickly see, you
can only do that if you understand the subject matter,
right? You can sort of arm wave your
way through that, right? You need to have, you know, the
hard tech skills as well. But for me, it's very purpose
driven. What should we do?
Do we have a point of view, right?
Do we have a question in mind? Too many architects try to find
answers when they don't have a question.
And so it's like, oh, here's the thing that answers all possible
questions. I'm like, that would be nice.
Wouldn't that be, wouldn't that be easy?
That doesn't work anymore. You got to start with a question
in your mind. And then like the scout, I was
like, whatever, can we cross the river?
I was OK, come back with the answer to this.
It's got to be situational and timely.
Otherwise it becomes hard work. And we might like our hard work,
but I always say we're not a museum.
We're the IT you. Can't be a historian, yeah.
Exactly. We can't be a historian.
We're not collecting modern art, right?
Our diagrams serve a purpose, right?
They help us make better decisions, get a better
decision, Transparency and discipline.
So a the decision is is clearer and everybody's on the same page
to what the decision was actually what drove the
decision. What trade-offs are we willing
to make? That's what adding the value and
that the picture just has to be a means to that end.
If that end isn't there, the pictures also worthless.
Then it just becomes modern arts and boxes and triangles and kind
of kind of things. From a career perspective,
people are saying very early on, topics are getting automated now
by agents, which means that the people that are educating
themselves and that usually that's a step for them to build
up the skills to do very, very cool things that help society.
That step is now changing and people are asking, well, what do
I do then to make myself not obsolete?
And we're talking about anything with regards to communication
and soft skills and learning. I agree with all of that.
And then there's still a tooling aspect.
Like I don't know what I should advise people with regards to,
OK, how do you go from junior to actually in the end becoming
senior? Because it's such Gray area that
I don't know yet. I feel like we're really
figuring things out. And the only advice that I have
is be as open minded as you can. Try and familiarize yourself
with a lot of things. Try and build as much
foundational knowledge as you can because tooling does change.
I'm wondering what your perspective is on that.
Don't be a fool with a tool. That is one of the core pieces
of advice I got started my career over 9 years ago.
God, don't be a fool with a tool.
Back then we refer to only knowing our only knowing Python
or only back then. Do you remember RPA people?
Do you remember back when RPA was a was a thing?
I was using a Python package back back in the day to to
scrape Twitter. I forgot forgot the name
Selenium. Yeah, yeah.
I was learning Selenium because that was one of the first Python
based browser. This automate the browser and
click down. Back then those were bots, but I
knew people who doubled down on only learning Selenium and all
the insurance and outs. But Selenium was open source and
it was great. You could do everything with it.
But then the blue prisms came in, which was basically the the
company or the company organization equivalent of it.
But it was reliable because you could sue somebody if it didn't
work. And suddenly the whole Selenium
market disappeared because people went for for larger
infrastructure tools instead. And the guy who knew everything
about Selenium was stuck and the people who learned Blue Prism
were laughing at him. Nowadays we laugh at the people
who only know Blue Prism because the cycle continues.
It's not about learning anyone tool, it's about being able to
learn in general. And that involves learning the
insurance and outs of tools. I think it we are switching from
an explicit knowledge economy to an implicit knowledge economy
and our education systems haven't adjusted to that, that
the worth of knowing stuff in your head, memorizing it, that
worth is only going down. But the ability to look up stuff
that was introduced like what, 25 years ago when Google hit the
market, before we had that, we had start start that has been
introduced during our lifetimes. But the value of that, of
finding stuff in large amounts of information, that is only
going up, especially in the age of disinformation, because we
are drowning in information. But truth and wisdom has only
increased invaluable and has become relatively more scarce
because now there's more bots and more fake stuff flooding the
Internet than actual real stuff. And the only way we can still
distinguish truth from fake, because I see so many deep fakes
now of Zelensky, of Putin, of F-30 fives that crashed in Iran.
And we could only tell they were fake because there was still a a
human in the cockpit, because they forgot to prompt it remove
the human from the cockpit. We can only tell truth from fake
because of human error. And that too will end.
So what we need to learn, again, because learning is important,
is to triangulate information to figure out what's real.
And This is why I I'm frustrated with modern media and journalism
that thinks that just regurgitating and repeating what
no liar say is somehow journalism.
I forgot the quote, but somebody once wrote this.
If one source tells you it's raining and the other says
there's sunshine, your job as a journalist is not to report
both, but to open a damn window. And that's what I'm missing.
What is your perspective on AI tooling in this building frame?
Because if you're looking towards end goals, if my end
goal is to build a product or an e-commerce website, I can, I can
generate a lot of that stuff. But would I then learn how to
actually do that? No, I would achieve my goal in a
different manner. Would people from your
perspective that Start learning now?
Should they leverage AI tooling or how can they use it to learn
effectively? That's a great question and
we're still finding that out. I think so.
So my take is yes, you can use it to to set up a lot of things
for you. I would more use it as a tool
for validation rather than something for, for you to
generate things right. So if you are not able to
actually explain what comes out of this model and, and if you
are not able to understand why the code is there, then you will
have a very rough problem also maintaining that and extending
that. And of course then you can say,
OK, well, then I have some agents, AI agents do that for
me. But ultimately there, there's,
there will be a gap of understanding where the model
trips up and, and you are not able to get it, catch it.
So use, use AR models to validate your understanding, try
to generate maybe a few things and see, do I actually
understand what's happening here and not ask the model right that
that's great. But don't focus on on getting a
polished product out of it and then getting sort of the, the,
yeah, the products there. In the end, it's, it's really a
tool that you can use, especially if you're like taxi
driver who's who's going to learn coding.
It's a tool that you can use to, to build your knowledge.
You can also use very much to cheat, of course, and to just
sidestep all of this hard work of, of trying to understand it.
But I don't think that will in the long run help you.