The 6 Types of Golden Advice for Junior Web Developers

1. Intro (or, The Path to Web Development)

On Working as a Developer

If You are Still Looking

• Polish your (One-page) Resumé: Add any relevant and/or recent job experience you have had. Avoid unnecessary details that either paint your claims as false or add no relevance to the job you are applying to.
  
  And, keep your resume at only one page. You probably don't have more experience than can fit on more than one page (unless you are exaggerating or strangely underselling yourself).
  
  Keep it simple, clear, well-formatted and informative. Your resume is just a "bird's eye view" of your professional skills and experience. The links to your Github repos will tell the larger (and more "glamorous") developer story.
  
  As for cover letters, create one for each job you apply to. Don't send a coverletter that says that you are "happy to apply to this web development role at your company" when you could have just taken a minute or less to customize it to say that you are "interested in the Junior React Developer Role at vCorp's 'eCommerce Division'".
  
  
• Apply for Jobs: Once you have a decent resumé, don't prune it more than a few times before you start applying for jobs. Take it out there into the wild (of job applications and interviews, etc.)
  
  You can approach your job search by looking at and applying through:
  
  
  1. Job Boards: These are platforms that collect (and accept) job listings from companies (large and small) that are looking for developers to fill vacant positions in their organizations.
     
     Some of these job boards are generalists and accept job listings from a variety of industries (writing, legal, medical, technical, and so on) and not just from software companies or companies looking for fill in software positions.
     
     These generalist job boards include such ones as Indeed, SimplyHired, etc. If you live outside the USA, your country or region should have a few job boards that you can search on to see if you find any matching job listings.
     
     Other job boards (such as Vettery, WeWorkRemotely, etc.) are targeted mostly for the technical crowd like web developers, UI designers and project managers.
     
     
  2. Hiring Companies: These could be startups, fortune 500 companies or lesser-known (but profitable) companies. Many companies list the jobs they are hiring for on their "Careers", "Jobs" or "We're Hiring" pages on their websites. Look through those and see if you find some that appeal to you.
     
     Avoid internships unless you are a college student looking for experience (to put on your resumé) and some change to pay for your meals and such. Go for a "Junior" role instead so you can get some real "hands-on" experience instead of doing social media updates and getting coffee for the team.
     
     Depending on your arrangement with the hiring company, even if you are a college student, you can work either part-time or part-time as a Junior Developer on the team.
     
     
  3. Government Jobs: Depending on your country and/or municipality's state of technical advancement, you may find sections (on the government websites) which list jobs that are available in various fields of work and departments of the government. Follow the instructions and apply for them.
     
     NOTE: Government jobs don't always pay as much as private sector jobs, but they usually offer a lot of benefits and "job security" than in the private sector (which tends to have bouts of layoffs every now and then when their profits are threatened.)
     
     
  4. Recruiters: Recruiters could be invaluable when it comes to looking for your (first or next) job. They can also be pesty and unprofessional, depending on whom you are lucky to cross paths with. Just avoid the ones that reach out to you to tell you that they have "a role you will be interested in" at a "successful company."
     
     If they reach out, but didn't take the time to look at your (LinkedIn) profile and instead just paste and send you a message they have probably spammed dozens of others with, avoid them like the plague. Those are most likely just trying to collect resumés so that they can turn around and tell hiring companies that they have "a list of qualified candidates that are ready to interview".
     
     You are a professional and your time is valuable. If someone isn't professional enough to understand and respect that, toss them aside and keep moving forward. You will be glad you did.
     
     "Trying to see if it works" will just bury you deeper into a quicksand of hopelessness, desperation and unprofessionalism. You are a professional, dear developer; so, treat yourself like one.
     
     I once got a role through a very professional recruiter. At other times, I had to ignore a whole recruiting agency because they canceled two or three "scheduled interviews" on the same day. Talk about dishonesty and disorganization.
     
     And, whatever you do, DO NOT tell a recruiter or another company which other company you are currently interviewing with. You can tell them that you are looking at other companies and roles too, but don't be pressed to tell them about the specifics. That's none of their business.
     
     And, after you get the job, you don't owe anyone (company or recruiter) information about who you are now working with. That's none of their business. They can find out if they check your LinkedIn profile three months after you start working.
     
     Always wait at least three months after you start working before you update your LinkedIn profile if you were also using a recruiter but took a job with another company that you interviewed with on your own. Why? Because the recruiter may have had a contract (with an "exclusivity" clause in there) with your new employer where the recruiter will handle hiring for them.
     
     I onced interviewed with a company (let's call it "<Some Corp>") while I was also using a recruiter to look for jobs (desperate times, I assure you.) Anyway, during a phone "chat" with the recruiter around the "so, are you interviewing with anyone else at the moment?" question, I let slip that I was interviewing with <Some Corp> and that we were "close" to a deal. She chatted about knowing the CTO (whom she named) and so on. Anyway, I never heard back from <Some Corp> even after I tried reaching out for updates on the interview/hiring process. Guess whose fault it was? It wouldn't have killed me to just keep my business ... my business.
     
     
• Interview Like a Pro: Once you apply for a role you like and get back a response to setup an interview, it is time you started preparing.
  
  Research the company (and/or department), learn about their (stated) business objectives and tech stack and any media mentions and coverage of the company and their work in recent times (i.e. in the last year or so).
  
  Then:
  
  
  • Review the code of the apps you built so that you can talk about your design decisions, libraries used, and so on, while building that app.
    
    
  • Review the tech tools you have learned about (like git, etc.), libraries, packages and libraries you have used and any related information (like any major updates to the libraries or frameworks you use).
    
    
  • Review your resumé so that you don't mix up the timeline of your job experience, education and such which may make you appear like a liar or heavily unorganized job applicant and potential employee.
    
    
• Attend Interviews as Scheduled: Is it online? Make sure you have a good headset/earbuds to use and that you are away from noise and physical distractions. And, be on the call right on the time scheduled. If you jump in a few minutes before, he/she may be on another call with another candidate, colleague or client. If you jump in a mnute late, thats just viewed as you being unprofessional.
  
  
• Ask questions of the interviewer and touch on recent projects they made the news for. The interviewer's "do you have any questions for me?" is actually a way to know:
  
  
  1. If you cared enough about the company to do some research about it (which you can then ask follow-up questions about.)
     
     
  2. If you are genuinely interested in the tech stack they use at the time. Do they use VueJS instead of Angular? Ask why? Did they leave MySQL for MongoDB? Probe just a little.
     
     Of course, make sure you know a bit about each of these technologies so that you can carry on meaningful conversations about them and handle follow-up questions should you need it or be asked counter questions during the conversations.)
     
     
  3. If you were paying attention during the interviewer's presentation "about our company" or just treated them as just "yapping" away into the void.
     
     
