But First, Don’t Do the Dishes

This is a guest post from Sonja Parsell. Enjoy.

Dear Developer,

Don’t misinterpret a small distraction, or even a big disaster, as a “sign” that coding isn’t for you.

There were definitely times in my journey when a break in learning was completely justified, but by no means should I have seen it as a reason to quit, or that I was missing the message that I didn’t have what it takes to be a developer.

Thanks to a lot of personal reflection, some low-tech research about my habits, behaviors and values, and not a small amount of tough love, I am happy with my progress now, even though it’s taken years to get here.

Maybe you’re struggling with something similar?

Don’t sweat DO the small stuff.

No outside factor is going to make you more productive, and if you need a certain atmosphere to be at your best, you’re not truly in control of yourself.

Rachel Hollis

I used to feel like the house had to be tidy before my mind was clear to sit down to learn/code. If I couldn’t get those tasks done, how would I ever have time to hold down a software engineering job?

My habit of clearing up the breakfast dishes, tidying up after the whirlwind of getting kids off to school, and letting the “silent do-do list” (totally worth a Google) shout at me was definitely keeping me from maximizing the best time I had to learn to code. I knew if I didn’t squeeze some coding practice in by 10:00 AM, it was likely not going to happen that day. 

Those chores were a waste of my best hours. I learned to walk away from the mess in the kitchen (it was hard at first) and I now spend my most productive hours on my most important goal: becoming a software engineer.

Because really, there will always be dishes and laundry. I really didn’t mean to give them priority. 

Never enough time.

You can’t see the silver lining through victim goggles.

Jen Sincero

I used to think I would never have enough time to learn enough to get hired. Who was going to employ me as a career-changer over 40?

Running is my go-to form of exercise because it’s one of the only things in life I get “enough” of in a short amount of time. At some point, I am tired and I have to stop. That feeling rarely comes when I’m writing code.

As a SAHP (stay at home parent) for the last eight years, my time hardly feels like it’s my own. But everyone has the same 24 hours in a day, right? How could I feel so unproductive?

To solve this, I started with a basic Excel spreadsheet by listing all the things I wanted to do, or were my responsibility (household tasks, volunteering, hobbies, learning objectives, social commitments, family obligations, after school activities, etc.). It seemed endless. No wonder I wasn’t actually doing any of it consistently or well!

After keeping track for a few weeks of what I actually participated in each day, the results were eye-opening. I now had a map of how I spent my time and, most importantly, where I could save it.

The four biggest changes I made to my days were:

  1. Saying “No.” or “Not now, maybe later.” to anything that would interfere with my best coding hours: socializing, volunteering and doctors appointments were strictly scheduled for late afternoons or weekends only.
  2. Waking up at 5:00 AM to have a few quiet hours to myself. This was transformative in how I felt about my progress (by the time I ate breakfast, I had already coded for two hours!) and how the day progressed. 
  3. Giving up a few things. I put a few hobbies on hold, graciously backed out of friendships and groups that didn’t make me happy, and even taught my kids to make their own breakfast and pack their own lunch.
  4. Finding what to learn, when. I lined up coding podcasts for meal prep time. I caught up on all my Slack groups while waiting for the kettle to boil. I quit social media for periods at a time (apart from Twitter – all tech related for me). This helped to keep me focused but not burned out from just sitting at a screen, trying to learn in a silo.

Because really, you have more time than you think you do. You can’t do everything, but you can do anything you set your mind to. Spend your time wisely.

“You want to make websites??”

The first stage of forming an ambition requires imagining yourself in a role that requires skill and that exists outside of the domestic sphere.

Anna Fels, “Necessary Dreams – Ambition in Women’s Changing Lives

I used to think my family and friends didn’t understand what I was trying to do or even why. So why on earth did I think it was a good idea? I must be crazy.

