Make it open source

This is a guest post from Eddie Jaoude. Enjoy.

Dear New Developer,

I will be the first one to tell you that it is not essential to have a degree in computer science to become a developer. My own journey started with a degree in engineering and falling into code as a mix of a hobby and also by necessity in my first graduate job. I have seen so many others in the tech community follow different paths to becoming developers; such as primary school teachers and historians.

Whether you have always wanted to become a developer or whether this is a new start for you, the likelihood is that you will be looking for learning resources from blog posts, YouTube videos and online courses. There are so many resources available, many of which are free, which means that you can improve your abilities without having to leave your house – which in a Covid era is quite handy.

However I would say to you – do not fall into the trap of getting stuck in “tutorial hell”. Thirst for knowledge is a great thing – and a good developer will realise that at no point in their career will they know everything and you do need to keep learning.

This is a little like going to the gym: you’ve decided you want a six pack – your trainer has shown you where the three different ab machines are and how to use them, you have watched endless videos on the best time to train, how long for and what food you should be eating. But it won’t be until you do that first ab crunch – which lets face it, won’t be perfect, that you will embark on your journey to achieving that six pack.

So my advice to you is – pause the video tutorial and build something. Apply what you have been learning and let go of the idea that it will be perfect. What is perfect today can be improved by your experiences tomorrow, the day after, in a year’s time and so on.

My second piece of advice – which is perhaps the one I am most passionate about as it forms the whole ethos of how I work: make it open source. I don’t want to assume that you know what open source is. It took me a few years into my career to find out about it. I was using open source tools in my day job and thinking how great it was that there were so many valuable free available tools out there that anyone could use. I was also beginning to network more and everyone kept talking about open source, which got me interested in finding out more about this community which works publicly and transparently to resolve software problems. I didn’t want to just take, I wanted to give back.

As a new developer you might be worried that you are not yet at a stage where you can give back and contribute. There is a misconception that you only have something to teach when you have reached a level of seniority in your career. But everyone has a voice. Don’t think that just because you are at the start of your career that all you should be doing is asking questions and seeking help. You do not want to be a drain on the community; at first you will get the help you need, but soon community members will see you are just there to get a quick fix to your problem and then drop off the face of the earth until you hit another stumbling block.

Beginning to get involved is not always easy – it might feel like you are entering an old fashioned boardroom meeting full of senior colleagues and you are under immense pressure to say something…anything at all… which really just contributes to you feeling anxious and insecure about your abilities and in a worse case, can stop you from taking that step.

So start small. Github in my view is a fantastic (and essential) way to start your journey into open source. Firstly, find a good repository:

  • Go to the Issues section which lists your issues, clear the search box;
  • Add the search parameter for the label “good first issue” and consider including a language;
  • This will list all issues which will match this criteria and from there have a look at the repositories and see which ones seem interesting to you.
  • Check the closed Pull Requests that have not been merged: it is completely acceptable for a project maintainer not to accept pull requests – but were these rejected in a friendly and constructive manner?
  • When making a contribution, focus on adding value (don’t just suggest a change for the sake of it) and being respectful towards the project maintainer’s time;
  • Bonus tip: check the insights tab on the repository to see if the project is inclusive for things like code of conduct.

You might ask – “But why should I make my projects open source?” Why would you not?

Is it because you hope your project will become your revenue stream and you do not want to share this with others? Making their project open source certainly did not hinder Red Hat when it was sold for £34 billion.

Is it because you lack the confidence and do not want to feel exposed? How else will you learn if you do not put yourself out there?

By making your project open source you widen the number of people you can learn from massively, as well as making connections which might even help further your career. When recruiting for my team I no longer spend hours quizzing a candidate about the bullet points in their CV. I go to their Github account where I can see exactly what they can do and how they interact with others.

Making your project open source is probably one of the best calling cards you can have as it showcases what you are about, not only from a technical perspective but also how you will engage with others. Whether you are looking for your first role as a developer, have secured one with a small start up or have embarked on a graduate training programme with one of the large tech companies, you need to know that no project is limited to one person only. You will need to collaborate with UI/UX, testers, product owners …the list goes on.

