Working with companies from early-stage startups to Fortune 500, I’ve experienced both the struggle of continuing someone else’s work and the joy of it. The difference is only in their approach towards the design of their code. It’s a minor effort if done on time, with a huge impact on the overall development of the software.

In this presentation, we’ll focus on what distinguishes a good developer from a strong one and learn how to stand out from the crowd. After this presentation, you’d understand how to incorporate the SOLID principles in your daily work and design your code for extendibility. You’d learn how to write code in a way that will make it easy to go back to a feature you developed a year ago and extend it with additional functionality in minutes, not hours.

Comments

Please login to leave a comment

SOLID with a good practical example and well made conclusions. Interesting qa session. Well done.

Nicolas Carlo at 12:59 on 10 Nov 2019

Very nice talk and great delivery. I liked the concrete examples and story of a change, so we can compare. Thanks!

Ognyan Tsonev at 13:25 on 10 Nov 2019

Very informative talk. SOLID explained in a practical manner.

Babarinde at 14:09 on 10 Nov 2019

Fantastic

Great start, but examples could be better with DDD ;)

By the way, remoteok.io is extremely slow and probably insecure, don’t think that was a good example when solid isn’t good choice for you. Probably, better example will be any startup that starts in short period, get investments and then spending money to refactor everything after they got enough money and time.

Trajche Nakov at 16:13 on 10 Nov 2019

Great delivery, good practical examples which makes it much clearer then just talking theory.

A great example was chosen which was very helpful. Also, the spreaker is cute 😃

I liked the way SOLID principles were presented. The practical approach was very interesting, the example is wonderful. My only concern, as I already mentioned on the talk during the questions time, was that the domain model was bound to the framework - in this particular case - Laravel/Eloquent. I would rather make it as a separate thing and make use of some DDD patterns. Another thing to note (which I didn't mention) is that you could have divided the repository into 2 pieces - one for the read part, and one for the write part, following CQRS.