My friends said things like “You want to do WHAT? You’re training at a bootcamp for a nuclear what?”. (True story.) And there were giggles, looks of confusion, and eventually, they would change the subject, still in the dark about my goal.

My wonderful spouse thought it was an interesting hobby, but wasn’t excited to make space for it if my studying schedule interfered with the division of household tasks.

Through an amazing “Moms in Tech” slack group, I found hundreds of women trying to do what I am. We were all struggling with the same imposter syndrome, were misunderstood by loved ones (at some point in our journeys), and were filled with self-doubt. I decided to enroll in my coding bootcamp on the heels of a meaningful discussion with these women over Slack. I’ll be eternally grateful for their input, and I’m determined to pay back the favor someday to anyone who needs a sounding board.

Because really, your family and friends may never understand what you are trying to do. That’s why the coding community is so critical to your success. Just jump in and find your people. I promise they are looking for someone just like you.

Make progress every day.

It’s not complicated, it’s just unfamiliar.

fellow software engineering bootcamp student to whom I am eternally grateful and wish I knew your name

I used to feel like a failure for not achieving the coding goals I made each day, even if they were SMART goals. If I can’t figure this out, how am I going to move on?

You might want to finish a small feature but when you’re a newbie coder, nothing is linear. First, you need to know what 1a, 1b, and 1c mean, with the right syntax, and know what the errors are telling you, before you can even get to B. That’s NORMAL and it can take a lot of time.

What helped:

  1. Keeping a journal of what I worked on every day. It helps to see your progress in words. And it reminds you of what you learned. Recall is an important part of learning. 
  2. Realizing I had too many things going at once. As a newbie, you feel the pressure – excitement even – to learn all the things at the same time. It’s truly a discipline (and worthy of practicing) to be able to focus on one language, complete one tutorial, or to build one thing at a time.
  3. Repeating a course or an exercise doesn’t mean you’re not learning the concept or syntax. I know I need to see it, read it, watch it and then write it – at least 3x – before it feels familiar.

Because really, you’re still successful if you make consistent progress, not specific goals.

Driving with the brakes on.

Be strict about your goal, but flexible in how you get there.

Rachel Hollis, Girl Stop Apologizing

I used to think that when I had to take weeks or even months off from coding to take care of myself or my family, it was the ultimate sign I should quit. What else could it possibly mean?

I’ve been learning through babies and children under foot, a trans-Atlantic move, a brain hemorrhage, recovering from a brain hemorrhage and vision impairment, and, just two weeks after I spent some serious money by enrolling in a bootcamp, the pandemic hit. All the time I had reserved to finish the program, became dedicated to more housekeeping and homeschooling than ever seemed possible.

But six months into 2020, I was still totally committed to, and absolutely in love with my studies and — guess what – I was finally convinced that this is what I should be doing.

Yes, it took a pandemic.

Because really, changing your life is SO HARD. You just have to work harder. And you can, you just might be lining up at the start more times than you originally thought.

If I belong here, you belong here.

Regret is the thing we should fear the most. Failure is an answer. Rejection is an answer. Regret is an eternal question you will never have the answer to.

Trevor Noah, Trevor Noah: Born a Crime

We are our own worst enemies and often close doors that aren’t ours to close. Only you know exactly why you started this coding journey, and that’s all that matters. Don’t let anything or anyone stop you. 

Especially those dishes.

— Sonja

Sonja Parsell is nearly finished with her software engineering bootcamp. After 15 years on Wall Street working in various finance and operational roles, she’s beyond excited to pursue an engineering career in blockchain. You can read more about her story.

Be kind

Dear new developer,

Kindness is an unsung virtue for software development. I touched on it in this post on empathy, but wanted to emphasize it again.

Practice kindness. When I was young, I thought scoring points and being right were important. They are, but being kind and a good human is even more important.

Be kind to your teammates

They are working with you to try to solve problems. They bring different experiences and perspectives. Value those. Assume positive intent. Yes, there may be the occasional toxic person, but in my career the vast majority of my co-workers wanted to do good work and help our customers.

