Intro – About NodeConfBP
NodeConfBP is a one-day, single track conference held in Budapest in 2017 January, sponsored and organized by RisingStack – the Node.js Consulting & Development Company.
Below you find a near-perfect, stylized transcript of the prezentation from a first person perspective:
Meet Daniel Khan
At DynaTrace everything that has something to do with Node kind of runs through me. Besides that, I’m doing courses for Lynda, I have three daughters and a son, and I’m teaching at the local University.
This talk is basically my story. It’s about some of the Node connected things that I learned during the last 17 years.
I think that everything is kind of cyclic, which means that things are coming back again and again, so we can learn from the history to not make the same mistakes in the Future.
That’s me in 1997 with my first webcam picture (on the right)..
So, we had this silicon graphics O2, which cost almost as much as a typical small car, and then this guy came to us and told that “Now we’re taking a picture for the internet” together. And whoaaa the picture was on the internet, and that was a quite great thing at this time.
In 1998′ I was already playing around with HTML.
Websites looked a little bit like that. Also, 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 is that the web never forgets. I really had no clue at all this time.
Enter the 2000’s
In the 2000’s I was already working as a web developer, and I was teaching PERL for the Austrian Job Service because at this time, everyone who had problems getting a job was a perfect candidate to become a web developer. That was a trend.
So PERL was a quite difficult language at this time, and I was ready to teach it, so..
I most probably was very very intelligent right?
Turns out that 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.
So this is what you think you know, and this is what you really know. At this time, 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 you start to find out what you don’t know and you kind of get desperate. I think I’m here now (green dot)!
So, we went to a Bank..
But somehow, I managed to find a company, and we bought a server. 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 without a server and build up a whole company – so things really have changed.
We had to put the server in a rack in some data center in Vienna.
Every time the server was down I sat into my car, had to go to Vienna and reboot the server.
The important thing I learned 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 that you should at least know a little bit about the protocols of the web, know how routing works, and know how HTTP works basically. Know how SMTP works!
I think, when things go wrong, it’s essential to understand how the packages come to the browser and back and how everything fits together.
And then the World ended in 2002.
So now we are in 2002, I have a company, the internet is booming everywhere, except in Austria.
We were just waiting for the boom to come to us, and then the world ended.
I think it started with boo.com. This was one of those new startups who ran a fashion store.
At this time everyone was big-time investing in everything, which had something to do with new economy, new media and so this whole industry was booming.
Companies went from 10 people to 100 people in two months. And then boo.com went broke.
I think it started with them, and then all investors kind of moved out, because they realized that new economy companies could actually fail.
This is NASDAQ. So we were at this boom phase here, and then everything crashed. We’re here around 9/11, and everything was gone..
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 if you go to Silicon Valley Today it’s like that. Everything is a 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.”
And this can happen anytime again. At this time, we saw them a lot.
I think even I would say that it’s not the question if it will happen, the question is when it will happen.
Make the hay while the sun shines!
And one thing I learned from that is to “make the hay while the sun shines”! And I’m not talking so much about money.
I’m talking about preparing for the bad times by investing into your skills and into your knowledge.
Don’t settle for Mediocrity, right?!
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. 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 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 then every problem looks like a nail.
So this was the course I did this time. It was really hard, but this was by Martin Odersky, who invented Scala, so he knows what he’s doing, and it was really interesting.
And all those resources are free on the net, so when you have time, invest it in fostering your skills.
Write code for your future self
So, between 2002 and 2012 I did many projects, mostly web projects, many PHP based and believe it or not, some of them are still running, like this:
They are haunting me still today. The problem is, when I did these 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 the company anymore.
And I’m always like:
“Oh my God, which idiot did this, because this code doesn’t make sense.”
.. and I knew it was me.
I think it’s important to write code that your future you will understand and be proud of! When you do something, do it right.
The Broken Windows Theory of Coding
One of my favorite analogy is “The Broken Windows” theory – which applies to coding very well.
Imagine that you are in a city, standing in front of a building, which is fine and everything is okay about it. Then someone comes and smashes one window.
If you’ll wait a few weeks and go back, you will be able to see that the whole building will start to rot away, it will fall apart, there will be graffiti on there, people will not care anymore.
And the same happens to code, because of 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 comes and says:
“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. 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 it will just take two weeks because it’s easy! We have done it already right?”
We know 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.
When you switch to a new stack, and the project is somehow complex, you won’t have the same features again from the start.
It happens because there is so much inherent knowledge woven into this whole system all the time, that you cannot redo it so easily. 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.
Does this site really needs React and Isomorphic JavaScript?
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. And we also want to rewrite our front-end every six weeks, right?
Because there’s always a new technology, especially in JavaScript. New technologies are coming up monthly. And there are companies that are kind of pushing these.
If it’s from Google or from Facebook it has to be awesome right? Because they know what they’re doing.
So I was trying to get into React and was watching this talk where they introduced React and Flux, and there they basically said that:
“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.”
“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, since when do arrows go back from the View to the Model in MVC? I think that’s kind of wrong.
There was a Q&A afterward with a lot of people in there, and no-one said anything. Everyone was like, “Hey yeah, MVC sucks, we need Flux definitely.”
And maybe she had a point, but this point she had was not rightly explained.
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 MVC!”
What are they talking about? After the talk, everyone was like “Oh MVCs a bad thing, we really need Flux because this solves all of our problems..”
Honestly, I’m the same. I would not have stood up there at the Q&A and said something like “that’s wrong”, because I’m always kind of humble, and think that the people are always right.
Keep Calm and Don’t Believe the Hype
You should really start to question things and don’t believe the hype.
After all, Facebook and also Google are just companies. If Facebook pitches React to the community, they have some kind of agenda behind that. Angular and React are pitching for new developers, and maybe it’s not because they want to give something to the community.
We should 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 behind that.
All those things are frameworks after all, and that’s other people’s code!
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?
It’s a very low hanging fruit to use third-party components, and also whole frameworks.
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, and you get some error from deep-down of the framework. You won’t really know where it comes from.
And there’s the question:
Isn’t it better to do something on your own instead of having it done quickly?
In this case, when things start to go wrong you have to deal with the code and learn how does everything fit together.
For instance, in JavaScript, we have this modularity thing – especially when we look again at things like React – where everything is separated into modules with different versions that somehow fit together.
So I tried a React project and when I was fed up with everything I did this npmnpm is a software registry that serves over 1.3 million packages. npm is used by open source developers from all around the world to share and borrow code, as well as many businesses. There are three components to npm: the website the Command Line Interface (CLI) the registry Use the website to discover and download packages, create user profiles, and... uninstall 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.
Don’t trust blindly in other people’s code!
This is npm. It’s actually quite the same problem here.
Obviously, the programming world has around 400 thousand problems, right? So there are 400.000 things that will solve 400.000 problems..
Last week I needed something to convert some UTF-8 HTML entities – and here you see the results for that:
There are so many modules that solve the same problem, and it’s really hard for you to find the right module to use.
You have to look for and decide:
- Is this package still maintained?
- How many bugs are there?
You should 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.
They have a clear error in their documentation. They have this var Entities, and then they do entities = new Entities(), so they create an unintentional loophole here.
And there is a question on StackOverflow which this guy answered by just copy-pasting from the documentation right into StackOverflow.
I’m totally convinced that the next person will take this and copy it right into their code. So, because it’s on StackOverflow it must be right.
No one said that there is something wrong with this code, so you have to be careful when you 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.
Final web development advice from Daniel Khan
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!
This means that you should – and it’s quite easy in Node actually to repeat yourself – really try to not copy-paste code around, like the same logic at some places.
You should pass the config into the application, and just require this config once, and not in each of your classes. Because then, you can change how the config is loaded, and all things like that.
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 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.
Yagni said, “You ain’t gonna need it.”
So when you do something, ask these questions:
- Will this project 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?
Be pragmatic about what you’re doing!
KISS
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 this book – it’s the Pragmatic Programmer. Many of the rules you find inside are kind of inherent in all the philosophy I was talking about.
Thank you!
