David gave great practical advice for handling the situation, contextualizing the likelihood, and dealing with immediate anxiety. So, I will speak to the overarching and somewhat permanent anxiety portion as me and my partner deal with the same anxiety.

What helps with me is looking with a very long term view as then I get to take solace in reality, optimism, and positive statistics. It is most likely (as shown by many stats) that your salary will increase as you age. If they are your spouse, it is likely they will be with you forever, through all the problems. So, looking at the period of a lifetime, both of your being laid off is a small insignificant blip. Not to stay your anxiety isn't valid or proportional to the situation, but your emotions are likely calibrated to the short term, focusing on actively calibrating it to the long term helps reduce the feeling of anxiety the more often you make the effort.

If the worst happens and you both are laid off, you have a small period of no income. You either burn through some savings if you have it, or take on a little debt. You take a job you aren't as interested and live a modest life for a short period. Then, the market picks back up, you get new jobs and you rebuild savings with a higher income. So, the worst possible situation is a small portion of your life with less in the bank and less satisfying work that averages out with little long-term effects. You get the opportunity to learn how to deal with difficult situations and problems with your partner. This skill alone will have more long-term benefits than the financial cost of being underemployed. If this worst happens and it really hurts your mental health, you get a clear signal to invest more in your support network, coping skills, and overall mental health. Those skills as well will pay more long-term dividends that a little extra money would.

Thanks for sharing your worries, there are many of us and reading about someone else's experiences always helps. Just know the worst is unlikely, and even if it happens things will be fine.

Mid-Level Software Engineer at Series B Startup

Josh Lindsay

This is an obvious answer, but I think it summarizes the complexity well: the highest amount you can charge and still get work.

So, if you charge 1.5x and have more business than you deal with, charge more. If you charge 1x and don't get any, and you have already improved things like marketing, networking, etc, you will have to charge less.

One thing to keep in mind is that if you are very efficient, charging by the hour hurts your profitability. I know you said you are looking at long term contract roles, but usually investing in those gives you much worse revenue compared to project based contract work or regular employment. Jobs at startups are inflated by outside investment, and FAANG jobs are inflated by their leverage as money printing machines with their core businesses. It is much harder for you to compensate for that as a contractor. So instead, you would probably be better off investing that time in improving your regular salary with interview prep, networking, investing time for internal promotions, etc.

However, this isn't the case for project based work and you don't charge by the hour. For example, if you are a 10x developer and charge your hourly rate, you are giving them a 90% discount. If you do project based, that's not the case. In other industries like construction, this is seen as "piece work". It's better to switch to this as quickly as you can since you capture more of the value you generate. For example, if you charge what would take a normal developer 100 hours, but complete it in 20, you are making 5x more. The customer isn't hurt by this at all, since they are still getting the market value. You are just getting the extra value from your productivity. Or, you can charge the cost of 80 hours, when it would take a regular developer 100, and you still capture most of the increase in efficiency but still give the customer a good deal.

However, in practice this ends up being less satisfying. For one, there is tons of competition as you have to compete with developers who don't have access to us FAANG salaries but may be just as productive if not better. Chasing profitability ends up diverting you towards CRUD apps and small websites which are not technically satisfying. Most start off with a smaller network of customer base so they have to charge less to get their foot in the door.

If you want larger complex projects with many stakeholders and working alongside a team, then long term contracts are better for this. However, at that point, it's usually better to invest in your corporate career.

What's most important really depends on:

1. What are the company problems that need to be solved
2. What the company recognizes as important problems

Oftentimes these are the same, but sometimes they are not. I would argue 1 is better to pursue as it actually makes the company better. However, if you're more focused on internal promotions and recognition, 2 is better for the short to medium term.

If you are going to pursue an important problem that aren't getting the recognition they deserve, you should advocate for it so it enters category 2. For example, if you believe that a lack of internal tooling is causing devs to be less productive and bugs to me more apparent, you need to contextualize that for the business. You would want to show the extra cost to development time, the cost of fixing bugs, and have a concrete number for that. Also, have a concrete number for the opportunity cost, and then show the cost and impact of your proposed solution. If you're persuasive and have good management, this means you will be able to work on something you care about, is recognized by the company as important, and actually helps the company.