Be kind to them by listening to them, trying to understand and incorporate their perspectives, and honoring your commitments to them.

Be kind to your users

Making software is an excellent career for many reasons. One of the best parts of my career has been building tools that help others do their jobs or live their lives more easily. To do so requires understanding of their problems, empathy for their constraints, and a vision for how to improve both.

Be kind to them by listening to them, especially when they talk about their problems. Understand that what you do is magic.

(Think of a highly focused discipline that you aren’t familiar with. I’m not a car person, and I still think that the fact that you can turn a car and have the tires go different distances without impacting the overall vehicle speed is pretty magical. This is similar to what users think about developers.)

Use your powers for good.

Be kind to your friends and family

As much fun as coding is, don’t disappear into it entirely. Spend time with friends and family. Forge those bonds.

I promise you in five years you won’t remember the precise problem you were solving today, but the friendship and family bonds you foster will sustain you.

Be kind to them by spending time with them.

Oh, and when you do, don’t talk shop. That gets pretty boring pretty quick.

Be kind to yourself

I read another tweet about a developer being burnt out and quitting the industry recently. It made me sad, because I think I could write software until my 80s. Not full time, but man can it be fun. It can also be horrendous. The environment matters, but so does setting and enforcing boundaries. Make sure you do so.

Be kind to yourself by taking regular vacations, setting and clearly communicating boundaries, and celebrating your wins at least as much, if not more, than your failures.

If you wouldn’t say something to a close friend in the same situation, don’t say it to yourself.

In conclusion, be kind.

Sincerely,

Dan

Always be replacing yourself

Dear new developer,

I had a friend who brought me into a club. The specifics of the club don’t matter, but like most clubs, it had a variety of executive roles. Someone had to run the meeting, other people had to take notes, someone needed to keep track of the finances.

As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. You don’t want anything to be your particular special area of knowledge. You should always be trying to train your replacement.

I think this is good advice for a software developer as well. At any new job, you are learning tons of new things. This is doubly true when it is your first or second job.

But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the eng team is relatively stable) or new hires (if you are on a rocket ship), in a year or so you won’t be the new kid on the block.

Obviously this is a discussion to have with your manager, but you should always be looking at ways to replace yourself. This will free you up to work on new tasks and learn new things.

Here are some ways to replace yourself.

Document all the things

Don’t rely on your memory. When you are performing a task for the second or third time, write down what you are doing and why. (If you only do a task once, this is not usually worthwhile.) Keep this under version control and share it widely. That way anyone can see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.

Offer to cross train

When you are working with someone else, you both gain knowledge. Whether this is a command line trick a different view of the world, or specific domain knowledge, working with someone on a task will help you both. This doesn’t need to be full pairing, it could be an impromptu design session or troubleshooting discussion.

Automate for the people

If you are doing a task and have time time, write a script or program to do all or part of this. Don’t let the perfect be the enemy of the done. If you can write a script to do 70% of the work in 10% of the time it would take to automate the entire task, write that script. This pairs well with documentation and is a living form of knowledge transfer.

Obliterate the task

Sometimes a task is always done because it has always been done. With your beginner’s eyes, you can ask “why”. Don’t be crotchety, but try to get to the root of the problem to be solved, rather than focusing on learning the solution. There may be other ways to resolve the issue. There may not. But by understanding the root of the solution, you’ll be better able to see if you can avoid doing it altogether. This isn’t strictly training your replacement, but it will be welcome and does make the organization more efficient.

Don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.

Sincerely,

Dan

Think about your career risk budget

Dear new developer,

In certain areas of software operations, the concept of an error budget makes an appearance. An error budget is a way of tracking how often errors occur. When the budget is exceeded, you spend time and energy to decrease them.

