11–20 of 272 posts
> 4. Use frameworks and customise them – only refactor/build your own when absolutely neccessary. > 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.
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.
> 4. Use frameworks and customise them – only refactor/build your own when absolutely neccessary. > 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.
For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. 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 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 enti…
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).
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.
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.
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.)
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.