There may already be tons of things in category 2 you can work on. For example, if conversion is a problem your product is having, you can work on improving the, user experience, analytics, building/implementing a/b testing frameworks, etc. You can show how important your project is with obvious metrics like improved conversion rate. Decreasing cost and increasing revenue are always low hanging fruit, but there may be more interesting problems like hiring processes, dev processes, etc.

If you're having trouble finding important problems, it's good to talk to other teams, looking at overall company goals, and hearing from department heads or skip managers are great places for inspiration. People in your company who have been promoted quickly will have some more tangible advice and experience for your org. Keep in mind that these often don't align with your regular daily tasks unless you are already working at a cross team level like Staff, Principal, etc. So, try not to just look at your immediate team's needs, as that will lead you to solve problems in your team's subdomain and not larger more impactful problems.

Some easy things to look at to gauge how important a project is are:

1. How many people or teams it effects
2. How long the positive benefits will impact the org
3. How many people will need to work on it for it to be successful
4. The highest level of stakeholder who will have visibility

Hope this helps. One thing to keep in mind is that I have more experience with medium sized companies or ones that prioritize autonomy and independence. I assume since you are at Amazon there is complex structure and politics (call it stakeholder management if you prefer) that you will have to navigate. Someone here with more FAANG experience would be better advising you how to make this advice actionable given your specific large company.

My side project was instrumental in getting my first three jobs, despite it being non-commercial. However, now that I have more experience I will be leaving it off my resume. Side projects are good at establishing passion, initiative, technical experience, and helps with culture fit.

Early in your career, you're more likely to have gaps in any one of these dimensions. A somewhat technically complicated project that solves a problem is great at filling in these gaps. So, if you have a dimension lacking, like coding experience, a personal project can be a great supplement. However, since you mention you are a manager, you may not have any deficiencies in these. Or, the deficiencies are not big enough to warrant the investment into a complicated project.

However, this is just speaking on the perceived value to employers. Projects also have the value of learning hard and soft skills, can be extremely fun, etc. So whether or not the project is worthwhile for its intrinsic benefits is a personal choice. But, if one of the main motivations is for your CV, it would be good to draft your CV with and without this project to see if the benefits are worth the investment.

I agree with Lee. Depending on your culture and the bandwidth of the tech lead, I think it's much more important to use this opportunity to start establishing a great personal relationship.

Reason being is the practical stuff like how best to succeed, org structure, dev processes etc will be answered organically as you start to ramp up, work with others, look at the code etc. 30 minutes of talking about work related things with the tech lead won't have a large impact on how well of efficient your onboarding goes.

However, 30 minutes establishing a good personal connection will. There are tons of opportunities to learn about the code, but not many to connect with your tech lead. The earlier you establish a great personal connection, the earlier you can benefit from the better connection. This will manifest with benefits like
1. More patience with any onboarding troubles
2. More personal investment of the tech lead in your success 
3. Reduce your resistance in reaching out when you need help
4. A headstart in building an even better connection

