Always learning something new. Software is continuously evolving and there's always a next version of some technology, a new algorithm that I haven't seen or used, or a new practice that improves productivity. It's more of a journey than a destination and I love the ride.
If you shared your concerns with them respectfully, how would they react? There are multiple possibilities, but it will also tell you about the people that you're going to work with. If they handle your answer poorly, it might inform you that they're harder to work with. On the other hand, there's another extreme where they will say "We feel exactly the same way and maybe this is a good opportunity to switch". You just never know - if I were hiring you, I would want to know if there was something keeping you on the fence.
I started by getting a contract with a recruiter and resigning from a full time job. I had done a lot of research to find out different ways of getting clients, such as writing, presenting, networking at user groups. Essentially, doing things for other people to enhance the community around your specialty. These types of things result in referrals. Over time, the people you meet move on to other companies and the source of referrals grows. The important thing to remember is that you're running a business and doing things like finance, marketing, and continuous training to keep up with technology are as important as the time you bill.
During the pandemic, most of my work is coming from previous clients. Occasionally, some of the people I work with leave and make referrals for me in their new companies.
I think it will vary greatly from company to company. Some companies were full remote from creation and others decided to go full remote forever. A lot of companies will be hybrid and need to consider the fact that some people want to be in an office with their co-workers. In companies that deal with security, like banks, government, and military/defense industry, on-site will be required. I do believe that, besides exceptions I've mentioned, remote will be very common.
What if you fashioned what you just said into an interview question? Perhaps phrase to be careful that you aren't asking for free consulting. Maybe candidate reaction could indicate who might be a good person to help with that problem.
I'm an advocate for my open source. Here's what I do:
1. Have a Twitter account and follow folks who would be interested. Some follow back.
2. Write blog posts about it. Spend some time to make it high quality to increase the chance that search engines rank it higher. Also, high quality improves reputation and confidence.
3. Tweet every time you blog or release.
4. Tweet about subjects of interest related to your software.
5. Engage in the community around the subject of your software.
6. Contribute to the community - #GiveFirst (maybe this should be first).
While I mention Twitter (I feel like it's one of the best channels), there are other social media channels to look at - whatever makes sense for your situation. There are meetups, YouTube, and other ways that you can generate content that people might care about. Also, my situation is open source and not a product for sale, YMMV.
The PC discussion is like tabs vs spaces and will never be resolved because people will always have different opinions. Anyone that puts themselves in public view like this will attract more attention and generate opinions of all types. I don't let that figure into the larger technical decisions I need to make.
Uncle Bob's writing, teaching, and speaking is widely known and feels like something that a lot of developers know about. Because of this, it's important to know about. Further, he has a lot of useful ideas that developers can use to make their software better. Note that many of the things he discusses aren't new and have been around for a long time. He just re-packages it in a way that a lot of developers find useful. More knowledge gives us all more tools to get our jobs done.
My annoyance around SOLID and any other ideology in software engineering is the near religious fervor around it. A little research will show that many developers are promoting these concepts as "The Best Practice" or "If You Aren't Doing SOLID, You're Doing it Wrong" and similar declarations. I believe this approach is myopic because there are many different approaches and ideas on how to build software.
I'm in the camp of looking at a project and setting up practices, processes, and standards that make sense for the application and team you're working with. Some of it is likely to align with some SOLID principles. Our industry changes all the time and we need to be flexible in how we adapt to new tools and new ideas, respecting the various ideas and approaches that evolve over time.
My approach is to learn from a variety of sources. For that reason, I'd say take a look and give them a try. I've taken a few MS courses and have learned things I didn't pick up anywhere else - they also have Azure sandboxes so you don't have to burn any of your own CPU. I haven't taken any Google courses yet, but intend to. IIRC, they've hired people who have successfully passed their courses. I also recall that there are AWS courses and I'm interested in those too. They're all free and you're free to bail (I have) on any course that isn't meeting your needs. Of course, some material might feel like marketing, but I filter that out and concentrate on what is going to move me forward.
People do this all the time, not only with Twitter keys, but DB connection strings and so on. On Stack Overflow, I edit peoples posts to remove their credentials and then let them know. Nice move on the post - I think it's good to let people know when they have a vulnerability.
One of the things we try to do is keep PRs from getting too big. No standard on what is big or small, but just a general feeling that this is going to take someone more time than normal to review. The person who submits the PR usually lets others know when they know it's large to plan the time. Another thing we do is to take discussions off-line so we can resolve issues quickly (over Zoom or in-person) rather than having long threads. This way, the submitter can explain the code and answer questions quicker. Sometimes there's no way around a big PR, but part of the PR feedback (if the submitter hasn't acknowledged it yet) is that this PR is pretty huge to encourage folks to submit in more digestable chunks.
So many things, but one that stands out is realizing the nature of the career field. It's a constantly changing field with new things invented all the time. Think of it as a moving train that never stops. This is what is exciting about software because there's always something new to learn. Some folks don't like this aspect because they would rather learn one thing and use that for a long time. These are also people who have problems and wonder why they get laid off from their jobs or can't find work because they've allowed their skills to grow obsolete - especially during recessions. A caveat is that sometimes hard-to-find skills (aka nearly obsolete) might be in high demand. However, I think it's generally true that committing to keeping your skillset up-to-date is a safe and rewarding approach.
Both my experience and most other authors I've talked to don't make a lot of money from book sales/royalties. In one case that I know of, one author self-published a book on a niche subject that no-one else was writing about and made a fair amount of money (over $100/book). Other author's I've spoken to have made more money self-publishing than through a publisher. One of reasons why some authors write is because they're independent consultants or part of a software house where the book is good for marketing. It's a nice calling card that might be attractive to a certain type of customer (especially via a well-known publisher). There are other intangibles like personal growth and teaching others that might contribute to your later success. Teaching others can be a forcing function that makes you think about a subject more deeply. So, while you might not experience immediate financial gain, there are often future gains from the endeavor of writing a book.
Some years ago when getting started, I did a lot of research ahead of time by reading books and talking to other people who had done it. While there are always new situations and the learning never stops, the single most important thing in my mind is to manage yourself as a business. In addition to doing the work, you have operations like healthcare, retirement, vacation, and services like accountants and attorneys. My wife helps with that so I can spend more of my time on billable activities, but business aspects are still something you have to pay attention to no matter what. When you negotiate with customers and/or recruiters, you're representing your business. Your loyalty resides with your business. Recruiters are an easy way to get started. I asked my attorney to help understand my first couple of contracts (there are good ones and very bad ones) and learned most of what I need to know over time. The more work you do with different companies, the more you can build out your network. As you build a network, take care of other people and make referrals for them (whether permanent opportunities or contracting). Occasionally, people might do the same for you - that's how this thing works. There will be gaps between contracts, which is normal. If you're too successful, the phone will always be ringing and you can work yourself to death - so set boundaries and take care of yourself. Therefore, when determining your pay, you need to consider the operational aspects of the business, gaps between gigs, and how much you want for payroll. BTW, my wife gets a paycheck and benefits too because she is doing work for the business. Then do research on what the market might pay for your services. There's likely a gap between what you need to live and what the market will bear and that's the space you negotiate in. If you take less than what you need, you and your business suffers. One of my early attorneys wisely advised me - you have a right to make a profit.
I recall feeling like social media was taking up too much time. Instead of just quitting, I listened to tips from other people and figured out my own hacks to minimize distraction. In a couple cases, I just uninstalled apps - though it wasn't easy because some people only communicate on certain apps. It's just that I realized that my time is more important. Some of my work is social media, so I do have to keep my accounts. On Facebook I set privacy so that only friends could see my activity or contact me and then unfriended everyone so that no-one could contact me - this lets me follow groups, manage pages, and access developer APIs without being bothered. On Twitter, where I mostly hang out, I have a list that I've made private and I only add people I really want to follow there. By minimizing exposure, I'm able to stay on a platform without wasting a lot of time.
If contract work is an option for you, I have a few ideas that might be interesting for you. As an independent consultant, I'm continuously reading the market to get a feeling for current and future demand. This thread is filled with great advice on upgrading skillset and I +1 to all of that because having a viable skillset is a prerequisite for a lot of jobs. You can get some experience by contributing to open source, which is something you discuss in a potential interview - recruiters might not care about it but someone interviewing you might.
On contract work, you'll need to select the recruiters you want to work with. Large recruiting firms have clients all over town and if they send out your resume, they send it to everyone. Essentially, this means if you give your resume to too many recruiters, you're hurting your job prospects. Many hiring managers will skip resumes that are multi-submitted because they don't want to deal with the hassle of which recruiter gets paid if they want to hire you. What has worked well for me, when I use a recruiter, is to go with individuals or small shops that don't have the reach of the larger firms. They're also more likely to pay attention to you because of a candidate shortage and thus easier to create a relationship because you're taking a bet on them as much as they are on you. Go after Jr. developer roles for whatever they want to pay you.
The idea here is to get your foot in the door on any software development work possible. This corresponds to the business perspective of being a contractor, the market determines what you're able to do. When times were hard, my rate went down and I took less desirable work - but it was work. The benefit of any work over no work is (beyond bringing in > $0) that people would rather hire developers that are already working. With contracting, you can get a 3, 6, 12 month gig and get experience. When that's over, it's easier to get the next (better) gig at higher pay - just work your way up over time.
Another idea is to scan CraigsList, attend user groups, or network locally to see if there are any companies or individuals looking for software help. Volunteer work is better than nothing too. Then submit a proposal that is dirt cheap enough to get the work - again this type of market is cost conscious. There are also very few developers, beyond college students, who are willing to do this type of work, especially in today's competitive market. It isn't much, but all of the sudden you have something current on your resume.
I have lots of hope for the new Twitter API v2. They've standardized formats, added a new developer portal, and improved documentation. The really positive part is that they're openly reaching out to developers for input. They've even lifted restrictions on what you can build. e.g. new Twitter clients are allowed. I've been working with the Twitter API since 2008 and have never seen this level of engagement.
I like Walter Isaacson's books and this one was so timely. It was also fascinating to learn about the competition/cooperation in scientific research and how one discovery builds on top of others.
There's too much divisiveness in the world today. This is a time for people to put more effort into building each other up and contributing to harmony. I don't mean being so open that we listen to nonsense, but probably enough to turn away from ignorance and don't give it air, rather than locking horns. In the early days of the Internet, maybe on UseNet, there was an essay they posted on forums regularly titled something like "Don't feed the trolls", meaning that long drawn-out arguments do nothing but hurt the community. Other forms of this are "Don't wrestle with a Pig. You just get dirty and the pig likes it." I don't post that much, but before doing so, I ask myself if what I'm saying contributes to the discussion or helps someone. Another thing to remember is to treat other people with respect, no matter who they are. Everyone has blind spots, but there are very smart people on here, I appreciate listening and learning, and kindness makes it more enjoyable.
The most important thing to remember is the benefits of code reviews. They're a great way to learn, help the team arrive at a common perspective on how code is written for the organization, and improve the quality of the product. You're fortunate to be in a company that takes code reviews seriously.
On bugs, those are opportunities to write unit tests that reproduce the bug, fix the code, and prove that the bug no longer exists. After a while, you'll be able to recognize how to avoid bugs specific to the type of things you've done in the past. If it helps to know, you'll gradually get better, but even the best/most experienced/smartest people can have bugs in their code.
To summarize, don't feel bad or inadequate for making a mistake. Appreciate the fact that someone cares enough to help you improve and they also care about the company that they take the time to do good code reviews. You'll get better.
I've used https://www.freecodecamp.org to refresh on a few subjects and pick up some new tech that I needed. They also have coding challenges and interview prep.
You might also want to start hanging out at meetups - many are virtual now. When user groups open in-person again, they're a great way to meet other devs and pick up work.