Over the 15+ years of my development career, I have learned several things that significantly increase my effectiveness. In this post, I share thos...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Awesome post. I've actually read the Clean Architecture book in the last month and I would highly recommend it. It significantly changed the way I think about software and taught me how to take decisions carefully.
Ok not in which ways?
What were you see we the most impactful aspects for you personally?
I'm curious about the interaction between 6 and 7.
6 - OO && don't use static
7 - Functional
In my experience, writing functionally implies lots of static functions (as this is how you declare a "pure" function (one without access to state) in OO languages).
Is 6 more around static objects? e.g. this would mean an object (and its relating data) are global
The "avoiding static" in point 6 is about not writing static functions with side effects or usage of global state. You are absolutely right that pure functions are not a problem.
Nice article! I always recommend Working effectively with legacy code, too. It's one of the best and most applicable books I've read.
What I think what should be added is to structure your code with "package by feature".
This changed a lot for me and I use the same concept now for structuring documentation.
It's much easier to see strange dependencies and to reduce/restrict/avoid them.
Much easier to navigate and find classes and much easier to grasp the code as the classes are much more cohesive (on package/folder level at least).
great post !
Thanks for sharing this ^^ I'm new to dev
Many topics, rich resource gathering!
Really nice article, congrats!
This post really means a lot to me, thank you so much
top!
I love this article and valuable information for juniors
Great post and valuable for all experiences! A reminder is always good!
Am happy this appeared on my feeds.
This is a lot and this is awesome
Thanks so much
Thanks for your valuable post
Such a detailed and helpful blog!!! Thanks!!
Really really good post.
Thank you for the resources! I'll take it to heart as a new dev.
Great content...
Solid post! Love the explanation of comments being code smell and suggesting there is a more clear way to write the code
The issue is not the comments themselves but the fact that many developers just repeat what's already obvious in the code or they use comments to avoid doing good software design. Instead of saying 'avoid comments', advice should be given on what makes a good comment. I love comments that detail why something is done, assumptions that are being made, explain workarounds (with links to github issues for instance) and so on. So I don't see comments as a code smell, I see them as an important part of the code and they should be reviewed as such.
This is great advice for a new dev such as myself. Thanks for providing reading material too. Very helpful!
As a developer with 18 years of experience, I find very odd the statement "don't inherit". I inherit in a healthy amount regularly. It also a common practice to have a base class for abstract factories. Is it because people don't do it properly? In my opinion, if you are SOLID, it is OK to have base classes. After all, the main argument of composition over inheritance seems to be geared towards obtaining services, not implementing them.
Or am I missing something? Cheers.
My advice is to "don't inherit for code reuse". Inheriting a purely abstract class is basically the same as implementing an interface: all about subtyping, and not about code reuse.
I regard inheritance for code reuse as an advanced tool, that sometimes can be used appropriately, but is better not handed to devs that are just starting out.
Do one thing in your functions
By doing a single thing in a function, you can give it a clear name
Great post. And this bit of advice is something I always seem to forget.
Nice article!
Awesome post. Thanks to write that.
Very helpful post
I think we can add
Don't trust everything you read on the internet, for example, inheritance or SOLID principles or ..., without knowing the drawbacks before the gain.
Try to search on the internet about SOLID principles, for example, you would see that the majority of the resources tend to over-praise them without mentioning their limitations.
I have already written two articles about the SRP and the OCP, you can check them out to know what I mean.
dev.to/mayallo/do-you-really-know-...
dev.to/mayallo/open-closed-princip...
The post contains some great information but are those really things a junior developer should focus on? To me a junior developer is someone who is still getting the lay of the land, like learning the programming language, the tooling and so on. While something like software design is extremely important to me, I wouldn't want a junior developer to worry about that yet. I feel that in this industry we expect way too much, way too soon. The best way to learn is often from your mistakes. Following best practices blindly might sound like a good idea at the start but how is a junior supposed to know when there's a best practice and in what situation it's applicable? Like you said, code is not the point. I'd rather have them thinking about the problem first, the quality of the code later. Having a good mentor, doing pair programming and getting detailed feedback on reviews will be far more valuable to a junior imho.
Really great post, nice work! I agree with most of it and love all the additional reading sources.
About point #3, I agree but I think it's a little more nuanced. Junior devs should definitely follow best practices when starting out. The issue though is that sometimes there is no consensus around what the best practice is, or there may be outdated resources on the internet recommending outdated best practices. This makes it difficult for junior devs to discern what actually is a best practice or not, but that's more an issue with the industry as a whole than anything else. Things move quickly, and what used to be a best practice last month might not be the best way to go about it next month.
I'd also like to shamelessly recommend my own book to add to the resources. I just published a book called "Junior to Senior: Career Advice for the Ambitious Programmer". Here's a link to a free sample chapter: How to Read Unfamiliar Code
I talk about some similiar points your mentioned in your post, and you mentioned some points that aren't covered in the book. All in all, nice job and I think the more resources junior devs have to get up to speed in the industry the better.
Hello Jeroen De Dauw,
thank you for your article.
It was easy to read and many links were added to the specific terminologies that helped me understand the article better.
I think it's a great thing when someone wants to learn more than they should.
I also agree that documentation is necessary and needs to be written, imo.
Still, the things you expect from a junior developer are a bit overwhelming in my opinion. It sounds like a way to become some sort of full-stack developer.
For example, I understand your article to mean that this junior developer is expected to:
Please correct me if I'm wrong here.
As a software engineer you write code that you design and test. If you split that into 3 different jobs, you will not get a good outcome. Yes, you can have dedicated testers or people who specialize in architecture, but this does not remove the need for devs to think about what they are doing and to create automated tests.
Thank you!!! Very useful post for those who are just starting to work in IT. I also want to recommend looking at the code of well-known or just interesting projects, to analyze its structure. If you want to see how this code works in business and what is the life cycle of the project, watch the growth of young companies. For example, I like to look at SlotoGate. It's nice to see how young projects are gaining popularity.
The book recommendations looks like someone from ThoughtWorks made them. I’ve always recommended Code Complete over Clean Code. The principles are explained clearly with a lot less preaching and TDD gospel.
You make a lot of great points. I'll add one suggestion. Try out a low-code programming tool. Low-code is growing and it gives you an overview the process for creating an app. It replaces a lot of the tasks of classic development, in which you should definitely become expert, but low-code enables you to get some wins.
I play around with the jetveo.io platform to make apps for myself, just for fun. It's kind of like when html start a long time ago: in order to learn how to do the coding for work, I taught myself with a side project for myself (which was much more interesting and engaging).
People always forget the most valuable skill! Learn to use a debugger and/or [developer tools](People always forget the most valuable skill! Learn to use a debugger and/or developer tools!
awesome post
Nice and insightful article! 💯
Wonderful post buddeee
Great advices! Thanks for posting it.
**Tradexpro Exchange **is the best php script based Cryptocurrency platform for all time.
Awesome post. Thank you for your advice, I am trying to transition to tech without a CS degree and it's not been easy. Thank you these recommendations.
Great post, lot of usefull things i a good structure.
This is awesome, thank you so much!! ❤️
Literally my 3rd day of reading small chunks + blog posts linked in this post. Very good stuff!
Testing comment
Always go for progress and not perfection as a developer. We keep learning everyday and daily progress will take you to higher heights in your journey as a developer.
Great post.
To be honest, it's good to review these points even as a more seasoned developer, just to check which habits to keep and which ones to get rid of.
Very nicely summarized !
very good posts