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.

Your network increases optionality

This is a guest post from Karl Hughes. Enjoy.

Dear new developer,

I was in your shoes in 2011. I was finishing up a degree in mechanical engineering that I would never use and looking for a way to join a startup as a software developer.

Maybe it was the entrepreneur in me, and maybe it was just naivety, but instead of applying for jobs, I decided to start emailing interesting companies instead. I made a list of technology startups in the education industry and emailed each of them my pitch.

Two of them got back to me and one (Uloop) had an office three hours away in Nashville. I drove to meet their CEO and after a few conversations, they brought me on as a freelancer. When I graduated a few months later, they offered me a full-time role managing their blog and writing custom WordPress plugins.

Since then, I’ve worked at three different edtech startups and never once had a formal “job interview.” Every company I’ve worked for has hired me because I met someone there and stayed in touch for months. When a job opened up, they reached out to me to see if I was interested.

My first job hunt showed me that your strength as a software developer is not in your resume, your knowledge of algorithms, your ability to keep up with the hottest frameworks, or even your problem-solving skills. The most powerful tool you have is your network.

The Employer’s Perspective

As a job-seeker, you know that looking for a job is scary, but from an employer’s perspective, hiring is scary too.

After sitting in the hiring manager’s seat several times in the past few years, I can tell you that I’m as scared of hiring the wrong person as you are of screwing up the job interview. If I make a bad hire, I look bad to my boss, and my team’s productivity will suffer. Having to fire someone kills morale and hurts the manager’s reputation, so nobody wants to do it.

This fear is why managers look for people in their networks or work with recruiters. The very last place employers look for applicants is the cold resume bin.

How I Built My Network

If you want to avoid the black hole of submitting your resume online, you need to build a network. I don’t know you well enough to give you a perfect formula for your situation, so I’ll just tell you how I built my network. I hope some of these ideas resonate.

First, I started as a freelancer before I ever had a “real” job as a programmer. Most people don’t recommend this approach for new developers, but it forced me to learn to “sell” myself really well. When I started with Uloop, I often had no idea how to accomplish a task, but I bet that I could learn it before they discovered I was making it up.

After getting that first job, I started attending meetups and conferences regularly. Uloop was a small company, so there wasn’t much opportunity to network within the organization, but I had moved to Chicago, where there were plenty of programming meetups and tech events to attend.

I tried meeting people at these events, but it was hard. I’m not that outgoing, so instead, I would email the event’s speaker or organizer afterward and invite them to a one-on-one coffee or lunch. Some of the people I met like this are among my closest mentors and friends today.

As I attended more meetups and got to know speakers and leaders, people started inviting me to give back. I was little more than a junior developer at the time, but I was asked to speak at bootcamps, meetups, and even a couple of small conferences because of my network.

Naturally, I was nervous the first few times I got up in front of a group to share my experience. I knew there were people in the crowd with decades of experience on me, and I expected them to stand up and call me out if I made any mistakes. I found that practice and gradually increasing the stakes helped me. By trying a talk out at a local meetup and slowly working up to larger audiences at a conference, I gained confidence over time.

Giving a talk at a meetup or conference is a lot of work, and you don’t typically get paid for it. That said, I knew how helpful it was hearing developers who were more experienced than me back when I was first learning to code, so I have always enjoyed the opportunity to give back.

One side effect of speaking is that you get even more opportunities to increase your network. At some point, I switched from being the one asking speakers to meet with me to the one that attendees were asking to speak with. I always enjoy these interactions with new developers, and the opportunity to encourage or help others is my primary motivation for speaking and writing this letter.

Keeping in Touch

Everyone who talks about networking tells you to go out and meet more people, but that’s worthless if you don’t keep in touch with anyone. As I started to meet more people in Chicago, I realized that I needed to come up with a way to have more encounters with each of them.

“It takes on average about 3 encounters — and by that I mean intentional rather than passing interactions where you’ve gotten together primarily to just hang out — to really see if there’s potential for a relationship with someone.” – Brett McKay

The first step was to start a spreadsheet of people I wanted to keep up with. Most of them were more experienced than me, but many were peers or newer developers I “clicked” with or found interesting.

