When is it time to quit my 9-5?

This is a guest post from Pariss Athena. Enjoy.

Dear new developer,

Honestly, I don’t think there’s one absolute answer. I believe the answer depends on you and the risk you’re comfortable taking. However, I do think there are things you should take into account before jumping the gun. This is how I personally knew it was time to give my notice and take my business full time…

Everyone’s situation is going to be different. This is my story.

I announced that I was launching Black Tech Pipeline (BTP) in June of 2020. Around this time is when everyone was really riding the Black Lives Matter train, and claiming their allyship after George Floyd’s murder.

This was not why I decided to launch. Weeks prior to the pandemic and quarantine, I was constantly tweeting about launching BTP “in the next weeks.” Those next few weeks just happened to fall during a tragic time.

But these two things did contribute to the eagerness of announcing my launch:

  1. I knew my performance at work was dropping. I stopped attending happy hours, and engaging in conversation. It wasn’t because there was something wrong with the company I worked for, my focus just shifted.
    I was rightfully distracted by social media and the flooding of content surrounding the injustices happening in the Black community. Knowing the work I should be doing full time vs the work I was actually doing full time made me annoyed with myself. I wanted to just help create impact in my community. That’s it.
  2. I was pissed the hell off.

I want to preface this by saying that I know I have the privilege of already having a platform and a following. I know that contributed to the traction my launch announcement received.

I had been writing newsletters surrounding Black Lives Matter a few weeks before announcing my launch, and those newsletters gained lots of traction on social media, which gained me more subscribers. I decided to announce the launch of BTP in my newsletter, and the response to the announcement was sign #1 that I was going to be on my way out of my job.

My calendar was flooded with calls. I had 15 minute breaks in between calls from morning to evening. I was talking to employer after employer wanting to take advantage of BTP’s services. Aside from calls, I received emails non-stop. Not just from employers, but from opportunity extenders of all sorts. It was tiring but good problems to have, especially before even launching.

On top of my performance dropping at work from being distracted by the political climate, I was now also distracted by BTP’s calendar being completely booked. Having so many calls booked seems promising, but until I had client agreements signed and invoices paid, I wasn’t going to leave my job, especially during a pandemic.

Plenty of employers expressed interest. They loved the origin story of #BlackTechTwitter and how it led to me building Black Tech Pipeline. There were lots of promising words, but you can’t go off of words of interest to determine your safety net.

The way I determined my safety net was by looking at my finances with my mentor, Leon Noel. I kept in mind what I was making annually at my 9-5. I already knew what I was charging for my services so I also used that to think about worst and best case scenario. He told me to ask myself:

  1. At the very least, how much do you need to make to pay your bills on time?
  2. Are you willing to give up your typical lifestyle?

I looked at my pricing model and mapped out how many clients I’d have to have per month to get by. And not just how many clients, but:

  1. Which services would those clients have to pay for in order for me to get by?
  2. And when those clients pay me, how much money do I have left over after putting 30-35% into savings for tax time and personal savings?
  3. And if I don’t want to live a life of just getting by, how much money do I need to make, with tax deductions in mind, to live the life that I want to live?
  4. How much money would I like to make annually? What will it take to get there? Can I project that?
  5. Is it possible that I can stay at my 9-5 and balance my business at the same time?
  6. Could I potentially hire someone to help me out so that I can do both?

Those numbers and questions are extremely important and it’s what you should think about before making the decision to bounce from your 9-5.

Sign #2: Personally, time was not on my side. It came to a point where something had to give. It wasn’t fair to continue working my 9-5 when I wasn’t giving it my all because I was busy prioritizing my own business. I also wasn’t willing to give up potential clients, miss calls, and wait to reply to business emails for the sake of my 9-5.

Sign #3: Potential clients turned into paying clients. Agreements were getting signed, and invoices were being paid. That sounds dope, but that’s not enough to say you’re secure. The question is,

  1. With the money you’ve been paid + your savings (if any), would you be able to quit your job and be able to pay your bills for the next 6 months, even if you got no other paying clients?
  2. How many signed/not yet paid clients do you currently have?
  3. What’s your projected paying client rate for the next month?
  4. What are you going to do if you don’t have any new business coming in?