Having a number like this is a good way to align different areas of the business with the reality that at a certain scale and complexity, issues will arise. When this happens, the question is always, should you spend time fixing the issue or working on new functionality? The error budget helps make the answer clearer. (There’s a lot more to this concept and the link above is worth digging into.)

In the same way, you have a career risk budget. You will work for approximately 40 years, give or take a decade. Each job and career move you make is important, because if you move jobs every three years (on average) you get only 14 different opportunities. These are complex decisions; how can you choose which job at any given time is the right fit? Here are three things I consider:

Goals

This is a very common one. Is this new job moving me toward my goals? Goals can differ for each person, but here are common questions I ask:

  • Is it the tech stack I want? (The older I get, the less this matters to me, but it still matters.)
  • Am I working in an interesting domain?
  • Is this the size of company I want?
  • Will I have opportunities to grow?
  • Will things like work life balance expectations and culture be in line with what I think I want or have enjoyed in the past?

These are all trying to get at an answer to the question: Can I see myself at this company for a while?

It’s always worth writing down your goals and seeing if the company can help you meet them. But it’s also tough to be really clear on goals a few years out sometimes. After all, if you’d asked me in 2016 if I wanted to work in DevRel, I’d have said “maybe??”. Another filter for considering a career move is comp.

Money

I love writing software. I do it for fun sometimes. But the fundamental employer employee relationship is through compensation. I give an employer my time, knowledge, experience and energy. They give me money.

So there’s nothing wrong with picking a job based on money. In fact, from my experience and the experience of others I’ve talked to and read about, switching jobs appears to be the best way to get solid salary raises, especially in the current market. Some of the numbers I’ve seen are eye popping, including double digit increases. You won’t get that at the same company, typically. (However, I did get some double digit raises early in my career, from 42k->55k at one company, so it isn’t out of the question.)

Make sure chasing a higher salary aligns with your career goals too. Funnily enough, jobs in software which are unpleasant, career limiting or otherwise less desirable often pay more (the free market at work). So when you see that junior engineer position using MUMPS which pays 10k more than other positions you’ve seen, find out why.

Money is important, but not the only thing to chase. There are risks to any job and it’s worth thinking about them.

Risk budget

Another approach to fold in is your risk budget. There are all kinds of risks, but you want to look at financial, emotional and career risks.

  • Is the company going to be able to pay you? Do they have a viable business model? Do you feel like buying a lottery ticket (equity) with your time?
  • How are you going to feel working at this company? A valued part of the team, or an expense to be managed (or, worse, minimized)?
  • Is this position, in terms of responsibility, technology, and growth opportunities, going to help or hinder your career?

You can’t, of course, quantify all of these precisely, but you can assign relative numbers to them. This can be helpful when comparing opportunities, either side by side or over time.

Risk budgets change as you age, as well. For example, your financial risk budget may decrease as you have more obligations. On the other hand, it may increase if you build up savings or have a cushion.

As I get older, the team I am a part of has become more important and the precise technology less important. But that’s me. You need to take some time and think about what matters to you.

Sometimes you have to take a job to have a job. I get that and have been in that position. But if you have the luxury to have some patience, consider the above three factors and don’t forget your risk budget.

Sincerely,

Dan

Take jobs that help you grow

This is a guest post from Adam Steel. Enjoy.

Dear New Developer,

Getting your first developer job can feel like a big accomplishment. And it is! It can feel so big and you can feel so relieved to have any job at all that you might start to develop your worldview around that one job. “This is how things are in the real world” you might tell yourself. “I’m lucky to be here,” you murmur. “Leaving too soon looks bad on your resume,” says an older friend.

This sort of thinking can be entrapping. I’m writing to show you a better way.

The spectrum of jobs and companies in tech is broad. To understand how the world is and what your options are you have to take a couple samples and grow, grow, grow! To that end, there are three “traps” I see developers get stuck in early in their career.

The first trap: Spending too long at your first job

