Our industry has these polar ethos that are pretty deep: one group sees old product that has stood the test of time as an indicator of quality. Like "UNIX has been around over 40 years, it clearly did some things right." The other, and it's insanely popular right now, thinks that anything that is too old clearly has some damage and its no longer good technology, like the neovim crowd, "vim doesn't even use the newest C standards features.." Some times you have to believe that you're doing something different and everybody did it wrong before and that's while you'll succeed this time, that's how you take the risk and ignore the downsides. being old can be a detriment to that belief.
There are young people who will only use the tools they are comfortable with. Ageism is the mistaken belief that this is somehow associated with your most recent birthday, akin to astrology.
Honestly, if you find and older person that wants to work at a startup, there is a good chance that they could be doing a few things right to have that energy and drive. You want to know how they live and what they do.
Answer: "If you're good and VC's like you, I'll be working with you on your third startup by then."
Yet if you admit that, it counts as a mark against you while being hired. It is one place where those hiring are outright ignoring reality, and instead prefer that everyone pretends we are making life long arrangements. Anything that breaks the playing pretend game counts against you; be it honestly stating you think there is a better chance than not that you'll have moved on in 5 years or being of enough age that the interviewer thinks you will retire within 5 years.
Almost everything I've written professionally in my 15 year career so far is closed source and not going to turn up on Github.
Also isn't programming one of those fields.
That said, she definitely has something to share - if not open-soruce hobby projects, then at least interesting stories from jobs she did and battles she fought. I'd love to read such account.
So now a professional programmer also has to program as a hobby too? Doesn't that set the bar a little high? What if your 'hobby' code is also closed source because it's for a side project?
What if your hobbies are thinking hobbies but not programming? What if your 'building stuff' fascination is more multi-faceted than just software?
I get that GitHub is great for employers because it allows them to evaluate a person's chops, provided that they have a substantial enough body of code published. But that only works for people who have some way to publish their work or personal code. Not everyone does that, nor is it practical to expect everyone to do that.
What kind of argument is it that an employer has the bar 'set too high'? Put yourself in their shoes; obviously you're going to hire a photographer/contractor/programmer who can show off a portfolio over one who just talks about it. It's silly to suggest otherwise.
I hear what you're saying of course, the easier a person makes it to have their work evaluated, the easier they will be hired.
But I think it's obvious that there are a great many good programmers who do solid work but don't program as a hobby too, and whose professional work can't be released because it's proprietary.
What I'm suggesting is that the notion advanced a couple of comments up of "everyone can have stuff on GitHub" isn't realistic for a variety of reasons and I tried to touch on what those reasons are.
EDIT: I of course agree that an employer should be able to set whatever standard they want to hire people, too. What I'm suggesting is that it's not really practical for every employer to hire to this standard.
No. There is no should or should not, there is and is not. And the 'is' of the matter is that a candidate with a portfolio will be ranked higher than a comparable candidate without. That is only one factor, and other factors can still override that factor. And sometimes, you may be applying for a job where no programmer with a portfolio has applied.
I see no problem even if every employer wanted to use this standard, as long as the employer realized it was only one factor of many and not some gold standard.
If they want to get hired easily, yes. (NB: I don't have any code up on github)
Hiring sucks, interviewing sucks. Existing code on GitHub - which can be discussed makes it easier. It creates an online reputation that an interviewer can judge you on without asking 20 extra questions. People are people and are going to take the easy way out rather than come up with good ways of interviewing people who don't have their hobby projects online.
That was part of the employment agreement I had to sign when I worked at a large electronics/telecom company a number of years ago. So anything that could have been put on a public facing site (including technical articles) was not allowed. Of course, you could get a waver for individual projects but that had to be granted by I believe a VP level employee. Oh, and if you were to seek out that permission, unless you were already a superstar performer, you'd hear thing like "How do you have time for these side projects when you are behind on xyz project".
Nights and weekends ?
TeMPOraL is correct that by "field" I meant "websites" or "ASIC design" or "CAD software" or "embedded". Even at my previous employer (small consultancy), only one of 10 of us had a github with anything on it. Currently I'm in an environment with technologies like MFC and Borland Delphi.
I have >8000 HN karma and >17000 electronics.stackexchange karma. Can I trade these internet points for job offers? Possibly the latter.
I do have a bunch of war stories ("linux upgrade escalates into needing to solder a floppy drive", "three ended ethernet cable", "structured exception handling isn't", "how many managers does it take to change an SSL certificate"), but like most people I'm not Richard Feynmann and don't think they'd be entertaining enough. I'll talk about them in interview if relevant.
(I'm hoping the 99 in your username is a disambiguation number like mine and not an age like some people's!)
I see two reasons:
1. Your employment contract forbids it. My previous job had a stipulation that they reserved all rights to any related outside work and until permission was explicitly granted by the CEO who deems it is unrelated, no code written during your employment could be released. It sucked. It was part of the reason I left. But those types of contractual requirements exist
2. You don't write code as a hobby. This is me. My GitHub has a Redmine theme fork that I maintain for our installation and a simple project written in ArnoldC because it's ridiculous. I don't leave work and immediately go work some more. I'm already putting in 45-50 hours a week. When I go home, I want to read, watch TV, go to the movies, play video games, blog, etc., not code. As far as I am aware, this is common on my team. I think only a single person has anything of worth in their GitHub and several employees don't have accounts at all.
The growing trend of seeing "GitHub Account (Required)" on job applications is worrisome. Yes, it can be a good indicator if they use it, but a lot of people don't. A lot of people can't. A lot of people simply do not want to.
Point being, even if the person has open source code, it's not necessarily an accurate reflection of the work they will do for you.
The general point I wanted to make is that it's much easier to make the age discrimination case if the person in question is doing all the same things that people who get hired do. Maybe all her work is in COBOL and no one wants to hire COBOL programmers. If you are a master and a sage etc. and you can't find a job, and you don't know to throw some stuff on GitHub or otherwise signal that your skills and practices are modern, you might be out of touch.
(I work for Google, which I assume is not what you meant by "little world", and haven't touched my GitHub profile for years, FWIW.)