You may come across really well in a face to face (or virtual!) interview – exuding confidence and a team spirit. You also might not. By having an open source project your prospective employer and colleagues will be able to see how well you do with receiving and giving feedback and how you act upon this. This is a skill which needs to be learnt and open source projects are the forum to do it.

You might have a job where you work your own, or perhaps you work in a team with quite similar views and levels of seniority – these things might not be conducive to receiving and giving feedback.

By making your project open source you are interacting with people from all over the World, with different levels of seniority and most importantly different perspectives. That, New Developer, can only be a positive for your technical and personal development.

— Eddie

Eddie Jaoude is an open source advocate and believes open source is for everyone. Check out his GitHub and YouTube.

Think first about what problem this is solving and for whom

This is a guest post from Kate Catlin. Enjoy.

Dear new developer, 

Welcome to tech! Wow, I remember those days– Confusing, exciting, challenging. Nothing is certain except that you are in for a wild ride. Hold tight! 

The advice I’m writing to share with you today is this:

Before you write any code, think first about what problem this is solving and for whom.

As a little background, I’ve spent my whole career in tech. I’ve had two stints writing code (once in Android and once in Ruby) and neither lasted long. The rest of my career was a journey through Community Management, Sales, Startup Foundership, and now Product Management. While I love code, I love understanding people’s problems and figuring out how to solve those as well. That side always sucked me back in. 

Even in my roles where I wasn’t a developer, I’ve always interacted with developers. Many of them were new to the industry, just like you. The ones who have since excelled in their careers were the one who embodied the advice I just shared.

And so, every time you pick up a new Jira ticket or sit down to complete a new requirement, I suggest that you ask yourself the following questions: 

  • Who does this solve a problem for? 
  • What is the problem they’re trying to solve? 
  • How does this ticket solve it? 

There are three reasons this is going to help you out. 

First, it will keep you motivated. 

I think software development is one of the closest real-life professions to having superpowers. 

Why? Because your job is to use skills that most don’t have or understand in order to solve someone’s problem. 

Some of the problems you’ll solve may be big– Maybe you’ll work on an app that facilitates financing for renewable energy and measurably reduces climate change emissions. Some problems may be small– Imagine someone quarantining alone who misses their grandkids and has tried not to cry all day. Perhaps they have a slightly-less-frustrating time ordering a gift to send someone because you fixed a bug in a website’s UI. 

The world is a tough place to exist sometimes, especially in a pandemic. As a software developer, you get to use your powers to help make life a little easier for people. Remember that! Focusing on the problem rather than other things (like the shiny tech) will help you do so. 

Second, because you can start to push back if you see an easier way to solve that problem. 

A few months ago, I prioritized a new feature for CircleCI that would allow software developers, our users, to import Environment Variables from one project to another. I wrote up a long list of acceptance criteria involving multiple screens and checkboxes. 

The junior developer who picked up the Jira ticket for that feature was someone who regularly practiced user empathy. He paused, thought about it, and then suggested a simplified approach.

The simpler version worked! We were able to ship the feature in half the time, and it still resulted in a measurable lift to organizations adding new projects. This was good for the user, good for the developer, and good for the company. 

This is just one example of many I can name where by embracing user empathy, our team has solved more people’s problems faster. And so can you! 

Third, because it’s how you advance in an organization. 

Product thinking is so important at CircleCI, it’s a skill we specifically review our developers for during our annual review cycle. A minimum-threshold rating is necessary for a promotion. 

This is obviously not true of every organization, but in no case will the mindset not serve you well. Leaders simply need to understand why we’re building what we’re building for our users. How else could they help us achieve the future we’re working together to bring about? 

I would love to hear how a user-empathy mindset works for you. 

Everyone’s path is different, and every organization values different skills. You can find me on twitter at @Kate_Catlin, and I’d love to hear from you! 

Sincerely, 

Kate Catlin

Kate Catlin is Senior Product Manager of Growth at CircleCI.

Why and how to improve your writing skills as a software developer

This is a guest post from Allie Cooper. Enjoy.

