Side projects are, in my humble opinion, by far and away the best thing that we as developers (not just a PHP developer, a developer in any language) can do for ourselves, our careers / bank balance, and most importantly, our happiness.
The big problem is that in most instances, the code you are writing for your day job is not the code that get’s you excited.
Let’s not blame the code though. It’s unfair to blame that friendly if / else statement. After all, even if you were writing the software of your dreams, you would likely still need a conditional here or there. Or maybe not if you’re Sandi Metz 🙂
Rather, it is the domain in which your software applies that may not be your dream come true.
But we can fix that.
We can work in our dream domain in our own time. In my experience, few are the software developers who don’t have ambitions of making their own app or software company or dream product. And yet, so few work in their own time to make those dreams come true.
How many times have you thought about learning Python, Go, or the latest JavaScript framework (
What about tinkering with Redis, Elastic Search, or GrayLog?
No, management don’t understand any of that. And anyway, what are you doing looking at that stuff? Get back to work. There’s a thousand unresolved tickets in JIRA. Marketing need to know urgently whether that div with background-color #9888ce converts better than #a89ad5.
Ugh.
Please don’t put your life in the hands, Of a Rock n Roll band, Who’ll throw it all away
Ok, so far, so sweeping generalisations.
I’m not here to rag on day jobs.
Management may very well have good reason why you shouldn’t be looking into blindly adding new tech to their existing stack. But this can’t be your excuse to sit on your hands and stagnate.
I find it baffling that simply because a technology of interest is not in use in the work place / day job, that this is any reason not to actively try / learn about said technology in your own time. And worryingly I see this attitude time and time again.
But Chris, Learning technology in isolation is a bit dull… I hear you cry.
And I agree.
Why?
Because there is no purpose to it. You installed it. It worked. Next.
What is much more interesting is to use the technology in context.
Imagination Station
Let’s imagine a happy place where you have taken that app, that SaaS, that dream of being the next Zuckerberg, and you’ve seen it past the first hurdle… that is, you’ve actually started it. There’s some code on your machine that does something. Regardless of how small that something is, it’s a step towards improving yourself, your career / bank balance, and your happiness.
Now, if this project is of any worth, making sure it doesn’t fall over in some unexpected way should be quite high on your list of priorities – especially as your project grows and you and your end-users start interacting with it.
Suddenly your VM with that lovingly built ELK stack has a purpose. Hurrah. Fire it back up, quick. Let’s find a Symfony bundle to make sending messages from our project to Logstash so we get some nice visuals in our ELK dashboard.
Even if your project ultimately gets shelved, the knowledge you have gained from implementing ELK in a real / production environment puts you well ahead of the majority of your peers.
And of course, the ELK stack is just one such example. I use it because implementing logging / monitoring is an inherently useful and transferable skill to have. Setting this up for one project is no different to setting it up for another – whether that be another side project (you used Ansible right, so this is easy and quick to do?) or for your day job.
I’ve worked in places that actively discourage you from having a side project. May I be the first to say – that’s a stupid policy that can only hurt both you and them. And then there are places like these. This reminds me of that story about the brick layer who build his own house in his spare time, and then found out his home was actually owned by his boss at the building company where he worked. Oh yeah, wait, that never happened.
Continuous Improvement
I want to share with you some tips and tricks I have found to motivate myself towards a lifetime of Continuous Improvement.
1. Make a list.
Start by making a master list of all the projects / dreams / ideas you have in your head.
This doesn’t have to be fancy – pen and paper is a great way to start, but of course, there are likely a ton of apps for this sort of thing too.
I use pen and paper as it’s simple and easy, and available to me when I don’t want to be sat at my computer (shock horror).
If your list is anything at all like mine, it will be long and non-exhaustive. That’s great, keep adding to it whenever you think up something new. Simply writing it down will free up some of your limited head space to focus on the here and now.
And again, if your list is anything like mine, one simple line on an A4 jotter could be a year or more’s worth of work. That’s cool too.
2. Chunk in down
For each item on your master list, start a new page and brain dump everything you think you will need to do to make that idea into a reality.
As most of my ideas are ‘software for x’ kind of things, I like to brain dump everything I think I will need to do to get to v1.0.0.
I have never yet managed to write everything down in such detail that this covers every single task I need to do. That’s cool too. This process is a lot like Behaviour Driven Development (BDD) in that you will only start discovering more of the steps to get you to your goal as you start working on achieving that goal.
Try and write down everything and anything that comes to mind. The amount of mental clarity you will gain from freeing up clogged brain space is a very worthwhile side effect of this exercise.
3. Pick Something… Anything… And Get Started
I found that initially, possibly the hardest part is knowing which project to pick.
This is a nice problem to have. However, it can be frustrating.
My advice – pick the one that has the shortest path to v1.0.0.
By writing out each of your dreams / goals, you should have a much better idea of the timescales each project will involve.
If two or more look very similar in terms of time, choose the one that you would most enjoy.
Once you have picked one, look at your list for this project, pick the easiest thing to do from that last, and get started.
Just make sure you get started!
4. The Daily List & The Daily Review
Whatever you opinion of the daily stand up meeting, completing a similar exercise for yourself and your own projects is highly rewarding.
Just don’t do it first thing in the morning. Do it last thing at night instead.
You already have you high level overview, but the day to day may require more technical information, bug fixing, or time consuming bits of admin.
Running through this first thing in the morning is a time consuming waste of energy. Instead, review, re-organise or re-arrange your task list in the evening. That way you can hit the ground running first thing the following morning, or whenever you next get chance to work on your project.
This is similar in some ways to leaving a failing test when doing TDD or BDD. You work to a point, then leave the test failing for your next / current feature, which in turn makes it much easier to get back into the swing of things when you next load up your code base.
Each night you should review your tasks, prioritise accordingly, and be realistic about what can be achieved the next time you will be working on your side project. The very act of making and reviewing this list will increase your personal productivity significantly, and being able to see a check list of ideas, goals and tasks each ticked off on your paper is hugely motivating.
5. Use Technology You Know
A simple task on your list of daily tasks towards achieving your goals could be to git init a new project, and push the contents of your dir up to your newly created repo. Progress!
The real power for me has been standing up a Gitlab server for my own private projects.
Inside GitLab you can add in task / bugs lists, add in Wiki entries for complex parts of your project, and generally do 99% of the things you can do with GitHub. About the only thing not there is the public’s code to search.
But the most powerful feature of GitLab for me is the Contributions Calendar. GitHub have this, and if you were to look at my profile you would think I rarely did anything.
Not so. I just commit to private GitLab instances a heck of a lot more than I use GitHub.
Keeping that streak alive is a powerful motivator, and it’s built in for free if you use the same GitLab a lot. Of course, you’re free to use GitHub or whatever, but don’t under estimate the power of seeing all of your daily activity in a friendly little widget.
Share Where? Here. There. Everywhere!
So now you have one or more projects you are working on in your spare time.
You’re immediately ahead of the curve.
This makes your resume more complete. It gives you things to talk about inside an interview situation that aren’t blah blah corporate finance payroll software blah blah. And hopefully it’s got you highly excited about some of the amazing open source tech that makes your world a much better place to be.
You can choose to share these projects any way you see fit.
Of course, be careful about this if you do work for a company where side-projects are banned or frowned upon.
Share the source code via GitHub – hey, free side benefit is your GitHub Contributions Calendar will look awesome!
Talk about your project on your blog – you do have a blog, right? If not, add that to your list.
You don’t have to share your source code – talking about what you’re up too is fine, and sharing some code snippets with a bit of context can be equally helpful.
Always wanted to do a conference talk? Great, your side project is likely interesting to others – maybe not the domain in which you operate, but the process and the journey it’s taken you on.
Meet new, like-minded people. Every language has it’s own community. There are some real lemons in each one, I’m sure. But don’t let that put you off. You will highly likely find some amazing, like minded friends amongst them.
tl; dr
If your passion is coding, do it every single day.
Working on code / in a domain that interests you is much more motivating than coding for a pay-cheque.
As software developers we can build whatever we can dream up.
Dream up something – anything – and get started. The journey is just as important as the destination.
One thought on “Shhh, Don’t Tell Anyone About My Bit On The Side”