Next, I made a reminder to reach out to 1-2 people on the list every week. I’d ask how they were doing and see if they wanted to get lunch or coffee sometime. I tried to find organic reasons to connect (birthdays, an article related to their industry, etc.) and ask them questions about their lives. One of the easiest ways to make someone like you is to get them talking about something they like. People love talking about themselves.

While this sounds calculated, I do genuinely enjoy these conversations. We’re all busy, but having a system like this ensures that I don’t forget to maintain my network. If I ever feel like I’m no longer getting along with someone, I remove them from my list and no harm is done.

The reason most people don’t do this is that it takes a lot of time. I still spend 4-6 hours per week keeping in touch with or expanding my network. It may seem like a lot, but the investment has paid dividends and afforded me many interesting conversations and relationships along the way. This strategy of intentionally staying in touch with people has led to friendships, co-workers, job offers, and clients.

Make It Yours

No career advice will work for everyone.

I didn’t write this letter to give you a formula for networking, but rather to let you know that unconventional approaches can work. My network has been an invaluable asset, but luck and privilege played a huge part too.

If I hadn’t been able to drive three hours to take a meeting with my future boss, would he have hired me? If I needed to be home after work to help care for a family member, would I have been able to network at Meetups? If I weren’t a white male in an industry dominated by white males, would people have taken the time to meet with me?

I don’t know.

I have no idea what your career path will look like, but I hope my story gives you the courage to build a path that works for you.

Signed,
Karl

Karl is a former CTO and freelance writer. He’s currently the founder of Draft.dev where he helps companies create content that reaches software developers.

Influencing outcomes through output

Dear new developer,

“Outcomes over output” is one of my favorite letters on this blog. In it, Mark, a guest poster, talks about what business actually values (outcomes) over what developers often focus upon (outputs).

Outcomes are things like:

  • more sales
  • happier customers
  • publicity
  • less customer churn

Outputs, on the other hand, are things like:

  • more features
  • test coverage
  • flexible code
  • customer retention analytics

The reason that I focus on outputs is that is what I can control. Outcomes, except in rare cases, are outside of my control. For instance, at a startup a while back, I wrote a lot of code, but couldn’t control how the sales process was going. I felt whipsawed between building things as fast as I could when sales seemed to be happening at a snail’s pace.

It’s important to recognize that business, like life, is a long game. You are the result of choices you (and those who have influenced you) have made.

So, also, are the outcomes upon which you are judged in your career. To square this circle and relate outcomes to outputs as best as I can, I do the following:

  • Recognize the tension. All I can control are the outputs; I can only, at best, influence outcomes. But people pay for results, not for effort.
  • Find best practices. If others have completed tasks or created outputs which produced desired outcomes, learn about them. I don’t follow the same paths uncritically (cargo culting) but need to know about them to make informed choices.
  • Be methodical. When I choose to produce an output, make it good. How good depends on the audience and possible payoff: a script to load data once deserves less care than code that will be run thousands or millions of times. But, I strive to make anything I do excellent.
  • Find ways to incrementally improve outputs over time. These can include automated tools, checklists, and incorporating new practices. I can also choose to stop. This is a strategic choice that shouldn’t be considered every day; once in a while, though, I ask myself if I need to keep producing this output.
  • Experiment. Tweak outputs and see if the outcomes change. Sometimes this is easy and quick, other times I’ll need months to see changes. This requires patience.

What can you do if you are in a situation where the outcomes and the outputs are totally divorced from each other? Where your effort isn’t going have any effect on desired results?

That’s a tough place to be. I would feel ineffectual and frustrated. I think if you are in this situation, you need to sit down on a weekend and spend some time thinking about how you want to spend your life. Of course, there are valid reasons to hang tough:

  • Desired outcomes might be shifting
  • New outputs are being tested
  • Your role is changing

If that is the case, hang on if you can; sometimes a job is stormy but it is better afterwards and therefore worthwhile to see through. After all, outcomes aren’t just hard for you to influence, they are hard for everyone.

