DEV Community

loading...
Cover image for The 14 habits of highly effective developers (Part 1)

The 14 habits of highly effective developers (Part 1)

pavlosisaris profile image Paul Isaris Originally published at paulisaris.com Updated on ・5 min read

Introduction

Many believe that transitioning from an effective Junior-level developer to a mid-level is just a matter of time and experience.
Truth is that the line separating these 2 kinds of developers is very thin and subjective. This article is not going to add more to the endless debate on "What exactly defines a mid-level developer".

To be honest, I firmly believe that something that can shift one's mindset and help in transitioning one from a Junior to a Mid-level or Senior developer is habits:

A habit is something that you start doing systematically until it is no longer something strange to you but comes naturally.

Forming code-related and work-related habits is of crucial importance when it comes to professional and personal advancement.

Let's see a list of everyday habits that, upon mastering them, will definitely help you get to the next level and progress fruitfully:

1. Write small methods

Ideally, no more 20-30 lines of code (LoC) long. This habit is extremely important. It will not only force you to write compact code, but it will help your analytical thinking when it comes to modularize your code.
Having big methods with a high degree of indentation (many ifs, for loops etc) is a nightmare. It may seem easy and straightforward when you write a method like that, but after some days even you will have a hard time figuring out what this method even does.

To add insult to injury, big methods often are not-reusable. They were written to serve only one need in a project and it will be difficult to be used anywhere else.

2. Give meaningful names

Both to methods and variables. It is not acceptable for a mid-level developer to have variables named "x" or "xyz", or even "object". The purpose of naming variables with English words is so that they have a meaning.

Communicating with your code is far more important than communicating with documentation or comments.

The purpose of comments is to explain the "why", not the "how" in the code.

Having meaningful variables helps you communicate with whoever reads the code better, and may remove the need for an excessive amount of comments.
The same goes both for variables and methods.
Also, when struggling with naming a method for too long, consider refactoring your code so that the method gets more simple. A name for a good, clean method always comes to mind easier than the name of a cluttered one.

When struggling with naming things, take a step back and think of the possibility that the component you are trying to name is too complicated and needs refactoring.

3. Don't clutter your methods with many parameters

Having many parameters in a method is a sign for refactoring. More often than not, writing this kind of methods violates the SRP (Single Responsibility Principle) meaning that they do too many things.
An efficient, clean method does one thing, well.
As Uncle Bob said, three is the maximum arguments acceptable. Although this may not be strict. It gives you an overview of the desired number of arguments in a method.

Fight the urge to change some of your method's local parameters into class fields. Consider refactoring your code so that a method does fewer things, or break up your method into 2 separate ones.

Quote by Robert C. Martin:
"Functions should have a small number of arguments. No argument is best, followed by one, two, and three. More than three is very questionable and should be avoided with prejudice."

4. Avoid too many methods in a class

As with the number of parameters, the number of methods that a class has is also important.
Big classes with a lot of methods usually signify a component that knows too much or does too much. We refer to these components as God Classes to characterize an anti-pattern of writing highly coupled code.

If you have many methods in a class, consider how often you will need to enter this class in order to change its behavior, as the code progresses through time. This may violate the Open–closed principle stating that "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".

5. Use LTS / stable releases when using a 3rd party library

Always keep in mind the next developer that will be required to use your code and re-compile the project.
Using LTS (Long Term Support) versions of libraries, plugins and frameworks may not be the best when it comes to shiny new features but it will be better when needing to re-build or re-compile the code sometime in the future.

Fight the urge to use the latest and greatest version of a tool and stick to the safest and more stable one. Your future self and co-workers will thank you!

6. Learn to identify the most common design patterns

That's right, most big projects are built using one or more Design Patterns. A Design Pattern defines the description, the relationships and the abstraction level in a component. You don't need to know all of them or be good in all of them, but knowing the most essential will be beneficial not only in terms of thinking and designing but also identifying them in a code base.

When able to identify a design pattern in a code base, one is also able to extend it or add more functionality to it, by knowing in which places to look for specific classes and objects.

