Category: letters to a new developer

Writing great software isn’t all about the software you write

This is a guest post from Adam Leventhal. Enjoy.

Dear new developer,

I love software engineering. Even as excited as I was to start my first job, I didn’t imagine the deep and enduring joy it would bring. In my career, I’ve oscillated closer and farther from writing code, and while management and entrepreneurship are wonderful, there’s nothing like the pure joy of building software.

Building great products takes a team. Code is a critical piece, but that doesn’t mean you need to stick to your narrow lane. Yes, developers write code, product managers write specs, doc writers write docs, marketing writes slides, sales sells, support supports, etc. Focus is important, but it’s a myth that doing your job well requires focus at the expense of understanding the holistic view of how products are built. Understanding the full product lifecycle–from conception, to purchase, install, and support–will make you better at your job and lead to better products.

One of the first things I worked on professionally was a product called DTrace. It’s a tracing tool to help understand how systems operate. It’s used to find bugs, chase down performance problems, or explore how a code base operates. I was drawn to the project early on because of the extremely precise and creative engineering required to safely instrument running programs and kernels. It was all very cool, very satisfying. An extremely formative moment in my career came when I was demonstrating an early DTrace prototype to a customer. We used this new lens into their software to understand behaviors that had always been mysterious to them. Their ideas came one on top of the next as we exposed all kinds of crazy behaviors and pathologies on the fly. I had seen the power and utility of what I had built in my own use, and my team’s use. Seeing a customer–and engineers quite different from me–get so fired up was eye opening. I still wanted to build cool stuff and write hard code, but understanding the problems it solved and the people who used it informed my work from then on.

There were three engineers working on DTrace. We were our own product management. We built features we needed to solve urgent problems for ourselves and customers. We were our own marketing, giving talks and writing blog posts. We were our own doc writers, churning out a hefty users guide. Those activities weren’t downstream of development, they were an integral part of it. When building a feature, we talked about how to explain it to sales people, to users, to support engineers. Sometimes that meant changing what we had planned to build: if you can’t write the documentation for a feature you’re probably building the wrong feature.

Almost a decade later I joined a new team that could not have been more different. The development team was comfortable in their ignorance of the broader product. They didn’t just stick to the code, they were narrowly focused on just their own subsection of the code. In the Solaris Kernel team where we built DTrace, we would follow bugs up and down the stack, through multiple, enormous code bases, to determine the root cause of problems. Here, developers were content to chase a problem to the edge of the module they owned, and then reassign the bug to the developer who owned the next module. The team barely had a shared understanding of what they were building, much less of that true north of customer need. That gap was evident in the end product: modules were poorly integrated and features fell short of solving customer problems.

Whatever you’re working on, understand not just what’s needed, but why. Listen in on a sales call, talk to a customer, or do a ride-along with a support engineer working on an escalation. Some companies have great programs to involve engineers in the broader product lifecycle. If yours doesn’t it’s probably (hopefully!) because no one has asked. Empathy is an engineer’s greatest asset: empathy for the customer to understand their problems and priorities; empathy for the doc writer trying to explain a complex feature; empathy for the next engineer to pick up your code and make sense of it. Empathy starts from a curiosity to understand what and why.

Find true north for the products you work on. It will make your work better and bring you more satisfaction.

Adam H. Leventhal is an engineer at Oxide Computer Company building a new, modern computer. Previously he was a software engineer at Sun Microsystems, CTO at Delphix, and co-founder, CEO at Transposit. He’s sheltering in place in San Francisco with his wife, teen, toddler, and two dogs. Find more of his writing here, here and here.

Don’t sign anything you can’t understand

Dear new developer,

I want to preface this with the fact that I am not a lawyer, so please don’t take this as legal advice. This is my experience with employment contracts and other legal adventures as a software developer.

When you are starting a new job, you’ll be confronted with a big basket of paperwork to sign. Actually, nowadays it’ll probably be a pile of PDFs. When you leave a job, you may sign a termination agreement, which again will be a lot of legal documents.

Read all of them. If you don’t understand something, ask what it means.

These legal agreements can profoundly affect your career. (Here’s an example of a noncompete causing a fair bit of legal pain.) It also doesn’t really matter what someone like your boss says when you are hired or leave–it’s the legal documents everyone signed that will control. (Often the employee handbook is incorporated by reference into your starting docs. Ask to see that as well.)

