Udemy has a great course on Full Stack Web Development and Java. PluralSight also has phenomenal paths on C# and Java.

Check out GitHub and do a search for some projects you might be interested in. Fantasy text based games, checklists, to-do lists, mobile games, etc. See how other people write code. Eventually you can offer to participate in the projects and contribute or fork your own.

Books! Books are great resources, especially if you know where to look. Some can get dated, very quickly, but others are timeless.

Core Java Volume I

Python Programming: An Introduction to Computer Science

Eloquent JavaScript

Head First Ruby


Regarding Python Programming: Let me tell you everyone's most hated research methodology. An anecdote! I hated, I absolutely HATED* Python.

"Python is beautiful!" said the pompous coder. "Python is the world!" said the obnoxious tool. I thought it was ugly, jagged, white space loving garbage.

Turned out, it was the method I was learning Python. That book changed my life.

Anyway, back to the other books.

Core Java Volume I and II are INSANE in the amount of information they give. You will learn more about Java than you probably care to know, but when you finish both volumes you'll be able to do anything with the language.

Eloquent JavaScript is one of the best JavaScript books I've read, and I've not read them all, but I've read more than a few. But who am I? :D

I'd get the Ruby book after you've learned some Python or get it before you dig into Python. Could get a little confusing. But after one, you'll essentially know the other.

Some of the replies have suggested to ask your company to cross train or see what stack their working in and learn that. I disagree for a couple of reasons (which should be taken with a heaping spoon of salt):

1. It's always good to see what else is out there. The best way to get a raise is to get a job at another company!
   
   
2. The stack the company is using could be out of date or not in demand. We don't live in the age of working for the same company for 25 years. In fact, with software engineering, it's good to experience different tech every few years. It wouldn't be a bad idea to ask to shadow or maybe mentor, and depending on the time invested you might want to give them at least a year.
   
   This is another example of personal experience, I am far from an expert.
   
   
   Check out some podcasts too!
   
   Coding Blocks .NET
   
   Code Newbie
   
   Programming Throwdown
   
   Coder Radio (see below)
   
   
   

   Sometimes that guy can be super jaded and negative, just an fyi... They do cover good subjects, though.
   

   
   
   Also, not a podcast, but https://scaleyourcode.com/ has some good insight on software development as a career.
   
   Good luck! There is a slew of information out there.

Boot camps might help teach certain technologies, but they might not help with the fundamentals. Additionally before you give money away try to complete courses on Udemy or Coursera to see if you can commit to the effort.

Over simplified recipe for building skills to transition:

• code on the side; build skills to learn and dig deep. You'll always be solving things you may not know. The skill of learning is huge. Always be curious.
  
  
• Master an OOP language, a scripting language, and maybe get familiar with CSS/HTML/JavaScript Node if you want to be a modern web Dev.
  
  
• read this: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
  
  
• read this (recommend to study for Google interviews): https://www.amazon.com/gp/aw/d/1848000693/ref=zg_bs_3870_4?ie=UTF8&psc=1&refRID=70YNX3TJA8F9GXG03Q9F
  
  
• learn about web services . Try to build one from scratch with a REST API and a connection to a database. A lot of good fundamentals here and a lot of companies have devs that do this daily.
  
  
• code some stuff on GitHub; maybe find an open source project to contribute to. Get involved with a Dev community and you'll learn 10x more than paying for a boot camp.
  
  
• If web Dev turns out to not be your thing. Dive into other "programming" domains such as machine learning, big data, embedded systems, etc.
  
  
  If any buzzwords here might not make sense, congrats you get your first exercise in digging for answers ;) (no rudeness intended)

Clean Code Books:

• Clean Code: A Handbook of Agile Software Craftsmanship https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_api_i_2k80CbD4F4QHJ
  
• The Clean Coder: A Code of Conduct for Professional Programmers https://www.amazon.com/dp/0137081073/ref=cm_sw_r_cp_api_i_Ml80CbREG48TD
  
  Design Patterns:
  
• https://sourcemaking.com/design_patterns
  
  And of course, good ol’ practice.

>The word engineer has been hijacked in various job titles such as software engineer, systems engineer and even sales engineer. But none of these positions are actually engineers at least not in how we use to use the word.

I fail to see how these job titles "hijack" the word engineer. I think the biggest problem is that there isn't a good understanding of what engineering is or what an engineer does, and part of that comes from the fact that there's very little published about engineering outside the context of a particular engineering discipline. We know that not all engineering disciplines are the same - I think most people would agree that a chemical engineer and a civil engineer and a mechanical engineer are all definitely engineers, but the things they do and how they do them are radically different. Even within a discipline, there are a broad variety of ways to do work. I'd highly recommend reading Billy Vaughn Koen's Discussion of the Method: Conducting the Engineer's Approach to Problem Solving. Koen also has an earlier paper - Definition of the Engineering Method - that is an early draft of the first 3 or so parts of the book, and the PDF full text of that is available.

​

>My reason for asking is now that I work in a country where software engineer title doesn't exist and is actually software developer instead.

That's generally the choice of the company. Unless all use of the title "engineer" is regulated by the government, companies are generally free to choose their own terms and titles.

​

>I'm wondering what software engineer means to you?

I'm pretty much in line with a lot of what Koen writes about, so I'd check out his paper or book. Using his definitions, I'd say that software engineering is the use of heuristics to cause desired changes in an unknown or uncertain environment or situation within the constraints and available resources. Koen defines a heuristic as "anything that provides a plausible aid or direction in the Solution of a problem but is_ in, the final analysis unjustified, incapable of justification, and fallible". Anyone who does this is conducting software engineering. However, I also think that in engineering, there's a side of professional responsibility and ethics. Koen doesn't get into this, but I believe that people who call themselves engineers also have obligations to the stakeholders in the things that they create or maintain or design, to other members of the profession, and to themselves.

Maybe a bit too much to start with but I really like https://www.amazon.co.uk/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164

For testing, I liked this one: https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

For version control, continuous integration, continuous delivery, this was a good read: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

There are many extreme programming books that briefly talk about pair programming. If you want a book specifically on pair programming only then there is this: https://www.amazon.com/Pair-Programming-Illuminated-Laurie-Williams/dp/0201745763

There are thousands of books out there for learning various topics of software engineering.