Smart Developers Write Simple Code

00:00:00: When working as a developer, when

00:00:02: writing code, there are certain principles

00:00:07: you might want to keep in mind and

00:00:09: follow.

00:00:10: Something like the DRY principle, the

00:00:13: don't repeat yourself principle, but also,

00:00:17: for example, the KISS principle, the "Keep

00:00:20: it simple, stupid!" principle.

00:00:23: That's a principle I want to take a closer

00:00:27: look at today, because it's fairly easy,

00:00:32: especially if you're maybe a less

00:00:34: experienced developer, to write

00:00:37: unnecessarily complex code.

00:00:40: And it's not just the code complexity, but

00:00:43: I'll get back to other forms of

00:00:46: unnecessary complexity later.

00:00:49: Let's start with the code complexity.

00:00:52: Especially if you're not that experienced,

00:00:55: maybe, it can be quite tempting to

00:00:58: introduce a lot of unnecessary

00:01:01: abstractions in your code.

00:01:04: It can be quite tempting to think, well,

00:01:07: what if I also maybe need to use a

00:01:11: certain function or a certain piece of the

00:01:15: code base in a slightly different way in

00:01:18: the future?

00:01:19: And all of a sudden, you start making a

00:01:22: function that did one specific thing in

00:01:25: the past more generic so that it can do

00:01:28: more things or accept more types of

00:01:32: input and so on.

00:01:33: So it can be quite tempting to make

00:01:36: your code more flexible so that it can

00:01:39: handle more use cases and your code

00:01:41: base gets more modular and more

00:01:43: generic.

00:01:44: And that's a good thing, right?

00:01:46: We want a modular and generic code

00:01:49: base.

00:01:50: Well, not necessarily.

00:01:53: If you're writing some code for a

00:01:56: package that you plan to distribute as a

00:01:59: third party package to developers all

00:02:02: over the world, then you might need

00:02:04: some generic code or modular code.

00:02:08: You might need to support a lot of

00:02:11: different use cases.

00:02:12: But even then, you might not need to

00:02:14: support all the use cases you think you

00:02:17: need to support.

00:02:19: And especially if you're working on your

00:02:22: own application.

00:02:23: So if you're writing code for an app you

00:02:26: built where you know what it should do,

00:02:30: it really doesn't make a lot of sense to

00:02:34: already think of all kinds of possible

00:02:37: variations at the point of time where

00:02:40: you're getting started.

00:02:42: Sure, there always is a trade-off and if

00:02:45: your code is too specific, you might

00:02:48: spend a lot of time refactoring that code

00:02:51: if you eventually need to support

00:02:54: different use cases or if parts of that

00:02:57: code need to get more flexible in the

00:02:59: future.

00:03:00: But on the other hand, if you write

00:03:02: everything as generic and flexible and

00:03:05: modular as possible right from the start,

00:03:08: you spend a lot of time making your

00:03:11: code base quite complex and that then

00:03:14: can actually also lead to problems in the

00:03:18: future because it's now maybe not so

00:03:21: easy to use it in the way you want to use

00:03:23: it because you made it very flexible and

00:03:25: modular so you need to pass a lot of

00:03:28: configuration parameters or stuff like

00:03:30: that.

00:03:31: So there actually is a trade-off here.

00:03:34: Modularity and flexibility can make

00:03:37: sense but it's not always what you

00:03:40: should go for.

00:03:41: And I guess you can kind of like draw a

00:03:46: bell-shaped curve where on the left side

00:03:49: of the bell where the curve is very flat,

00:03:52: we have beginners who write very

00:03:54: simple code that's not very flexible and

00:03:57: modular because they don't know that

00:04:00: they might need more modular code or

00:04:02: they're not able to write more generic

00:04:04: and flexible code.

00:04:06: But then we go on top of that bell so we

00:04:09: go up that curve if that curve depicts the

00:04:12: complexity of the code base and we