So read them and understand them. If someone won’t answer what a phrase means, seek info from someone else at the company, perhaps HR. You should, in certain circumstances such as a layoff, make sure you get the document reviewed by a lawyer who is looking out for your interests.

I have only sought advice from a few lawyers in my life, but all of them I found through referral. I’d recommend finding your lawyer that way as well. Ask family members, other professional contacts, or even people you’ve interacted with online in your area for a recommendation. A good lawyer should:

  • cost a lot of money–my most recent lawyer charged $475/hour
  • be willing to listen
  • focus on understanding what you want from them (for example, “is this employment contract normal”)
  • stick to your budget; make sure you communicate that
  • be local–different laws apply in different countries, states and cities
  • have expertise in the area and be willing to refer you if they don’t

You’ll pay for the certainty of a lawyer’s review, which is why you should check out the documents and only ask about sections you don’t understand, rather than sending them the entire document.

Now, for higher risk/return situations, it may be worthwhile to have every document reviewed. When I joined a startup as a co-founder, I had the entire agreement reviewed. But I don’t do that for my normal employment agreements or any contracts I sign as a consultant.

There are three main benefits of reviewing these agreements. (I’ll focus on employment agreements as those are by far what I have the most experience with, but realize you should read and understand any legal document you sign.) The first is that often there is scope for you to protect previous projects, ideas or side businesses. This can be as simple as listing the project in broad terms. Should you have any desire to commercialize a project in the future, doing this ensures it is not entangled with your employer’s properties.

Another benefit is that you’ll know your rights. Even if the agreement is punitive, wouldn’t you rather know, rather that discover it after you’d violated the contract? Here are things I look for in an employment contract:

  • Who owns what I create while on the job? As an employee, it will almost always be the employer. If you are contracting, it can vary and I know people who’ve started businesses because they had the insight to ask for non-exclusive rights to the code they were creating.
  • Who owns what I create while not on the job? In most cases, you should own anything you build on your own time, but be wary if the company works in a similar area, and if you use company resources to do the building. Get clear on this. (Some states, such as California, have explicit laws explaining the boundaries.)
  • What limits are placed on me after I leave? Do I have a non-compete, and if so for how long? How broad is the non-compete–what areas of employment are now off limits? What about confidentiality agreements? Is there anything else I need to do? One company employment agreement dictated I let them know where I was working for three years in the future.
  • What am I getting paid? Any salary or bonuses that were mentioned verbally should be included in written form, either in the offer letter or employment agreements.

It’s worth noting again that the verbal promises of anyone at the company are typically worth far less than the written agreement. I’ve had some employers honor verbal agreements (and those are good employers to stick with!), but typically when the rubber meets the road, what is written down is what will be enforced. So if someone says “ah, don’t worry about that clause” then simply ask if you can strike it from the document. And if someone promises you something, ask for it in writing. No need to be arrogant, but realize that if anyone in a business setting won’t put a statement in writing, getting what was promised will probably be difficult.

The final benefit of reading what you’re signing is that now that you have protected some of your previous inventions (if any) and know what you are agreeing to, you can negotiate.

The amount of leverage you have to change any of these agreements depends on how big the company is and how much you are desired. If you’re a new developer and the company is large, they probably won’t budge. If you’re a senior engineer that the hiring manager really wants, clauses can be negotiable. It doesn’t hurt to ask.

I understand that you may not feel you have a lot of power. You may have gone through a grueling interview process and may not have many other options if you don’t take this job. In that case, you don’t have a lot of negotiating power, but at the least you can know what you’re agreeing to. The earlier you can see these agreements, the better. The best is if you can see them before you turn down any other job offers.

At the end of the day, these agreements can have a large future impact on your career. They can limit who you can work for, what you can do, and who owns what you have made. Understand what you are agreeing to.

Sincerely,

Dan

Take time for decisions

Dear new developer,

For large long term life decisions, you should realize a few things.

First, that few decisions are 100% irreversible.

Second, that the choices you have in the future are based on the choices you make (this is called path dependence).

Finally, that you should take time for important decisions. In fact, you should consult others, spend some time dwelling in your own head, and sleep on it.

Consulting others

I like to check with other people who have been in similar situations when confronting a big decision (like switching a job or starting a consulting company). This of course means that I’ve kept in touch with them over the years (via LinkedIn or by other means). This can be as simple as a coffee or beer or phone call. Even an email where you document the choices as you see them can be clarifying.

