- Hey, this is Overpass Insights.
My name is Eric, and I make apps.
Now today let's share some thoughts on older developers
and younger developers.
(rock music)
All right, so I just spent the last three hours
writing a stored procedure in SQL Server.
And it was a lot of fun.
I hadn't done it in a long time.
And the reason I was writing it,
it shouldn't have been me doing it,
it should have been the developers
I'm working with doing it,
but they were really struggling with this,
and we have a client that wanted everything done on Azure
with SQL Server which is fine.
We've done it lots of times in the past.
But they were also saying we want some of this logic
to be done in a stored procedure,
because it's gonna change frequently.
So we have a business logic,
and rather than put it into the code,
why don't we do like a stored procedure
which goes through and disseminates all the data
once it goes into a holding table beforehand,
which is standard stuff.
I've done that in the past.
It's easier to update a stored procedure
than it is to update code sometimes,
especially if you're not having access to the server.
We have all the permissions and everything.
And while you shouldn't change stored procedures willy nilly
you can kinda tweak 'em a little bit if you have to.
So I was like, so I told the client,
that's totally fine, sure, we can do stored procedures.
I told the developers we can do stored procedures, right?
And they said, yes.
And they said yes but it was kind of an unsure yes.
I thought, okay, okay good, good.
And they've been struggling with
the logic of the stored procedure.
'Cause most of the code has been in,
most of the database code has been done in code.
So inserts into tables, maybe selecting out,
doing updates, statements in the code.
But I was like no I want all this to be done
in one stored procedure,
just execute the stored procedure.
And again, they were just struggling with it.
So I thought, you know what, I'm gonna show you guys
how the experienced guy does it.
Stand back and watch the magic happen.
So I just, ahhh.
So I just, so I said, give me, all right,
let me have a look of it.
And I try not to look like I was joyful inside.
I looked like I was like, all right,
let me have a look at it and see if I can do this
because you guys should be doing this,
but let me look at it now,
I was like (making typewriter sound).
Typing away and I just sent it off to them,
and in my mind, they're looking at it going,
wow, this is amazing how he was able to do that.
But the reality is, I started to realize,
I'm kinda the old developer.
Stored procedures were my bread and butter back in the day.
I used to it every single day working in an investment bank.
And everybody had to know Transact-SQL really well.
And this was a good stored procedure, right?
It had a cursor in it.
I'm declaring variables, insert it into multiple tables,
all that kinda stuff.
But I don't think people use them as much as they used to,
especially not people who come from
the open source background like MySQL.
Now this is an opinion, so you might disagree with me,
but MySQL does have stored procedures,
but they're not as widely used as they are in a SQL Server.
So a lot of the times I work with developers
who don't know that logic.
And there's other things, too.
I had one developer who was really good with MongoDB
but not with SQL.
So a lot of times I was helping him out writing the queries,
because to me SQL is something everybody should know,
but not him.
So anyway, going back to me
being the old developer showing off.
When I first started in software,
and I was 25 when I got started.
So I was a bit later than a lot of you guys probably were.
I remember working in investment bank
and talking to people who were trying to impress me
with the technologies that used to work in before.
So they might be in management now, but they say,
back in my day we used to code in Pascal.
Or back in my day...
One guy even said he used punch cards.
Or they'll talk about some old technologies they used
just to try to show that they're hip,
they're hip with the kids and everything.
And I remember thinking, dude, that's old.
That's an old, that's some old technology.
And now that's what I'm doing.
I'm the one going, stored procedures are the way to go.
You should always use stored procedures.
Even I think Entity, I think Entity Framework on .NET.
I think even that's new.
Once everything started going Entity Framework and ORMs,
was ORM tools and everything like that,
object relational mapping tools,
stored procedures became less relevant for a lot of people,
but for some of us they're good all the time.
Anyway, I wanted to share that with you guys.
I'm getting to the point now where I'm the old developer.
I'm clinging to those old technologies.
I'm like dude, I'm gonna get back into VB again.
I might do a WAP web, a mobile website using WAP,
which I know a lotta you guy are
too young to know what that is.
So my question to you guys, what do you,
so, when I look at younger developers,
they're still learning, but they know
a lot of the newer technologies.
They don't see the reason to learn the older stuff.
The same way I didn't see a reason
to learn Perl, for example, when I was doing ASP.
And that was 20 years ago.
So what do you guys think?
For those of you guys who are older developers,
what do you think is technology that you still rely on
but a lotta younger people don't use?
'Cause me, it's SQL.
I think a lot of younger developers are,
they're not as SQL savvy,
not as SQL savvy as older developers.
But that's just my opinion.
For older developers out there,
what do you think are technologies
that younger developers don't know as well.
And for you younger developers,
what do you think of the older developers?
Do you think the same way I did when I started?
It was like, dude, man, that guy is old.
(laughing)
Anyway, just some thoughts today.
I hope you guys are having a good day.
That is it for today.
I'll talk to you guys again tomorrow.
(upbeat music)