The dispassionate developer
blog.ploeh.dk
blog.ploeh.dk
I wouldn't think of myself as a passionate developer. I have a family, I value my free time. I spend work time growing my skill set as it's required, anything else I do is rarely related.
I have a feeling that there's a silent majority of developers such as myself, that do enjoy programming and have a "passion" for it, but do not let this passion dissuade them from family time, or having more varied down time.
I think for a lot of people it's a dangerous game to be spending every waking moment working for a company, then spending your down time scraping together stuff for open source contributions etc.
I salute those that can and do though.
Every once in a while we see someone with a lot of open source contributions, or even full leadership of a popular project. These people would really prefer if we believed that OSS contributions and GitHub profiles replaced resumes or CVs, because it’s where they shine. Unfortunately, doing so would exclude many great hires who have done a lot of great work at private companies that doesn’t show up on their GitHub. We’ve also had trouble hiring prolific OSS contributors who spent their days working on OSS contributions instead of doing their job. One candidate wanted their contract to state that they could spend half of their paid time working on their OSS project. We passed.
In my experience, anyone claiming to have a single dimension credential preference for hiring (usually GitHub portfolio, Ivy League education, ex-FAANG) is simply hiring for people who look like themselves. They’re not a good fit for unbiased hiring.
I say "often" because OSS contributions can still be an indicator of something, but it's not really clear what. Maybe it indicates drive to contribute to OSS, maybe technical ability, maybe no hobbies or commitments outside their day job. In our experience it's often the latter, but even so, it's biased against people who don't have the time to contribute even if they desired to do so.
So we typically just stick with the resume for actual experience and college coursework, if any, but not the college itself. Using these heuristics we've managed to build a pretty strong pipeline of people with all backgrounds of education or experience.
When I was single I had a lot of free time to tinker and go through coding tests, etc, etc, and cater to whatever hiring shenanigans were in place.
First marriage, then a kid, and I find myself grabbing my laptop after work maybe once a fortnight. I'm always "open for new challenges" and I regularly apply to positions in interesting (to me) projects, but more often than not, at some point in their process they gimme some "take home assignments" that are a literal week of unpaid work. I've heard of companies that pay for those assignments, but I've never stumbled upon one.
I always drop out of that, thinking, "good luck with that particular choice of candidate sampling". I might not have been the best candidate, but most seniors I talk to are turned off by these things as well.
Timed coding tests are fine, up to 2-3h, I can squeeze one of those in most weeks. But, and I'm not making it up, "implement this subset of the MQTT spec in your language of choice" as just a step in the hiring process? Hell nah.
The biggest killers to my open source contributions are general life soul sucking killers. For me the worst is long driving commutes to an office. I can feel my soul bleeding away.
It is the norm in my line of work. I mean in my other line of work that isn't a software development.
I like programming as hobby so I choose to program outside of work. By no means is that sentiment meant to suggest any form of hostility. There isn’t even any competition implied.
I'm pretty lucky in that my wife is a stay at home mom. My sister in law has a dual income family. They basically never see eachother, because one has to work during the day during the week, and the other works nights and all weekend. They're lucky one of their jobs is so flexible.
If you are into open source you can spend 2 hours per night. Where you put that two hours is up to you, but you need to break for a scheduled meal. A scheduled meal ensures better nutrition and mental health plus some dedicated family time. This mean you program open source from 4-6pm or 8-10pm. Which ever you choose the other is dedicated time with the kids or chores around the house. Then you can spend about an hour before bed watching a show with your spouse.
You still need time to exercise and I find it’s better to do that in the morning with less mental fatigue so I will wake at about 5am.
When you need to participate in a side job that is structured time dedicated in a scheduled way, one or two weekends a month and occasional emails and a rare phone conference during the week in the evening.
What I discovered was that they'd be willing to make me work 5+ hours on their assignment but wouldn't spend 5 minutes reading my code.
Though it wasn't my intention it inadvertently gave me a quick and easy way to filter companies which actively disrespect candidates' time.
Ignoring it completely also sends a signal to the candidate. IME this red flag is usually paired with 5 or 6 other red flags.
Maybe we're just really bad at interviews? It probably doesn't help that management here is almost entirely non-technical. There's usually a developer or two sitting in on the interview to try and balance it out, but I don't think any of us would consider ourselves particularly good at interviewing people.
These are mutually exclusive things. Candidates who have more free time to code are more likely to be better at it than those who don't (all else equal). Candidates who have OSS maintenance / leadership experience are more likely to work well in teams (all else equal).
If you choose not to weight those things, to balance the playing field for people who have more obligations outside of work, then you'll also have lesser quality candidates (again, generally).
So if you're struggling to hire good candidates, maybe it's a good idea to weight these things (and bias against people with less free time outside work). Once you have good candidates, and this is no longer a pressure on your business, then it might be a good time to try and balance the playing field for new hires.
But you cannot balance the playing field and also hire the best candidates. The best candidates will have unfair advantages in general. You can either lean towards having the best or lean towards balancing the playing field.
Some of the gymnastics thinking that I see seems to suggest that we’d seek to hire fluent English speakers by interviewing evenly across all populations. By all means, I’d be more than happy to hire someone fluent in English from China, but if I’m looking for a fluent English speaker, I shouldn’t spent 18.5% of my recruiting efforts/budget in China out of "fairness".
People who don't contribute to OSS typically don't do it because they don't have the ability (some OSS code is held together by duct tape) but because they don't have time, interest or think it's harder than it is.
If you have better tools to determine if someone is good at writing code for your company, why use a proxy measure that's different in many ways?
It’s rare for an interview process to provide more than 6 hours of content, some of which is non-evaluatable. Reference checks are all but useless compared to seeing actual work over time.
About 1 time in 6, you’ll interview a full standard deviation above or below your “true” ability. About 1 time in 50, you’ll turn in a +2σ (or -2σ) performance. That’s largely eliminated with personal experience, a trusted vouch, or a strong OSS portfolio.
Unpopular opinion on HN: This is actually quite common when you hire based purely on resumes or credentials. Some people are really good at interviewing and being charismatic enough to convince people to hire them. There are a lot of candidates who can talk the talk but really just want a job where they can browse Reddit and Twitter all day while writing a couple lines of code every once in a while. There are a lot of companies that are big enough for these people to blend in for years.
Take home tests in the range of 1-4 hours shouldn’t be an undue burden on any applicants, if you give sufficient time to return the test. Many candidates wouldn’t bat an eye at taking a day to interview on site, so asking them to spend a couple hours of their free time on an interview isn’t really a disproportionate ask.
Giving someone a 20-40 hour take home project would be ridiculous, of course, but reasonably sized problems are perfectly reasonable.
As I said it's not very hard but you can get bonus points if you come up with considerations for responsive design or stuff like that. Overall the aim is to create readable idiomatic code and not come up with something clever that no one but you can understand.
I guess that's a very specific task that's of no great use to others but the point is to have a specific problem with some blanks that can be filled out with a reasonable amount of work by the candidates. Plus the general workflow using git and such.
As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes and largely biasing against experienced devs who aren’t as likely to waste their time. And worse with a take home, is that they have no skin in the game. With an in person interview they lose at least as long as the inverview. With a take home they lose nothing except short email exchanges.
If you’re constantly worried about “traps” then you might not want to work for those companies anyway. Take homes should be straightforward and similar to solving real problems.
> As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes
Take homes are contrived problems, not real work. Every candidate receives the same problem so they can be compared.
No company should be giving employees actual unpaid work to do as part of the interview. That’s more of an internet trope than a real problem because no rational company is going to be sending their codebase to applicants to add features to.
The biggest issue I see are people underestimating the setup time for "simple" projects. You're a big software company that doesn't start new projects regularly, I'm a developer at a big company that doesn't setup new projects regularly, why do you expect me to remember how to setup "professional quality" projects in a couple of hours?
A simple console app might test if I can code, setting up a new MVC project with authentication, unit tests, IoC, etc is testing how well I can google shit I haven't had to setup for years.
Totally agreed. Traditional interview processes select for people who are good talkers. That doesn't correlate well with technical skill: you over-hire glib people and under-hire people who aren't. E.g., the shy, awkward, and anxiety-prone.
When I run an interview process, I focus on making it as much like real work as possible. Some pair programming, some technical discussion, some joint product collaboration and systems design. It's my firm belief that if we want to know if people can do a thing, we should try doing the thing with them. It's not perfect, but it's way better than asking people about their 10-year career plan or having them solve Mensa puzzles.
This is true: but "technical skill" is not the ONLY hiring criteria that should be considered. (I say this as a fairly shy, awkward and anxiety-prone person, who has had his share of interviews-gone-wrong).
I'd posit that you DO want to hire people who are good talkers, and are glib. They help build teams. They help with information flow. The greatest ideas in the world are worthless if they can't be executed by a team that doesn't understand them, and the person who came up with it can't communicate that idea effectively. One might say that that is what code is for. But that's not true. If code were to communicate between the developer and the machine, we'd all be writing in machine language. Code is a communication tool for developers to collaboratively tell the machine what to do. And that has to be supplemented by human, interpersonal skills. (especially when you have collaborators who are not coders, like business and finance people who organize the teams and manage projects and programs).
I like that you focus on pair programming. One horribly toxic factor I see at way too many places is where management pits programmers against each other like it's some kind of competitive sport, and collaboration is frowned upon because "if you can't figure it out by yourself, you're a burden on the rest of us".
Basically, I think workaday collaboration and communication is a pretty different skill than on-the-spot glibness. If I'm hiring a PR person or a press secretary, glibness is a valuable skill, because an important part of their job is to talk over people, to favor sounding good over consideration or substance. But for a software team, I value more substantial engagement and communication. So no, I'm happy to hire people who are not glib. Have done before, will do again. And for those who do happen to have the gift of gab, I want to be sure they have it in check and only deploy it when necessary. A colleague who can say, "I don't know" is way better than one who glibly avoids that out of pride.
An interesting interview question could be to study the job applicant's background and then ask questions that, given the background, s/he doesn't know -- then, will s/he tell you this, or make up nonsense
What's the compensation like? Stock?
> For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations
You'll also find out that the people you really want to hire are not on the market for a long time. So if they are interviewing at several places and you give them a 4 hours take-home, they'll put it on their to-do list but by the time they get to it they might be in the final rounds at 2-3 other places that brought them on-site immediately.
> It probably doesn't help that management here is almost entirely non-technical
That's a much bigger issue than most assume.
> There's usually a developer or two sitting in on the interview to try and balance it out
That's a huge no from me. Final approval of a technical candidate should only be in the hands of the technical staff.
I've heard horror story of a "senior" engineer from "his country's top school" being interviewed for a technical position by several non-technical managers and HR reps. They only included an engineer in the final round, which was basically supposed to be rubberstamped anyways. He was then asked to implement something trivial like fizzbuzz or wordcount on the whiteboard. The candidate then became extremely defensive and tried to argue that such task was "beneath him", arguing for a good 15 minutes why he shouldn't have to do it.
Then the dev just left the room and said that he used this question as a warmup with new hires and it typically takes them less than 10 minutes.
"Ok this problem is called fizzbuzz. We just need to see if you can really code."
It sounds like the situation was of course different, but situations like above have happened.
I laughed and wrote the solution on the board.
There is absolutely nothing wrong with coding test. Timed with internet. The one that does not tests for algorithms, but for basic competency. For example, ask them to parse some data out of xml file and give them tons of time. That will check competency without being burden.
Yes, non tech managera sux at recognizing who is good programmer in discusion. But, so do programmers and technical people. It is easy to pretend competence if you read enough blogs and can project right attitudes.
This seems to be the issue, in fact it's quite baffling to me. If you are interviewing for a technical role, why would you not perform a technical interview led by technical staff?
I'm not saying the other stuff is not important as well, but this reads to me like you are essentially leaving the core of the role out of the interview (I'm not sure what "usually a developer or two are sitting in as well" means).
1. Write code that takes in a rectangle, coordinate, and distance, and tells if that coordinate is within the distance of the rectangle.
2. Determine whether a string has permutations which are palindromes. (I'm of the opinion this one is too simple, but it's been fascinating seeing what mental gymnastics some developers will go through to solve this problem)
3. Write a CLI dice game (we provide the rules) in which the computer player wins 70% of the time. Make the method by which the computer cheats undetectable (of course this is impossible, but candidates just give it a best shot and we talk about their approach in the interview).
Assuming the test passes muster, we have three interviews right now, I think. One with managers to talk about the role, one with senior devs outside the team to perform the technical interview, and one with the devs in the team to talk shop.
In the technical interview, we primarily go through their test solutions (we do no whiteboard coding aside from reviewing the test and even that's very loose - not actual code). We have hired candidates before who have failed some of these tasks (mainly our candidates have trouble with #1) but who showed a capacity for being able to think on their feet and correct their mistakes during the interview. Of course a candidate who aces the test is going to have an advantage, but absent having the right answers, quick thinking/adaptability is probably the #2 trait we look for that seems to be a good predictor for developer success.
Every candidate we've hired through our process has been a success (which could be dumb luck, since none of us are super experienced/knowledgeable interviewers either, but we wing it best we can) and the take-home (and, equally importantly, the technical interview) has absolutely helped us weed out candidates with impressive CVs whose test results did not measure up.
If I understand this correctly, it's the sort of problem that's simple if you see the trick and hard if you don't. I'd expect many candidates to think that you actually want them to generate all the permutations and then get bogged down in recursion.
#1 is good, and #3 sounds interesting.
Ideally the candidate should realize that this is computationally infeasible and quickly come up with a much more efficient solution, right? Perhaps they believe that this question filters out people who 1) don't have a feel for what is computationally feasible 2) will just dive into coding without spending 10 seconds to see if there's a significant optimization.
Distance from the center of the rectangle? Easy. From the closest corner? Easy. From the closest point on the rectangle? I'm not clear how to do this.
And will the sides of the rectangle be parallel to the x and y axes?
It's easiest to think about an axis-aligned rectangle, and you can convert any problem to have an axis-aligned rectangle by rotating everything.
Quite a few pitfalls there, though. If I was doing computer graphics often, the geometry wouldn't be a problem I guess. But I've not done any such thing in decades.
If the job needs the geometry, then it might be a useful question to ask.
There were three "rounds":
1. Phone screen with actual lead developer. There were some quiz-y questions here, which I'd previously thought of as a silly outdated approach, but it honestly was a low stress filter for basic technical knowledge.
2. 90 minute pairing exercise with the same lead developer. We built a small example app together. Resources were sent over ahead of time so my environment was good to go, and the expectation was set from the start that the goal was to assess how I thought and approached code, not to see how far I could get in 90 minutes.
3. 4 hour "on site" where I talked to each developer on the team I'd be joining. No technical exercises. Each person came with their own questions, and expected me to ask mine.
What I took away from the experience was that companies are seriously overthinking and over-engineering the process. There isn't a magic heuristic you're going to discover that will identify "10x engineers." You can vet if someone is technically competent enough for the role, approaches software in a way that gels with your org, and if they have any red flags in fairly straightforward fashion that doesn't require enormous amounts of prep for them or your team.
We use this process at my current employer, and we've gotten mostly good feedback about it (including from people we didn't hire), though some candidates don't like it. The people we've hired using this process have been quite good, though I can't say if that's the process or something else that leads to that outcome.
Don’t penalize people for not having OSS contributions, of course, but it doesn’t make sense to ignore them. Whatever credentials the candidate brings to the table should be taken into consideration.
Not everyone has the opportunity to go to colleges or get a first job at a well-known company. If someone chooses to prove themselves via OSS contributions, let them.
It's a fairly clear signal of skill quality and attitude.
Reading open source commits/PRs and issue trackers tells you quite a lot about a developer which you can't see without some sort of a test (often not even then).
>it's biased against people who don't have the time
Surely any career that requires a high level of skill and practice honing that skill is biased against people who don't have the time?
What's special about open source?
Now of course this doesn’t matter past a certain point — people could spend all their time working on something that doesn’t help them grow.
Then once you have those 10,000 hours of actual growth, you are probably close to a Senior developer level. Which after 5 years in an office job working 40 hour weeks, you’re there anyways.
But at the earlier levels of developers, it seems that working on projects outside of work would definitely help you improve faster!
Except that 10000 hours thing is non scientific nonsense.
To improve, you have to practice right way. If you code for 8 hours at work, coding 2 further hours wont make you improve more. Similarly, if you want to improve in music or running, just playing songs or jogging means you will hit plateau pretty fast. After that, you have to train on correct selection of exercises.
At that point reading some theory will have much bigger impact, because yoi are doing something new. And even exercising will likely make you improve more due to what it does to body then further 2 hours of the same.
A) I'm pretty sure almost nobody actually codes 8 hours at work.
B) Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.
The non-coding parts of work are necessary on oss projects too. In any case, programmers work being mostly coding + code review is pretty normal.
> Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.
That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software, it will be more of the same after a while.
IME a far greater % is coding. There's also a lot of OSS people involved who don't code who help out with the other stuff.
Moreover, a lot of the stuff that "isn't coding" is a strong quality signal - how the developer interacts with bug reports for instance.
>That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software.
It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.
It was not my experience. In work, the proportion of coding was bigger then when I maintained open source one. Mostly because company paid people to do other stuff. In OSS, afaik, it is was more of rare to have dedicated tester or to get already analyzed input. Also, the planning, organization, documentation, keeping tickets clean, decision making and so on are all on you. The ratio of project work is the same.
> It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.
Maybe yes, maybe not. And after a while of maintaining the same software, you already maxed out what you learned. Moreover, you can learn new stuff without having side project. It has advantages, because then you dont have to finish and polish stuff. You just learn or try what interests you.
Lastly, side project is really not that dissimilar then working on the job - meaning job+side amounts to 10 hours a day work basically. It means your hourly effectivity will go down exactly like all studies on crunch predicts. You will get tired and slow.
I'm sure a lot of people who hire developers think of themselves as people who could write open source but don't have the time.
This also accounts for why stuff like leetcode persists (the hirers were successfully selected by that process), why top colleges are often preferred and even why the profession is predominantly white/male.
Any career, especially in our field, requires a high level of skill. We try our best to level the playing field for everyone while still getting a lot of signal in the interview process so end up eschewing things like school attended, talks given, OSS contributions in evaluating candidates. Anecdotally we've seen little correlation with these sorts of things and interview ability or ability at the job after being hired.
And even more have the potential to become excellent coders but didn't have the bandwidth to develop it.
It seems peculiar to single out one quality in particular that sends a clear signal that a skill has been honed on the basis that it took time to hone that skill.
All skills take time to develop.
Besides, having a diverse experience base and pipeline (parents, non traditional developers, non traditional paths to SWE, and even single people with a ton of time and fortune to be able to do things like robust side projects) has served us particularly well in having a team with a wide breadth and depth of experience and viewpoints. Specifically weighting side projects in lieu of technical/EQ interview performance would ruin that in favor of the latter group.
Nobody said that we did.
This is about ignoring OSS contributions vs. reading them taking them into account - i.e. deliberately ignoring a signal of quality because it might, for instance, discriminate against people who chose to have kids.
I find it particularly ironic coz part of the reason I wrote open source was to save time - to skip wasteful technical interviews that it ought to be obvious are unnecessary if I have public evidence I can code well.
To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source. (Maybe if I had worked side by side with the person in a previous life would be weighted) Even if we did use that as a proxy, it doesn't really save time because people would have to inspect the work and still doesn't really tell me anything about the candidates approach to problem solving or framing of issues that I can get from pair programming or walking through some code for an hour.
I applaud all your open source contributions and appreciate them, but I wouldn't consider them in whether to hire you except perhaps at the margins. Others may disagree and that's their conscious choice or they're indexing on something different.
I did suspect that underlying your opinion was a desire to discriminate in favor of parents/against non parents.
This would fit in with the double standard I highlighted in my first comment.
This was also because you mentioned "parents" in the context of diversity (which is weirdly unique). I threw that phrase out there to see if it triggered you.
>To your second point, I can't think of a single thing I would let be a proxy for technical skill in an interview process -- certainly not some commits to open source
I've not worked with a huge number of developers who have made > 3 significant pull requests to a serious OSS project but every single one has been stellar.
I've worked with a lot of developers who can do the cracking the coding interview dance who sucked and even more who interview well in other ways.
A full time job and small children for example don't leave much space for extended coding sessions on side projects, unless you're lucky enough to need little sleep.
I've worked around this by learning at my day job : read books/papers at home (this is relaxing), and look for opportunities to apply this knowledge at the office. Unfortunately, it stays at the office though, and can't be shown as proof of your skills outside of the company.
This is just another single dimension hiring credential, that will result in limiting your hiring pool to people like yourself. My code ran on 70+ million machines last month, but I've come to decline any timed or proctored technical interviews.
It's not that I'm too good for whiteboarding or timed tests, or that my options are so open that there isn't significant cost in doing so - quite the opposite: I'm come to find the process so traumatic that going through with it isn't worth it for anyone involved: those jobs just aren't open to people like me.
I think we'll agree that there has to be _some_ interview process. iirc node's Left Pad package is downloaded like 20M/mo.
There's obviously a fundamental necessity to evaluate a candidate's technical skills directly, rather than relying on credentials - my issue is with the false expedience and conflationism of timed and artificially performative technical evaluations, and my personal difficulties with the social requirements inherent to them.
Or their company ships a product that has a huge dependency on that particular OSS project, so they are doing the work on company time.
Not saying your strategy is bad, just that you might miss some good candidates.
Do you mean it's rare to see someone hired, or rare to see someone in the hiring process?
Because if it's the latter, that's exactly what I'd expect too. People with very significant and visible portfolios aren't sending their resumes because they don't have to.
There are plenty of amazing developers that don't to open source and are great employees.
Other devs have extensive open source code. It doesn't make sense to give popular open source devs coding tests. Open their GitHub account, see their popular repos, see how they communicate on issues, etc.
The most powerful teams I've worked on have a mix on OSS devs and folks that only do closed source work. Hiring both is the best from what I've seen.
I like the dudes honesty. He would not be doing OSS while pretending he is working for you. He is also leaving himself time for other things.
It seems to me like fair way of doing things. Company like yours passes and maybe another one will take it.
Because these people rarely apply for a posted job opening.
It probably is a better way for graduates to differentiate themselves than experienced engineers.
Just do things like implement a heap or boyer-moore in pseudocode or python on pen and paper without referring to google.
Still clock out at 5, though, and you can be sure I'm not going to put work Slack on my personal phone. My time is my time.
That said, I do think some sort of "passion" is really useful. I've been coding a long time. I'm on something like my fifth major language. My first computer had 4K of RAM; now my phone has a million times that. I can't even count the number of business domains I've had to learn. I can't imagine people keeping up with the pace of change in our field without finding ways to love the work.
In contrast, I've worked with people who learned enough to be employable and then just kinda stopped. I remember one guy, a great manager, who kept giving technical advice based on his Vax BASIC experience at least a decade past the point it was sensible to do so. Or programmers who had basically become fused with legacy systems, only employable until the old code was replaced. It's not impossible to make a career of out that, but it's risky.
Especially given the release cadence of modern frameworks and tools, I think continuous learning is vital. And I think keeping up (or better, keeping up and getting ahead) is much easier to do if people really enjoy the hour-to-hour details of the work.
Though it's hard to get a full picture. Maybe past gigs or other circumstances have given them enough financial stability that they don't strictly need to work anymore. They then continue consulting out of passion for their particular niche, or somewhat opposite because they don't have any drive to learn anything else, but still don't want to retire completely. I feel like the people I have in mind there seem to be in a more good than bad situation.
But I've also encountered the other category you're hinting at, people who are fused to a legacy system (i.e. a particular project at a particular company), not a technology in general. A few friends of mine do that, and they are much younger and much further away from feasible retirement than the aforementioned "gray beards". I sometimes do wonder about their prospects, but, again, no full insight.
And yeah, I too worry about people who do that early on. Some things will probably last. E.g., I'd bet that Salesforce admins will still be employed 30 years from now. But the odds are not as good for most technologies in use today.
I agree that people shouldn't fake qualities. But neither do I think everybody will be equally good at every job. E.g., I can do sales, but I just don't like it. I'll just never be as good at it as somebody who really enjoys the work.
Thank goodness. I didn't spend all these years working for it to be ignored in favour of a few hours a month patching people's shit for free. My work experience is also 9-5 week after week of solving real business problems, which can be messy and requires pragmatism. Just working on OSS doesn't prepare you for work, it's a great start, but OSS projects are often very clinical, perfectionist and academic. Work has messy business requirements, legacy code and the need to deliver good work in a timely manner.
If I had to start as a new developer again, I would still just do pet projects, not OSS. You can be very targeted in your demonstration of skill with a pet project intended to get you a job.
Clearly you've never met devs that have no passion. They will actively refuse to learn new things and have absolutely no interest in doing so.
If you look at other professions, growing skills and staying up do date is supposed to be done during working hours and is budgeted for. A lot of 10x I've met were parents and had a pretty strict schedule. Whatever time they had in the office was 100% dedicated to shipping results or growing and they had to be efficient at it because there was no way they would spend less time with their families.
We just don't have that in the software industry, at least not portfolios that we can legally share or that other employers would trust, so we end up essentially torturing each other with coding tests.
I don't think everyone having a portfolio of open source code is a reasonable ask, but the idea of portfolios, if we could create them, would bring some sanity to our industry's interview practices.
I think you're absolutely right. For me (he said, ironically, whilst responding to a post on Hacker News) it's just not that healthy to spend even more time sat in front of a computer programming away than I did at work.
As it happens nowadays I don't spend that much time at work programming so this does tend to make me more inclined to do so outside of work. But everything has to be in balance: I have family, I have friends, I have other interests. I need to spend time with family, with friends, and pursuing those other interests, otherwise I start to go nuts.
So no: I do not have a plethora of OSS contributions, nor will I ever have. My side projects aren't OSS and, at present, I have no intent to make them OSS. I'd need a motivation that I simply don't have in order to do that. Moreover my side projects are things that I find fun, that probably aren't very generally applicable, and that some would see as frivolous - but I deal with enough serious business at work.
In any case the thought of entitled internet randos getting in touch to demand free support because I've written an OSS library, module, or tool that's accidentally become somewhat popular and is now included in other modules and is used by corporations around the world who make tons of money in some tiny part off the back of using it is deeply unappealing.
Not that if you want to spend your free time on OSS there's anything wrong with it - far from it. If you love doing it then have at it and more power to you. But we need to dispense with the idea that this is for everyone any more than photography or collecting vinyl is for everyone.
I'm not sure what exactly he means by passionate, but I do know a surgeon who spends time reading and lecturing about the history of surgery. I'm sure there are judges who take pride in understanding more than just how to do their current jobs too. And for a fact you will run into engineers, both the traditional and software kinds, who care to get some context related to their professions. I also spent a fair bit of time when I got a trading job reading up on how the market had evolved. Does that qualify as passion?
Now, there's of course a difference between demonstrating that you care about the larger context of your work, and doing work for free. I think the only place where we associate passion with no money tends to be the arts, the common trope being that person who acts or paints but needs a job to pay the bills. Then clearly they aren't doing it for the money.
But of course you can do something for money while also caring deeply about it.
Overall he's right though, you should never let someone talk you into a position where you need to demonstrate that you want to work for free. If you are in the village play because you like it, and that play somehow ends up on Netflix and makes a gazillion dollars, you should get a sensible piece of it. Likewise if someone is proposing you help with some software that might end up being worth a lot, you should get a piece.
Nobody wants an engineer who is passionate while they are literally writing code, screaming at the computer and flailing his hands[1]. Much in the same way we wouldn't want a judge to be passionate when he's handing down a sentence.
But a judge should care about our laws, our constitution, and be opinionated about them. I want a surgeon who understands how the practice of surgery is evolving and stays up to date on best practices. I want a bridge builder to get ABSOLUTELY passionate about the type of materials used on a bridge and not settle for anything less. Similarly I think the best software engineers care deeply and are knowledgable about the craft of software engnineering.
[1] Well, I've had a coworker who did this and it was actually really comical and we were all entertained, but he was the exception that proved the rule.
As my career has gone on longer and I've overcame the algorithm bias, my OSS contributions mostly dissipated. I do continue to work on side projects to learn but I continually encourage businesses to promote learning during work time. Bringing back read only Friday is a great way to do this and generally maintain velocity.
I don't have any data for you, just my experiences.
Can't any school teach the same algorithms material? It's not exactly secret. Algorithms interviews seem more like surreptitious IQ tests than anything else.
Whiteboard tests aren't inherently bad, but the sorts of algorithm questions that are asked at some interviews are absurd and do practically nothing to determine whether the candidate would be a good employee. 95% of being a programmer is plumbing data together, and it's pretty rare that there is a need to develop more complex algorithms for things - as long as someone knows the concepts of time and space complexity and isn't going to make huge O(n!) operations, it's much more important IMO to be interviewing for communication skills, system architecture, network, and security knowledge.
There's obviously exceptions to this if you're hiring for a role that specifically is writing very algorithmic code to solve a hard science or graphics problem but that's very much the edge case and even if it is the case, domain knowledge will be more important.
I almost feel like that for-profit companies of a certain scale should be charged a reasonable licence to use OSS software and that money should be re-distributed. I know there is GitHub Sponsorships but now that MS runs that, well, there went that. Large companies are parasites that have zombified OSS with cute "X <3s OSS" icons and marketing.
Beyond that, the bit on passion being a weakness is incredibly important. I have been mulling that over the last few years in America. Extreme political movements tend to cater to a popular passion that they can then bend to their will (such as religion) that they then try to tie their movement to it. (E.g. "You are not a [religion/passion here] if you support [political opponent here]", even when the usurper's agenda is not clearly aligned to the religion.)
Virtually every tech startup or company makes use of open source at every level. We all benefit.
There’s no need to be cynical because big companies are also benefiting.
They do benefit immensely, but no by having "others fix and build" their own repos. You're overestimating the source code contributions and underestimating the cost to manage a hugely popular project.
> The Gameplan is to gain from the community, not contribute.
This is just silly. The """gameplan""" is to contribute and AND grow a community, which benefits everyone. Does it benefit more the company than the community as a whole? Maybe, but that's petty reasoning.
Even many companies who do eventually release parts of their secret sauce (e.g. Google, Facebook) first secure their financial and tech positions before they do so. In other words, when they do release their secret sauce, the good will they get far outweighs the risk of a competitor improving on top of their secret sauce and getting a significant chunk of their market.
Which is completely understandable? I can't see how things would be different and I'm still pretty satisfied with the outcome of releasing "the secret sauce" after it is a bit more stable instead of going through a turbulent development (looking at you, Angular).
Though the main problem is in companies expecting too much from their employees (see: "looking for starter with 5 years of experience in framework X Y Z, language A B C and preferably knows devops front to back"), it is somewhat naïve to expect a passive force can only be beneficial to everyone while the majority power is still in hands of employers and employees are too decentralized and unorganized to fight it.
It's in much the same way if I were recruiting for an auto mechanic for a repair shop, a body shop, or a race team: someone who had their own custom car is probably a better bet for me than someone who is otherwise identical on paper but drives a stock Toyota Camry. I'll absolutely hire the qualified driver of the Camry, but I'll prefer the driver of the '65 Candy Apple Red Mustang that they restored and painted in their garage.
On several occasions, I've found a bug and suggested that I spend time going to the framework source or whatever to fix it. I have never been allowed to do it, we've always just worked around it. There has been no concept of giving back.
I suppose Facebook et al are probably better in that respect.
The world for sure didn't need Go, yet we got it, and it's gaining mindshare versus stuff like C/C++/Python/Perl/PHP/Ruby/OCaml/... (I'm not including Java and C# as those are also enterprise languages).
Angular, React, same story.
Sometimes it's good, but with stuff like Dart you can definitely feel thatsome Googlers are bored and desperately want to own their language instead of contributing to a pre-existing language.
Reason vs OCaml, etc. there are a ton of examples.
Basically big companies can afford to throw a ton of money into their own open source projects, basically depriving true community open source projects of the attention/oxygen they need.
There are pluses and minuses to this... But we should definitely start pushing back when the open source project is a clear open source "land grab" (for example to me Dart definitely falls into this category).
I'm not sure you can put Spring in the same category with Angular, plus Spring definitely filled (fills?) a niche that's useful: pre-built components for Java, especially for enterprise development.
Practically, these are not in free time weekend projects. Tech people are really invested in mythology of it all being done for free or mythology of everyone having side project on top of work. Neither is reality.
People are starting to realize this, but to understand it it's important to disambiguate "free" and "open source" software.
See https://www.boringcactus.com/2020/08/13/post-open-source.htm... for one perspective.
I think looking at other corporate run project (VSCode, Kubernetes etc.) will tell a similar story: the vast majority of the code will be written by the employees of the company owning the project in the first place.
You could argue that companies are getting free bug reports, but users are probably reporting bugs because they find value in the tool, and would like it to be better, so it's hardly parasitic there either.
The author also claims that employers don't invest in training and expect us to do it on our own time. Every employer I've had has been thrilled when I used my paid hours to study and master technology relevant to the job. Although it's true that I've never really had much formal "training", no one ever told me to stop learning stuff and just do my job.
I'm sure I've been very fortunate, but I'm curious why my experience differs so much from the author's.
Likewise, unless I just stop doing my job and flat out refuse to do my tasks I never had issues with learning new technologies on the job. If anything I got congratulated for showing initiative in exploring ways to better our current stack.
I've seen what he mentions in regards to self-improvement. Management under a large engineering company I was previously at would encourage self-learning and improvement, but disregarded it the moment deadlines became a concern or if you requested resources for it (e.g budget for tech conferences). They had a lot of long-time employees who were content with mediocre salaries (due to family, complacency, poor marketability/atrophied skills, etc.), so they literally had no incentive to invest in meaningful training for employees.
In regards to the focus on open-source contributions that he claims, I've found that the credibility and clout that comes with being a prolific contributor really only matter online. It most definitely helps you get your resume in the door, but you're still expected to whiteboard some bullshit like everyone else when it comes to interviews. I'd imagine that the majority of applicants have zero open source contributions and that the companies not only expect but are also okay with that. That was the definitely the experience I had back when I had did interviewing for my team at least.
Of course, it could be possible that what he's describing is more of a trend going on in Europe or Denmark than the US. But I think he has some hits and some misses with his takes.
"Passionate" has nothing to do with taking satisfaction in performing an interesting job well and being fairly compensated for your efforts and having some appreciation for the opportunities you are given.
It has everything to do with feeling such strong emotions about something that you make decisions guided by emotion rather than logic.
Although I suspect the never ending abuse of the word will eventually change the meaning to actually mean "moderately enthusiastic about and interested in".
Sort of like how in English "awesome" has been degraded from "that inspires both fear and wonder that I do not normally experience" to "that pleases me somewhat".
I am passionate about software development - I enjoy it and while I have experienced burnout before, its never been from software development, only from all of the other things that have to do with business. I want to hire passionate developers not because they are "easier to exploit" but because passion helps you be better at what you do - if you can program for hours and not feel burnt out because you enjoy it, youre likley to program a lot and gain a lot of technical expertise. Passionate people are more likley to be happy with their jobs, and happiness can be contageious - it contributes to a positive office environment. I dont expect anyone to ever work more than 40 hours a week regardless of passion - in fact I discourage it, and even encourage working less than that if you can still get things done doing so. Passionate people don't get "rewarded with a pat on the back" as the writer claims - they get rewarded by having done something they enjoyed and being happy. Huge difference.
It sounds like this person isn't passionate, and is trying to make up for it by mischaracterizing passionate people and attacking them. This seems dumb, jelous, and mean. I agree that passion shouldnt be a requirement to be employed in a field - after all, lots of people arent passionate about anything and still have to make money. Fortunatley, from fist hand experience, it is obviously not neccisary to be passionate about software to have a career in it. We already live in the world this person wants. I agree that this is how it should be. I dont see the point of trying to go after people who value passion or try to form work groups where thats a sought after trait, them doing so doesnt make things worse for anyone else.
Speaking from personal experience....
Recovery is easier/faster than in the non-passion case, but it still happens.
As to being dispassionate, when I take such an approach, even to the passionate thing, I have greater endurance and tolerance for moments of frustration.
Seems to me that protects from overdoing it too.
My point is more that there really are people who contribute to OSS and whatnot for no reason other than that they felt good doing so. I think this is a behavior to be encouraged and celebrated. I agree with the author's point that we shouldnt encourage extra suffering-inducing work for the sake of it, but disagree with his take that all acts of extra-curricular work cause suffering in those that do it.
It also has a romantic sense to it, for example you are passionately in love if you suffer for that love and would sacrifice yourself for it. You are passionate about something if you're willing to die for it. That is, your feelings about something are so intense that you are willing to endure suffering and pain for it. A programmer is passionate if they devote themselves to it to the point that they end up sacrificing other parts of their life in the process.
I am passionate about programming in that sense, for better or worse, and have knowingly sacrificed a great deal in pursuit of this skill and have lost out in many other areas of my life because of it. I am not ashamed to admit it anymore than a Medical Doctor is ashamed to admit that they must also sacrifice a great deal of their life to pursue their career path, doctors are also passionate about their career.
It would be hard to claim that you are passionate about something without admitting to sacrificing or risking something in pursuit of that passion or feeling pain about it such as burning out or struggling to the point of feeling exhausted, even depressed in some cases. It does not mean doing something out of fun or joy or leisure, it means doing something in spite of the pain often because you believe in it so strongly that you put aside feelings of joy.
That said, there are certainly very competent developers who are incredibly productive and aren't passionate about it, and as you said it may even be the case that people who do programming for fun end up being productive because it's fun for them and that helps keep them motivated. That's amazing and I admire such people... but that's not being passionate in its most common usage, passion kind of has a fairly common meaning and the author is using it appropriately.
This is what bothers me the most. Whether it's about tests or something else. Even clean slate "let's get everything right this time" projects degenerate into legacy code within weeks with this mindset. The "It's more important to deliver value to the customer" line is especially insulting, since it's not as if the developers are trying to sabotage the delivery of value by writing tests or sanitising input or whatever the conflict is about. We know that high quality code is faster and cheaper to build than low quality software, but it's counter-intuitive to most managers.
And you need sympathetic managers to get the software right. Business rules are rarely clear, orthogonal or consistent. Which is not actually a problem for humans, but until we have artificial general intelligence, it is an insurmountable one for computers. But unsympathetic managers will not want to have long, uncomfortable conversations about deducing what they actually need from what they think they want. So developers are instead forced turn messy rules into messy code as best as they can, and put out fires whenever they break out, which they will all the time.
And perhaps the most insidious thing of all, spending all the time putting out fires means they don't get real world experience they need to build a robust system on time. If managers let them try once it would just make them look incompetent. And if they quit, their experience putting out fires will be worth nothing to companies who actually value proper workmanship. Their only option would be to join another death march company.
I think this the biggest reason why most software, especially enterprise software, is so bad, and isn't likely to improve in the foreseeable future.
A dev who's also focused on "how can I deliver value to the customer" is really the only person who can make the right choices there, because the code has to be designed to make sure future valuable changes can be made, vs designed for a specific "snapshot" of specs.
And yeah, it often becomes a cycle, where management doesn't trust devs to build systems that won't suck, because devs haven't shown they can build systems that won't suck, because they're constantly just fighting the old systems that suck instead of having good training/experience building ones that don't... but I can't put that on non-technical management. We don't want non-technical management trying to tell us how to build a system, we just have to get better at it ourselves. You can do that by working on a bunch of broken systems, but you have to be thoughtful about it, and reflect on what you learn, and not just be distracted by "ooh, new shiny framework will make this better!"
On one hand developers get to scratch their "ooh new shiny" itch, on the other management doesn't risk any deadline from people trying new ideas when there's no time for that.
Unfortunately few employers are willing to go this route due to the associated cost.
Yes, but more due to inexperience than anything else. Projects tend to start out under-abstracted because modelling takes time, and they were told time to market was the #1 priority. So the natural reaction when that approach breaks down is to dust off the old design classes from school and create an all-encompassing model of everything in the business. Of course in the safe confines of college assignments they never got to experience what a pain that really is.
> Management rarely is involved or interfering there, when a dev or dev team decides to abstract over messy rules to make something "clean" - but in the process just encodes the messiness deeper, and in a harder-to-change way.
That exact lack of involvement is a big part of the problem. The idea of chucking PowerPoint mock-ups for CRUD screens over the fence and telling the devs not to worry their pretty little heads with any domain knowledge. I think Eric Evans has the solution to this problem with Domain Driven Design, but DDD requires a huge commitment on both sides to meet in the middle, sit down and work it all out. But neither have the time for it the way businesses are currently run.
The author hints that they wouldn't want a surgeon who is passionate because they should be making rational decisions.
But IMO passion isn't all about making an on the spot emotional decision without thinking things through. It's about their willingness to continue learning and advancing their craft because they have the motivation and passion to do so without getting burnt out. They do it because deep down it's truly what they love doing.
So in the surgeon example, would you rather want the surgeon who clocks in and out for the day and that's it while doing the bare minimum to keep their license? Or the surgeon who puts in similar hours but also decides to speak at conferences / universities afterwards and is keeping up with everything while evolving their practice? Perhaps they do more work (surgeries), but not putting in more hours. Maybe they specialize in 1 thing and then just crank that out continuously to become an expert in their field.
If given the choice I'd go for the more passionate surgeon every time.
The ones I've talked with are more interested in the implementation details, changing lives for the better and sharing what they've learned so everyone as a whole can rise.
Their practices are also wildly successful without content promotion and no to very little social media presence. These are the folks doing 750+ surgeries a year while being surrounded by relevant cases all the time. Basically total immersion in their field and then openly sharing everything with their colleagues.
Also, I'd rather have a surgeon who was skilled, cared about his profession, and also was not burned out from overexertion trying to be "passionate" about his job.
I think the medical field in general (not unlike the software development field in general) often undervalues people's time outside of work. It's fair to say that some fields require more investment from those that work in them, but in every field there is a point when investing even more of your time and effort is counter-productive.
This phrasing captures the issue exactly, imo. The split is between someone who is "trying" to be "passionate" about their work, versus someone for whom that's just an apt description.
It seems like the discussions around "passion" tend to ignore that distinction. I think the problem could be alternately framed in terms of intrinsic/extrinsic motivation without losing much. The passionate developer is a proxy for someone intrinsically motivated by the act of constructing software, vs. extrinsic motivation, which would be something like salary.
So if someone is trying to be "passionate" about their work, that will not convert them from extrinsic motivation to intrinsic (in most cases!), so of course it's seen as empty.
The surgeon question can be restated in these terms too: prefer a surgeon who's driven by saving lives and refining their expertise in this particular mode of doing it, or a surgeon driven by salary?
(Of course this is a simplified/extremal statement of the problem, and a false dichotomy if taken literally: basically everyone is somewhere between those two poles.)
But the issue I'm more concerned about is this idea that you have to live, breathe, drink, eat, sleep software development 24 hours a day, or you are a lesser developer than someone else who does. There are obviously different levels of investment people are willing and/or capable to commit to a job in this field, and yes some people are better at it than others. However, I think many in our profession are being pushed to invest too much of their lives into career-centric tasks, and as a result will end up being less effective as developers than they could be. I think this is perhaps even more dangerous than being lazy, and not keeping your skills relatively current.
Having a good balance in life is the way to avoid burnout. It is way too easy to leave your family and/or friends in the wake. There are infinitely more things to learn, and you can't do it all. These are choices I personally struggle with, as I'm sure many others here do.
It doesn't help that almost all of the job listings are asking for people "passionate about X" (where X can be almost anything related to development), or looking for "a Rockstar Y developer", or some other such buzzword-laden description. It seems to me, that there is a way to describe people who want to do high quality work, who care about their results, but at the same time have a life outside of work. However, although I see some job listings where the writers appear to be trying, a lot of them leave me thinking "no need to apply there, I just want a job doing a lot of things that I am good at and enjoy most of the time. I don't want to join a cult."
In the medical field, it's common to get CME (continuing medical education) time and dollars allocated specifically for this purpose.
100% this. I've seen consultants get paid $250 an hour to simply listen to what the team is saying and regurgitate that to management. But it's more trusted than their own employees because the consultant is "independent".
But it still came back to bite me in the end. When the consultant was paid and gone, there was suddenly no time anymore to act on any of the advice. It was all back to to the perpetual "just make this one simple feature" cycle, but the most insulting thing was hearing a twisted version of the consultant's advice used as ammunition against the team, questioning its competence.
That's the advantage of having an expert that is no longer there. You can make him agree with whatever you want.
Once there was an expert invited to solve a problem at a company I worked for. Towards the end of his short visit, we met in a kitchen and talked for a while. I asked him what he thought about the problem we had, and he told me his opinion. After he left, there was a meeting where the managers told us what the expert thought. It was almost the opposite of what he told me. Was he telling different conclusions to different people? Or were the managers just lying? No way to find out, of course.
My neighbor is an amazing carpenter. He makes beautiful furniture from exotic pieces of wood he's had for 10 years just waiting to be used on that perfect project. I told him he could make a fortune selling things like what he's got in his living room, but he just shrugged and said it would take away all the fun. He's right.
My neighbor has a job unrelated to carpentry, and woodworking is his hobby. He doesn't want to ruin it.
I get that it's not much fun to code apps (which I did for fun, too) because you need to do some kind of marketing to get a user base because if you don't it's not much fun to have an orphaned app in a store.
There's still a place for fringe programming if you feel the urge. Or go fishing or do gardening.
'An American investment banker was at the pier of a small coastal Mexican village when a small boat with just one fisherman docked. Inside the small boat were several large yellowfin tuna. The American complimented the Mexican on the quality of his fish and asked how long it took to catch them.
The Mexican replied, “only a little while.”
The American then asked why didn’t he stay out longer and catch more fish?
The Mexican said he had enough to support his family’s immediate needs.
The American then asked, “but what do you do with the rest of your time?”
The Mexican fisherman said, “I sleep late, fish a little, play with my children, take siestas with my wife, Maria, and stroll into the village each evening where I sip wine, and play guitar with my amigos. I have a full and busy life.”
The American scoffed. “I have an MBA from Harvard, and can help you,” he said. “You should spend more time fishing, and with the proceeds, buy a bigger boat. With the proceeds from the bigger boat, you could buy several boats, and eventually you would have a fleet of fishing boats. Instead of selling your catch to a middle-man, you could sell directly to the processor, eventually opening up your own cannery. You could control the product, processing, and distribution,” he said. “Of course, you would need to leave this small coastal fishing village and move to Mexico City, then Los Angeles, and eventually to New York City, where you will run your expanding enterprise.”
The Mexican fisherman asked, “But, how long will this all take?”
To which the American replied, “Oh, 15 to 20 years or so.”
“But what then?” asked the Mexican.
The American laughed and said, “That’s the best part. When the time was right, you would announce an IPO, and sell your company stock to the public and become very rich. You would make millions!”
“Millions – then what?”
The American said, “Then you could retire. Move to a small coastal fishing village where you could sleep late, fish a little, play with your kids, take siestas with your wife, and stroll to the village in the evenings where you could sip wine and play guitar with your amigos.”'
To me, that has been a challenge over my career and I've finally come to terms with it and I find my mood has improved quite a bit in the workplace as a result, albeit with a small death of my youthful idealism. However, now I try to use my passion in side projects, not to improve my CV, but just for fun. Interestingly enough, even idealism doesn't always work out there.
[1] I suppose it's possible to maintain your passion in the workplace and keep pushing ahead and doing even bigger and bigger things within a business (leveling up in the process, I'm sure), but I think to do so requires a lot of strength and endurance that a lot of us just don't have.
Likewise, when we interview people, we ask if they have a github repo or other portfolio, but it's about their code, not about OSS. I don't care if it's private code or OSS, so long as I can use it to judge their skill level.
And if they don't have anything like that, it's not a mark against them... It's just harder to be confident in their ability.
We do a short test, but any test that actually tests their abilities would be too time-consuming (and thus expense) to give to more than a handful or candidates that we were already pretty sure of.
The answer is yes. In terms of engineers and passion, I would bet that an engineer who is passionate about designing bridges would be one that would have studied past designs and failures of bridges in great detail, be up on the latest benefits and issues in material science, who was aware of special considerations for weather or location. I would also bet that engineer would be able to design a better bridge than one that was just doing it purely because it paid money.
As for surgeons and passion, when I was in neurosurgery, the best surgeons I knew were passionate about their work. They were constantly reading the latest journals, attending conferences, going to courses to hone and refine their skill. They were also constantly evaluating themselves to see if they could do things better. Then there were others who were just coasting on what they knew worked in the past. I would rather go to a passionate surgeon any day.
As for judges, I would like a judge who is passionate about the law and justice. I want a judge who not only knows what the current law says, but who has researched and knows how it came to be, the various precedents and circumstances that law has been applied. I want one who has contributed review articles to law journals, versus a judge who quickly does a Google or Lexis-Nexus search about the law to supplement their knowledge from 15 years ago in law school before they render their judgement.
There is a distinction between passion and exploitation. You can be passionate without having to give away your labour for free. Big corporations want people to work on open source because it saves them R&D money. Some projects take years to develop and that costs millions had the companies had to pay salaries and taxes, but instead they can just appropriate the project once it is mature enough, pat the developers on the back and then make billions off of it without sharing a penny.
You can be passionate and develop your own business, own projects without having to share them and saving corporations money.
To level the playing field big corporations should be required to pay royalties to open source contributors.
I think this would honestly be a bad assumption to make. The people I've worked with that did the most amount of work on their own time have typically not done any OSS work.. because they were working on work stuff all the time. Those that dabbled in (non work related) OSS stuff often were able to do so because they had clearer boundaries between work/personal work.
Perhaps the best model for software development is a small company with a few cofounders who are passionate about what they're working on, who charge a fair price for their software, and who work smarter in every possible way (yes, including making full use of open source) to minimize the amount of hiring they have to do. When they do hire, they treat their employees fairly and don't expect too much of them.
But then when I'm presented with, say, a security questionnaire, I wonder if developing software that meets today's standards is inevitably the sole domain of big companies. (I suspect many other developers feel the same way about my own pet cause, accessibility.)
I don't this is true of software. I live on the West Coast and SWEs are by far some of the most vocal and aggressive voices in a crowd. They seem highly engaged and constantly channeling emotion for what they want. That said, it's a recent trend. When I came into software the attitudes were much more laid back. I'd prefer a return to this.
I do not know what constitutes "cool job" but I've been developing for longer than many lived and not once was I asked about my open source contributions. When I do work for clients it is nearly always to design and create a product. I have a "portfolio" of such products with appropriate references and this is what I show to clients and it seems to work very well.
Also working on product makes me interested way more in the design / inventive aspects. Programming itself is just a tool for me to express my ideas. This makes me a "dispassionate programmer". I can appreciate good tools / languages /tech / etc that make me complete the task easier but once more - they're just tools.
Last thing. I do not have any "open source" contributions. I am not proud of it but do not feel guilty either.
The big corps simply will not use such OSS because they would have to also make their code open.
More wide adoption of these licenses would encourage a more healthy relationship between corps and OSS devs.
It's easy to imagine that in a world where essential low level software and useful libraries are AGPLed, the current big corps would probably not be as big as they are today. Instead more transparent organizations with more sustainable business models would gain a real advantage.
I don't know how convincing that argument is, but hopefully realizing how much investment the big tech companies are putting into their talent is eye-opening for some people.
(Note: I talked about investing in junior employees, but the idea applies to all your employees.)
[0] https://hiringfor.tech/2020/09/07/the-prisoners-dilemma-of-t...
Parenthood takes a lot of time, and I fear I'll never be able to find a new job because i don't have time to jump through interview hoops.
I'll certainly never work at Google or wherever, because they interview for so long and have so many requirements that it's impossible for me to even think about applying. The tech interview process is openly hostile to parents.
> ... I'd like such people to care about their vocation, but I'd prefer that they keep a cool head and make as rational decisions as possible.
> Why should programmers be passionate?
While I agree with the gist of the article, the author should realize that "passionate" as used in this context is effectively synonymous with "cares", and is only used because the word "care" has lost most of its impact over time, being mostly associated with the phrase "doesn't care". This is common linguistic phenomenon.
Lightbulbs are flashing for me right now because I’ve never really thought about it like this, despite caring a lot about passion.
In the teams I’ve been on that have over-performed (aka released quality software on schedule), there was always at least one or two (sometimes the majority) engineers who actually cared. Cared enough to push back when we tried to skimp on standards compliance. Cared enough to upstream a fix to a library we use. Cared enough to notice patterns in problems we had and write internal articles about how to avoid those problems.
I’ve also been on teams of (primarily European, as the author points out, the culture is very different) engineers who really are just collecting a paycheck. As long as they keep working, it’s really not a big deal if the product ships on time, or a year late. It doesn’t really matter if the product meets customer needs well, because we know they will buy it anyway. It doesn’t really matter if your colleague knows enough to get their work done. And if I see a new problem the team encounters, I’m certainly not going to learn anything to solve it, or assist a colleague who does; job descriptions are there for a reason.
I guess a good test is the “job description” test. Does an engineer ever say “that’s not in my job description” and refuse to do needed work (note this is very different than pointing out there would be someone better equipped to do it, if that is the case) to the detriment of the team? Does an engineer not bristle when someone else brings up “the job description”? If so, that’s a pretty sure sign that they don’t care about their work, which means they don’t care about your team’s success.
Yes, but not because of the lack of passionate programmers, but because most software companies are dysfunctional. A few passionate souls can make a project succeed in spite of all the underlying dysfunction, but it's cruel of the industry to continue leaning on those people.
Teams of uncaring developers would consistently deliver working software on time and on budget if they were both trained in the same level of skill and given the same level of respect that let uncaring civil engineers build stable bridges on time and on budget. And I would certainly hate living in a society where the only thing between me and a smoking hole at the bottom of a gorge is one passionate civil engineer.
I think that largely depends on who is using the word. Personally, I'm sick of seeing the word "passionate" thrown around in job listings. It comes off as "we really need to use this buzzword", and 90% of the time feels disingenuous.
Much of the time I end up interpreting it as "someone who is willing to work a lot of uncompensated extra hours". I say this as a person who very much cares about their craft, and wants to do excellent work as much as it is within my power to do so. I also do spend a lot of my free time learning new things related to my profession.
I'm not saying everyone who uses that word is intending to take advantage of their future employees desire to excel. It just seems like most of the times I see it, the job listing ends up being one that I'm less likely to be interested in.
I would say that I am passionate about solving problems with technology - I was coding since GWBASIC on a Soviet 286 when I was 8 years old. I am in product now and I still get fired up about solving problems for my users and clients.
But...
I was also able to channel this passion into lucrative fields. If you asked me 2 decades ago if my passion is derivatives trading software, I'd say no. But turns out this field gave me plenty of space to be creative, enthusiastic, and engaged while giving me and my family a good life. And also I can connect my work to important things (eg: helping asset managers generate good returns for pension funds)
To be honest, I'd hesitate to hire someone who is just all about open source, because if they don't care (that much) about financial impact of their work on their own life, I can't rely on them to care about the financial impact of their software on my company's success either, and I guess it just feels like impractical/unpragmatic decision making.
I think a lot of techies believe there is massive untapped potential in information technology, and to some degree that the commercialism occludes humanity from gaining a fair, reasonable, and developing perspective on how computation and communication happens in the modern world.
We see the world not as being well served by the software and services about, but as being made helpless, as suffering real pain, and never being given the chance to understand or grapple with issues we encounter. The current system is not a fair shake, and does not permit the formation of human will. Computing technology is too amazing, humans have too much awesome potential, to be bounded by such a finite fixed tragic end, as all this. It's long been time to stop playing with shadows on the wall, & embarking on a more honest means to make accessible the tiniest yet most amazing empowering bicycle-of-the-mind creation of our era is a journey we feel deeply moved to start upon.
Pretty much this.
See also: https://www.wired.com/story/open-source-coders-few-tired/
This one is so common, it's a staple. Very few places I have worked will pay for certs because after that the employee is worth more so there's no budget for the cert + the requisite pay bump that having such a cert deserves.
I don't know how to fix it, but I wish one day I can convince other people that training is the path to unlocking better teams versus just more headcount. The salary for one senior dev can be split 5 ways into an existing team and given enough knowledge can make you more than having an extra dev.
I read Bullshit Jobs and realized why this might be the issue... reports are a sign of power, the more you have, the more power you have, so in order to advance your career, you must be willing to sacrifice the place you work at by hiring more and more people under you.
Then I quit.
Now I'm happy.
Do they really? I feel that my employers have all preferred employees who prioritize business needs, smooth functioning of the corporate hierarchy, "doing what everyone else is doing", and writing code for the common denominator more than they prioritize personal feelings about code quality and about what technological decisions are correct. I feel that my employers would all have preferred a steady, dispassionate 9-5 corporate type over a passionate employee who burns the midnight oil. The midnight oil burner, they probably would think, is likely to be a "cowboy coder". He might be a loose cannon.
Not that any of this is surprising. Of course employers prefer employees who prioritize making the company money more highly than they prioritize passion about their craft.
> I don't think that it's in our interest to be passionate, but it is in employers' interest
Meh, I'm into some technologies just cause they fascinate me. Benefits employers, but benefits me too cause I get paid to pursue my passion.
> Not only are passionate people expected to work for free, they're also easier to manipulate
Passionate ppl in the Spark world make tons of money and strike me as geniuses that'd be hard to manipulate.
> Some open-source maintainers have created crucial software that runs everywhere
Yes
> Companies make millions off that free software, while maintainers are often left with an increasing support burden and no money
Maybe some. Spark creators went on to build a successful company (Databricks) that'll be going public soon. Companies seem to be throwing money at top open source devs in the data world.
Like others have mentioned, I don't really see this in the industry. That said, I think it's less a quest for the 'passionate' developer and more a quest for a good employee who can contribute to the task at hand.
Companies don't want 'passion' they want someone who will work hard on their product and be a great return on investment for the company. How do you measure that? That's hard. Detecting it in a 1-4 hour interview is also hard. Or, they can take the easy way out, generalize, and look for markers of that behavior, such as working an open source project 'job' in addition to their daily job.
> For reasons that are complicated and that I don't fully understand, the software development community in the eighties and nineties developed a culture of anti-capitalism and liberal values that put technology on a pedestal for its own sake.
Liberalism is by definition pro-capitalism. It's not pro-capitalism in the libertarian sense of "free markets", of course, but it's not like Silicon Valley doesn't have its right-libertarians, too. I think this analysis has it exactly backward. I find the position proposed in The Californian Ideology much more compelling: The culture Mark is talking about was a fusion of market liberalism, countercultural signifiers, and techno-utopianism.
> The idea of free software, for example, has led to a software economy where you, the user, are no longer the customer, but the product.
This is almost exactly what the notion of "free software" was invented to oppose. "Freedom" in software isn't supposed to be about price, but about liberty. Free software can absolutely cost money, but if it starts treating its users like products, it is by definition no longer free software. Of course, this is exactly why "open source" became so popular...
> The idea of open source, too, seems largely defunct as a means of 'sticking it to the man'.
Open source was never about "sticking it to the man". Open source is a defanged version of free software, where the only freedom left is the one which hurts the man the least when exercised.
Post-Open Source by Melody Horn is also recommended reading here.
Same during interviews, when asked if I have contributed to open source library, I answer not at at work and that I don't program that much on my free time. It may not serve me well but it is the last bastion of honesty that the hiring process allows me. Besides that you are still just selling yourself to whoever take interest in your case.
For example with covid, I have fewer other possible hobbies so doubling down in this specific interest is both fun, and a sound investment.
And also age/trajectory matters. I'm at year 10 of my journey, probably around year 20 I'll have completely different priorities in my life.
I'm sure there are other ways, but one sure way that I have personally used and been fairly successful. Understand your boss and make your boss look good. If you don't understand your boss by year 2, it's time to move on.
No it hasn't, unless the author is conflating free software with free beer. Free software, if anything, leads to the opposite: empowering users to take stronger ownership over the programs they use.
1. For reasons that are complicated and that I don't fully understand, Americans smile at each other.
2. Ad agencies show pictures of humans smiling at each other in order to exploit humans into buying products they don't need.
3. Americans should stop smiling.
It's also somewhat of a fallacy to claim that open-source software is the domain of hobbyists. A lot of open-source software nowadays is produced by paid programmers as part of their day jobs.
People like painting, baking, brewing beer, playing music or sports... and also coding. For free.
Let me give a couple of examples from this blog:
Software devs had anti-capitalist values -> free software -> unintended consequences -> customer is the product
Do you see where the leap of faith occurred? The last arrow. If you're young and you don't know, when app stores on mobile phones started and apps got built, most of them weren't free. When facebook got started, it was free, but it had nothing to do with anti-capitalist values, etc.
Another example:
employers want people who are passionate -> do open source to prove your passion
Where's the leap of faith? The initial premise. Let me give another example that'll perhaps illustrate: when women get polled about what they look for in a man, they say: sense of humor.
Does anyone take that seriously? No, right? We know people are full of shit and say one thing and mean another? Well, not people who write blogs or comment on twitter a lot of the time!
So much of blogging and twittering, is taking false premises or helping start new ones (first example). Guys/gals, I can forgive people who have never heard of A implies B in their lives. You have, please check that A = true and A actually implies B, every step of the way.
Apply mental-tests to your own thinking - it's great that you get software to compile, please get your view of the world to compile to a level a random stranger on the internet can't tear apart within 10 seconds.
" For reasons that are complicated and that I don't fully understand, the software development community in the eighties and nineties developed a culture of anti-capitalism and liberal values that put technology on a pedestal for its own sake. Open source good; commercial software bad. Free software good; commercial software bad.
I'm not entirely unsympathetic to such ideas, but it's seems clear, now, that these ideas have had unintended consequences. The idea of free software, for example, has led to a software economy where you, the user, are no longer the customer, but the product. "
Free software is free as in freedom, not free as in you don't have to pay for it. If Google & co followed the ideals of free software, all of their source code for their servers would be available to the public, and indivuduals would be free to spin up and run their own google that doesn't use ads.
This writer has no idea what he is talking about, its not worth reading this post.
Software need to be open! If it was meant to be free it would be called Freesource not Opoensource.
I don't get it, is he being facetious or am I missing the point in some other way? To anyone in tech those are obviously orthogonal concepts. There is commercial FOSS, commercial proprietary software, non-commercial FOSS, non-commercial proprietary software.
And if you think commercial software is the problem, as some communist hard-liners that I've talked to, the only logical conclusion is to do as they did, vehemently oppose FOSS licenses since you're not allowed to restrict commercial use of it.
Of course the F camp emphasise the personal values while the OS camp emphasise the commercial opportunities. But I don't think RMS was trying to "stick it to the man", he was just trying to print some listings. And big businesses like Microsoft have sensibly come to the same conclusion, that sometimes it's nice to have that same freedom.
> The idea of free software, for example, has led to a software economy where you, the user, are no longer the customer, but the product.
I don't see how it has led to that at all. It's just different, not as polished, but if you have the know-how you can fix things. You gain some, you lose some.
This goes back to an earlier age of software, in the 1960s and 1970s, when much more software was being shared, among research groups and labs in Academia and industry, as it had not been commoditized and commercialized as such. As this gradually changed, it also motivated an embattled, somewhat-delayed, backlash in the form of the Free Software movement.
> and liberal values
Problematic term, because it means very different things historically vs. in current political discourse in the US.
> The idea of free software, for example, has led to a software economy where you, the user, are no longer the customer, but the product.
The author accepts as granted the foundational assumptions that:
* Users are customers, basically and originally.
* Software is a commodity, to be sold (as a product or service).
* Users are fundamentally disjoint from developers, and these groups of people interact through commercial entities.
Proponents of Free Software with an anti-Capitalist perspective would be to differ.
> The idea of open source, too, seems largely defunct as a means of 'sticking it to the man'.
While commercial corporations co-opt FOSS as much as they can, it has still, and is still, sticking it to the man: Billions of people, given only access to a computer, can now enjoy a huge variety of software to meet their needs and interests, without having to pay for it. A salaried software developer, sitting in some tech-rich organization, may fail to appreciate what a tremendous achievement this is. And there's the no less important ability to partake in development, and to build on the existing software with something new - which is much less accessible than plain use, but infinitely more accessible than with commercial closed-source software.
> You're expected to 'contribute' to open source software. Why? Because employers want employees who are passionate about their craft.
I don't know what employers expect. But we, i.e. users and developers of FOSS, need your help to add features and fix bugs and write docs and file bugs, for the software we use or want.
> Would you like engineers to be passionate as they design new bridges?
I hope they could be. This is less likely the less in touch they are with the people and groups who need their bridge; and the more alienated they are from their work in general.
> passionate... I'd prefer that they keep a cool head and make as rational decisions as possible.
This is a false dichotomy. The dispassionate programmer is more often than not the disinterested programmer; the "I just work here" programmer; the programmer who is writing software to meet arbitrary goals set by far-away managers, not to have the tool they need or to help their friends and colleagues.
> This was back in my Microsoft days, so I suggested that they institute a training programme for the employees. To give it structure, they could, for example, study for some Microsoft certifications.
Ah... well, indeed, living in the Micorosft certified-whatever world will likely take care of your excessive passion problems.
> If I teach you something that improves your productivity, your employer benefits, too. I think that your employer should pay for that.
This, I agree with. But instead of "being dispassionate", I suggest we be _unionized_! Make those companies pay for this kind of professional development and meandering exploration of new knowledge and skills.
(And also remember that a lot of, or most of, FOSS isn't necessarily what you do in your day job anyway.)
So, I'm old enough to remember a time before widespread open source and even before the world-wide-web itself. I was paid to work on whatever my employer thought they could sell, but not necessarily what I was interested in learning more about. When Linux came out, for example, I thought that going through it and maybe even working on it would be a great way to learn more about operating systems in a way that I would never get a chance to do professionally. Being curious about something isn't necessarily declaring it "worthless".
That said, I agree with the author that it's scummy to demand it of employees (although I've never seen that myself).
- yours sincerely, the descriptivists of this world