Note, you don’t have to do what they suggest. What you want is someone who:

  • is close enough to you to have context, so their opinion matters
  • will be honest in sharing their opinion
  • is going to make you see the decision in different ways
  • has experience with similar situations

Spend time thinking about it

Go for a walk. Write some things down (I’m a big fan of plus/minus lists.) Don’t think about the decision for a while. All of these will help you get out of your head.

I have found that it’s easy for me to get wrapped up in a decision and overestimate its importance. The work you do day to day in a company and the people you meet matter a whole lot. But there are many many excellent people everywhere.

But, you should definitely not feel rushed into any decision. If a person offering you an opportunity (whether that be a project, job or other choice) is rushing you into it, that’s a bad sign. It’s an indication that the choice can’t stand on its own.

Sleep on it

Finally, sleep on it. There’s an interesting discussion here, including tips to have a notebook by your bed, but the long and short of it is that if a problem is worth consulting others and dwelling on, often taking an additional eight hours won’t make or break the situation. And a night’s sleep can allow you clarity. Sometimes things that seem true the night before (“I am afraid of taking this job”) appear in a different light after (“What I’m really afraid of is change”).

Sincerely,

Dan

What’s your best advice for a new developer?

Dear new developer,

Dev.to is a relatively new community of developers. A few years ago, someone on that community asked for advice for junior developers, and I found the answers fascinating. Here are a few of my favorites.

People should respect you. It’s your right to push back against disrespectful interactions. If it’s waved away with “oh, [person] is just like that,” know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong. – Sarah Mei

Respectful communication and interaction is the foundation of trust, which is the foundation of team building, which is the foundation of software delivery.

Not getting your pull request through code review first time is okay. Everybody has their own approaches to problems, and a comment on your code review saying “X could be improved by Y because Z” doesn’t necessarily mean you’re not a good enough developer for only thinking of X, rather than Y. It’s usually more a case of your haven’t encountered a scenario that leads you to see the reasoning Z that causes you to use Y over X yet. – Aidan Walters-Williams

We all have something to learn. And our code is not ourselves, so when someone tries to improve our code, they aren’t attacking us.

Reporting a problem you’ve discovered is good, thorough analyses are better, proposing a solution is best. It doesn’t have to be right, it just has to start the discussion. – Dian Fey

It’s always good to go a step beyond reporting a problem because a) additional investigation may reveal it isn’t actually a problem and b) if it is a problem, the more you provide up front, the easier it will be for anyone trying to solve the problem (including future you) to replicate the context and hence investigate the problem with less effort.

There are a lot of great gems in the post.

Sincerely,

Dan

A letter to myself as a fresh software engineer

This is a guest post from Luca Florio, lightly edited. Enjoy.

Dear Self,

You just graduated and you are ready to start your career in the IT field. I cannot spoil anything, but I assure you it will be an interesting ride. I’m writing you this letter because I want to give you some advice that will help you be a better professional. Nothing you won’t learn by yourself in the next few years, but it is something that I wish someone had told me when I started my career. They are not ordered by any means and are all equally important.

Run a marathon, not a sprint.

The road to becoming a good software engineer is a long one. Don’t rush on stuff, and don’t give up just because you are not getting an easy and fast win. Take your time to learn and become good in the topics you are interested in. Remember that this is a marathon, not a sprint.

Be humble, not stupid.

It is good — sorry, it is fundamental — to be humble. There is always something to learn from others, even when you are an experienced professional. But this doesn’t mean that everyone is better than you. You have to respect yourself and your skills. When you don’t respect yourself you become stupid, not humble.

Compare with yourself, not others.

There is no point in comparing yourself with others. There will always be someone better than you in your job. And there will always be someone better than the one that is better than you. And there will… ok, you got the point. Just do your best. If you think someone is a better engineer than you are, learn from him/her. Keep doing your best, and eventually, you will be a reference for someone else.

Respect people, not titles.

During your career, you will work with exceptional professional. Most important, you will meet exceptional human beings. Respect people for who they are, not for the title they have. If “foo” is “Principal Senior Lead Engineering Chief Architect” doesn’t mean that he deserves more respect than “bar” that is a junior software developer.

Choose the challenge, not comfort.

The road will be full of crossroads. There may be multiple choices, but everything boils down to a choice between your comfort zone, or go outside your comfort zone. There may be a moment in your life — hopefully after decades of work — when you will feel the need to cool down a bit because you will be satisfied with what you achieved. Until that moment, try to go out of your comfort zone. It will make you a better professional and you will feel more satisfied with your career. Remember that the best things often happen outside the comfort zone.