• Go Fast-Track on your Technical Onboarding: Once you get offered a job, make sure you fast-track your way through learning about the tech stack, technical tools, frameworks and processes that the company and/or your team uses. No new employee gets penalized for "learning too fast" on the job.
  
  Don't wait until you are assigned a project or app to work on before you start learning about how to properly use git (commits, branches, merging, pull requests, etc.)
  
  And, don't wait until you are assigned "tickets" to work on in JIRA before you start googling "how to use JIRA".
  
  If you are given two weeks to learn anything, don't wait that long. Schedule yourself to deliver it in half the time. You will kill two birds with a stone: learning quickly and saving yourself some embarrassment and frustration AND you will score a point with your manager and team mates in your first month.
  
  Will the company be using AWS to host their applications? Spend the nights and weekends of your first month learning about how the various solutions that the AWS cloud provides.
  
  Does the company use Jenkins for CI/CD? Don't put in on your "to-do" list for this weekend. Schedule it for the nights of your first week.
  
  If you wait until you are asked to learn something (that the company uses) before you embark on it, you will most likely regret it, because:
  
  
  • once you are assigned a task and you fumble through it (or, worse, fail at it), your manager will nag you for it the rest of the year and your colleagues will tag you as the "unreliable" new team member who can't be trusted.
    
    
  • you will lose credibility faster than a straw hat in a windy desert. The whole claim about you being "smart", "quick-learning" and "up and coming" developer will go out the window and you will lose (a LOT of) leverage in your first performance review (which will affect any raise and bonuses you could have gotten for the year, etc.)

If You are Already Working

• Learn on the Job (Faster): If there are items on your company's/team's tech stack that you haven't fully-mastered, put those on your learning "priority list" and get started learning and reviewing them right away.
  
  Maybe you need to brush up on the Data Structures for the programming language that your company/team uses. Or, you have to learn that frontend framework that your colleagues use (even if you are a Backend Developer). Or, you should create some sample databases using the database solution that your team uses.
  
  Or, maybe you have to master the CI/CD tools and processes that your team employs. Or, you must catch up on the ins and outs of deploying your web projects to the cloud provider that your company uses, and so on.
  
  Whatever it is that you need to learn, re-learn or master, do it right away and faster. And, keep personal notes that you can refer to when you are stuck or need to review the "how-tos" and best practices related to using any of the tools in your tech stack. Your personal notes will save you days of "I'm stuck" execuses later during your daily team calls.
  
  
