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!

• 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.

Don’t be afraid of failure.

Learn to learn new languages quickly. You don’t need to be an expert in every language you need to recognize the pros and cons of different languages the same way you would with any tool.

Don’t get hung up on one language. It shouldn’t matter what language a job is in if you build the ability to learn a new language fairly quickly.

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)

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.

Ask questions

“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

deleted by creator

!remind me 2 hours