Jump on the whiteboard, not on the keyboard.

When you have to design a new feature or a new system, don’t jump on the keyboard to start coding. The “muscle” you have to train and use as an engineer is your brain, not your fingers. Always think before acting. For this reason, jump on the whiteboard instead of the keyboard, and start thinking of what you should implement. Better if you have a sparring partner to challenge your thoughts. Oh, when I say “the whiteboard” I mean “every object that can help you think”, be it pen and paper, a notebook application, draw.io, etc.

Deliver value, not code.

Please don’t be affected by the NIH syndrome. There is no point in reinventing the wheel. Avoid wasting time in something that is already out there. If you can achieve your goal simply glueing together some tools, just do it. What you should deliver as a software engineer is value to your business, not lines of code.

Choose life, not work.

In the IT field, it is easy to focus too much on work. After all, for most of us, it is not just a job, it is passion. Remember that work is important, but life is more. Live a meaningful and rich life. Play sports, read books, find hobbies, travel and see the beautiful world we are living in. Hangout with friends, find a partner for your life and give to your partner all the love, attention, and support that you can. You’ll be surprised how much having a rich life will improve you as a professional.

That’s all I can tell you right now. I still have a lot to learn.

One last thing: enjoy the ride! 🚀

With love,

(a more experienced) You.

Previously published at florio.dev.

Luca Florio is a Software Engineer working remotely for Pleo, a Danish startup. He loves to study new things and share what he learns in his blog.

How to be a 10x engineer: Business value for technologists

This is a guest post from Donnie Berkholz, lightly edited. Enjoy!

Dear new developer,

Since joining an enterprise (the world’s largest business-travel company) a while ago to drive their DevOps transformation, my ongoing mental evolution regarding the value of technology has gone through an almost religious rebirth. I now think in a completely different way than I did 10 years ago about what technology is important and when you need it. If you want to become a 10x engineer, you need a different perspective than just working on things because they seem cool. It’s about working toward the right outcomes, whereas most of us focus on the inputs (what tech you use, how many hours you work).

It all comes down to business value. You need to contribute to one of the core factors of business value, or however incredible the technology is, it just doesn’t make a difference. If you don’t know what that really means, you’re not alone — most of the technologists I know have trouble articulating the business model of their employers.

I think about it as 4 primary factors:

  • Money. This comes in two flavors. First, you’re creating new efficiency, which increases the profit margin. This could either be through lowering the underlying fixed costs of running the business, or decreasing the cost of goods/services sold by saving a little money on every one. Second, you’re increasing sales, which grows overall revenue. In a cost center within a larger enterprise, or in saturated markets, the former is the most common mode of operation because it’s hard to capture new opportunities. In the latter, it’s about growth mode – investing to capture new value, and often assuming you can make it profitable later. This could be framed as “land and expand” or with the assumption that your company will increase the price and margin once it’s gained a sufficient market share to do so with lower risk. Do you understand your company’s business model? Where does the money come from, who are the customers, what are their needs, what is the sales process and cycle, and what are they buying?
  • Speed. Again, there’s a couple of versions of this that overlap. The overall goals are either initial time to market or speed of iteration. Time to market can come at the expense of significant technical debt, while long-term accelerated iteration cycles are about product-market fit. If you know of the Lean Startup approach promoted by Eric Ries, this should sound familiar. From a long-term perspective, iteration cycles require a balanced approach of customer perspective and technical debt. Otherwise, your company can’t deliver value to customers quickly due to accruing interest on its tech debt. In practice, this can drive an approach that involves gradual refactors with the assumption that long-term rewrites (or e.g. strangler pattern) will be required. It’s the classic “design for 10x but rewrite before 100x,” to paraphrase Google’s Jeff Dean.
  • Risk. As before, this essentially boils down to executing on new opportunity or loss to existing opportunity. Dan McKinley has a fantastic post on why you should choose boring technology, because the important risks are in the business model vs the tech. You should only make a small number of bets on new technology when it will really make a difference in your ability to deliver on business value. For existing opportunity, it’s more about risk avoidance. Typical approaches tend to end up in some mainframe application that one nearly retirement-age developer knows but is afraid to touch. However, a more sustainable model is to implement heavy automation if it truly is a business-critical application that justifies the investment. Relatedly, risk avoidance is where security shines. One of my favorite perspectives is Google’s BeyondCorp model, which assumes your perimeter is compromised and acts accordingly.
  • Strategy. Often not immediately visible in the above approaches, investing in strategic growth opportunities is consistently a great path to success in your business. Do you know your company’s strategy? They probably have posters up and meetings about it all the time. Could you say it out loud? Do you know how it maps to concrete actions? Although any individual opportunity may fail, your contribution to executing on the technology behind that opportunity will not go unnoticed. Similarly, if you’re involved in divesting from areas your employer wants to leave as part of its strategy, you have a real but often smaller opportunity to leave your mark upon the work.