• Be Proactive: Don't just sit around and wait to discuss, validate and promote other people's ideas and projects. Come up with projects that you think your team needs.
  
  Or, work on apps that use the libraries and frameworks in your tech stack. Then, push your code to your Github (or other) repo and share that with your manager and co-workers.
  
  Just make sure that when you create personal projects and push their code to your Github profile that you DO NOT: use company data (even if anonimized) or internal tools (even if your intent is for your team members and manager to see your work).
  
  Heads role (job-wise) because naïve employees use company data in their projects (without due diligence or consulting their technical leads beforehand). Don't let your head be on the list of the heads to roll for the quarter.
  
  Worst case scenario? They won't care too much about it (even though you will always be at the back of their minds as the guy/gal who created the project with that framework/library/package).
  
  Great outcome? You will establish yourself as an authority in that field and be the "go-to" guy/lady for that library, tool or framework among your co-workers.
  
  Also, actively contribute (within reason) to projects and initiatives that your co-workers are working on. If you need to start a new project and/or initiative, do so and get your manager and colleagues involved.
  
  What if you don't agree with another team member's suggestion or initiative? Speak up and coherently express your opposition and alternative approaches and/or implementations.
  
  And, innovate where necessary (within reason of course; you don't want to spend a large portion of your personal time outside work doing "work-related" stuff.)
  
  
• Actively Ask for Feedback: You don't have to wait until your first or next performance review to ask for feedback from your manager(s) and colleagues about the quality of your work and your relationship with co-workers. Then, take those (especially the critical ones) to heart.
  
  Find a way to work on improving yourself in the areas you find yourself (through personal observation or the feedback system) lacking in. Then, improve your yourself and work on becoming a more well-rounded and well-grounded fluent developer.
  
  
• Work on Some Side-Project Apps: While you will be tied to your work 8 hours a day (or, likely more) and 5 days a week, you have your nights (at least 2 hours daily) and your weekends to start a new project, see it to fruition in a week or two of nights and weekends.
  
  Use the same tech stack you use at work to develop your side project apps. This will enable you become more proficient (and valuable) in the tech stack that your company/team has invested time, manpower and resources in for use in production.
  
  Working on apps (in your free time, nonetheless) will benefit you in two major ways:
  
  
  • You will master your tech stack more.
    
    
  • You will develop your personal brand. Your side project apps will become useful for when you need to apply to a new job, get a side gig (as a freelancer or consultant) or ask for a raise (and promotion) in your current company or team.

2. Tools of the Trade

1. 1. Version Control System (VCS): Few professions are as meticulous as Software Engineering when it comes to tracking the progress of work assigned. Developers came up with a way to track when a project was started and whenever there was an update (addition, deletion or replacement), who made the update and when.
      
      This is called a Version Control System. Most of us are familiar with using the `git` tool to track our code and the changes made to it.
      
      To host your code remotely (as a hedge against local data loss), you can use a remote code hosting provider like Github or Bitbucket or company/privately-hosted (which is pretty rare, but doable) solutions. Both of these providers also offer free private code repositories (or "repos", for short) to host the code and documentation files for your projects and apps.
      
      Even if you are just starting out doing software engineering (or, specifically, web development), you should learn how to use `git` to manage your code. A few good resources to help you include:
      
      
      • An Intro to Git and GitHub for Tutorials (An introductory tutorial by HubSPot)
      • The git book (A more detailed 10-chapter book on Git and Git-related tools)
      
      Every organization that works in the software space uses a VCS (mostly `git`) and a remote code hosting provider (usually, Github or Bitbucket). So, learn (at least) the basic usage of `git` such as:
      
      
      • starting a new git repo
      • committing code
      • creating, using and managing multiple branches of a repo
      • setting up and linking a remote branch
      • merging branches
      • Pull Requests
      • creating git shortcut commands
      • ... and so on.
      
      If you want to get more advanced (and you should), you can invest some time in the free git book (by the fine folks at git-scm.com) for a more detailed coverage of the advanced usage of `git`.
      
      
   2. Project Management Tools: Even if you are working alone or with just one or two other developers, you should practice using Project Management tools to help manage ... well, your software projects.
      
      Some common project mangement solutions usually used include JIRA (very common and usually used by companies big and small) and Trello (less commonly-used, but great for personal or small-team projects). Learn to create projects and tasks and assign those tasks or tickets to yourself or other team members.
      
      Then, learn how to update those tickets as well as how to mark them "complete", "pending", etc.
      
      In a real-world setting, you will be using these tools (most likely JIRA), so, setup a free account and start using it on your own to remove some of the initial frustration that you will get when you are first introduced to a new tool at work. Perspire now so you can rest easy later (or however that saying goes.)
      
      Knowing these tools (even at the basic level) will also give you leverage (and smart talking points) during interviews and onboarding (when first get hired). So, give yourself an edge by learning to use these tools early on and don't wait till you get hired and start to be bombarded with all these "assigned learnings."
      
      
   3. UI Design and Wireframing Tools: Even if you barely do any UI designs of your own (besides your pencil-and-paper sketches), you should learn about some of the UI design and wireframing tools that are commonly used by software teams.
      
      You don't have to master these, but it is great to at least know that they exist, how to setup an account and do basic things with the tool.
      
      Some of the most-commonly used wireframing and designing tools include Figma, Sketch, Moqups, and others you can discover by asking on designer forums on the web.
      
      If you have to pick just one, go with Figma (mostly because it is one of the most popular and widely used by teams, big and small). Setup a free account and learn the interface. Create a simple set of wireframes for a fictional (or real) blogging app and see where it takes you.
      
      
      On your team, you may not be doing the wireframes or UI designs (there is usually a "UI Designer" who does that), but the more acquainted you are with the tool, the better you are as a team member and can provide more constructive feedback to both the UI designer(s) and your fellow web developers on the team.
      
      
   4. Testing: This is not a must have when first starting out as a Web Developer, but it is great to know at least the basics of it. No serious piece of software (whether a mobile, web or desktop app) is complete without proper testing.

       

      But the testing tools (libraries or packages) you use will depend on the programming languages and frameworks you use to develop apps at work. So, if you are working on becoming a Backend Web Developer (working with Django or Flask, for example), ask around for the common Python testing libraries used by developers in those frameworks' communities.

       

      If you use any JavaScript backend framework (like ExpressJS), check their official documentation and ask on the relevant developer communities for suggestions and input on what testing tools they usually use.

       

      The same applies if you are an aspiring Frontend Developer (whether you use React, Angular, Vue or the others).

       

      Whatever frameworks you use, also figure out what testing tools are used and learn at the basics of it by:
       
      • looking at the official documentation of the framework and their tutorials and guides for what testing tools they recommend.
        
        
      • asking in the relevant developer communities (on LinkedIn, Reddit, etc.)
        
        
      • writing tests for a (new or existing) app you created, so that you go beyond the theory and actually write automated tests for your apps.
        
        
   5. CI/CD Tools and Processes: This is a more advanced topic. But look around (or ask around) in the developer communities (forums, groups, mailing lists, etc.) that you are active on and your team members (at work) for pointers on what CI/CD (Continuous Integration and Continuous Deployment) tools and processes are commonly used.
      
      Then, go and read a tutorial or two (or see the official docs) to get the hang of it. If you are still lost, go watch an intro/"crash course" video on Youtube to see it done.

       

      The intent here is not to be acutely familiar with these tools. It is just to know that they exist and understand how they work (even if at a high level.)
      
      
   6. Command Line Interface (CLI): Depending on the operating system your team develops on and the tech stack it uses, you likely will need to master how to use the command line interface (CLI) of either a Unix-based (Linux or mac) operating system or Windows.
      
      
      The point-and-click GUI can only go so far for you as a developer. You will need to be able to navigate your filesystem, manage users, monitor processes and setup configurations (for web servers, etc.) using the CLI of the operating system you use.
       
      The OS you deploy your web apps to will also likely be the same as the OS of the local machine that you develop them on.
      
      
      So, learn how to use the command line (or "terminal" as it is alternatively called) of your host operating system whether that's Window or Unix (i.e. macOS or Linux).

       

      Here's a great guide on learning about:
      • The Linux Command Line
      • The Windows Command Line Commands
      
      If (and when) you need to get more advanced skills in the CLI of your choice, search online for a book or course that has detailed coverage of that CLI.
      
      
      If you are just starting out and don't know which operating system's CLI to learn, just go for Linux. Most of the packages, libraries and frameworks you will use are built with a default assumption that the end user (you, the developer) will be working on a Unix machine (running the Mac OS or a Linux distribution); so, you don't lose either way.

      If you are already working, you should already know which operating system you and your team use and, as such, the CLI that you should be learning. Get a book or signup for a course on it (and don't wait for your manager to ask you to do so) and start building mastery of the CLI commands, tools and packages over the next one or two months.

       
      Get a relevant certification in that CLI to cement both your understanding and your standing as a power user of the terminal.
      
      
   7. Databases: Any web app, big or small, will need a database to store the data it needs to run. Whether that database store is a SQL one (like PostgreSQL and SQLite) or NoSQL (like Redis or MongoDB) is not the point.
      
      Different dev teams will pick different (or a variety of) databases to use in storing (and managing) data for their web (and mobile) apps.

       

      If you are alreading on the payroll, ask your manager and team members about which database(s) you use and then learn them, one after the other.

       

      If you are still looking for a job, pick one SQL database (ideally PostgreSQL because it is the one with the richest set of features; though MariaDB and SQLite are also worthwhile options) AND one NoSQL database (like MongoDB, CouchDB or Redis) and learn those two.
      
      
      Pick up a book or sign up for a good course on modern databases and learn the two databases you picked. If you are really unsure (and undecided) about which ones to learn, just ask the developer community that you are a member of or developer communities/forums that are built around databases for recommendations. That should work fine too.
       
      Just be careful who take your advice from: a fanboy who has barely done any complex database queries and a seasoned backend developer or Database Admin don't hold equal weight in terms of their technical opinions.
      
      
   8. Programming Languages: Whether you are a Backend Engineer or a Frontend Developer, you should learn at least two programming languages.
      
      JavaScript should be one of them since it is used  for (i) backend development, (ii) frontend development and for (iii) developing cross-platform native mobile (phone and tablet) apps (using frameworks like React Native).

       

      So, pick up a book or signup for a course and learn proper JavaScript. If you are lost, I recommend the Eloquent JavaScript book (available online at that link and in print format) to help you learn what you need to know from the basics to advanced topics like web development using NodeJS and its various modules.

       

      JavaScript is the primary language in every frontend web development library and framework (like Angular, React, VueJS, and others). So, learn it and develop at least an intermediate proficiency in it.

       

      You should also learn another language to help you easily pick up backend web development (if that's not already your field).
      
      A few great choices are: Python, Ruby, Java and PHP.
      
      Combined, these languages are used in possibly most of the web apps out there on the world wide web. So, do yourself a favor and master at least one of these languages too.
      
      
      You can find a few great books on each language or courses (and crash courses) on each of these languages.
      
      If you are lost on good resources (books, courses, etc.) to use, ask on the forums dedicated to these programming languages and/or the web frameworks built around the languages.
      
      
   9. Web Servers (Management): "The proof of the pudding is in the eating", as they say. Well, the proof of the usefulness of your app is that you launched it to the world.
      
      To launch an app (or a larger website), you will need to setup a virtual server, create and configure users and their permissions, create databases and tables and setup web servers (using Nginx, Apache or other solutions).
      
      So, learn those solutions by deploying at least a few apps to a virtual server you created yourself.

       

      If you are already working, ask your team members about which databases, web servers and operating systems the team uses to deploy web apps to. Then, read up on how to deploy web apps to such web servers and actually orchestrate a web appication deployment on your own from A to Z.
       
      If your team has a managed hosting provider (such as AWS or Azure), you can (safely) play with those environments. If not, signup for (a free) account on the platform (or hosting provider) that your team uses and practice deploying apps (just not the ones you built for the company that employed you. That's a catastrophe waiting to happen.)

       

      If you are still learning (and looking for a job), create a free account on the platform you want to learn to use (AWS, Azure, etc.) and deploy a few sample apps that you built. Document the bugs you encountered, the errors that jumped out at you and the steps you took to fix each one.
      
      Those notes will become invaluable later on when you start to work with a team and need to replicate the same process to deploy a web app to production.
      
      
      Depending on your web stack and team choices, you may need to use either Apache or Nginx. You may also need to use other backend-specific tools to serve as a go-between between your web application servers and your web servers.
      
      
      In either case, also learn how to install SSL certificates for your domain (using, for example, Lets Encrypt, etc.)

3. Community Engagement

1. Local Developer Groups: In the heydays of Meetup.com, there was a tech meetup on every programming language, library and framework that exists. You also had meetup groups in almost every city. Look online for in-person developer groups in your locality and see if you find any that match the "tools of trade" (programming language, frameworks, databases, etc.) that you use.
   
   Then, attend, contribute and see if it can be productive for you to be an engaged member. I cut my teeth at doing tech talks by delivering a talk on "AngularJS" (yeah, back in the day) at the local tech meetup I was a member of.
   
   
2. Workshops: Both NGOs and companies do sometimes organize and host training workshops (usually free) that teach critical programming skills (programming languages, libraries, frameworks, etc.) or to introduce the larger developer community to a product or tool (open source or proprietary) that the organization has developed or just released an update of.
   
   Because these workshops are usually free (and developers like free food and swag), you will meet many local developers at these events. Plus, you will gain some new skills, if you are serious enough to pay attention.
   
   
3. Webinars: Those who can't afford to host in-person workshops resort to hosting online webinars. These are not always as effective (for you, if you are primarily there for networking), but you get access to the organizers and can even sometimes connect with other developers (and you don't know who is hiring).
   
   Just be genuinely interested in learning so both your and the organizers' time is respected and productive.
   
   
4. Conferences: Tech conferences (especially the software ones) are great opportunities to learn new skills, refresh your memory and to interact with your fellow developers around the world. There is also usually a "Job Fair" at these conferences. So, you have companies that are vetted to be ready, willing and able to hire skilled developers to join their teams.
   
   Before you attend a conference, check the list of companies participating in the Job Fair and polish your resumé(s) accordingly. You never know, your return trip (from the conference) could be you as a "New Developer Hire" for a company/role you really like.
   
   
5. Mailing Lists: Many open source projects (which is what most frameworks and libraries you use are) will have a mailing list to notify users of updates to the project.
   
   You may also find more than a few newsletters run by some professionals with experience with that framework or library. Signup for these to keep yourself abreast of what's going on in your developer ecosystem. You will learn about tools, resources, events and (even ocassionally) job offerings.
   
   If the mailing list is for an open source project (like the frameworks and libraries you use), you may regularly receive discussion threads that your fellow developers are participating in. Join in and share your own experience and insights or ask (new or clarifying) questions, depending on what's at hand.
   
   If you participate professionally and become a useful (and respected) member of the community, that will be leverage for you to build your professional network, get offers for jobs, ventures and partnerships, etc.
   
   
6. LinkedIn Connections: LinkedIn is a useful tool if you approach it correctly. You can bypass whatever "gatekeepers" there would have been and establish direct connections with fellow (junior, intermediate or senior) developers, tech leads and CTOs and other decision makers in various companies and organizations.
   
   Just don't be (or appear to be) spammy when you reach out to connect to others. Be genuine and professional.
   
   I once got a job offer through LinkedIn. It was great while it lasted. So, nurture your connection and it may bear fruits for you in ways that could be a good "harvest" for your career.

4. Professional Development

1. Conferences: Many software engineering conferences that are out there (PyCon, JSConf, etc.) will have a set of (sometimes paid) workshops that will introduce you to new/existing tools, libraries and frameworks that can help you become a better in-demand developer.
   
   So, watch out for the conferences that are organized around the components of your tech stack and see if they have training sessions/workshops that give you a more indepth introduction to some of the tools in that developer ecosystem.
   
   
2. Books: You can get high-quality books on almost any programming language, framework, library or package that will walk you through using it from beginner to intermediate or expert level.
   
   Search and browse through the list of books you can find on Amazon and other online sellers and see what you come away with. For about the price of a decent (but cheap) lunch, you can get a book that will help make you an expert in a coveted field of software engineering or web development.
   
   If you are unsure which one to pick from the array of unending list of books, ask folks in your developer community for which books they use for backend, frontend, data science or whatever field, framework, library or package you are looking to learn about.
   
   Then, exercise your own due diligence and pick a book or two that you think will be the most helpful to you.
   
   Then, read, take notes, do the exercies and document the bugs you encounter and the solutions/processes you followed to fix them. Call these your "bug database".
   
   Over the lifetime of your career (or the lifetime of your using that framework or library), your "bug database" will be probably as useful (if not more than) the book and tutorials you had to waddle through during your learning days.
   
   
3. Online Courses: Online courses (especially targeted at Software Engineers) are very plentiful these days. They range from the very mediocre to the thoughtfully-developed.
   
   They go for the same price as a sandwich to somewhere close to your monthly rent. So, ask around in your developer community and forums and do some "googling" to see if you find a course that works for you.
   
   MOOC platforms (such as edX.org, coursera.org?, etc.) are also invaluable in this regard as you get access to courses taught at top universities around the world. See if you find an up-to-date course that suits your current professional development needs.
   
   By the way, sofware engineering courses are not the only ones you get online that could be helpful to you. Depending on your needs and your career developnent track, you can find courses on communication, writing, public speaking, social media marketing and management, and more at these learning platforms.
   
   Good luck with your search. Search intelligently and choose wisely.
   
   
4. Bootcamps: For those with a couple of weeks to spare and some money to invest, you can sign up for an intensive software bootcamp for a month or more to go from beginner to intermediate developer in an area of web development or other branches of software engineering.
   
   Just don't just go and shell money into a bootcamp program that isn't highly-rated or vetted. A good place to source feedback (both biased and not) about bootcamps (or any specific one) is on the forums and groups used by software engineers on Reddit, LinkedIn or mailing lists. Do your due diligence with the feedback you get there too.
   
   If you don't find one that fits your needs, better keep your money and invest $100 to $200 into a good course and devote your time to learning and working through the course lessons and exercises until you master it.
   
   This way, you put in a little money (which is low-risk) and some of your precious time (which you will be doing anyway whether you signup for a bootcamp, course or get a book) and gain valuable skills by at the end of the day.
   
   
5. Tech-centric Publications: As a Software Engineer, you should be familiar not just with what's going on in your little circle of expertise, but be aware of developments, news and events in other areas of technological development. It is one way to guarantee you won't go the way of the dodo bird too soon.
   
   So, signup for and read magazines on technology, smart vehicles, open data, cyber security, Artificial Intelligence and whatever else you can find.
   
   You will come away with both knowledge of current developments as well be better suited to make analyses based on your knowledge of the impact that other technical fields of endeavor will have on your product in both the short and longterm, and vice versa.
   
   
6. Developer Newsletters: Some developers have taken it upon themselves to pay attention to developments in the software space (new open source projects, framework releases, library updates, etc.), do research, conduct interviews and publish these findings in newsletters read by thousands of your fellow developers.
   
   If you come across one such newsletter (or get high recommendations from the developer community), signup for them and keep yourself abreast of news, events and developments in your ecosystem.
   
   And, if you can't find any (or a great one that you like), what do you do? Well, you are a developer too. So, do the community a favor and start a newsletter for them
   
   
7. Content Hubs: There are many developer channels on Youtube, software and startup podcasts and engineering blogs that you will find online to help you be a continuous (if not "lifelong") learner. Subscribe to the ones that are relevant to you and keep learning.
   
   
8. Interview Every Six Months: Seriously, update your resumé, apply for jobs similar to (or ideally, one level up from) the one you are currently working in.
   
   Don't fool yourself with the "I am happy at my current role" self-talk. There are always opportunities out there that pay better than your current job and guarantee quicker and juicier upward mobility.
   
   If you get an offer from the interview, use it as leverage against your current company (to get a raise or promotion). Don't fall for the "we will look at your performance at the next performance review to determine your raise and promotion" empty promises.
   
   You aint married to your company and (hopefully not) your boss. If your current company and manager don't "love you" enough to match your newly-offered salary and benefits, accept the offer from the new company, give your current job an "exit" date and move on with your life.
   
   There are a lot of benefits to interviewing seriously every six months. These include:
   
   
   • You will gauge how well your skills are still relevant in your field
     
     
   • You will learn about the new skills, frameworks and paradigms that are making the wave in the industry.
     
     
   • You will get the "courage" to ask for a raise and promotion knowing that you can bail out anytime you want if you don't get a good new compensation package from your current boss and company. That's the power of being "your own man" or "your own girl".
     
     
   • ... and more

5. Personal Branding

1. Github Repos: The proof of your expert coding skills as a developer is the number and quality of relevant projects you have pushed to your Github account.
   
   These repos tell the story of the ideas that you have come up with, projects you have conceived and delivered (pun intended) and shed light on your approach to thinking about software development in general and the interesting problems that you encounter daily in your line of work and inspiration you get from life in general.
   
   So, create a new project or app for any new technology (library, package or framework) you have learned and push it to your Github account as a proof-of-concept (POC) project.
   
   Then, add it to the "Projects" section of your your LinkedIn profile and share it in a status update. Then, add it to your resumé's list of "Projects" section (if you have one; create one, if you don't already have it.)
   
   Your collection of Github repos help tell the story of your engineering expertise, whisk you past the traditional hiring "gatekeepers" and give you leverage during your salary negotiation.
   
   By the way, always add a `README.md` (or `AboutProject.md` or something else) file in part of your project's repo. This is where you explain the design decisions you made, approaches you took and possible alternative ways that could have worked but that you didn't go for because of reasonA, reasonB and optionC. That file alone is worth as much as the whole codebase of your project or app; it's like a potential recruiter, co-worker or hiring manager is reading the thoughts of your mind (and they are.)
   
   
2. Content for Fellow Developers: If you have already learned, worked with and sufficiently mastered a piece of tech, do your fellow developers a favor and create some content to help them learn the process, tips, tricks and best practices for using that library, package or framework.
   
   Depending on your content creation skills and background, you can write blog posts, shoot videos, create slides or contribute to the official documentation for that tech.
   
   You can also submit developer guides or updated official documentation for the components of your tech stack. That's one surefire way to establish your authority in the Free and Open Source Software (FOSS) community.
   
   Some developers have even made a career out of just creating content for their fellow developers whether on Youtube, in podcasts or on their blogs.
   
   Pick the content creation format that works best for you and go do it.
   
   
3. Your Personal Website: Whether you are a backend, frontend or full-stack developer, you should not create websites just for your employer and clients. Don't be the cobbler's kid that has no shoes.
   
   Create a website for yourself, too. This will contain your personal bio, details of your professional experience, links to your Github projects, your regular blog posts (that could be tutorials, opinion pieces or your insights on the world of software engineering or web development or life in general, etc.) Then, add your website to your social media profile's bio section. Then, share the link to any new blog post you just published on your website to your developer community (on LinkedIn, Reddit, Facebook, etc.)
   
   And, if you are applying for jobs, add your personal website to your resumé.
   
   Whatever you do, just don't be homeless on the web. Get a domain (no, don't host your site on the free wordpress.com subdomains and the like) for $15 or less. Build your website and deploy it to the world wide web.
   
   
4. Develop Soft Skills: Many Sotware Engineers think that they should just be "code monkeys" for their employers or clients. No, you shouldn't. You are a professional software developer (whether you learned your art through a book, course, bootcamp or a college degree). So, invest in yourself and develop some non-technical skills that come in handy and give you leverage in the real-world. Theese include:
   
   
   • Writing: If you are not already a seasoned writer (like some of us are, ahem!), pick up a book, signup for a course or join a MOOC class to learn the art of writing creatively, correctly and prolificly.
     
     The intent is not to make a Shakespeare out of you (not that I consider William Shakespeare as the hallmark of literary genius; I don't).
     
     The end goal is to show you how to best tell a story, pick from an array of words, expressions and tongue-in-cheek wordlings (see what I did there) to express yourself whether while writing a blog post, delivering a workshop or publishing an email newsletter to your subscribers.
     
     The only thing better than a proficient coder is a proficient coder who is also a prolific writer. That one is in a class of his own. And, they are rewarded handsomely for that rare combination of skills.
     
     
   • Speaking: Many a "wickedly-smart" developer can't deliver a speech even if their lives depend on it. Get over the fear of (public) speaking by treating every talk you deliver like you are on your team's "Sprint Call".
     
     Start with practicing on your own first before watching "public speaking" lectures. Then, watch some conference talks (related to the stack you use) and see how your fellow developers do it.
     
     Then, watch some keynote talks (from tech conferences) to see how more seasoned speakers deliver speeches. Only then should you watch "public speaking" training videos.
     
     Next, submit talks at your local developer groups and battle yourself and your fear of speaking to successfully deliver your first technical talk. Trust me, it gets easier every time you do it. You will develop the muscle memory, intuition, "funny bone" and people skills for it.
     
     But, first, you have to deliver your first talk. I have been there, so, I know. It is self-affirming to speak to a group of fellow professionals and add value to their personal and work lives. Be That Guy (TM) (or Gal) who is a smooth speaker and invaluable in their developer community.
     
     
5. Nurture People Skills: Some software engineers are notorious for being "anti-social". Well, not strictly in a negative sense, but because they would rather code all day than take some time to talk to a fellow human. Some claim to be introverts. Others think they shouldn't "waste" time talking to "less-smart" humans. Whatever their excuses, they are not in the developers' best interests.
   
   Develop some social skills (like talking to complete strangers, joining a conversation midway) and contributing your talking points without so many "umms", "wells", "I think", "yeah but" and other fillers.
   
   Become a valuable and cherished communicator, not just a "nerd", "geek" or whatever else society labels you with (whether positive or not.)

6. Resources

• "Salary Negotation" by Patrick McKenzie 
  
  
• "Coders at Work" (a book by Peter Seibel)
  
  
• "Seven Databases in Seven Weeks" (A book covering seven of the most commonly-used databases across five database genres.)
  
  
• "Seven Languages in Seven Weeks" (A book covering seven of the most commonly-used modern programming languages.)

7. Technical Reference

• The Free 5-Day "React Developer" Course
  
  
• "React/Frontend Web Development Best Practices"
  
  
• "Eloquent JavaScript"  (One  of the finest books on the JavaScript language.)