Pronking for Programmers(paulbutcher.com)
paulbutcher.com
Pronking for Programmers
http://paulbutcher.com/2014/04/20/pronking-for-programmers/
9 comments
Agree. Very much.
Not everyone has a huge body of work they can put out there in the world of FOSS for a vast variety of reasons. Of the two best programmers I know, one is active and publishes, the other is a guy you would kill to have on any team, but whose work is all in pursuit of his closed source job.
Not everyone has a huge body of work they can put out there in the world of FOSS for a vast variety of reasons. Of the two best programmers I know, one is active and publishes, the other is a guy you would kill to have on any team, but whose work is all in pursuit of his closed source job.
You have probably seen code written by the best programmers you know, and I guess you are comparing their work with the code in open source projects. As the rest of us can't see their code, it's impossible to agree with you, so we can only trust you blindly. But "trust" with something so technical is a bad criteria, and that's why open source software is good for showing your approach to problem solving and your programming style.
I think the idea of "doing open source work" sounds a bit disproportionate. At least to me. Instead, think about people sharing some small tools they have built for themselves. Even if they work for IBM, they should be able to customize their environment by tweaking some tool or writing a script to make their lives easier. They only have to share that code, not to show off but to help others with similar problems.
I think the idea of "doing open source work" sounds a bit disproportionate. At least to me. Instead, think about people sharing some small tools they have built for themselves. Even if they work for IBM, they should be able to customize their environment by tweaking some tool or writing a script to make their lives easier. They only have to share that code, not to show off but to help others with similar problems.
"Playing with your kids" is not mutually exclusive with doing open source work. Linus Torvalds (of Linux fame) is a father and so is Doug Cutting, founder of Hadoop.
"Doing research" is not mutually exclusive with doing open source work either. In fact, I think these days, I would be suspicious of a systems software research project that didn't release the code. A lot of systems software research projects use Linux or some other open source code base as a starting point, since re-inventing the wheel is not very conducive to publishing quickly.
It's pretty obvious why companies would want to look at open source contributions. They show that someone works well on a team, is motivated, and can write code. Of course, they're not ever going to be the only thing companies consider.
It's not even that they don't work on projects in their spare time. They do, but they're not part of open source culture, where people share things by default. They're satisfied with having made the thing itself, and they're not going to put their hardware or software project on github any sooner than they're going to make a website for the house they built from scratch.
How do you know they work on projects in their spare time? Is it because they shared them with you?
"Doing research" is not mutually exclusive with doing open source work either. In fact, I think these days, I would be suspicious of a systems software research project that didn't release the code. A lot of systems software research projects use Linux or some other open source code base as a starting point, since re-inventing the wheel is not very conducive to publishing quickly.
It's pretty obvious why companies would want to look at open source contributions. They show that someone works well on a team, is motivated, and can write code. Of course, they're not ever going to be the only thing companies consider.
It's not even that they don't work on projects in their spare time. They do, but they're not part of open source culture, where people share things by default. They're satisfied with having made the thing itself, and they're not going to put their hardware or software project on github any sooner than they're going to make a website for the house they built from scratch.
How do you know they work on projects in their spare time? Is it because they shared them with you?
> "Playing with your kids" is not mutually exclusive with doing open source work. Linus Torvalds (of Linux fame) is a father and so is Doug Cutting, founder of Hadoop.
I think the context here is doing Open Source work in one's spare time. And I guess that Linus does it mostly during the daytime. (I think his diving software thing has probably been done in the spare time, though.)
I think the context here is doing Open Source work in one's spare time. And I guess that Linus does it mostly during the daytime. (I think his diving software thing has probably been done in the spare time, though.)
"Hiring is so hard, so burn your free time to help me!"
Please don't contribute to OSS unless you really want to. It's great if you do. But making it a near-mandatory requirement just means that it drives yet more self-promotion (it isn't a real project unless you buy a domain!), more low quality contributions, and, ultimately, becomes yet another thing-you-really-should-be-doing.
Please don't contribute to OSS unless you really want to. It's great if you do. But making it a near-mandatory requirement just means that it drives yet more self-promotion (it isn't a real project unless you buy a domain!), more low quality contributions, and, ultimately, becomes yet another thing-you-really-should-be-doing.
It doesn't have to be contributing to existing open source projects. I always find it a bit surprising when other programmers have no code to show on Github or similar, for this reason: 1. most people who use computers day in, day out, encounter a pain point or two with the tools they use; 2. as a programmer, it seems natural to fix that pain point; 3. once fixed, it seems natural to share the fix, so that others are helped too (and that can also help post-hoc justify/rationalise the investment of time!).
You're forgetting the work that's needed to make it production (or at least more production) ready and the maintenance. A fix is often just made "good enough" for oneself in my experience. It's like sharing your dot files.
I'm not even allowed to share my my custom portfiles. I started to, but was asked to hold off; that was 2 years ago.
Legal / contract constraints may prevent people from publishing code written at work or even in their free time.
I really hope this doesn't become a thing. We don't need a bunch of perverse incentives pushing people to write open source like academics are forced to churn out papers.
As noted, it's expensive. I've encountered potential employers who were lukewarm because I hadn't done enough work in open repos to impress them. That's understandable, it is rational to tend towards "no" instead of "yes" when evaluating developers. But to me it seems strange to do open source work just to be more attractive to employers. So I guess it really is an honest signal. I'm not going out of my way to do a bunch of stuff to impress you because I already have a good job, so you could be ignoring good candidates with this mindset. But like I mentioned, some people might be OK with that.
As someone who does contribute a bunch to open source, it does make me a bit wary - I've met some excellent developers who do very little open source development and who I have learned a lot from while working with them.
Personally, I contribute to open source because I want to see things fixed and generally want to move fast since that's how I operate. Sometimes this has meant figuring out fixes myself and opening up a pull request. I see this as a way of helping projects I like move forward since they can focus less on bugs and more on feature development.
Personally, I contribute to open source because I want to see things fixed and generally want to move fast since that's how I operate. Sometimes this has meant figuring out fixes myself and opening up a pull request. I see this as a way of helping projects I like move forward since they can focus less on bugs and more on feature development.
> But to me it seems strange to do open source work just to be more attractive to employers.
Particularly if it's an employer that doesn't itself contribute to open source.
Particularly if it's an employer that doesn't itself contribute to open source.
How can someone who has time and could be that "fit gazelle" get into contributing to open source?
I have tried several times. At least, I've looked at a few of the suggestions on how to get started. All of the ideas don't quite work, though. Namely because most of the suggestions are things that I've either never even heard of or that I do not use. The gardening approach mentioned not long ago on this site seems very good for beginners - but I feel that just jumping in and starting with this could be a bad thing if the organization already has some sort of system set up.
For example, I have used Express. I don't really understand it well enough, and I've never had reason to, jump into the source code. There are only ten open issues. For just about every open source thing I've used, this is the case. Am I just doing something wrong?
I have tried several times. At least, I've looked at a few of the suggestions on how to get started. All of the ideas don't quite work, though. Namely because most of the suggestions are things that I've either never even heard of or that I do not use. The gardening approach mentioned not long ago on this site seems very good for beginners - but I feel that just jumping in and starting with this could be a bad thing if the organization already has some sort of system set up.
For example, I have used Express. I don't really understand it well enough, and I've never had reason to, jump into the source code. There are only ten open issues. For just about every open source thing I've used, this is the case. Am I just doing something wrong?
Don't force it. If the itch isn't there, don't scratch it.
Instead, look for things that are interesting to you, follow your passion; if that eventually leads to an OSS project (either your own or helping on an existing one), great! Just avoid toxic startup cultures that require forced OSS track records and then provide "unlimited" vacations.
Instead, look for things that are interesting to you, follow your passion; if that eventually leads to an OSS project (either your own or helping on an existing one), great! Just avoid toxic startup cultures that require forced OSS track records and then provide "unlimited" vacations.
There are several ways to get started and it depends a lot on your motivations and are of interest. However the main piece of advice is to jump in, dont be worried about upsetting someone system, some OS projects arent setup well for contribution and they will become easy to spot, but for the ones that are, doing something 'wrong' is a great way for a maintainer to come along and help introduce you to how to do it 'right'.
http://openhatch.org works a lot on making initial contributions easier, if you are interested in express then you dont need to work on the core framework, write a plugin and open source it, contributing is by far easier when you have a real need to do so, maybe someone will use your plugin and find a problem they want to fix, maybe you will use someones project and want to fix something.
http://openhatch.org works a lot on making initial contributions easier, if you are interested in express then you dont need to work on the core framework, write a plugin and open source it, contributing is by far easier when you have a real need to do so, maybe someone will use your plugin and find a problem they want to fix, maybe you will use someones project and want to fix something.
Contributing to open source doesnt mean only contributing to someone else's project. You can always start yours, it can be as simple as you want and about whatever you want.
I would suggest reading through the Express (or any popular project) source code to improve yourself as a JavaScript developer. As you do, there will inevitably be things you notice that should be fixed. E.g. typos, edge cases, refactoring[0]. Fixing those will help you familiarize yourself with the project, the process, and will eventually lead to bigger contributions.
[0] Though be careful with that. Only refactor stuff if you're pretty confident about how it works, and that your changes don't decrease performance or readability.
[0] Though be careful with that. Only refactor stuff if you're pretty confident about how it works, and that your changes don't decrease performance or readability.
I don't think it has to be open-source... you just need to release things.
And what's a great motivator for releasing things when working alone? It's having other people expect you to make progress on your projects. That's why I made a club that meets weekly to screenshare what we're working on.
It's the benefits of YCombinator weekly dinners, without the benefit of awesome speakers, great advice, or mentorship. But I'm there! If you want to get feedback on your projects and give feedback on other people's projects, then you should join my club.
And what's a great motivator for releasing things when working alone? It's having other people expect you to make progress on your projects. That's why I made a club that meets weekly to screenshare what we're working on.
It's the benefits of YCombinator weekly dinners, without the benefit of awesome speakers, great advice, or mentorship. But I'm there! If you want to get feedback on your projects and give feedback on other people's projects, then you should join my club.
People, please keep in mind that "contributing" is not just limited to pull requests. I would consider filing bug reports, answer SO questions, and participate in IRC to be contributing.
Is it dedication that is being signaled here, or intelligence? Open source can also be a signal that you get you work done quick enough that you have time for hobbies.
Or, to play devil's advocate, that you aren't putting in the level of work in your day job that you could be putting in. If I were an employer looking at a candidate and I saw they had huge amounts of open source contributions, the first thing I'd ask is "how did you have time for this and your day job?".
It also tells you something else about a candidate: that their previous job probably wasn't particularly hard or that they didn't have much in the way of responsibilities. If you're the lead developer on a several hundred thousand line codebase, it seems less likely that you have time to build an open source resume than if you were a junior developer.
Honestly, I think open source is a bit of a mixed signal. If the code shown in the repositories is great, then that's fantastic, but if it's merely average then I think it makes you look worse than just not having it there at all. This is really my biggest objection with open source: if you want to use it as some sort of resume, then you have to contribute huge amounts of time to it in order to make it representative of your skill. Then it's no longer an open source project you do for fun, but just a second day job. Additionally, when it gets good enough for an employer to see, what interviewer is going to have time to read through it? This problem is magnified especially when developers start treating open source as a form of resume, and interviewers have to wade through shockingly poor repositories from every candidate to determine the candidate's quality.
It also tells you something else about a candidate: that their previous job probably wasn't particularly hard or that they didn't have much in the way of responsibilities. If you're the lead developer on a several hundred thousand line codebase, it seems less likely that you have time to build an open source resume than if you were a junior developer.
Honestly, I think open source is a bit of a mixed signal. If the code shown in the repositories is great, then that's fantastic, but if it's merely average then I think it makes you look worse than just not having it there at all. This is really my biggest objection with open source: if you want to use it as some sort of resume, then you have to contribute huge amounts of time to it in order to make it representative of your skill. Then it's no longer an open source project you do for fun, but just a second day job. Additionally, when it gets good enough for an employer to see, what interviewer is going to have time to read through it? This problem is magnified especially when developers start treating open source as a form of resume, and interviewers have to wade through shockingly poor repositories from every candidate to determine the candidate's quality.
> The uploader has not made this video available in your country.
> Sorry about that.
Sorry about you, BBC.
> Sorry about that.
Sorry about you, BBC.
It's not even that they don't work on projects in their spare time. They do, but they're not part of open source culture, where people share things by default. They're satisfied with having made the thing itself, and they're not going to put their hardware or software project on github any sooner than they're going to make a website for the house they built from scratch.
If you work at an open source shop and hire with this attitude, all you're going to do is make sure that you have a monoculture in this dimension. That's not the worst thing in the world, but it filters out people who don't particularly care about open source, which is the majority of programmers. If that's a moral imperative for you, I don't have any objection to that. Otherwise, I don't see why you'd want to do this.