[keeeeeeeem]

You need to learn how to communicate with other developers and understand their ideas and arguments. Same goes for customers, and management. Therefore my suggestion is to invest time in building up a good working vocabulary of technical and organisational skills. Take the time to mentor others even on small things, it forces clarity of thought and being able to speak about a topic. I have known absolutely amazing developers who can't talk or explain their decision making process, and it handycaps them since they can't expand their skillset past churning out code. As someone who has changed fields a few times, rebuilding my vocational vocabulary has always been the most time consuming and difficult part.

Here are some things I think are helpful for long term growth (YMMV):

- "The Mythical Man Month" by Fred Brooks is a classic for a reason.

- Learn how your tooling works to a reasonable level. It's worth investing time into tooling as you use it every day.

- For your long term technical development dabble with other languages and libraries, try to understand why and how they do things differently.

- Ignore orthodoxy, but educate yourself on why developers follow it and come to your own conclusions as to whether you agree or not. This means reading widely but sceptically, check out many different open source projects.

- A lot of what constitutes current industry best practice is not written for any one developer/organisation and the chances are it won't apply to you. There are organisations of all sizes dealing with problems of all different types and the current language/framework/library/infrastructure pattern of the month may or may not have been developed with you and your organisation in mind. Don't be taken in just because everyone's talking about it.

- Set aside object orientation and type systems for a moment and learn the language of data. Data structures and operations on them, normalisation & the relational model and how to model a problem domain as data are all more important than class diagrams or arguing about whether composition is better than inheritance. Once you understand and can navigate how data works, you can apply those rules to any programming paradigm you want.

- You need to know how to operationalise your projects, or at least communicate effectively with people that do. Writing code and throwing it over a fence to QA or ops won't do.

- If you're building code that will be exposed to the internet, you need to understand application security. Check out OWASP.

- If you're not working in organisations where coding standards are cared about, consider moving on. On the other hand, beware holding too strong an opinion. If your tech lead doesn't follow Martin Fowler's, or Bob Martin's, or the GoF, or test-driven development, or whoever else you care to name, that doesn't mean they're "doing it wrong". Nearly all "rules" and "laws" in programming are just some person's opinion.