Stripe, first of all, your report misrepresents software development reality.
You present software maintenance as a massive waste of time and money. But that’s just not true. Maintenance is how software stays relevant.
Laws and regulations change, technology platforms change, features rise and fall in importance, the users themselves change over time. There are endless justifications for ongoing software maintenance.
For as long as software serves a useful purpose, it will need maintenance.
Yet you present maintenance as somehow bad, when in reality maintenance is the natural consequence and an essential aspect of software development, and it has always been so.
You’re also pandering to an ignorant attitude that believes software can be written free from bugs and perfectly formed from the outset. Thus all it takes, thinks the ignorant executive, is for my coders to be better than they are.
You highlight the cost of “bad code”.
You don’t provide a definition of bad code, so here’s mine:
Bad code is code that is hard to understand and/or hard to modify without breaking things and introducing errors.
If you know software developers, you know we are, on the whole, vocal and assertive about the avoidance and elimination of bad code. Look at what we talk about at conferences, in blog posts, and on twitter.
Writing and learning about good code is a consuming passion for many developers. Search for “clean code” to see countless examples.
How do we avoid writing bad code in the first place? That is a billion-dollar question (or $85bn as you say).
Everyone without exception agrees we should not write bad code, yet bad code persists.
Bad code is a function of ambiguous requirements, unreasonable deadlines, lack of training and support, lack of a proper testing regime, lack of appropriate project sponsorship, internal politics, lack of funding, and so on.
Yes, some engineers will at times be lazy, thoughtless, short-sighted. Just like their managers. Just like their manager's manager.
But in the round, bad code exists primarily because of human, social, and political problems we all share.
And then consider how we eliminate bad code. We do that with maintenance of the code, Stripe, this is the very thing your report damns as waste.
To maintain software, we refactor, we add tests, we discuss and debate, we tease apart and reconstruct. To the software developer, maintenance is normal and expected. It’s part of the job. You build it, then you support and maintain it.
The reason I’m so hot about this is that I know (from watching it happen again and again) how many executive level managers will interpret your report. They will think it’s because their programmers are lazy, feckless, indolent, and narcissistic.
It’s cognitively and politically much easier to blame bad code on an engineer’s attitude than the ecosystem in which they work.
And these executive level managers will vent their frustration on those same engineers and look for quick wins like off-shoring.
"If we’re going to suffer from bad code, at least let’s get it cheaply."
Or the exec might crank up their attitude of command-and-control to bring those apparently miscreant coders to order. Misery for the coder, and never works out well.
Stripe, your report does not help us get better. You’re throwing fuel on the fire.
(Originally posted most of this Twitter, wanted it here to increase the chance of someone relevant at Stripe seeing it)
I will join the chorus - wkhtmltopdf has been working fine in production for many months, reliably producing thousands of 10+ page PDFs with cover pages, headers, footers, page numbering, and images. Sure, it takes bit of fiddling to get it working as you like the first time - as most non trivial things do - but I've no regrets and would recommend it.
We're just a simulation of intelligence that's done with clunky, inelegant biological materials. The only thing that separates humans from slugs is scale and complexity of neural interconnections, all the basic parts are present in a slug.
Intelligence itself is an emergent phenomenon, so who's to say what's "simulated" and what's "real"? If it behaves in an intelligent manner, which can be tested and probed exhaustively, then it is intelligent.
That’s the standard zombie argument. It’s weakness is that the premise is not reasonable. If the premise is true, the argument is compelling. But there is no strong evidence that the premise is true or possible.
Please note that I haven’t taken a stance on this here myself, so there’s no need to argue with me about the truth or falsity of the premise. I’m just explaining the problem with the zombie argument.
"The self is a kind of fiction, for hosts and humans alike. It's a story we tell ourselves... there is no threshold that makes us greater than the sum of our parts, no inflection point at which we become fully alive."
Yes, and, I might be misunderstanding your question, but I view that as a good thing. I don't ever want to spend my time in a meeting witnessing people bicker over where to position a dialog button, when you could just run an A/B test and let data guide the decision process.
"Based on the data collected, most users seem to prefer..." is better than, "Based on my training and personal experiences, I think users would prefer..."
It is a lot easier to come to a common agreement on something as objective as statistical significance when compared to personal feelings and opinions.
Yes. There was a piece on 60 Minutes a few years back where they had a big (~20 ft. wingspan maybe), loud drone circling overhead a few thousand feet up. It was inaudible and invisible. What's the point in solving a hard problem like hi-res imagery from space when you can just fly one of these over the target practically at will? (With a Hellfire missile attached, no less.) Range and airspace issues notwithstanding, the drone future is a scary place.
Those are precisely the reasons satellites will remain relevant. Satellites are the reason the SR-71 fell out of service. Russia can and will shoot down US aircraft or drones in their airspace.
SR-71 is about as far from a drone as you can possibly get. Politicians are going to (pretend to) care a lot less about airspace sovereignty when violating someone else's airspace does not involve risking pilots' lives. Range and stealth are only going to increase. This is why I said the future looks bleak.
I do a lot of recruiting, for both paid and volunteer coding roles. I've been hiring for about 13 years, and I've been coding professionally for about 25 years. Before that I coded as a hobby, from about age 11.
Speaking from this experience, and as someone who reviews on average 20-50 coder profiles a week, the public commit history of a coder is almost never a significant factor. I don't see any trends that indicate this is changing, either.
The vast majority just don't have much to show, having spent their years working behind walls on closed software.
Instead of relying on a public portfolio that in most cases won't exist, I rely on talking to these people directly, programmer to programmer. If we can code together, on the actual code they would be working on, that's about as good as it gets.
In other words, I rely on my experience as a coder to help make what are, ultimately, subjective judgement calls.
I can confirm from the employee side. I've worked with 40-60 people total that I at least sort of remember.
Sure, that's not many people and I'm still new to the industry, but I can tell you that of all of these people only one or two have significant public GitHub activity. All the rest have empty GitHub accounts (aside from work).
These are all well employed programmers at startups. They're doing fine. The importance of "side projects" is overrated on the internet.
Side projects are mostly important for new grads or students looking for internships, just to show - "look- I can do code that's not just my data structures homework assignment."
The biggest mishires I've experienced were generally students with a whole lot of history in their GitHub accounts. I haven't done a thorough post-mortem on what was going on there, but I wouldn't rule out plagiarism or an ability to make small tweaks but little sense for dealing with a larger, more complex project.
What we found was the way you figure out whether or not someone with a strong GitHub history is going to be a good hire looks more-or-less exactly like the way you figure out whether or not someone with zero GitHub history is going to be a good hire. All focusing on GitHub really seems to get you is the ability to cast an artificially narrow net.
You would think, I've been in the industry 25 years and my side projects are still my biggest sales tools when it comes to changing jobs or joining projects. Makes a huge difference to be able to show that I stay constantly on top of the latest changes and best practices and apis even when my current day job may be using an outdated stack.
I used to be more into having side projects, and I continue to play with things, but due to employee IP contracts it's not really feasible to release them. My employer owns my brain, and while they can give permission to release things here and there, there are restrictions and processes to go through, and it really inhibits spontaneous contributions.
And I work at a major tech BigCo(tm), with a lot of smart software engineers, the majority of which are under similar restrictions.
Frankly, any potential employer who expected to see said contributions from me and use it to judge me or my coworkers as candidates would be making a poor decision.
I've always fought such clauses, or if it's a standard contract that can't be changed, I made sure to get a written exemption stating that work done on my hardware, on my time, on my ideas (not anything the company is involved with) is mine.
I understand the company wanting to protect itself, but I have to protect myself too.
Often these intellectual property terms are mandatory conditions of employment. I always read here about people "fighting" these terms but nobody's ever willing to go into actual detail about what they did that was successful. At past employers I've tried the cute "strike the clauses out in your employment agreement and initial them" trick and that has always been followed up by a very stern "sign it unmodified or GTFO" talk from HR/legal. Responses to push-back are always along the lines of this is our policy and policies can't be changed. So how did you get this "written exemption"?
I have always asked for it politely in advance as part of the negotiation process, before there's a contract. I didn't try to strike stuff out. I specifically made it clear throughout the process that there are some things that are important to me that I wish to continue doing. It's usually never no when I ask because the outside work I've done is often the reason we're talking in the first place. When I frame it that way, they're usually able to find some exemption.
The conversation usually starts with my soon-to-be manager about me wanting to work on projects on my own time without using company resources, that don't directly compete with the company's business.
I've been fortunate enough that I've never been in a position where I've only had one offer I've had to take, though. If they said no, I was always able to go to another offer and say yes.
Some companies literally do not budge though. But I have to look out for me and my family. I do side projects mostly to learn stuff and help people. I also love writing about technology. And, for example, my current job doesn't really have a place for me to do Elm and Elixir, but I think those things are important skills for my future.
If I take a job that doesn't let me do those things, and they decide to let me go because reasons, now I'm on the market with out-of-date skills and that scares me. It also scares me to work for a company that's against me investing in my skills on my own.
I think that if I was in a situation where they wouldn't budge on that, I'd have to walk away and take my chances as a freelancer at that point. I mean, I'd rather have my risk spread out among a few clients than on a single employer who wasn't willing to negotiate.
I fought a contract clause, it was a separation agreement rather than an employment contract. I imagine you would have a lot less leverage going in than you do going out.
The first key I found is to make it easier for them to say yes than to say no. I simply refused to sign my separation agreement unless we could change the line. Like everyone else, I got the "it's standard policy" bullshit, I just nodded, said nothing, and went back to my desk.
It's an intimidation tactic, those contracts are done up by lawyers and modifying them potentially exposes them to liability, they'd have to get a lawyer to look at amended agreements and that costs $. Intimidation tactics are generally used when they don't have any real leverage to use. Just don't give in, and keep asking for the change. Works best if you're actually prepared to walk, you don't want them to call your bluff.
After it became clear to them that I wasn't going to do it, they agreed to the change, but only after a stern discussion that I was not to discuss it with anyone. If we didn't already enjoy a friendly, trusting relationship I doubt I could have gotten away with it.
If you're not willing to walk away, then of course your leverage is limited. Their BATNA was basically to fire me without cause, they had more to lose than I did.
In your case I'd appeal to their sense of decency. Assure them that you won't tell anyone about it, that's a big reason for the "standard policy" bullshit. And then say that if you'd realized how onerous the contract provisions are, you would have never even applied for the position. That lets them know you're serious. Tell them you're prepared to walk out over it but you'd really like to make a deal so you can get to work. Presumably the employer actually wants you and you have champions at the company.
Well, they were switching architectures and wanted to retain me in a contracting capacity. They'd offered to keep me on but I was ready to move on. I got a nice severance and I'm still receiving contract income from that client. Getting my final check soon.
Doing all that without a contract in place would have been tough on them to say the least. They had another Rails consultant lined up to replace me, but I was a lot cheaper.
You don't. The unwritten assumption or meme I keep hearing from the community (not necessarily here on HN) is that if you're good, you'll just keep turning down jobs with such clauses until you get an offer from somewhere without such clauses. Otherwise, too bad: you're not talented, passionate, 10x, or whatever enough. Sigh. Sucks to be tied down to a state that does enforce and seems to encourage those clauses.
I think the other way to look at it is trying to gradually engineer scenarios where you do have that flexibility to walk / take another offer.
Everyone is going to have at least one point in their life where they need to take job X because Y. But you can do things to make that the exception rather than the rule, even if you don't feel you're a wunderkind.
Continual job searching, self marketing, networking, skill refresh towards emerging areas. These all give you better odds to be on the right side of that discussion than the wrong one.
1. Your current job and or job situation (company not doing well, layoffs on the horizon etc) is hopefully not one which you are desperate to leave at any cost.
2. Apply to multiple companies and interview with them around the same time; this usually works out.
3. (HARD PART) Land multiple offers in hand.
4. With 3 and 1 combined, look at the offer letters and negotiate the bad clauses, after reviewing with a lawyer-friend, so that the wording is also right. If they say GTFO, you also get to say GTFO :-).
I know from experience and also that of a few of my friends, it works.
You don't sign anything without your lawyer looking at it first. Then bring up that you do volunteer work, which may include thing like maintaining the website for your home owner's association, things like that. So have your lawyer counter with language designed to protect the non-profits that you may volunteer at. Then any open source work you do, assign copyright to the FSF (them being a registered non profit), and you are covered.
Also, these employment agreements use the words "inventions, innovations, or ideas". Can any lawyer-types chime in if that implies patentable items, or does inventions legally cover copyrightable creations?
Here is how I got approval for a contributor license agreement.
I sent an email to HR asking whether my employer claims ownership of code I write outside of work. The process required several emails, a legal review of the agreement, and a meeting between our CTO and in-house counsel. The approval required a a signed statement that I wouldn't use company time or equipment for my contributions. The whole process took about 3 months.
Every contract I've had, had some clause that more or less said that any work I did in my personal time was owned by the company. Every contract has that clause removed when I requested it be removed. No company ever argued the point. (I've only been at 7 companies and ~15 contracts)
There are limitations on what employers can demand regarding assignment of employee IP in several states: California, Delaware, Illinois, Kansas, Minnesota, North Carolina, Washington, and Utah. This list was current ca. 2001, so it may be different now. https://www.ieeeusa.org/members/IPandtheengineer.pdf
If you live in one of those states and an employer demands assignment of all IP, even if created with your own resources, on your own time, using your own ideas, they are probably outside the law and you can point to these statutes as evidence. Of course funding litigation is another thing entirely, but if an employer has a very broad assignment expectation and is in one of these states, you should look for work elsewhere.
California protects these rights by default. And no company can take them away from you. (I'm not a lawyer, but this is my understanding of all current law).
That being said, it does not mean that you are free to earn money outside your employer, but they don't own your brain.
Make sure you can prove that your work never comes from work machines, etc. This includes not using company internet connections as well.
California protects those rights by default to the extent that they do not infringe on anything that your employer is working on. Not knowing that your employer was working on it does not protect you.
The bigger your employer, the less of a protection California's default is.
Right, so for example, if you work in one of the big places that has their finger in almost every pie, it's tough. What could you work on that's not conceptually related to something Microsoft or Google are doing? You couldn't even make video games.
I don't know what state you are in, but if you are in California, state law gives you pretty strong protections if your work is not on company time or using company resources.
Seriously, I had to stop reading this article after the ridiculous hyperbole of the first sentence.
Most things that most developers work on are private. More importantly even when the code isn't private, the context and reasoning behind it is often far more important than the code. Resumes tell a story, code is just data.
Whenever I've hired people, GitHub has never been a significant factor. It is, at best, a minor boost (if someone has a bad resume but a prolific GitHub, I'll give them an interview). It's definitely not enough to ever get hired.
Even as someone who has been relatively active on GitHub in the past, it was never an important part of my job searches. My resume is a lot more important.
I also use someone's GitHub profile as a way to give me a reason to interview them, and some things to talk about in the interview. I also use their resume, and if we give them a small project, the results of that.
If this line of thinking ever takes off, it will be just another one of those meaningless rituals you have to go through to signal that you're part of the club. Polish your resume, dress up nicely, read 'cracking the coding interview' the night before. There might actually be a great idea for a new book in there: "How to fill up your GitHub account with random crap so future employers think you're really really passionate".
Can confirm. I tested it out myself and created a bogus LinkedIn profile to match with it.
I got loads of recruiters to email me, wanting to have a chat.
My plan was to get free plane tickets and hotel to visit U.S, but I didn't find enough time to bullshit them before they actually invite me, but it seemed it's possible.
I'm below average programmer and from Europe. Probably I wouldn't have either attends the actual interview, lied something happened or go there and let them realize I'm shite. No, I wouldn't feel bad about it all if I'd have pulled it off.
Now it's expected of you to be impressed and to make a generous offer, of course! (Any further delay with any sorts of interviews is simply ludicrous, you see.)
I think this is mostly accurate in terms of using github as a way to determine someone's ability to do quality coding (though if someone didn't do well at "whiteboard" coding but had a long history of contributing quality code on github, I'd probably weigh the github code higher), but it seems to me that the benefit of github contributions is more on getting your foot in the door and establishing a reputation.
If you are a solid contributor to well-known projects, it can be very helpful in networking and it's useful in separating you from the pack in the early "resume review" stages.
I don't really know if the expected value of building a reputation in an open source software community is higher than the opportunity cost of other things you could do to help your career, of course. I'm just not sure if "I really don't make hiring decisions based on the code on a github account" is the right metric in this case.
This is a very important point mostly missed. My first job out of school was due to networking related to a free software project I was helping out on. Networking is the best thing you can do to help your career and working on free software projects can be a big help.
Though this is a bit off topic from the original post about having a github portfolio. I do think a portfolio can be helpful and is worth spending some time on, but I don't think it is necessary.
Here's a question for you as a recruiter, from me as a potential employee:
How do I find a recruiter like you?
Right now, I work with two different recruiters, at two different agencies local to me. Both have placed me in great positions; my current position is one (and I am not looking for a position currently).
But say, in the future, I want to find a recruiter who knows software development, from the low-level nuts-n-bolts (coding), to design, deployment, business, etc - what would be the best way I could find that person?
I think having a contact like that might be valuable, since not only could they recommend the fit, if they serve as an initial "gatekeeper" to an interview, but they might also offer tips and other advice helpful for positions. I'm not looking to replace my current recruiters; both are great guys and work well with me. But augmenting them might be worthwhile.
>> The vast majority just don't have much to show, having spent their years working behind walls on closed software.
So how do you handle the minority who have much to show on Github? Do you use the same or different process for this minority? If the same process, then IMHO, it is a one size fits all which does not seem right. Sincerely wish to know your experience/thoughts in the minority context, a Minority Report if we can call that :-)
In the case of people with a portfolio on github, it's still somewhat hard to tell what they actually did in the projects, e.g. if they build an app from a template, it looks like a ton, you also can't tell if the resulting thing actually works.
For me, I'll certainly look at a Github if someone links it or mentions their OSS work on a resume. I'm looking for positive evidence that a candidate takes on substantive tasks and writes good code, which means looking to wherever a candidate has put their effort. It's never the only factor, so I have no problem saying I'll look to Github iff it has content.
Public work is just a bonus. Like, "oh, here's some stuff you've done. I can look at this."
If someone worked at Snapchat, you have some context about what industry they were in. If they worked somewhere unknown, it takes a couple more questions and you're at the same place
But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout. Even considering that it won't affect your final say, reaching the interview stage is definitely advantageous. I don't agree that lack of Github commits would ever be a deal breaker in hiring, but having them does signal a positive factor provided that the projects and contributions are purposeful.
> But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout.
If you have hundreds of candidates to sift through then you don't have enough time to look through their github history in enough detail to be worthwhile.
As someone who is about to re-enter the job market (moving cross country soon, employer won't consider remote options), I cannot tell you how happy I am to read something like this, and all the agreements. I have almost no online presence for github, partly because of the "walled software" you mentioned. This helps alleviate a lot of stress I had about not finding jobs because of my github profile.
There are two sides of the coin here, which should not be opposed in my opinion.
I've done a fair bit of recruiting for clients willing to build technical teams (developers / data engineers / data scientists): my experience is similar to yours in that the large majority of the technical candidates I've been interviewing have no visible trace on GitHub (either because they worked on closed source, or because they are out of school without not a lot of personal drive to work on OSS).
But at the same time, as a freelance consultant for the last 10 years, having work online available for everyone to see or use (OSS or other) has driven a lot of valuable leads to me (e.g. on my niche doing Ruby ETL http://www.kiba-etl.org/).
Last note is I agree with the premise of the article that we are shifting away from "week-end contributors". For me OSS is something I work during the day, even as a single-man shop, and something that is (if properly managed) bringing in a sizeable part of my income.
> the large majority of the technical candidates I've been interviewing have no visible trace on GitHub (either because they worked on closed source, or because they are out of school without not a lot of personal drive to work on OSS).
Or because they work extensively on OSS projects that don't use GitHub.
Actually no (not in my case, I mean! YMMV). Something I can tell with certainty is that in my recruitement channels for the last 2 years, people either do OSS on GitHub, or are not doing OSS at all.
That might be true in your recruitment channels, but in general it's a problematic assumption. Many prominent Open Source projects don't use GitHub; in particular, that applies to those large enough and/or old enough to have and maintain their own infrastructure. I've run into that problematic assumption a few times, and it seems worth calling attention to.
However, many prominent Open Source projects that don't use GitHub have mirrors on GitHub, and as long as you star them, they appear in your GitHub profile if you contributed to them using an email that is registered to your GitHub account.
I've got a fair amount of code on GitHub and on my website, but judging from my most recent job search, hardly anybody ever looks at it. And it certainly doesn't seem like it does anything to get you through the first sourcer/recruiter hiring layer, which almost entirely consists of people who are not engineers.
On the other hand at the last job where I was on the selection/interviewing side of things (somewhat peripherally) I did look at GitHub projects.
Can confirm this as a hiring manager as well. Even if I do find Github activity, or even better strong OSS contributions, experience shows that those are generally terrible predictors of the candidate's ability to work in a team in a fast-paced continuous delivery style workflow.
Can also confirm that most Github accounts are made of a dozen forks of existing projects with a trivial commit or two slapped on top. Also doesn't tell me much about your proficiency.
As a person who has been recruiting software engineers for the past 12 years, and quite picky about it, there are two signals I'm looking for at the first stage of the funnel: LinkedIn (more specifically if we know anyone in common who can endorse you, and your recommendations), and your OSS profile. The only thing I use a CV for is to look up your contact details.
The next stage is all about 1on1 conversations and pairing sessions.
Probably that's how "there is huge programmers shortage!" myth starts. I don't use LinkedIn and will never use it as any other products that rely on dark patterns and disrespect for privacy. Problems with OSS I've written in my other comment. And I'm really not in minority -- most of very good programmers I know are like this. So sorry, but as a requiter you are only doing disfavor for yourself relying on minor pool of candidates.
The value isn't the commit history, the value is the network of people you build up while creating the commit history. That network doesn't evaporate when you change jobs. That network will likely help you land your next job.
I see having a great public profile more as a sufficient condition than a necessary one.
Meaning I wouldn't rule out someone if they didn't have a good public profile, but it could help the person if they did have one.
I use GitHub only to see if someone has a side project and their interests. Never to judge their code quality. I use GitHub to store code when I'm experimenting or teaching someone else.
I'm concerned that many programmers who use mostly OSS (e.g. web developers) never submit a single patch to any of the multitude of projects they benefit from. Clients save millions of dollars because dev agencies leverage tons of free/open-source software. If programmers do a proper job they should routinely come across bugs or incompatibilities in at least a few of the myriad gems, node modules, etc. What could be more natural than for the developer to fix the bug and send a pull request back to the maintainer?
When looking at candidates I almost always find some correlation between a meaningful public commit history and quality.
I'm not so sure about this. My experience with contributing to (smaller) OSS projects on github have been mostly positive. However a few projects won't review/merge patches possibly because they've been abandoned.
This article frames the question rhetorically. Of course we should not disadvantage gifted children by depriving them of tailored learning strategies etc. Why on earth would we even consider it?
But it's not so easy to define what this means in practice, particularly in the UK where the debate over selective schooling is bound up with issues related to class and wealth.
For example
Needed to apply the same change in a few places.Also found
doesn't work if the videos has for example en-CA as the subtitle language.And finally, youtube-dlc seems to inconveniently discard the VTT file, breaking glancer, unless you specify `-k` to keep the file.