You don't really write code by hand anymore at certain
organizations. If this part of the craft for
you is where you get your fulfillment, that at your job to
me is completely changing. Juniors, they don't really care.
They're like 6 months is fine. I'm starting out early in
career. I can invest this and this is
where it's going. Those that cannot, to me, they
will be legacy quite soon. Things are changing already in
hiring processes. I've seen companies just focus
on system design. Show me how you design a system
that can start simple and then can scale.
It is the calling out there. People that have little
experience, people that cannot grow and educate themselves
quickly. They will be weeded out.
A special Q&A episode, which I call Reddit Reacts.
It's the second edition and last time I'm sure you were not here
because it was about 3 years ago.
Questions I found on Reddit, statements, controversial topics
and I'll give you my perspective.
So enjoy. How do you become technically
cracked in 2026? For me, 2026 is not that much
different from 2025 or any year previously.
The biggest analogy I can get to, and for those who don't
know, cracked is just really, really, really good, is to put
in the reps. When you start out fitness,
you're not going to be a strongman from the get go,
right? You're not going to develop the
muscles that aesthetically you might want to have.
It takes a long time and it takes a long kind of venture of
discipline. The people where I've, I would
say they're really cracked. The people where I, if I start a
startup or if I start a project, I want them in my team because
of their execution prowess. Those people have put in the
reps and those people have put in the reps so much so that when
we're discussing a problem, me who has, who might not have put
the same amount of reps in, I'm like, well, I would have to
figure out how to build this. As we're discussing a problem,
there are some holes in my knowledge, some things that I
would have to figure out or experiment with, and these
people that I would truly trust that I would say are really
cracked. Those people have built
something similar or have developed this kind of feeling
where they instantly have an idea of how they would build it.
When we're discussing something where they could break down a
big, big problem. And in their mind, they can
already have kind of a stepped approach of how they would get
to this huge end result. And for me, that's really cool.
Putting in the reps is actually something that you can do quite
easily. Greenfield is definitely
different than brownfield or something that is out there in
production for many, many years. So you need a varied amount of
experience. So starting with personal
projects or hobby projects, those are quite easy to start
with, especially with agentic tooling that you have.
There is the discipline that you need to use it as an educator
and potentially not as a power booster if you want to learn and
really use this to boost your educational knowledge, your
fundamental knowledge. And then you have open source.
I think 2 weeks ago an episode came out about open source.
If you haven't listened to it, definitely give it a listen
because that is an established project with kind of strong
conventions that you can contribute to.
And the way you contribute to it really matters, right?
Your audience is not your peers or your audience is not
yourself. You cannot say this is how I
like to structure my pull request and this is how I like
to structure my code commits. Your audience is the people that
maintain this repository, and the more you accommodate for
that audience in how you develop software, the more versatile you
will become and the more easy your pull requests will also be
merged, which is that feeling of fulfilment.
Again, I think you learn a lot from contributing to open
source, especially when you want to become kind of technically
cracked. Figuring out not just using
tools from a tooling perspective, but also how they
work under the hood can give you an edge and it's definitely
worth it. And then lastly, there are many
people giving out their time for free online in the form of
mentorship. So if you create code and you're
not really sure what it is, right, you can use agents to
review yourself. But still a human pair of eyes.
Some people that have really good industry experience is
different feedback. And those people are out there.
They give their time out for free.
The website I always refer to and I'm not affiliated in any
way. I just know people that give
their time out there for free is adplist.org.
I'll put it in the link. I'll put a link in the show
notes. I should definitely talk to them
and ask them if they want to sponsor the podcast, but in any
case, they are not a sponsor right now.
People are out there giving their time out for free.
Engineering managers of Spotify, of Netflix.
I've seen them hardcore back end engineers, really good front end
engineers. I know some of them.
So you can go there and you can say I want to book a half an
hour time slot with this person and this person is really
reliable and has really good reviews.
And then just talk about some challenges that you have and get
feedback from these people. It's really valuable.
SO3 stepped approach, putting in the reps, doing it in different
types of code bases, early brownfield, very, very
production like and open source can get you there to bridge the
gap and then getting feedback from people that are very
experienced in this field and doing that over and over and
over again. All right.
I don't think there's a ceiling to how technically cracked you
can get just by virtue of having so much information out there
and things evolving so quickly. You do have to accept that you
will not know everything about everything because things are
evolving continuously. And if you're not comfortable
with that, then either accept not being technically cracked
all the time and only in certain fields, or maybe this field is
not for you because this is a field where you continuously
need to learn. And it's easier when you're
young, when you're early in career, when you have all the
time. And to be honest, it gets harder
the more responsibilities you have.
If you have kids, if you have bills to pay, you cannot afford
to have as much free time as you want.
And it's a trade off. That's reality.
This is a statement and this, this person says the juniors who
only learn to code with AI are going to have a rough time at
about five years. They talk about two juniors
being in their team, both shipping fast, both growing up
with Cursor and Claude, and they're quite afraid what it's
going to look like in five years.
I don't think I agree with the statement.
I don't think juniors are going to be stuck in five years.
Things will evolve in five years, especially in this field
is a long, long time. I think things will evolve to a
point where you define your interfaces and kind of what
happens, what is agentically generated in the middle, people
don't really care for as much. Or you have conventions in place
to kind of audit and to make sure that the quality is as high
as it can be. Because to be honest, you will
never have a code base that is 100% to your liking, that is
100% aesthetically pleasing or elegant as some people say.
Elegance is very opinionated and some people agree or disagree
based on what some things look like.
It's all very personal. And in the end, when you're
talking about production grade software, to be honest, most of
the time it doesn't really matter.
Things or code specifically needs to be simple and it needs
to be easy to change. That's the most important aspect
of production quality code in my opinion.
If it's not easy to change, then you're going to have a hard time
building changes upon it. And if it's not simple, it's
going to be very hard to understand for humans, but
especially nowadays as we're following this evolution for
agents. So that's what you need going
forward. And you can still do that by
manually creating code. And you can still do that, in my
opinion, by having agents generate the code.
You need to have strong conventions in place.
And for the people that don't have at least half a year of
experience working with this AI assisted development tooling,
they will disagree. Put it in the comments if you
disagree, but if you don't have at least half a year experience,
I'm just putting out an arbitrary amount of time to be
honest. But for me half year makes
sense. Then I'm assuming you're going
to disagree after you bridge that gap.
I've seen for some people it could be a training, it could be
a specific moment, it could be a pair programming session.
Something just clicks and then they're hooked and then they see
this new way of working which is quite effective.
Fundamental knowledge will always be needed, but to what
degree that fundamental knowledge is, I don't know yet.
That's something we're going to have to experience.
But the junior people right now have an edge that is quite
unique because when things are new, when I'm telling people
that have 20 years of experience that they need to have six
months with this new way of working, the juniors, they don't
really care. They're like 6 months is fine.
I'm starting out early in career, I can invest this and
this is where it's going. So the sooner they're able to do
that and they also start with a blank canvas.
They don't have 20 years of baggage, and baggage can be
good, but it can also in this case be potentially negative.
Then they don't really care, right?
They start with the blank canvas.
They start with the six months of experience with a ISIS
development tooling. They deliver over and over and
over again. And when they reach a
bottleneck, which might be a knowledge, which might be in a
code base, they will adapt. I strongly believe that for the
people that are transitioning into this, they also kind of
start with a blank canvas. It's really for the people that
have 20 to 30 years of experience, they have baggage
and that baggage is really, really valuable.
All right, don't. I don't want to undermine that.
It's incredibly valuable. That's why I truly believe in a
good mix of seniority within teams.
It also means that they need to be open to learn, learn new
things, open to learn new things, potentially even from
people that are less experienced than them.
Those that cannot. To me there will be legacy quite
soon. Do most of you seriously not
write any code by hand anymore? This person talks about really
loving the craft that is coding, finding a problem or fixing
something and then getting a dopamine hit when it's actually
solved. And that is now outsourced to
agents in this new agentic way of working.
My latest experience was kind of end of last year where for a lot
of months I didn't do any hands on coding anymore.
And I understand the difference, right?
I like building things and the building process is really speed
up. I also like the state of going
in flow and then typing away and then making solutions where I
think this is actually quite neat going into a cycle where I
get review remarks from my peers and then correcting it,
something I'm proud of. That latter part is completely
changed. You don't really write code by
hand anymore at certain organisations.
Not every organization is at a level where all code is
generated by agents. I don't believe that.
So companies are definitely playing catch up though.
If this part of the craft for you is where you get your
fulfilment, that at your job to me is completely changing.
So you need to find something where you can still find that
same passion or fulfilment or move that to part of your
hobbies. Because if companies are
expecting you to work like this and there is an ambition and a
strong belief that this makes people more effective, even
though the metrics and the statistics and the surveying and
the results are still a little bit out there, there's a strong
belief that it can speed up people and make it more
effective. That's what organisations are
pushing for, which means that currently it's just changing.
If you want to pivot, it's likely going to be a few months
of time investment for you to be effective or to feel effective
close to what you were previously.
But this investment in my opinion is worth it, so find
something else to get fulfilment from because things are changing
and everyone's unique. This one's hilarious.
I vibe coded for six months and my code base is a disaster.
The app works, users are happy, revenue is coming in.
That's actually only the good part.
But I tried to onboard a dev and they opened the repo and they
just said what is this? I think this is vibe coding with
people that have 0 experience. I came back from this work
remote trip in Australia and I talked to my Uber driver.
I still need to make a LinkedIn post about this.
This person is an acupuncturist, acupuncturist.
This is really hard work for me, an acupuncturist.
And he talked about creating an app.
He said app continuously but in the end it's a web page and it's
for acupuncturists like him. He has all the domain knowledge.
He said this was an idea he's had for many, many years, and
then he opened up Lovable and he's just started building it
and he says he has analytics with regards to usage.
He has a whole test suite and he's building out more
integration tests. He has it up and running.
He has users. There's no revenue yet, but he's
super excited and he's trying to think about distribution because
he's now built the thing and it's value.
He has the domain knowledge. This idea was translating some
Western practices or medicine into Chinese practices or
medicine. But the fact that he built that
for me is incredible. I don't know what the code base
is. Looks like all right.
I'm sure this person doesn't know about any type of code
conventions or any type of architectural patterns.
In the end, it doesn't really matter.
They had an idea and they executed it, and right now it
provides value. Code might not be simple.
Code might be very complex, which means at a certain point
it's going to be very hard to change.
Which means adding a feature that was previously not in
scope, but all of a sudden valuable based on user feedback
might be possible or might require a lot of refactoring.
And then vibe coding might reach its limits, right?
This is all a hypothetical, but the fact that there's another
person that says after six months, my code base is a
disaster, it's for me quite funny.
I think these people, either they're going to go through this
way of working where they realise, OK, I have to change
something. They might hire a person, an
engineer that has experience to help them kind of navigate this
thing. But this problem is not unique.
It's maybe unique in the way that it's right now presented as
vibe coding, but codebase is stagnating and becoming hard to
change. Just had a longer time horizon,
right? Instead of six months, it might
have had six years. And then all of a sudden people
would be like, well, it's so hard to change that we either
need to rebuild components of it or we start from scratch and we
rebuild from scratch. That is not a unique
circumstance in our industry. It's basically what has happened
to many companies that I've been involved in.
They get rid of certain vendor lock insurance that they have.
It's not a unique problem right now.
It's just accelerated. And vibe coding is really cool
because it allows you to build quite quickly, but also you will
hit certain bottlenecks just quicker.
And you need to, from my perspective, learn how to accept
that if you have the knowledge navigated early.
But if you don't, when there's a bottleneck, you fix the
bottleneck. And the way you'd go about it,
you have to either teach yourself or you just hire a
consultant that has expertise to help you go through that.
Depending on how much money you have and how much money you want
to spend, you can accelerate that process.
But in the end, there's learnings to be had for people
that are new to the field, even more so than for the people that
are already in the field. So yeah, I think we're going to
have more examples of this. The problem is when applications
have security holes. I think that's the biggest
concern that I have right now. Lovable got hacked and then
many, many secrets of the websites they host or the
websites that are built upon that were out in the open.
At least I read about that. I don't know if it was just
secrets or if it was also user credentials, but for me that's
the biggest concern where you deliver value and users are
using it. But if it's full of security
holes and security exploits, then yeah, security people, the
main experts in that field, they have a lot of work to do still.
Why are non-technical leaders obsessed with screen sharing
during incident calls? So for those of you that don't
know, I started out my career in operations not doing any
software engineering. I had some software engineering
experience from uni, but the first year was just in
operations where I wasn't really allowed to touch code.
And I've done many incident calls, I've done many kind of
migration projects. And this was pre COVID era where
there was not really a lot of working remote.
If I needed to do something in downtime and I needed people to
navigate and contact with, there was not really any screen
sharing. I feel like that's more of a
modern thing. But in any case, I just open up
a call, multiple calls with people.
And I said, OK, I'm going to do XY and Z just like we planned.
And I would do that and they would not see what I was doing.
They would just be on the call on standby and then when it was
their turn, I was like, all right, you're up.
You know, we need to do XY and Z just like we planned.
And they would do that and just tell me, OK, it's done.
And I would coordinate with another person because I was
responsible for application operations.
So screen sharing part is for me, nothing unique.
If people are asking for, can you screen share?
So they can either learn or they can follow through.
The problem is if they're kind of in the way with the questions
they ask, but if it's genuinely from a good perspective, then
who cares, right? Is it really something that is
kind of unique to you or is it an ego thing that you need to
figure things out as you go? I don't know.
When I used to play video games as a kid, I hate it when people
were looking over my shoulder, but now I don't care.
Maybe it's an ego thing. I feel like you need to reflect
on that. Screen sharing is not as big a
deal from my perspective. Maybe ask why they want to see
it, right? If it's if it's from a learning
perspective, then definitely accommodate.
If they want to see how things go and see how you navigate,
then who cares? Either they see it or they
don't, but the result is going to be the same.
If it slows you down, then have a conversation on why that is
and maybe they can accommodate, right?
If they ask so many questions and you have to explain things
and you can't really do the damage control that you're there
to do, then that's a valid remark, right?
It's valid feedback to give to them.
I wonder if they actually realised that this person says I
don't do anything and I still get promoted.
I've been at the same company since graduating.
I've been there for about four years, I make really good salary
and I just got promoted. I've consistently written maybe
500 lines of code tops per year. Aside from database queries,
I've never built a project, excluding in college and in my
free time. My work consists of scrolling on
reels and occasionally fixing a bug in an application that was
created when I was a child. OK, since this person, this is
the first company they joined since graduating, you have a
decision to make, all right? You make a really good salary.
Apparently you don't do anything, you don't learn
anything. So this is a risk to your
career. Are you OK with that?
Then just ride this sugar train. It's not my choice.
I would be incredibly frustrated.
When I joined my first job. I wanted to make impact and I
wanted to learn as fast as possible.
Now I know right now and I didn't really realise it back
then that not everyone is like that.
If this is OK for you then that is fine, but the risks are
there. Your skills will atrophy,
especially after four years and only doing 500 lines of
production code and then debugging applications that were
built before you were live. It doesn't really like future
proof your skill set when it comes to your career.
So if all of a sudden there's a reorganisation which could
happen and you're on the streets looking for a job and people
were asked, OK, what experience do you have in the last four
years at your job, then there will not be a really good
answer, which means that finding a job will be really hard for
you. And there will be another post
on Reddit where it says 4 years of experience and it's taken me
a year to get a job. Well, yeah, they don't tell you
about the background experience that this person actually had.
So I feel like this is a real wake up call.
If you find yourself in a similar position where you
cannot make impact or you feel like you're not, what you're
learning is not contributing to the skills that you want to have
in the future, then you need to act.
I hate it when people say, oh, woe is me and my career is kind
of driving itself and I'm not behind the steering wheel.
I feel like you need to grab hold of that steering wheel.
Talk to the people with regards to what you actually want to do
in life and in your career and make that happen.
If it's not at this company, then your new job is to find a
company where you can actually grow, and it might definitely be
taking a pay cut and starting off at a junior position
somewhere else. It's a really rough time
compared to especially two to three to four years ago where
there were more and more jobs. But if Meta is laying off 10% of
their population, I don't know how much of that is engineers
and other huge companies are laying off staff, which might or
might not include engineers. Then right now there's a lot of
people looking for jobs. So if you don't act, then I'm
afraid for your future. Have the best engineers
basically stopped applying? Forcing companies into passive
hiring? This person has a theory.
A lot of the strongest engineers aren't really in the market
anymore in the traditional sense.
They're employed, busy, selective, and only move when
something unusually compelling shows up.
So they have a question, Do you think the best candidates are
mostly passive now? Are they waiting for the right
opportunity? This is interesting right?
Because if you like what you do at your job, there's no reason
for you to move. If you don't like what you're
doing at your job, you still want something that is better.
So if you cannot find better out there, then you will stay at
your current job. It's not really black and white.
There might be really good things at your job and some
things that just suck. So you're trying to find
something where it's 100% great and 100% in my opinion doesn't
exist. Everything is a trade off right
now. At my current job, I have a lot
of freedom and I have a lot of room for growth.
My salary might become a bottleneck in a couple of years,
which means I have something to think about.
Am I going to continue investing in my personal career and in my
growth? Or is it time to harvest because
I've invested enough and I want to be at a job that actually
also brings a lot of money to the table?
I don't know yet, but because I don't know yet and I'm happy
where I am at, I'm not actively applying.
If something comes up on my doorstep, I do think it's good
to apply and to learn from those application processes, to see
what is out there and to see what is needed and to see how
you actually go through an interview process.
I take all of that as a learning, but I've been at my
current job for seven, close to seven years, something like
that. Now it's a consultancy, so I go
from assignment to assignment, which means I'm at the same
company, but not really because in those seven years, I think
I've been in at least 12 different projects, which some
have been a year more, more than a year, some have been a few
months here and there. And I learned a lot through that
throughout that process. Strong onboarding.
How can I make impact as fast as possible?
What is my legacy when I leave this company behind?
How do I make sure that things are better when I go than when I
started? Those are some of the things
that I focused on. And it's a very kind of, yeah,
unique feel. It's consultancy.
If you've been seven years at your same company, then you
might have this kind of baggage of contacts that people want you
in meetings because you just know things, not for your
skills, but because of you're kind of a historian at that
company. And if I find myself in a
position like that, I've never been in a position like that,
but I don't think I'd be happy, right?
I want to be valuable due to the skills or the perspectives that
I provide. And if that is just being a
historian, then I would rather be a history teacher.
It's not what I want to be at a company, but those engineers
might be really, really good. If they cannot find something
out there that is as good or better in terms of financial, in
terms of growth, in terms of impact, in terms of fulfilment,
in terms of tool usage, then they will just stay at the
current company. So I'm not sure if the best
engineers are currently out on the market.
What I would do and what I see the best engineers do is re
network. So they will not necessarily
call the ply to a vacancy at a company where they don't even
know what that company is. The company is new, the company
is not really established. They will network with people
that work at the companies they want to work at.
And those companies typically are either really, really good
big tech companies or they're really, really good.
High potential, high risk, high reward startups, scale UPS, you
name it. Networking for me is the name of
the game nowadays. If I know someone that works at
a company and I've been working together with them and we did a
24 hour hackathon, for example, then yeah, I already worked with
this person. They already know a lot about
me. If I see a vacancy or if I think
I would love to work at that company based on what I know
from them working there, why wouldn't I reach out to that
person directly? Really, really good engineers
for me. There's always room at companies
for really, really good engineers.
So your hunch might be right. I don't know what your pipeline
looks like. Interview process also can make
a difference, right? If you get a take home
assignment and it's 8 hours compared to a very fast hiring
pipeline where we just jump in a call and I can show you exactly
what the results are of something that I have been
building. Or we jump in a call, you give
me an assignment and you go out of a call and in one hour I can
show you results. It's very different.
So it needs to come from both ways.
Really good engineers are looking for really good
companies and you show that in the type of people that you have
on board and the type of hiring process that you have, the
hiring experience. If you don't have anything and
you're starting from scratch, let's say at a start up, then
you better have a really good network and you better have
really good offers to those networks and definitely leverage
the network of network effects. If you hire a really good
person, ask them who are really good people that you've hired or
that you've worked with and then cold call them and then say I
just hired this person. They said you're amazing.
Let's talk software engineers. How do you see the future of
software engineering? With all the recent news about
large scale layoffs and how fast AI is improving, I'm curious how
people here see the future of software engineering.
Do you think it's still a strong long term career path and what
do you think will help engineers stay competitive and stand out
the future of software engineering?
Now I don't have a crystal ball so I cannot give you a
definitive answer. I can only give you my
perspective. And for me what is software
engineering is changing, right? If your fulfilment we talked
about that is really in the hands on coding part, then that
is slowly but surely in my opinion moving away.
That doesn't mean that other challenges are not as
interesting, something like system design, systems thinking,
thinking about architecture and business context, making
trade-offs in terms of speed and delivery, customer value.
For me, those things are very, very interesting and they're
becoming, they're coming more to the forefront, more to the
plate, on the plate of engineers, not to forget
anything with regards to infrastructure as well as
debugging production issues. For me, those skills are
incredibly valuable. They have always been, and they
might even become more and more valuable moving forward.
So the shape is changing now when we're talking about career
and long term viability. I feel like a few years ago
there was this narrative where this is where you make money and
it's very easy to get into. Do a six month boot camp, self
educate and get into this field and make impact or start
creating things and companies will hire you.
That part I feel like was trying to solve the things that are
quite repetitive. Not every company is doing
unique things. Every e-commerce website that
I've seen has some similar components.
When we're talking about product catalog, product detail page,
check out funnel, payment, transaction order history, order
management, warehouse management, fulfilment, return
process, etcetera, etcetera, loyalty process, all of that is
already kind of established. So when you're building that
from scratch how it used to be, yeah, you just need a lot of
hands to build all those topics, especially when we're talking
about something new, a company that didn't do e-commerce
before. Nowadays when we're talking
about repetitive processes that kind of have established
success, AI is really good at pattern recognition and
something that is established output.
So something like e-commerce, you can use a lot of agents to
help speed up the build process. Now understanding what a
customer actually wants and AB testing kind of your examples
and thinking about where the value is in terms of delivery,
MVP and figuring out where some production bugs are just very,
very nasty. Those skills are also always
going to be there and they can be automated to some point, the
repetitiveness, but there will always be a unique aspect to it,
which means that's where your edge is.
That's where your value is moving towards more so than it
used to be potentially. Coding was never 100% of the job
unless you're at a start up and I know at least one person in my
network that just he's running start up but he just codes 80%
and his start up to be honest is not moving that quickly in my
opinion because he codes 80%. That's what he loves to do.
He doesn't really have the financial how do you say that
strain his back is not against the wall.
So this is more like a hobby start up in my opinion, which is
fine. Everyone has their own thing.
Coding as an engineer is never going to be 100% of the job.
I don't think it's going to be 80% of the job.
I think I did a poll, all right, I did a poll on YouTube, 305
votes. 46% says less than 25% is what I'm doing in terms of
coding. Now that less than 25% is going
to be optimized with agents. And sure, other polls, other
parts of the software development life cycle will also
be optimized with agents, but that other 75% is where your
value is. I think that 25% is not going to
go away. It's still going to be a certain
percentage. You're still going to have to
orchestrate agents. And I like companies that say,
and that's right now. And I'm also very naive and very
hopeful, trying to be very positive that we will do more.
So why would we remove engineers that make impact?
We will just hire more engineers that make impact and then go
faster, right? The sooner we reach a bottleneck
and fix those bottlenecks, the sooner we will be where we want
to be in terms of vision, in terms of outcomes and in terms
of value, because that was, that's what companies are aiming
for, right? They want results, outcomes and
value. So the faster you can go, the
better it is. There is a number of people
where people processes just become a bottleneck.
So when that is there, then yes, you have too many people, so you
might need to cut people. You have to find companies where
I feel like there's a sweet spot where you can make impact, but
there is a lot expected of you. This job has always paid really,
really well. We've just talked about a person
that has been at a job for four years, not really doing
anything, watching Reels as part of their day-to-day.
To be honest, in my opinion, that's unacceptable.
You get, you pay, you get paid a lot, and then you watch
Instagram. That's unacceptable.
If you find yourself in a position like that, it's time
for change. Or just ride that sugar train.
It's not for me. Do whatever you want to do, you
do you. So for the future of software
engineering, things are changing already in hiring processes.
I've seen companies just focus on system design.
That is the biggest part, might be the only part that they care
about. Show me how you design a system
that can start simple and then can scale and based on questions
that I ask on database complexity or compute
complexity, what is your answer? How do you think, How do you
reason? How do we have a discussion?
How do we have a conversation? If you can reason about systems
that you've never built, or you can reason about starting simple
and then growing to more complexity and seeing and
communicating how you still keep things simple, and that's
incredibly valuable. So if that's not something that
you're good at, I know for me, it's definitely something I'm
not great at. It's something for me to work
on. It's something for us as an
industry, as engineers to become better at.
There's a lot of videos out there.
There's a lot of Rd. maps on system design and how you can
take ownership of that. It just requires effort and
discipline. Are most programmers bad?
Is this just inevitable state that any project ends up with
after sometimes or are most programmers just bad?
I don't think most programmers are bad.
I think there is a scale and not everyone is technically cracked,
that's for sure. I think a lot of people are very
very capable. I think the bad ones get weeded
out quite quickly because everything is kind of
transparent as you work, which is quite unique, right?
You can see based on your pull requests and your code commits,
what someone is putting in in terms of output.
And then in terms of quality, you can also judge that from
other people's or you can get feedback from their peers.
So I feel like people that are really not great, they get
weeded out. And also because this is an ever
evolving landscape where you need to continuously learn.
The people that don't have the drive and discipline for that, I
feel like they just themselves realise this is not for me.
This is not worth it. Yes, there's a nice paycheck,
but I feel this anxious feeling of imposter syndrome because
imposter syndrome is a real thing.
And sure there are imposters out there, but I don't think it's
the most engineers. I think what this person is
describing, it's just a sad reality of when times are tough,
when people are have their backs against the wall, and this could
be metaphorically people, leadership teams or an
organization as a whole, then trade-offs need to be made.
So do we go for something fast? Do we go for something risky?
Do we go for a bandage solution for value now?
And those solutions that are temporary, they might just
become permanent. And if that happens over and
over and over again, it doesn't matter who's operating.
They are doing what is expected of them to potentially save
their business from hell fire. So to judge them for it and to
be like, well, these people are bad, I feel like that's quite
naive. I feel like I wouldn't want to
say that to my colleagues or to my peers.
Now I have worked with people that are exceptionally good and
then I do see a skill difference and I think those people are
exceptionally good. But to be able to judge based on
the output, based on a system that is there in production for
10 plus years, that system has also survived 10 plus years.
Not many systems, or I should not say not many, but not any
system can say that. So yeah, give some grace to the
people around you. Ask some questions instead of
judging. That's my approach.
That would be my advice. And learn.
There's always things to be learnt.
All right, Last one, I just got laid off.
I want to take a gap year. Is that advisable?
My answer is no. All right, I was outside of
hands on software engineering for about a year and a half.
This was two years ago and I had, I feel like the biggest
career FOMO you just threw out there.
And the fact that I'm talking to really good engineers on the
podcast, it doesn't really help. And the fact that I wasn't
really building and wasn't really inspired to do any
personal projects doesn't really help.
But I felt a lot of FOMO and things accelerated very, very
quickly. I feel like if you have a gap
year right now depends on what you feel that gap year with,
right? If it's a year of travel and
you're early in career, you do you.
You might get back on your feet is not for me.
I feel like this is the time to invest and to experience and to
experiment and to find a company that invests in tooling so you
don't have to pay those AI bills yourself.
I just heard that GitHub is increasing their multiplier by
9. All right, Opus was I think 3 or
4, depending on 4.6 or 4.7 in the GitHub Enterprise, GitHub
Copilot license, specifically GitHub Copilot, and they're
increasing it to like 27, which means, yeah, the cheap licenses
are becoming expensive. I'm going to have a 9X
multiplier on my license. Something that was 30 bucks a
month is now going to be something that is like close to
300. That's ridiculous.
So you might come back in a year and it might not be affordable
from a personal side. And then because you have not
worked for a year, experimented and rode this wave, no company
wants to hire you. That is on you.
Do not take a gap year is my advice.
Find a company investor yourself.
Find a company that invests in you and learn and grow and be on
top of things. Because right now it's like the
calling games. If anyone watches anime, that's
definitely a reference. It is the calling out there.
People that have little experience, people that cannot
grow and educate themselves quickly.
They will be weeded out. And yes, I believe that
companies will go faster and do more with really good people.
But you need to be really good to fit in there.
If you're not really good then either get lucky.
Network hackathons, open source contributions, meetups,
conferences, network Build credibility, get your foot in
the door. Ace the interview process.
There is still the skill that is required to ace an interview
process that can be taught, that can be learned, that can be
executed upon. I believe that.
But if you don't have the discipline to do that, it will
be rough for you. Let me tell you that it will be
very rough. So right now might not be the
best year to take a gap year. However, if you have a financial
nest egg and you've always been kind of entrepreneurial in
spirit, then that gap year might not be a gap year.
Might it might be a year to invest in building up something
from scratch, right? It could be tooling to find
customers to deliver value quite small, something that you solve
for yourself and that you can then market to solve the same
problem for other people. Those are the best, but I
wouldn't call that a gap year. For me, a gap year is I'm taking
a break, I'm not doing anything. I'm going to travel, I'm going
to experience, I'm going to live my life.
Everyone's journey is unique and you do you.
I wouldn't do it right now. Take a year and build a start up
if you want. If you really kind of feel like
you're in this rat race and you're exhausted throughout your
career and you feel like you're close to a burnout, then don't
push through. That's not what I'm saying, but
definitely think about kind of the repercussions and you can
take a year and invest in yourself in terms of technical
aptitude. You might have some hefty
license fees, but if you can afford that, then why not make
the most out of it? I'm going to round it off there.
This was my Q&A, my Reddit Reacts episode 250.
Thank you for listening. I'll see you next time.