I’ve been a web developer for 17 years and this is what I learned – Daniel Khan

Node.js is just another technology we are
supporting, and everything that has something to do with Node kind of runs through me. Besides that, I’m doing courses for Lynda,
I have 3 daughters and a son, I’m teaching at the local university, and that’s what I
do. This talk is a little bit kind of my story,
or kind of some Node connected things that I learned during the last 17 years, because
I think that everything is kind of cyclic, which means that things are coming back again
and again, so we can kind of learn from the history to don’t do the same mistakes in the
Future. That’s me in 1997 with my first webcam picture.. So we had this silicon graphics O2 which did
cost almost as much as typically a small car, and then this guy came and told that “Now
we’re taking a picture for the internet” together there. That’s me, and *whoaaa* the picture was on
the internet, and that was a quite great thing at this time. In 1998′ I’m already playing around with HTML. Websites looked a little bit like that. This book hasn’t been written at this time. At this time there was no Google, there was
no Facebook, there was no GitHub, there was no Wikipedia, and also no StackOverflow. What we had was something called newsgroups,
so we could ask questions and people could answer to them. It was a little bit like emails, but still
different. And here it’s 1999, 17 years ago I guess,
so I’m writing my question in my Square newsgroup where I say: “I’m now writing databases for
the web, but have already databases for the Desktop. “Yes, Microsoft Access!” “My hosts supports MySQL now I don’t know
what this means..” I really didn’t. “I know how a Query works”. No I totally didn’t. One thing we really learned as the web never
forgets, is that I really had no clue at all this time. But in the 2000’s I was already working as
a web developer, and I’m teaching PERL for the Austrian Job Service, because at this
time, everyone that kind of had problems getting a job was a perfect candidate to become a
web developer. That was a trend here this time. So PERL was a quite difficult language at
this time, and I was ready teaching it, so I most probably was very very intelligent
right? So, actually I wasn’t. When I tried to update a dataset in a database,
I was first deleting it and then inserting it, because I just didn’t know how to do it
properly. Why I still thought I could teach is called
the Danning-Kruger Effect. In short, it means you are so incompetent
that you don’t know how incompetent you actually really are. And there is even a kind of a function of
time here. So this is what you think you know, and this
is what you really know. And at this time, I was almost here, so I
thought I knew it all, and a little bit later when I finished university – most probably
this was in 2011 – I was at this point where I thought “okay I know what I know”, and then
the humility kicks in, because then you start to find out what you not know and kind of
gets desperate. I think I’m here now. So I would say this goes in this direction. When you are here you kind of, I don’t know,
you move into the woods. But somehow, I managed to find a company and
we bought a server, and I think it was really this server when we went to the Bank, took
a loan, it was 15,000 Euros or so, to get the server. Today we have serverless so you can start
even without a server, you can build up a whole company – so things really have changed. You put it in a rack in some datacenter in
Vienna, so we put it in the car, we went to Vienna – and every time the server was down
I went into my car, had to go to Vienna and kind of reboot the server. So this was how things were. But what I learned, the important learning
at this time was that you really should strive to understand the full stack. And with full stack I mean this full stack. This means at least know a little bit about
the protocols of the web, know how routing works, know how HTTP works basically. Know how SMTP works! Because I think it’s essential to when things
go wrong understand how this funny little packages come to the browser and back and
how everything fits together. So now we are in 2002, I have a company, the
internet is booming everywhere – not in Austria. We’re just waiting for the boom to come to
us, and then the world ends. I think it started with boo.com. This was one of those new startups, they had
some fashion store, and at this time everyone was big-time investing in everything, so that
had something to do with new economy, new media and this so whole industry was booming. And if a company had any Linux in there, it
was already kind of overrated and there were companies that went from 10 people to 100
people in two months, because this is how it was this time. And then boo.com went broke, I think it started
with that, and then all investors kind of moved out, because new economy companies can
actually fail, and so they were kind of shocked, and this is what happened then. So we were at this boom phase here, and then
– this is the NASDAQ – and then everything crashed until here. We’re here around 9/11, and 9/11 was kind
of, everything was gone actually. And I Googled a little bit to find out how
this felt at Silicon Valley at this time. And I found this guy who writes: “Oh man,
it was brutal. As a youngish startup guy, everyone I knew
was affected. Most everyone I knew lost their jobs. Soon after, most everyone I knew moved away.” And here he writes: “The contrast between
the bubble years was epic. Gone were the open bar events and fabulous
launch parties. Gone were the jobs and companies. And soon after, gone were most of the entrepreneurs
without a safety net – many back to live with their families to regroup.” Sounds somewhat familiar right? So now if you go to Silicon Valley Today it’s
like that. Everything is startup. Everyone working there is like “What? They don’t have a breakfast buffet at this
job? They don’t have this table football thing? Oh I won’t work there – I need a private jet
at my company, basically”. And this can happen anytime again. I think even I would say that it’s not the
question if it will happen, the question is when it will happen. And no-one will end up like that right? I don’t know how many of these pictures were,
but at this time, we saw them a lot. And one learning from that I would say is
“make the hay while the sun shines”, right? And I’m not talking so much about money, I’m
talking about also preparing for the bad times by investing into your skills and into your
knowledge. Don’t settle for Mediocrity, right?! Because, there are so many languages around,
and I think programming is not about being a JavaScript developer or being a Node developer. Programming is very much about concepts.I
think that maybe when you do JavaScript for instance, try something functional like Scala. I did at first at Lynda and Coursera, and
it really helped me to really understand also JavaScript and also why we use underscoring
and how things fit together. So what I want to encourage you is, see yourself
not as Node developer or JavaScript developer – see yourself as an engineer. Learn concepts, learn how to solve problems
with different languages, because after all, if everything you have is a hammer than every
problem looks like a nail right? So this was the course I did this time. It was really hard, but this Martin Odersky,
he invented Scala, so he knows what he’s doing and it was really interesting. And all those resources are free on the net,
so now it’s the time when you have time, invest your time in fostering your skills. So, between 2002 and 2012 I did many projects,
mostly web projects, many PHP based and believe it or not, some apps of them are still running,
like that. This means that they are haunting me still
today, because the problem is, when you did this apps in 2002 or 2004 or whatever, I never
thought that in 2015, 16, 17 I’ll have to look at them again, but then this call comes
“This website is down, could you please help us?” – even if I’m not anymore employed at
this company. This call will come, and then you’re like
“Oh my god, which idiot did this, because this code doesn’t make sense”, and you know
it was you. So my learning is – and I think it’s important
– write code that your future you will understand and be proud of, right? So always when you do something do it right! And my favourite theory I have about that
is “the broken windows” theory. When you’re in the city and you have a building
and this building stands and everything is fine, and then someone smashes one window
there. And you’ll wait a few weeks, and the whole
building will kind of start to rot away, it will kind of fall apart, there will be graffiti
on there, people will not care anymore. Put a car in a bad neighbourhood, it will
stand for there sometime, it’s not a problem, but then someone smashes one window and in
days it will be totally be taken apart. And the same happens to code, because you
know those temporary workarounds, right? “So yeah, let’s fix it somewhere somehow right? Let’s do it somehow!” And those temporary workarounds stay in there,
and then the next person, or you again coming: “Okay, it’s broken anyways, so let’s fix this
quick and dirty again.” And all those dirty fixes basically pile up
in your code and ten years after you may have to deal with that again, but why bother with
your old code, right? So you think, “It’s an old project, let’s
rewrite everything from scratch.” – because that’s how we like to do it, right? So I so often hear developers say “Oh, this
project we wrote two years on, this whole stack is not modern anymore, let’s do everything
fresh, and that will just take two weeks for that – because it’s basically easy. We have done it already right?” What you have to know here is that this is
the Achievable Capabilities of some application, and this is the effort it takes to kind of
add new capabilities, and we really see that, software has a saturation curve. It’s right that sometimes it’s really hard
to add new features to your code, and so it makes sense at some point to start over and
do it fresh, but you have this gap here. Because when you do it fresh and you switch
to a new stack and everything, and the project is somehow complex, you won’t have the same
features again from the start. Because there is so many inherent kind of
knowledge woven into this whole system all the time, that you cannot kind of redo so
easily. And you have to be aware, that this is a project
where you something for the customer and you do it fresh, and the customer is kind of totally
desperate, because the things that worked before don’t work anymore. We had this already, and now it’s gone. So you have to be aware that if you do something
from scratch then there will be a feature gap, at the beginning at least. But okay let’s rewrite it, but does this site
really needs React and Isomorphic JavaScript? I know it’s so nice we want to use it right? And we also want to rewrite our front-end
every six weeks, right? Because there’s always a new technology, especially
in JavaScript – so new technologies are coming up, I would say almost monthly, right? And there are companies that are kind of pushing
that, and even I’m like that. If it’s from Google or from Facebook it has
to be awesome right? Because they know what they’re doing. So I was kind of trying to get into React
and then looking at this talk where they introduced React and Flux and there they said basically
that “Yea, we had this problem with this notification thingy on Facebook, so we had a problem that
it didn’t get updated when someone read it was not sent that it was read, so we had big
problems. And we had this ugly MVC because MVC’s suck. So this is why it didn’t work so we had to
invent Flux. And I was like.. “What?” So let’s look at this again! So, since when do errors go back from the
View to the Model in MVC? I .. that’s kind of wrong and there was a
Q&A afterwards. A lot of people in there and no-one said anything,
everyone was like, “Hey yeahh, MVC sucks, we need Flux definitely.” And maybe she had a point, but this point
she had was not right explained actually. And then I scrolled down and here you have
all those comments where people are saying, “Oh, that’s not true and there’s something
wrong here and this is not… What are they talking about?” This is not MVC! But still, after that, everyone was like “Oh
MVCs a bad thing, we really need Flux because this solves all of our problem..” So, honestly, I’m the same, so I would not
have stood up there at the Q&A and say something like that’s wrong, because I don’t know, I’m
always kind of humble, and think that the people are always right. You should really start to question things
and don’t believe the hype. After all, Facebook and also Google are companies. If Facebook pitches React to the community,
they have some kind of agenda behind that. Angular and React are pitching for new developers,
they try to sell it, they have a marketing that told to sell it to you – it’s not because
they kind of want give something to the community. There’s someone at the company that says,
“Okay, this React initiative – how much does it cost us to do that? And then there’s a bunch of .. and then they
do that.” And we should really be aware of that, most
of the time nothing is for free and everything is about selling things. So if there is a hype, you really should question
the agenda of the people that are doing that. One important learning that comes from that,
because all those things are frameworks after all, and everything around that is code, and
that’s other people’s code. So what we really love to do in the whole
JavaScript world is taking on needless dependencies, because code written by some stranger on the
internet is always perfect, right? So it’s a very low hanging fruit to use third-party
components, and also whole frameworks. To use frameworks that give you a “Generate”,
where you just click on a button, and then there you have your block in five minutes,
like that. The problem is, that every time you rely on
someone else’s code you basically have to deal with the code when you want to try to
change something. So at this point you don’t anymore work with
a language or have to learn a language – you have to learn other people’s code and you
have to debug other people’s code. There were a lot of examples in the past,
like Symphony for PHP. You have a Generator, you run it and it creates
everything for you, but then at some point something breaks or something really doesn’t
work and you get some error from deep-down of the framework, and you really don’t know
where it comes from. And there’s the question: Isn’t it better
do do something on your own and maybe instead of kind of having it quickly, but then have
to really deal with the code and really learn how does everything fits together when things
start to go wrong. For instance, in JavaScript we have this modularity
thing currently, especially when we look again at things like React, where everything is
kind of separated in modules with different versions that somehow fit together. So I tried a React project and when I was
kind of fed up with everything I did this npm uninstall here to get rid of all of these
dependencies that were needed to just create this isomorphic React application. And it was 13 dependencies! 13 dependencies, megabytes of code by someone
else. And you really have to be careful about that
because this React is Webpack, everything creates code for you. That’s a whole transpiler, we’ll come to that
again. This whole transpiling thing is really a problem. And talking about that, that’s npm. It’s actually quite the same problem here. So we have, as we see here, obviously the
programming world has around 400 thousand problems, right? So there are 400.000 thinks that will solve
400.000 problems. And when I just look at this – I had this
at last week, I needed something to convert some UTF-8 HTML entity – and here you see
the results that you need some Node module that you need to convert some HTML entities. You get, I don’t know… There are so many modules that really all
solve the same problem, and it’s really hard for you to find out the right module to use
right? Because you don’t ever know if it’s still
maintained.. you have to look at, is it still maintained? How many bugs are there? And you really have to deal with that, and
Danny Grander will talk about that, I think a little bit later, when he’ll talk about
Node security. You should really think twice before you npm
install anything, or Yarn.. The same applies to copying and pasting from
StackOverflow. So here again, it’s one from the HTML entities. There they have a clear error in their documentation,
so they have this var Entities, and then they do entities=new Entities, so they create
unintentionally a loophole here. And there is a question on StackOverflow and
this guy that kind of answered this question copypasted it from the documentation right
into StackOverflow – and I’m totally convinced that the next person will take this and copy
it right into their code, right? So, because it’s on StackOverflow it must
be right. There’s no one really said that there is something
wrong with this code, so you really have to really be careful when you kind of take things
out of StackOverflow or from somewhere. It’s always someone else’s code and you really
should understand it and line-by-line be sure that it really really works as intended. Here are my last words, alright.. These are some key principles that are kind
of important for me. One key principle is don’t repeat yourself,
right? This means that basically when you have code,
you should – and it’s quite easy in Node actually to repeat yourself – really try to not kind
of copypaste code around like the same logic at some places. But also this means, that you should for instance,
when you have some Node application and Express application, and you have this application
script here, and you have a config, pass in the config here into the application. That’s a really practical example on how to
do it. So here you run it, and you require ./app,
and you pass in the config and you have it here. And you require this config once, and not
in each of your classes right? Because then you can change how the config
is loaded, and all things like that. Or for instance, you could use parents for
your routes here, so you can even pass in code classes into the route and really pass
this through your routes, and you have one single point in your application when this
one service, this one class is created. And as soon as something changes here, like
the signature of this constructor, you change right at one place. And I think that the rule of thumb here is that you should not have requires
to you own code, like require /// spread over your whole application, because really try
to load things at one point, extenuate it, set it up, pass it through your code. And that’s a thing that’s kind of a little
bit more complicated in Node, because of all those callbacks. Also, speaking about callbacks. It’s always a good idea to create functions
that deal with the return of the whole functions, so the callback functions. That didn’t make sense? So you create, you have a function that reads
something from the database, and the callback comes back and you do something with the database
result, create a function that can deal with different database results instead of creating
it again and again and again. And, Yagni – I think it’s also important that:
“You ain’t gonna need it.” So when you do something, really question
yourself: Do I really have this project, will it be so large as Facebook tomorrow? Do I really have to set it up like that? Do I really have to create it like that, and
prepare for that? So really be pragmatic about what you’re doing! The last rule is “Keep it simple stupid.” Again, think about your future self, create
your code in a way that’s easy to grasp, easy to understand. If you like this whole philosophy about programming
I was talking about, read this book. If you read any book, read really this book
– it’s the Pragmatic Programmer. Where really, many of those rules are kind
of inherent in all the philosophy I was talking about and exlained. Thank you!

3 Replies to “I’ve been a web developer for 17 years and this is what I learned – Daniel Khan”

Leave a Reply

Your email address will not be published. Required fields are marked *