It’s one thing to be able to write good code, but professional written communication is something else entirely. The ability to efficiently and authentically communicate using written language is an often ironically underrated skill in software development.

This is something that new developers need to get over very quickly. “Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves,” explains engineer and career coach Minh Pham. “While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human.” In today’s increasingly digitized workplace, achieving these qualities means honing your professional written communication skills.

Writing is Essential to Software Development

Any veteran developer can tell you that non coding-related writing is part and parcel of the daily grind, which includes writing tons of bug reports, notes for yourself, documentation for co-workers, and other technical discussions over chat or e-mail. You might also be tasked with explaining technicalities in ways that can be easily understood by clients. And as Inc points out, all of this generates a permanent record of any and all significant ideas, incidents, and other facts pertinent to how you’ve handled the job. In software development, the way you write and communicate over work platforms defines a great majority of your work history.

While writing code defines your raw ability as a software developer, your written professional correspondence tells the story of your ability to work with others in an inherently collaborative and complex field. Today, the sudden digital migration brought on by the global health crisis has only made professional writing a more integral skill for thriving in the new and increasingly web-based workplace. This is as true for experienced developers as it is for those who are looking to pick up the skills necessary for the job, which brings us to our next point.

The Future of Coding Education is Written and Online

From basic coding courses to advanced degree programs, more and more future developers are learning essential skills through online means. And the pandemic has only increased their numbers. For instance, Code Platoon Coding Bootcamp online basic coding courses have allowed the U.S. Department of Veteran Affairs to continue offering software development skills training for veterans as well as their spouses. And for safety reasons, all classes have been moved online.

Meanwhile top universities have also made this switch to training software specialists online. Maryville University’s online masters in software development is an advanced degree program that’s 100% web-based as well, with the perspective of producing future software consultants, UX designers, web developers, and DevOps engineers. And while these programs do include video conferencing classes, the majority of the work is through written communication. As natives to online work, the developers trained in these online programs are already developing the writing skills necessary to thriving amid the current digital migration.

In short, the field of software development is only getting more competitive and web-based. And while there’s no shortage of genius code writers for companies to cherry-pick from online universities and coding courses, the combination of a great coder and a great online communicator remains rare.

Practice Makes Perfect

Whether you’re already coding for a living or still learning the skill, you already have plenty of opportunities to hone your professional writing skills. Strive to be succinct and straightforward with every chat message or e-mail before hitting send. Put yourself in other people’s shoes – think about how the message you wrote will affect you if you were the one to receive it. Remember that every unnecessary word only muddles already complex conversations about technical specifications. Grammar is important, but so is writing with the perspective of being as empathic and as concise as possible – which can also allow you to develop a writing style that won’t require grammatical gymnastics. Never play to your emotions and always write with a collaborative mindset. The better you can communicate with the written word, the more value you can bring to any software development effort.

Allie Cooper is a freelance tech writer who specializes in I.T. and software development. Her mission is to help software developers further their careers. In her free time she plays online chess and sails.

Understand the use case

This is a guest post from Christie Brandao. Enjoy.

Dear new developer,

It’s easy to get wrapped up in only focusing on the deeply technical aspects of your job, especially if many parts of the stack have technologies you haven’t worked with yet. As your career progresses over time, you will be improving the quality and readability of the code you write as well as your problem-solving skills. This takes deliberate practice, but you’re already used to this! At the beginning, it’s natural for all your energy to go towards getting up to speed with the codebase and learning how everything works together. My advice is to take some time to also understand the use case.

At the core of it, your job is to be building something that will provide a positive business impact through your development skills. Ignore the urge to dive right in and start coding and instead, take some time to learn the bigger picture. Focus your energy on gathering as much information as you can to start building your foundational knowledge of this area of the product. You can start small! When asked to build upon a feature, for example, don’t just take the ticket at face value. Ask questions (to yourself or others) about how the current feature is currently working. What are the difficulties people are having using this feature? How is this going to be an improvement to the current process? Once you have a good grasp on the ticket level, it’s time to learn about the bigger forces that impact larger business decisions. You never know, maybe your fresh perspective will offer valuable insight that no one else has brought to the table.