00:04:15: suddenly start writing pretty complex

00:04:17: code because we feel smart about it

00:04:19: because we write code that supports a

00:04:21: lot of different use cases and input

00:04:23: parameters and we suddenly end up

00:04:26: with that very complex code base which

00:04:30: we don't need for the project or which

00:04:32: we might not need for the project we're

00:04:34: working on and we introduce new

00:04:37: problems along the way and of course if

00:04:40: we write very complex code we also

00:04:43: spend more time solving a specific

00:04:46: problem because we don't just solve the

00:04:48: problem but we also think of future

00:04:50: problems which we also try to solve

00:04:52: already.

00:04:53: So it takes us more time to write the

00:04:56: code to get a certain job done because

00:04:59: we try to make that code as flexible and

00:05:03: modular as possible.

00:05:05: Well and then we go down that curve

00:05:07: again as we get more experienced

00:05:09: because as you get more experienced as

00:05:11: a developer you learn that you might not

00:05:15: need the most generic and flexible code

00:05:17: base in all situations.

00:05:20: That in a lot of situations and scenarios

00:05:23: it's fine if you just write good code that

00:05:26: solves a specific problem and doesn't try

00:05:29: to solve all kinds of problems you might

00:05:32: be facing in the future.

00:05:33: If you then evolve your code base so that

00:05:36: you need to solve another problem you

00:05:39: can still make parts of your code more

00:05:42: flexible and modular but even then you

00:05:45: might just make it as modular and

00:05:47: flexible as needed to solve the original

00:05:50: problem and maybe now another new

00:05:53: problem you need to solve.

00:05:54: So even then you might not go down

00:05:57: that route to make it as modular and as

00:05:59: flexible as possible and that is a really

00:06:03: important lesson to learn that you don't

00:06:06: need to look smart when writing your

00:06:09: code that you don't need to try to solve

00:06:12: all possible kinds of problems with your

00:06:15: code base and that instead it's often

00:06:18: better to keep the code simple to keep

00:06:21: the code base simple and by the way

00:06:24: simple code does not mean bad code

00:06:27: not in any way instead simple code

00:06:30: means that your code solves a certain

00:06:32: problem and it does that well and of

00:06:35: course it also does that in a way that

00:06:37: handles potential errors that might arise

00:06:40: and so on but it's not getting

00:06:43: unnecessarily complex and that is a skill

00:06:46: that simply comes with experience.

00:06:49: It is something you can learn by always

00:06:52: questioning your code by always being

00:06:55: critical and asking yourself do I need to

00:06:59: make this code more generic more

00:07:02: flexible or should I keep it simple is it

00:07:05: simple enough does it do what it should

00:07:07: do and does it do that well or am I trying

00:07:11: to do more than I originally planned or is

00:07:15: the code maybe not doing enough are

00:07:17: there potential errors that might occur

00:07:19: that I'm not handling you always have to

00:07:23: question your code and of course it also

00:07:25: helps if you're not working alone but in a

00:07:28: team if you got a colleague or a friend

00:07:30: who reviews your code and who gives

00:07:33: you input on your code because there is

00:07:37: the danger of writing bad code because

00:07:39: it's too simple too focused on one

00:07:43: specific problem maybe but in my

00:07:46: opinion there is an even bigger danger

00:07:48: of writing bad code because it becomes

00:07:51: too complex because it tries to do too

00:07:55: much now as I mentioned originally at

00:07:58: the beginning here it's not just the

00:08:00: complexity of the code base that

00:08:02: matters and that you should keep an eye

00:08:06: on it's also a complexity regarding the

00:08:10: technologies you might use because for

00:08:13: example if you're building a blog website

00:08:16: your own personal website which should

00:08:19: contain a blog where you plan on

00:08:21: sharing some posts about your life or

00:08:24: some tutorial posts whatever you could

00:08:28: just create that blog with a content

