Are You A Bad Developer If You Don't Take On Side Projects?
forbes.com
forbes.com
i'm currently back at a far less exciting enterprise job, and made it to every baseball game this year even though they started at 5pm. you only get one short chance at being their hero, so better make the most of it.
i haven't coded on the side in a long time, but look forward to doing so soon w/ my oldest now going into 1st grade. whatever i code will be for/with them.
As my youngest goes from 0-1, I've been working lots of projects via my own consultancy. I look at him and can't believe how much I've missed. I'm currently shifting gears to get back to focusing on my family. I'm still new at this, but it's pretty clear programming/career is so far below family in importance, I need to adjust my life accordingly.
You will be a better developer if you code more. You will be exposed to more languages, tools, people, and ideas.
If you don't code in your spare time, but you are happy where you are, don't feel like you are a bad developer, you just will not be as good at development as you could be. It is your life, why does it matter if you prefer to paint paintings at night instead of code? If you don't need to maximize your future revenue, don't feel bad.
If you want to be a better developer more than anything, then you should code. If something is stopping you from doing that, remove the blocker.
Personally, I don't hire anyone if I can't see code samples. 95% of the people I hire have their code samples on Github (not in a .zip file). So make sure you have some code samples available, but it doesn't have to be a side project or open source work.
I can't be the only person on Github that uses it primarily as a junk drawer full of bad implementations and abandoned "projects" that were more quick and dirty personal itches. Sometimes I'll contribute to random OSS, but the vast majority of GH for me is just a place to store random ideas, many of which were just toying around with some new tool or whatever and would never see the light of day in production without given much more thought.
Honestly, if you want to see code samples, you're probably better off watching the person work through a problem. Give prospective hires a project. Whether its as simple as fizzbuzz or as difficult as a trial week is up to you, I suppose.
And yet, many potential hires are judged by their facebook posts[1,2], tweets, blog entries, and anything that can be found in a google search. All of this amounts to methods of elimination. You can treat it like a portfolio, but an active github account is just a cheap way to filter out possible negatives.
It is also good to mention that, unlike writers, a lot of programmers cannot show their previous work, because it is the private property of their current/previous employer.
[1] http://www.forbes.com/sites/kashmirhill/2012/03/05/facebook-...
[2] http://www.wired.com/threatlevel/2013/01/password-protected-...
I'm torn. Do I leave it up there to show that I enjoy learning new technology in my free time, or do I take it down because it's not coded in the professional quality I hold myself to at work?
More than what? The highest earning programmers I know have never heard of github and would never consider using it.
You will be a better developer if you code more. You will be exposed to more languages, tools, people, and ideas.
You will be a better developer if you deliver more. "More languages, tools, people, and ideas" can just as easily dilute your focus as improve your skill. To get better, you must focus on results, not activity.
If you don't code in your spare time, but you are happy where you are,
Why do you assume these 2 are mutually exclusive? I know lots of excellent programmers who deliver more before noon than most deliver all week. Nothing wrong with being excellent during working hours and doing something else in your spare time, like perhaps, enjoying your spare time.
If you want to be a better developer more than anything, then you should code. If something is stopping you from doing that, remove the blocker.
If you want to be a better developer more than anything, then you should deliver production quality software. Sometimes the "blocker" is a distraction. Distractions can be other things that masquerade as "side work".
Personally, I don't hire anyone if I can't see code samples. 95% of the people I hire have their code samples on Github (not in a .zip file). So make sure you have some code samples available, but it doesn't have to be a side project or open source work.
Personally, I never show code samples. I'll gladly go through the right company's process, including coding for them. But they don't get to see anything I've ever done before out of context and without proper permissions. And personally, I will never work for anyone with hard and fast rules about hiring. 3pt14159 is choosing to not consider many of the best programmers who refuse to show their underwear. His loss.
Honestly edw519 you are being pedantic. The highest earning programmers I know made billions of dollars starting a company and now no longer program. The outliers don't matter because most people are not competent enough to be an outlier. And that is ok. It is OK to "just" earn $200k / year at 27 years old working a 8/9 to 5 job. If someone follows my advice, they can easily achieve that if they want to.
> You will be a better developer if you deliver more. "More languages, tools, people, and ideas" can just as easily dilute your focus as improve your skill. To get better, you must focus on results, not activity.
I completely disagree. I hand rolled ASP (pre .net) code for 4 years manually stitching things together. No. Production on its own once you stopped learning doesn't matter to your personal development. I became much more productive once I switched to Ruby/Python.
Results mean coding up another pricing page for yet another A/B test.
> Why do you assume these 2 are mutually exclusive? I know lots of excellent programmers who deliver more before noon than most deliver all week. Nothing wrong with being excellent during working hours and doing something else in your spare time, like perhaps, enjoying your spare time.
Why do you assume that I assume that they are mutually exclusive? I said essentially "If X and Y then Z" someone could code in their spare time, and be happy where they are (coding is self fulfilling for its own sake). But if someone is not happy where they are, and they are not coding outside of work then I think they should start coding after work. This is not exactly a ground breaking opinion. If you are sick of working at a souless jquery job, learn a more productive language on the side and get moving.
> If you want to be a better developer more than anything, then you should deliver production quality software. Sometimes the "blocker" is a distraction. Distractions can be other things that masquerade as "side work".
I agree that this could happen, but more often the opposite thing happens. People come to work, check out, and slowly stop caring about learning because every day they are doing the same thing and working on small problems that don't really matter (like making a stupid parallax effect because the marketing guy wants it). Usually people could be more productive and be paid more if they understood more productive technologies.
> Personally, I never show code samples.
Well ok. Put yourself in my position. You get 1000 resumes a week and 58% of people exaggerate or outright lie (I know MySQL, can't do a basic join clause) and 40% are completely unqualified. Now, I put in a very basic requirement. Send me code sample or a link to your github. 100 resumes, half of which have horrible, horrible, horrible code. 45 of which have decent, but not amazing code, and 5 of which have outstanding code.
I've yet to interview someone that had amazing code and turn them down for the job. I went from rejecting 8 or 9 out of 10 people in an interview to 1 or 2 out of 10 (depending on the position).
Code isn't underwear. Code is a product. You don't hire photographers for your wedding without seeing their work. You don't give production keys to people that don't know what a hash table is. It is that simple. Not my loss. The rest of you are the crazy ones and in the long run I'll be proven right.
This is a pretty bizarre position. Don't you have any code that's carefully prepared and that you think represents your ability to at least write clean code? And wouldn't you rather show a potential employer that carefully prepared code than trying to whip something up on the spot?
Also, a lot of things like showing off your chops at configuring complicated builds with, say, maven or ant can hardly be demonstrated in an interview or an overnight coding assignment. You need to have a nontrivial project prepared to show that you can write a nontrivial project.
Further, contributing to open source projects (outside of what I do for my employer) is also problematic, because nearly all the things I'm interested in/expert in are very related to what I do for my employer. Figuring out what is and is not work product and what I can and cannot release is a hassle I just don't want.
Seems like your rule and your reliance on GitHub is a very narrow filter and you are likely getting a very narrow subset of potential applicants.
On the other hand, if you're a startup CRUD hacker, your potential employers are much more likely to expect some personal CRUD projects in your github, since 1) that's easier to do than personal quant/sec/whatever work and 2) there are likely a lot more applicants for such jobs, so they can afford to filter for "hustlers"
A. From a legal standpoint, AFAIK (IANAL), things that fall under the same trademark code are considered to be one industry. I have said this before in various discussions forums and while I am open to hear that I am wrong, no one so far as told me so. This means that "Computers, software, electronic instruments" are considered to be one industry [2] from a legal standpoint.
B. Even if the OP or you feel that you are in a very different industry, you/OP need to check your contracts for such IP issues before concluding that you do not have the same issues.
[1] https://news.ycombinator.com/item?id=6245738 [2] http://www.tmweb.com/trademark_classes.asp
If someone has side projects on Github, it may reveal something (good or bad) about their coding skills [1], but it also reveals, most probably, their lack of understanding of legal and IP issues [1]. (It may in principle be telling about their risk-thresholds if they were aware of the legal issues and still took the risk, but this is not the most probable case.)
In various discussions I have had on the topic, even companies who otherwise are open to their employees having side projects nevertheless block them from the same in their employment contracts. In other words, if it all goes well for the company, it's fine, but if things go wrong, the employee may be under a big trouble.
[1] While telling nothing on this front, good or bad, about the same for people without such side projects on Github or elsewhere.
Being based in California, I am well aware of the laws specific to here also (though IANAL). After having read two books on IP laws, I totally agree with what this lawyer told you -- not to sign. If you were to sign, there are plenty of things there that prevent you from having side projects and moonlighting even if you are in California.
A question: So did you join the company without signing it? What was the reaction of the company? Were they just OK? I know of cases where not signing meant refusing to accept the job. I also know of one case where they allow you to not sign it, but then also bar you from receiving any sign-on and performance bonuses while you are with the company (i.e., you get only the basic pay plus benefits, no RSUs, cash bonus, etc.)
Thanks.
A majority of people who are aware of their employment contracts report having these issues and cannot legally have contributions to open source or side projects on their Github profiles [1]. I extrapolate from that that those who are unaware of these also are legally-speaking bound by their contracts for these contributions. I still see this rising use of Github profiles to tell good developers apart from bad developers. There was a huge thread I had started on "Startup Engineering" Coursera discussion forums on this topic itself that generated over 50 replies, several new data-points, and also over 20 down-votes for me ;-)
[1] Unless they have appropriately written permission from their employers of course...
I've stopped interviewees during an interview when I felt like they were treading on what we would consider protected work product.
It is entirely possible I can't pass your technical interview, but I'd be surprised if everyone in my industry couldn't, and they are all as restricted as I am.
Finally, I hope that is a typo. Asking for 10k lines of code is beyond the pale for anything I've ever heard of. If you want 10K lines of my code you better be prepared to pay for it.
>> If you want 10K lines of my code you better be prepared to pay for it.
+1.
I do not mind someone having me write code on a whiteboard during an interview. Asking for 10K lines is indeed out of question since this would invariably be code I have developed for a previous employer. I am working on my own startup now and still won't show 10K lines of code to protect the startup's IP!
There have even been a case where a colleague pulled out code he had written at previous employment for use in the current employment. We blocked him from doing that.
> You will make more money if you have an active github
> account.
I highly doubt this, but I'd love to be proven wrong.There's also a downside with sharing too much information about yourself without being present to answer questions or provide more context: It lets an employer discount you as a potential candidate simply because of their misunderstanding of your work.
As evidence, refer to the "n projects on github have SQL injection security flaws" articles that show up here occasionally. But we all know that when you're just hacking around on something for fun, you might write code like this. The point of your project might have been to quickly demonstrate something cool, yet it can be used to demonstrate that you lack security awareness (even if that's not actually true.)
I'm not making any judgement about the value of the profile, but in my corner of the world it doesn't seem very important or even common.
This is simply not true. Some developers will improve the more they code under the right circumstances. Others are sort of like the person at the gym who has bad form that, for one reason or another, is never corrected. For this person, more exercise is actually detrimental.
This can't be true if you count all the programmers working in the financial industry.
Would you be comfortable with the candidate that would put a brief description on CV and bring a laptop to the interview to show it?
"remove the blocker"
That mean to me either dropping the SO or not doing my house chores.
EDIT: fixed typo
[1] https://www.linkedin.com/today/post/article/20130620142512-3...
> I do attend (and give) technical talks; and perhaps most
> importantly, I pick my day job based on learning and
> growth opportunities: which company I’m working at, which
> team I’m on, and which projects I take on. I stumbled
> onto this a little bit by accident, but I discovered that
> responsibilities in your day job that require you to
> learn are a great forcing function for learning.
I think that this is the nuance of the article that the headline simplifies away. I think we often look for side-projects because they are an indicator of ongoing learning and they demonstrate expertise. They are by no means the only way to show these things to a prospective employer. Giving presentations, writing articles, being able to discuss industry trends intelligently... All of these things count too.[1] https://www.quora.com/Software-Engineering/Are-you-a-bad-dev...
Instead, it should be like a carpenter that does their own home renovations, or an accountant who uses double-entry book-keeping for their personal finances: they're using their work skills in their personal lives. That's like a developer who makes up a tool to keep track of errands in their house, for example.
Or, it should be like a technical writer or copy writer who writes short stories in their spare time. That's like an application developer who writes games in their spare time.
In none of these cases would you think that an carpenter who hires professionals or an accountant who just does normal budgeting and so on or a writer who writes only at work must be bad at their jobs. Why should it be any different with programming?
BUT, and this is a big BUT, having multiple personal projects does make you much more marketable to potential employers.
If you don't have a well known University or a well known company on your resume, having a stack of personal projects that show you're constantly learning, that you're passionate about the programming and that you love what you do can mean the difference between getting a request to interview at a start-up vs. getting put in the "pass" pile of resumes/profiles that internal recruiters have to look at.
This especially holds true if you work at a large, enterpris-ey company (IBM, VMWare, Goldman, Delloite, etc.) and want to attract the attention of, and get a job at, a venture funded start-up based on our experience at DeveloperAuction.
In my case I'm trying to get out of a consultant role and more into a development role. Said company forbids me to share things I have done internally. My only option is to start doing side projects. I understand that an employer needs a way to make sure you can do what you say you can do. The only choice I have right now is to sacrifice my personal life to develop some projects I can share, look for another consulting role (which I don't want), or suck it up. The problem is the longer I stay the more out of touch I become with the development world. It's like a big trap.
What I find with side project developers is a certain self-directedness that bodes well for the kind of employees that can thrive in a pure startup environment. The kind of thinking it takes to go ...
"I have this problem, Heck, I'm going to hack something together that does what I need"
or
"this open source tool I use is missing this one feature, I'll just code it and send in a pull request"
Then actually take time out of your life to code it up and put it out for use and, even better still, maintain it over a period of time.
That tells me that such a person will have no trouble figuring out what they need to do if they go to work for a startup that they're passionate about. It tells me that they'll usually be the kind of people to drive initiatives at bigger firms if they don't lose patience with the politicking, red tape and glacial pace of things.
Now, this DOES NOT mean that developers who don't do side projects won't possess these traits as well. Its just that the signal is clearer with the side project types. In the end you still have to go ahead and find out if they're actually good engineers before you hire them
It particularly struck me that HN very recently had an article that kicked off this exact debate.
What a sad state of affairs, although the full advert splash and the junky "similar" articles give that impression too.
Our clicks are providing positive reinforcement for Forbes' blogspam and I'm surprised that HN hasn't banned forbes.com yet.
The authors are asked individually if they want their answers to appear on Forbes and receive no compensation.
http://arstechnica.com/information-technology/2013/08/how-ea...
I will give you that the Ars series is edited much much better than this one-off from Forbes
Are you a bad writer if you don't write on your own time?
Are you a bad carpenter if you don't craft on your own time?
No. You can be an excellent, professional .+\. But it's very rare to see someone at the top of their field who isn't passionate about their vocation. I haven't heard of many rockstars who started playing music for the money.
Software's in this weird spot where it has some qualities of art (creative, inspires "passion", we expect people to do it without getting paid) and some qualities of a craft (it pays)
The big problem that I see with questions like these is that it presents a false dichotomy of "bad" vs. "good" developers. Not only is this a false dichotomy, but skills aren't even one dimensional, so even considering them as falling on a spectrum is wrong.
I'm certain that there exists some task that would take me 10 hours that would take my co-worker 1 hour, but there also exists some task that would take him 10 hours and only take my 1 hour.
They are important in a careers way though. Not so much because 'you need code samples' - there is a skills shortage you know. It's more that at large companies, you learn to be a Facebook Programmer, rather than a programmer. Goldman Sacs apparently have their own private programming language.
Side projects let you do things that are not your job. That is why they are fun (rather than more of the same). Some places, programmers never get to decide what they build (they get a list of features). Some programmers are 'test engineers', or maintenance engineers, and never write greenfield code. A lone inhouse programmer in a non IT company might enjoy working on opensource stuff and actually talking to someone about what they write.
And you do need that. I've work with plenty of C++ people who have never touched a dynamically typed language. One day they will need to - the world always moves on faster than your team.
After a while, I figured I would take a year off and not do any side projects and focus on building my skills. I built more stuff in that year then I ever could being shackled to something which I would never learn much from.
I never looked back after that first year. I continue to learn faster and pick frameworks, techniques and languages far faster than I ever imagined.
What's the downside?
- Maybe not putting a few thousand tax free American dollars back in my pocket.
What's the upside?
- Spending more time with my family since I can learn on my own time and at my own pace without any deadlines looming.
- Learning things that are interesting to me.
- Building things I think are cool - not what somebody else thinks they want. Like having Comic Sans in their company logo.
- Staying on the cutting edge of my industry without falling behind.
This cuts into hours that could be used for work or family or fun, and probably won't succeed because their heart isn't actually in it.
You are a good developer if you make stuff that helps people. Not if you have an impressive résumé, not if you make a lot of money. Not even if your stuff is really technically impressive or shows off IQ or promise.
Really, that's important. There's a lot on this site about being the cleverest, the fastest, knowing more comp sci than the next person or handling trickier interviews or proving there's something wrong with some other ecosystem, program, language, etc. Sometimes I'm not sure everyone feels they have a job to do that can improve people's lives.
Whether sideprojects can sometimes help you reach career goals is a more appropriate question. For applicants I think there's an initial threshold of whether they can ship nontrivial stuff. They can demonstrate it with their past jobs or by actually building stuff. A sideproject could certainly help you get hired if you have no experience and the credentials aren't getting you there; it might be smart to do if you're having trouble finding right work out of college, say. Likewise, it might help you show you have potential in a radically different specialty that your past experience has no bearing on (e.g., you used to write Ruby on Rails but want start to writing code for microcontrollers).
And if someone has unrealistic expectations about how much of a rockstar you need to be, maybe you don't want to work for them. If a potential employer wants you to have a github account that shows you spend all weekend every weekend hacking, maybe you dodged a bullet when they didn't hire you.
I say this having just taken a bunch of time to build a side project. It was fun and stuff (building from scratch instead of tweaking a giant codebase! learning golang! making things go fast!) but there's no possibility in my mind it makes me "better" or I'd be "bad" had I not done it.
I envy others their limitless energy.
Notwithstanding the fact that working "with a lot of teammates on a large, complicated codebase with evolving and expanding product requirements and scaling it up and maintaining it over time" is not necessarily what "software engineering" entails (or should entail) at every company, I actually think this is why a lot of developers take on side projects: being able to design and build something of one's own using the technologies of one's own choosing can be a lot more satisfying than refactoring code and putting out fires for 8+ hours every day.
Obviously, developers who are adequately stimulated and satisfied by their day jobs probably have less incentive to indulge in side projects, and there's nothing wrong with that, but most people in the industry know that engineering jobs, even at the hottest or most prestigious companies, often leave something to be desired.
Are there great developers who just code 9 - 5? Yes. Are there great developers who code in their own time? Yes. Are there terrible developers who just code 9 - 5? Yes. Are there terrible developers who code in their own time? Yes.
Doing stuff in one's own time - or not - isn't any substantive determinant and we shouldn't try to make it so.
I don't have side projects. My one main project is all consuming enough that side projects would be distractions. The only distractions I can afford are enough to keep my live/work balance so I don't burn out.
It's hard to know whether a developer is good or bad with only a resume/interview. If you're looking for smart motivated people, the ones who tend to work on side projects etc. can actually show you stuff they've built, and generally you can get a good idea as to how/if they'd fit in with your company/start-up.
While this doesn't mean developers who don't take on side projects are bad, it's just hard to identify whether they are in fact good or bad.
When I have had to interview people, there is the technical abilities that are pretty easy to get through. What I prefer, when trying to find out something about the person, is to have them talk about a passion or something they enjoy. For some, that is coding, for others something else.
I think there are plenty of jobs that wont weigh side projects too heavily, as long as what you are working on for your job is awesome. I also think there are companies who like the modo I suggested at the top, and are looking for someone who loves to hack away at projects
I try to enjoy the little time I do have with friends and family.