But if you do some thinking and find that your efforts have been disconnected from outcomes for a while, and that your nerves are frayed, change the situation. Whether that is leaving a job or moving to a different town, changes can reset your life. And hopefully put you in a position where your outputs are more in line with desired outcomes.

Sincerely,

Dan

Always leave the code better than you found it

Dear new developer,

I’ve spent a lot of my time maintaining working code. I think that is more typical of software developers than working in greenfield development. Yes, there are definitely jobs where you are writing more new code than maintaining, upgrading, bug fixing and improving old code (startups without product market fit being one, consulting being another) but in general code is expensive and folks want to run it for a long time.

Often you’ll jump into code to fix a bug, investigate an issue or answer a question.

When you do so, improve it. This doesn’t mean you rewrite it, or upgrade all the libraries it depends on, or rename all the variables.

You don’t need to transform it.

But you should make it better. Just clean it up a bit. Doing so makes everyone’s lives just a bit better, helps the codebase in a sustainable way, and assists the business by making its supporting infrastructure more flexible.

What are some ways to improve the code when you are in it?

Document

Whether that is a comment that explains something tricky, a larger piece of documentation external to the code which explains how to interact with it, or fixing a typo, trustworthy documentation is key to interacting with code. This is a good way to start improving a codebase because it has minimal impact on the actual code. Therefore it is low risk. But if you’ve ever had a great comment explain a confusing bit of code, you’ll appreciate the time this effort can save.

You can also help documentation by removing old, crufty docs. If you see a comment that doesn’t apply, remove it. If there’s cut and paste documentation which doesn’t apply, get rid of it. That cleans up the code for the next person to come along (who might be you).

Write a test or improve a test

Tests help you write maintainable, extensible code that others can change fearlessly. If you run across code that isn’t tested and you have time and the supporting framework to write one, do so.

Even if it tests simple functionality such as “can I instantiate this object” or “how does this function react when I pass it two null values”, an additional test will help the robustness of the code.

Refactor it

This is one of the most flexible improvements. Refactoring code can range from renaming a variable to be more true to its nature to an overhaul of an entire module. Start small and don’t get wrapped up in perfection. Make the code clearer in intent.

It’s easy with refactoring to get wound around an axle and make too many changes and end up with broken things. Timeboxing is one technique I use to avoid, or at least minimize, my tendencies toward this when refactoring. If all I have is 30 minutes, I’ll make my changes smaller in scope.

A warning about refactoring. Don’t refactor what you don’t understand. Don’t drive by refactor. Discuss your plan with someone more familiar with the code; git blame is your friend. Especially if the code is not well tested, you want to make sure you don’t do more harm than good.

Upgrade a dependency

It’s sometimes a winding path, but upgrading your dependencies regularly is a good way to maintain the code. I remember working in a fork of struts. It was an important application for the company, but we didn’t spend the time upgrading the dependencies, because it was too painful. Eventually, parts of the code became harder to update. The entire application couldn’t benefit from newer technologies and paradigms because of the older dependencies holding it back.

It never feels good to spend time updating a dependency; to me this always feels like running in place. But if you don’t do so, eventually dependencies will end of life and you’ll be forced to update. That’ll be even less pleasant.

How to do it

Based on feedback (this comment, among others), I added this section on Nov 28.

When you are making these changes to improve the code, you’ll help out code reviewers and your future self by making changes that are improving the code separate from changes that add functionality. Whether you do this in separate pull requests, tickets, or commits depends on your team culture. Ask about that. But such separation will make it easier for people who aren’t familiar with the changes to understand them and give feedback on them, whether that is a code review this week or someone reviewing this component two years from now.

Why do it

All of these actions not only help others because they improve the quality of the code, they also provide examples to other developers on how to do so. For example, it is far easier to write the second test in a suite than the first. You can cut and paste a lot of the setup code and tweak only what is different. The first bit of documentation will inspire more.

Code isn’t everything, but it is an important work output. Whenever you touch it, you should strive to leave it in a better place that it was before you did so.

Sincerely,

Dan

Save off context

Dear new developer,

A key part of software development is being able to pick up where you left off. You are going to have interruptions during your day, and you want to be prepared for them. Whether you took a break to rest your eyes, stepped away for lunch or have left for the day, you’ll want to capture the context of whatever you were working on.