In your first 3-4 years, it’s critical that you fuel your motivation and inspiration into learning and growing. It’s also a critical time for a steep increase in your salary. Too many companies fail to recognize that a junior developer’s abilities are growing far faster than their compensation and responsibilities. Or it’s recognized but the company cannot afford to promote or give a raise. It’s up to you to take the reins and move to a new job to find the new challenges and new salary that match where you are in your career. This is especially true for self taught and boot camp taught developers.

How long is too long? How long is enough?

“Enough” time as a junior can be surprisingly short, depending on how you learn. At 6 months it is reasonable to consider switching jobs if you are learning quickly. Not for all positions you’ll hold, but specifically for this first one. Juniors are paid less because they need to come up to speed on all the terminology, tooling and processes.

Once you don’t need hand holding to tackle moderately complex features, you will be far more attractive to other companies. Occasionally a company may recognize and reward your growth, but that is rare.

Stay longer only if you’re feeling significantly rewarded and challenged. Which brings me to…

The second trap: Not investing in learning

Building business software in teams requires a set of skills that are hard to acquire in the absence of customers and a team working to support them. This learning curve can only be tackled when you have these components. And the best way to move along the learning curve is to take a job that helps you learn faster!

What does a “learning” job look like?

“Learning” jobs tend to have similar characteristics. There are resources to learn from and the autonomy to work however suits you best. There is time built into the team’s cadence to allow for research, either organic time throughout your week or time specifically set aside.

Most importantly, there are lots of smart people who give you feedback and engage in discussions about the best way to do things. These people will focus on things like best practices, optimization and customer value. Often they argue! While the arguments might excite you or wear you down, they should feel overall productive and, at the end of the day, move the team toward its goals.

Think of a learning job like an additional career investment, beyond whatever you’ve already paid to learn before your first job. What you need is exposure to good ideas in the context of solving a business problem with an experienced team, and a good learning job gives you that. You may take a lower salary in the short term, but by expanding your knowledge your career will be more fulfilling long term.

What should I avoid?

The list of positions where learning is difficult is much longer than the list of “learning jobs”, but here are some examples:

  • Isolation: Working alone is the hardest career decision to come back from, but it’s especially destructive in your first job. If you aren’t challenged by the ideas of multiple people, your world becomes small. You also won’t have a chance to build your network.
  • Micromanagement: Good companies work to give their developers autonomy and space to do the right thing. If someone is managing the details of your daily life, you aren’t learning how to flex that autonomy muscle. For example, once I had a job where a senior manager stood over my shoulder and dictated what he wanted to see as I wrote code.
  • Lack of visibility: Do you get a chance to learn how the pieces fit together? Do you get a chance to fit them together? A narrow field of view restricts your ability to build a larger context. For example, are you only ever asked to fix specific bugs, or are you encouraged to think about the larger architecture while building new features?
  • Unsafe environment: If we don’t feel safe, we cannot learn well. Depending on the threat, there could also be much bigger concerns. Examples include, but are not limited to, yelling or harassment of any kind. Leave as quickly as you safely can.

The third trap: “Being glue”

“Being glue” is when your role is focused on filling gaps like coordinating between teams and keeping everyone organized, as opposed to actually writing software. Especially in smaller, more dysfunctional teams it can be a tempting role to fill. The team needs it, after all! It’s an important role for managers and higher level engineers to fill, but if you step into it too early it will stunt your learning curve and can leave you forever feeling like you are “behind” the rest of the team. It’s first (and best) described in this noidea blog post.

Once you are technically competent, and everyone knows it, consider taking on this work.

Finding a job that maximizes your growth

There’s no silver bullet for this problem. My best advice is to try to develop the ability to “sniff out” the kinds of companies you’re looking for. Did someone impressive speak at a meetup or write an inspiring blog post? Track down where they work. Job descriptions that are well written and articulate good values are promising. And if you end up in a job that you misjudged and find yourself stagnating, don’t feel guilty about quickly moving on.

