Comment by zamalek | Hacker News Reader

Comment by zamalek | Hacker News Reader

> I ran 50+ miles a week. I pushed myself to excel. To excel within the boundaries of the time and life-balance I had set for myself.

Part of excelling at your job is learning new stuff - something that I am absolutely certain you do all the time, even if you only do it during work hours. Maybe this week you are starting a new project and need to learn Vue.

Publish those 100 lines of code to GitHub. Just like that you've demonstrated that:

* You are willing to learn new things.

* You know how to use a little Vue.

* You know how to use a little Git.

Make it clear that it's a learning project - call it "Learning Vue," "Learning C#," "Learning Node" etc. When a hiring manager looks at your profile they will see dozens of technologies that you have at least some experience with.

Edit: if they turn around and demand side projects; you would be completely correct to ask about how many office hours they allocate to side projects. Interviews are a two-way process and the more you stick your neck out, the more you get noticed.

Better check your employment agreement. My company owns what I write on company time, I don't have the rights to just "put it on GitHub", and yes, I take that seriously.

Ditto. At my current place my employment agreement doesn't allow me to publicly post code I write in spare time.

My previous employer was a defense contractor, so... yea.

I don't have any side projects that I can share. Sucks, but that's the reality. If I get fired/quit and can't find a job without side projects, I have a list of things in my head to build in ~months if that's what becomes necessary.

You should, because it's absolutely grounds for termination at many companies.

You shouldn't put _actual_ work code you wrote on GitHub, but you should write your own small sample programs that demonstrate you know how to use a certain library that you just learned, and then you have it as reference code for yourself later and it shows you know a specific technology.

100 lines of code is not a meaningful amount of experience with anything, and surely cannot provide any meaningful advantage over the lifetime of a serious project compared to another developer who starts fresh.

Having "dozens of technologies" at this level of experience is often a bad sign. Very frequently candidates who mention lots of technologies like this on their resume or github can't answer the simplest questions about them, even "why should I use this, what problem does it solve". Source: Years of interviewing people with a laundry list of technologies on their resumes.

Should people be expected to remember everything about all tools they've ever used? No! Is trivial experience with something useful? Probably not.

This kind of thinking is why most of my "side" projects aren't on Github. Sometimes a new algorithm or technology I hear about peaks my interest, and I spend a few hours playing with it. But in the end, I don't have something I would be proud to show or that properly showcases my skills, and so I don't want people extrapolating from that.

Then again, I don't claim to be an expert in these skills, and don't put them on my resume, which seems to be more what you are referring to.

100 lines of code is far, far better than zero, and this thus quite meaningful. Mathematicians can write proofs shorter than that and demonstrate mastery of their craft, and programmers can demonstrate basic competencies the same way.

> if they turn around and demand side projects; you would be completely correct to ask about how many office hours they allocate to side projects.

^^^^ This

Take any other profession and apply the same - see if it makes sense.

Architects should have side projects they can show.

Mechanical engineers should have side projects they can show (e.g. modifying cars, robotics, etc).

And so on.

Reply on news.ycombinator.com