Although many other factors have an impact upon business value, those are 4 of the most important ones that can make you consistently successful as a technologist. The key is to understand which ones play into your work, so you can act accordingly in your day-to-day efforts and as part of your career strategy. Are you building software for a cost center, a growth incubator, a risk center, or at a company that cares to invest in speed? Taking full advantage of this approach could make you the 10x engineer you’ve always wanted to be. Best of luck in your journey, and may you spend time where it matters!

Sincerely,

Donnie

Donnie Berkholz has been driving the DevOps transformation at CWT (formerly Carlson Wagonlit Travel) since early 2017. Prior to that, he led a global team at 451 Research providing research and consulting around leading-edge trends in software development and DevOps. His background includes roles at RedMonk — where he focused on DevOps and open source — and well over a decade at Gentoo Linux, where he worked his way up from a developer to lead a group of more than 250. One of his passions is the social side of technology, and he’s led initiatives to turn around unhealthy teams as well as measure and act on open-source community metrics.

He got into tech almost by accident, because his role as a biophysicist got increasingly computational and he decided he wanted to focus on the technology. Prior to tech and science, he did a stint as a journalist. Donnie now combines that diverse skillset in communications, data-driven thinking and technology to drive companies toward differentiation with leading-edge technology.

I’m writing the book I wished I’d read

Dear new developers,

Update July 5, 2020: I now have a launch date and a cover.

You may have noticed the pace of new letters has slowed down a bit. There have been some fantastic guest posts, but there’s only been one new letter per week for a while. There’s a reason for that.

I’m excited to announce that I’m writing a book. It’s the book I wished I’d had when I was beginning my development career.

It’s based on this blog, with ideas, text and guest posts drawn from it. The format is similar: letters covering a variety of topics. However, all the content has been thoroughly reviewed, organized and revised. You’ll also see new letters covering topics left untouched by this blog.

I just shipped off the first half of the book to the publisher. If you want to be in the loop, contact me to be put on the book announcement list.

– Dan

You’re going to put some plates in toasters

Dear new developer,

I saw this insightful tweet:

The whole thread is worth reading, but you get the basic idea. Sometimes you don’t know what you don’t know.

When I think back over the years, I am amazed at how many things I can do without thinking now that would have been baffling to me at the beginning of my career, including technical and non technical knowledge). This list includes:

  • navigate files and directories work
  • examine an HTTP call
  • determine the performance characteristics of an application
  • refactor an application
  • architect a large application
  • run a meeting
  • plan a project
  • exit vi

The road is long. And I still put plates in toasters periodically.

Recently at work, I energetically revised a planning document, adding what I thought was a ton of insight and value. Later I found out that the value I added was actually negative and that I’d done more harm than good to the organization’s goals when adding my thoughts. Man, was that a humbling and learning experience. Actually, that was more like putting a fork in a electrical socket than putting a plate in a toaster.

Much of what I know is at a high level with the idea that I can dive in (using resources like Google or Stackoverflow or a mentor) if I determine a need. Just knowing that something exists means that I can leverage all the great learning resources available if I see a place where it might appy. I also do a lot of pattern matching, where I compare how one system or process worked and see if and how that knowledge applies to a new problem.

So when you find yourself floundering, take a deep breath, forgive yourself, and dig in to learn. Foundational competence is something that you will acquire with time and study. But until you do, you’ll be putting plates in toasters.

Sincerely,

Dan

Learn an IDE

Dear new developer,

Just like you should learn a text editor, you should learn an integrated development environment (aka IDE). This is typically a standalone program focused on one or more programming languages. They range from free to a couple of hundred bucks in pricing.

