Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
Me too, I think there are two types of side projects, this article focuses on those which I believe people will try to generate a business out of, or at least some form of passive income.
But there are also some side projects where you just want to get your hands dirty with some different tech, if you do deliver something then you can showcase it on your portfolio. I know when the app store gold rush first started a lot of people did this as experience to get iOs dev jobs.
Exactly - I enjoy side projects precisely because they're not bound by pragmatic concerns. I can delve as deep as I like into getting the CI pipeline working just right, making sure the servers and cacheing are set up ok and all those other things that I usually have to leave to colleagues.
More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job.
I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't.
But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
99% of the time, if you want to go pragmatic, you should buy a ready-made solution (and then possibly adapt it to your use case). It's efficient (especially if you need the problem solved to make money) - but it's no fun.
I agree, but there are good reasons why it is often good to combine both types.
Considering this is only a side project, you have a high likelihood of abandoning it out of boredom, lack of traction or simply burn out. However, if your side project is "interesting" to you because you are experimenting with various tech, you come back to it because it is fun and it will keep you motivated.
It is totally cool to build something to learn and throwaway, but why not build something to learn that might also generate some income in the future?
I do that too, but make that my secondary goal. If it fails, at least I got to improve my skills on whatever technology I chose to build it in. It helps me push along when it gets to the dull parts.
I have never regretted taking the time to make sure my projects have a proper logging infrastructure with every possible thing fed to the logger. I've built logging support libraries to set up AOP hooks to auto-log the call stack at all times, and it's been a lifesaver.
I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.
Not 'amyjess, but the rightest answer I've found (and I do a lot of this stuff) is to use a Bunyan-style one-JSON-object-per-line log file and ship to something that can consume it (ELK, CloudWatch Logs, whatever). AWS CWL is dirt cheap and the awslogs daemon, while pretty far from perfect, does work pretty well. You can also couple it with CloudWatch Metrics.
That's completely dependent on the format of your infrastructure. There is no answer that will fit everybody, and asking around for advice of strangers may even bias you in a damaging way.
Yea a lot of my side projects are started out with the understanding they're not going to become anything more than toys for me to play with ideas.
This article feels like it's written from the perspective of using a side-project to bootstrap a business rather than as a learning experience, hobby or toy.
I often explore new stacks by building a product that already exists complete with identical css! For example: Wanna try out aiohttp, vue & css grids? Let's build a Slack clone!
Yep. That's why I've rebuilt my little blog about a dozen times. I've built CMS's from scratch before (actually built a white label CMS generator) and it's a non-complicated process that I know deeply enough to push the pain points when I try things out.
Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"
I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project.
I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc.
There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it.
And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)
Maybe the real lesson here is that the last open task on your project is something that can present human-readable digests from parsing the compiler errors...
To be fair, many of us have plenty of side projects that are just not computer related. Reality is those should also provide teaching opportunities. (Indeed, for many, teaching children is essentially a full time job in terms of time commitment.)
Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)
> "This person probably has no side projects to play with"
Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"
It doesn't even have to be something "productive" ... what's being proposed here is that companies invest in literally having developers research new technologies, without expectations that said research will result in anything immediately profitable.
How about making wednesday mornings, a 4hr 'personal project' time? Make it a requirement that everyone has to work with tools at the edge of their skillset, that is also relevant to work, but let them choose what, why, how. They could work on a personal project, or experiment with a new library or tool they would like to incorporate.
Start the day with a "not really a standup", where people can quickly explain what they want to accomplish in the next four hours.
Once a month, you spend a couple of hours of the time demoing the work you have done for each other, explaining the technology and what you have learned, and then discussing and evaluating our individual technical weaknesses and deciding what to do next. This rest of this monthly meeting could also be spent improving social coding skills - code and commit hygiene, team processes etc.
Not only would this keep people technically sharp but it keeps them from playing with toys in production and breaks up the work week, while still fulfilling company goals.
If you have to start giving reports, it kills creativity. The point is to do something everyone else may think is irrational, but you feel would lead somewhere interesting.
Some companies are already doing this. When I worked at Intuit we would have Whitespace days and Innovation days, roughly every month or so where you could spend 1-3 days doing whatever you want.
Having a solution to the problem and having people advocate for implementing that solution in their companies are too different things.
We know about lots of best practices but if no one is advocating for them at their companies those practices we'll just be shining cities on a hill that we look to from a deep, dark valley.
We call this development time at my workplace. Every two weeks, I spend the first half of my shift doing whatever I please, with encouragement for it to be work related, but no real guidance.
Last week I wrote a utility in Python to parse a configuration file that we had so far been editing by hand, or with bad, slow and cumbersome tools. Now our Linux guys can make the changes is seconds across multiple machines, and the parser is much safer than the bash hacks we had been tempted to use before.
Point being, development time can be great! More companies should embrace the idea of letting their employees improve their own workflow. Some of our best ideas were just that: a little spark that an employee had the opportunity to actually explore.
While I have a lot of freedom at work to explore side projects and random stuff and I spend a lot of time doing so, there is a part of me that feels like there's a reason software engineers, at least in the US, are paid so damn much. To me, it's kind of implied that I'm paid <ridiculous amount compared to virtually any other job with similar requiring similar amount of training> is because I'm going to be doing more than the 35-40whatever hours I spend at the office.
Part of that is support (though about half of the jobs I've had involved little to no on call duty), part of it is training one self, in addition to everything I have to do during the day.
Let's call it discretionary overtime baked in pay since we're usually salaried.
IMO, there's room for both approaches, perhaps with the exclusion of the most the irrational situations as you describe. It's unreasonable to expect engineers to bring battle-tested solutions to the table 100% of the time.
I have a side project where I'm using the new Crystal language and even wrote a post on my company blog about it but we don't actually use it, nor do I try to get us to use it.
Now that's a good point - I've noticed a tendency to use side projects as a buffer for frustrations being experienced at work. Maybe there is a fundamental amount of true engineering I need to do on a weekly basis; if I'm not getting my fix at work it'll spill over to hobbies.
Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before.
Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think.
Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.
Or they're bored out of their minds and trying to make their work not be so much of a waste of time.
Most of the stuff I've seen done at typical development companies are intellectually interesting maybe to people who really started learning to code on the job, and generally don't have much experience. They're discovering new things every day, so it's fun! However, if someone has already few languages and various types of projects behind them, then the job becomes much less technically challenging and much more repetitive.
This is exactly how I approach side projects as well. I use them as iterative learning experiences, with each new project building on the last to more complex ideas. Learn a TON that way, and potentially build something that people want to use. You can always go back, and add things you've learned down the line.
One thing I do not do, is just rebuild something someone else has already done in a new "stack", just to see if I can. Any project I undertake is a new idea I've not seen done, or with features I want.
Nailed it with this comment. My side projects are for learning. There was a moment or two where I was aiming to monetise but I'm not at that stage and I now realise that, I just want to play with technology.
Actually starting to livestream them now as I figure if others can see what I'm trying to do I might be able to get instant feedback on how to do things better - crowd sourced learning :)
By "deployment approaches", I mainly meant CI/CD and infrastructure. So Jenkins, Travis CI, etc. to do the build work and testing, then automatically push to Kubernetes, Docker Swarm, AWS Lambda, etc. on the infrastructure side.
For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.
Agreed; in fact, the title falsely (or maybe ironically) conveys a positive attitude about how it's an "art," thereby attracting people who, like me, wanted to hear about some gloriously and baroquely over-engineered side project that will never see the light of day. A large investment of time, effort and craft into something, for its own sake, with no heed to whether it will ever "ship": That's what art is, man!
Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"
When you are doing a side project you typically have a number of risk factors such as: (A) using new tools, (B) working in a new area, (C) building a new type of application, (D) uncertain marketing, etc.
Any kind of project has a "risk budget". If you have few other risks, then you can spend your risk budget on new tools. If you are facing high risks in other directions, it makes sense to stick with what you know.
Most of my side projects are like that -- just an excuse to learn something and more often than not abandoned when I have learned what I wanted. Not the best way to develop software but a great one to learn new technology.
There's probably another reason hidden in the first sentence, which is that there's a transition from building the product (engineering) to shipping the product (marketing, customer development, sales) that requires different skill sets and experiences. Was just discussing this with a software engineer friend of mine who realizes that he "has no clue how to market my product the right ways."
Agreed. The best part of side projects is that I can take as long as I want to build it to my satisfaction, rather than to the minimal acceptable state for business purposes.
If your goal is to make money on something, then yes I agree with the author's points. However the whole goal of side projects is to have fun with new languages, frameworks etc.
I think the majority of engineers only do side projects to learn things they couldn't at work or explore architectures they wouldn't be able to in a work environment.
When I first read the title, I had thought that this would be a humorous example of a delightfully over-engineered side project. It turns out that this is instead a list of 5 common mistakes of over-engineering with some commentary.
I don't agree with this reasoning. Expressing in public your projects is a compromise and it can help you keep developing it when people ask if it is ready. If you are going to abandon your projects, not telling people will not help you succeed, it will only spare you the shame and effort explaining why you droped another project.
I don't think people start projects with the conscious intention of building identity, but with a genuine intention of delivering. I do think, though, that there's a small (or big!) part of your unconscious brain that binds these efforts to an overarching persona-building (both inwards and outwards) project. Although unconscious, it contributes to this net energy.
I guess that this communicating your intentions satisfies this portion of your brain, and reduces the amount of energy involved in the project.
Sure, this makes sense. I just don't think (using only myself as a reference, which is totally biased) that this effect has a bigger impact than the social pressure the public compromise creates.
On another note, I believe integrity could be unnecessarily valued sometimes.
My (limited) experience in business field told me that there is no friend or enemy, but profit. Profit trumps integrity almost every time in business decisions.
I don't think VC deals with integrity of founder in absolute term either. If potential benefit outweigh risk after calculation, then greenlight it is.
Very much perceived as disloyal Steve Jobs, I don't think he got around by integrity.
Fascinating. I've tried to use talking about a project as a commitment device.
Looking back on my many projects, the feeling of delivering on an external commitment seems much weaker than the urgency of "wait 'til my colleagues see this!"
The weird thing is the same situation works in reverse as well.
Publicly declaring your intention to quit a habit or lose weight has also been shown to increase success in some instances.
I think it depends on whether people reward you with positive regard for stating an intention to do something, and whether you look foolish if you don't do the thing you stated. When you can get the reward just for the statement and there is no consequences for failure, pre-stating your intention seems harmful. On the other hand, if you are not rewarded for pre-statement, and failure is embarrassing, pre-stating your intention seems helpful.
I have observed this vastly "bipolar" results amongst my friends as well. Some take public declaration to heart and they ram through their goals. However I quickly lose interest of the project after I told everybody. I would go extra length to surprise and dish out cool stuff more often I care to finish side project only because I said I will do it.
I somehow concluded that I don't care about approvals on my 'integrity' yet I highly value my 'creativity' viewed by others.
I find that exclaiming publicly what it is I want to do has a level of gratification (hey, look at this cool idea!) that would otherwise turn into excitement/anticipation during development. That initial gratification might be enough to stall/kill the project.
I've had plenty of ideas that I'd love to see through and think are great, I just don't have the time to do them. Since my time is so limited, I have to choose to focus on one project, or I end up with a ton of unfinished ones (which is the case). So unless I have strong motivation to complete a project (which can be compromised by some sort of gratification), it stalls.
But the majority of mine stall for other reasons; I don't usually announce/discuss them.
Yep, as soon as you start talking about it, people start congratulating you, your reward system kicks in in your primitave lizard brain, and you don't bother actually doing it because you've already been rewarded.
Why do you need a deployment system if you have nothing to deploy? Build the project locally, then use continuous delivery when you have something to deliver.
"Build the project locally" implies some kind of pipeline system, even if it's not "deployment" or "delivery".
Triggering that pipeline from a commit trigger instead of manually just means copying the build command into a config file. It pays for itself in the first hour.
“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!”
The good news is, once you've done that, you can get a pretty decent job.
The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running.
This is not entirely true. The technology do surface in terms of user experience. It does in the details: app start, ui responsiveness, etc. I'm writing a game using go right now, and the end user can tell it's different because the user's cpu seems more powerful.
All in all, I think those are good mistakes, not bad ones. I wish more engineers could spot over-engineering, and they don't until they did the mistake a couple times. Side projects are, I believe, how one really learn to write programs. I think the right advice is: do whatever you want, do all the mistakes. How can you write a successful side project anyway if you never learn how to write a program? Also, the worse type of programmers are the ones telling you about over-engineering because they read about it in a blog. Code more, read less, I guess should be a good motto.
"A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are)."
Where games are concerned I'd tend to agree (though Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it).
> Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it
Well, it still takes absurd amounts of memory for what it's doing, which I guess is on par for Java. (On my notebook with 4GB RAM, modpacks fall into one of three categories: "works well", "have to shut off as many OS services as possible before starting" and "forget it".)
well only because java has no value types/struct like data structure.
the reason why this makes memory so heavy is because even a simple int list, needs boxing.
So you end up with a big chunk of garbage which you don't need. On the server, this is not a problem because most of the time the list is a young gen object and die really fast, so G1GC solves most problems.
The problem of course is really big, because arrays are a pain to work with and not many people do that.
However as soon as java 10 hits, we might get value types and maybe this changes the game (but we will see, since it would've taken way to long for that thing).
Also there are more and more types inside the standard library who would be great value types, i.e. LocalDate/LocalDateTime, but at the moment they take way more memory than needed, especially since they only contain 2 immutable shorts and 1 immutable int.. in the perfect case it would be something like 8 byte, however it takes way way way way more. (basically a simple class at least takes 16 bytes, which is already double the field size, so you end up with 24 bytes [probably more due to various other stuff])
btw. for a game like minecraft you probably have a lot of types that follow the same stuff like LocalDate, small class with immutable int's/short's for position, etc. these have the same problem and will fill the memory more quickly than needed
comparing minetest (a c++ minecraft clone) and minecraft gives the following memory usage upon starting on a blank new world. Also, minecraft takes five times more time to launch.
4GB? I wouldn't expect most open world games to perform well with 4GB. I think 2010 was the last time I had a laptop with less than 8GB. My current laptop has 16GB. Game developera and certainly mod developers don't optimize for bargain basement hardware.
Potential customers do care about the stack you're running. They care if they have to download Java or Flash. They care if they have to be connected to the internet or can use your product offline. They care if your program starts quickly. They care if your program runs quickly once started. They care if your program has bugs (let's not pretend different languages aren't more or less error-prone). They care if your program is cross-platform. They care if your UI is consistent with their platform. They care if your product releases new features quickly.
I think the point was that user doesn't care about your stack, but they care about the consequences of the stack you've chosen. It's a subtle but important distinction.
Of course. My point was that it's fairly common to write slow/unsuitable applications in spite of a stack's strengths, while stack limitations (or strengths) are generally overstated, depending on trends.
Proper engineering and design are required no matter what you choose.
Have you figured out a way to make a mature implementation of the JVM start up fast? Nobody else in the industry has.
Is there some way I know of to package Flash games so that Firefox users can play them without downloading Flash?
I get that done of the examples I mentioned are arguable, but some of these are pretty unambiguously stack intrinsic. Some usability concerns cannot be addressed in some stacks.
Notice how just about none of them are the user caring about your stack.
In other words, when confronted about your high bug rate, you're not going to get anywhere going "heh, you see, Python was just more convenient than a statically-typed language and this lead to..."
You'll likely have to anyway :) I still make a difference between writing a side project and starting a startup. The way I see it, there is no failing on a side project.
I always overengineer my side projects, because it's way more interesting that way. I do side projects for fun and to learn something, both of which happen more easily when the project is overengineered.
I tend to underengineer my side projects because the stuff that I touch at work is frequently much too overengineered to begin with (cough OpenStack cough).
Agreed. Part of the fun of my side project is that it's well built. At work I have to deal with poor quality code practices from artificially tight timelines, contractors, etc. From one perspective it's very wasteful to have higher quality code for an app that generates $150/mo. vs multimillion dollar projects I manage at my day job, but I enjoy that $150, the code and customers more than what I get from my day job. I wouldn't if it was an MVP.
The article has good points. But the term "side project" implies working on something that isn't part of your job. I think looking at your project from that perspective can also be a step in the wrong direction---if you enjoy what you do, work is just one such application of your knowledge and ability. Projects you do outside of work are another, and may even be more important to you than work.
A number of commenters point out that many side-projects to them are to explore new concepts/libraries, or as a means of learning. If it's for the sake of learning for your job, then yes, it'd be a side project.
But if you're looking to take a project to completion (the author talks about products; my projects aren't), I find that using it as a learning environment extremely detrimental. Yes, you do learn things over the course of development---through research, struggle, and growth. But if too much of your time is spent on things you don't have a good foundation on, you may burn out too early, wind up frustrated, and wind up with a mess that leads to refactoring. Use a foundation that you have experience with and know well, and learn the parts that are necessary.
(I do distinguish, though, a research project with a project for playful learning. The former is much more formal and disciplined. But you can still burn out early.)
heh, most of this stuff is extra wastes of time past the very first hurdle that you should be working on: make something that works and is useful to people.
sure it would be great to have scaling to 10,000 users already sorted by the time you get there but odds are your project will never get there, when you get to 5k users you need to start worrying about that
if you're just doing it to learn or for fun then obviously this article or my comment don't apply
> A customer will not know or care if you are using Ruby, Go, PHP or any other language
Users will absolutely notice if your product crashes or breaks, which is more likely with some languages than others. The single most likely reason for me to stop using a nominally useful product is that it doesn't work reliably. I hate the fact that so much technology today is broken, partly because people have this cavalier attitude towards choosing technologies that help to keep things working.
#3 hits home. I've been "working" on my side project for 3 years now with almost no progress because I'm constantly intrigued by new frameworks and BaaS. I spend all my time tinkering with them until I get bored with it all together. If I had just built the thing in Rails from the start I'd probably have a solid app under my belt by now.
I'm in the same position. I've built my own game engine from scratch and while it was a really good learning exercise I recently started looking at Unity and wow... So many things I've always wanted in my engine that I will get for free. I don't regret a thing though.
Related to this, I've been following a practice I call "Release Notes Driven Development", which is perfect for side projects. Don't worry too much about technical debt (although, keep it under control), but focus on the little time you have and how to make that as efficient as possible.
Sounds good. Early on, a quick list of bragables should be able to tell you how awesome the idea is. Have new bragables for the next version. If its not awesome at some stage (and the bugs are fixed) you are probably done?
It reminds me of many release notes describing a ton of work without any woah.
Good points in there. I have a little trouble with "mistake #5" though.
I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or things have settled down and leave more time for my side projects. If I didn't take the time to automate testing and deployments (which makes a lot of what continuous delivery is about) I find myself struggling with getting things up and running and become frustrated before I even get started.
Then there's only one way to make sure that my test and deployment automation keeps working: running it regularly, e.g. in a pipeline.
So, yes, don't over optimise your deployment pipeline early on. But having one in place early can pay off really soon -- and maybe even keep your side project alive.
Agreed. Having a deployment pipeline in place dramatically reduces the friction of returning to an old project.
I have a back-burner project that touch very infrequently, but I can jump in, make a quick change, and have it deployed to "production" in just a few seconds.
I definitely automate locally by way of Makefiles, running tests then using the GCloud/aws CLI to deploy from local. Things like TravisCI, webhooks, etc come much later if at all.
I can tell this article was written by a very wise man who wasted time on lots of projects or saw a lot of other people waste time on projects. He's described behaviors I have dabbled in many, many times.
In fact, I have a side project currently where I just needed to fabricate a tiny fixture for a physical device. I caught myself over-engineering the prototype, went to sleep, woke up, saw this article and came to my senses. Consider this article bookmarked!
Man, I think this article is dead on, except it doesn't identify the original reason, for me at least. In a normal environment, there are constraints on time, money, goals, resources, etc. Suddenly, when there are no constraints, a side project, you try to do everything perfectly, which leads to the issues in this article.
271 comments
[ 3.4 ms ] story [ 221 ms ] threadBut there are also some side projects where you just want to get your hands dirty with some different tech, if you do deliver something then you can showcase it on your portfolio. I know when the app store gold rush first started a lot of people did this as experience to get iOs dev jobs.
More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job.
I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't.
But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
99% of the time, if you want to go pragmatic, you should buy a ready-made solution (and then possibly adapt it to your use case). It's efficient (especially if you need the problem solved to make money) - but it's no fun.
Considering this is only a side project, you have a high likelihood of abandoning it out of boredom, lack of traction or simply burn out. However, if your side project is "interesting" to you because you are experimenting with various tech, you come back to it because it is fun and it will keep you motivated.
It is totally cool to build something to learn and throwaway, but why not build something to learn that might also generate some income in the future?
That's not a problem, that's the goal!
I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.
This article feels like it's written from the perspective of using a side-project to bootstrap a business rather than as a learning experience, hobby or toy.
My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it.
And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)
Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"
Start the day with a "not really a standup", where people can quickly explain what they want to accomplish in the next four hours.
Once a month, you spend a couple of hours of the time demoing the work you have done for each other, explaining the technology and what you have learned, and then discussing and evaluating our individual technical weaknesses and deciding what to do next. This rest of this monthly meeting could also be spent improving social coding skills - code and commit hygiene, team processes etc.
Not only would this keep people technically sharp but it keeps them from playing with toys in production and breaks up the work week, while still fulfilling company goals.
We know about lots of best practices but if no one is advocating for them at their companies those practices we'll just be shining cities on a hill that we look to from a deep, dark valley.
Last week I wrote a utility in Python to parse a configuration file that we had so far been editing by hand, or with bad, slow and cumbersome tools. Now our Linux guys can make the changes is seconds across multiple machines, and the parser is much safer than the bash hacks we had been tempted to use before.
Point being, development time can be great! More companies should embrace the idea of letting their employees improve their own workflow. Some of our best ideas were just that: a little spark that an employee had the opportunity to actually explore.
Part of that is support (though about half of the jobs I've had involved little to no on call duty), part of it is training one self, in addition to everything I have to do during the day.
Let's call it discretionary overtime baked in pay since we're usually salaried.
====http://www.bosscyber.com
Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before.
Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think.
Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.
Most of the stuff I've seen done at typical development companies are intellectually interesting maybe to people who really started learning to code on the job, and generally don't have much experience. They're discovering new things every day, so it's fun! However, if someone has already few languages and various types of projects behind them, then the job becomes much less technically challenging and much more repetitive.
One thing I do not do, is just rebuild something someone else has already done in a new "stack", just to see if I can. Any project I undertake is a new idea I've not seen done, or with features I want.
Actually starting to livestream them now as I figure if others can see what I'm trying to do I might be able to get instant feedback on how to do things better - crowd sourced learning :)
For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.
Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"
Any kind of project has a "risk budget". If you have few other risks, then you can spend your risk budget on new tools. If you are facing high risks in other directions, it makes sense to stick with what you know.
I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.
http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...
I don't think people start projects with the conscious intention of building identity, but with a genuine intention of delivering. I do think, though, that there's a small (or big!) part of your unconscious brain that binds these efforts to an overarching persona-building (both inwards and outwards) project. Although unconscious, it contributes to this net energy.
I guess that this communicating your intentions satisfies this portion of your brain, and reduces the amount of energy involved in the project.
If someone else could get hurt, I push through.
Looking back on my many projects, the feeling of delivering on an external commitment seems much weaker than the urgency of "wait 'til my colleagues see this!"
Publicly declaring your intention to quit a habit or lose weight has also been shown to increase success in some instances.
I think it depends on whether people reward you with positive regard for stating an intention to do something, and whether you look foolish if you don't do the thing you stated. When you can get the reward just for the statement and there is no consequences for failure, pre-stating your intention seems harmful. On the other hand, if you are not rewarded for pre-statement, and failure is embarrassing, pre-stating your intention seems helpful.
I somehow concluded that I don't care about approvals on my 'integrity' yet I highly value my 'creativity' viewed by others.
But the majority of mine stall for other reasons; I don't usually announce/discuss them.
To me, that would suggest it wasn't a good idea in the first place.
Either way I learn a lot more by building a bad idea than I do by talking about it.
> The king of Israel answered, "Tell him: 'One who puts on his armor should not boast like one who takes it off.'"
> 5. Build your project first – then worry about continuous delivery.
These contradict each other. Building your own deployment system is just as much of a distraction as building your own CSS framework.
Triggering that pipeline from a commit trigger instead of manually just means copying the build command into a config file. It pays for itself in the first hour.
You can get quite far without any kind of "pipeline system" nor does building imply a pipeline.
The good news is, once you've done that, you can get a pretty decent job.
The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running.
This is not entirely true. The technology do surface in terms of user experience. It does in the details: app start, ui responsiveness, etc. I'm writing a game using go right now, and the end user can tell it's different because the user's cpu seems more powerful.
All in all, I think those are good mistakes, not bad ones. I wish more engineers could spot over-engineering, and they don't until they did the mistake a couple times. Side projects are, I believe, how one really learn to write programs. I think the right advice is: do whatever you want, do all the mistakes. How can you write a successful side project anyway if you never learn how to write a program? Also, the worse type of programmers are the ones telling you about over-engineering because they read about it in a blog. Code more, read less, I guess should be a good motto.
Where games are concerned I'd tend to agree (though Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it).
Well, it still takes absurd amounts of memory for what it's doing, which I guess is on par for Java. (On my notebook with 4GB RAM, modpacks fall into one of three categories: "works well", "have to shut off as many OS services as possible before starting" and "forget it".)
the reason why this makes memory so heavy is because even a simple int list, needs boxing. So you end up with a big chunk of garbage which you don't need. On the server, this is not a problem because most of the time the list is a young gen object and die really fast, so G1GC solves most problems. The problem of course is really big, because arrays are a pain to work with and not many people do that.
However as soon as java 10 hits, we might get value types and maybe this changes the game (but we will see, since it would've taken way to long for that thing). Also there are more and more types inside the standard library who would be great value types, i.e. LocalDate/LocalDateTime, but at the moment they take way more memory than needed, especially since they only contain 2 immutable shorts and 1 immutable int.. in the perfect case it would be something like 8 byte, however it takes way way way way more. (basically a simple class at least takes 16 bytes, which is already double the field size, so you end up with 24 bytes [probably more due to various other stuff])
btw. for a game like minecraft you probably have a lot of types that follow the same stuff like LocalDate, small class with immutable int's/short's for position, etc. these have the same problem and will fill the memory more quickly than needed
Does it though? There's a non-trivial amount of data being loaded (and generated) all the time.
You have mentioned modpacks. Those can be HEAVY. And a single not well programmed block can bring down and entire server.
All of these are stack-related.
Proper engineering and design are required no matter what you choose.
No silver bullets ;-)
Is there some way I know of to package Flash games so that Firefox users can play them without downloading Flash?
I get that done of the examples I mentioned are arguable, but some of these are pretty unambiguously stack intrinsic. Some usability concerns cannot be addressed in some stacks.
In other words, when confronted about your high bug rate, you're not going to get anywhere going "heh, you see, Python was just more convenient than a statically-typed language and this lead to..."
You are right that nobody will care if you use them as excuses. But that is not what the GP said.
And you'll likely have to.
A number of commenters point out that many side-projects to them are to explore new concepts/libraries, or as a means of learning. If it's for the sake of learning for your job, then yes, it'd be a side project.
But if you're looking to take a project to completion (the author talks about products; my projects aren't), I find that using it as a learning environment extremely detrimental. Yes, you do learn things over the course of development---through research, struggle, and growth. But if too much of your time is spent on things you don't have a good foundation on, you may burn out too early, wind up frustrated, and wind up with a mess that leads to refactoring. Use a foundation that you have experience with and know well, and learn the parts that are necessary.
(I do distinguish, though, a research project with a project for playful learning. The former is much more formal and disciplined. But you can still burn out early.)
sure it would be great to have scaling to 10,000 users already sorted by the time you get there but odds are your project will never get there, when you get to 5k users you need to start worrying about that
if you're just doing it to learn or for fun then obviously this article or my comment don't apply
Users will absolutely notice if your product crashes or breaks, which is more likely with some languages than others. The single most likely reason for me to stop using a nominally useful product is that it doesn't work reliably. I hate the fact that so much technology today is broken, partly because people have this cavalier attitude towards choosing technologies that help to keep things working.
Thinking about using Unity now...
In the context of hobby projects, over-engineering can even serve purpose of learning new things you otherwise could not.
For side projects, or startup candidates, however, you just ship it
Eventually backed up and used Make to run Babel and then cat the files together.
I wrote about it here; https://ma.ttias.be/release-notes-driven-development-rndd/
It reminds me of many release notes describing a ton of work without any woah.
I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or things have settled down and leave more time for my side projects. If I didn't take the time to automate testing and deployments (which makes a lot of what continuous delivery is about) I find myself struggling with getting things up and running and become frustrated before I even get started.
Then there's only one way to make sure that my test and deployment automation keeps working: running it regularly, e.g. in a pipeline.
So, yes, don't over optimise your deployment pipeline early on. But having one in place early can pay off really soon -- and maybe even keep your side project alive.
I'm a big fan of doing the hard work early on. When you push that step off it makes dev later slow and frustrating.
I have a back-burner project that touch very infrequently, but I can jump in, make a quick change, and have it deployed to "production" in just a few seconds.
In fact, I have a side project currently where I just needed to fabricate a tiny fixture for a physical device. I caught myself over-engineering the prototype, went to sleep, woke up, saw this article and came to my senses. Consider this article bookmarked!
Then you can send the link to anyone and it always just works.