— Christie

Christie Brandao is based in Columbus, Ohio. She is a Full Stack Serverless Web Developer for Branch, a tech-forward insurance startup focused on giving instant prices for home and auto with just a couple questions.

Interviewing at a FAANG in the Midst of COVID

This is a guest post from an anonymous FAANG engineer. Enjoy.

Dear New Developer,

In 2020, one question lurks in all of our minds: What the hell is going on? And yet, for many of us, life not only goes on, it presents exciting new opportunities. Towards the end of 2019, after six years of working as a software developer, I felt it was time to leave my second job. The familiar faces were rapidly disappearing, and I just wasn’t finding the work fulfilling anymore. I entertained a couple calls from FAANG recruiters, but I wasn’t particularly excited about any of them. I assumed I was going to find The Perfect Startup™ at which to spend the next phase of my career. I was complacent. I had endless excuses for why this wasn’t a good time and why my job wasn’t so bad. I could spend another year there.

Little did I know that the “another year” in question was going to be the craziest year the world had ever seen.

For personal reasons, I did not interview at all for the first month and a half of 2020. I even scheduled a phone screen with a FAANG, but due to a family emergency I rescheduled it and then forgot about it until the night before. Oof. I pride myself on my algorithm skills, but three years without interviewing is enough to make anyone rusty. I didn’t fail the phone screen, but I didn’t pass it either – instead, I was asked to try again. That was a wake-up call, and it made me really want to succeed at the interviews that I had previously not cared about.

My first tip, for anyone interviewing in 2020 or any other year: Grind LeetCode. I cannot understate how important it is to build muscle memory for the coding portion of your interviews. You don’t want to spend fifteen minutes thinking about whether you should use a Queue or a List (as I did), you want to spend that time solving the actual problem. Anyway, after that experience, I practiced every night (and some days) and easily passed all of my phone screens.

Less than a week later, COVID struck and my office asked me to work from home until further notice. All good, this should just make it easier for me to spend time on interviews, right? I assumed it would just be a temporary exercise for the next two weeks. Little did I know, all the companies, FAANG and other, which I was interviewing at would soon close their doors as well. I started panicking – what was to come of my on-site interviews? Well, some of the smaller companies didn’t feel comfortably hiring remotely, so those processes were dead in the water. All the FAANG companies assured me that I would get the full on-site interview experience through the magic of videoconferencing. I was not happy about this at all. I’ve always prided myself on my ability to connect with other people, so I feared that this would be lost over video. I shouldn’t have worried. All my interviewers made an extra effort to connect with me due to the circumstances, and I actually felt more comfortable than I ever had for an in-person interview. Thus, my second tip: Relax. Yes, times are extremely weird right now, but they’re weird for everyone. Have fun and enjoy the process.

I went into the interview process with a pretty good idea of which FAANG I wanted to work at. Based on what I knew of the internal culture, the company’s impact on the world, and my expected daily happiness, I had already decided where I wanted to be. However, if I didn’t receive an offer from that one, I was more than happy to work for any of the others I was interviewing at. Thus, I treated them both as practice interviews and as high-stakes challenges. Ultimately, I aced all of the interviews, received offers from all the companies, and immediately accepted the one I had been thinking about. I could not have been more thrilled. I attribute my success to two things, preparation and routine. Preparation was already mentioned in my first tip – grind those practice problems. I did over 100 problems on LeetCode in the month leading up to my interviews, and I even wrote up solutions on that website as a way to practice my ability to explain to others.

As for routine, my final tip is this: Build a stable routine. This is something we software developers struggle with even in years that are not 2020. When the lockdown first started, I felt lost. I worked until midnight because there was no reason to stop. My diet and exercise slipped. However, once I turned that around, I felt the ability to compartmentalize and plan. I set a regular bedtime and waketime. I started cooking myself meals at regular times to replace the ones from the office. I ordered a pull-up bar for my doorframe so that I could exercise any time I passed through it during the day. Once my life and health were in order, it was easy for my brain to focus on the fun part: passing those interviews.

— Anonymous

Learn in public