There's not really a script in building a good relationship. But easy tactics are 
1. being genuinely interested in them as a person and ask questions about themselves and things they are interested in
2. Finding points of connection like hobbies, experiences, etc.
3. Be vulnerable when socially appropriate
4. Being some most likely much needed positive and enthusiastic energy (I don't think you will have a problem with this given your question)

Obviously, if your tech lead is all business or overworked this will be more difficult. However, you won't know that until you try connecting first.

I had the same experience at my workplace. There were no tests, minimal outdated docs, devs with many tasks, etc. Startups are chaotic and the code and processes will reflect that.

I found a sink or swim approach to be best. Find a bug that's being ignored, and work on fixing it. It will force you to bounce around the codebase, get context for business logic, talk to devs that are in the git blame, etc. Plus, you're providing value to the company while you learn.

The silver lining is all these poor processes give you the opportunity to make a massive impact. During onboarding, if you find the dev environment difficult, improve it while you learn to set it up so future devs can benefit. If docs are missing from something you are working on, add them. If you find tests are missing, add them as you learn the codebase. It forces you to solidify your understanding of the business logic and architecture while providing more value.

With a 9 to 6 schedule and a commute, it's asking a lot of yourself to do extra when you get home. Not saying it's not do-able, but due to the constraints I don't think a 'good balance' would be possible. Especially if you want to have some other hobbies or a social life. If that's a tradeoff you're willing to take early in your career, as many of us did, it will be beneficial career wise. However, I would advise you to be suspicious of any intuition you have that this will be "a good balance".

A good compromise to reclaim some of your free time would be to do as much learning as you can at work. So, get as competent as you can as quickly as you can at your regular responsibilities. Then, you will have the freedom to carve out an hour or two of your working time to read blogs, play around with new tech stacks, leetcode, etc. You shouldn't work on any project that could make money at work, but other than that you should maximize your self learning during your working hours.

A way to do this without taking away time from your employer is to take on learning projects at work. So anytime you can work with a new tech stack, deep dive into a tricky bug, etc, you should. That way you don't have to steal time away from your regular duties or free time as you will be getting the learning "for free" from your regular work. You're just taking the initiative to make your regular work as maximally educational as possible.

Building in public is great for this, so posting demos, status updates, user interviews, etc. on public  People get value from seeing how build things I get practice pitching/posting, and you grow a user base as you build instead of having to get it all at the end.

A welcoming community for this is indie hackers, <https://www.indiehackers.com/>. They have tons for great resources and an active community, so you can post updates there (there's a whole section and culture around it). Also, the community is super supportive so you automatically have some people willing to check out your product.

The best way is always talking to users early and often. So, if you have outreach to people in your relevant vertical who are interested in the idea, they give you useful feedback early and have incentive to try out your product.

The fact that you're bored is a good sign, that means you're probably competent in your role.

So, it's probably time to tackle harder problems. Expanding your role to handle more aggressive refactors, be involved in more of the product design process, building internal / developer tools, and mentoring others are all great problems and domains to learn more and add some positive stress.

If you have a good manager, let them know and they will be happy to give you harder work. If your manager is not as helpful, then you get to talk to coworkers and other teams to identify problems yourself and take away time from your regular responsibilities to work on these. If your bored and can manage expectations, it will be easy for you to manage your ambitious learning and your regular day to day.

Leading by example is great here. Start communicating in the way you think it should be done. But remember to keep in mind that there are many valid ways of communication, and what is "better" should be driven by noticable benefits like productivity, enjoyable work, improved product, less long tail negative impact, etc.

If you're communication is better and beneficial, others will notice this when they work with you and have their work be more joyful and productive. They will remember this, and try to do the same.

If your commutation method is not better, and they are opting for a more scattered, context driven and agile approach, you will notice this when the time you put into 'better" communication doesn't provide meaningful benefit.

Either way it's a win-win. If your method is better you will have improved your organizations processes and established yourself as a leader. If it's not better, you learn more about different styles of communication and establish yourself as an ambitious team member who cares.

This isn't always necessarily a bad thing, it depends on your company culture. I would say unless you have good evidence, give the new manager a try. If it ends up being a bad fit, transfer teams, but don't do so until you're sure that the current manager is poor and the alternatives are good.

From my experience, if it's a manager without experience, you get more autonomy. They have less experience, often less expectations, and rely on you more to take charge. This is a great opportunity to better advocate for work you want to do and push back on things like timelines and priorities you think are detrimental to your work and organizational goals. It is also easier to stand out since other team members may not be able to make use of the opportunity as much as you are.

However, if the manager is purely HR related and doesn't overlap with your actual work and priorities, then my point is less relevant.

I feel you, I had that issue with my first remote job. You can definitely build meaningful relationships, I have, but it will take some effort and vulnerability. I don't know if it's necessarily the default with remote work, but it's way easier to fall into comfortable disconnected patterns, especially with the focused work of developers.

It's easy for interactions to be transactional when they're about work. A code review is way less personal than raving about your favorite tv show or venting about a frustration in your life. I found making an effort to be fun, kind, and human makes it easy for others to return the favor.

One way to break the ice of vulnerability is with public praise. Either in a public slack channel or decent sized meeting, give a coworker a shoutout for something helpful they do. I remember almost every time someone has given me a genuine compliment and it makes it much easier for me to connect with them on a personal level.

A few things I found useful

1. Schedule a half an hour one one with someone and make the goal not to mention work.
2. Use liberal memes and jokes when interacting with coworkers in private chats.
3. Share your suffering. If your stuck debugging some niche issue for a few hours or are putting out a fire, involve someone else. Patching a prod database in a pair programming session builds way more trust and connection than a async code review.

If you try to make an effort, other people will reciprocate. So just find a way that to reach out that makes you the least uncomfortable.