Stuff I've Learned

When I was beginning the path to becoming a software developer, I was so full of questions. I looked everywhere for evidence of real people making the transition from regular person to software engineer and I was always trying to figure out what would make me more prepared when I began my first programming job.

As a service to the internets, I'll share my first impressions while they are still relatively fresh...

Don't try and learn all of the things

I mentioned this a little in my last post, but this is worth repeating. There are far too many cool frameworks for a beginner to "learn". There really is no point in touching all of them right now. Pick one and learn it to death. There is no telling what framework or library your future employer will use, so stop trying to cover all your bases. If you've learned one really well, your prospective employer will assume that you can learn another in not too much time.

Have something to show for your work

Don't learn things without trying them out and adding code to your public GitHub repo. If you aren't a genius programmer after 6 months, it's okay. People will be able to see what you've been doing instead of having to take your word for it. There is nothing like being asked for a code sample and being able to send out links to code in your GitHub repo. If you work on learning something for more than an hour, you should find a way to integrate it into your public GitHub repo, whether it means adding it to an existing project or creating a new repo for a test project.

Some things are probably going to be learned on the job and that's okay

You can work on learning Git on your own and you should definitely know your way around it and understand the basic concepts. However, working on a non-trivial project with a team is quite a different experience. You will come across issues that you won't encounter working on your own... merge conflicts, reading diffs, making pull requests, squashing commits to make pretty commit messages, branch naming conventions etc. I've heard that some fancy people have gone so far as to create multiple GitHub accounts and create merge conflicts on purpose, just to get some practice on a non-critical repo. This is actually a pretty great idea, and I might still do this, as playing with your team's git repo is a pretty high-stakes way to learn.

Actually, there are tons of things that will be learned by actually working on a large project with a team, but I'm not really sure if there is a way to prepare for every eventuality. I think it probably makes more sense to not worry about that stuff too much and just work on really nailing the fundamentals, because everything else will come in time.