These are the risk questions, and you have to be very real with yourself when you answer them. The last thing you want is give yourself optimistic answers and then be left with late payments, debt, and serious financial hardship.

My personal answers: I’d be fine. I determined this by the tangible money I had been paid. I didn’t count the client agreements signed because anyone can back out of an agreement before the work begins, something could delay the process on their end, etc. I made enough to feel confident in giving my job my notice, and to continue living the life I want to be able to live. I only considered signed agreements when I thought about future business expectations: “I have {x} many clients potentially secured for {x} services, which will keep me financially stable for {x months}. I also have {x} many potential client calls lined up for the next {x weeks/months}.”

I also double checked with my mentor, and when he approved, I felt even more confident in leaving.

It was bittersweet, but I gave my notice. It was time. ✨Shout out to G2i for being the best employer I’ve worked for since entering the tech industry. Amazing culture, dope people, and doing the work of solving the broken vetting process.

Now, I don’t know what’s going to happen with Black Tech Pipeline. Maybe things are only going well right now and we’ll struggle later down the line. I don’t know, I hope not. I will do everything in my power to make this company successful, but there’s only so much that I have control over. That’s the risk. That’s entrepreneurship for ya.

If I’m being totally honest, a job will always be there. Companies will always be hiring. I know- I’m a recruiter.

— Pariss

This post was originally published at Black Tech Pipeline.

Pariss Athena is the creator of the movement, hashtag, and community #BlackTechTwitter, and Founder of Black Tech Pipeline.

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

No choice is permanent

Dear new developer,

Sometimes when you are thinking about a new job or shifting to a new position in a company, it can feel overwhelming. What if I make the wrong choice? At least, I’ve often felt that way.

Every choice you make has effects. When you choose to study ruby, you can’t also study python (opportunity cost!). When you work at a company, you will learn how that company works, but not about how other companies work.

I sometimes have FOMO (fear of missing out) when I commit to one path. “What would have happened if I had gone down another path?” I wonder.

That’s OK. I think it’s human. But you still have to make a choice.

I remember talking to a friend once about making decisions. She said that she likes to make a decision as late as possible. I think this is a good practice. Gather the data you need and can get without asymetric effort (that is, the larger the issue is, the more effort you should put in–I should invest more effort into learning about joining a new company than I should into learning a new project within the same company, for example). Make the decision as late as you can, because you’ll learn more as time goes on.

However.

It’s also important to realize that few decisions are permanent, especially as a new developer in your career. You’ll have flexibility in terms of geography, type of company, type of job, size of company, business domain. Some shifts may be easier because of your history and the aforementioned effects (shifting from being a web developer to being a backend engineer), some may be harder (changing from a web developer into an embedded systems engineer), some may be well nigh impossible (changing from a web developer into a compiler developer), but some change will be available to you.

What this means to me is that decisions which seem crucial, critical, life-changing, are, but that if you make an incorrect decision you can change. And that, for me, takes some of the pressure off.

Sincerely,

Dan

PS, as Kendall pointed out, there are some decisions that are essentially permanent. But most career decisions aren’t.

The perfect is the enemy of the good (and the done)

Dear new developer,

When you are facing a problem, it can be very tempting to try to solve it perfectly. Handle all the possible edge cases, make it extensible, have it be configurable without code changes.

As with everything in life, there’s an opportunity cost to this perfection. If you’re spending days perfecting a single page of a webapp, for example, you won’t be able to move on to the next feature.

There are times for perfectionism, without a doubt. When data could be lost or security could be compromised, you want to move slowly and carefully.

For the rest of the time, good and done is better than perfect and undone.

Of course, the definition of ‘good’ is the crux of the above statement. Unfortunately, this is a judgement call, depending on context, team and risk. One thing that is non-negotiable is that the code meets the requirements. If it doesn’t work, then nothing else matters.