This is a guest post from Shawn Wang aka swyx. Enjoy.

Dear new developer,

If there’s a golden rule to learning, it’s this one.

You already know that you will never be done learning. But most people “learn in private”, and lurk. They consume content without creating any themselves. Again, that’s fine, but we’re here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they’re not public.) Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning. Don’t judge your results by “claps” or retweets or stars or upvotes – just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.

Guess what? It’s not about reaching as many people as possible with your content. If you can do that, great, remember me when you’re famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that’s icing.

Oh you think you’re done? Don’t stop there. Enjoyed a coding video? Reach out to the speaker/instructor and thank them, and ask questions. Make PR’s to libraries you use. Make your own libraries no one will ever use. Clone stuff you like. Teach workshops. Go to conferences and summarize what you learned. Heck, go back to your own bootcamp to tell alumni what’s worked for you. There’s always one level deeper. But at every step of the way: Document what you did and the problems you solved.

The subheading under this rule would be: Try your best to be right, but don’t worry when you’re wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You’re pushing yourself. Don’t assume you know everything, but try your best anyway, and let the internet correct you when you are inevitably wrong. Wear your noobyness on your sleeve.

People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. Of course, if they get abusive block them.

Did I mention that teaching is the best way to learn? Talk while you code. It can be stressful and I haven’t done it all that much but my best technical interviews have been where I ended up talking like I teach instead of desperately trying to prove myself. We’re animals, we’re attracted to confidence and can smell desperation.

At some point you’ll get some support behind you. People notice genuine learners. They’ll want to help you. Don’t tell them, but they just became your mentors. This is very important: Pick up what they put down. Think of them as offering up quests for you to complete. When they say “Anyone willing to help with ______ ______?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.

“With so many junior devs out there, why will they help me?”, you ask.

Because you learn in public. By teaching you they teach many. You amplify them. You have one thing they don’t: a beginner’s mind. You see how this works?

At some point people will start asking you for help because of all the stuff you put out. 80% of developers are “dark”, they don’t write or speak or participate in public tech discourse. But you do. You must be an expert, right? Don’t tell them you aren’t. Answer best as you can, and when you’re stuck or wrong pass it up to your mentors.

Eventually you run out of mentors, and just solve things on your own. You’re still putting out content though. You see how this works?

Learn in public.

— swyx

p.s. Eventually, they’ll want to pay you for your help too. A lot more than you think.

This post was originally published here.

swyx is a Senior Developer Advocate at AWS and author of The Coding Career Handbook.

Create Value for People

This is a guest post from Minh Pham. Enjoy.

Dear new developer,

I want to start off by saying Congrats and Good job. If you’re reading this, it’s likely you know how to code – and even if you’re still working on getting that first job, that means you have one of the most desirable skill sets in the world today. I congratulate you because getting here took work. You weren’t born with this knowledge, and even if you felt like it came naturally, it was still a journey of discovery, learning, and practice that got you where you are today.

As you look towards your first job – I want to offer you a single piece of advice that may act as your career’s guiding north star:

Create Value for People.

When you have the power to create anything, you begin to realize the importance isn’t on the code you’re writing but rather why you’re writing it in the first place. What value are you creating through your skill? This is why companies hire people like yourself. They are seeking out individuals who can ultimately deliver value to their customers, particularly through software. As you mature, you will realize that much of engineering has little to do with how fancy your solution is, and instead has everything to do with what problem it solves for the user. Once you accept this, you’ll begin to see that discussions of tech choice and code structure rarely matters outside the context of what business value it represents.

This is where your focus should stay.

Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves. Ignore the constant pressure to assert yourself through syntactic cleverness and obscure trivia. These things don’t matter. These things don’t drive value for anyone. No matter how many “experienced” engineers tell you these are important, I promise you no company hires people simply for them to recite principles and algorithms.

While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human. These attributes will guide your engineering efforts to ensure you bring value.

No matter where your career goes, if you focus on creating value for people, opportunities will never be in short supply. Desire for specific skills may rise and fall, but people will always look to those who can create value.

With that, I wish you the best of luck and may our journeys cross again,

