The tech stack Crappy/lacking/out of date documentation Can't get the project up and running locally or it's way too complicated a setup Unfriendly/condescending contributors on the project Not wanting to deal with someone's mess (poorly architected solution) Poorly maintained/managed project - coming to a project and having no idea where it's at, or if it's even actively being maintained. Complete overwhelm in not knowing where to dive in! Lack of development workflow, coding standards, and/or too many "cowboys" on the project (ie: no team cohesion). I've been looking for a while now for an open source project I feel comfortable and motivated to contribute to. Hoping that knowing what prevents me from working on others projects, that the upcoming open-source project that I want to start will be more welcoming to new open-source contributors.

I believe there is a need for a product like this. There was a PM at the coworking space I was working out of that was asking around for this type of software. It seemed like there was no product offering on the market for what he was looking for which was measuring how effective his remote developers were. He was also asking at our dev meetups how you would even measure such things, let alone, how effective those metrics would be at truly measuring their performance. Lines of code (or lack thereof)? Test coverage? Bugs killed? Features implemented in xyz timeframe? Code stabilization (going from putting out fires that prevent you from writing new features to actually writing those features)? Would those metrics change as your product becomes more stable? What would have to happen for those "goal posts" to move? I think a product like this would fit better into the corporate model (IT department vs a startup). There's already metrics set in place for most IT departments for performance reviews. I think having a product like this in the enterprise (large(r) corporations) would help them let go of enough control so that their employees could work remotely. Floors me that in a market like Vancouver, remote jobs are incredibly rare to find - especially when there's a "brain drain" happening because of the cost of living. I'm all for anything that would help increase the amount of remote work available!

That's the one! I decided to purchase it as an introduction to startups and the idea of MVP's. My first two reads of the book (I've read it 3-4 times now), I completely skipped the middle section on Technologies because I'm an experienced developer/dba/server admin and figured it would be of least value to me personally. Thankfully, I don't have the mindset of "I already know that" and did eventually go back to read the section that I had skipped twice before. Surprisingly, it ended up being the most valuable section of the book for me! Mostly because it validated my thoughts and feelings about web development that I had expressed several times over the years, only to get shot down by others. It's quite frankly, a book I wish I could have thumped a few bosses, team leads, and senior devs over the head with throughout my career ;)

hello, startup by Yevgeniy Brikman Surprises me that I've never seen this book mentioned anywhere, let alone on anyone's list of "must reads". It popped up as a recommendation on Amazon after it was released in 2015, and I am so grateful that I added it to my cart that day. The "Choosing a Tech Stack" chapter is something I think every developer should read. Highly recommend the book, even if you're not into startups.

My favourite thing to do (and what I do in my "spare time" when I'm "not coding"), is sit on a cafe patio early in the mornings, sipping coffee, reading computer books. I do it at least three times a week for upwards of two hours each visit. It's mostly books on theory that I read because I learned years ago not to buy books on a specific version of something (because it'll be outdated by the time it hits the stores) - unless it's a language that I want to dive deep into or something completely new to me - like React or Laravel. I find that even "dated" books have relevant material to learn in them. Most books, provided the content is good, I have read 2-3 times from cover to cover. I literally study the sh!t out of them until I've absorbed and fully understood the material! I even have a colouring system when using sticky notes in my book so I know where to go back to, and why. Over time, most of those sticky notes come out as I start to grasp those concepts and/or incorporate items from the book into my projects, helping me to solidify and know that I understand the material. I spend a fair bit of money each years on books. I hate that I have gotten rid of many of them over the years because I'd have quite the museum of computer books if I'd held onto them all! I don't know if it's because of not growing up in the digital age, but I simply don't absorb digital material the same way I do as reading a book. I also learn from watching others work. You'd be amazed some of the cool shortcuts you can learn just by watching someone else work, and when they have a pause in their concentration asking, "hey, that thing you did back there that did this, how did you do that!?" I learned PhotoShop by watching a couple of my former roommate's work sessions and asking her questions at appropriate times.

I feel it's well worth the $10/month I pay to know that all my work is "backed up" and that I'll never lose it (again). It gets backed up locally as well, but not offsite - that's part of why I use github. The other parts being it's a standard in the industry and pretty good at doing it's job! If you don't want people to be able to see your code, upgrade your account and make your repo(s) private. Then, if an employer needs to see your work, you can either grant them full access to your project, or you just send them snippets from your codebase without sending them the whole thing. You have every right to tell an employer that no, you will not send the entire application but you can send snippets. If they can't respect that, that's a red flag right off the bat for me that they are a crappy (and potentially unethical) company. On (and off) the internet, nothing is stopping someone from ripping/stealing your idea. If you feel strongly enough about it, you can seek legal counsel on how best to protect your idea.

As someone trying to build up a business: to keep my startup costs as low as possible. I somehow had not seen Vue.js referred to as open source until very recently and have started learning that and halted work on my projects that I'd been writing in React.

Not advice but I was once interviewed by a CTO that thought React was the bestest thing in the whole world and way better than anything else because...... it had state and props! which he stated with much glee on his face!!! while I sat there a bit puzzled!? I had only just finished reading my React book the evening before my interview and wondered what I'd missed in the book because.... maintaining state on the web is nothing new, nor is passing properties.... Then I was told that I "didn't have enough experience" even though my experience spans into those early days of the web when we were having to figure out exactly how to maintain state on the web. While I was in that city, the "advice" I kept getting as a LAMP developer was to learn React because "PHP was dead" (to them - mostly startups using React), then I move back to Vancouver where it is pretty clear that I should have spent my time learning Laravel instead.... I plan on picking up Laravel next calendar year because I seem to be much more employable as a LAMP developer with 20 years experience than as a React developer without any industry experience using it (and I've recently started switching to Vue because it's open source).

My answer since none apply above is "No, already took it in college." And no offence, but I would not spend money to take a course from someone who's own grammar needs improving.

First off, you are human and not an encyclopedia! I did a lot of copying and pasting of code early in my career of the syntax's that I could never remember. I realized at some point that I was not learning those lines of code at all because I was being lazy by just copying/pasting them without really "saving" them to my own memory for the next time I had to use those lines of code. If you want to be able to get to the point of being able to type those lines of code from memory, rather than blindly pasting them into your editor, open them up in a place where you can refer to them instead, and type them into the editor yourself. This is when having more than one screen comes in very handy! The more you type the code yourself, the more you will remember them in the future. I don't know of many developer's who don't have to look at documentation from time to time because they've forgotten (or quite simply, don't know) something. IMO, being resourceful is much more valuable than having an entire language memorized! This is why it is recommended that with whatever tutorials/books you are consuming, that you type out each of the examples on your own. Repetition is required if you want something to stay in your memory. You don't learn how to play a sheet of music by listening to someone else play it - although, that can be a valuable part of your learning process! Quite frankly, you will learn more from your mistakes than from everything just working for you without any errors. Once you get "burned" from one "stupid mistake", you generally won't make that mistake again.