Some things to think about when you are considering what ‘good’ is:

  • How often will this be used? Once a second? Once a year? Once?
    • The more often code is used, the more it should be polished.
    • Note that usage often changes over time, so it’s worth keeping an eye on this and spend some time cleaning up code if it moves from the once a year category to the once a week category.
  • Is this a relatively static part of the system, or is it in flux?
    • If you’re touching this once and don’t expect to touch it again for a while, taking some extra time makes sense. Niggling bugs may live for years.
    • On the other hand, if this area of the codebase is churning, polish could be wasted because the code may be trashed.
  • What are the risk factors if this fails? Will someone be killed? Will money be lost? Will someone be inconvenienced?
    • Obviously, the higher the risk, the more care you should take.
  • What is the next thing on the list?
    • If you have other high priority issues, you may want to avoid polish.
  • What is the team quality ethic?
    • You should meet and improve that standard. For example, in the context of testing: if no one writes tests, set things up to write tests. If everyone writes unit tests, think about integration tests. If everyone writes integration tests, think about performance regression tests.
    • This is a great topic of conversation at an interview or team meeting so that everyone can be on the same page.
  • How permanent is this code?
    • The more permanent the code, the more care should be taken.
    • Some code lives on servers and is easy to change. Other code is shipped to mobile apps and is harder to change. Yet more is distributed to IoT devices and really hard to modify (when is the last time you updated your router’s firmware? I thought so.). Some is burned to read only memory and can’t be changed short of great expense.

One question that I’d avoid asking is “how will I feel about this code in 12 months”. Because I know the answer–you’ll cringe. At least, in all my discussions of running code, I’ve never met someone who revisited old code and didn’t find at least one thing to improve.

Two examples, rating the above factors on a scale of 1-5 (where 1 indicates you should just get it done, and 5 indicates you should get as close to perfection as possible).

  • Your website portfolio:
    • Usage: 3. Used maybe once a year or two (if you are an employee) or maybe every month (if a contractor), when someone is checking you out.
    • Static or churning: 4-5. relatively static. You probably build out an example app once.
    • Risk factor: 3. You’re looking for a job, and your portfolio is a powerful signal, but not the only one.
    • Next thing on the list: ?
    • Team ethic: N/A
    • Permanence: 1. This is a website, so you can ship new code whenever you have time.
  • Billing software on your large public site:
    • Usage: 5. Used many times a day.
    • Static or churning?: 4-5. Should be relatively static as payment processing doesn’t change that often.
    • Risk factor: 4-5. Billing mistakes are expensive.
    • Next thing on the list: ? Depends on the company.
    • Team ethic: ?
    • Permanence: 2. You have the code on the server, but you have a lot of history and state to maintain.

When you are working on code and struggling to get to ‘done’, I encourage you to consider the above questions to guide your decision. Finally, don’t forget that (most) code can be revisited. If something is good and done now, ship it. You can typically improve it next week or next year if the code needs it.

Sincerely,

Dan

Learn to look around corners

Dear new developer,

Sometimes you want to play out things two and three steps deep. Kinda like chess players, who think about many moves ahead, if you can consider the ramifications of your decisions, you’ll be well served.

I remember talking to someone about a software position at his company and he referred to the “original sin” of choosing a particular NoSQL database. This had ripple effects throughout the life of the company. Some were good, some were bad.

These kind of downstream effects are worth thinking about. The biggest ones are things like fundamental platform choices (Rails or Django, Java or golang, mysql or postgresql). But even smaller things can have ripple effects. I can’t count the times when I’ve said “I’ll just upgrade this one thing” and then the change just keeps cascading out.

Or if you are working on a feature definition, think through the ramifications. “We want to allow people to change their email address.” But if email address is the primary key of a table, or a primary means of connecting data across accounts, or some other invariant, what will the ripples in your system be.

And these are just the functional repercussions. There are also performance repercussions to changes, some of which are hard to test unless you are in production.

I’m not saying don’t accept changes. That way lies madness (and Fortran). Just be aware of how changes in complicated systems like web applications have a way of rippling out beyond their intended scope, and consider how to test, mitigate or handle such ripples.

Sincerely,

Dan

What if I have to make a technical decision and I don’t know the right answer?

