What eight years of side projects have taught me (2019)

Same here, though I've been chugging along for 34 years. Used to write all kinds of software to try out new languages/ideas, but that all changed once I went down the rabbit hole of designing my own language. Since then, I've mostly been trying out different host languages, features and implementation techniques. I figure once I get to a point where the language is good enough, I'll go back to writing all kinds of software but in my own language. It really doesn't matter that much, the journey is the goal, you do whatever it takes to stay motivated and keep learning.

https://github.com/codr7/gfoo

What my years of side projects have taught me:

* 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.

> 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.

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.

I put all my notes and bookmarks in my self-hosted bookmarking site https://github.com/jonschoning/espial . I definitely agree with the author that the combo of tags, search, the feed, and notes is very effective technique that I sure every day.

I can relate to the post, having just started for couple of months now, learning to write code for your self is satisfying. I have followed several youtube videos to learn programming language, but the fruitful results only come from working on side projects/challenges etc.

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.