Lately, I've been wondering how I could preserve my work to showcase in the future. I don't think it's always practical, or legal, to assume keeping a copy of the code is a good showcase. And screenshots are, well, shallow.
Anyways, I was curious if any of you have done the same? And what route you took for preserving your work.
EDIT: I'm not just referring to interviewing purposes. I think in general it would be great to reflect back on the things you've done from time to time. Who knows where you'll be in 20 years, but in a digital age it seems desirable to keep some kind of log of what you've done of the course of your career. Perhaps the word, "showcase", was a bad choice.
EDIT 2: My comment about keeping the code was poorly worded and being misinterpreted. I have no interest in keeping any former code, it'd be dated within a year or two. The heart of this question is about showcasing/archiving great innovations and cool things you've built that aren't easily available.
> I've been wondering how I could preserve my work to showcase in the future. I don't think it's always practical, or legal, to assume keeping a copy of the code is a good showcase.
I agree. I see a lot of organizations asking for open source as a litmus test for the candidate.
As a former manager who has hired dozens of programmers, I think that's stupid, because it vastly limits your pool of candidates to people who have time to contribute to open source. I've found that there are lots of very gifted people who have never worked on anything they can share. And "side projects" tend to show you what the candidate wants you to see: well crafted code that didn't have external requirements or hard deadlines. (Note: I'm not suggesting you _don't_ use open sourced code in the interview process, just that you don't use it as a gateway into the larger interview process).
Looking forward to watching this thread!
Edit: fixed a confusing sentence.
That's an interesting observation. Sadly, I feel that my side projects are of lower code quality than my paid work, since they are constrained by whatever scraps of time I have left over after making a living. I sometimes wonder if I'm doing myself a disservice by sharing code on github before it has been polished.
This is a fairly common point of view that I've come across when discussing this issue recently.
Personally, I think it's a bit of a fallacy, because you don't actually need a lot of time to contribute to open source. I find it hard to believe that anyone who is serious about their career can't afford as little as one or two evenings a year to establish some kind of online presence. Yet that is all you need to set yourself way above the overwhelming majority of the competition -- especially in .net -- who have absolutely nothing online whatsoever anywhere to substantiate the claims on their CVs or LinkedIn profiles.
The point about "side projects" showing what the candidate wants you to see is true, but you could make the same claim about artists, photographers or architects -- and you simply wouldn't hire one of them who didn't have some kind of portfolio, end of story.
The real reason why we don't expect programmers to have any kind of portfolio or other online footprint is a cultural one more than anything else. It's still so uncommon -- especially in the .net world -- that if you limited your recruitment pool to developers with online portfolios, then you'd have trouble hiring anyone. However, I expect that will no doubt change in the coming years.
(Edit: fixed sentence that didn't quite make sense)
I'm not sure I agree with that. Two follow up points:
1. I think an online portfolio is a great idea: I've hired a number of designers, too, and their portfolio is the first thing I've looked for.
The difference is a designer portfolio can include their professional work, whereas a programmer is limited to their open source contributions. I wouldn't judge a designer on their personal projects: "Hey, designer, I want to see your work, but only the stuff you've done on weekends and in the evening." It doesn't do them justice, and I'm basing my hiring decision on a subset of the work. In the same way, requiring open source contributions to gain entrance to the interview process is limiting.
2. If the programming culture required an online portfolio, that is essentially requiring programmers to have a second, unpaid, part-time job. I do not think you can generate enough great code in a few days to get noticed.
I do agree that some sort of portfolio would be handy: I just don't think an open source only portfolio is the way to do it.
As to coding chops, I think that has to be solved via asking them to code a solution to something on the spot (or perhaps in advance). That's far from perfect, but I don't think you need a portfolio, per se.
Although, if you have lots of stuff that's publicly available, that's clearly a bonus. But that's not an option for many people.
Ask me to code something beforehand and I'll excel at it, but ask me "what's going through your mind" as I'm coding it and I'll sound like a scatterbrain. I need time, low pressure, and privacy to code well.
Me too. I've had jobs where I had to work in areas with high foot traffic, lots of distractions, I could never get in "the zone" and never got any real work done. Well, looking back, I did get some work done, but I always felt like I was too distracted to focus, and it definitely took me a lot longer than it would have otherwise.
- How big was the team?
- What was your role on the team?
- Project scope / length / budget?
- Did you meet that timeline & budget?
- What kind of work? (Building new features? Maintenance? Replacing legacy project?)
- Major technical challenges?
- Lessons learned?
- Technologies used?
- What would you do differently next time?
If you can speak to all of that, it generally doesn't matter that you can't actually show off the product. In my case I can answer all of those without even telling you what the product was.
The one exception would be if you are doing heavily UI based work. Then I would think recording some screencasts might be good, and putting it in a gallery. That's not the kind of work I do, so it generally doesn't apply for me.
And also, part of my concern that wasn't well pointed out, was in some cases those previous companies may not even exist. You couldn't even "point to the company" and say I worked there, on that.
This is a non-starter. Its not your IP; you can't keep a copy around (even if its just for archival purposes).
Running a live version of old software is often surprisingly hard, as it will depend on other old software or nonexistent systems. VMs make this a bit easier, but if it's a distributed or embedded system that doesn't work either.
* Open source whatever you can. I have had the good fortune of being self-employed for the last few years (although I was also in school for part of that time), and one of the huge benefits of that was being able to open-source almost everything. (My client agreements usually allowed me to open-source anything that wasn't unique to their line of business.) Obviously not everyone is that fortunate, but it often makes good business sense to open-source internal libraries and such (more eyes on the code base, currying favour with developers, etc) so it definitely can't hurt to ask and try making a case for it.
* Take screenshots and video. Sure, maybe shallow by themselves (especially if you're not a UX/front end person) but it is a neat part of the package, even if only for yourself to review 10 or 20 years down the road. Some people have pointed out that you may need permission to take a video of the software... it seems to me that if you were working on that sort of software you'd know it.
* Keep a journal. This is helpful on a lot of personal levels. You might also want to blog, for similar reasons. 10 or 20 years down the road, it will help you remember what you did. Information from the journal can be helpful in portfolios and resumes, and you might also find yourself using your own journal down the road when you run into similar problems.
Regarding your second edit, I think turning the above information into a "showcase" probably just means building a small portfolio for yourself. Have "case studies" where you talk about what you did for a certain project/company/whatever. Or, depending on the nature of the work, you might choose more of a "memoir" style--either way, the point is you pick a few things you worked on and write about them, using your journal (if available) as a memory aid and screenshots/video/open source contributions as supporting material, if available.
If the company has public demo or instructional videos, on the other hand, you could use those.
If it's legal, make 100% sure it only has test data.
Still, it's probablly a better alternative to showing code (which is usually owned by the company).
Edit: it apparently isn't legal by looking at the sibling comments :)
It also has the disadvantage of not showcasing the back-end. In my case, most of my work doesn't show on a screen :) .
I don't know where that "3 minute" rule comes from. It smells like the "you are allowed to download these ROMs only for 24 hours" nonsense that emulator sites (used to?) say. That only increases my suspicion of this advice.
The 3 minute thing seemed to me a simple example of "keep it short to keep viewer attention".
EDIT: maybe you interpreted GP as meaning take a screencast of the code, while I am thinking of the working app?
I guess my point is try to look for resources your company puts out before trying to create your own
Call it a wash.
- mason.js-style grid of experiments and projects, filterable: http://hakim.se/ – direct links to demos
- short-description + screenshots: http://www.robbiemanson.com/
- a full blog post per project: http://www.minimallyminimal.com/
Ideally, as developers, we would have some sort of standardized process to archive the important parts of our career. I personally don't need this for future employers but with this weird fear I have that if I ever did have early-onset alzheimers, I'd want to remember at least some aspects of my life. It may be a highly irrational fear but archiving my work life in a relatively meaningful way that I may archive my personal life seems like nothing but a good idea to me. These ideas may be completely impractical in most scenarios but at least having the discussion seems like a good idea.
As a hypothetical employer, I would want my employees to feel they can share the interesting parts of their career with my company. It promotes enthusiasm, showcases important work we're doing as a company, and a host of other benefits. I'm sure there are a series of downsides I can't think of at the moment but conceptually this seems like a good idea. It's just standardizing on what really works in most situations that'll likely be the biggest challenge.
I'm not about to not do it based on someone on the internet's interpretation of IP.
If a programmer is working on super proprietary high-tech stuff like HFT, sure - but most of us are just pushing bits and most value we add is from processes and experience.
I think you should look to have a portfolio online and an active Github account.
I have 3 things on my portfolio (www.bcooke.net):
1) Side projects I never finished or am still working on 2) Freelance sites I built alone (where my good relationship with the client meant I could openly share the work) 3) Brief blurbs about the salaried roles in my career, with a screenshot
I haven't updated it in a while but it's something.
Do you have a portfolio? Is your Github active? StackOverflow? You need things you can show!
It sucks because your best work - the stuff you spent the most time on - isn't always available to share. And even if you could, there'd be questions about which part you did.
Having a site you can point to and say, "I did that" is a good way to showcase your abilities, and if all your work is owned by your employer, you should probably start thinking about ways you can change that.
Most interviewers come in with a list of questions they want to ask, so if you can talk about your work in terms of the answers you know they want, you're probably better off than a candidate who can demo a project that the interviewer may or may not care to see.
For keeping a log of what you've done, I don't think there's too much you can do about this. Part of your agreement when being hired is that you are being paid to build something that belongs to your employer. The only way around this I could see is if you were able to extract some abstract tool that could have wider use and get permission to distribute it or at least keep a copy for yourself (a lot of employers won't agree to this, however).
To your first edit, I say I do keep a log of what I've done over the course of my career. That log is my resume. I typically update my resume multiple times while I'm at a job even when I have no plans to leave any time soon. I do this to keep it up to date while projects are fresh on my mind.
Some comment about edit 2. That's what the resume is for. It's my list of great innovations and cool things I've built. For me, this includes personal projects. This is where open source contributions can be really useful because they're public and everyone can look at them. IMO open source projects are one of the most impressive resume builders out there.
2. Give the documention to your employer ( it will be greatly appreciated )
3. Ask your direct superior if you can keep a copy just for personal reference
4. Unless your superior is a jerk, this will likely be given the ok.
5. Do so ( strictly speaking this is often illegal; but if superior approves... )
6. Use said documentation to write -new- documentation based off it off work hours ( clean room rewrite of docs essentially ) ( note that depending on what you signed, even these conceptual documentation rewrites may be illegal to share; you'll need to read what you sign )
7. Give rewritten un-infringing documentation to whoever you wish
I do like some of the suggestions other people have mentioned about recording a screencast of the product (if you're allowed to do it). Its definitely a great idea, although if you're programming something in say Ruby On Rails or PHP on the backend, how can you show off code that you wrote and then refactored?
I'm curious what the more seasoned hiring managers would want to see?
Pragmatically the easiest thing might be to take your own copies of company publicity materials about the product. That way you avoid NDA problems. Technically a screen shot of the product information page from 3 years ago is infringing but not in a way that anyone is likely to care about.
I've literally stopped interviews when the applicant starts getting too close to what appears to be protected output.
If nothing else the experience itself will probably turn out to be quite healthy for your team.
I have a video of one of products I made - a virtual oscilloscope but other than that one, they are just images with a little blurb about the technology used.
https://training.kalzumeus.com/newsletters/archive/do-not-en...
These needs understanding the underlying IP law motivations.Most things like mathematical processes around things cannot be IP'd.So , can't we have an open-source implementation around the same?
