Start a side project, says GitHub founder (2008)(gist.github.com)
gist.github.com
Start a side project, says GitHub founder (2008)
https://gist.github.com/defunkt/6443
76 comments
Businesses always claim to value developer productivity, but this is rarely accurate. Usually it’s the stellar opposite of productive despite what they claimed during hiring.
Honestly, if they really let me take the gloves off I could easily replace 4-8 other developers. I am not saying that due to arrogance or some delusion. I just value other qualities than most other developers. Usually it’s not that I am fast or anything impressive but that the company is a drowning self-licking ice cream cone. Things get much faster when you get rid of all the framework bullshit, unnecessary process, and focus purely on business requirements and smallest possible delivery. Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it.
These are things you realize when managing a side project because your time is important to you and the person you answer to is yourself.
What’s super frustrating is how awesome that always sounds in an interview and how much the hiring team really appreciates those concerns and that level of honesty. Then once you get the job it’s just the same old slow safety mitten insanity as everywhere else.
Honestly, if they really let me take the gloves off I could easily replace 4-8 other developers. I am not saying that due to arrogance or some delusion. I just value other qualities than most other developers. Usually it’s not that I am fast or anything impressive but that the company is a drowning self-licking ice cream cone. Things get much faster when you get rid of all the framework bullshit, unnecessary process, and focus purely on business requirements and smallest possible delivery. Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it.
These are things you realize when managing a side project because your time is important to you and the person you answer to is yourself.
What’s super frustrating is how awesome that always sounds in an interview and how much the hiring team really appreciates those concerns and that level of honesty. Then once you get the job it’s just the same old slow safety mitten insanity as everywhere else.
Also the same is true for the opposite case where a framework would really speed things up but instead you have to wade through special snowflake implementation marshland leaving your own little trail of destruction for your localized tornado of changes.
Safety mitten insanity abounds.
Safety mitten insanity abounds.
I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail.
The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested.
Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions.
Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following:
1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in.
2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector.
3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code.
4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible.
After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible.
[1] https://github.com/prettydiff/wisdom/blob/master/Delusional_...
The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested.
Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions.
Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following:
1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in.
2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector.
3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code.
4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible.
After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible.
[1] https://github.com/prettydiff/wisdom/blob/master/Delusional_...
hmmm... I'm thinking from a back-end perspective as I don't work in JavaScript or front-end that much. I can see how you may encounter those types of people working with front-end stuff and I would say, yes, probably you're correct in that maybe they don't have the deep fundamentals of the raw technology outside of the frameworks.
My comment is not from that perspective though. I find in back-end land code quality varies wildly. When people get frameworks right on the back-end code quality goes way up. It can be anything from the right choice of an off-the-shelf solution to a stellar design of a bespoke solution. Good frameworks are enforcers. They pre-make a high quality set of choices and don't leave the choice up to the developers to provide wildly inconsistent implementations and sub-optimal choices. In the cases where a framework is needed and one is not in place and instead there is much code which looks the same-ISH, feels the same-ISH, is named the same-ISH, and behaves the same-ISH but is all slightly different and unique - the code quality and speed of development suffers massively.
Sometimes it's the right thing to not use a particular toy because you want to or because its cool. I agree, for sure. Hopefully, we can make high quality decisions about our code bases. For me one measure of quality is 'does this way of doing things contain the maximum amount of entropy?' If the answer is yes, then I am very much in favor. Some times there are other considerations, but that one is very, very high on my list. Good frameworks do an amazing job at that. Not all frameworks are good.
My comment is not from that perspective though. I find in back-end land code quality varies wildly. When people get frameworks right on the back-end code quality goes way up. It can be anything from the right choice of an off-the-shelf solution to a stellar design of a bespoke solution. Good frameworks are enforcers. They pre-make a high quality set of choices and don't leave the choice up to the developers to provide wildly inconsistent implementations and sub-optimal choices. In the cases where a framework is needed and one is not in place and instead there is much code which looks the same-ISH, feels the same-ISH, is named the same-ISH, and behaves the same-ISH but is all slightly different and unique - the code quality and speed of development suffers massively.
Sometimes it's the right thing to not use a particular toy because you want to or because its cool. I agree, for sure. Hopefully, we can make high quality decisions about our code bases. For me one measure of quality is 'does this way of doing things contain the maximum amount of entropy?' If the answer is yes, then I am very much in favor. Some times there are other considerations, but that one is very, very high on my list. Good frameworks do an amazing job at that. Not all frameworks are good.
> Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it.
Do you have examples of this? It sounds contrary to my experience.
Do you have examples of this? It sounds contrary to my experience.
Here are some examples:
* spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification.
* Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule.
* Rejecting code that uses functions or makes use of lexical scope instead of OOP.
* Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework.
* Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests.
* Rejecting code because the diff is intimidating.
* really long build cycles so that a developer can use their favorite framework or tool
* A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency.
---
If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue.
You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.
* spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification.
* Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule.
* Rejecting code that uses functions or makes use of lexical scope instead of OOP.
* Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework.
* Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests.
* Rejecting code because the diff is intimidating.
* really long build cycles so that a developer can use their favorite framework or tool
* A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency.
---
If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue.
You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.
I've often seen developers invent elaborate JIRA workflows and pre-checkin validation workflows that slow development to a glacial pace.
Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.
Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.
At the company I'm with, there is a 6 person team developing a nodejs app that started out as somebody's learning project / MVP through innumerable pivots (the original developers are gone). The codebase has had no significant deletioms over its five year history, only additions in the "3d chess" sense. It is a generic API server and dropbox-clone file uploader client. It requires on call attention because it blows up every time so etching unexpected happens.
Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"
Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"
I think we teach developers wrong. I recently attended a devops workshop for one of our government agencies, to share knowledge like we do in the public sector, and their setup was quite impressive.
At least it was, until it turned out that they had spent 8 people and two years making their toolchain and business processes work.
Why would you do that? We’re not Netflix, we’re a country of 5 million. It’s at times like that I like to remind myself of how simple the stackoverflow setup was (still is?), but it also makes you wonder what made it happen.
I mean, my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
Heh. On the bright side, it seems to work well for them now that they have it. A lot of other people have spent the same resources and failed.
At least it was, until it turned out that they had spent 8 people and two years making their toolchain and business processes work.
Why would you do that? We’re not Netflix, we’re a country of 5 million. It’s at times like that I like to remind myself of how simple the stackoverflow setup was (still is?), but it also makes you wonder what made it happen.
I mean, my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
Heh. On the bright side, it seems to work well for them now that they have it. A lot of other people have spent the same resources and failed.
It's not just governments. I contracted at Nike for a project that had a boatload the developers. I was on the UI team and there were 6 of us building a UI the size of which I had built (almost) alone at the previous place I worked. This isn't the developers fault, it was all because businesses are so risk-averse that they must throw a boatload of money at something because failure looks really bad. Yet they fail all the time anyways.
The only reason some businesses don't spend so much on resources is because they simply can't - they don't have the money to do so, which forces them to be streamlined and 'efficient'.
The only reason some businesses don't spend so much on resources is because they simply can't - they don't have the money to do so, which forces them to be streamlined and 'efficient'.
I am not understanding what this means:
> my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
> my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
I work in the public sector, our most expensive resource is the people who work for us.
If you have 8 people spending two years building a toolchain, that means your tool chain cost 65712 hours to setup.
In order to be worthwhile, it needs to save you more than 65712 hours on development and operations. If it fails to do that, then you’ve wasted tax payer money.
If you have 8 people spending two years building a toolchain, that means your tool chain cost 65712 hours to setup.
In order to be worthwhile, it needs to save you more than 65712 hours on development and operations. If it fails to do that, then you’ve wasted tax payer money.
The problem is that there are at least 5 or 6 different parts of your original comment that are completely lacking in context / elaboration, so that readers are left guessing about what you are trying to say. I don’t know what “their setup”, “making their toolchain and business processes work”, “the stackoverflow setup”, etc. mean, or what I am supposed to be comparing.
If you can quantify, e.g. “they spent 16 man-years working on a development process that saves no more than two weeks for each new project, and they only have a few dozen projects to use it on”, then I would have a much clearer idea of the scope, even if I still didn’t know what this process was. On the flip side, if this new process makes the difference between a high-impact future project succeeding vs. failing or getting started vs. never getting tried, it might still be worth it.
* * *
At a higher level, having people spend some amount of their professional time on public-facing work that helps more than themselves or their local organization isn’t necessarily such a terrible thing. If many organizations and individuals spend time volunteering their time to larger-scale open projects, it can end up as a multiplier for everyone’s effort.
All modern software projects (not to mention every other type of project) are built on millions of man-years of effort by huge numbers of people, most of whom didn’t recover much if any of the value they created.
If you can quantify, e.g. “they spent 16 man-years working on a development process that saves no more than two weeks for each new project, and they only have a few dozen projects to use it on”, then I would have a much clearer idea of the scope, even if I still didn’t know what this process was. On the flip side, if this new process makes the difference between a high-impact future project succeeding vs. failing or getting started vs. never getting tried, it might still be worth it.
* * *
At a higher level, having people spend some amount of their professional time on public-facing work that helps more than themselves or their local organization isn’t necessarily such a terrible thing. If many organizations and individuals spend time volunteering their time to larger-scale open projects, it can end up as a multiplier for everyone’s effort.
All modern software projects (not to mention every other type of project) are built on millions of man-years of effort by huge numbers of people, most of whom didn’t recover much if any of the value they created.
Likewise, I have no idea what this means:
> We’re not Netflix, we’re a country of 5 million.
> We’re not Netflix, we’re a country of 5 million.
From a cursory look at his comment history, he's located in Denmark[1] and works in the public sector[2].
1: https://news.ycombinator.com/item?id=19412779 2: https://news.ycombinator.com/item?id=19419308
1: https://news.ycombinator.com/item?id=19412779 2: https://news.ycombinator.com/item?id=19419308
[deleted]
We don’t need a massive operations setup when a single IIS instance can handle every citizen logging into X and not flinch. Yet more and more people are building a setup mirroring big players like Netflix.
My point was that it might be a waste of resources to build something you don’t need.
My point was that it might be a waste of resources to build something you don’t need.
autstincheney, it sounds like you should quit your enterprise (big tech co?) job and work for an early-stage startup.
That does sound exciting.
I reached this conclusion embarrassingly recently, after a few attempts at increasing productivity rapidly that were not well-received by coworkers.
Having thought about it more, it makes sense. Businesses are generally not paying developers by the hour, so why would they care about productivity when they can just pressure people to work extra hours, pretend it's a one-off crunch, make vague promises of future remuneration, or bring onboard inexpensive junior developers to work through their low-productivity processes?
Having thought about it more, it makes sense. Businesses are generally not paying developers by the hour, so why would they care about productivity when they can just pressure people to work extra hours, pretend it's a one-off crunch, make vague promises of future remuneration, or bring onboard inexpensive junior developers to work through their low-productivity processes?
Definitely a consideration. For me, my side project has basically replaced my TV time at night and it's been a significant life improvement. Sometimes I'll sit in the living room with my family and work while they watch TV, which still feels like quality family time.
Yeah, I just cut my gaming time. It has actually been a net benefit to time with the wife, because instead of being holed up in my office with my desktop computer, I'm on the couch with my laptop while she watches TV.
I do the same thing. Luckily, my desktop is in the living room, so I don't have to work on a laptop.
Yes, because that counts as spend time with the wife
We talk about what she's watching and what I'm working on. It's not like I put headphones on and ignore my surroundings. And it's definitely not the same as being in two completely different rooms with little to no interactions.
I don't think you can work and spend time together at the same time. Can you text and drive? :)
what counts is between them, and doesn't require the approval of internet randos.
time spent around the wife counts dude
This dude is downvoted but definitely just hanging out with your spouse counts. The availability and comfort of physical presence is a thing.
It isn't all the big moments. There's definitely a lot more of just time spent together.
It isn't all the big moments. There's definitely a lot more of just time spent together.
So, the guy cut on gaming and working late at the office to be able to do side project, which has a side effect of being around his spouse. It is better than nothing, but not something to be proud of. A side project is still "gaming", just easier to take breaks.
Of course it counts, but not as _with her_ just around, which is different imho.
Why does this apply almost uniquely to programmers, and not other professions though?
Aside from a handful of doctors giving up their holidays to work for MSF or similar overseas, nobody expects lawyers to do pro-bono work in their evenings, or teachers to volunteer spare time teaching different age groups, or whatever the analog might be.
Same with training, almost all other jobs give you time for training, but for programming learning new technology is somehow something you should be teaching yourself in your spare time.
Aside from a handful of doctors giving up their holidays to work for MSF or similar overseas, nobody expects lawyers to do pro-bono work in their evenings, or teachers to volunteer spare time teaching different age groups, or whatever the analog might be.
Same with training, almost all other jobs give you time for training, but for programming learning new technology is somehow something you should be teaching yourself in your spare time.
It's very circular. You're expected to code in your spare time because your peers code in their spare time. Your peers code in their spare time because it's expected of them.
Also- doctors and lawyers better be doing stuff in their spare time. They only get paid when they're working with patients. I sure as hell don't want a doctor who hasn't read a new study since he left medical school.
Also- doctors and lawyers better be doing stuff in their spare time. They only get paid when they're working with patients. I sure as hell don't want a doctor who hasn't read a new study since he left medical school.
Plumbers should fix clogged toilets in their spare time.
> Same with training, almost all other jobs give you time for training, but for programming learning new technology is somehow something you should be teaching yourself in your spare time.
Maybe it's your company? All companies I worked for so far allowed or even encouraged learning during paid work hours. Even an hour per day. Not something like learning a new language, but stuff like reading up on new framework/tools/architecture, how systems of other teams work or the inner workings of their programming language of choice. Basically anything that could proof useful later.
Maybe it's your company? All companies I worked for so far allowed or even encouraged learning during paid work hours. Even an hour per day. Not something like learning a new language, but stuff like reading up on new framework/tools/architecture, how systems of other teams work or the inner workings of their programming language of choice. Basically anything that could proof useful later.
This is very true. I have a colleague who is changing careers and while his lack of knowledge frustrates me from time to time, he is willing to learn, but instead of reading git manuals and bash tutorials at work he had made a deal with management, that he will do overtime now so that he can go home earlier to learn that stuff. And it's all the most basic stuff without which the colleague really wouldn't be able to do their job. (I would honestly not have hired them for their current position but I can't judge).
I think programming as a career path tracks the expectations of other "passion" careers. You're expect to be involved in the field in your spare time, all the time, and risk very real burnout. My first thought is writers- a writer that doesn't read and engage in the literary sphere in their space time is looked at funny. Models should know avidly about fashion. Actors about acting. Phd candidates about their chosen fields. Professors and their research.
Doctors and lawyers are required to do more overtime. That us one reason.
Also, doctors and lawyers and teachers do spend some of their out of work time learning.
Also, doctors and lawyers and teachers do spend some of their out of work time learning.
Agreed entirely. It's the same as hiring somebody out of college who had a job all throughout vs somebody who didn't and was involved in a lot of various organizations.
The involvement is great at all, but if you've graduated while working it shows great time management too.
The side projects are most valuable for conveying desire to learn / solve problems, which is perhaps the most critical trait for successful developer. At the same time, if your job already gives you a chance to showcase that, the side project isn't that big of a deal.
The key is just looking for that desire to learn to show through in the candidate. I've seen it from side projects where the side project showed experience (Ruby) that the primary job (.NET) did not, I've seen it from crazy detail and excitement in explaining how you solved a boring low level problem, etc.
There are many roads to surfacing that in an interview. When it shows, I'm currently batting 1.000 on the quality of hires though.
The involvement is great at all, but if you've graduated while working it shows great time management too.
The side projects are most valuable for conveying desire to learn / solve problems, which is perhaps the most critical trait for successful developer. At the same time, if your job already gives you a chance to showcase that, the side project isn't that big of a deal.
The key is just looking for that desire to learn to show through in the candidate. I've seen it from side projects where the side project showed experience (Ruby) that the primary job (.NET) did not, I've seen it from crazy detail and excitement in explaining how you solved a boring low level problem, etc.
There are many roads to surfacing that in an interview. When it shows, I'm currently batting 1.000 on the quality of hires though.
I'm just looking for any/every way to make the technical interviews I have to do as painless as possible.
Putting a project on GitHub that I spend real time on and believe demonstrates my skills as an engineer feels intuitively like an activity that might do that.
But you're right, it's not really about filling up time that's otherwise empty, it's really about making trades with the other time-filling things I'd like to do because the value of having a side project temporarily outweighs the value of spending time with my family.
Putting a project on GitHub that I spend real time on and believe demonstrates my skills as an engineer feels intuitively like an activity that might do that.
But you're right, it's not really about filling up time that's otherwise empty, it's really about making trades with the other time-filling things I'd like to do because the value of having a side project temporarily outweighs the value of spending time with my family.
Agree. The assumption underlying this is that you should use a bulk of your outside-of-work time to advance your career and grow your technical skills. True for some, not true for others.
I'd add: Workout and do other stuff while working on your side project. Don't just sit 8 more hours per day. Do some push ups, code a bit. Do some sit ups, code a bit, go running outside a bit, code some lines. Do the laundry, code while waiting. I've found that this works well for me and I am more satisfied with my day after.
This. Exercising has made all the difference. I'm more alert which leads to productivity. Used to be a night owl and barely got anything done in the day. Also, I now stop coding after say 10pm even on personal stuff, I make notes and pick it up the next day. That buggy block of code you churned out at 2am will be detrimental in the long run and your health isn't worth it.
The likelihood that a side project is going to pay off is very slim. If you are doing a side project for the sake of doing a side project, you are doing it wrong. Doing other things like fitness and raising a family are worthy projects, in which case your coding job is now your side project.
Why not do all of it? Here's what I do every weekday:
1. Work for ~8 hours 2. Go the gym for an hour 3. Commute home( unless I worked remotely that day ) 4. Work on side project for 1 - 2 hours. 5. Spend time with significant other/video games/both
1. Work for ~8 hours 2. Go the gym for an hour 3. Commute home( unless I worked remotely that day ) 4. Work on side project for 1 - 2 hours. 5. Spend time with significant other/video games/both
What's "worthy" about being fit or raising kids?
It's hard to decide for others what is important for them and what isn't. All we can say here is that side projects aren't free and you're going to need to take that time from other activities you participate in.
What it's not fair to say here is whether or not you're "right" to spend time on the things you do.
In other words, this conversation lives entirely on the "is" side of "is/ought", and doesn't need to stray into "ought" at all to still be helpful.
It's hard to decide for others what is important for them and what isn't. All we can say here is that side projects aren't free and you're going to need to take that time from other activities you participate in.
What it's not fair to say here is whether or not you're "right" to spend time on the things you do.
In other words, this conversation lives entirely on the "is" side of "is/ought", and doesn't need to stray into "ought" at all to still be helpful.
People normally don't take the kind of statement I made and interpret it as the sort of proclamation you are making it out to be. Relax.
I am relaxed, I wanted to be clear that you were crossing a philosophical line is all. No anger here, sorry if you felt attacked or anything!
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
> Now we have three people working on the site full time, thousands of paying users, and tens of thousands of repositories.
Three! Love it. That was a massive hire of course, a 50% increase above the two founders.
Three! Love it. That was a massive hire of course, a 50% increase above the two founders.
No can do, not sure if enforceable but employment agreement says all code I write even if unrelated to job is theirs.
Joel Spolsky wrote an excellent article about these kinds of clauses in programmer employment agreements.
https://www.joelonsoftware.com/2016/12/09/developers-side-pr...
https://www.joelonsoftware.com/2016/12/09/developers-side-pr...
> This ambiguity is meant to create enough of a chilling effect on the employee working in their spare time that for all intents and purposes it achieves the effect that the employer wants: the employee doesn’t bother doing any side projects that might turn into a business some day, and the employer gets a nice, refreshed employee coming to work in the morning after spending the previous evening watching TV.
Nailed it.
Nailed it.
write something illegal, see if they want to actually own that code. write strong encryption libraries and make them available for anyone to export.
I'm with you. At my current job there is no possible way to start any kind of "paying" side project.
So start a not-for-profit side project then (assuming a side project is something you're interested in) ... if your employment at this current place ever ends, then you have something tangible to take with you and show off; and side projects have a way of being more valuable than purely what money they can bring in (experience, clout, connections, etc)
Yes, but it took GitHub 10 years to make small private (i.e. side project-friendly) repos free.
Aren't most side projects open source, though? I wouldn't want to commit to maintain a side project if someone else found it useful.
I've used github for my side projects for that entire time and I still don't have a single private repo.
That's great. I love open sourcing things, so in a perfect world I'd never have a private repo. (for a side project that is)
Unfortunately, I have third party assets that I cannot release under an open source license, that I would like to use for my side projects, and I would like them to be versioned alongside the code. That's not an uncommon situation for people who enjoy writing games on the side, for example.
Unfortunately, I have third party assets that I cannot release under an open source license, that I would like to use for my side projects, and I would like them to be versioned alongside the code. That's not an uncommon situation for people who enjoy writing games on the side, for example.
Github was always very reasonably priced. It was only a free service to support free software. It's a shame it's not still like that imo.
That's a great idea -- if you don't have a wide range of hobbies and a curiosity about life. So work 40-50 hours a week, and then in your leisure time continue to work on the same type of item?
Maybe many developers who relate to this don't have creative pursuits (eg. writing, photography, painting, etc.), don't exercise, don't have much of a social life, and thus it is a no-brainer. Or, perhaps people are replacing wasted time (i.e. TV) with side dev time.
Either way, more power to you. I'm a believer in cross-training - creative thinking and a healthy body also improve the 'actual work' part of your work life.
Maybe many developers who relate to this don't have creative pursuits (eg. writing, photography, painting, etc.), don't exercise, don't have much of a social life, and thus it is a no-brainer. Or, perhaps people are replacing wasted time (i.e. TV) with side dev time.
Either way, more power to you. I'm a believer in cross-training - creative thinking and a healthy body also improve the 'actual work' part of your work life.
If everything will work out, at one point this side project will become your main project
And than after some time, You will need a side project again
And this cycle can last forever.
That's the life of the entrepreneur
Always chasing about something new
And than after some time, You will need a side project again
And this cycle can last forever.
That's the life of the entrepreneur
Always chasing about something new
As an ex-founder who was mad about side projects, I can tell you in hindsight, if you start a side-project, definitely make sure you enjoy what you are doing. The joy is in the process and not the destination. Otherwise, you will just burn your way through and destabilize your relationships unnecessarily as well.
Come to the free Minnebar unconference if you're in Minneapolis April 27.
Side Projects for Fun and Profit - 2019 Edition
https://sessions.minnestar.org/sessions/689
I would like to work on a side project, but I'm in my late 20s, single, and need to date a lot.
I need advice from people who went through this phase. Should I focus on my career or finding a partner?
I need advice from people who went through this phase. Should I focus on my career or finding a partner?
Video of talk: https://www.youtube.com/watch?v=AVs90EsAi3o
This is a great read but damn does he use “guys” a lot.
"Start a toy collection, says LEGO founder."
And Clearbanc will fund it :)
I also do hiring, not a lot of volume, but a rather rigorous process. I hardly ever look at someone's GitHub projects or OSS contributions because a) I don't know how much time they put into that work and productivity is a key metric for us and b) having our own process means I get just the information I need without needing to sift through a lot of code that will take me time to become familiar with. Not arguing this method is best, just that it's a reality that you can't be sure how many prospective employers will care about side projects. It worked for the article's author but it may not work for you. So again, just emphasizing that you should weigh the cost/benefits.