Minh Pham

Minh Pham believes you should lead how you want to be led. This has been the guiding principle of his career since he started. As an Engineer, he always wished he had someone who would guide him – telling him what’s important, what he has to work on, and what he should ignore. Having gone through all that and then some, Minh now looks to be the positive influence he wishes he had.

As a manager, Minh’s greatest passion was teaching people the skills to create and drive the careers they want to have. Now as a career coach, he works to show people they have the power to build the life they want.

Minh believes anyone can do it – and he promises it doesn’t involve linked lists or graph traversals.

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.

The Code Will Never Judge You

This is a guest post from Lorna Mitchell. Enjoy.

Dear new developer,

Recently, I decided my seven-year-old niece was old enough for her first programmable device. She has done a little bit of Scratch with me, so I bought her a BBC micro:bit (a very simple programmable device, with a web editor and USB connection, some buttons and some LEDs) and showed her how to get started. Then I said to my sister (whose child this is) “the tears are all part of the software development process, so try not to worry when it happens!”. However many years down the path I am myself, coding is still a rollercoaster and there are some downs as well as some ups.

One thing that makes software development more difficult is wondering if you are really cut out for this. It’s so easy to feel like you are doing software “wrong” in some way. Spoiler: there really isn’t a right way, it’s part art as well as part science. Keep the user in mind and apply the technology the best way you know how; you’ll go far.

Some days it doesn’t feel like it’s going well and you may wonder if you will ever be really good at your chosen profession. On other days, or perhaps overlapping days, other people will think you’re not cut out for it either. Maybe you think your skill set isn’t a good fit (it is), or that you don’t really look like a software developer (you do). It is very difficult to help other humans who have already decided that they don’t quite believe in you. From extensive field testing, I have found that almost none of them ever change their mind.

In fact, this is much less important than it seems. If you don’t understand the pop culture that inspired the bot/server names, you didn’t play the same computer games or watch the same films (I’ve still never seen Star Wars), that doesn’t impact on what you can be. For minorities of all stripes, not sharing the supposedly shared culture can really make you doubt yourself. That’s a human reaction, don’t feel bad for feeling your feelings. If you want to be a person who does play those games and watch those films, then go for it.

But if you are just there to be the best software developer you can be, then let the other things go past you, and focus on the things you really do want to learn from, and share with, the crowd. I think most of what I know about text editors, information security, and leadership I learned from colleagues or conference encounters. It took me far too long to realise that software developers do look and sound like I do, and my own interests and hobbies are no less valid than anyone else’s (I also know more very technical humans with yarncraft hobbies now).

The code will never judge you. You show up, try things out, keep learning, keep iterating. That’s how software is made. It isn’t made of what other people thought you could do, it’s only made of what you did do, and for that you need to show up, and do.

— Lorna

Lorna is based in Yorkshire, UK; she is a Developer Advocate at Vonage as well as a published author and experienced conference speaker. Lorna is passionate about open source technologies and sharing knowledge, code and experiences with developers everywhere. In her spare time, Lorna blogs at https://lornajane.net.

You’re gonna be OK

This is a guest post from Jerome Hardaway. Enjoy.

Dear new developer,

So, you’re in the office, learning a million things a minute that you were never exposed to. Everyone around you seems super competent and you don’t want to take time away from them, but you have no idea what you’re doing. You feel like you should probably be a janitor instead of working on a million dollar web app. I’m here to tell you, you’re wrong.

Every person who seems competent has felt like you or still feels like you do, they are just better at hiding it. I know people who have been doing this work for years and feel silly at least once a week. Hitting your head against the tech wall is a rite of passage here and normal and whether they tell you or not, we have all been there. We have all either accidentally taken down prod, nuked the repo, felt lost, accidentally ran up the AWS bill, and just straight up sucked at this job. So long as you focus on having more good days than bad, you will be fine. More than that, you’ll do great, so relax cause we are all rooting for you.

— Jerome

Jerome Hardaway is a Developer Advocate at Quicken Loans and Executive Director at Vets Who Code, Where they help veterans get jobs in software by teaching them how to program for free.