Start a side project, says GitHub founder (2008)
gist.github.com
gist.github.com
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.
It isn't all the big moments. There's definitely a lot more of just time spent together.
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.
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.
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.
Do you have examples of this? It sounds contrary to my experience.
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.
* 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.
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"
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.
> 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.
> We’re not Netflix, we’re a country of 5 million.
1: https://news.ycombinator.com/item?id=19412779 2: https://news.ycombinator.com/item?id=19419308
My point was that it might be a waste of resources to build something you don’t need.
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 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.
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'.
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?
Safety mitten insanity abounds.
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_...
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.
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.
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.
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.
Also, doctors and lawyers and teachers do spend some of their out of work time learning.
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.
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
Three! Love it. That was a massive hire of course, a 50% increase above the two founders.
https://www.joelonsoftware.com/2016/12/09/developers-side-pr...
Nailed it.
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.
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.
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
I need advice from people who went through this phase. Should I focus on my career or finding a partner?