This is especially true if you are being interrupted in the middle of the day to help a teammate or go to a meeting. These tasks are crucial to being a good team member, but often halt progress on a technical problem.

We all have to handle this type of timeslicing, but it can be difficult to remember where we were just before we stopped. Oftentimes if you are building or debugging something, you need to remember many small bits of knowledge: how pieces of a system fit together, what that blog post recommended, what tasks remain to be done.

When someone says “Hey, gotta sec?” a lot of this knowledge gets evicted from my short term memory.

It’s worth taking a minute or two and capturing the most important pieces of information so that when you return to the task, you can jog your memory easily.

The first thing I do is prepare to make time for this. If a co-worker pings me on slack to see if I have a second, I’ll reply when I see it with “sure, give me a few minutes, please”. Side note, I am a big believer in turning off notifications for slack, email and anything else. I always provide my teammates with my cellphone number and ask that if there’s anything urgent, they contact me there. (Haven’t been called yet.)

When you know an interruption is impending, plan for a context recording buffer. For example, if I have a meeting scheduled, a few minutes before the meeting, I’ll stop what I’m doing to capture the context.

Next, use that time to record what you’ll need to pick the task back up. I like to do this in a few different ways. I sometimes write things down in a paper notebook. This is great because it is free form, portable, works when I’m away from the computer, and quick. However, my handwriting is atrocious and I’ve definitely peered at notes I’ve written trying to decipher them.

I’ll also open up a text document and write down a couple of lines of context. These could be tasks I need to undertake, something I need to research, someone I need to talk to, or something I know is half working and needs to be looked at. I often do these in standalone files, but have also put them in comments in the code as well. I usually save these off, just in case my computer crashes. I could do this in a Google doc or slack message to myself, but find that a local text file is durable enough.

You can also capture this context in a more formal manner, by writing a failing test. That way, when you return to the problem, you can re-run your tests and move right to the work in progress. This is great if you are in the middle of code, but doesn’t work so well for other types of knowledge.

Another formal way to capture the context of whatever task you are doing is to use a checklist. Write it initially, modify it as the task progresses, and keep your progress up to date. If this is a complicated, multi day task, I’ve found a checklist to be useful, but if it’s an hour long task, I find the overhead of keeping the checklist up to date outweighs the benefit I receive.

These notes, by the way, aren’t designed to be your knowledge base. They don’t need to be authoritative. You aren’t going to consult this later. This isn’t full fledged documentation, these are scrawled notes which will be tossed as soon as you pick the task back up. So don’t stress over capturing everything in a way that someone else could use. Doing so will take too long for the value you’ll get.

Now that the context of your current task is saved off somewhere more durable than your poor neurons, take care of the interruption. Help that teammate. Go take that walk. Attend that meeting. Head home for dinner.

When you return, whether in 15 minutes or after a week vacation, return to the flow as soon as you can.

Re-read your notes, re-run your tests, review your checklist. And get back to it.

Sincerely,

Dan

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.

How to say I don’t know

Dear new developer,

The honest truth is that you won’t know everything. No one does. The CEO, CTO, the team lead, that really smart senior developer on your team, none of them know everything. In fact, I bet if you asked any one of them if they’d been stymied in the past week, they’d reveal that yes, they ran into something they didn’t know how to do or how to approach.

Encyclopedic knowledge isn’t a good goal. You need to know how to figure things out. But when someone asks you “can you do X?”, you need to be prepared with the right answer, even if you don’t know how to do X. For example, I was tasked with setting up a static IP for a heroku application. I didn’t know how to do this. Rather than say “I don’t know how to do that”, I said “let me do some research and get back to you.” I also asked about deadlines and how high a priority this was.

I did some research, read some docs and came up with a proposed solution. I discussed it at standup with my team, including my boss, and we came up with a path toward implementation.

When you don’t know something, and someone asks you about it, there are a few things you must do.

First, you should tell them you don’t know. They might have some clues for you, or pointers to documentation. These can all accelerate your ability to do what is asked of you.