Consultancies with great practices, like TestDouble, can be great accelerators for your learning. Changing projects more frequently results in a broader experience, but at the predictable cost of less experience with how your decisions in a codebase will age.

What does a “good” job description look like?

Writing a good job description is hard, but the best companies will put in the effort to do it right. Some attributes of good job descriptions include:

  • Reasonably correct English and readable formatting
  • A description of philosophies and values that align with yours
  • Reasonable requirements (e.g. no CS degree required for a junior level frontend position)
  • Specifically calls out personal traits like kindness or empathy as desirable

What can I ask in interviews to vet the position?

Remember that interviews are your chance to interview them as well. Examples of questions you could ask include:

  • What best practices do you think have made your team successful?
  • What kind of developers thrive at your company?
  • How do you support developers when they come onto a team?

How frequently can I change jobs?

This is a hot topic, but varies by which part of the industry you’re in. Early on, hopping jobs more quickly is fine. 3 jobs in your first 3 years? Not uncommon. Working in startups especially can lead to shorter tenure as companies fail or are acquired.

However, there are skills and wisdom you will only be able to build by staying longer. For example, no amount of training or reading will result in the wisdom you gain by wrestling with a technology decision you made over a year ago as you watch it cause painful issues.

The resume to avoid building is the one with only <2 year tenures over a 10 or 20 year career.

Happy growing!

Adam

Adam Steel is the VP of Engineering at TrueCoach. He lives outside Boulder, CO.

Take a tour with a different department

Dear new developer,

If you are totally thrilled with your job right now, stop reading. This letter isn’t for you.

Okay. So you may be unhappy with some aspect of your current job. I have some advice for you.

Take a tour with a different department at your current employer.

This won’t work for everyone. If you work in a company with only three devs in the department, there probably isn’t a lot of scope for switching things up. But if you work in a company with 20 or more developers, there probably are focused teams. And if you work for a company with 100s of developers, there are all kinds of specialized teams.

I worked at a consultancy with a couple of hundred people years ago. They had a dedicated database development group. I was not even unhappy with my software position, but I was really curious about the database folks. I talked to my boss and we arranged a tour of a couple of months where I worked exclusively with the database department.

I gained a deeper understanding of relational databases. The database group got a trusted helper who was happy to do whatever grunt tasks they handed me. My boss was able to let an employee explore something new and gain new skills, while being assured I would return in a reasonable period of time.

If this interests you at all, discuss the possibility with your manager at your one to one. Also, reach out to the team that seems interesting and learn more about their work. Just ask what they do day to day and you’d be surprised what they’ll tell you; people love to talk about themselves.

Now, some managers won’t want to let you go, even temporarily. I’ve been lucky enough to never have that happen, but if it does, well, that’s a good piece of data to know.

Doing a tour with a different department is a great way for you to spread your wings and try something new in a relatively safe environment. You’ll be a known, trusted quantity and there’ll be far less risk than if you were to take a leap to a different company and a different role.

Sincerely,

Dan

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.

If you’re trapped in your job, what should you do?

Dear new developer,

Perhaps you took the first job offered to you. Perhaps you joined a friend’s company, then realized it wasn’t quite what you were promised. Perhaps you joined a company as the only developer and didn’t realize you should avoid working alone.

You might feel trapped by the money, trapped because you believe you promised to stay for a year or two, or trapped by the position, without the ability to grow.

The most important thing to do is to prepare to leave. How can you do so? Here’s a three part plan.

Know what you want

First, write down what you want. You know more about what you don’t desire, but you need to have a clear path toward what you want. I’ll open up a google doc and write down all the things I’m disatisified with about the current situation I’m in. That may be people, it may be responsibilities, it may be salary, it may be situation, it may be the manager. This venting helps me get clarity.