A well-implemented Design Pattern causes everyone involved in a project to speak the same design language and communicate more effectively through the code.

7. Always think of the next developer

Whether it is you, another co-worker, a new employee or even a developer in another company, someone will be required to extend your code or add more functionality to it.
It is really hard to get a grasp of this since most junior developers are used in a typical University project paradigm where you write the required code and then nobody ever gets involved with it.

Things in a professional setting are somewhat different; You will be asked to write code in a project that was written many years ago, and your code will have to be ready for "the next developer" that may come in a few years.
So whenever you are ready to write a temporary "hack" just to get something working, whenever you add something in the build process and avoid documenting it, whenever you skip refactoring, you are simply adding more Technical debt that someone will have to deal with in the future.

Take the time to review your work every couple of hours. Add needed documentation to README files, delete unused code and files that you temporarily added to the project. When not sure about an architectural or programming decision you took, communicate with someone more experienced in your workplace.
You will not only improve the state of the code you wrote, but also you will get better at handling such situations in the future, and getting used to having your pride hurt. (This is something that will happen all the time when you are not a junior anymore :D )

Conclusion

Transitioning from a Junior to a Mid-level developer is not something that happens overnight. Advancing your career and getting better as a professional developer is a matter of forming good habits. In this article, I began laying out the most important habits one needs to form to begin this transition and make an impact as a Software Developer.

Please leave your comments below regarding these habits and stay tuned for Part 2! :-)

This article was posted on my personal blog.

Discussion (58)

pic
Editor guide
Collapse
gzuzkstro profile image
Yisus Castro✨

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 🤔

Collapse
sur0g profile image
sur0g

I strongly recommend refactoring.guru for studying patterns

Collapse
gzuzkstro profile image
Yisus Castro✨

Never heard of it before, I shall give it a go. Thanks!

Collapse
pavlosisaris profile image
Paul Isaris Author

Hey Yisus, I strongly (and by strongly I mean really really boldly) recommend
Head First Design Patterns

;)

Collapse
gzuzkstro profile image
Yisus Castro✨

Thanks! I'll add it to my list right away 😄😄😄

Thread Thread
pavlosisaris profile image
Paul Isaris Author

Good! It's a must and it's written in such an awesome way ;)

Collapse
jamesdengel profile image
James dengel

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.

Collapse
jscooksey profile image
Justin Cooksey

Took a quick look at the Coding Blocks Podcast. Good info, thanks

Collapse
gzuzkstro profile image
Yisus Castro✨

I gotta give the legendary book a try then 😃

Thanks for the podcast recommendation 😁

Collapse
waqarhusain profile image
Waqar Hussain

This type of tips are very helpful for juniors and as well as senior developers. Because teachers in universities even do not know about these things. I really enjoyed this article. Thank you so much for this.

Collapse
simoroshka profile image
Anna Simoroshka

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...

Collapse
pavlosisaris profile image
Paul Isaris Author

You are welcome Waqar, feel free to share it with your colleagues or students! ;)

Collapse
ldusoswa profile image
ldusoswa

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"

Collapse
pavlosisaris profile image
Paul Isaris Author

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.

Collapse
anduser96 profile image
Andrei Gatej

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!

Collapse
pavlosisaris profile image
Paul Isaris Author

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.

Collapse
anduser96 profile image
Andrei Gatej

Sounds awesome! Thank you.

Collapse
alicesos profile image
Alice-sos

Hi,

I hope to get your consent to translate and shared with Chinese developers, I will indicate the source and author.

Collapse
pavlosisaris profile image
Paul Isaris Author

Hi Alice-sos, Yes you can translate it into Chinese, also send me the link afterwards!

Collapse
alicesos profile image
Alice-sos

👌Thanks!

Thread Thread
alicesos profile image
Alice-sos • Edited

Chinese link:《高效程序员的 14 个习惯(一)》nextfe.com/14-habits-of-effective-...

Thread Thread
pavlosisaris profile image
Paul Isaris Author

Hi Alice, thanks for mentioning the original article in your post ;)

Collapse
mrkdawg profile image
Kieran Wright

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!

