What eight years of side projects have taught me (2019)
junglecoder.com
junglecoder.com
In my career (granted not a long one, but made it to C-Level in a startup after about 5-7 years) I've always used them to show my interest and learning skill to do something. It didn't matter whether it had 1 user or 1 million, employers were always very impressed and it always gives you an advantage during interviewing. Most of those have also been with very little or no code at all.
I'm normally prioritising people with side projects in the recruiting process vs. people who only did school -> work
Depends on the definition of "unfinished" - it's good to create something that's workable to some state (or at least demo something). If you're using a repo of unrunnable code as an example of your skills, you probably need to have a robust explanation of what needs to be done to get it working.
However, I doubt lots of examples of half-complete projects will reflect too well, and might be more of a hindrance ("doesn't follow through, constantly jumping from thing to thing...") than a benefit. Pick one you're proud of and run with it, even if it's just a "this is the state, this is what I'd do to get it running...".
If your answer was an unfinished project, I'd want to know why they were unfinished. Did you give up on them because of external pressures, you had a better idea, or because you often struggle to finish things you've started?
That last one is not alway a pejorative statement, BTW. Some people are great at figuring out the big stuff and then need others to help them execute on the detail (think about architects or producers). Others however, just give up at the first obstacle they meet, and if I get that impression from a candidate I'd want to dig into it a bit as it's possibly a yellow flag.
My advice then: think carefully about what they are likely to ask you about those unfinished projects, and what your answers are likely to be, before you offer them up.
[1] The most interesting answer to this question I've had was "an OpenGL renderer for the X Window System written in Lisp". My follow-up questions were many...
Good employers, but who do not have more qualified candidates than they know what to do with, are already very happy with someone who simply has an interest in his job, as this is already rare enough. They pay attention to personal projects as signs that you actually belong in IT.
Government and, by extension, the consultancies that cater to them, pay attention to diplomas. Bureaucracies recognizing the stamp of approval of another bureaucracy, is one way of looking at it.
One hiring manager let me talk about it more, but in retrospect he was basically nice to me and let me talk about it because I wanted to.
Learning how to do those is a useful skill in its own right, even if they're "toy problems", because what you're learning is a process to break a problem down, and then make a choice based on your knowledge of data structures and algorithms about how to approach it.
Getting good at those puzzles means you flex muscles related to:
- Problem breakdown into logical steps, or what I now call "the useful thing CS50 actually teaches"
- Data Structures
- Algorithms
- Communicating your thought process on all of the above
Those skills are going to help you in any developer job, but might also give you more confidence to take on side projects you wouldn't otherwise. You might look at something out there and think "woah, I want to go figure that out", and now your mental muscles are slightly better trained for it.
What I want when interviewing isn't necessarily a good guide, but typically the technical skills are a baseline and then I want:
- People who can be mentored and aren't know-it-alls. A touch of humility about them. Finds pairing whilst driving scary but will try it.
- People who want to mentor others. Finds pairing whilst not driving scary or frustrating, but will try it.
- Able to work within a team towards a common goal
- Will take ownership and accountability of their own individual tasks
These are things you're more likely find from previous work experience and maybe in side projects, at a push.
I'd say if you're going for FAANG-type companies, definitely prepare for the puzzles and quizzes, but for a more smaller one (let's say sub-100 people) go for the side project approach.
Exceptions do apply obviously: I've had friends who got hired at FAANG because of a side project that grew and got the attention of the engineers at said company.
The most common reason for me to ditch a side project is that I've gained what satisfaction is to be gained from making it. For example, I want to try or learn some new thing and convince myself I can do it. Once I'm far enough to know how it works (even if it's not really doing much yet), I'm satisfied and I can move on to the next interesting thing.
That's why I have basically no side projects to show off..
Just redefine the scope, or the success criteria!
If the project's purpose was to learn or experiment with X, it doesn't matter that it's not a polished product, it still served its purpose and as such can be considered done.
What is finished anyway? Are projects ever "finished"?
I've interviewed well over 100 people and I can count on the fingers of one hand the number that even mentioned some kind of side project.
This doesn't even have to be fancy, even just a list of projects on your own personal site with links to Github and what you learned/what you hoped to accomplish.
Having the public list is also good as many times the projects might be done at the behest of a company or you don't have a good way to "show" them so it's your chance to write them up and get "credit" for your work on them.
I always qualify this as "just in case you are interested", but they are almost always interested. Nobody wants to talk about a bland resume; they'd rather talk about the things you found a genuine interest in.
I've showed off circuit boards, half-baked Android apps and referenced webpages during interviews. It always helps.
A couple years ago at an interview debrief, the HR guy said, "Oh, the candidate told me that he was writing some kind of software to automate his home. Who would do that? Weird." And every developer in the room looking at each other and saying "and you didn't think to tell us that?"
It sort of wakes people up out of a traditional interview expectation and instead they now have to actually listen to what I'm saying rather than going through canned questions and answers.
Developers (or PMs) who are interested in the business they work in and participate actively tend to get promoted/pushed. You have to understand the business perspective if you want to move up and get away from the thought of "I'm just here to develop and if I make the product great, everyone will recognize my talent/skill"
I get what you mean about not even really needing the project to work, just show that you have an idea and wanna work on it, yadda yadda, but I think you'll eliminate some good candidates and hard workers if you see a lack of side projects as a lack of devotion or work ethic.
Do we really need to start shaming people that actually do cool stuff?
[1] https://erickhun.com/posts/why-you-should-have-a-side-projec...
If I had to pick languages that changed my thinking the most, they would probably be: Haskell, Erlang, Clojure, Prolog, and R. Unique languages like Erlang/Elixir and Prolog can be "10x" languages - they were written for specific purposes and if your problem fits that purpose it will be much easier to solve than in most other languages.
> Lesson 0: Programming in a void is worthless
100% true. If you are trying to learn a language without a goal, you'll probably never graduate from tutorials. Imposing your own requirements/boundaries, just makes the learning part more engrossing and you'll make connections which you won't otherwise. Iterating as fast as possible is worthwile itself.
If you want to grow as a programmer even more, try to convert that side project into a paid one. It definitely changes your view of the world. As programmers, we want to see elegance in code but real life is messy. We want to separate the world of programming from the human life and sometimes for good reason. You might find satisfaction in writing pure code (and that's great) but there's an opposite world too which will humble the strong opinions within you. Haggling about microservices vs monoliths seems trivial in the grand scheme of things (the customer doesn't care!). I still debate about this with fellow devs but at the end of the day, I really don't get stressed about it. For me, programming is pretty much only about building solutions to existing problems which improves my or others lives. Everything else is just an opinion which will not be considered until its time is due.
> Lesson 2: Organizing my thoughts is important, but tricky to figure out
Agree. Especially difficult if the software doesn't structure the knowledge in the same way as we think. As a dev, I have never been satisfied with any specific solution. But don't fret honestly. It's unlikely that any given piece of software will work for all your cases. Always take the context into consideration. Plenty of times I work on paper if what I'm thinking doesn't go into a specific tool. Don't try to fit yourself into a box when your mind itself can't. That said, a mindmap (big picture) + a task manager (big picture broken down into specific tasks) + a note taking app (learnings + thoughts derived from completing specific tasks) covers most of my bases. For publicly available information, I store it in a tool of my own making[1]
How did you decide to start a company around the idea before launch?
It was mostly a personal itch. I had been using Pocket for sometime but it honestly wasn't cutting it anymore. I built a smaller app over the Pocket api but as time progressed, the app diverged more and more. Once the Pocket api just became a glorified database, I decided to go all in. I waited for other solutions to come around but none were satisfying enough. After 5 years I had enough, talked to some people who expressed similar desire and that's when I jumped in full time.
saved serches -> saved searches
I feel the same way.
However, I take it one step further. I lose interest after I create the one core feature that drew me to the project. I've made shoot em ups before, but I wanted to do one with enemies that flew in like Galaga. After I replicated the first few patterns, I lost interest. You couldn't even shoot the enemies, but I already knew how to do that.
I'm currently taking a side project and going to attempt to make a business out of it. As far as building it goes, it's basically the culmination of about 5 other side projects I did over the past couple years. So I've been able to build the MVP extremely quickly.
I totally get and appreciate the "don't code outside of work, have a life", but at least for me, side projects have been very valuable.
It can be fun to built something without the 'overhead' of Sprints, standups, team meetings, design documents,.. :)
But you're right, it happened to me a few times as well and people assume you "just know". :P
[1] https://embit.ca
These are the times when I really find a yearning to write something and I want to put a bit of time into a side project like learning Godot, or writing a desktop GUI based program with Rust.
I just need to be doing something different with my day job to have the inspiration and energy to code when I get home, unfortunately at the moment I'm coding at work again, and when I get home I will stare blankly at the screen infront of me if I try and write more code, even in a different language.
I definitely recognize that not everyone has the energy to code at home after a day of coding at work. Often, I don't either. Side projects are a varying thing for me. I do try to make sure what I do code gets documented in some fashion, however.
The only way to account my progress is through github commits. I love the color green. ;)
Would love to get feedback on my blog http://codingbbq.github.io. Cheers.
Generally I find side projects are either about learning a new technology/language or making something that should exist, but not both. It's important to be clear which is the primary objective.
If the objective is to make something, pick the most familiar language and libraries, bang it out, and ship it. If the objective is to learn something, for sure pick a real project to focus your efforts, but understand it will take longer and the end result probably won't be amazing, though hopefully you'll learn a lot in the process.
To what?!?! D:
> Which means I’ll be able to use it for more things, and hopefully get that tight feedback loop back in place.
I wouldn't say worthless, but there's a world of difference whenever you have a practical use (or someone else's use). It forces your brain to focus and go broader at the same time.
* At work its better to hurry than get anything done.
Regardless of language if you work for a company of greater than 1000 people there is a certain nearly identical way of doing things. This way of doing things is based upon a combination user platform, quantity of developers on the market with a particular skill, and a need to pretend to be busy even when you don't actually accomplish anything. In most of my experience the platform was the web and the language of choice was Java (even though Java is not a web technology).
When you are working on side projects there are only two goals: don't waste your own time and produce something of value. Nothing else matters. And so you learn to become very productive and extremely focused on what you ship to production, because you would rather be playing games or drinking a beer than pretending to be busy.
The corporate world doesn't work like this. Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive. Maybe if you work twice as hard your bonus will be 5-10% bigger. Maybe if you deliver code that is perfect in that it never requires maintenance and never churns defects you can spend more time reading about foreign places on Wikipedia.
Frustration sets in after watching the corporate approach continuously releasing defective code into production because its important to hurry instead of write things down or write the code correctly the first time. You could always suggest a better way of doing things, but since there is no motivation to do things better all you are really accomplishing is frustrating other people.
* At work don't reinvent the wheel (if somebody/something is capable of doing your job then let them do your job)
When you are working on side projects there is nobody there to do the heavy lifting for you. You can figure it out or it simply isn't important enough to get done. It's the same way with risks and product performance. People who haven't spent time on personal projects or with equity at a start up have no motivation to try harder. That is why there are giant frameworks and a couple 1000 open source packages in your corporate application to solve simple common problems developers are unwilling to solve themselves. Nobody working on a public personal project will build around something like the 1000 ton hammer of the gods that is Angular or Sprint MVC, but you will certainly find these in public facing enterprise applications where developers have no care about punishing their users in exchange for easy.
* You are more productive not doing work
A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard. This could be planning, brainstorming a new feature, reflecting on a past feature, or putting things together in a new way to envision defects or refactoring opportunities. That said, its more valuable to work really hard to accomplish a feature or solve for a defect and then back off from the computer. You haven't stopped thinking about the application, but now you are thinking about the experience or new ways of doing things that you would never think about purely looking at the code. In the corporate world you are extremely lucky to find documentation much less anything like planning or feature engagement from the developers.
I’ve consulted in a lot of large enterprises, and this is really untrue. If you’re happy just stagnating and some level that you’ve decided is good enough, you can get away with it for a while. But such people absolutely don’t develop their careers. They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them. You also can’t do it forever. Most of the time when I go into a new organisation, I find groups of these people. They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore. I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
Being more or less productive is defined by - in no particular order - your salary, workplace culture (a due sense of agency and feeling respected,...), your own intrinsic motivation to choose a particular career path and personal circumstances that keep one at a job (usually household debt in any way shape or form).
Contrast that with the fact that digital tech today is an industry in which a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years). The net result is that most people burn themselves out in a race they can't hope to ever finish.
So the notion that "you must keep up at all costs" is unsustainable to put it mildly.
> They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them.
And that's totally valid. Why do people need to forcefully "climb the ladder" through promotions? A promotion isn't just a reward, it's often a serious career change that comes with serious challenges.
If someone wants to move vertically in a particular role throughout their career - say, as a developer - then that's totally fine too.
If someone isn't interested in spending time at home working on OSS projects - even when their employer provides incentives - then that's fine as well.
> They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore.
That's a bias. Not every large organisation operates like a silicon valley style start up. Not every organisation has "building cutting-edge software" as a primary mission.
Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech, they are interested in robust & proven solutions that last a very long time.
A large chunk of software engineering is boring and slow moving for a good reason: because breaking things comes with serious real world consequences.
Case in point: there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
> I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
Anecdotal.
If he works at a cinema, that might be because he can't simply move to another area with more swing projects (family or other concerns), or because he genuinely got tired and wanted something else, or because he just doesn't know how to promote himself properly - it's not his strong suit - and he turned to LinkedIn just recently.
Unless this is a close friend, you do not know half of this person's life and their decisions. Assuming x because y, well, that's just jumping to conclusions, isn't it then?
No, I’m simply debunking the parent commenter’s assertion that “there is absolutely no motivation to be productive”.
> a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years)
This is a major exaggeration. I do a fair number of node projects. I did my first one ~8 years ago. I don’t think I’m close to doing my last one, and it hasn’t been hard to keep up with the changes in that time.
> Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech
I feel like you haven’t worked in a bank or airline before. Most of them have ancient tech in their core infrastructure, but a) they’re not happy about that, they just don’t know how to change it and b) a vast majority of their technical workforce will have no contact with that at all. Your average sized bank will typically employ 0 DB2 DBAs (they’ll all just be contracted from IBM), and a very small team of Cobol devs. You could work writing code in a bank for 10 years and never meet one. Banks and airlines are constantly trying to modernize (especially since they’ve realized how much money they can save by employing SREs/DevOps engineers). They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
> there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
No you can’t. Today’s COBOL engineers are the ones that survived getting laid off when banks decided they didn’t want to invest in COBOL anymore. There’s essentially no entry level COBOL jobs on the market today.
> you do not know half of this person's life and their decisions
I know he got laid off, and that he’s been looking for work since then. I also know his skill set is no longer in particularly high demand. I see this happen all the time. A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
> might be because he can't simply move to another area with more swing projects
There is really no such place. There are still companies that use technology like that, but the number of them is shrinking every year, and people aren’t using it for new projects.
The bottom line is that even in large inefficient organisations, there is still a strong incentive to be productive and to invest in developing your own skills. Most people expect their careers to last 45+ years. Even if it takes 10 years for your skills to become obsolete in a slow moving organisation, you’d still have to spend the first 35 of those years developing your skills.
That depends entirely on your context. Debt, disability, dependents, other personal goals,...
Not everyone can easily spend nights and weekends following what goes on in the JavaScript, Go and IoT space at the same time.
> a) they’re not happy about that, they just don’t know how to change it
It's called "opportunity cost" and "risk management". They rather stick with what works - the best of all the worse alternatives - instead of stepping into the unknown. Personal happiness on the part of the staff is subservient to that strategy.
Don't confuse the opinions of the tech staff with the mindset upstairs.
> b) a vast majority of their technical workforce will have no contact with that at all.
Goes without saying.
> Cobol devs
I choose COBOL and Perl as random examples of niches. There is tons of legacy infrastructure to be maintained beyond COBOL and Perl as well.
> They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
Of course they do. But shiny tech only gets to be implemented in place where failure is factored against the potential gains.
Put differently, a mobile app being unresponsive for 15 minutes is an annoyance. Banking or medical records getting corrupted or lost, is a disaster that simply can't ever happen.
> A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
That's bad management based on short-term thinking, and it has absolutely nothing to do with technical skills.
Modernization isn't about the tech, it's about reducing costs. Employees are seen as a liability. Always. And so lay-offs and modernization go hand in hand. The hidden cost is the loss of institutional knowledge and culture.
Instead, they try to cheap out by bringing in consultants, like you, to do work on a per-project basis. But that doesn't create any institutional knowledge. Instead, it makes them utterly dependent on the volatility of the consultancy market.
Down the line, what you get are stories like the trainwreck which is Boeing.
Even if those employees did spend time learning Node in their free time, they would still have lost their jobs. Simply because their salaries, and the protections & benefits that salaried employers enjoy, made them unattractive.
And those who did learn, well, they left long before the writing was on the wall anyway, because the only reason reason to invest time and effort in your own skills is for your own sake, not the sake of your employer.
Finally, working for yourself, or working as an outplaced resource comes with many drawbacks. It may work out fine if you are healthy and you're in a situation that allows you to do that type of work. But those conditions can change at any time.
Private corporations and enterprises aren't charity. It's sensible to reduce costs as you go in order to stay competitive. But when corporations do that in such a way that the labour markets get stiffled, income levels stagnate or decrease and the fabric of society gets pressured, well, that's just predatory capitalism.
If you can live in such an environment, then that's great for you. But judging others because they struggle? That's a hard nope right there.
Given the choice what is better: developing your career or your skills/competencies?
Many developers learn some tool or giant framework instead of actually learning to write code or how to do their jobs because they are in a hurry to develop their careers. I would rather work with competent people who are less in a hurry to artificially justify their existence.
As an example in the real world nobody advertises their experience with a screwdriver, but the opposite is true in software. People will frequently advertise their limited value as a React or Angular developer. It’s clear they know how to use a tool, but can’t write an application to save their lives (or careers). Why should I not find that frustrating, particularly when these giant framework applications suck and these developers are immediately hostile to original code?
In that kind of work culture I could be 10x more productive, but if it’s met with hostility and not rewarded what’s my motivation to do anything more than be barely awake?
GP was saying that you only develop your career by developing skills. React is a skill, so is Angular, so is the wide world of front-end web programming.
I do know all of those things. I still think React, Angular and other frontend frameworks have a time and place.
This advice I consider to be the most valuable programming advice I have ever received.
Code can be a distraction from the process of coding. It is way too easy to got lost in the minutiae of how things are to be implemented and delude yourself into believing you are making progress when you don't know what you are doing. The saga of the Sudoku solver [1] is a pretty well-known example: the coder in question spent an awful lot of time redesigning the implementation of the game board because he didn't know how to actually solve anything, and yet changing the implementation looks like progress without making any steps on the actual problem.
[1] See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for mention of it.
The people that do the decisions and prioritizations are usually just as smart as developers, but have different priorities.
It’s often more lucrative for a company to release something early even if it’s beta quality, since business knowledge is a very lucrative commodity. The company will know more about its customers, how it can help (or exploit) them better.
And things get more complicated when you have multiple teams. Yeah you can spend a sprint or two to polish things now and save yourself 4-5 sprints worth in the future. But if there are 4 more teams waiting on your deliverables, it might be a worthwhile trade for the company as a whole.
Understanding where your own team fits inside the huge structure of a big company is of course the PM’s job, so you as a dev don’t have to know about it. But thats a lot tougher than figuring out estimates is for us, and even more disruptive if gotten wrong.
Estimating a dev task deals with a lot of unknowns. Building a sequence of tasks for teams to follow takes _those_ as input and needs to produce something thats not just pure chance. I don’t envy that one bit.
Once I started to get the bigger picture into account myself as a dev, it became much easier to go along with those decisions and to know when I can push for good quality stuff and where to leave it be.
It’s the whole “let me help you achieve your goals so you can help me achieve mine” thing and has made my life as a dev much more pleasant.
This is true because, you must create the program of how the computer and the user will interact. You must program the computer and program the user, their interaction.
There are always many different ways to do that. And the choice, or invention of how that happens really determines much of the success of the product.
It has to be easy and intuitive for people to use the app yet empower them to accomplish great things. That is no small feat and it is the most important one.
I'm currently trying out vimwiki. Let's see how that goes.
Over the years I've tried so many tools, languages, workflows, and the only ones that stuck were the ones that were boring but timeless. I've not just been gravitating toward OrgMode for all my note keeping, but I've also gotten more and more into bash for much of my stuff.
There are downsides to that, of course. It's frustrating that I'm mostly limited to text-only things, for example. But it feels like any investment into bash/emacs+orgmode/emacs+tramp/emacs+? offers so much more than becoming reliant on app number <x> that quite possibly disappears or stagnates.
Why do you say you're limited to text-only things? Org supports links, images, code blocks, spreadsheet-like tables and such. For me the experience of migrating to Emacs+Org was more of a liberating type.
* To make sure that it actually is correct. Multiple times I discovered when reading the documentation that I only had guessed it sort of right and that there were some key bits of info that I had missed.
* To make sure that it is complete and that it gives just enough background information for those who want to use it without being in the exact situation that I was in. I.e. for myself in a couple of weeks/months.
There are more benefits. Like being able to structure it exactly the way you like it with links, tags, search, etc. And that you can show it casually to potential employers, who won't read a letter of it, but they can see that you actually put in work and understand some topics. This last point can also work for friends and colleagues.
In a quest to find ways to manage my focus, I've also taken up doodling. It's proven to be a good way to help keep me from falling down internet rabbit holes nearly as badly as I used to.
"Give me modularity or give me grep!"
That saying was intended to showcase the importance of modularity, with the idea that you shouldn't need to grep good code. But my personal experience is that if you have to choose, grep wins, no contest.
Information is different than knowledge, and part of the challenge of acquiring knowledge is being able to get back to information you know you've seen in the past if it seems relevant to something in front of you right now.
I also very well remember my joy after I "invented" the AMQ, only to later find out about ActiveMQ, RabbitMQ etc. (which didn't diminish that "proud" feeling)
Good work!
And starting with #0 adds street cred.
The short answer, though, is that I knew I wanted green in the color scheme (due to having grown up in the tropics), and I liked how James Hague did his blog https://prog21.dadgum.com/
The rest was just iterating on that.