Depending on the situation, they may assume you know, based on their experience. For example, I work in the authentication space right now, with standards like OAuth and OIDC. When I first started, I had to ask what every piece of jargon meant, but after a few months I got up to speed. Now when I talk to other audiences, I need to be careful not to use too much jargon or assume what others know. One favorite technique I use is repeating back what someone said: “Can I repeat back to you what said to make sure I understand it? What I heard is that the OAuth code grant redirects to the client application after the user authenticates. Is that right?”

When you say “I don’t know” don’t stop there. Say “I don’t know, but I’ll find out.” Again, they may point you in a direction, but by adding that second clause, you indicate that you’ll solve this problem. You should also ask about timeline and priority if that hasn’t been communicated (by story points, a task tracker or in some other fashion).

Finally, do what you say you’re going to do. Find out what you didn’t know. Don’t be afraid to ask questions of your team members, spend time on the internet searching, set up your dev environment and tweak settings, brainstorm, get frustrated, and write down hypotheses that you can test out. All of these are techniques I’ve used in trying to figure things out.

Saying I don’t know, honestly, with a plan to remedy your ignorance, is a key part of being a software developer.

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.

Plan first, then code

Dear new developer,

I thought this article was worth sharing, as it is a relatively inexperienced developer talking to newer devs. But as I read it, one piece of advice stuck out and is worth emphasizing.

Plan first, then code

Roberto Hernandez

This is fundamental. Unlike, say carpentry, where planning is critical because you waste material if you don’t, coding sometimes feels like you can “just start.” After all, if you make a mistake, you can delete the code and start over (as long as you’re operating on your own development environment, not production). Seeing what you’re building is satisfying, both to you as a builder and anyone else you share your work with.

However, “just starting” is a recipe for waste, if what you start is writing code.

The first thing you should do before writing a single line of code is understand the problem. Depending on the size and scale of the problem, confirming this understanding could be as simple as repeating the request back to the person who made it: “so what you are saying is you want me to change the button text to blue” and thinking through the ramifications: “that will work on form A and B, but what about form C?”.

Or it could be as complicated as writing up a specifications document with the proposed changes and architecture, getting feedback on it, running it by the appropriate people or committees, and getting sign-off from stakeholders, including executives and customers.

Then, after you confirm you understand the problem and proposed solution, plan on how you are going to execute against it. For a small problem, this could involve starting immediately by writing or thinking of a list of tasks to do, though often you’ll want to add it to a todo list or calendar to ensure this task isn’t lost among the sea of other tasks you have. For a larger problem, there may be cross team coordination required, so: meetings and documents.

After you understand the problem and have a plan for how to accomplish this goal, you can begin writing code.

Avoid jumping in and writing code because the time to feedback is long. Compared to what? Compared to text, images or meetings. These are so much easier to iterate. If you write some code to solve the wrong problem or address it in the wrong manner, you’ve used more time than you would have if you’d talked through the problem.

It is also harder to communicate concepts with code, especially with non technical colleagues. Even with fellow engineers, a diagram or conversation is an easier way to explain ideas than written code. I’ve often whiteboarded a solution in a fraction of the time it would have taken to prototype it. Code is more precise and you can’t handwave a problem away, but there’s lots of chaff around the germ of the idea in many code bases.

There are times when writing code is the right way to start, though. This is called prototyping and if there’s no way to gain an understanding of the problem by reading, learning, discussing or otherwise approaching it, write some code to explore it. However, be prepared to throw this code away, as it will be the equivalent of a hastily scratched note on a napkin.

I do want to emphasize that this understanding and planning process doesn’t always have to be heavyweight and formal. In fact, for smaller tasks, you may internalize this process and not even realize you are doing it.

Next time you are working on a small task, take a moment and think about how you break it up into even smaller bits of work: “ok, I need to add this form. Therefore I need a model and a view too, and what are the methods I should add to validate the input?”

You don’t need to produce documentation and artifacts for every decision, but you would do well to at least in your own head think through the tasks and the ramifications of those tasks. This will help you look around corners and see issues that may arise because of your solution. If you do, you can modify the solution, again, before any code is written.

Sincerely,

Dan

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