¿Cómo pueden los desarrolladores junior aprender mejor los lenguajes de programación?

Instead of learning the language, concentration should be on learning programming. If language is treated as a tool for programming, it would be easy to shift to any language.

Transformation of your career as a programmer, whether starting or continuing, happens when you build software that you use yourself. The business world calls it "eating your own dog food". When you live with the product(s) you make and use for yourself daily you will be learning things they do not teach in school. Living through the development, roll out, and maintenance cycles will mature your skills faster, make you much more effective, and transform you into a critical player for any team. If you are not living with software you have developed for yourself (on a daily basis), think about it: why should someone else buy a product you yourself are not buying?

🎯 Choose a project that makes you happy. 🕹️ Love gaming? Code a game! Dream about helping the environment? Build an eco-app! 🧩 Learn by Creating: Don’t just read code; write it! Make something small every day. It could be a tiny app or a piece of a bigger puzzle. 🤝 Share the Journey: Pair up with a friend or mentor. Discuss, debate, and develop together. It’s more fun and you’ll learn faster! 📹 Write blogs or make videos about your project. Teach as you learn – it's a great way to deepen your understanding and help others! 😄 Stuck? Great! Mistakes are stepping stones to mastery. Learn, laugh, and leap forward! 💥 Let's code, connect, and create!

Choosing a project is important and another part is that you can always create a tutorial for others to build that project similar to you in easy todo steps. This way you will be clear about how you are learning and building something while creating guides to help future junior developers go through the same exercise. I have always used this approach and helped others too.

Define a goal and Start from where you are. Keep working hard on the problems. find appropriate solutions. if can't move ahead then stop and restart.

There are so many tutorials out there but the most effective way to grasp the concepts and understand it the easy way is to apply the concepts and build something which is very much easy to remember.

Nothing beats learning by doing! I reckon a common challenge facing junior developers usually is to define or identify a project, thus another great option is doing leetcoding, where you get to learn coding while also preparing for interviews!

I think adopting practices such as test driven development really help. The SDLC is a very rigid process to be more agile, you need to write and test code periodically before deployment.

In my opinion, The Best way to learn in depth is by doing something and have a senior that can guide you through this process ,in addition to spending time to read documents and finish related courses, you will become a expert in no time, remember that experience is the main key that comes with hard work.

You can read books, watch tutorials, hear a lot from experts, and fill your brain with a lot of concepts that are there but are not connecting until you start coding by yourself.

Code reviews are one of the best way to improve your skills , this is a good way to point out your weakness and to create your own road map to upskilling.

Always seek feedback from your peers and lead. Keep an open mind, accept the criticism and work on the improvements. One day you will find yourself becoming the mentor.

A great way is teaming up with senior developers for pair programming sessions. In both pair programming roles, driver and co-pilot there’s a high amount of knowledge transfer. Not only about „how“ but also „why“

I learn new languages by reading open source code, envisioning how I'd write that function or class or how I'd structure them and then argue the merits and demerits of my approach. Dissecting and understanding the logic behind well-established code helps gain valuable insights into the best practices and idioms of that language. This not only accelerates comprehension of the syntax but also provides practical knowledge on how to solve real-world problems efficiently. Additionally, exploring different open source projects exposes me to diverse coding styles and approaches, broadening my understanding of software development as a whole. It's a hands-on, immersive way to enhance language proficiency and become a more versatile programmer.

As a Junior Developer, it is not expected to know everything and to do everything right the first time. What is expected is to ask, seek advice, and research possible solutions. It is ok to make mistakes, what's not ok is to not learn from the mistakes and use the opportunity to learn from others.

Turn your "quick questions" into pair-programming sessions! Code solo & only pair when you're stuck or having questions answered. Then, minimize PP as you grow. Here's what I've observed: The time spent in pair-programming sessions by junior developers will exponentially decay IF they pair up with someone more seasoned and WEAN themselves from it as time progresses. As the more experienced dev (senior or not), it takes patience, and you have to make yourself available. I said, "Let's have a call," to questions that I could've answered in a couple of Teams messages. On my remote team, I've led them to independence. It's a marvel to behold! Everyone has grown and made the team very fast. We still pair, but only for the real brain teasers.

No need to reinvent the wheel, learn the objects in detail and master the techniques. Learn from the gurus who are willing to share.

Like learning a new speaking language, you first translate the words into a language that you already know and then attempt to understand it. Learning a new programming language is like that. This will boost your understanding of the new language.

Learn techniques not technologies. Technologies are all manifestations of different techniques. This will give you a deeper understanding rather than just learning some tools. You'll be independent of the technology you learn and this gives you the ability to easily switch between technologies.

I would say stay curious, never get too fixated about a specific technology and allocate some dedicated time everyday even if for 15 min to learn something new!

Participate in online forums, communities, or meetups related to the programming language you are learning. Engaging with others can provide valuable insights and support.

There are many concepts to learn as software engineers than just programming such as: 1. Database - how to store and retrieve data 2. Network - how packets sent/ received over internet 3. Testing - functional, unit, sanity, smoke, regression, load, performance, security etc 4. Data representation - json/xml 5. Algorithms - search/sort/graph/tree 6. DevOps - build/deploy your program 7. Web - html/css/javascript 8. Not the least but to - understand the requirements (what problem are you solving) - ask questions - what/how/why

Aim to achieve more with less. Learning how to achieve results with fewer words should be a goal! One of my favorite books says, "In the multitude of words, sin is not absent" Similarly, having thousands of lines of code does not necessarily mean coding prowess. Fewer, syntactically better written lines can achieve same results, possibly run faster and easier to follow, understand and even re-use!

Every technology like programming languages or databases have their own unique signature but they all serve the same purpose. This will make them similar to each other despite their radical differences at the first glance. So the best way to learn everything in technology is to learn the origin of every technology rather than its interface

Mastering a programming language isn't difficult, but the key to a programmer's success lies in efficiently developing the logic to achieve business results. In my early days at HDB, I remember completing the validation of NRIC in just a few lines using Lotus Note Formula, showcasing the importance of understanding comprehensive business requirements.

Even if you have made the sexiest software, if its not going to bring in money for the business thats just it, sexy code. The test of the pudding is in the eating. If the end user wont like the product that you made, your hard-work will just fade away into oblivion.