That makes sense. Ok now explain rebase vs. merge like I was a dim toddler.

The toddler version of the difference is related to history again. Both commands combine commits from one branch into another. But rebase does it by rewriting history so that your history is cleaner. And again, the main danger is that when you rewrite history you want to make sure you're only rewriting your personal history. If it's shared with other people bad things can happen.

Why would you want your history cleaner? Wouldn't you want as many rollback options as possible?

I think of rebase as your changes are always the "newest" changes, even though they might have occurred earlier in time. It applies your changes after merging in other changes from master (if you're branch is off master).

I almost never use rebase but I don't think it changes the number of 'real' rollback options. It just rearranges them and applies them in a way that makes your history easier to view and follow. There's some value in that when doing things like git bisect or just in seeing commits in a simple ordering.

The only time I use rebase is when I want to squash a bunch of messy commits into a cleaner logical commit.

The common scenario for rebasing is: two people are working on completely different parts of a project, not touching the same files at all. Person A pushes their changes, Person B will either have to merge those changes in, creating a commit that has no diff, or they can rebase so all of Person A's changes get applied to their local, then their HEAD is now up to date and they can push without having to squash away that worthless merge commit.

Having never used git or anything like it, I figure I probably should and I did a little reading.

As a solo developer, this basically gets me ability to snapshot / rollback a folder tree to various points in time where I told it to take a snapshot?

It maybe gives me ability to keep a folder tree in sync on two or more machines if I want to work on the same thing from both (not clear on this?). I can do this with just SSH access? Can I do this with only SSH server on one of them (linux with sshd and windows with putty)?

It stores all it's info in a .git folder at the top level of the folder tree, so a filesystem backup of the folder tree contains all git data also if restored?

If I create say 10 new files and folders, I must "git add" them all manually one by one or they won't be tracked?

The answer to all of those is yes with a caveat on the last thing, you will have to add them all but when you add a directory you add all the contents of the directory as well. So, `git add .` will stage all those new files for commit. If you have some files you want to exclude from committing you'll want to know about gitignore.

It's great for keeping work in sync between machines. It makes branching very easy so you can experiment with your code with much less overhead. if you think of git as a database of your code then git add is how you get stuff into the database. There are 17 million videos on git basics out there.

It also gives you the ability to try little experiments, via branches, that you may or may not really want to keep.

You don't really need to run your own git server - there are lots of online options, probably github is what I'd do, that support a lot of functionality and if you end up wanting to distribute your code or accept help from other people, will let you do that.

This has just never seemed like it's worth it. Who cares about the merge commit?

I get the impression that it's only the really aspie types that care about merge commits

I'm thinking of joining a coding bootcamp, I know this has been discussed before but not sure if there is a dedicated thread.

I have worked in technology for ~5 years with 90% of my responsibility being net new sales and business development/marketing, but 10% has been figuring things out on the fly and occasionally having to do things from trivial to medium complexity involving writing code.

I was a member of executive leadership at an open source web development shop and I'm very familiar with higher level responsibilities in software engineering. I convinced my CEO to move from off-shore to in-house engineering, was deeply involved in that hiring process, and also convinced him to go from waterfall to agile, I had a major certificate issuing scrum organization as a client, and have led technical demos to people like core team members of the most popular open source database that kinda rhymes with MostBest, have sold an early msft engineer billionaire on using open source, wrote an SEO migration for a company that gets >1M visits a month and competes on words related to SEO, I've also built a half dozen websites myself using Drupal and Wordpress.

So I have a lot of unique experience and I'm looking to use a coding bootcamp to fully immerse myself and change my career trajectory. My plan would be to work as a software engineer for 5-10 years and then likely start founding startups for life being competent at both business and technology.

Are there obvious flaws with this plan?

I'm assuming since I'm willing to take a low salary (80-90k) in my first role out of this bootcamp and they claim people are getting that with zero experience that enter with no clue about technology, that if I go all out and learn as much as possible and go above and beyond, I should be able to easily get a job?

Once I am done the bootcamp I plan on contributing bug fixes and features to open source projects, gradually taking on more complex work as I increase in aptitude.

The one I'm looking at is General Assembly, they seem to have a ~decent reputation, the timeline would work really well.

Yeah, not me

There is a thread about bootcamps.

If you are going to go, I'd only consider the most highly rated ones. Check your network of engineering managers to see how many of them would hire bootcamp grads, and which ones they'd recommend.

I don't know if you keep up with the trends and discussions on HN, etc., but I wouldn't rely on old information (i.e. more than 1 year). People's perceptions of bootcamps seem to be changing a lot. And as more engineering managers get experience working with bootcamp grads, it could change future hiring rates considerably.

I think another viable path for you may be a customer-facing engineer role. Helping customers integrate the product in a consultant-type role. Companies have trouble hiring for the role because few traditional engineers want to move into it, and it requires skills that many of them lack. Also, if they're very good engineers, it doesn't pay as well as they could be making.

It would give you an in and let you work somewhat closely with an engineering team, work on the codebase (maybe) and learn software development practices while you continue to develop your skills. If you pick up some basic developer skills, you might be able to get someone to stretch a bit and hire you right away.

Yea I figure worst case I will be a Sales Engineer after the bootcamp, which I could probably do now, but ideally I really want to be part of a team of software engineers and build stuff.

I'm very familiar with what you mentioned, when we brought on clients I was usually the one going through 3rd party API docs and writing the plan for integrating Drupal with these applications. That **** really isn't that fun though and maybe I got burned out by stuff like Marketo's API not doing things in the order you send it stuff and having to constantly figure out workarounds because no client wants to switch their ancient way of doing things.

Ideally I won't have to be client facing as a primary element of my role. I really just wanna learn and build.

Do it. The people that don't do well after boot camp don't have the same level of demonstrated immersion that you do.

With your background and sales ability you'll get hired extremely quickly and be able to command a top end starting salary

This is a great and courageous idea - I'm on a similar path with a similar goal though yours would be much more drastic as I was always an engineer and never stopped doing it despite having more or less transitioned to a strategy/product/exec combo role in the last few years in my last job. I don't think the question is about whether this path would work or you could get a job - I have no doubt about this - but whether you want to put your ego/psyche through this and how you think you will respond. Some of the more repetitive grunt work that's kind of low-impact from the big picture perspective - which you may be uniquely qualified to understand among your peers - may be quite demotivating if you're used to being in a higher impact role with input on the higher-level decisions.

Why not just skip the bootcamp/interim bull**** and spend 3 months working on open source projects you find interesting, while you look for a startup to join as a junior engineer.

Keep in mind that most startups usually are a combo of build/sell, rarely does one person function in both roles and the people who even have the flexibility are very sought after. (IE CTOs who can articulate business use cases and function as enterprise account managers.)

I think you shouldn't have such a rigid plan and instead just startup. @FakeGrimlock has some good advice on this: "ME, FAKEGRIMLOCK, SAY BEST WAY IS BE STARTUP. BE LEAN. FIND MARKET. ITERATE UNTIL AWESOME.

NOW.

IT TIME FOR STARTUP YOU."

Def a viable and solid fallback plan. Technical sales roles would be the higher paying alternative.

Seems like you got it. If you wanna be the build guy in a startup, it'd prob be useful just to join a startup and see how it actually works rather than joining a larger team. You'll get much more practical experience being the junior dev on a two person team with 200 hours of work to be done each week and seeing how someone decides which things to totally ignore rather than joining a more evolved team that is trying to un**** all the things that were initially ignored.

I've worked in startups before and my last job I was employee #1 and my chair of the board was the CEO of a different 15 person company and she had previously exited as the CEO/founder of a 3 year startup that raised 3M and sold for 75M.

I'm not capable of working on open source stuff in any sort of impactful way on my own, and learning completely on my own will make much longer than 3 months, likely at least a year, and I wouldn't have as compelling of a story as going though a bootcamp if I was 100% self taught. I'm not trying to just work at a **** tier startup. The places I interview are YC startups, experienced entrepreneurs, and through the talent dept of major VCs.

I would be totally fine with doing grunt work, as I understand it would be completely appropriate and serve as a stepping stone for me. Even in the rare case I somehow felt like I wasn't learning, I would at least be becoming more comfortable working with code and could devote nights/weekends to doing more stuff.

In the next week it's looking like I'll be having the choice between a 150k+equity sales role for a startup that just raised a Series A, and doing this bootcamp. If it comes down to it, may be a tough decision but I think longterm the bootcamp would be the right one.

Could you explain what you envision you'd be doing as a founder in your future startup? It sounds like you envision being able to build a MVP in a meaningfully complex industry then transitioning into a more traditional CEO role. I'm just not sure I understand why you think you need 5-10 years of engineering experience to become an entrepreneur.

I also don't understand why you think you'd learn more startup apropos engineering skills in a code bootcamp rather than actually working on a problem. But to each their own. (Is there not a way to follow the framework of something like this on your own?) If you think that the bootcamp is 4x as effective as actually working on a product, then def do that if you think you need half a decade of expertise in engineering to head out on your own endeavor.

I'm with Mihkel. I don't think 5-10 years of engineering experience is going to be a very good return on investment for what you want to do.

If you want to do your own startup stuff, it sounds like you already have the skills to find a good technical co-founder. Try to do that?

Edit: I also know a bunch of founders that learned enough about coding to solve a very specific problem for their early start-up. Think, enough to build an MVP of an app / product / whatever in one specific technology. Then when its successful they were able to raise money / find better talent to make the next version.

Keep in mind that the Google MVP was built with arguably one of the worst imaginable technology stacks and was so buggy that it was almost immediately rewritten by someone else.

If you have a reasonable idea and some of the other skills necessary to build the business, you can recruit a talented technologist to solve some of the difficult problems. Or you can solve problems that have nothing to do with technology. (Selling people iPads.)

I don't think it's a given that you can find an open source project and work on it for any amount of time and learn the same breadth of information you would from a good bootcamp. Bootcamps should be designed to cover more edge cases than you'll find in an OSS project. What kind of tasks are you going to be given on an active OSS project and who is going to be making sure you are learning new things and not just trying to parse last names correctly or some other scut work? Whether Larry needs it to be a CEO of a start up is another question but I don't think there are very many people or projects that are going to give the same level of experience as a good classroom for the same amount of time.