00:08:31: management system like wordpress you

00:08:34: could also build it on your own of course

00:08:36: with some static site generator with

00:08:40: something like astro.js for example but

00:08:43: you could also just build it as a node.js or

00:08:46: php based website where you store your

00:08:50: blog post data in a database and you

00:08:52: render that as html documents then you

00:08:57: could do all that and that would all be

00:08:58: fine but you could also start building a

00:09:02: complex application where you have a

00:09:04: standalone react or angular or whatever

00:09:08: single page application front end and

00:09:10: then a rest api backend or a graph ql api

00:09:14: doesn't matter you have some caching

00:09:17: in between a caching layer you set up an

00:09:20: extra database to which the backend

00:09:22: communicates you start bringing in a

00:09:26: ton of extra third-party libraries into both

00:09:29: ends also in the front end to add lots of

00:09:33: extra features that might not be too

00:09:36: important for a blog but that you feel

00:09:38: like you need to have then you start

00:09:41: hosting that blog on aws and you want

00:09:45: to do it with docker and containers and

00:09:48: also in some kind of serverless way so

00:09:51: you look into all the services you need to

00:09:53: do to do that and so on you see what i

00:09:57: mean you can build a simple blog in a

00:10:00: pretty complex way and don't get me

00:10:03: wrong you can do that it can be a great

00:10:06: exercise if you want to get better at

00:10:09: working with docker or with aws or react

00:10:13: or whatever definitely start building

00:10:16: demo projects build your blog that way

00:10:19: but only do it if you do want to practice

00:10:22: certain technologies or services don't

00:10:26: start building your blog like this if you

00:10:29: just want a blog if that's the main thing

00:10:31: you want if you don't care about the

00:10:33: exercise because you don't need that

00:10:35: super complex text deck you don't need

00:10:38: a super complex web application that

00:10:42: consists of dozens of technologies and

00:10:45: libraries and frameworks and so on just

00:10:48: to render some blog posts onto the

00:10:51: screen of your website visitors you don't

00:10:54: need that so here again keep it simple

00:10:58: don't introduce all those libraries and

00:11:01: packages because you read somewhere

00:11:03: that you need to use them instead keep

00:11:07: it simple use the simplest possible

00:11:10: solution for achieving the goal you want

00:11:13: to achieve unless as mentioned you

00:11:16: want to practice working with those

00:11:18: technologies because then of course

00:11:20: your goal also isn't to render blog posts

00:11:24: onto the screens of your visitors or at

00:11:26: least that's not the primary goal then

00:11:28: but the goal then is to learn and grow

00:11:30: and then it's of course absolutely fine

00:11:33: and the right thing to do to work with all

00:11:36: those packages and services and

00:11:38: technologies and so on so then

00:11:40: definitely do it but if your goal is

00:11:43: something else if your goal is the end

00:11:45: product the blog or whatever it is then

00:11:48: you should keep your tech stack simple

00:11:51: because in that case if you would make

00:11:53: it unnecessarily complex you would just

00:11:56: spend more time unnecessarily on

00:11:59: working on that project and you would

00:12:01: also make it harder to maintain because

00:12:03: if you come back to a super complex

00:12:06: project in the future it simply takes you

00:12:09: longer to get back into it and that's the

00:12:11: case no matter if we are talking about a

00:12:14: complex tech stack or if we're talking

00:12:17: about a complex code base so therefore

00:12:20: in a nutshell keep it simple and don't

00:12:24: think that it's smart or a sign of

00:12:27: intelligence to use complex technologies

00:12:31: or to write complex code it's actually the

00:12:36: opposite a good developer uses the best

00:12:39: and simplest code or tool to get a job

00:12:43: done without doing that job in a bad

00:12:47: way so without ignoring important

00:12:51: features the code should have or

00:12:53: something like that but adding

00:12:55: unnecessary complexity it's not

00:12:58: something you want to do