CSCareerQuestions

Finish projects: this will teach you how to set reasonable goals and expectations and how to break down large problems into smaller steps.

Whenever you are facing something you don't know how to do yet, recall a previous time you were faced with something you didn't know how to do and that you learned how to accomplish it and moved forward: this helps me a lot with blockers and imposter syndrome--it shifts my mentality from being lost and not knowing how to keep going to one of "I'm capable of learning, that's gotten me this far, and will continue to advance me."

Network. Lots of great opportunities can come from other devs, who you've developed a mutual respect with.

Don't neglect your personal projects.

Learning architecture, and how to document it, is absolutely invaluable and can get you the big bucks.

Don't overengineer in an attempt to predict the future, and instead build deliberately and flexibly.

Learn to work in a team. Most careers will have you working on a team and it’s important for you and the people around you to work effectively together.

First and foremost don’t be an asshole. I hate that this has to be said. This doesn’t mean you have to be friends with everyone but honestly liking the people you work with all the time does make the job more pleasant.

This might sound cheesy but I recommend reading the book Radical Collaboration. Software breeds a lot of disagreement, so it's important to be able to approach arguments with co-workers with a level head and learn to reach alignment before making decisions.

Most of your job won't be focused on actually writing software, most of it is understanding requirements and building a solution to fit their problem.

Oh, join or form a union if you get a chance.

If you are working in a decent workplace, you will receive lots of feedback on your code and what you do. Don't take it personal and learn from them. Sometimes there are multiple correct answers and yours can be one of them, but each workplace, project and senior colleague has their own concerns and priorities. Sometimes feedback seems to be on a trivial mundane detail, and sometimes it really will be. If you think it is valuable feedback, learn. If you disagree, discuss. Enjoy!

Don’t be afraid of failure.

• Learn how to write and propose ideas.

• Develop empathy with users and put yourself in their shoes.

• Think ahead about how what you're working on is going to be used. If it requires a lot of steps, take out as many as possible before writing a single line of code.

• Automate the crap out of everything you do, so it's a one-line command to build, test, and install it. Your future self will thank you.

I like to not think of anything as "absolute" or "dealbreaker" (within reason. If there's a culture of harassment I'm gone, for example). But spend intentional time throughout your career reflecting on what matters to you in terms of team culture, code culture, career growth opportunities, compensation, etc. There are a lot of factors to being happy in your work, and a lot of ways to get there. Be intentional about it, and try to always move toward it. It matters a lot more than whatever software you're writing.

Organize your knowledge. Identify where you have gaps, and address those. Establish a study plan, make it realistic, and follow it. Know which form of learning works the best for you (e.g. books vs videos)

Understand programmatic approaches to testing, unit testing, test driven development (TDD), behavioral driven development (BDD), and integration tests.

Understanding TDD and practicing it as a new developer forces you to understand the end result wholly. It's one thing to understand how to solve a problem, but understanding how to validate that the problem is solved programmatically, before you have implemented the solution makes you a better developer. It gives you a better view of what you are doing and will change you way of thinking about solving problems.

!remindme 3 hours

!remind me 2 hours

don't do it, become a circus clown instead...

“Perfect” is the enemy of done. Sometimes you’ll get to 90% of a project and discover 20 ways you can refactor it. Sometimes you just need to ship code and not spend weeks tweaking it