October 9, 2024 • 51 mins
In this episode of the Mix the panelists talk about Seniority. They lay out their own personal journeys towards getting a senior title and how they define seniority for themselves - especially how it goes beyond the ability to write code well.
Among other things they discuss:
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Among other things they discuss:
- how to become fluent in reading and writing code
- how side projects are useful but not required to become a great developer
- how senior developers tend to approach problem solving and how to get better at that
- how interpersonal skills play at least an equal role as technical knowledge
- how specific tech know-how becomes less and less important the further developers climb the ladder - at least the managerial ladder
- how organizational structures cannot be ignored when building solutions
Links
- Are We Really Engineers? * Hillel Wayne
- Seven Languages in Seven Weeks
- Conway's law - Wikipedia
- Team Topologies
- The Little Elixir & OTP Guidebook
Picks
- Adi- The Little Elixir & OTP Guidebook
- Adi- Seven Languages in Seven Weeks
- Adi- God of War Ragnarök - PS5 Games | PlayStation
- Sascha- Specification by Example
- Sascha- Exercism
- Sascha- You Know Nothing ... or do you? - Sascha Wolf
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Everybody, and welcome to another episode of the Elixier Mix.
And this week on the panel we have Addi, Iron
Gar and me Social World. It's again a small round
because kind of fits cozy enough. And Addie and me
have been thinking what we do we talk about today,
and we want to talk about seniority, seniority in the
countries of software development. So you could also she wants
(00:27):
to have a clickbait title for the because you might
name it. How do you how do you get a
tasty senior title? So yes, it was an idea of you, Addi.
So why don't you take the helm and tell us
what made me think of this topic?
Speaker 2 (00:39):
Yeah?
Speaker 3 (00:40):
So, yeah, lately a lot of the people I mentor
have been asking this question to me, And I know
Chuck told us a while ago that good amount of
our listeners are early mad engineers, so I thought that
this would be a good topic.
Speaker 2 (00:51):
But yeah, I mean, one thing I wanted.
Speaker 3 (00:53):
To cover is, like, you know, there's like no single
path to that seniority, right, and we can try to
like talk about things that might actimize the likelihood for
you to get there. But luck, like Sasha not talking
about before recording that luck is the biggest is probably
the biggest factor and really decides that what works for you, you know,
you making an individual also is a big thing. Like
(01:15):
for example, we talk about side projects, right, and like,
I is pretty much never a point in.
Speaker 2 (01:19):
My life where I don't have an active side project
going on.
Speaker 3 (01:22):
Like ever since I started coding in twenty eleven, even
when I was at a student whereas startlist that he
almost never had.
Speaker 1 (01:28):
A side project, that is, outside of projects, I don't
do side projects.
Speaker 3 (01:34):
Yeah, so each engineer can like take different paths, you know,
and still you know, be a very good engineer and
be a seniorque senior engineer. So uh yeah, I do
want to preface this whole episode by saying that.
Speaker 1 (01:48):
Adie, have you actually seen my coded Maybe maybe.
Speaker 3 (01:53):
That's another thing, you know, like do you define a
senior engineer as someone who writes good code or defines
the engineer as like this like kind of a meta
term of you know, someone who knows what they're talking
about right, from an architectural perspective, from someone who has experienced,
someone who through experience has developed the sixth sense of
(02:13):
what's the right thing to do right? So quote is
important as well, But I think I generally use the
ladder things that are described to the financier engineer. So yeah,
even if I even though I'm not senior quade, Sasha,
I've talked to you enough, I tell you're a senior engineer.
Speaker 1 (02:27):
I'm also gonna like to answer your question like, how
do you define a senior engineer? I'm going to give
you a very senior answer and then say it depends
because it is actually a question we've been tackling at
the current job. Also, like because at the Instatus Quo
and we have senior engineers, we have mid level engineers,
we have early career engineers. Actually prefer the trum developers
(02:48):
because I think there's a very good article series from
hel Way Anyway it goes into a software development actually
engineering category and spoiler, the answer is sometimes it is.
Most of the time it's not. But yeah, I'm aggressing.
So we had basically the same topic about, Okay, we
have we have some seniors, we have some mid levels,
we have some early career people. What criteria are we
actually applying to that because until that point that was
(03:10):
pretty much nearly really yet you're senior and you're not,
But why right? And we now have like a like
some levels and expectations attached to that, and what we
ended up with is not something where you say, this
is like I don't know, like like a list of
things you need to check the boxes and then your
senior boom. But it's more of an aspirational topic. So
like a very good senior would potentially check all of
(03:31):
these boxes, but realistically speaking, most people probably won't. And
then you can actually look at that and say, okay, hey,
this is like some skills. Maybe it's a mid level engineer,
you already check that senior box, but it's also some
room to growth on that, like because there are some
topics where you're more in the early career area, and
then you can actually talk about, okay, what are some
(03:51):
growth areas, what are some topics you might want to
look into? And yeah, code and code quality is part
of that, but it's not everything at all, and knowing
you too is part of that, but it's not everything
at all. So if you have had somebody and you
and they have no freaking clue how to write any
kind of code yet, then probably no senior developer. But
(04:11):
if they're a decent at writing code but have like
some very good understanding about like the ICD pipelines, right,
like how to set that up properly and maintainable, how
to potentially design a system in a bigger sense to
be like have like faith safes, consider educases, all those
kind of topics. Then all of those contribute towards getting
having a senior mindset. And then it might be okay
(04:35):
that maybe the code you writer is like just just average,
you know, just like average everyday code, not great, not terrible,
and still you could very much call yourself a senior developer.
So I would actually, because I mean it is just
said that path to seniority can be very different for
different people. How was your path to seniority?
Speaker 3 (04:54):
That's a great question. Yeah, I think I got super lucky.
As I said, like, it's a huge country and factor
for this job. It's actually a funny story. I had
offers from multiple companies. After a couple months of not
having any offer, I got, like entering a ton, I
got cuddenly I got a bunch of offers at the
same time, and I picked a small company with the
(05:16):
salary almost half of the highest salary I was offered.
The companies that I got offered form IBM was one
of them, which half in the highest salary. And there's
this company in the middle of Boston called Anti Sam
where a startopy they were thinking of doing ALICKXA. At
that time, it was like twenty fifteen. It was like
just one point zero and Phoenix wasn't one point zero.
(05:37):
So I was prett excited about that, and I got
paired with the CTO of the company, and I chose
to go there because I had a positive instinctive feeling
that if I go here, I will really enjoy and
I was not probably financially, I guess mature enough at
that point to think that, you know, double the salary
could really make a huge difference.
Speaker 2 (05:57):
So I was like, ah, I this sounds great.
Speaker 3 (05:59):
I'm gonna go work at this company and needs money. Yeah,
Well what happened is like my first project because I
was pared the CTO ware are two people team.
Speaker 2 (06:09):
My first project was a SECO level project was.
Speaker 3 (06:11):
Architecting and building a new software which talks to like
a legacy rails app and writing it in lixter when
Phoenix was just one point zero, right, And I was like,
that experience just chreeged my mind right, Like instead of
using packages that people have written and the lex community
at that time, it was so new. We were building packages.
We built the authentication package. We didn't use device and rails,
(06:34):
we built the device right. And like that experience two
hours of working in a project like it is equal
to like a day eight hours of working in a
project that's not like that. So again got super lucky,
and that fuel the passion I already had of courting
and allowed me to do site projects and like writer
open source libraries and kind of like try to push
my site projects beyond my work projects. I can bring
(06:57):
something into our work projects to impress r C, who
is like you know, there's like a godlike figure like
in my eyes, like here's Here's Still the best Enginet
I've worked with. We actually had him on this podcast.
Eric he built Eric stillim mus name he built it.
He started his own company a few months ago. We
had him a couple months ago. But anyway, uh yeah,
(07:17):
like having that beginning to my career, I was extremely lucky.
And you know because of that Elixir experience and initial
you know, learning the salary also if I'm probably much
higher than what.
Speaker 2 (07:30):
I would have been if I have stayed in IBM. Right,
So that worked out.
Speaker 3 (07:33):
You know, it worked out because I did not have
financials to make quote unquote the right financial decision at
that time, and went with my gut and got paed
luckily with the CTO and kind of had a company
that believed in me.
Speaker 2 (07:46):
Right.
Speaker 3 (07:46):
It's actually quite funny because that company I started my
own company twenty eighteen as well, and this is the
company I joined.
Speaker 2 (07:51):
They mentored me to start my own company.
Speaker 1 (07:54):
You know.
Speaker 2 (07:54):
Again, it's just a bunch of series of.
Speaker 3 (07:56):
You know, lucky breaks one after the other, which again
is the over arching kind of theme of career current
development in my eyes is luck.
Speaker 2 (08:03):
But Sasha, what was your path? Clear?
Speaker 1 (08:07):
I would expect that my path is a bit more
traditional in that sense, Like basically I came out of
my when I had my degree, right, I started at
a smallish consultancy slash agency, which had a very big
work in contract with Volkswagen. So I actually worked at
the software development part of Volkswagen. We didn't write any
(08:30):
code for CAST. We actually brote software which was used
by different parts of Volkswagen to give build to basically
set builds between each other. So the building internal top
Folkspargen building software. Yeah that exists. That was all a job.
And the thing is, like I worked there for roughly
(08:53):
two years, and that was at least it was a
very interesting experience in the context of learning the ropes
of like what agile development actually means, because I have
to say, like, while there was a lot of technical
debt at that place, they actually did scrum real well,
Like that was the really working system they had. They
had there and then a particular part of Folks Bargen
(09:14):
So still think to that day that that probably is
the best implementation of scrum I've seen it. So that
was like an interesting experience to see like how how
you can potentially deal with like changing requirements things, doing
estimations in a big group of developers, all the kind
of things. But I left there after two years because
it was in Folks Barkers and Volsburg and I don't
(09:35):
come from that area, so I wanted to go back
where I originally came from, back to family, back to friends,
and then I started a very small company because I
also like Folks super big company. By yeah, I wasn't
directly working for an employee of Folks Bargn, but I
was still like a super big environment, right, corporate environment,
And so I went to a very small company where
is it all kinds of things like, I mostly did
(09:56):
iOS development, but I also did some web development, I
did some backgand development and PHP. I at some point
did some embedded development in C So I ubbled with
all kinds of things. I then, after two years again
left there because it was actually too small for me.
It was too stressful, like just being happy to have
to handle all of that. But it was also a
very valuable experience in the context of having to see
(10:18):
the full project product life project life cycle right because
we didn't have any product project managers that didn't exist.
That was like a company of like six people, so
we had a little lot about ourselves sit in the
rooms with customers alsoves like thick with their things out.
So that gave me a very valuable perspective on what
it actually means at the end of the day to
take customer requirements, take something to customize an idea about
(10:39):
and make make create working software on that. Then I
ended up at a mid level company because I figured, hey,
folk smart and too big, right, six people too small?
Why not for a mid level it was like, I
don't know, like eightysh people said at that point, I
think where I originally encountered elixir and that was just
classic agency work. So and that was yeah, but that
(11:01):
was also an interesting available experience in the countries because
I said, Okay, I want to do more back end work.
That was the part of the things that did before,
which which I enjoyed most. And then that project also
at some point took over some technical not lead ownership.
I didn't have any like I didn't lead anybody, but
I was basically the technical link to the customer. So
(11:21):
like we had to always like a two fold set
up with like a project manager and somebody who had
like technical architecture perspective. So that was something where I
really started to dig into what it actually means to
figure out, Okay, people say they need X, but actually
they need why, right because they have to drill down
to what it actually what they actually mean when they
(11:41):
say the X and those kind of topics and that
at that point, I was still like, of course, at
poke one I was early careers lest junior. Then at
the middle of a company, I was just a developer,
right like everybody just was just a developer there, and
then I was like hired as a mid level back
end engineer and the developer at that company and then
my next company because I figured, okay, now I did
(12:03):
did mid level company size. I actually like that, but
I don't like this project agency work because it's just
super stressful. You kind of have always a bit of
had that ting with customers because they think you want
to oversell them, even though maybe you don't, so it's
not really it's like more of an antagonistic relationship than
like a collaboration relationship. So I was, hey, let's do
product work. Product work is like more aligned everybody's land
(12:24):
and also delivered best possible thing. And that is then
where I landed my first senior job. And up until
that point I was kind of concerned because like I
did all kinds of things, but like a JAVA, I
did it embedded, I did development, that in front of development,
and did all these different things. I was like, that's
the how how does it look at my CV?
Speaker 3 (12:44):
Right?
Speaker 1 (12:44):
Like, am I actually ever gonna end up getting that
senior title because my skills are kind of all overplaced?
But it actually turns out that was a boon because
now in this case For example, I we had like
a we wanted were looking for full stick people and
that company was to using alixis so what but a kay,
you did mobile development from the development that's like, it's
(13:04):
good that you have this holistic perspective on things. And yeah,
my specialization was back end, but it boils down to
being this T shaped engineer or the T shaped developer,
like having it dabled with a lot of different things.
And that was also like one of the main reasons
like how I ended up with my current employer, which
is basically then after that where we actually have a
mobile app we're building, and well, I know what it's
(13:27):
like to build a mobile app, but it's actually beneficial
from a back end and developer perspective to know the
daily targets of a mobile developer, to know what it
means when you have to work with a device where
the stable Intel connection is not guaranteed. And so yeah,
that is basically why I say the most traditional because
it boils down to me getting that senior title by
switching employers every three years. That was never a plan
(13:49):
from the get go. It's just how it ended up happening.
I hope that now I kind of am in a
place where I can stay a bit longer. I'm kind
of tired of switching all the time because then I
feel like I've two years you really have settled into like, Okay,
this is your work for a company, like you know
what you're doing. You you really start to feel familiar
with everything. It's just for me personally that always like
(14:10):
a different either an environment changed in a way I
didn't like, or a different opportunity came around the corner
which I just was too good to pass up. Yeah,
so this is my my my path to seniority, which
then boils down to always staying curious and trying on
different things and not being afraid to take a take
a jump into be unknown, you know. And it always
(14:31):
was of help for me personally that I'm just inherently
a very curious person and I always never stop when
I don't understand something. But but that's just like, well
my brain is wired like if somebody tells me that
this is just the way it works, and always like,
but why tell me why? I need to understand why.
And I think this is also like when you don't
need to have the quality to get the scene tight.
(14:52):
But it's very beneficial as a software developer in general,
because that was also something like in the beginning, like
you have I don't know, like you work in a
in a project and there's this framework and you think
this thing is magic, right, Like how does this thing work?
Like it does all these different things that I could
never write something like that. But if you then at
some point figure out, okay, this is how you work
with it, but how does it actually work? Most of
(15:13):
the stuff out there, as the liabil is out there,
they're not magic. It's just written by average people like
you're me, right, Like at the under the hood, it's
still code which does things. And I guess at some
point each of us could have come up with those
topics if they work long enough in that environment. It's
not magic. It's not magic source totally that it helps
to arrive. It helps out this curiosity mindset to arrive
(15:35):
at that conclusion earlier. Then that brought up them later
because I've also met software developers which were like, I
don't know. I get a ticket, I read my code,
I don't care right like, I'm done, I'm here here
for eight hours, I'm a warm body and leave and
that is fine. That is fine. That there is a
way to do this job, but it's not a way
or where you will excel at that job. But not
everybody needs to excel, right, I mean coming back to
(15:57):
that example of earlier, like if you're in a take
place like folks bog, at some point in the scale
of a company of that scale, somebody needs to write
some boring code.
Speaker 2 (16:07):
Yeah, totally, there's so much to impath there.
Speaker 3 (16:09):
Yeah, I totally agree with the last part where there
are like senior engineers too who like just like do
their job every day and like you know, do the
boring I guess like grind right, and they're senior probably
because of the value added the company in terms of context,
they hold on the code, right because it will take
them probably lesser time to do some work in that
code than a new engineer who's not famous familiar with
(16:30):
the code. Right, So they've seen a bit of.
Speaker 2 (16:32):
A value to add.
Speaker 3 (16:32):
But if they decide to leave the company, they might
not come across as a senior engineer because again they
haven't put work into growing and building that curiosity feeling,
that curiosity that you were talking about. And and there's
a perfect segue to a very shameless which I'm going
to make.
Speaker 2 (16:47):
I do agree. Curiosity and wanting to.
Speaker 3 (16:49):
Know how things work under the court, there's a correlation
of that to seniority, which is why there's a book
coming out that teaches you how to build the Phoenix
from thretch and I'm writing that book.
Speaker 2 (17:00):
It's going to come out in a couple of months.
Speaker 3 (17:02):
So if you're curious, if you want to take that
path of that kind of like an extreme curiosity, right,
how to build plugs, how do the plugs made?
Speaker 2 (17:09):
The plug library itself? How to build a websitever from
scratch just using DCP can engine.
Speaker 3 (17:14):
Right. This book talks you through that and eventually wrap
back like a nice meta programming interface.
Speaker 2 (17:19):
But leave a link to that in the show notes.
Speaker 3 (17:22):
But I totally again totally agree with'sashure that that's actually
also the preface of the book.
Speaker 2 (17:27):
Right to cross that bridge to seniority.
Speaker 3 (17:29):
Curiosity and like demystifying all this magic is like a
in my eyes, like almost a necessary phase to kind of.
Speaker 2 (17:37):
Be senior, like a true senior.
Speaker 3 (17:39):
When true senior is someone would be senior at most
places they would go not because of the context but
the tenure that.
Speaker 1 (17:45):
They have in a Yeah, I'm always bit careful for
like to senior like because that feels are a gate keep,
but maybe you could say not only a senior by title,
right right, And it.
Speaker 3 (17:55):
Is actually gain keeping for me, Like when I hire
engineers is something I very them forward like look for
you know, And yeah, the curiosity element and wanting to
know how things work is it's it's life gets so
much easier if you are managing or mentoring an engineer
who has the curiosity and what's the word capacity.
Speaker 2 (18:16):
Really you know to take in that knowledge because some
people just don't.
Speaker 1 (18:19):
Have the capacity.
Speaker 3 (18:19):
It's like to like dig into something, right, and it
just it just gets a lot. It's very easy to
mentor that engineer into an amazing scenior. And I've seen
I have mentored a bunch of those engineers. I've seen
them flourish and better engineers than me. And I saw
that when when I had them this this person will
be better than me, you know if if mentored properly,
and they ended up being better engineer than me. Right,
(18:40):
So I always always try to hire engineers in that category.
Speaker 2 (18:43):
And another thing for me, and you mentioned.
Speaker 3 (18:45):
Sasha about this too, and it's like a transition to
the code aspect.
Speaker 2 (18:48):
I do think it's very.
Speaker 3 (18:49):
Important that someone codes well too, and I think about
it at least when I hire someone, And I do
like to do a live coding interview, And I think
again with the value especially for right like the startup
who has like you know, less intention in team. If
you hire an engineer who quotes more your naturally, like
you know, they have coded so much that you know
(19:10):
it's not a chore for them to like, oh, how
should I do this? Like just simple who can do
simple tasks without really thinking much, you know, like as
a reflects action, right, have quote it enough that they
naturally put code that doesn't necessarily need refactoring, right, Like
all that it makes a huge difference when you have
like four people who quote like that. You add a
person who can't quote like that, right, Like, it just
(19:33):
changes dandmads completely. So it is that one one bad
apple situation. So I do get keep in that aspect
as well, Like I and if I'm hiring someone, that
person needs to be able to code think in code,
you know, so like as they write code, they're not
nationally but record because they've written enough code in their
life that they can churn out code for simple solutions
(19:54):
pretty easily. So and that that's great because in a
less productive day, less productive day, which all engineers have,
you know, it's like a highest party lays less party
days too, they'll they'll share our code for less less
complex solutions like okay, another deal, just another API called
just another test. Like I really like people who can
code as if they are talking, are thinking, you know,
(20:16):
it just comes naturally to them, and it's just another
means of communication.
Speaker 1 (20:20):
Now I wouldn't necessarily disagree. I just think and maybe
that is where I guess you could say that that
that that it depends right again, at the beginning, in
a startup environment, for like a small team, you really
want to like have everybody pull their weight in that context.
But if for example, in a legacy maintenance situation, right,
we have this system, it needs to keep it's running,
(20:42):
it's finished, it just needs to be keep keep running,
needs to be maintained, it needs to be updated. It's
like the completely different skill set where the ability to
write new code from scratch it's just as important. And
then again that is also fine. Right, there are people
who put who very much excel at that and very much.
It's it's an area where I probably you don't excel
that muscles. I never had to get to work in
(21:02):
a scenario such as that for a long period of time,
So yeah, it depends, But yeah, I agree that like
in a small team, it's very valuable to have a
group of experienced people who like to know what they're.
Speaker 2 (21:15):
Doing right and don't get intimidated by code. You know.
Speaker 3 (21:19):
That's another thing, Like some people make sense, so that's
another thing I look for. And again just too for
our listeners like who want to kind of place themselves
in that category. Like I clearly remember when I was
in a category and when I wasn't like the infelection
point that took me, and that was reading through a
Bruce stage seven languages and seven weeks work.
Speaker 2 (21:40):
Actually did seven languages in three days. I finish that
book in three days.
Speaker 3 (21:43):
But just coding through the exercises and for actually making
sure to follow exercise of that book to improve in
the code that's in the book. That's such a great
way to just like change how you approach coding, change
how you approach solving a problem stead of like instead
of thinking of you know them mental scale of a problem,
a problem that had mentally for me was at the
(22:05):
scale of like a day.
Speaker 2 (22:06):
After doing that, it shrunk to an hour.
Speaker 3 (22:09):
You know, oh, this should take me an hour, not
a day, you know, Like that infection point came after
in netbooks, so another book seven ninetes and seven weeks
cregoris that quickly. But that worked really well for me
and one of my mentees as well. But it really
helps to be at a place where code comes naturally
to you, especially in interviews, because trust me, it a
(22:30):
lot of times it blows people away when you are
literally coding.
Speaker 2 (22:34):
While talking, you know, and they're like, wait, how is
this happening? Right? And all it just took.
Speaker 3 (22:39):
All it took was a few days of hardcore coding
right to reach reach that point. So if if any
of our listeners want to be in that place, it's
hard work, but only for you know, a week or two.
And I think once you, once you find a ridden
that works for you, it's not that much hard work
after that.
Speaker 1 (22:55):
I'm not sure I would agree with that, to be honest,
because I think it might be the cause it might
have been the case for you, but I mean I
would expect that you already had some experience at that point.
Speaker 3 (23:05):
So I think it was very junior at that point.
I had less than a year of experience. And yeah,
I think I did have a lot of interest in passion.
I guess right that that is something I had. But
I mean another thing is I kind of wanted to code,
like that all things I want to code. I saw
a professor of my in my first year who kind
of fell in this category. Like when I went whenever
you'd see Courte, everyone would like just like in awe,
(23:26):
you know, like how is he just like coding as
if he has a mental compiler, you know, because he
doesn't need to run the code to make sure it's working.
Speaker 2 (23:34):
He just knows what to write. And I guess I
set myself side back goal for myself a while ago.
Maybe that's what helped.
Speaker 3 (23:40):
But I have seen it happen to one of my
mentees too, Like he also read through the same book
and in a week and he kind of had an
inflection point over the course of reading that book and
doing all textided as well. So it's not just one
data point, it's two days points. I do know it's
not much, but too more than one.
Speaker 1 (23:57):
Yeah, I can relate in the context of that, I
feel that like for me personally as a software developer,
I grew very much by having to switch paradigms. So
like when I when I switched from the classic complect
oriented program into functional programming, and to be honest, I
think it would probably be would have been the same
would have been true if I switch from functioning to
object oriented, because it just challenges a lot of biases
(24:19):
you might have had at that point, like okay, like
a lot of ideas how you can solve certain problems
because that's seck of the tools you know, and now
suddenly you have a completely different thing which works completely
different in your brain is like wait, what, but how
how can I solve a problem like this? And I
feel like at that point your brain kind of is
forced to find a more generalistic approach to problems exactly, And.
Speaker 2 (24:42):
That's that's kind of hidden what I was saying.
Speaker 3 (24:44):
The seventh problem in seven weeks has an option the
language back language Ruby, but it also has a pure
functional language, right, so maybe maybe that was part of
that doing that, But yeah, I do agree paradigm changing
paradigms is one of the best way to train your
mind as an engineer.
Speaker 2 (25:03):
I remember I did prologue. I was like, oh my god,
like just.
Speaker 3 (25:07):
Doing like the logic oriented programming was so foreign at
that time.
Speaker 2 (25:12):
But yeah, it evolved. It kind of evolves. As an engineer,
for sure, I totally agree.
Speaker 1 (25:17):
Yeah, And I think I mean, now, if you've spoken
a lot about writing code, I think one skill, which
in my opinion, is even more important than writing good code,
is being able to read and navigate code, because I mean, yeah,
if you are in a startup situation you have to
build a system from spetch, then writing code might be
a little bit more important. But let's be honest, how
often is that the case in day to day work?
(25:39):
Most of the time not.
Speaker 2 (25:40):
Reading is important even I agree.
Speaker 1 (25:44):
That most of the time you actually need to work
as an existing code base, you need to make modifications
to that. You probably will have to work broke with
code you have never seen in your life before, and
you need to figure out where the problem is if
it's a case of a bark, also where some part
of a log lifts you might want to change, and
how you change it. So I think that it's also
(26:04):
why I've used to also do live coding exercises for like, okay,
let's build something like that. But I'm kind of coming
around on that way. I say, I still think that
coding is like something you probably should do in the
context of an interview, because at the end of the day,
I don't see a better tool to figure out, okay,
is somebody actually capable of doing it. But I'm coming
around and saying like, it doesn't necessarily have to be
(26:25):
live coding, because some people might just be might not
be good on the live context, right, They're not very
good of like somebody they don't know looking over the shoulder.
But I in my perfect world scenario, my perfect interview scenario,
I would say, hey, we have this existing project. It's
maybe well prepared ahead of time. It's a small project
which I don't know provides an API in the context
of a back end and developer, right, and there's a
(26:46):
buck end there where you there's like maybe a feature
a thing you need to build, and they need to
change a feature. And then I would ask people to
set up a poor request like I actually go through
emotions of what you do day to day and navigate
this unfamiliar code base and see what they do. I
would potentially hide maybe one or two bucks in there
on purpose, maybe some bad variable naming, all those kind
of things, because in a very senior developer, I would expect, Okay,
(27:09):
they might might catch one of the bucks, they might
do some refactoring along them, maybe they might add some
missing tests, right, they might all do all of these
little things which help you maintain the health of a
project in the long run. And also I would expect
that from a senor developer, I would expect that they
challenge potentially what executly the requirements were in that interview context,
(27:30):
I would actually give some requirements to them which are
in some places deliberately vague, because it is like most
of the time you don't get a perfect ticket. You
get a ticket which is in some place is vague,
and then you have to ask questions, you have to
figure out what it actually means. And that is then okay,
you can practice your coding skills day in and day out,
and that is something I wanted to get at. You
can do. I don't like some lead skills challenges. You
(27:52):
can do exorcism a lot, which I think is actually
if you want to get better at coding in general,
and like at understanding problem and like how tests can
be written or you can write testable code how to
learn some best practices. Then Exorcism is actually a very
good platform because you have people mentoring you and like
especially if you engage with the mentors and reflector your code,
(28:13):
that's like potentially a way I can really learn these
best practices very well. But that only covers part of
the job, like on one one area of a job.
And this is what it for me means to have
somebody who is like a senior software developer, is I know,
let me let me started that talk about that differently. Basically,
So if I have like an early career development and
(28:34):
a junior developer, I would say, I give you a
well defined task. I give you a well defined problem,
and then point you where you need to put the
way you need to go to solve this right back.
For example, hey, this is a bug. This is the
code base, it's probably over there, figure it out right,
But this is like a very small, very small defined
probably like a mid level developer, I would expect, Okay,
(28:54):
we have this speech that we want to build, right,
this is a well defined area already, this is the
thing we want to build. This is like potentially inside
of the app instead of the screen it should change
to be like this, But now go figure out what
exactly you do in the best way how you can
do that. And for a senior, I would say, hey,
we have this problem. How do we solve this problem?
And I would not necessarily, like for really of a
(29:16):
senior developer, I would not expect to have any kind
of solution at that point. Yeah, you might have. You
might think this could be a good idea, but maybe
there's a different solution about this. Right. I want to
be able for like somebody who is really senior. I
want to be able to give you give them a
problem and they come with a solution. And then if
you think about it that way, coding is only part
of the like part of a tool set. And yeah,
you need to be very fluent in coding to actually
(29:38):
pull that off. But it's just like it's it's a
foundation what to build your your your skills as a
senior and developer, I would actually be curious about what
do you think about that? What I just to do?
Do you think it makes sense?
Speaker 3 (29:50):
Totally makes sense? Yeah, and I'm going to give you
this a year of I'm swying. It depends right, Yeah,
how much of that is true, depends really on your
definition are what pas? But overall the heart of it,
it makes a lot of sense, are yeah, And.
Speaker 1 (30:04):
I maybe I wouldn't say that like a senior then
has to come up with designs or anything. I might
still collaborated with somebody from from who is more in
the design area, but they would like a senior developer
would be really be responsible of figuring out, Okay, we
have this problem. This might be a possible solution to it,
but like we can delegate it right, Like this is
like I don't need to think about vinity details of
that anymore. I can trust somebody to deal with it.
(30:26):
And then when you look at that, there's a coding
in there. Yeah, but there's also people skills in there.
There's also like the general problem solving skills in there,
and there's I think a very strong ability of a
senior is also to decide when not to code. Because
there's a very great quote from Marco him Software. It
says like code is expensive to write, to maintain and
(30:47):
to something I forgot to run, and to educate, to educated.
Its means the right to maintain or to educate. So
if you have less, if you can solve this problem
of less code, you're better off so and exactly those
kind of thoughts and those kind of considerations are something
which for me, like where you would say people is
like a senior but this is an excellent sceniority developer.
(31:09):
This is really where where you can go beyond and
then at some point also go beyond the senior title,
like where you go. Okay, now now I'm going to
go into a leadership position. Now maybe you're going to
go into a principal area where to potential to make
a kind of the connection to some past episode like
what we talked about last week in the DVD episode, right,
(31:31):
like all the strategic work, and that has been something
like I've learned along the way in like this in
a small scale environment of six companies, six people, because I,
by necessity necessity had to do some of that work.
And then also instead of like the agency like getting
working with the customers, and then I looked into what
what's domato from design? Like whatever are the ideas there?
Like what what does it mean to speak the language
(31:52):
of stakeholders? All those kinds of things monologue and well,
I think.
Speaker 3 (31:57):
Just to add to one more thing, right, here's so
many things that are outside of coding that makes se engineer.
I think one more thing, probably lower in the priorities,
is someone who can be like a multiplier, someone who
who's addition to the team by either changing processes by
their inflicting inducing positivity and inducing there's some people just
(32:18):
induce passion and other people to like quote more and
you know, like change single handly can positively influence the
entire culture. Like you know, maybe post series A, like
big enough companies, it would it could have a huge difference. Yeah,
and I don't want engineer who might have be the
fastest in coding but very good at like designing and
architecture and like.
Speaker 2 (32:37):
But I think his contribution is like.
Speaker 3 (32:40):
The he I'll just give his name.
Speaker 2 (32:43):
His name is Jeffrey Mattias. He's the author of Testing
a Luxur.
Speaker 3 (32:46):
But he he was a community and I think he
is probably the biggest reason why a lot of engineers
work there or continue to work there. Right, he's single
handedly creates a positive work environment for everyone are most engineers,
and also keeps that normal relationship with them to help
them improve and grow. Right, I think that's huge during
(33:08):
that in itself even he's a very good corner. He
might have the fastest, and he is a very good
he's a very good set of architecture. But even without
all that, the value he adds just by being that person,
that glue is you know, principal engineerbility value.
Speaker 2 (33:24):
That makes sense.
Speaker 1 (33:25):
Yeah, yeah, that makes a lot of sense. And I
think I mean said that was something I said before
we press record. But I feel our industry and especially
like the social media space around, it's very much into
this hustle hustle hustle mentality, right, and that you have
to be a ten X engineer blah blah blah blah blah.
And I don't buy into a lot of these topics,
but I do think that sometimes you have people which
(33:47):
are close to their ten X engineer, not because they
write codes so well, but because they enable other people
to grun faster. And if you doesn't mean it, just
imagine if you have like a software developer who maybe
is average in code writing, right, but they're very good
at like actually coaching and mentoring and like helping people
find the answers. And then the people mentoring maybe three
(34:07):
juniors and they one of average. Maybe a junior might
need three days to solve a buck but with support
from them, like maybe even half an hour, one hour,
you cut that down to half a day. Boom, Yeah exactly,
it's a technic engineering. And that is really where I
said in the beginning. It depends like in some environments
in some context, I don't know, if you work in
(34:29):
like aerospace engineering and like you have right software for
a NASA probe, then yeah, other skills are important than
if you're in a big team where you have a
lot of early career engineers and to mental those and
all of the different skills are potentially important. And I
at this point in my career, I don't describe myself
as like I don't know a senior developer. I often
(34:50):
just say I solve problems. My my weapon of choice
is technology, but the end of the day, I solve problems.
And I think a good example of that is, like
I talked last week about the CDD workshop, we did
right and one outcome is this is, for example, now
that in the leadership round of a company were actually
talking about, Okay, do we need to do some organizational
changes because of the things we learned, because we see
(35:11):
some misalignment between the things we would like to do
the things the organization is currently structured around that, and
well how did that come to be? It came to
it was born from they want to have we want
to change our current software architecture because it's not really
aligned with how you think about the business. But we
first need to really learn how the business works and
how we as a company think about the business. And
(35:33):
I already suspect that we might get to hey, maybe
our organization structure sometimes. But you can't go in there,
go to the CEO and think that, hey, the organization
suctor suck, sucks, right, But I can go there and say, hey,
to actually build good software me to figure out how
the organization works.
Speaker 2 (35:47):
So it's not like there's like a.
Speaker 4 (35:51):
Lot my guy, yeah exactly, Like and that's a very
excellent book, which is got Team Topologies, which is basically
about that is like take Conway's law, Like everybody who
does not know Conway's Law is basically any any organization
which designs a system in a broad sense, which software
is a system is what is the exact wording.
Speaker 1 (36:12):
There is do doom doomed to like produce a copy
of the ication structure. I think it's opposite organization.
Speaker 2 (36:20):
I think it's opposite.
Speaker 3 (36:21):
The organization takes a structure of the domains and the
software naturally.
Speaker 1 (36:26):
Yea, all the other way around. It's actually any I'm
going to look it up. I'm going to.
Speaker 2 (36:32):
I know it goes both ways, but let's see.
Speaker 1 (36:35):
There's a very reverse Conway maneuver which actually takes that
into consideration.
Speaker 2 (36:38):
Oh, I think you're right, and you're right. Organizations, you're right.
Speaker 3 (36:41):
Organizations design systems that their own communications structure.
Speaker 2 (36:45):
Yep, okay, I.
Speaker 1 (36:46):
Haven't now any organization that designs the system defined broadly
will produce a design whose structure is a copy of
an organization's communications structure. And that is true. That is
just true. It's insanely true. Like if you have I
don't know. There's also like a very good rephrasing of that.
If you have four groups working on a compiler, you
got a four past compiler, and if you have five
groups are going to go past compiler. And that is
(37:07):
that true, because like that's the way we humans are,
our brains are wired. But it hints towards a significant
truth is you can't design software in a vacuum. You
can't ignore communications. You can't ignore people. It does not
work because software is written by people four people. How
can you remove people from that equation?
Speaker 2 (37:28):
Doesn't make sense?
Speaker 1 (37:29):
And I think that is like the core one of
the core things a software developed is like, really, if
you really grock that and like really work towards making
making improvements in that area in a holistic perspective, then
there's nothing stopping you from becoming an excellent senior and opinion.
Speaker 2 (37:45):
I agree, So yeah, yeah, I agreed.
Speaker 1 (37:52):
I guess there's so much there's so much to it,
and like I said, that's an excellent book form. It's
called team Team Topologies, which is basically about taken this
idea of Conway and like, okay, what what does that mean?
Like how can you then structure organizations to actually deliver
the kind of software you want to build? Because this
is this is a nice side effect that if you
accept that this is true, you can say, okay, so
now how do we need to build our set up
(38:13):
our teams. We get the architecture you want to get
to get like the system you want to get them
to get fast flow where we want to get it.
And yeah, this then leaves the realm of senior developer
of responsibilities. But this is something that I've always done
in my career, Like I always when I came to
a point of okay, this is like my responsibility bubble,
I always look beyond, always like okay, like what does
(38:34):
that mean? Like I see some issues and I see
some people talk about this Conway's law thing, Like what
does that mean? Like, let me look it up. And
while I was never in a position in that particular
moment to actually impact the organization and structure, it made.
It gave me context. It gave me understanding about why
things were are the way they are, which then boils
down to again like I wanted to figure out why
things out the way they are, and it always enabled
(38:55):
me then to go the next step in my career, right,
like because I already diged into some of these topics
and that helped me to go further. And now I
may that I basically since the beginning of this month,
I've been a technical team lead at my my current employee,
because I bring like a lot of these talking about
actually helped me get stead title right. And now, like
(39:18):
I said, we have this discussion in the team in
the lead circle, Okay, but do we need to do
organizational change. This design never stops.
Speaker 2 (39:27):
Yeah. Yeah.
Speaker 3 (39:29):
In fact, that's funny you mentioned we were just talking
about how and this is when the reverse conway, right,
like how the US defining and domain in our software,
which again without getting too much into this, after you know,
patient pace for our service and like starting creating that
as an entire domain will inevitably create its own engineering team.
Speaker 2 (39:50):
Right because it don't mean it is really different. So
we just had a conversation.
Speaker 3 (39:54):
Yeah, you're right, like those kind of conversations are also
being part of being.
Speaker 2 (39:57):
Like a senior senior. Yeah, seniority.
Speaker 1 (40:02):
Yeah, and I think that maybe to cam some nerves
of it, you don't have to do all of that,
but it really helps because by the nature of these topics,
you will touch on a lot of subjects which are
then very relevant to your today work. Yeah, but maybe
to go back to something we said earlier, because I mean,
like I set a set that helps you to figure
(40:23):
out why things are the way they are, and that
is also like in the small scale and again that
we talked about, Hey, figure out why like that that
for example, Phoenix is not magic, but also OTP is
not magic, right, and it's the same, like you understand
how the system as a whole actually why why it
works the way it does, right, and you don't just
use processes and elixir. You've understand how they work and
(40:44):
that enables you to do other things. And there's also
a book on that and which I think has not
aged that well because it's been quite updated a lot,
but it's the little Elixir and OTP going. Yeah, it's
a great book. I'm not sure how like it's I
think it's elix A one point three or something, so
like you have to navigated a bit carefully in that context,
(41:06):
but it's what it basically does. It makes you rebuild
some of the primitives of OTP, like a supervisor and
an exam server and all those kinds of things, and
that really enables you to like figure out, Okay, how
do you want to design systems and stable systems instead
of ODP and why are things the way they are?
So yeah, I feel like we've kind of given a
(41:26):
complete maybe to come back to one subject of the
beginning side project, I mean, like, especially for exmple getting
fluid with code. Side projects are a great way to
go about it. But you don't have to like I'm living,
I'm living proof of it.
Speaker 3 (41:41):
I mean it's a good way of like getting more
experience and less less of experience, right like, and also
getting opportunities to solve problems that you would not have
device anymore, especially if you're working like a big organization,
a lot of bureaucracy, a.
Speaker 2 (41:54):
Lot of you know, red tape. I guess you know.
Speaker 3 (41:57):
Then the side projects can be opportunity to explore topics.
I think the part of in durn design and explore things.
Speaker 1 (42:05):
I was always in a very luck, to be honest,
privileged position to never never have to work on boring
stuff like it was always challenging in one way or
never right now, My job right now is not challenging
because we solve super hard technical problems, but well I
have to know, solve organization problems, so it's it never
(42:26):
has been boring. So I never had the inherent desire
to say, okay, I want to have more even more
challenges outside of mine. But I always like what I
like to do occasionally is been like I've done a
fair bit of like advent of coding, and I did
it and has skill just to tickle my brain in
ways work cannot and I also did the Pure Scripts
track on on on Exorcism, Like I didn't complete it right,
(42:48):
but I did that. So that's to look beyond the
my immediate horizon. So yeah, you can do hYP projects.
You don't have to do hype projects. It's maybe your
place of work also gives you some some time time
to grow as as a developed provide some some innovation
time or whether you might want to call it some
twenty percent time. That can be an excellent source of
side product. And that's that's where most of my open
(43:09):
source work comes from. And I've worked at places where
we could invest some of our time into work related topics,
but not directly, like I didn't have to contribute towards
solving a concrete problem at work, but they still had
to be related to my teraately work. So I couldn't
do yoga at that time. But I was perfectly fine
to write an open source library and to scratch like
a personal each of mine out of work. For example,
(43:30):
that's where Nigger was born, which was the main reason
why I want this spam podcast, why I always invited
in the beginning. So yeah, side projects can take many forms.
They don't have to be from your free time. As
I mentioned in the past, I have two kids, I'm married,
I don't have a lot of time on my hands. Okay.
And while I while there are a gazillion things I
would like to build, I still have like this ideal
(43:52):
about some application to help organize gaming events with friends.
It's just not high enough on my list of priorities
to end up on my schedule. Okay, then I guess
we can transition to pics. Yes, do you have any
picks for us?
Speaker 2 (44:05):
Yeah? Not really. I mean the two books that I mentioned.
Speaker 3 (44:09):
Check out my book if you want to learn how
Phoenix is built, and definitely check out Seven Languages and
Seven Weeks by Bruce Take.
Speaker 2 (44:15):
It actually covers.
Speaker 3 (44:16):
It has Haskell and Prologue, two of the most amazing
paradigms I've worked with. If you guys want to change
yourself with the paradigms, prolog and Haskell a great and
this book has them. Yeah, I think, I think, Oh, well,
one more thing. I it's not a lily brilliant. Maybe
it's a very small point. Like the one thing. As
you learn and as we start to contribute and take initiatives,
you have to show that you are gaining in seniority.
(44:39):
Just be careful of just doneing Kruger's effect, right, Like
that's something you don't want to make a fool of yourself.
Speaker 2 (44:44):
Just make sure you know what you're talking about.
Speaker 3 (44:47):
And I know most people engineers don't have that, but
it's something I had an affinity towards.
Speaker 2 (44:53):
And I've kind of made a full of myself early
on a couple of times in my career. So in
any respect, it is like when you know, when you
think you.
Speaker 3 (44:59):
Know a lot more than you actually do, and it's
happened to me a couple of times, So it's it
could be embarrassing and it could be also hard to
arrange that impression already need do on someone, So just
side pick. Also video games, right, I've forgotten that Vio
video games. Now, man, I was going to pick Yeah,
I think it pickstraight already.
Speaker 2 (45:18):
I think I already picked straight. Yeah, I think all
my games have been picked. Well.
Speaker 3 (45:21):
Yeah, if you guys are not aware, the next Hour
of War is coming out in a couple of months,
and so yeah, this is pre order it it's going
to be amazing.
Speaker 2 (45:31):
Or no is good.
Speaker 3 (45:33):
That's how that's how, that's how engineers get paid more
based on the preorders. That's how these gaming companies to
determine success, and that's how game engineers salaries. It significant
influences gaming engineers and salaries and post release sales if
you do pre orders.
Speaker 2 (45:50):
That's something I learned recently.
Speaker 1 (45:51):
So, but it also encourages to deliver city product, because
I mean, if you're already made bank, I don't make
a great product. I'm going to say this is the case.
Speaker 2 (45:59):
For a God of Or, But generally companies pre orders.
Speaker 3 (46:02):
Generally complete these pre order early post orders for the
next game at the current game, they already have money
allocated from patches and stuff. Generally, that's how it works,
unless you're like a very new studio. But anyway, I
think you should pre order. I think you shouldn't furnish
that if you guys have played the first goal of War.
Speaker 2 (46:20):
I'm pretty sure. I'm for sure.
Speaker 1 (46:22):
I'm pretty much in the camp of patient gamer. I
always pretend that the game gets released two years later,
and then I have like a full picture about how
good is this game. It's the deal's other deal, C
is worthit? And oh it's only twenty bucks.
Speaker 3 (46:36):
Yeah, only if I could fight just the addictive feeling
of that instant gratification.
Speaker 2 (46:43):
Right.
Speaker 3 (46:43):
But you know, if if I was mature enough to fight,
then I would follow the category.
Speaker 2 (46:48):
But I wanted as soon as it's.
Speaker 1 (46:49):
So fair enough, I get it. But for my wallet,
it's been very good. I have a bunch of picks,
and I would like to repick some things I picked
in the past already, so I would first one we
pick is Specification by Example, and it's an excellent book,
but it's a very basically is a book about doing
a case study on different projects and different companies doing
(47:10):
different things, and the author expected some dos and don'ts
from from from these different projects, and maybe maybe not
that surprisingly, it has a lot of overlap with some
of the ideas from DOMAINO from design, even though it's
not a DOMAINO of design, not at all, Like there's
never a single mention of the world DOMAINO of and
design in the book, but there's close collaboration with stakeholders,
with experts and so on and so forth, and it
(47:32):
is definitely something if like, if you really want to
like get closer to that seniority title, that senior title,
it's a very worth you'll read because it's very interesting
to see like how projects succeed and don't succeed. It's
also a very cool I think it's from this book,
but sometimes I mix some books up. But I think
in that book as like an example of like how
the F sixteen, like the cup fight at Fight Jet
(47:54):
fighter jet what was built and originally in the specifications
it's said, hey, we want to have jet which can
get muck whatever I don't know, six seven whatever, like
get this high speed, and at that point in time
was kind of difficult to pull that off. And then
like the company who took that contract, they've asked why, why, why,
why why do you want that? And it turns out
(48:15):
the reason was that it needs to escape from combat
if things go sour. So what they ended up building
was not a jet which could get that speed, but
we were super maneuverable, so it could just out maneuver
the opponent and get out of combat that way. And
the sixteen, as far as I know, it's still in
service today even though it's quite old, because well it's
actually taken the underlying problem and found a different solution
(48:35):
to that. It's very very well if you read even
in this is a software development book, but it takes
examples from all kinds of industries and how you actually
want to solve problems and find solutions. So specification by example,
and it has been written by go Ajit right, great author.
Generally it has some very wise things coming from this
(48:56):
this person. Okay, another pick I would like to do
and already hinted at an earlier exorcism excessism, which is
a great platform if you actually want to well baby
devil in other languages, want to learn some best practices.
It's like a it's an page where you can do
code exercises, but you also have people volunteering. We have
free time to mentor so like you can submit solutions
(49:18):
and then you can get somebody to mentor to give
feedback on the solution, kind of like a code of view,
and it's really helpful and like getting an idea about
some of the best practices in the language, like how
you might want to solve how you how you should
approach solving problems in some languages. And if you are
in your state and in your state of your career
(49:38):
where writing code fluently is still not something which comes
naturally to you, then that's not the worst place to
go to to be honest. And then last but not least,
I'm now going to do a shameless self pick because
we talked about okay, what is what is something like
coding and reading code and all the kind of coding
topics are just something which is helpful in getting the
(49:58):
senile title, but not its lusively. There's much more to
being a bit of a developer. And a few years
back I actually gave a talk which was titled you
know nothing or do you? And that was at the
height of the John Snow Grace And then this is
the game of Ronan's Grace. So it's like it has
some references in it, but what it boils down to
is talking about, Okay, we have software developers. We like
(50:20):
to define ourselves by our skills, but our abilities to
write JavaScript, to write Elixir, to do react well, to
be built great APIs. But there is more to each
person than just these technical skills, and there's more to
you to each person bringing experience in from all kinds
of areas. For example, in the talk, I give an
(50:41):
example of I'm very calm in like stress situations, and
I try to reflect on what I do wrong. And
actually that's a skill I attained by playing a lot
of League legends because bring a lot of solo cure
gaming where the only person I can reasonably influence myself.
So yeah, that is the kind of what what this
whole talk hints at. It's like, yeah, maybe some people
(51:03):
think I don't know nothing, how can I ever be
a great software developer? But there's probably more skills you're
not even aware of you bring to the table than
just your ability to write other script So yeah, I'm
going to pick that talk. Okay, those are my free picks.
So what's a pleasure is always uddie and I hope
you also enjoyed the episode, folks, and tune in next
(51:25):
time if another episode of AlSi mix bar
Everybody, and welcome to another episode of the Elixier Mix.
And this week on the panel we have Addi, Iron
Gar and me Social World. It's again a small round
because kind of fits cozy enough. And Addie and me
have been thinking what we do we talk about today,
and we want to talk about seniority, seniority in the
countries of software development. So you could also she wants
(00:27):
to have a clickbait title for the because you might
name it. How do you how do you get a
tasty senior title? So yes, it was an idea of you, Addi.
So why don't you take the helm and tell us
what made me think of this topic?
Speaker 2 (00:39):
Yeah?
Speaker 3 (00:40):
So, yeah, lately a lot of the people I mentor
have been asking this question to me, And I know
Chuck told us a while ago that good amount of
our listeners are early mad engineers, so I thought that
this would be a good topic.
Speaker 2 (00:51):
But yeah, I mean, one thing I wanted.
Speaker 3 (00:53):
To cover is, like, you know, there's like no single
path to that seniority, right, and we can try to
like talk about things that might actimize the likelihood for
you to get there. But luck, like Sasha not talking
about before recording that luck is the biggest is probably
the biggest factor and really decides that what works for you, you know,
you making an individual also is a big thing. Like
(01:15):
for example, we talk about side projects, right, and like,
I is pretty much never a point in.
Speaker 2 (01:19):
My life where I don't have an active side project
going on.
Speaker 3 (01:22):
Like ever since I started coding in twenty eleven, even
when I was at a student whereas startlist that he
almost never had.
Speaker 1 (01:28):
A side project, that is, outside of projects, I don't
do side projects.
Speaker 3 (01:34):
Yeah, so each engineer can like take different paths, you know,
and still you know, be a very good engineer and
be a seniorque senior engineer. So uh yeah, I do
want to preface this whole episode by saying that.
Speaker 1 (01:48):
Adie, have you actually seen my coded Maybe maybe.
Speaker 3 (01:53):
That's another thing, you know, like do you define a
senior engineer as someone who writes good code or defines
the engineer as like this like kind of a meta
term of you know, someone who knows what they're talking
about right, from an architectural perspective, from someone who has experienced,
someone who through experience has developed the sixth sense of
(02:13):
what's the right thing to do right? So quote is
important as well, But I think I generally use the
ladder things that are described to the financier engineer. So yeah,
even if I even though I'm not senior quade, Sasha,
I've talked to you enough, I tell you're a senior engineer.
Speaker 1 (02:27):
I'm also gonna like to answer your question like, how
do you define a senior engineer? I'm going to give
you a very senior answer and then say it depends
because it is actually a question we've been tackling at
the current job. Also, like because at the Instatus Quo
and we have senior engineers, we have mid level engineers,
we have early career engineers. Actually prefer the trum developers
(02:48):
because I think there's a very good article series from
hel Way Anyway it goes into a software development actually
engineering category and spoiler, the answer is sometimes it is.
Most of the time it's not. But yeah, I'm aggressing.
So we had basically the same topic about, Okay, we
have we have some seniors, we have some mid levels,
we have some early career people. What criteria are we
actually applying to that because until that point that was
(03:10):
pretty much nearly really yet you're senior and you're not,
But why right? And we now have like a like
some levels and expectations attached to that, and what we
ended up with is not something where you say, this
is like I don't know, like like a list of
things you need to check the boxes and then your
senior boom. But it's more of an aspirational topic. So
like a very good senior would potentially check all of
(03:31):
these boxes, but realistically speaking, most people probably won't. And
then you can actually look at that and say, okay, hey,
this is like some skills. Maybe it's a mid level engineer,
you already check that senior box, but it's also some
room to growth on that, like because there are some
topics where you're more in the early career area, and
then you can actually talk about, okay, what are some
(03:51):
growth areas, what are some topics you might want to
look into? And yeah, code and code quality is part
of that, but it's not everything at all, and knowing
you too is part of that, but it's not everything
at all. So if you have had somebody and you
and they have no freaking clue how to write any
kind of code yet, then probably no senior developer. But
(04:11):
if they're a decent at writing code but have like
some very good understanding about like the ICD pipelines, right,
like how to set that up properly and maintainable, how
to potentially design a system in a bigger sense to
be like have like faith safes, consider educases, all those
kind of topics. Then all of those contribute towards getting
having a senior mindset. And then it might be okay
(04:35):
that maybe the code you writer is like just just average,
you know, just like average everyday code, not great, not terrible,
and still you could very much call yourself a senior developer.
So I would actually, because I mean it is just
said that path to seniority can be very different for
different people. How was your path to seniority?
Speaker 3 (04:54):
That's a great question. Yeah, I think I got super lucky.
As I said, like, it's a huge country and factor
for this job. It's actually a funny story. I had
offers from multiple companies. After a couple months of not
having any offer, I got, like entering a ton, I
got cuddenly I got a bunch of offers at the
same time, and I picked a small company with the
(05:16):
salary almost half of the highest salary I was offered.
The companies that I got offered form IBM was one
of them, which half in the highest salary. And there's
this company in the middle of Boston called Anti Sam
where a startopy they were thinking of doing ALICKXA. At
that time, it was like twenty fifteen. It was like
just one point zero and Phoenix wasn't one point zero.
(05:37):
So I was prett excited about that, and I got
paired with the CTO of the company, and I chose
to go there because I had a positive instinctive feeling
that if I go here, I will really enjoy and
I was not probably financially, I guess mature enough at
that point to think that, you know, double the salary
could really make a huge difference.
Speaker 2 (05:57):
So I was like, ah, I this sounds great.
Speaker 3 (05:59):
I'm gonna go work at this company and needs money. Yeah,
Well what happened is like my first project because I
was pared the CTO ware are two people team.
Speaker 2 (06:09):
My first project was a SECO level project was.
Speaker 3 (06:11):
Architecting and building a new software which talks to like
a legacy rails app and writing it in lixter when
Phoenix was just one point zero, right, And I was like,
that experience just chreeged my mind right, Like instead of
using packages that people have written and the lex community
at that time, it was so new. We were building packages.
We built the authentication package. We didn't use device and rails,
(06:34):
we built the device right. And like that experience two
hours of working in a project like it is equal
to like a day eight hours of working in a
project that's not like that. So again got super lucky,
and that fuel the passion I already had of courting
and allowed me to do site projects and like writer
open source libraries and kind of like try to push
my site projects beyond my work projects. I can bring
(06:57):
something into our work projects to impress r C, who
is like you know, there's like a godlike figure like
in my eyes, like here's Here's Still the best Enginet
I've worked with. We actually had him on this podcast.
Eric he built Eric stillim mus name he built it.
He started his own company a few months ago. We
had him a couple months ago. But anyway, uh yeah,
(07:17):
like having that beginning to my career, I was extremely lucky.
And you know because of that Elixir experience and initial
you know, learning the salary also if I'm probably much
higher than what.
Speaker 2 (07:30):
I would have been if I have stayed in IBM. Right,
So that worked out.
Speaker 3 (07:33):
You know, it worked out because I did not have
financials to make quote unquote the right financial decision at
that time, and went with my gut and got paed
luckily with the CTO and kind of had a company
that believed in me.
Speaker 2 (07:46):
Right.
Speaker 3 (07:46):
It's actually quite funny because that company I started my
own company twenty eighteen as well, and this is the
company I joined.
Speaker 2 (07:51):
They mentored me to start my own company.
Speaker 1 (07:54):
You know.
Speaker 2 (07:54):
Again, it's just a bunch of series of.
Speaker 3 (07:56):
You know, lucky breaks one after the other, which again
is the over arching kind of theme of career current
development in my eyes is luck.
Speaker 2 (08:03):
But Sasha, what was your path? Clear?
Speaker 1 (08:07):
I would expect that my path is a bit more
traditional in that sense, Like basically I came out of
my when I had my degree, right, I started at
a smallish consultancy slash agency, which had a very big
work in contract with Volkswagen. So I actually worked at
the software development part of Volkswagen. We didn't write any
(08:30):
code for CAST. We actually brote software which was used
by different parts of Volkswagen to give build to basically
set builds between each other. So the building internal top
Folkspargen building software. Yeah that exists. That was all a job.
And the thing is, like I worked there for roughly
(08:53):
two years, and that was at least it was a
very interesting experience in the context of learning the ropes
of like what agile development actually means, because I have
to say, like, while there was a lot of technical
debt at that place, they actually did scrum real well,
Like that was the really working system they had. They
had there and then a particular part of Folks Bargen
(09:14):
So still think to that day that that probably is
the best implementation of scrum I've seen it. So that
was like an interesting experience to see like how how
you can potentially deal with like changing requirements things, doing
estimations in a big group of developers, all the kind
of things. But I left there after two years because
it was in Folks Barkers and Volsburg and I don't
(09:35):
come from that area, so I wanted to go back
where I originally came from, back to family, back to friends,
and then I started a very small company because I
also like Folks super big company. By yeah, I wasn't
directly working for an employee of Folks Bargn, but I
was still like a super big environment, right, corporate environment,
And so I went to a very small company where
is it all kinds of things like, I mostly did
(09:56):
iOS development, but I also did some web development, I
did some backgand development and PHP. I at some point
did some embedded development in C So I ubbled with
all kinds of things. I then, after two years again
left there because it was actually too small for me.
It was too stressful, like just being happy to have
to handle all of that. But it was also a
very valuable experience in the context of having to see
(10:18):
the full project product life project life cycle right because
we didn't have any product project managers that didn't exist.
That was like a company of like six people, so
we had a little lot about ourselves sit in the
rooms with customers alsoves like thick with their things out.
So that gave me a very valuable perspective on what
it actually means at the end of the day to
take customer requirements, take something to customize an idea about
(10:39):
and make make create working software on that. Then I
ended up at a mid level company because I figured, hey,
folk smart and too big, right, six people too small?
Why not for a mid level it was like, I
don't know, like eightysh people said at that point, I
think where I originally encountered elixir and that was just
classic agency work. So and that was yeah, but that
(11:01):
was also an interesting available experience in the countries because
I said, Okay, I want to do more back end work.
That was the part of the things that did before,
which which I enjoyed most. And then that project also
at some point took over some technical not lead ownership.
I didn't have any like I didn't lead anybody, but
I was basically the technical link to the customer. So
(11:21):
like we had to always like a two fold set
up with like a project manager and somebody who had
like technical architecture perspective. So that was something where I
really started to dig into what it actually means to
figure out, Okay, people say they need X, but actually
they need why, right because they have to drill down
to what it actually what they actually mean when they
(11:41):
say the X and those kind of topics and that
at that point, I was still like, of course, at
poke one I was early careers lest junior. Then at
the middle of a company, I was just a developer,
right like everybody just was just a developer there, and
then I was like hired as a mid level back
end engineer and the developer at that company and then
my next company because I figured, okay, now I did
(12:03):
did mid level company size. I actually like that, but
I don't like this project agency work because it's just
super stressful. You kind of have always a bit of
had that ting with customers because they think you want
to oversell them, even though maybe you don't, so it's
not really it's like more of an antagonistic relationship than
like a collaboration relationship. So I was, hey, let's do
product work. Product work is like more aligned everybody's land
(12:24):
and also delivered best possible thing. And that is then
where I landed my first senior job. And up until
that point I was kind of concerned because like I
did all kinds of things, but like a JAVA, I
did it embedded, I did development, that in front of development,
and did all these different things. I was like, that's
the how how does it look at my CV?
Speaker 3 (12:44):
Right?
Speaker 1 (12:44):
Like, am I actually ever gonna end up getting that
senior title because my skills are kind of all overplaced?
But it actually turns out that was a boon because
now in this case For example, I we had like
a we wanted were looking for full stick people and
that company was to using alixis so what but a kay,
you did mobile development from the development that's like, it's
(13:04):
good that you have this holistic perspective on things. And yeah,
my specialization was back end, but it boils down to
being this T shaped engineer or the T shaped developer,
like having it dabled with a lot of different things.
And that was also like one of the main reasons
like how I ended up with my current employer, which
is basically then after that where we actually have a
mobile app we're building, and well, I know what it's
(13:27):
like to build a mobile app, but it's actually beneficial
from a back end and developer perspective to know the
daily targets of a mobile developer, to know what it
means when you have to work with a device where
the stable Intel connection is not guaranteed. And so yeah,
that is basically why I say the most traditional because
it boils down to me getting that senior title by
switching employers every three years. That was never a plan
(13:49):
from the get go. It's just how it ended up happening.
I hope that now I kind of am in a
place where I can stay a bit longer. I'm kind
of tired of switching all the time because then I
feel like I've two years you really have settled into like, Okay,
this is your work for a company, like you know
what you're doing. You you really start to feel familiar
with everything. It's just for me personally that always like
(14:10):
a different either an environment changed in a way I
didn't like, or a different opportunity came around the corner
which I just was too good to pass up. Yeah,
so this is my my my path to seniority, which
then boils down to always staying curious and trying on
different things and not being afraid to take a take
a jump into be unknown, you know. And it always
(14:31):
was of help for me personally that I'm just inherently
a very curious person and I always never stop when
I don't understand something. But but that's just like, well
my brain is wired like if somebody tells me that
this is just the way it works, and always like,
but why tell me why? I need to understand why.
And I think this is also like when you don't
need to have the quality to get the scene tight.
(14:52):
But it's very beneficial as a software developer in general,
because that was also something like in the beginning, like
you have I don't know, like you work in a
in a project and there's this framework and you think
this thing is magic, right, Like how does this thing work?
Like it does all these different things that I could
never write something like that. But if you then at
some point figure out, okay, this is how you work
with it, but how does it actually work? Most of
(15:13):
the stuff out there, as the liabil is out there,
they're not magic. It's just written by average people like
you're me, right, Like at the under the hood, it's
still code which does things. And I guess at some
point each of us could have come up with those
topics if they work long enough in that environment. It's
not magic. It's not magic source totally that it helps
to arrive. It helps out this curiosity mindset to arrive
(15:35):
at that conclusion earlier. Then that brought up them later
because I've also met software developers which were like, I
don't know. I get a ticket, I read my code,
I don't care right like, I'm done, I'm here here
for eight hours, I'm a warm body and leave and
that is fine. That is fine. That there is a
way to do this job, but it's not a way
or where you will excel at that job. But not
everybody needs to excel, right, I mean coming back to
(15:57):
that example of earlier, like if you're in a take
place like folks bog, at some point in the scale
of a company of that scale, somebody needs to write
some boring code.
Speaker 2 (16:07):
Yeah, totally, there's so much to impath there.
Speaker 3 (16:09):
Yeah, I totally agree with the last part where there
are like senior engineers too who like just like do
their job every day and like you know, do the
boring I guess like grind right, and they're senior probably
because of the value added the company in terms of context,
they hold on the code, right because it will take
them probably lesser time to do some work in that
code than a new engineer who's not famous familiar with
(16:30):
the code. Right, So they've seen a bit of.
Speaker 2 (16:32):
A value to add.
Speaker 3 (16:32):
But if they decide to leave the company, they might
not come across as a senior engineer because again they
haven't put work into growing and building that curiosity feeling,
that curiosity that you were talking about. And and there's
a perfect segue to a very shameless which I'm going
to make.
Speaker 2 (16:47):
I do agree. Curiosity and wanting to.
Speaker 3 (16:49):
Know how things work under the court, there's a correlation
of that to seniority, which is why there's a book
coming out that teaches you how to build the Phoenix
from thretch and I'm writing that book.
Speaker 2 (17:00):
It's going to come out in a couple of months.
Speaker 3 (17:02):
So if you're curious, if you want to take that
path of that kind of like an extreme curiosity, right,
how to build plugs, how do the plugs made?
Speaker 2 (17:09):
The plug library itself? How to build a websitever from
scratch just using DCP can engine.
Speaker 3 (17:14):
Right. This book talks you through that and eventually wrap
back like a nice meta programming interface.
Speaker 2 (17:19):
But leave a link to that in the show notes.
Speaker 3 (17:22):
But I totally again totally agree with'sashure that that's actually
also the preface of the book.
Speaker 2 (17:27):
Right to cross that bridge to seniority.
Speaker 3 (17:29):
Curiosity and like demystifying all this magic is like a
in my eyes, like almost a necessary phase to kind of.
Speaker 2 (17:37):
Be senior, like a true senior.
Speaker 3 (17:39):
When true senior is someone would be senior at most
places they would go not because of the context but
the tenure that.
Speaker 1 (17:45):
They have in a Yeah, I'm always bit careful for
like to senior like because that feels are a gate keep,
but maybe you could say not only a senior by title,
right right, And it.
Speaker 3 (17:55):
Is actually gain keeping for me, Like when I hire
engineers is something I very them forward like look for
you know, And yeah, the curiosity element and wanting to
know how things work is it's it's life gets so
much easier if you are managing or mentoring an engineer
who has the curiosity and what's the word capacity.
Speaker 2 (18:16):
Really you know to take in that knowledge because some
people just don't.
Speaker 1 (18:19):
Have the capacity.
Speaker 3 (18:19):
It's like to like dig into something, right, and it
just it just gets a lot. It's very easy to
mentor that engineer into an amazing scenior. And I've seen
I have mentored a bunch of those engineers. I've seen
them flourish and better engineers than me. And I saw
that when when I had them this this person will
be better than me, you know if if mentored properly,
and they ended up being better engineer than me. Right,
(18:40):
So I always always try to hire engineers in that category.
Speaker 2 (18:43):
And another thing for me, and you mentioned.
Speaker 3 (18:45):
Sasha about this too, and it's like a transition to
the code aspect.
Speaker 2 (18:48):
I do think it's very.
Speaker 3 (18:49):
Important that someone codes well too, and I think about
it at least when I hire someone, And I do
like to do a live coding interview, And I think
again with the value especially for right like the startup
who has like you know, less intention in team. If
you hire an engineer who quotes more your naturally, like
you know, they have coded so much that you know
(19:10):
it's not a chore for them to like, oh, how
should I do this? Like just simple who can do
simple tasks without really thinking much, you know, like as
a reflects action, right, have quote it enough that they
naturally put code that doesn't necessarily need refactoring, right, Like
all that it makes a huge difference when you have
like four people who quote like that. You add a
person who can't quote like that, right, Like, it just
(19:33):
changes dandmads completely. So it is that one one bad
apple situation. So I do get keep in that aspect
as well, Like I and if I'm hiring someone, that
person needs to be able to code think in code,
you know, so like as they write code, they're not
nationally but record because they've written enough code in their
life that they can churn out code for simple solutions
(19:54):
pretty easily. So and that that's great because in a
less productive day, less productive day, which all engineers have,
you know, it's like a highest party lays less party
days too, they'll they'll share our code for less less
complex solutions like okay, another deal, just another API called
just another test. Like I really like people who can
code as if they are talking, are thinking, you know,
(20:16):
it just comes naturally to them, and it's just another
means of communication.
Speaker 1 (20:20):
Now I wouldn't necessarily disagree. I just think and maybe
that is where I guess you could say that that
that that it depends right again, at the beginning, in
a startup environment, for like a small team, you really
want to like have everybody pull their weight in that context.
But if for example, in a legacy maintenance situation, right,
we have this system, it needs to keep it's running,
(20:42):
it's finished, it just needs to be keep keep running,
needs to be maintained, it needs to be updated. It's
like the completely different skill set where the ability to
write new code from scratch it's just as important. And
then again that is also fine. Right, there are people
who put who very much excel at that and very much.
It's it's an area where I probably you don't excel
that muscles. I never had to get to work in
(21:02):
a scenario such as that for a long period of time,
So yeah, it depends, But yeah, I agree that like
in a small team, it's very valuable to have a
group of experienced people who like to know what they're.
Speaker 2 (21:15):
Doing right and don't get intimidated by code. You know.
Speaker 3 (21:19):
That's another thing, Like some people make sense, so that's
another thing I look for. And again just too for
our listeners like who want to kind of place themselves
in that category. Like I clearly remember when I was
in a category and when I wasn't like the infelection
point that took me, and that was reading through a
Bruce stage seven languages and seven weeks work.
Speaker 2 (21:40):
Actually did seven languages in three days. I finish that
book in three days.
Speaker 3 (21:43):
But just coding through the exercises and for actually making
sure to follow exercise of that book to improve in
the code that's in the book. That's such a great
way to just like change how you approach coding, change
how you approach solving a problem stead of like instead
of thinking of you know them mental scale of a problem,
a problem that had mentally for me was at the
(22:05):
scale of like a day.
Speaker 2 (22:06):
After doing that, it shrunk to an hour.
Speaker 3 (22:09):
You know, oh, this should take me an hour, not
a day, you know, Like that infection point came after
in netbooks, so another book seven ninetes and seven weeks
cregoris that quickly. But that worked really well for me
and one of my mentees as well. But it really
helps to be at a place where code comes naturally
to you, especially in interviews, because trust me, it a
(22:30):
lot of times it blows people away when you are
literally coding.
Speaker 2 (22:34):
While talking, you know, and they're like, wait, how is
this happening? Right? And all it just took.
Speaker 3 (22:39):
All it took was a few days of hardcore coding
right to reach reach that point. So if if any
of our listeners want to be in that place, it's
hard work, but only for you know, a week or two.
And I think once you, once you find a ridden
that works for you, it's not that much hard work
after that.
Speaker 1 (22:55):
I'm not sure I would agree with that, to be honest,
because I think it might be the cause it might
have been the case for you, but I mean I
would expect that you already had some experience at that point.
Speaker 3 (23:05):
So I think it was very junior at that point.
I had less than a year of experience. And yeah,
I think I did have a lot of interest in passion.
I guess right that that is something I had. But
I mean another thing is I kind of wanted to code,
like that all things I want to code. I saw
a professor of my in my first year who kind
of fell in this category. Like when I went whenever
you'd see Courte, everyone would like just like in awe,
(23:26):
you know, like how is he just like coding as
if he has a mental compiler, you know, because he
doesn't need to run the code to make sure it's working.
Speaker 2 (23:34):
He just knows what to write. And I guess I
set myself side back goal for myself a while ago.
Maybe that's what helped.
Speaker 3 (23:40):
But I have seen it happen to one of my
mentees too, Like he also read through the same book
and in a week and he kind of had an
inflection point over the course of reading that book and
doing all textided as well. So it's not just one
data point, it's two days points. I do know it's
not much, but too more than one.
Speaker 1 (23:57):
Yeah, I can relate in the context of that, I
feel that like for me personally as a software developer,
I grew very much by having to switch paradigms. So
like when I when I switched from the classic complect
oriented program into functional programming, and to be honest, I
think it would probably be would have been the same
would have been true if I switch from functioning to
object oriented, because it just challenges a lot of biases
(24:19):
you might have had at that point, like okay, like
a lot of ideas how you can solve certain problems
because that's seck of the tools you know, and now
suddenly you have a completely different thing which works completely
different in your brain is like wait, what, but how
how can I solve a problem like this? And I
feel like at that point your brain kind of is
forced to find a more generalistic approach to problems exactly, And.
Speaker 2 (24:42):
That's that's kind of hidden what I was saying.
Speaker 3 (24:44):
The seventh problem in seven weeks has an option the
language back language Ruby, but it also has a pure
functional language, right, so maybe maybe that was part of
that doing that, But yeah, I do agree paradigm changing
paradigms is one of the best way to train your
mind as an engineer.
Speaker 2 (25:03):
I remember I did prologue. I was like, oh my god,
like just.
Speaker 3 (25:07):
Doing like the logic oriented programming was so foreign at
that time.
Speaker 2 (25:12):
But yeah, it evolved. It kind of evolves. As an engineer,
for sure, I totally agree.
Speaker 1 (25:17):
Yeah, And I think I mean, now, if you've spoken
a lot about writing code, I think one skill, which
in my opinion, is even more important than writing good code,
is being able to read and navigate code, because I mean, yeah,
if you are in a startup situation you have to
build a system from spetch, then writing code might be
a little bit more important. But let's be honest, how
often is that the case in day to day work?
(25:39):
Most of the time not.
Speaker 2 (25:40):
Reading is important even I agree.
Speaker 1 (25:44):
That most of the time you actually need to work
as an existing code base, you need to make modifications
to that. You probably will have to work broke with
code you have never seen in your life before, and
you need to figure out where the problem is if
it's a case of a bark, also where some part
of a log lifts you might want to change, and
how you change it. So I think that it's also
(26:04):
why I've used to also do live coding exercises for like, okay,
let's build something like that. But I'm kind of coming
around on that way. I say, I still think that
coding is like something you probably should do in the
context of an interview, because at the end of the day,
I don't see a better tool to figure out, okay,
is somebody actually capable of doing it. But I'm coming
around and saying like, it doesn't necessarily have to be
(26:25):
live coding, because some people might just be might not
be good on the live context, right, They're not very
good of like somebody they don't know looking over the shoulder.
But I in my perfect world scenario, my perfect interview scenario,
I would say, hey, we have this existing project. It's
maybe well prepared ahead of time. It's a small project
which I don't know provides an API in the context
of a back end and developer, right, and there's a
(26:46):
buck end there where you there's like maybe a feature
a thing you need to build, and they need to
change a feature. And then I would ask people to
set up a poor request like I actually go through
emotions of what you do day to day and navigate
this unfamiliar code base and see what they do. I
would potentially hide maybe one or two bucks in there
on purpose, maybe some bad variable naming, all those kind
of things, because in a very senior developer, I would expect, Okay,
(27:09):
they might might catch one of the bucks, they might
do some refactoring along them, maybe they might add some
missing tests, right, they might all do all of these
little things which help you maintain the health of a
project in the long run. And also I would expect
that from a senor developer, I would expect that they
challenge potentially what executly the requirements were in that interview context,
(27:30):
I would actually give some requirements to them which are
in some places deliberately vague, because it is like most
of the time you don't get a perfect ticket. You
get a ticket which is in some place is vague,
and then you have to ask questions, you have to
figure out what it actually means. And that is then okay,
you can practice your coding skills day in and day out,
and that is something I wanted to get at. You
can do. I don't like some lead skills challenges. You
(27:52):
can do exorcism a lot, which I think is actually
if you want to get better at coding in general,
and like at understanding problem and like how tests can
be written or you can write testable code how to
learn some best practices. Then Exorcism is actually a very
good platform because you have people mentoring you and like
especially if you engage with the mentors and reflector your code,
(28:13):
that's like potentially a way I can really learn these
best practices very well. But that only covers part of
the job, like on one one area of a job.
And this is what it for me means to have
somebody who is like a senior software developer, is I know,
let me let me started that talk about that differently. Basically,
So if I have like an early career development and
(28:34):
a junior developer, I would say, I give you a
well defined task. I give you a well defined problem,
and then point you where you need to put the
way you need to go to solve this right back.
For example, hey, this is a bug. This is the
code base, it's probably over there, figure it out right,
But this is like a very small, very small defined
probably like a mid level developer, I would expect, Okay,
(28:54):
we have this speech that we want to build, right,
this is a well defined area already, this is the
thing we want to build. This is like potentially inside
of the app instead of the screen it should change
to be like this, But now go figure out what
exactly you do in the best way how you can
do that. And for a senior, I would say, hey,
we have this problem. How do we solve this problem?
And I would not necessarily, like for really of a
(29:16):
senior developer, I would not expect to have any kind
of solution at that point. Yeah, you might have. You
might think this could be a good idea, but maybe
there's a different solution about this. Right. I want to
be able for like somebody who is really senior. I
want to be able to give you give them a
problem and they come with a solution. And then if
you think about it that way, coding is only part
of the like part of a tool set. And yeah,
you need to be very fluent in coding to actually
(29:38):
pull that off. But it's just like it's it's a
foundation what to build your your your skills as a
senior and developer, I would actually be curious about what
do you think about that? What I just to do?
Do you think it makes sense?
Speaker 3 (29:50):
Totally makes sense? Yeah, and I'm going to give you
this a year of I'm swying. It depends right, Yeah,
how much of that is true, depends really on your
definition are what pas? But overall the heart of it,
it makes a lot of sense, are yeah, And.
Speaker 1 (30:04):
I maybe I wouldn't say that like a senior then
has to come up with designs or anything. I might
still collaborated with somebody from from who is more in
the design area, but they would like a senior developer
would be really be responsible of figuring out, Okay, we
have this problem. This might be a possible solution to it,
but like we can delegate it right, Like this is
like I don't need to think about vinity details of
that anymore. I can trust somebody to deal with it.
(30:26):
And then when you look at that, there's a coding
in there. Yeah, but there's also people skills in there.
There's also like the general problem solving skills in there,
and there's I think a very strong ability of a
senior is also to decide when not to code. Because
there's a very great quote from Marco him Software. It
says like code is expensive to write, to maintain and
(30:47):
to something I forgot to run, and to educate, to educated.
Its means the right to maintain or to educate. So
if you have less, if you can solve this problem
of less code, you're better off so and exactly those
kind of thoughts and those kind of considerations are something
which for me, like where you would say people is
like a senior but this is an excellent sceniority developer.
(31:09):
This is really where where you can go beyond and
then at some point also go beyond the senior title,
like where you go. Okay, now now I'm going to
go into a leadership position. Now maybe you're going to
go into a principal area where to potential to make
a kind of the connection to some past episode like
what we talked about last week in the DVD episode, right,
(31:31):
like all the strategic work, and that has been something
like I've learned along the way in like this in
a small scale environment of six companies, six people, because I,
by necessity necessity had to do some of that work.
And then also instead of like the agency like getting
working with the customers, and then I looked into what
what's domato from design? Like whatever are the ideas there?
Like what what does it mean to speak the language
(31:52):
of stakeholders? All those kinds of things monologue and well,
I think.
Speaker 3 (31:57):
Just to add to one more thing, right, here's so
many things that are outside of coding that makes se engineer.
I think one more thing, probably lower in the priorities,
is someone who can be like a multiplier, someone who
who's addition to the team by either changing processes by
their inflicting inducing positivity and inducing there's some people just
(32:18):
induce passion and other people to like quote more and
you know, like change single handly can positively influence the
entire culture. Like you know, maybe post series A, like
big enough companies, it would it could have a huge difference. Yeah,
and I don't want engineer who might have be the
fastest in coding but very good at like designing and
architecture and like.
Speaker 2 (32:37):
But I think his contribution is like.
Speaker 3 (32:40):
The he I'll just give his name.
Speaker 2 (32:43):
His name is Jeffrey Mattias. He's the author of Testing
a Luxur.
Speaker 3 (32:46):
But he he was a community and I think he
is probably the biggest reason why a lot of engineers
work there or continue to work there. Right, he's single
handedly creates a positive work environment for everyone are most engineers,
and also keeps that normal relationship with them to help
them improve and grow. Right, I think that's huge during
(33:08):
that in itself even he's a very good corner. He
might have the fastest, and he is a very good
he's a very good set of architecture. But even without
all that, the value he adds just by being that person,
that glue is you know, principal engineerbility value.
Speaker 2 (33:24):
That makes sense.
Speaker 1 (33:25):
Yeah, yeah, that makes a lot of sense. And I
think I mean said that was something I said before
we press record. But I feel our industry and especially
like the social media space around, it's very much into
this hustle hustle hustle mentality, right, and that you have
to be a ten X engineer blah blah blah blah blah.
And I don't buy into a lot of these topics,
but I do think that sometimes you have people which
(33:47):
are close to their ten X engineer, not because they
write codes so well, but because they enable other people
to grun faster. And if you doesn't mean it, just
imagine if you have like a software developer who maybe
is average in code writing, right, but they're very good
at like actually coaching and mentoring and like helping people
find the answers. And then the people mentoring maybe three
(34:07):
juniors and they one of average. Maybe a junior might
need three days to solve a buck but with support
from them, like maybe even half an hour, one hour,
you cut that down to half a day. Boom, Yeah exactly,
it's a technic engineering. And that is really where I
said in the beginning. It depends like in some environments
in some context, I don't know, if you work in
(34:29):
like aerospace engineering and like you have right software for
a NASA probe, then yeah, other skills are important than
if you're in a big team where you have a
lot of early career engineers and to mental those and
all of the different skills are potentially important. And I
at this point in my career, I don't describe myself
as like I don't know a senior developer. I often
(34:50):
just say I solve problems. My my weapon of choice
is technology, but the end of the day, I solve problems.
And I think a good example of that is, like
I talked last week about the CDD workshop, we did
right and one outcome is this is, for example, now
that in the leadership round of a company were actually
talking about, Okay, do we need to do some organizational
changes because of the things we learned, because we see
(35:11):
some misalignment between the things we would like to do
the things the organization is currently structured around that, and
well how did that come to be? It came to
it was born from they want to have we want
to change our current software architecture because it's not really
aligned with how you think about the business. But we
first need to really learn how the business works and
how we as a company think about the business. And
(35:33):
I already suspect that we might get to hey, maybe
our organization structure sometimes. But you can't go in there,
go to the CEO and think that, hey, the organization
suctor suck, sucks, right, But I can go there and say, hey,
to actually build good software me to figure out how
the organization works.
Speaker 2 (35:47):
So it's not like there's like a.
Speaker 4 (35:51):
Lot my guy, yeah exactly, Like and that's a very
excellent book, which is got Team Topologies, which is basically
about that is like take Conway's law, Like everybody who
does not know Conway's Law is basically any any organization
which designs a system in a broad sense, which software
is a system is what is the exact wording.
Speaker 1 (36:12):
There is do doom doomed to like produce a copy
of the ication structure. I think it's opposite organization.
Speaker 2 (36:20):
I think it's opposite.
Speaker 3 (36:21):
The organization takes a structure of the domains and the
software naturally.
Speaker 1 (36:26):
Yea, all the other way around. It's actually any I'm
going to look it up. I'm going to.
Speaker 2 (36:32):
I know it goes both ways, but let's see.
Speaker 1 (36:35):
There's a very reverse Conway maneuver which actually takes that
into consideration.
Speaker 2 (36:38):
Oh, I think you're right, and you're right. Organizations, you're right.
Speaker 3 (36:41):
Organizations design systems that their own communications structure.
Speaker 2 (36:45):
Yep, okay, I.
Speaker 1 (36:46):
Haven't now any organization that designs the system defined broadly
will produce a design whose structure is a copy of
an organization's communications structure. And that is true. That is
just true. It's insanely true. Like if you have I
don't know. There's also like a very good rephrasing of that.
If you have four groups working on a compiler, you
got a four past compiler, and if you have five
groups are going to go past compiler. And that is
(37:07):
that true, because like that's the way we humans are,
our brains are wired. But it hints towards a significant
truth is you can't design software in a vacuum. You
can't ignore communications. You can't ignore people. It does not
work because software is written by people four people. How
can you remove people from that equation?
Speaker 2 (37:28):
Doesn't make sense?
Speaker 1 (37:29):
And I think that is like the core one of
the core things a software developed is like, really, if
you really grock that and like really work towards making
making improvements in that area in a holistic perspective, then
there's nothing stopping you from becoming an excellent senior and opinion.
Speaker 2 (37:45):
I agree, So yeah, yeah, I agreed.
Speaker 1 (37:52):
I guess there's so much there's so much to it,
and like I said, that's an excellent book form. It's
called team Team Topologies, which is basically about taken this
idea of Conway and like, okay, what what does that mean?
Like how can you then structure organizations to actually deliver
the kind of software you want to build? Because this
is this is a nice side effect that if you
accept that this is true, you can say, okay, so
now how do we need to build our set up
(38:13):
our teams. We get the architecture you want to get
to get like the system you want to get them
to get fast flow where we want to get it.
And yeah, this then leaves the realm of senior developer
of responsibilities. But this is something that I've always done
in my career, Like I always when I came to
a point of okay, this is like my responsibility bubble,
I always look beyond, always like okay, like what does
(38:34):
that mean? Like I see some issues and I see
some people talk about this Conway's law thing, Like what
does that mean? Like, let me look it up. And
while I was never in a position in that particular
moment to actually impact the organization and structure, it made.
It gave me context. It gave me understanding about why
things were are the way they are, which then boils
down to again like I wanted to figure out why
things out the way they are, and it always enabled
(38:55):
me then to go the next step in my career, right,
like because I already diged into some of these topics
and that helped me to go further. And now I
may that I basically since the beginning of this month,
I've been a technical team lead at my my current employee,
because I bring like a lot of these talking about
actually helped me get stead title right. And now, like
(39:18):
I said, we have this discussion in the team in
the lead circle, Okay, but do we need to do
organizational change. This design never stops.
Speaker 2 (39:27):
Yeah. Yeah.
Speaker 3 (39:29):
In fact, that's funny you mentioned we were just talking
about how and this is when the reverse conway, right,
like how the US defining and domain in our software,
which again without getting too much into this, after you know,
patient pace for our service and like starting creating that
as an entire domain will inevitably create its own engineering team.
Speaker 2 (39:50):
Right because it don't mean it is really different. So
we just had a conversation.
Speaker 3 (39:54):
Yeah, you're right, like those kind of conversations are also
being part of being.
Speaker 2 (39:57):
Like a senior senior. Yeah, seniority.
Speaker 1 (40:02):
Yeah, and I think that maybe to cam some nerves
of it, you don't have to do all of that,
but it really helps because by the nature of these topics,
you will touch on a lot of subjects which are
then very relevant to your today work. Yeah, but maybe
to go back to something we said earlier, because I mean,
like I set a set that helps you to figure
(40:23):
out why things are the way they are, and that
is also like in the small scale and again that
we talked about, Hey, figure out why like that that
for example, Phoenix is not magic, but also OTP is
not magic, right, and it's the same, like you understand
how the system as a whole actually why why it
works the way it does, right, and you don't just
use processes and elixir. You've understand how they work and
(40:44):
that enables you to do other things. And there's also
a book on that and which I think has not
aged that well because it's been quite updated a lot,
but it's the little Elixir and OTP going. Yeah, it's
a great book. I'm not sure how like it's I
think it's elix A one point three or something, so
like you have to navigated a bit carefully in that context,
(41:06):
but it's what it basically does. It makes you rebuild
some of the primitives of OTP, like a supervisor and
an exam server and all those kinds of things, and
that really enables you to like figure out, Okay, how
do you want to design systems and stable systems instead
of ODP and why are things the way they are?
So yeah, I feel like we've kind of given a
(41:26):
complete maybe to come back to one subject of the
beginning side project, I mean, like, especially for exmple getting
fluid with code. Side projects are a great way to
go about it. But you don't have to like I'm living,
I'm living proof of it.
Speaker 3 (41:41):
I mean it's a good way of like getting more
experience and less less of experience, right like, and also
getting opportunities to solve problems that you would not have
device anymore, especially if you're working like a big organization,
a lot of bureaucracy, a.
Speaker 2 (41:54):
Lot of you know, red tape. I guess you know.
Speaker 3 (41:57):
Then the side projects can be opportunity to explore topics.
I think the part of in durn design and explore things.
Speaker 1 (42:05):
I was always in a very luck, to be honest,
privileged position to never never have to work on boring
stuff like it was always challenging in one way or
never right now, My job right now is not challenging
because we solve super hard technical problems, but well I
have to know, solve organization problems, so it's it never
(42:26):
has been boring. So I never had the inherent desire
to say, okay, I want to have more even more
challenges outside of mine. But I always like what I
like to do occasionally is been like I've done a
fair bit of like advent of coding, and I did
it and has skill just to tickle my brain in
ways work cannot and I also did the Pure Scripts
track on on on Exorcism, Like I didn't complete it right,
(42:48):
but I did that. So that's to look beyond the
my immediate horizon. So yeah, you can do hYP projects.
You don't have to do hype projects. It's maybe your
place of work also gives you some some time time
to grow as as a developed provide some some innovation
time or whether you might want to call it some
twenty percent time. That can be an excellent source of
side product. And that's that's where most of my open
(43:09):
source work comes from. And I've worked at places where
we could invest some of our time into work related topics,
but not directly, like I didn't have to contribute towards
solving a concrete problem at work, but they still had
to be related to my teraately work. So I couldn't
do yoga at that time. But I was perfectly fine
to write an open source library and to scratch like
a personal each of mine out of work. For example,
(43:30):
that's where Nigger was born, which was the main reason
why I want this spam podcast, why I always invited
in the beginning. So yeah, side projects can take many forms.
They don't have to be from your free time. As
I mentioned in the past, I have two kids, I'm married,
I don't have a lot of time on my hands. Okay.
And while I while there are a gazillion things I
would like to build, I still have like this ideal
(43:52):
about some application to help organize gaming events with friends.
It's just not high enough on my list of priorities
to end up on my schedule. Okay, then I guess
we can transition to pics. Yes, do you have any
picks for us?
Speaker 2 (44:05):
Yeah? Not really. I mean the two books that I mentioned.
Speaker 3 (44:09):
Check out my book if you want to learn how
Phoenix is built, and definitely check out Seven Languages and
Seven Weeks by Bruce Take.
Speaker 2 (44:15):
It actually covers.
Speaker 3 (44:16):
It has Haskell and Prologue, two of the most amazing
paradigms I've worked with. If you guys want to change
yourself with the paradigms, prolog and Haskell a great and
this book has them. Yeah, I think, I think, Oh, well,
one more thing. I it's not a lily brilliant. Maybe
it's a very small point. Like the one thing. As
you learn and as we start to contribute and take initiatives,
you have to show that you are gaining in seniority.
(44:39):
Just be careful of just doneing Kruger's effect, right, Like
that's something you don't want to make a fool of yourself.
Speaker 2 (44:44):
Just make sure you know what you're talking about.
Speaker 3 (44:47):
And I know most people engineers don't have that, but
it's something I had an affinity towards.
Speaker 2 (44:53):
And I've kind of made a full of myself early
on a couple of times in my career. So in
any respect, it is like when you know, when you
think you.
Speaker 3 (44:59):
Know a lot more than you actually do, and it's
happened to me a couple of times, So it's it
could be embarrassing and it could be also hard to
arrange that impression already need do on someone, So just
side pick. Also video games, right, I've forgotten that Vio
video games. Now, man, I was going to pick Yeah,
I think it pickstraight already.
Speaker 2 (45:18):
I think I already picked straight. Yeah, I think all
my games have been picked. Well.
Speaker 3 (45:21):
Yeah, if you guys are not aware, the next Hour
of War is coming out in a couple of months,
and so yeah, this is pre order it it's going
to be amazing.
Speaker 2 (45:31):
Or no is good.
Speaker 3 (45:33):
That's how that's how, that's how engineers get paid more
based on the preorders. That's how these gaming companies to
determine success, and that's how game engineers salaries. It significant
influences gaming engineers and salaries and post release sales if
you do pre orders.
Speaker 2 (45:50):
That's something I learned recently.
Speaker 1 (45:51):
So, but it also encourages to deliver city product, because
I mean, if you're already made bank, I don't make
a great product. I'm going to say this is the case.
Speaker 2 (45:59):
For a God of Or, But generally companies pre orders.
Speaker 3 (46:02):
Generally complete these pre order early post orders for the
next game at the current game, they already have money
allocated from patches and stuff. Generally, that's how it works,
unless you're like a very new studio. But anyway, I
think you should pre order. I think you shouldn't furnish
that if you guys have played the first goal of War.
Speaker 2 (46:20):
I'm pretty sure. I'm for sure.
Speaker 1 (46:22):
I'm pretty much in the camp of patient gamer. I
always pretend that the game gets released two years later,
and then I have like a full picture about how
good is this game. It's the deal's other deal, C
is worthit? And oh it's only twenty bucks.
Speaker 3 (46:36):
Yeah, only if I could fight just the addictive feeling
of that instant gratification.
Speaker 2 (46:43):
Right.
Speaker 3 (46:43):
But you know, if if I was mature enough to fight,
then I would follow the category.
Speaker 2 (46:48):
But I wanted as soon as it's.
Speaker 1 (46:49):
So fair enough, I get it. But for my wallet,
it's been very good. I have a bunch of picks,
and I would like to repick some things I picked
in the past already, so I would first one we
pick is Specification by Example, and it's an excellent book,
but it's a very basically is a book about doing
a case study on different projects and different companies doing
(47:10):
different things, and the author expected some dos and don'ts
from from from these different projects, and maybe maybe not
that surprisingly, it has a lot of overlap with some
of the ideas from DOMAINO from design, even though it's
not a DOMAINO of design, not at all, Like there's
never a single mention of the world DOMAINO of and
design in the book, but there's close collaboration with stakeholders,
with experts and so on and so forth, and it
(47:32):
is definitely something if like, if you really want to
like get closer to that seniority title, that senior title,
it's a very worth you'll read because it's very interesting
to see like how projects succeed and don't succeed. It's
also a very cool I think it's from this book,
but sometimes I mix some books up. But I think
in that book as like an example of like how
the F sixteen, like the cup fight at Fight Jet
(47:54):
fighter jet what was built and originally in the specifications
it's said, hey, we want to have jet which can
get muck whatever I don't know, six seven whatever, like
get this high speed, and at that point in time
was kind of difficult to pull that off. And then
like the company who took that contract, they've asked why, why, why,
why why do you want that? And it turns out
(48:15):
the reason was that it needs to escape from combat
if things go sour. So what they ended up building
was not a jet which could get that speed, but
we were super maneuverable, so it could just out maneuver
the opponent and get out of combat that way. And
the sixteen, as far as I know, it's still in
service today even though it's quite old, because well it's
actually taken the underlying problem and found a different solution
(48:35):
to that. It's very very well if you read even
in this is a software development book, but it takes
examples from all kinds of industries and how you actually
want to solve problems and find solutions. So specification by example,
and it has been written by go Ajit right, great author.
Generally it has some very wise things coming from this
(48:56):
this person. Okay, another pick I would like to do
and already hinted at an earlier exorcism excessism, which is
a great platform if you actually want to well baby
devil in other languages, want to learn some best practices.
It's like a it's an page where you can do
code exercises, but you also have people volunteering. We have
free time to mentor so like you can submit solutions
(49:18):
and then you can get somebody to mentor to give
feedback on the solution, kind of like a code of view,
and it's really helpful and like getting an idea about
some of the best practices in the language, like how
you might want to solve how you how you should
approach solving problems in some languages. And if you are
in your state and in your state of your career
(49:38):
where writing code fluently is still not something which comes
naturally to you, then that's not the worst place to
go to to be honest. And then last but not least,
I'm now going to do a shameless self pick because
we talked about okay, what is what is something like
coding and reading code and all the kind of coding
topics are just something which is helpful in getting the
(49:58):
senile title, but not its lusively. There's much more to
being a bit of a developer. And a few years
back I actually gave a talk which was titled you
know nothing or do you? And that was at the
height of the John Snow Grace And then this is
the game of Ronan's Grace. So it's like it has
some references in it, but what it boils down to
is talking about, Okay, we have software developers. We like
(50:20):
to define ourselves by our skills, but our abilities to
write JavaScript, to write Elixir, to do react well, to
be built great APIs. But there is more to each
person than just these technical skills, and there's more to
you to each person bringing experience in from all kinds
of areas. For example, in the talk, I give an
(50:41):
example of I'm very calm in like stress situations, and
I try to reflect on what I do wrong. And
actually that's a skill I attained by playing a lot
of League legends because bring a lot of solo cure
gaming where the only person I can reasonably influence myself.
So yeah, that is the kind of what what this
whole talk hints at. It's like, yeah, maybe some people
(51:03):
think I don't know nothing, how can I ever be
a great software developer? But there's probably more skills you're
not even aware of you bring to the table than
just your ability to write other script So yeah, I'm
going to pick that talk. Okay, those are my free picks.
So what's a pleasure is always uddie and I hope
you also enjoyed the episode, folks, and tune in next
(51:25):
time if another episode of AlSi mix bar
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.