Introduction
Many believe that transitioning from an effective Junior-level developer to a mid-level is just a matter of time and experi...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the article!
What resources would you recommend to improve in Tip #6 ?
I've heard about Design Patterns by The Gang of Four, but I don't know if it's still the best book on that topic 🤔
I strongly recommend refactoring.guru for studying patterns
Never heard of it before, I shall give it a go. Thanks!
Hey Yisus, I strongly (and by strongly I mean really really boldly) recommend
Head First Design Patterns
;)
Thanks! I'll add it to my list right away 😄😄😄
Good! It's a must and it's written in such an awesome way ;)
I've found the gang of 4 book to be really helpful in this regard.
Also the podcasts from coding blocks do a good job of giving great examples on when to use them and recognise them.
Took a quick look at the Coding Blocks Podcast. Good info, thanks
I gotta give the legendary book a try then 😃
Thanks for the podcast recommendation 😁
Re: Point #7 - There is an increasing number of women in our industry. I think we should try to steer clear of saying things like "the next guy" as it's not very inclusive. Especially as women find it very difficult to progress in our industry, using the word 'guy' suggests that progression is only for men. Of course you may accuse me of reading too much into it, but i'm not in the affected minority and in the interest of a healthy inclusive community, it would be easy to change the word "guy" to "developer"
You are absolutely right, Idusoswa. I thought of the exact same thing when writing the post but never made the change. I updated the post now thanks to your suggestion.
Very useful!
Number 3 helped me a lot as I’m dealing with a situation in which a have a bunch of helper functions and some of them can take up to 5 parameters. Even though I did some fancy things with classes, I hadn’t had the idea of wrapping those functions into a class.
Where would you advise me to store this Helper class?
Thank you for your time!
Hey Andrei, thanks for sharing your thoughts!
Usually when having a helper method that only provides dummy or trivial functionality, a good idea is to put it in a class with an appropriate name, and call an instance of this class. You can also make this class a Singleton (Google it) so that you don't need to have multiple instances of it accross your project.
Sounds awesome! Thank you.
And don't try to adapt to all 7 (or 14) habits at one point. Choose one to (main) focus on one week, check if you made some progress on it, then choose the next one. When you have focused on all of them, repeat at the first one.
Hi,
I hope to get your consent to translate and shared with Chinese developers, I will indicate the source and author.
Hi Alice-sos, Yes you can translate it into Chinese, also send me the link afterwards!
👌Thanks!
Chinese link:《高效程序员的 14 个习惯(一)》nextfe.com/14-habits-of-effective-...
Hi Alice, thanks for mentioning the original article in your post ;)
This is a great post, cheers! I agree with you particularly as the company I currently work at do not follow many of these and that tends to provide me with a lot of frustration. Slowly but surely, since I'm a new developer, I'm introducing these kinds of things and ensuring to confirm them with other devs to facilitate some kind of standard. There's definitely improvement so far in efficient and effective teamwork, and code readability and reusability.
I am, however, guilty of not following at lot of these when pressures like budget, time-constraints, and "it just has to work!" get in the way so it's good to be reminded to try and pick these up as habits to make them the first thing I do.
Looking forward to Part 2. Thanks again!
Thanks Kieran! That's totally understandable, it's hard to strictly follow these rules. That's why I believe we should do it until they become habits, then it will be hard to break them ;)
With regard to point 2 (Give meaningful names) I found that the smaller your methods get, the less important it is to have real meaningful names. They can even distract from what the code is doing. If you have a piece of code of - say - 10 lines, then having a one-letter variable is not so bad, whereas that is a real problem if you are digesting a multi-hundred lines piece of code.
An example in the Progress 4GL (where I use to work in) to get the number of orders of a customer. Compare the below two functions:
To me, the latter is more clear than the first one, despite the less meaningful name.
I've met senior developers who would benefit from these tips. And it is a bit sad. Especially when you are a junior who doesn't know better and learns from the bad practices in the code they are working with...
All the points are great, but I especially like point 7.) - code is a way of communication. I think this concept is pretty nicely presented in 'Clean Code', a book that I highly recommend.
Exactly, many of the habits are based on this excellent book ;)
Some smart man once said to me: "the best code is code you don't write". Which sums up your article very nicely. In all the projects I have ever been involved the best code was always small and atomic. This really levels up ones programming skill.
That's such a great advice, Fohlen. Code should be elegant and to the point.
So good article! thanks for write it.
I think, mentoring others can help you improve a good ways to understand the concepts that u alreay had. Also contributing with pull in open source proyects, and at last but not least follow the standars for make better code like psr-standars.
P.S. Sorry if my english is bad.
Thanks for your feedback Jose! Really appreciate it (your English is fine by the way). Your additional points are very valuable as well 😊
Great post!
(Uncle Bob, is that you?)
Thanks, Austin! (I am not uncle Bob but I surely admire him ;) )
It is very useful information, thank you for this nice article👏🏻
Thanks, Ajda! :)
7: How are you writing everything down?
I’ve started taking notes in markdown with an extension for vscode, and we are all getting a little more comfortable with Confluence, but it’s not perfect. Organization is a little tricky.
2(a) - change names when meaning changes! Method purposes sometimes evolve, so refactor appropriately!
Exactly! An effective developer should keep up with code changes ;)
Great advices! I'll put in practice every one.
These are a great set of habits to learn, I look forward to reading part 2!
Thanks Sam!
Nice! It is good to learn from others, and confirm that we are on a good way for coding, thanks for the post and sharing your experience.
Thanks for the article! Will look to implement these in my work.
You are welcome Thomas!
Thanks For The Article Paul! Extremely Helpful
Thanks for your feedback, Ahvi!
Excellent post. Awaiting the next part.
Thanks!
Excellent article, very useful.
I feel totally identified with the First point. I'll put in practice all yours advice.
Thanks!!!
Hey Smill, Thanks for your feedback! Let me know how it goes ;)
You are welcome Waqar, feel free to share it with your colleagues or students! ;)
Great write up, I agree with habits can make for a great developer, waiting for your next set of habits
Thanks Giorgos!
Thanks Fab!
Nice article. :)
Hi,
Great post, enjoyed reading this!
look at me, I'm your senior developer now 😁