Personally I am not a big fan of the word "passionate" as the number 1 attribute for employees. I think there are better words like competence, commitment, empathy, independence, maturity, etc.
There was a time some while ago (as I blow mental dust off my college literature studies) when "passion" was not a word that carried wholly positive connotations. It came with implications of things like irrationality, moodiness, strong emotions, even violence.
Passion can be an asset if a person must maintain momentum in the face of hardships and competition. It can be the base for tremendously hard work (which is one reason I think employers like it). But, it could potentially be a liability too, if it drives a person to create conflict or inhibits teamwork. Depends on the role and the team.
Empathy is not part of computer science, but is incredibly important in software engineering. In software engineering, much of the day-to-day work includes things like:
* Discussing and ultimately making decisions
* Learning about how things work from people with a different set of knowledge than you
* Doing things which optimize for the understanding of other people after you, as opposed to optimizing for your own productivity in this second
Software engineers who do these things with low empathy end up contributing to the stereotypes about engineers who are unpleasant to work with because they don't consider other people.
If you mean CS in the academic sense, e.g. algorithm research, probably not much.
If you mean CS as in "occupation that involves designing and/implementing software" then I'd argue empathy is an integral part of being an effective professional. Empathy facillitates effective communication and ethical/moral decisions.
I think the idea that "all that matters is your code" is flawed. It's very short-sighted and narrow minded, and it does nothing but to artificially limit oneself. The world is bigger. You interact with other people and can have either a positive or negative effect on them.
Companies are made out of people. A person writing algorithms in the corner does not create value; in order to create value, they have to work with other people to make decisions, deliver work, help each other, etc.
Some of those other people might not know as much about CS, but might have other skills like design, marketing, management, etc. Empathy is a trait that helps one to appreciate and adapt to these differences constructively.
"Passionate" in programming is shorthand for "cares for quality" AND "will improve on their own". Companies are unwilling or unable to train on the job (because it requires tech mentor resources they dont have /wont spare) so they are looking for people they can drop in and see payout for without further investment (particularly in time).
I think it is a shortsighted strategy, but not one without basis. The supply problem is real.
When hiring managers talk about “passion” what they usually mean is that they want to hire a geek who is willing to work crazy hours because of a love of programming and won’t dare negotiate for higher pay or leave for a job that will pay them more.
Saying that you shouldn't hire people because they're only in it for a paycheck and not passion is just shorthand for I want you to make this your life, but not pay you to make it your life.
Subsequently, what I've seen is that most problems in the field of k-12 education in the states can be tied to this sentiment.
I've heard this distinction before, and I think it's a difference in the base quality of the place. My last three jobs all put "passion" as a major hiring criteria, but all maintained a strong work/life balance (average work week was 40 hours give or take a few, and though crunch times happened more than a few weeks a year was considered a bad thing. I conducted plenty of interviews myself and helped write interview questions so I'm pretty confident in what _we_ meant at least, even if I wasn't a hiring manager.
One of those places, however, did slide after a few years into the nastiness described (I left when the slide started, and it reportedly continued). Another
So while "Passion" CAN mean "we want huge levels of uncompensated work without complaint", that has not been the norm for mean and I think it's a mistake to assume that is what is always meant. Certainly I've been at some great places to work that I'd have avoided if I thought asking for passion was a negative.
You would be surprised about how many founders who post on HN bemoan the fact that they can’t find developers who have passion for the founder’s “vision” and only care about the money.
My usual retort is why should I care about a founder’s vision if I don’t have a substantial amount of equity in the company? They find that highly insulting.
I have zero disagreement here. I have a similar reaction when someplace tries to attract me to the "challenge". Finding hard, interesting work is EASY - I'm looking for interesting work (often but not always hard) that also pays well. ...and it'd be nice to be able to tell people who I work for and what I do without feeling defensive.
Nothing wrong with believing in the product or the company, but there is something wrong with thinking that would be enough. I don't think the entitled executive syndrome you're discussing is really the norm for companies, but yeah, I've encountered it and it's annoying.
Sorry - that was a mostly removed sentence, because it wasn't very interesting: "Another is a new job, so we will have to see how well they sustain it".
You're not entirely wrong, but that's a very bitter interpretation.
A more charitable interpretation of "passion" would be... I'm nominally a Python & Scala programmer (according to my CV), but I can also competently talk about OCaml, Haskell, Rust, instruction scheduling, tracing JIT compiler implementation, propagating type inference, TCP stack, C memory model, register allocation, hardware concurrency primitives and ring 0 privileges.
Compare that to another Python programmer that once tried to convince me that when a C++ program tries to access unallocated memory "the computer just throws an exception".
Honest question, I’m not trying to denigrate anyone who takes an interest in software development for its own sake.
But would you consider someone passionate if they said that they only care about learning a language/technology/framework that is marketable and doesn’t believe in learning for its own sake?
Unless the Python developer is actually writing C++, I don’t think he would ever need to learn the intricacies of C to be a good developer.
But take that opinion with a large grain of salt. I spent 12 years bit twiddling in C/C++, 10 in C#, and have been doing Python for a grand total of 6 months so I definitely haven’t done anything complicated with Python.
Nah obviously not. I just listed what I know. I mean looking at the list you could maybe tell that I'm mostly interested in programming language implementation (I forgot to list all my Linux and Windows sysops skills that I've gained from years of managing said systems).
The end result is, that (1) my knowledge and skills extend way beyond any of my past or present job descriptions, and (2) (this is probably even more important for employers/productivity) that I'm capable of, and curious enough to actually want to, learning quickly/deeply and solving hard problems that might not have an obvious instant-knowledge-based solution.
I think that anyone that has ever had an interest to go "beyond" (in any way) the obvious, or immediately what's necessary in his/her day job, would built such a knowledge base - but could of course be completely unrelated to mine (e.g. networking specialist, cryptography geek, hardware/embedded engineer, ...).
It's a little dangerous to expect companies to train junior employees well when their focus is on making product/revenue. Generally they would prefer solving immediate problems over developing the craft, so over time most training would align with short-term solutions rapidly executed. Perhaps we need to be thinking about building trade schools as a service which can be hired by companies to institute part-time professional development for engineers, especially in junior roles, so that craftsmen be the ones pushing the field forward rather than the business analysts who make use of them.
I'm all for trade schools, but I feel like that's a slightly orthogonal issue.
There's no immediate reason to expect a company to help train up employees (not just juniors, but moving people from every level to the next step)....unless those companies want to improve the outcomes of their staff, want to improve morale, and want to resolve their perpetual difficulty in finding people senior enough for their needs.
Don't do it out of social responsibility, do it for keeping your business functioning long-term. I've worked too many places that have almost exclusively senior devs with more work than they can handle. They focus on hiring MORE senior devs (but don't have much success), meanwhile their senior devs are spending a lot of time doing work that junior devs could accomplish.
There are numerous side-effects too - mentoring (if you like it) can help improve your own skills and outlook. Fresh perspectives are always good, and once someone gets their first few years in, they will occasionally have insights that seniors can learn from. At the best places I've worked the more senior devs have wider perspectives and deeper experience, but the "who is right" between junior and senior becomes more of a statistical model than a certainty.
There are certainly benefits for the company but between predominantly revenue-centric attitudes and a lot of poorly trained "senior" engineers I wouldn't trust the majority of companies (outside of Google, Apple, Netflix, and other great engineering orgs) to do it well. Independent schools dedicated to progressing the craft and tools would benefit more, I think.
