• KISS is waaaaay more important than DRY. Avoid tricky maneuvers at all costs.
• ALWAYS write tests if you are serious about a project.
• Take time to plan the architecture of your project. Keep code related to a feature close. Keep code from different features apart.
• DON'T EVER spread a feature across a bazillion of files and directories. This will make it a pain to maintain it. This is actually the same advice from the last item, but it's so important that it's wort mentioning twice.
• Give priority to advices coming from experience. Some "good practices" you hear about on the internet are pure bullshit.

Here are 5 things I hoped I knew from the beginning:

---

1) No matter how fancy or popular a new framework or library might be nothing can beat vanilla/simple javascript. Always solve a problem using best possible and efficient approach and not simply by simply following new framework or libraries because they go out of date quite often or npm modules undergo breaking changes most of the times. It is better to keep modules up to date and code maintainable rather than trying to fix bugs at last moment.

2)It is always better to release build to QA or production in the middle of the week rather than delaying it till Fridays and spending your weekends at office.

3)You need to be up to date about latest syntax,features and libraries. So following relevant technical publications on medium, glancing through questions on quora, joining relevant technical groups on facebook and even opening hashnode feed daily or once a week can help you stay relevant on variety of topics.

4)Never try to multitask unless and until you can do it effectively. It is always better to stay focused on one problem/module at a time rather than trying to do many things simultaneously.

5)Every programmers has some "power hours" in a day where they have maximum focus and can be most productive. Some might be night owls and others might be early risers. Irrespective of the times try to figure out solutions to complex/difficult parts of your projects in this hours and then do menial tasks like attending meetings, interacting with team members and other trivial programming tasks later.

Focus / Specialize now. Generalize later.

I am still struggling with this as I want to know everything. Don't bank on Elon Musk succeeding with Neuralink any time soon.

Most answers here are what I would echo, but I'd add one big one:

SECURITY

As a web developer, you MUST think like a criminal. There's no way around it. It's a necessary evil these days.

• Comment your code - not for the benefit of other people, but for your own benefit a week down the line
• Your site will never look 100% the same across all platforms, so don't worry too much about it (no-one uses Internet Explorer anyway)
• Today's shiny is not always going to be around, try to make sure you don't back the wrong framework
• Back end styling is just as important as front end, especially if non-developers are going to be using your work
• Learning the command line tools is never a waste of time

Tommy and Marco have covered most of the points I wanted to mention. However, here are a few learnings I want to highlight.

• Embrace TDD. It saves a lot of time.
• Avoid quick and dirty unless it's a temp/side project.
• Refactor from the beginning (I know it has been mentioned, but I want to emphasize this) as you will never get time to get back to the old code to improve it further.
• Don't say yes to everything and don't agree with the deadlines without estimating first.
• It's best to use pen and paper first before writing a piece of code.
• Automate deployment pipelines and use a CI/CD tool if you are serious about a project.
• Try to finish a side project within a week or two. If it exceeds that, there is a good chance it'll slip out of your hand.
• Find a partner who complements your skills.
• Job is not everything. Find time for self improvement.
• Don't hesitate to take risks as a programmer.
• Perform major deployments at Friday nights only if you are available immediately to fix issues that may arise. Or else deploy in the day time on weekdays.
• Work on open source projects, submit PRs and get them reviewed by the maintainers. It always helps.
• Read as much code as possible.
• Save money and invest in good books and tools.
• Write technical blog posts and contribute to other publications as well.
• If possible, work with good technical editors and publish a book.
• Don't fall in love with a particular technology. Keep an open mind.
• Don't go by what people say. Test/try things yourself and take informed decisions.

• How to CSS (even professionals of many years often don't know about CSS architecture and there are sometimes no standards in place, which makes working on old or big projects really hard)
• How to estimate the time needed for a project
• Plan first, then code (a whiteboard or even just a piece of paper can do wonders)
• Documentation is important (then, I didn't know, but today, I am just lazy :D)
• Split problems into smaller, easier to solve chunks

• today's trendy library often turns into tomorrow's technical debt: try to build projects as lightly as possible

• do things correctly the first time, because you wont be coming back to refactor it later like you plan

• be liberal when forking, backing up, and saving copies of your work — disk space is much cheaper than labour

• you learn more by building 100 tiny projects than 10 large projects, repetition reveals patterns and teaches skills faster than the size of the projects

• there is no end to what you can learn about web development but your lifetime is finite, to stay on top of your skillset you must learn to stay focused

In a more general sense:

• as tempting as it is, never promise anything
• saying no, is a very important thing
• as soon as a sentence starts with "that's easy you just have to" run for cover
• it's okay to ask for help, it doesn't make you look incompetent and if it does you're in the wrong team.
• if you feel uncomfortable .... just leave

As a backend programmer:

• how does time and space complexity work
• different datatypes and strategies
• know the difference between comfortable with and the right tool for the job
• stateless architectures and atomic design are better in the long rund
• code for the domain not for yourself -> if it's a tool for admins write it with configs, if it's for devs write it with a database, .... etc.

As a frontend programmer:

• only a few people know CSS most of us just guess
• declarative is the stable solution if you want to have less work
• don't couple layout to the DOM structure, couple them to classes
• fancy JS is awesome but it comes with a price.
• don't do hype-driven-development :)

I can go on but I already cheated with categories ;D ....