DEV Community

The 14 habits of highly effective developers (Part 1)

Paul Isaris on February 10, 2019

Introduction Many believe that transitioning from an effective Junior-level developer to a mid-level is just a matter of time and experi...

Read full post

Yisus Castro✨ • Feb 11 '19

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 🤔

sur0g • Mar 10 '19

I strongly recommend refactoring.guru for studying patterns

Yisus Castro✨ • Mar 11 '19

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

Paul Isaris • Feb 11 '19

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

;)

Yisus Castro✨ • Feb 11 '19

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

Paul Isaris • Feb 11 '19

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

James dengel • Feb 12 '19

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.

Justin Cooksey • Mar 9 '19

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

Yisus Castro✨ • Feb 13 '19

I gotta give the legendary book a try then 😃

Thanks for the podcast recommendation 😁

ldusoswa • Feb 21 '19

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"

Paul Isaris • Feb 21 '19

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.

Andrei Gatej • Feb 10 '19

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!

Paul Isaris • Feb 10 '19

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.

Andrei Gatej • Feb 10 '19

Sounds awesome! Thank you.

Roland Bär • Feb 15 '19

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.

Alice-sos • Apr 15 '19

Hi,

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

Paul Isaris • Apr 15 '19

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

Alice-sos • Apr 15 '19

👌Thanks!

Alice-sos • May 22 '19 • Edited

Chinese link：《高效程序员的 14 个习惯（一）》nextfe.com/14-habits-of-effective-...

Paul Isaris • May 22 '19

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

Kieran Wright • Feb 11 '19

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!

Paul Isaris • Feb 12 '19

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

Patrick Tingen • Apr 30 '20

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.

Anna Simoroshka • Feb 12 '19

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

Canu667 • Feb 11 '19

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.

Paul Isaris • Feb 11 '19

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

L. Berger • Feb 12 '19

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.

Paul Isaris • Feb 12 '19

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

José Manuel • Feb 12 '19

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.

Paul Isaris • Feb 12 '19

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

Austin Standing • Feb 14 '19

Great post!

(Uncle Bob, is that you?)

Paul Isaris • Feb 14 '19

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

Ajda Akter • Feb 12 '19

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

Paul Isaris • Feb 12 '19

Thanks, Ajda! :)

Jesse M. Holmes • Mar 10 '19

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.