Then, take some time thinking about what you’d change to be happier. This may require some research. You can do a lot of research by googling and reading, but you may also want to reach out to some members of your community to ask about their jobs. Hey, I said this was a three part plan, I didn’t say you wouldn’t have to do some work.

Think about your runway

Next, consider your financial situation. Do you have money saved up? Can you cut costs? Figure out your financial runway. If at all possible, save up three to six months of expenses, as that will make any transition time much much easier. The alternative may be borrowing from friends and family if possible, or the credit card companies if not.

I find that even just the exercise of looking at my expenses and income cause me to be more aware of my spending. You don’t have to wallow in it (though plenty of people swear by living on a budget); rather the goal is to set yourself up for success should leaving a job turn into a longer period of unemployment than you planned for.

Reach out and interview

Third, interview. Find companies who you are interested in based on the previous thought and research, and apply. Look on the company website, but don’t apply through it. The best way to apply is to hand your resume to someone already at that company. I find applicant tracking systems to be mainly good at weeding me (and others) out. Use LinkedIn to find people you know at the company. This also lets you ask them about the company culture and the job. Lots of companies, unfortunately, have job listing pages that may not reflect current needs.

If you don’t know anyone at the company, see if you can start. This includes following people on Twitter, watching speakers from the company, and connecting on LinkedIn. Please please, if you connect to someone on LinkedIn, write a quick note: “I was just watching your presentation on Kotlin and wanted to connect with more people in the community.”

Don’t be transactional about any of these interactions; you’re trying to learn more about the position and company, but you also want to provide value to the other person. How can you do so? I dunno, every situation is different, so ask.

I also use a spreadsheet to track all my applications, including contact info, links to the the job, and notes. I always have a ‘follow up date’ column where I can put in when I should reach back out again. It is hard when you are in the throes of the job search, but remember that usually finding and hiring candidates is just one part of the hiring manager’s job, and so you might slip between the cracks. Take control, send regular follow up emails, and you can avoid that fate.

If you do get an interview at a company you like, this should give you some great information. How prepared did you feel? How competent? Did you crush it or did you flub the interview? By the way, flubbing an interview is never fun, but when you already have a job is about the best time to do so.

What was the reaction of the interviewer and the company? You may not get as much information as you want (I never do) but you’ll get some feedback. I like to update that spreadsheet with whatever I learned: was there a question I didn’t answer as well as I could have? Was there a technology I need to brush up on? Do I never want to interact with that company again? All good data.

Consider your situation

Now that you’ve have prepared with your wants, your financial situation and gotten feedback from the hiring market, you can reconsider your situation. Does it seem better now? Or are you still feeling trapped. Sometimes popping your head up and looking around at other opportunities can actually make you happier where you are. Other times it reinforces your desire to move on.

If the former, go to your manager with a concrete set of changes you’d like. The amount of work to put into this depends on the scope of the changes. If you’d like more money, justify it with the value you are providing and how your salary compares to other like positions. If you want to spend more time on a different project or technology, make sure you understand how that would benefit the company, not just you.

Be flexible. If you want mentoring but there’s not money to hire a senior developer above you, ask if you can attend conferences or hire a senior developer on an hourly basis to bounce ideas off of. I had an acquaintance who regularly hired people on Upwork to consult with when he ran into thorny technical issues.

The point is to inform your boss, in a polite way, of any changes which would make you happier. Know that there might be no time or budget for some of them, but I guarantee that you’ll have a higher chance of making something happen if you present reasoning why both you and the company will benefit. Bosses don’t read minds.

If it is time to move on, keep interviewing and when you get an offer, leave professionally. Give two weeks notice (or whatever is typical in your country or spelled out in your employment agreement). Connect to co-workers on LinkedIn. And head off to your next adventure.

Sincerely,

Dan

How to make a move to a related occupation

Dear new developer,

I’ve written before about how being a developer sets you up for a lot of adjacent professions. Jobs like:

  • Engineering manager
  • Technical trainer
  • Startup CTO
  • Product manager
  • Developer advocate
  • Sales engineer