Using an IDE will give you the following benefits:

  • It will be easier to navigate a project. Typically IDEs have a tree view of the entire project. Especially if you are not familiar with the command line, having this may make it easier for you to see how pieces of the project fit together. If the language supports it, an IDE can provide powerful searching capabilities, allowing you to see where a function, method or class is used.
  • Often these have refactoring support. Refactoring allows you to easily rename variables, functions/methods and files. If the language or IDE support it, references to the renamed entity can be updated as well. This will help make the code more fluid.
  • Debugging and code inspecting capabilities can be very useful. You can walk through code that is running locally and see the state of variables and make function calls. This is especially helpful if you have a test that can drive the code and replicate a bug. You can also, if the language supports it, connect to remote servers. (Many languages have command line debuggers as well, but it’s usually easier for a new developer to use an IDE.)
  • The IDE can provide text manipulation functionality. For instance, if you want to add documentation comments to every method, or an easy way to generate boilerplate methods, IDEs can provide this. It’s often easy to customize to your needs as well.
  • Easier learning the language or framework. If you are not sure of the exact name or syntax of a library call, an IDE can suggest it (often based on you typing a few letters). The documentation is often integrated as well, so you can, for example, see the javadoc by mousing over a method call (in a Java friendly IDE).

Obviously, as you see above, an IDE is very powerful. It’s also very tied to a language and the language’s features. If you are using a dynamic language (PHP, ruby) your IDE will have different capabilities than if you are using a statically typed language (C#, Java). But in either case, mastering your IDE will make it easier to write and debug code on your development computer.

Sincerely,

Dan

How to go through a layoff

Dear new developer,

At some point in your career, you might get laid off. This is different than being fired for performance reasons (which might happen too, unfortunately). First off, I am not a lawyer, so this is based on experience, reading and research, not a law degree.

Please don’t take this as legal advice or anything other than an informative blog post.

So, you get called in for the meeting. Your boss is there. Likely someone from HR is there. They tell you the news that the company has decided to part ways with you.

Your heart sinks. You get a big fat packet of paper. The HR person runs through it quickly and asks if you have any questions. You feel a bit dazed.

Take a deep breath. Realize that no matter how crushing this feels, two things are true:

  • this isn’t personal.
  • you’ll get through this.

Ask any questions you have. Some important questions:

  • when do you have to sign this packet of documents by
  • is there a severance, and if so, how much
  • what about other things that were yours (401k, FSA, HSA)
  • how to say goodbye to your teammates
  • what about other things that are the company’s (computer, books, equipment, etc)
  • who at the company you should contact if you have other questions

Don’t be unprofessional. Don’t get mad.

Don’t try to get your job back (it’s gone, sorry!). Don’t agree to anything other than reviewing the paperwork.

Make sure they have a non work email for you so they can send you additional docs if needed.

By the way, if they have their act together, you won’t have access to your work accounts after the meeting, for better or worse.

You can ask why you are being let go. Don’t be surprised if you don’t get many details.

Email or LinkedIn are good options for saying goodbye. Write a quick note to your former co-workers stating that you enjoyed working with them. You can express regret at leaving, but there’s no sense in badmouthing anyone. You never know if you’ll end up working with these folks again.

After the meeting, take some notes on what happened during the meeting. Use your own computer or a notebook. This will help make sure you understood everything that happened. If you want, add some details about anything leading up to the layoff (some things are more obvious warning signs in retrospect, and you want to remember them in the future).

Before you sign anything, it’s always a good idea to run any agreement by an employment lawyer. Yes, they cost a lot of money ($X00/hr) but they’ve seen these kind of contracts before and are legally obligated to do right by you–unlike the company’s lawyers who wrote up the agreements, who are obligated to look out for the company. At this point it’s “just business”, and you want to protect yourself. Ask the lawyer for their advice (“does this seem reasonable, are there other clauses I should ask for”), but make clear your budget and timeline. (If you don’t know a lawyer, ask for a referral from a friend.) There may be some back and forth with the company over the documents.

After the lawyer has looked any agreements and you’ve had some time to think, you can sign the agreement. Or you don’t, based on their advice and your feelings.

After that take a bit of time to grieve, if you can. Even if the company or job wasn’t the perfect fit for you, it hurts to part ways.

Then, roll up your sleeves and start looking for a new opportunity. Is it time to try contracting? Maybe something else that is risky? Or to reach out to your network and see what is available?

A layoff feels like a defeat. But you’ll get through it.

Sincerely,

Dan