There are many things you can do, and not really "one" silver bullet, but I feel the most important are "soft-skills" and a hyper-focus on learning. You asked

There are many things you can do, and not really "one" silver bullet, but I feel the most important are "soft-skills" and a hyper-focus on learning. You asked for one, but the two of them are so deeply connected, I feel they warrant being included together. Communication/soft-skills has already been mentioned so I'll leave it with the simple "At the end of the day, regardless of how smart you are, if you cannot work well with others and you're not the sole employee/owner, your value is very limited". The biggest problem I've found being a software developer is exposed by this phenomenon referred to as Imposter Syndrom[0]. In a lot of fields, there are good ways to measure yourself and your skills against others. In software development, it's a difficult thing to measure. You can become an "expert" in the core language you write in -- understanding the common patterns, standard libraries, and common features -- and no matter how much your abilities increase, what you know is far less than what you don't know. Even today, with resources like StackOverflow, open-source material and source repositories with endless amounts of code available, learning corners of your specialty is hard. Your resource may be "out-of-date" (which happens within weeks, rather than months/years) or might be so specialized that there's just nothing out there[1]. Because of Imposter Syndrom, your developers are not quick to point out their weaknesses, but knowing the strengths/weaknesses of your coworkers helps you to be effective and to know who to tap when you get stuck. Unlike "that person in the forum", they have a vested interest in making you better -- you'll reduce their workload the more effective you become. Provided you're good at establishing relationships/friendships with others, they'll actively help you to become better and there's no better way to learn than one-on-one with someone who has the skills you lack. Knowing their weaknesses allows you to better focus your study on areas that the team has gaps (tip: offer up your own deficiencies and others will open up about theirs). A lot also depends on what corner of software development you're focused on. If you're focused on web front-end development, you have a much easier time learning what you need to learn, and more jobs available to shine in, but you also have a huge amount of competition and a greater distance between Junior and Senior. In a highly specialized area -- mine was Skype for Business development -- you have fewer job options, almost no resources but a much smaller distance between Junior and Senior since simply having experience in one of the APIs already puts you near the middle. At first, I was tempted to say that being in the latter category is helpful, but having done it and reflecting on how painful it is when you run into a problem and have, literally, nobody to turn to for help[2], I can't say that I recommend it. Picking an area of focus that is somewhere in the middle might be a good idea. :o) On learning, figure out what techniques are most effective for you. I don't do well in lectures, and I don't have the patience for video tutorials. I took a class about 20 years ago on effective book study (it was called "speed reading" at the time, but has nothing to do with these gimmicky techniques taught by apps, today). I learned how to skim/scan material and take effective notes while doing so, allowing me to consume huge books in hours, and "read" those books for information several times over a period of a week/month. I felt like I had a "super power" and exercised this ability to the tune of about 6-10 large volumes per year. When I need to learn something, I look for a good, thick, book on the subject, set a goal for completion and relentlessly pour myself into it. For programming, I know this requires me finding a personal, useful, project to build, an "instructional book" and a "reference book". Give me those three things and the language, framework or pattern in question will be cemented in a way that allows me to use it at a practical level. [0] https://www.hanselman.com/blog/ImAPhonyAreYou.aspx https://www.hanselman.com/blog/ImAPhonyAreYou.aspx [1] My area of focus until very recently was developing software for Skype for Business using some of the (very excellent) APIs provided by Microsoft. Unfortunately, the number of people who are doing professional development in this software is small due to its target audience being enterprises. You just don't have a large number of hobbyists writing libraries on the weekends. The primary API I used to develop in, UCMA, had one half-chapter in one large book written in 2007, none of which is helpful to new developers due to it being wildly out of date. The documentation for this API is mostly "Undocumentation", and I've encountered very few APIs that have as many sharp edges, parts that don't work as you'd intuitively expect or simply don't work in any way resembling the documentation. [2] I can't tell you how many times I've googled a problem and ran into solutions where the answer was provided by a person I worked with that I could have tapped on the shoulder. Or the two times I googled something, saw the answer (in one case, slightly disagreeing with the approach) only to discover that the person who wrote it ... was me. Just goes to show that anything in software that you've written six months ago might as well have been written by someone else.