I have either direct personal experience or have watched a colleague or friend transition to those types of jobs. I’m sure there are many that I’m missing.

I had someone ask me about developer advocacy and how she could transition into it. I gave some off the cuff advice that I’d like to formalize in this post.

Moving to an entirely different career (“I want to be a rock climbing guide!”) is a bit different, but if you are transitioning to an adjacent profession, I think there are four parts.

Google

First off, find out more about the position: the responsibilities day to day, the types of problems you’ll face, what kinds of companies hire for the position, what kind of career growth is possible, the salary ranges, the challenges.

All this information will help you make an informed decision about whether a move is what you want to do. I’d spend a lot of time researching using Google because you can do that at your leisure.

If you decide from this research that you are interested in taking the next step, then you’ll want to talk to some people already doing the job.

Interview

Reach out to people who are or have done the job, whether internal to your current employer or on LinkedIn, and ask for their time. The research you’ve done previously should leave you with some questions. For example, for a developer relations position, you might ask the following questions:

  • How do I find companies looking to hire devrel folks?
  • How much experience do I really need?
  • What is the split of coding vs speaking vs writing?
  • Person X said Y about devrel, is that true in your experience?

If you do that, make sure you have a crystal clear agenda if you don’t know them personally, and that you communicate your focus. These folks are probably busy. Don’t start off the message saying you’d like to “pick their brain” for 30 minutes at coffee. Instead say:

I’ve been researching a career transition to developer relations and I notice you’ve been doing this for a few years. I’m especially interested in your experience at <startup> and would love 30 minutes of your time to ask some questions. If you’d prefer email, happy to do that as well.

If you are still interested in this change, the next step is to try it.

Give it a try

You should now have a good grasp of what kind of day to day work is needed for this adjacent profession. Now you want to try it in a low stakes way.

  • Want to be a trainer? Research and give a talk about a new technology in the area you want to train in.
  • If you are interested in product management, see if there are user interviews that need to be done for your current work. Can you sit in on one, or run it
  • Devrel interesting? Write some blog posts about a technology you’d like to promote.

From your previous research, you should be able to find an easy way to practice some of these skills. You could find an open source project looking for help, ask around internally, or start/continue a side project.

Doing this has two benefits:

  • You can learn even more about the profession.
  • When you want to make a transition, you can point to this work as an example that you have the skills to do so.

How long should you do this? Ah, another example of the secretary problem. I don’t know. But you should try it a few times, enough to give you a feel.

Finally, if you are still interested, take the plunge.

The plunge

You can transition internally or by getting a new job. If you do the former, the stakes are lower and you’ll come in with your existing reputation, which will presumably help you. However, it may be tough to do if the company doesn’t really have a need for the position. For example, I was interested in developer relations, but worked for a consulting company which didn’t have a developer facing product. It would have been difficult for that company to justify a developer relations position.

If you can, though, the internal transfer is a great way to go. While every internal political situation varies, if you think one is possible, I’d talk to the manager of the team to which you want to transition and to your own manager and see what they think. Is it possible? What is a good timeline? Should the transition be blended (two days in one position, three in the other) or have a firm cutoff? What would success look like?

In a smaller company, you may have more flexibility if you see a gap. One colleague stepped into product management successfully because she saw the company needed it and no one was doing it full time.

If you don’t see an internal option, interview with other companies. Be prepared with an explanation of why you want to make the transition and how they’ll benefit from hiring you. Your research and experimentation should provide you with plenty of anecdotes to share.

Finally, one nice aspect of software development is that if you take a year or three off in an adjacent field, you can come back. The change need not be permanent. You may need to brush up on some particular technologies, but in general I’ve found you can transition back fairly easily. And you’ll be a more valuable software developer if you know about product management, how to have a one to one, or marketing automation.

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