Collapse
pavlosisaris profile image
Paul Isaris Author

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 ;)

Collapse
baerroland profile image
Roland Bär

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.

Collapse
patricktingen profile image
Patrick Tingen

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:

FUNCTION getNumOrders RETURNS INTEGER (piCustNum AS INTEGER):
  DEFINE VARIABLE iNumOrders AS INTEGER.

  FOR EACH order WHERE order.custnum = piCustNum:
    iNumOrders = iNumOrders + 1.
  END.

  RETURN iNumOrders.
END FUNCTION.
FUNCTION getNumOrders RETURNS INTEGER (piCustNum AS INTEGER):
  DEFINE VARIABLE i AS INTEGER.

  FOR EACH order WHERE order.custnum = piCustNum:
    i = i + 1.
  END.

  RETURN i.
END FUNCTION.

To me, the latter is more clear than the first one, despite the less meaningful name.

Collapse
canu667 profile image
Canu667

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.

Collapse
pavlosisaris profile image
Paul Isaris Author

Exactly, many of the habits are based on this excellent book ;)

Collapse
fohlen profile image
Fohlen

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.

Collapse
pavlosisaris profile image
Paul Isaris Author

That's such a great advice, Fohlen. Code should be elegant and to the point.

Collapse
usuario001 profile image
José Manuel

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.

Collapse
pavlosisaris profile image
Paul Isaris Author

Thanks for your feedback Jose! Really appreciate it (your English is fine by the way). Your additional points are very valuable as well 😊

Collapse
wolfhoundjesse profile image
Jesse M. Holmes

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.

Collapse
austinstanding profile image
Austin Standing

Great post!

(Uncle Bob, is that you?)

Collapse
pavlosisaris profile image
Paul Isaris Author

Thanks, Austin! (I am not uncle Bob but I surely admire him ;) )

Collapse
ajdakter profile image
Ajda Akter

It is very useful information, thank you for this nice article👏🏻

Collapse
pavlosisaris profile image
Paul Isaris Author

Thanks, Ajda! :)

Collapse
noamyogev84 profile image
Noam Yogev

Hi,
Great post, enjoyed reading this!

Collapse
codingmindfully profile image
Daragh Byrne

2(a) - change names when meaning changes! Method purposes sometimes evolve, so refactor appropriately!

Collapse
pavlosisaris profile image
Paul Isaris Author

Exactly! An effective developer should keep up with code changes ;)

Collapse
ahvblackwelltech profile image
Ahvi Blackwell

Thanks For The Article Paul! Extremely Helpful

Collapse
pavlosisaris profile image
Paul Isaris Author

Thanks for your feedback, Ahvi!

Collapse
svasquez profile image
Smill Vásquez

Excellent article, very useful.

I feel totally identified with the First point. I'll put in practice all yours advice.

Thanks!!!

Collapse
pavlosisaris profile image
Paul Isaris Author

Hey Smill, Thanks for your feedback! Let me know how it goes ;)

Collapse
rodolforobles profile image
Rodolfo Robles

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.

Collapse
luispa profile image
LuisPa

Great advices! I'll put in practice every one.

Collapse
devfanooos profile image
FaN000s

Excellent post. Awaiting the next part.

Collapse
pavlosisaris profile image
Collapse
giorgosk profile image
Giorgos Kontopoulos 👀

Great write up, I agree with habits can make for a great developer, waiting for your next set of habits

Collapse
pavlosisaris profile image
Paul Isaris Author

Thanks Giorgos!

Collapse
pavlosisaris profile image
Collapse
mubarakky profile image
Mbo

Nice article. :)

Collapse
sambenskin profile image
Sam Benskin

These are a great set of habits to learn, I look forward to reading part 2!

Collapse
pavlosisaris profile image
Collapse
t33hsn profile image
Thomas Henson

Thanks for the article! Will look to implement these in my work.

Collapse
pavlosisaris profile image
Paul Isaris Author

You are welcome Thomas!

Collapse
vicoerv profile image
Vico

look at me, I'm your senior developer now 😁