Dear new developer,

Sometimes you are confronted with decisions for which you simply don’t know the correct answer. This has happened to me many times over the years. A recent example is that the client wanted to build an online quiz. They wanted to be able to edit quiz questions and answers. They wanted it to feel like an application (rather than a website). I had never built something like this before, but I was the person best situated to make the architectural decision which would underpin this application.

You may not have time or money to do all the research you feel you need. You may be doing something that has simply never been done before. You may be in an arena where you are being pressed for a decision (like a meeting).

If you are in a situation where you have to make a choice about a fundamental architectural decision (like a platform/library/framework), you probably are in a small team moving fast, or at a company where you are one of a very few number of technical folks. In this case you may feel over your head and incapable of making the correct decision.

And yet, the decision still needs to be made, and you are the one who has to do it. (The unfortunate fact is that the too late perfect decision is worse than the pretty good timely decision.)

Techniques that won’t work out well for large important decisions:

  • avoiding making the decision
  • googling for an answer and take the first option provided
  • deferring to someone else
  • doing a thorough full examination of all the possible solutions, draw up an excel spreadsheet and a powerpoint to make sure you haven’t missed anything
  • avoiding discussion among team members

Here’s how to proceed.

First make sure that you do need to make the decision, and that you have the proper business context. The number of choices that you should consider and amount of research you should do depend on the impact of the decision. Things to think about:

  • how much of the business does this touch? If it is contained or constrained, you can spend less time thinking about this. If you are implementing a small micro service, or if you are choosing a service that is only used by a portion of the organization (like github for your code), then a choice that needs to be unwound will be easier to do. If you are picking the development language that will be used for the core product, rewrites are almost guaranteed to be far in the future.
  • how irreversible is the decision? Most decisions aren’t irreversible given enough time and money, but some are easier than others. Swapping out one memecached provider for another is pretty trivial, but changing from mysql to postgresql is more complex. Changing from GCP to AWS can, depending on the amount of data you have, be person-years.
  • does your company have internal solutions that you might be able to leverage? The bigger the company, the more likely the problem has been solved before, and finding that solution will be quicker and better than rebuilding it.
  • can you defer the decision until later? Is there a manual process or a service you can buy that will avoid a technology investment, even for a few months?

If you can’t defer the decision, then make the best one you can with the information you have. Research based on the impact on the business. I want to acknowledge the uncomfortable tension between knowledge and action that are at the root of any decision made with incomplete knowledge (aka, all of them!). There’s a spectrum based on risk and commitment, and unfortunately, I’m not aware of any great heuristics for determining risk or commitment other than experience and reading.

My approach towards such a decision is:

  • learn what you can. This includes finding out as much as you can about the problem, including current solutions
  • bounce ideas off of others in the company, but make them specific (both in form and in who you ask). This will help avoid analysis paralysis
  • ask for recommendations. Start at your current company. Even if you can’t find someone who has direct experience with the problem, there may be people who have related experience. You can also google to see what other folks have said about the various solutions (make sure to limit the results to “the past year” or you’ll end up reading about old versions). It can also include searching for experts on twitter and linkedin to ask questions (or to look at their blogs/sites to see if they’ve answered it already). And finally, don’t forget to look for communities (slack, old fashioned forums, open source project email lists) and see what they say. It’s far better to read what you can rather than pop into these communities and ask–those kinds of requests can happen often enough to annoy folks. But if you don’t see any answers, do ask.
  • realize that no decision is perfect. In 20 years of development, I can tell you that I’ve never made a perfect decision, they all involved tradeoffs and lack of perfect knowledge.
  • communicate the risks with the business. This includes the risks of you feeling like you are over your head, as well as any other risks that your research has found.
  • come up with a recommendation and implement it.

Again, hopefully you won’t be confronted with a far reaching architectural decision for a number of years, but it happens. Hopefully this framework gives you a bit of guidance toward making that decision.

Oh, and if you wanted to know my quiz conundrum ended, some of the choices I made were implemented, and others got swapped out as the team changed. The app was a success.

Sincerely,

Dan