For me its just about finding people that have an eye on quality instead quantity. I want to work with devs that are going to try to find ways to improve the code, and not just work on stories. I want thinkers not robots.
I fully agree with you. I'm a picky developer in terms of code quality, and I want to deliver always as best as possible within time frame. This pursue of quality is what motivates me to find new approaches and technologies, listen and learn from people and, at the same time, share my knowledge. I would call that passionate.
I have something clear though: I'm a professional and I appreciate and give a lot of value to my free time. If something I do on my free time casually matches the company interests then good for them, but it's not my main driver.
Yes, you also have to make sure boundaries are respected. In my experience when those boundaries are not respected its usually caused by one or a combination of:
Lack of communication from the developer. Lets say a developer tries to fix things without discussion during a tight deadline. This will result in working beyond normal hours. If a refactor needs to happen but there is no time in the sprint, it should be brought up to the lead / team members and put in the backlog.
Lack of understanding from the manager as to how good software is made. It is best to work with the lead to try to address things. For each sprint, plan for some "fix time" works pretty well.
In short, "passionate" is a small part of what constitutes a good hire. Definitively a good trait to look for though.
In my own personal experience, I think of this as being separate from passion. Some people (and I agree they're the best developers often) simply don't like delivering flawed, unmaintainable code. For me that's separate from someone who is "passionate" in terms of always working super hard.
Well, Jonathan you need to be expicit here. Are you saying that you do ask for "passion" or do not? So, does passion create better code? I guess there is a point to be made on either side. no?
It isn't a requirement, but a good quality for a developer to have. I will favour developers who have this quality the same way I will favour a candidate which is already familiar with part of our tech stack.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For me its just about finding people that have an eye on quality instead quantity. I want to work with devs that are going to try to find ways to improve the code, and not just work on stories. I want thinkers not robots.
You can be competent without being passionate.
Agreed.
I fully agree with you. I'm a picky developer in terms of code quality, and I want to deliver always as best as possible within time frame. This pursue of quality is what motivates me to find new approaches and technologies, listen and learn from people and, at the same time, share my knowledge. I would call that passionate.
I have something clear though: I'm a professional and I appreciate and give a lot of value to my free time. If something I do on my free time casually matches the company interests then good for them, but it's not my main driver.
Yes, you also have to make sure boundaries are respected. In my experience when those boundaries are not respected its usually caused by one or a combination of:
In short, "passionate" is a small part of what constitutes a good hire. Definitively a good trait to look for though.
Interesting point of view!
In my own personal experience, I think of this as being separate from passion. Some people (and I agree they're the best developers often) simply don't like delivering flawed, unmaintainable code. For me that's separate from someone who is "passionate" in terms of always working super hard.
How is it different from passion?
Well, Jonathan you need to be expicit here. Are you saying that you do ask for "passion" or do not? So, does passion create better code? I guess there is a point to be made on either side. no?
It isn't a requirement, but a good quality for a developer to have. I will favour developers who have this quality the same way I will favour a candidate which is already familiar with part of our tech stack.