• 00:09:45

    Ep. 38 - How to conquer legacy code

    The freeCodeCamp Podcast starstarstarstarstar

    Have you ever had to deal with legacy code - code that someone else wrote a long time ago? Are you temped to just rip everything apart and rewrite it? Bill explains why this is a bad idea and how to approach - and respect - legacy code instead.

    Written by Bill Sourour: https://twitter.com/billsourour

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2KJahRe

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    At some point in your developer career, your boss will hand you a piece of legacy code — code that someone else wrote a long time ago. Your boss will tell you to learn this legacy code, fix it, and add new features to it.

    I’ve been in this situation many times over the last two decades. I can help.

    How to understand legacy code

    If you’re lucky, you’ll have documentation, or at least in-line comments. Maybe one or two of the original authors will still even be around to help. But most of the time, you will not be so lucky.

    Let’s talk about what you’re going to do in those unlucky cases.

    First, you need to be humble. Respect the code, and the developers who wrote it.

    It’s easy to look at work that came before you and decide it’s no good and that you can do better. This is the wrong attitude. It will lead you down a very dangerous path.

    If you go down this dangerous path, you’ll start making changes before properly understanding the impact of those changes. You’ll “fix” things that aren’t broken, because they are written in a style that you don’t like, or are based on an older way of doing things. Ultimately, you’ll waste an incredible amount of time with this attitude.

    So stop. Take a step back and realize that everything in that codebase was done a certain way for a reason.

    Until you know the code forward and backward, you have to assume that there were good reasons for it to be written the way it is, and that you just haven’t figured them out yet.

    This is a much more productive attitude, and it will save you from breaking everything, then just wanting to jump out of a window when you can’t put it back together quickly enough.

    Don’t Humpty Dumpty your codebase.

    The best way that I’ve found to learn a codebase is to start at the user interface level, then work my way back into the code.

    Pick a single user flow, like logging in, placing an order, writing a review, or whatever is relevant to your particular application. Go through the flow as an end user. Then look at the code, starting with the user interface code — it should be the easiest to recognize — and follow each step on back, all the way to the database.

    As you go along, draw a sequence diagram to help illustrate what is happening. If you’re not sure what a sequence diagram is, or how to draw one, check out this free tutorial. If you don’t have a good tool for drawing UML, here’s a free one.

    Once you’ve completed your first sequence diagram, using a local copy of the codebase that you can easily restore, start to make subtle changes to some of the components you’ve encountered. See if you can predict the effects of your changes on the application. This is a good way to test your understanding.

    Keep repeating this process, adding to your diagrams until you have a complete picture of the entire application (or at least all the parts you are responsible for).

    For bonus points, make sure you share your notes and diagrams. Put them in a highly visible place where the next developer who comes along can easily discover them. Don’t worry about making them perfect, or even pretty. Just do what you can. Every little bit helps.

    Overall, the most important thing is to be patient, and avoid beating yourself up. Code is a complex thing. Understanding legacy code takes time. Stay calm.

    How to fix legacy code

    The biggest challenge you’ll face when fixing legacy code is deciding how far to go with your fix. I strongly advise you to make the minimum viable change first. This means you should make the least disruptive change that completely fixes the problem before attempting to clean and refactor any code.

    This gives you an escape hatch. Worse case scenario, if you get pulled away to address some other priority — or if you’re on a tight deadline — at least you’ll have pulled together some working code that you can fall back on.

    Once you’ve gotten your code working, if you still have time left, you can start making small, incremental improvements.

    Martin Fowler has put together a catalog of refactorings which will give you a good idea of the types of changes you can make to incrementally improve a codebase. Check it out here. The idea is to always leave the code in better shape than it was when you found it.

    Sometimes, you’ll encounter a bug that is actually the result of a structural defect. These bugs can’t be fixed by a simple change to some conditional logic. They require more invasive changes.

    This is where things get hairy. You have to be brutally honest with yourself about what the minimum viable change is. Every fiber of your being will want to pull the code apart and re-write the whole thing. Don’t do it!

    Stick to a quick fix, followed by an incremental improvement that refactors it and cleans it up as much as time permits. Your goal is just to make the code a little better every time. The longer you maintain the codebase, the better it will get.

    To truly make this approach work, make sure you’re always padding your estimates to allow time for a bit of refactoring.

    Sometimes, the structural defects are so bad that a strategy of forever patching just won’t work. This situation is actually much more rare than you might think.

    Again, you have to be brutally honest with yourself about the cost/benefit of a rewrite or redesign. You need to accept that, ultimately, this will be a business decision and not a technical one.

    Prepare to state your case in business terms. What will it cost to do a major restructuring of the code? What are the real business risks of not doing it? If you have a solid case, you will eventually be heard. Don’t be surprised if it takes a few more cycles of patching first, though.

    Remember: if you are doing a major overhaul, first make sure there’s support for the change and a reasonable budget to go along with it. Don’t try to fly under the radar with this. Unless, of course, you relish awkward conversations with management when you start breaking things and missing deadlines.

    How to add new features to legacy code

    Finally, you will eventually be called upon to add features to legacy code. At this point, you have an important decision to make. Do you “go with the flow” of the current codebase, or take things in a new direction?

    Again, I advise you to be brutally honest in your evaluation. Would continuing to follow the patterns and practices evident in the existing codebase make it worse, or pile onto an existing problem?

    Most of the time, you’ll want to keep things stable. Just make incremental additions using the existing patterns and practices of the code. Re-use existing elements. Make the least disruptive changes possible, while making small, incremental improvements by cleaning and refactoring.

    If you believe that a new direction is absolutely necessary, then you’ll need to find a way to isolate your changes and couple them as loosely as possible to the existing codebase.

    Try carving out the new feature as a separate project. You can then expose an API that lets the legacy code plug into your new code. This makes it so that your new code and the old legacy code don’t need to know much about each other.

    This starts to get a bit tricky when you need to use functionality from the legacy code in order to implement the new feature. The best way to isolate the old code from the new code is to use the Adapter Pattern.

    DO Factory has a good explanation of the Adapter Pattern:

    “The Adapter pattern translates one interface (an object’s properties and methods) to another. Adapters allow programming components to work together that otherwise wouldn’t because of mismatched interfaces. The Adapter pattern is also referred to as the Wrapper Pattern.

    One scenario where Adapters are commonly used is when new components need to be integrated and work together with existing components in the application.

    Another scenario is refactoring in which parts of the program are rewritten with an improved interface, but the old code still expects the original interface.”

    Here are some links to explanations and examples in various languages.

    JavaScript example of the Adapter Pattern

    C# example of the Adapter Pattern

    Java example of the Adapter Pattern

    Key takeaways

    In summary, here are the key points that will help you tackle and ultimately conquer any codebase:

    Never judge legacy code or change it until you’ve taken the time to fully understand it.

    Sequence diagrams are your friend.

    Prefer small, incremental improvements over wholesale re-writes or changes.

    Each change should attempt to leave the code a little better off than it was when you found it.

    If you need to make big changes, make a business case and get approval first.

    When adding new features, try to “go with the flow.”

    If you need to take the code in a new direction, isolate your changes and use the Adapter Pattern to integrate.

    Hopefully you found this article useful. My mission is to help as many developers as I can.

  • 00:18:40

    Ep. 37 - The Rise of the Data Engineer

    The freeCodeCamp Podcast starstarstarstarstar

    When Maxime worked at Facebook, his role started evolving. He was developing new skills, new ways of doing things, and new tools. And — more often than not — he was turning his back on traditional methods. He was a pioneer. He was a data engineer! In this podcast, you'll learn about the rise of the data engineer and what it takes to be one.

    Written by Maxime Beauchemin: https://twitter.com/mistercrunch

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2tHLCST

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    I joined Facebook in 2011 as a business intelligence engineer. By the time I left in 2013, I was a data engineer.

    I wasn’t promoted or assigned to this new role. Instead, Facebook came to realize that the work we were doing transcended classic business intelligence. The role we’d created for ourselves was a new discipline entirely.

    My team was at forefront of this transformation. We were developing new skills, new ways of doing things, new tools, and — more often than not — turning our backs to traditional methods.

    We were pioneers. We were data engineers!

    Data Engineering?

    Data science as a discipline was going through its adolescence of self-affirming and defining itself. At the same time, data engineering was the slightly younger sibling, but it was going through something similar. The data engineering discipline took cues from its sibling, while also defining itself in opposition, and finding its own identity.

    Like data scientists, data engineers write code. They’re highly analytical, and are interested in data visualization.

    Unlike data scientists — and inspired by our more mature parent, software engineering — data engineers build tools, infrastructure, frameworks, and services. In fact, it’s arguable that data engineering is much closer to software engineering than it is to a data science.

    In relation to previously existing roles, the data engineering field could be thought of as a superset of business intelligence and data warehousing that brings more elements from software engineering. This discipline also integrates specialization around the operation of so called “big data” distributed systems, along with concepts around the extended Hadoop ecosystem, stream processing, and in computation at scale.

    In smaller companies — where no data infrastructure team has yet been formalized — the data engineering role may also cover the workload around setting up and operating the organization’s data infrastructure. This includes tasks like setting up and operating platforms like Hadoop/Hive/HBase, Spark, and the like.

    In smaller environments people tend to use hosted services offered by Amazon or Databricks, or get support from companies like Cloudera or Hortonworks — which essentially subcontracts the data engineering role to other companies.

    In larger environments, there tends to be specialization and the creation of a formal role to manage this workload, as the need for a data infrastructure team grows. In those organizations, the role of automating some of the data engineering processes falls under the hand of both the data engineering and data infrastructure teams, and it’s common for these teams to collaborate to solve higher level problems.

    While the engineering aspect of the role is growing in scope, other aspects of the original business engineering role are becoming secondary. Areas like crafting and maintaining portfolios of reports and dashboards are not a data engineer’s primary focus.

    We now have better self-service tooling where analysts, data scientist and the general “information worker” is becoming more data-savvy and can take care of data consumption autonomously.

    ETL is changing

    We’ve also observed a general shift away from drag-and-drop ETL (Extract Transform and Load) tools towards a more programmatic approach. Product know-how on platforms like Informatica, IBM Datastage, Cognos, AbInitio or Microsoft SSIS isn’t common amongst modern data engineers, and being replaced by more generic software engineering skills along with understanding of programmatic or configuration driven platforms like Airflow, Oozie, Azkabhan or Luigi. It’s also fairly common for engineers to develop and manage their own job orchestrator/scheduler.

    There’s a multitude of reasons why complex pieces of software are not developed using drag and drop tools: it’s that ultimately code is the best abstraction there is for software. While it’s beyond the scope of this article to argue on this topic, it’s easy to infer that these same reasons apply to writing ETL as it applies to any other software. Code allows for arbitrary levels of abstractions, allows for all logical operation in a familiar way, integrates well with source control, is easy to version and to collaborate on. The fact that ETL tools evolved to expose graphical interfaces seems like a detour in the history of data processing, and would certainly make for an interesting blog post of its own.

    Let’s highlight the fact that the abstractions exposed by traditional ETL tools are off-target. Sure, there’s a need to abstract the complexity of data processing, computation and storage. But I would argue that the solution is not to expose ETL primitives (like source/target, aggregations, filtering) into a drag-and-drop fashion. The abstractions needed are of a higher level.

    For example, an example of a needed abstraction in a modern data environment is the configuration for the experiments in an A/B testing framework: what are all the experiment? what are the related treatments? what percentage of users should be exposed? what are the metrics that each experiment expects to affect? when is the experiment taking effect? In this example, we have a framework that receives precise, high level input, performs complex statistical computation and delivers computed results. We expect that adding an entry for a new experiment will result in extra computation and results being delivered. What is important to note in this example is that the input parameters of this abstraction are not the one offered by a traditional ETL tool, and that a building such an abstraction in a drag and drop interface would not be manageable.

    To a modern data engineer, traditional ETL tools are largely obsolete because logic cannot be expressed using code. As a result, the abstractions needed cannot be expressed intuitively in those tools. Now knowing that the data engineer’s role consist largely of defining ETL, and knowing that a completely new set of tools and methodology is needed, one can argue that this forces the discipline to rebuild itself from the ground up. New stack, new tools, a new set of constraints, and in many cases, a new generation of individuals.

    Data modeling is changing

    Typical data modeling techniques — like the star schema — which defined our approach to data modeling for the analytics workloads typically associated with data warehouses, are less relevant than they once were. The traditional best practices of data warehousing are loosing ground on a shifting stack. Storage and compute is cheaper than ever, and with the advent of distributed databases that scale out linearly, the scarcer resource is engineering time.

    Here are some changes observed in data modeling techniques:

    further denormalization: maintaining surrogate keys in dimensions can be tricky, and it makes fact tables less readable. The use of natural, human readable keys and dimension attributes in fact tables is becoming more common, reducing the need for costly joins that can be heavy on distributed databases. Also note that support for encoding and compression in serialization formats like Parquet or ORC, or in database engines like Vertica, address most of the performance loss that would normally be associated with denormalization. Those systems have been taught to normalize the data for storage on their own.

    blobs: modern databases have a growing support for blobs through native types and functions. This opens new moves in the data modeler’s playbook, and can allow for fact tables to store multiple grains at once when needed

    dynamic schemas: since the advent of map reduce, with the growing popularity of document stores and with support for blobs in databases, it’s becoming easier to evolve database schemas without executing DML. This makes it easier to have an iterative approach to warehousing, and removes the need to get full consensus and buy-in prior to development.

    systematically snapshoting dimensions (storing a full copy of the dimension for each ETL schedule cycle, usually in distinct table partitions) as a generic way to handle slowly changing dimension (SCD) is a simple generic approach that requires little engineering effort, and that unlike the classical approach, is easy to grasp when writing ETL and queries alike. It’s also easy and relatively cheap to denormalize the dimension’s attribute into the fact table to keep track of its value at the moment of the transaction. In retrospect, complex SCD modeling techniques are not intuitive and reduce accessibility.

    conformance, as in conformed dimensions and metrics is still extremely important in modern data environment, but with the need for data warehouses to move fast, and with more team and roles invited to contribute to this effort, it’s less imperative and more of a tradeoff. Consensus and convergence can happen as a background process in the areas where the pain point of divergence become out-of-hand.

    Also, more generally, it’s arguable to say that with the commoditization of compute cycles and with more people being data-savvy then before, there’s less need to precompute and store results in the warehouse. For instance you can have complex Spark job that can compute complex analysis on-demand only, and not be scheduled to be part of the warehouse.

    Roles & responsibilities

    The data warehouse

    A data warehouse is a copy of transaction data specifically structured for query and analysis. — Ralph Kimball

    A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process. — Bill Inmon

    The data warehouse is just as relevant as it ever was, and data engineers are in charge of many aspects of its construction and operation. The data engineer’s focal point is the data warehouse and gravitates around it.

    The modern data warehouse is a more public institution than it was historically, welcoming data scientists, analysts, and software engineers to partake in its construction and operation. Data is simply too centric to the company’s activity to have limitation around what roles can manage its flow. While this allows scaling to match the organization’s data needs, it often results in a much more chaotic, shape-shifting, imperfect piece of infrastructure.

    The data engineering team will often own pockets of certified, high quality areas in the data warehouse. At Airbnb for instance, there’s a set of “core” schemas that are managed by the data engineering team, where service level agreement (SLAs) are clearly defined and measured, naming conventions are strictly followed, business metadata and documentation is of the highest quality, and the related pipeline code follows a set of well defined best practices.

    It also becomes the role of the data engineering team to be a “center of excellence” through the definitions of standards, best practices and certification processes for data objects. The team can evolve to partake or lead an education program sharing its core competencies to help other teams become better citizens of the data warehouse. For instance, Facebook has a “data camp” education program and Airbnb is developing a similar “Data University” program where data engineers lead session that teach people how to be proficient with data.

    Data engineers are also the “librarians” of the data warehouse, cataloging and organizing metadata, defining the processes by which one files or extract data from the warehouse. In a fast growing, rapidly evolving, slightly chaotic data ecosystem, metadata management and tooling become a vital component of a modern data platform.

    Performance tuning and optimization

    With data becoming more strategic than ever, companies are growing impressive budgets for their data infrastructure. This makes it increasingly rational for data engineers to spend cycles on performance tuning and optimization of data processing and storage. Since the budgets are rarely shrinking in this area, optimization is often coming from the perspective of achieving more with the same amount of resources or trying to linearize exponential growth in resource utilization and costs.

    Knowing that the complexity of the data engineering stack is exploding we can assume that the complexity of optimizing such stack and processes can be just as challenging. Where it can be easy to get huge wins with little effort, diminishing returns laws typically apply.

    It’s definitely in the interest of the data engineer to build [on] infrastructure that scales with the company, and to be resource conscious at all times.

    Data Integration

    Data integration, the practice behind integrating businesses and systems through the exchange of data, is as important and as challenging as its ever been. As Software as a Service (SaaS) becomes the new standard way for companies to operate, the need to synchronize referential data across these systems becomes increasingly critical. Not only SaaS needs up-to-date data to function, we often want to bring the data generated on their side into our data warehouse so that it can be analyzed along the rest of our data. Sure SaaS often have their own analytics offering, but are systematically lacking the perspective that the rest of you company’s data offer, so more often than not it’s necessary to pull some of this data back.

    Letting these SaaS offering redefine referential data without integrating and sharing a common primary key is a disaster that should be avoided at all costs. No one wants to manually maintain two employee or customer lists in 2 different systems, and even worse: having to do fuzzy matching when bringing their HR data back into their warehouse.

    Worse, company executive often sign deal with SaaS providers without really
    considering the data integration challenges. The integration workload is systematically downplayed by vendors to facilitate their sales, and leaves data engineers stuck doing unaccounted, under appreciated work to do. Let alone the fact that typical SaaS APIs are often poorly designed, unclearly documented and “agile”: meaning that you can expect them to change without notice.


    Data engineers are operating at a higher level of abstraction and in some cases that means providing services and tooling to automate the type of work that data engineers, data scientists or analysts may do manually.

    Here are a few examples of services that data engineers and data infrastructure engineer may build and operate.

    data ingestion: services and tooling around “scraping” databases, loading logs, fetching data from external stores or APIs, …
    metric computation: frameworks to compute and summarize engagement, growth or segmentation related metrics

    anomaly detection: automating data consumption to alert people anomalous events occur or when trends are changing significantly
    metadata management: tooling around allowing generation and consumption of metadata, making it easy to find information in and around the data warehouse

    experimentation: A/B testing and experimentation frameworks is often a critical piece of company’s analytics with a significant data engineering component to it

    instrumentation: analytics starts with logging events and attributes related to those events, data engineers have vested interests in making sure that high quality data is captured upstream

    sessionization: pipelines that are specialized in understand series of actions in time, allowing analysts to understand user behaviors
    Just like software engineers, data engineers should be constantly looking to automate their workloads and building abstraction that allow them to climb the complexity ladder. While the nature of the workflows that can be automated differs depending on the environment, the need to automate them is common across the board.

    Required Skills

    SQL mastery: if english is the language of business, SQL is the language of data. How successful of a business man can you be if you don’t speak good english? While generations of technologies age and fade, SQL is still standing strong as the lingua franca of data. A data engineer should be able to express any degree of complexity in SQL using techniques like “correlated subqueries” and window functions. SQL/DML/DDL primitives are simple enough that it should hold no secrets to a data engineer. Beyond the declarative nature of SQL, she/he should be able to read and understand database execution plans, and have an understanding of what all the steps are, how indices work, the different join algorithm and the distributed dimension within the plan.

    Data modeling techniques: for a data engineer, entity-relationship modeling should be a cognitive reflex, along with a clear understanding of normalization, and have a sharp intuition around denormalization tradeoffs. The data engineer should be familiar with dimensional modeling and the related concepts and lexical field.

    ETL design: writing efficient, resilient and “evolvable” ETL is key. I’m planning on expanding on this topic on an upcoming blog post.

    Architectural projections: like any professional in any given field of expertise, the data engineer needs to have a high level understanding of most of the tools, platforms, libraries and other resources at its disposal. The properties, use-cases and subtleties behind the different flavors of databases, computation engines, stream processors, message queues, workflow orchestrators, serialization formats and other related technologies. When designing solutions, she/he should be able to make good choices as to which technologies to use and have a vision as to how to make them work together.

    All in all

    Over the past 5 years working in Silicon Valley at Airbnb, Facebook and Yahoo!, and having interacted profusely with data teams of all kinds working for companies like Google, Netflix, Amazon, Uber, Lyft and dozens of companies of all sizes, I’m observing a growing consensus on what “data engineering” is evolving into, and felt a need to share some of my findings.

    I’m hoping that this article can serve as some sort of manifesto for data engineering, and I’m hoping to spark reactions from the community operating in the related fields!

  • Missing episodes?

    Click here to refresh the feed.

  • 00:07:45

    Ep. 36 - Explain Bitcoin like I'm 5

    The freeCodeCamp Podcast starstarstarstarstar

    You've probably heard a lot about bitcoin over the last few years. But do you truly understand how it works? This article explains the concepts in straightforward language (like you were 5) so you'll never be out of the loop again.

    Written by Nik Custodio: https://twitter.com/nik5ter

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2tzvh1E

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    We’re sitting on a park bench. It’s a great day.

    I have one apple with me. I give it to you.

    You now have one apple and I have zero.

    That was simple, right?

    Let’s look closely at what happened:

    My apple was physically put into your hand.

    You know it happened. I was there. You were there. You touched it.

    We didn’t need a third person there to help us make the transfer. We didn’t need to pull in Uncle Tommy (who’s a famous judge) to sit with us on the bench and confirm that the apple went from me to you.

    The apple’s yours! I can’t give you another apple because I don’t have any left. I can’t control it anymore. The apple left my possession completely. You have full control over that apple now. You can give it to your friend if you want, and then that friend can give it to his friend. And so on.

    So that’s what an in-person exchange looks like. I guess it’s really the same, whether I’m giving you a banana, a book, or say a quarter, or a dollar bill….

    But I’m getting ahead of myself.

    Back to apples!

    Now say, I have one digital apple. Here, I’ll give you my digital apple.

    Ah! Now it gets interesting.

    How do you know that that digital apple that used to be mine, is now yours, and only yours? Think about it for a second.

    It’s more complicated, right? How do you know that I didn’t send that apple to Uncle Tommy as an email attachment first? Or your friend Joe? Or my friend Lisa too?

    Maybe I made a couple of copies of that digital apple on my computer. Maybe I put it up on the internet and one million people downloaded it.

    As you see, this digital exchange is a bit of a problem. Sending digital apples doesn’t look like sending physical apples.

    Some brainy computer scientists actually have a name for this problem: it’s called the double-spending problem. But don’t worry about it. All you need to know is that, it’s confused them for quite some time and they’ve never solved it.

    Until now.

    But let’s try to think of a solution on our own.


    Maybe these digital apples need to be tracked in a ledger. It’s basically a book where you track all transactions — an accounting book.

    This ledger, since it’s digital, needs to live in its own world and have someone in charge of it.

    Say, just like World of Warcraft. Blizzard, the guys who created the online game, have a “digital ledger” of all the rare flaming fire swords that exist in their system. So, cool, someone like them could keep track of our digital apples. Awesome — we solved it!


    There’s a bit of a problem though:

    1) What if some guy over at Blizzard created more? He could just add a couple of digital apples to his balance whenever he wants!

    2) It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through Blizzard is like pulling in Uncle Tommy(a third-party) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way?

    Is there any way to closely replicate our park bench, just you-and-me, transaction digitally? Seems kinda tough…
    The Solution

    What if we gave this ledger — to everybody? Instead of the ledger living on a Blizzard computer, it’ll live in everybody’s computers. All the transactions that have ever happened, from all time, in digital apples will be recorded in it.

    You can’t cheat it. I can’t send you digital apples I don’t have, because then it wouldn’t sync up with everybody in the system. It’d be a tough system to beat. Especially if it got really big.

    Plus it’s not controlled by one person, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already defined at the beginning. And the code and rules are open-source. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on.

    You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like 25 digital apples as a reward. In fact, that’s the only way to create more digital apples in the system.

    I simplified quite a bit

    …but that system I explained exists. It’s called the Bitcoin protocol. And those digital apples are the “bitcoins” within the system. Fancy!

    So, did you see what happened? What does the public ledger enable?

    1) It’s open source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. Within the system, I know they are limited(scarce).

    2) When I make an exchange I now know that digital apple certifiably left my possession and is now completely yours. I used to not be able to say that about digital things. It will be updated and verified by the public ledger.

    3) Because it’s a public ledger, I didn’t need Uncle Tommy(third-party) to make sure I didn’t cheat, or make extra copies for myself, or send apples twice, or thrice…

    Within the system, the exchange of a digital apple is now just like the exchange of a physical one. It’s now as good as seeing a physical apple leave my hand and drop into your pocket. And just like on the park bench, the exchange involved two people only. You and me — we didn’t need Uncle Tommy there to make it valid.

    In other words, it behaves like a physical object.

    But you know what’s cool? It’s still digital. We can now deal with 1,000 apples, or 1 million apples, or even .0000001 apples. I can send it with a click of a button, and I can still drop it in your digital pocket if I was in Nicaragua and you were all the way in New York.

    I can even make other digital things ride on top of these digital apples! It’s digital after-all. Maybe I can attach some text on it — a digital note. Or maybe I can attach more important things; like say a contract, or a stock certificate, or an ID card…

    So this is great! How should we treat or value these “digital apples”? They’re quite useful aren’t they?

    Well, a lot of people are arguing over it now. There’s debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: $1,300 per apple. Some say it’s digital gold, some a currency. Other say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad.

    I have my own opinion about it (and you can check out the link in the original article).

    That’s a story for another time though. But kid, you now know more about Bitcoin than most.

  • 00:10:51

    Ep. 35 - How I went from zero to San Francisco software engineer in 12 months

    The freeCodeCamp Podcast starstarstarstarstar

    One day, Sean was working as a route setter at a rock climbing gym in Tennessee. The next, he was driving to San Francisco, without a plan, to start his career in tech. This is the story of his challenging, winding, but ultimately successful path to his first job as a software engineer.

    Written by Sean Smith: https://twitter.com/bonham_000

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2JQwSXI

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    One year ago, I was working part-time as a route setter at a rock climbing gym in Tennessee. Today I’m working as a software engineer at a cyber-security startup in San Francisco.

    My journey to this point has been unforgettable and life-changing. And yet as challenging as everything was, I think that any sufficiently-motivated person could do the same.

    Knowledge has become democratized. All you need to reach a competitive level in your field is time and dedication. This is especially true for the field of software engineering.

    In 2016, my life was falling apart

    When I started learning to code in 2016, I guess you could say my life was falling apart.

    I’d gone to college as a pre-med student, with degrees in biochemistry and anthropology. But I quickly became disenchanted with science and medicine, and left college with no clear path.

    I started working as a routesetter at rock climbing gyms for almost 2 years, but things were not going so well. I knew I was in need of a big change.

    I had been putting off learning to code for a long time, but I knew this was what I wanted to do. Finally, on my birthday in 2016, I committed to learning to code. I didn’t look back.

    At this point in time, I was vaguely familiar with the coding bootcamps that have become quite ubiquitous over the last few years. Luckily, I quickly discovered freeCodeCamp. When I realized that finishing their curriculum entailed writing software for non-profit organizations, I promptly joined and resolved that I would finish freeCodeCamp’s open-source curriculum before even considering a bootcamp.

    freeCodeCamp rapidly became the core of my education. I supplemented it with many other resources, such as podcasts, tutorials, open-courseware, and healthy doses of documentation and Stack Overflow when needed.

    Typical days involved me working through freeCodeCamp challenges and projects, which allowed me to progressively improve my skills.

    When sitting and writing code became unproductive, I would absorb material through other channels: audio, video, and so on. I moved back and forth between different learning methods, which was very useful in maintaining a strong level of engagement and focus. This was basically my process, and it allowed me to dedicate many hours to learning.

    Here it is by the numbers (roughly estimated):

    Total duration learning: less than 12 months
    Total hours: ~2,500
    Total projects completed: 70+
    Total CS courses watched: ~10
    Total GitHub commits: 1,500+
    Total lines of JavaScript written: 20,000+

    Most of this learning took place in Knoxville, Tennessee, where I was living at the time. I had a strong desire to move to one of the major tech cities, so one day I woke up and naturally decided it was time to drive to San Francisco. That’s about exactly how it happened.

    That night I left, and about 3 weeks later arrived in the Bay Area. Plenty of time to listen to podcasts on the road.

    Arriving in San Francisco for my first real job search

    After arriving in San Francisco and completing the core freeCodeCamp curriculum (front-end, data visualization, and back-end certifications) I had a brief go at job applications. Around 65 or so. Literally no response.

    Remember, I had just driven into the Bay Area from across the country. I had no idea how competitive it would be, nor how much my skills were even worth to employers at their current level. Did freeCodeCamp actually measure up to the education of an in-person coding bootcamp?

    These feeler applications gave me a clear reading: I had to do more. The market is pretty competitive. So I rapidly revised my plans, extended my time horizon, and reached out to freeCodeCamp to begin a non-profit project, since I was now eligible to start one.

    Meanwhile, I began networking in the city as much as possible. The networking came easily enough, as freeCodeCamp has many self-organized campsites throughout the world’s cities.

    I got a quick response from freeCodeCamp’s team about the nonprofit projects. Some of my React projects had caught the eye of Michael D. Johnson and Quincy Larson, and they asked me whether I’d be interested in helping write their React curriculum. (freeCodeCamp itself is a nonprofit.) I also helped build a conference management tool for the Conference on Crimes Against Women.

    I was very excited about the opportunity to give back to this awesome community, so I quickly accepted the challenge. My React and Redux challenges are being incorporated into their newly expanded curriculum, which is now live in beta form live here.

    In addition, I chose to advance my timeline to 2017. I would continue studying on my own for the remainder of 2016 before applying for jobs again. I left San Francisco, droving north through Portland and Seattle to Bellingham, Washington.

    It was during these weeks in the Pacific Northwest that I worked non-stop to complete the React and Redux challenges. I collaborated with another freeCodeCamp contributor from New York, Peter Weinberg, and built around 80 coding challenges in total.

    This was probably one of the key moves that helped set my resume apart, because it represented a significant project that served a real-world organization’s needs.

    In late December, we finished the initial draft of the challenges and moved them into an official alpha release which is still generating feedback from the community.

    My triumphant return to San Francisco

    Back in San Francisco, I was almost ready to dive into job applications again. I had decided to join Outco, a crash course in interview preparation for software engineers. I had always been pretty opposed to spending money at a coding bootcamp (partly because I didn’t have the money), but I chose to join Outco because in my view they are trying to serve a different purpose. Outco is specifically targeting the interview process for software engineers, a process which causes friction for many, even experienced and skilled engineers.

    Although I could write JavaScript pretty well at this point, I definitely was not prepared to solve arbitrary algorithm questions on a whiteboard. That’s one of the key areas Outco tries to prepare students for, because, for better or worse, whiteboarding remains a favorite interview tactic of tech companies. In addition, I could defer payment to Outco until after I got a job.

    And, a reality check: I had been going many months now at a strong pace of probably 50+ hours a week of coding and learning, and I was now literally risking it all on my ability to get a job in one of the most expensive and competitive cities in the US.

    I had already made a sincere effort to apply to companies and failed miserably! The pressure and stress were definitely bearing down on me at this point.

    I knew success was going to depend heavily on my performance of the next few months. I joined Outco because I expected that their structured program and support would prove indispensable in this last miles of my journey, and it did.

    2017 arrived and I started Outco. I began to work even harder than before. Tons of algorithms and data structures practice, whiteboarding questions, technical questions, pair programming, mock phone screens, systems-design questions—you name it, and lots of it. Not to mention applying to jobs again, and a lot more than I did the first time.

    And, of course, once you begin to get responses from companies it becomes very time-consuming (not to mention very stressful) to begin juggling all of these interviews at once.

    Practicing for interviews everyday is hard enough. Standing in front of a whiteboard in a real interview as they ask you about binary trees is much harder (and yes, interviewers asked me about binary trees).

    Again, the numbers tell the story more eloquently:

    Total applications: 192 (including the 65 from 2016)
    Total phone interviews: 17
    Total take-home code challenges: 6
    Total technical screens: 5
    Total onsites: 3
    Total offers: 1
    Total time to offer: 6 weeks
    Success Rate: 0.52%

    That one offer was from TruSTAR Technology, and I have been so happy to join their team! TruSTAR is building a platform that allows companies to share cyberintelligence data in order to prevent and mitigate cyberattacks.

    I’m working on the frontend side of their application and putting to use the JavaScript skills I gained through freeCodeCamp. The experience has been incredible so far, and I have been honestly surprised by how well prepared I have been to begin making meaningful contributions to their codebase.

    Lessons I learned over the past 12 months

    Now, finally, here is some advice I would have for anyone looking to do something like this:

    You need real-world skills and you have to learn a lot. That means a lot of hours of work, there’s no way around it. Passion helps.

    Building projects is an excellent way to learn, and once you know enough it is not very hard to find open-source projects or other high impact projects to work on.

    JavaScript and React are great to learn and in high demand! But learn what interests you.

    It’s critical that you cultivate a community of others who are learning to code or working as engineers. Network in your city. Network online. Find collaborative projects to work on. Ask for help.

    If you can afford it, try to have some patience. This is what I struggled with the most.

    There you have it — the journey that led me across the US to begin a career as a software engineer! I’m sure everyone’s path will look different, that’s part of the fun.

    Find your own path and don’t be afraid to disregard other people’s views if you believe strongly enough in your own. That includes my views.

    The opportunities in the tech industry are real, and if you want them badly enough, you can find a way there.

    As an engineer, your job will be to solve problems, and if you are self-taught, the first problem you must solve is how do you teach yourself?

    Cheers everyone, and happy coding!

    P.S. A huge shoutout and thank you to the entire freeCodeCamp community and everyone I mentioned in this article (and a few others: Archie, Christian, Susan, Beemer Girl and all my friends from home). You have all proven invaluable in helping me accomplish this goal.

  • 00:25:31

    Ep. 34 - d'Oh My Zsh

    The freeCodeCamp Podcast starstarstarstarstar

    In this episode, Oh My Zsh founder Robby Russell tells the story of how he unexpectedly launched one of the most popular zsh configuration frameworks out there. He shares his process, some mean tweets, and his advice for people starting open source projects.

    Written and read by Robby Russell: https://twitter.com/robbyrussell

    Original article: https://fcc.im/2HzyjYN

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    How I unexpectedly built a monster of an open source project

    It was the summer of 2009. I found myself helping a coworker debug something in their terminal. As I attempted to type in a few command lines, I noticed that the prompt wasn’t responding to the shortcuts that my brain had grown accustomed to. Frustrated, I exclaimed, “when are you finally going to switch over to Zsh?!”

    (yeah, I was the type of annoying coworker that would constantly point out that X was better than Y when given the chance. In hindsight, I don’t know how they put up with me…but between you and me, I had a point.)

    At that point in time, I had been a daily Zsh user for a little over three years.

    Some of my #caboose friends shared a few of their .zshrc configurations within our IRC channel. After a few years, my .zshrc file grew into a tangled rat's nest. Honestly, I didn’t know what ~30% of the configuration did. I trusted my friends enough to run with it, though. What I did know was that I had some git branch and status details, color highlighting for a few tools (i.e., grep), autocompleting file paths over SSH connections, and a handful of shortcuts for Rake and Capistrano. Working on a machine with a default Bash profile felt remarkably archaic; I’d become dependent on these shortcuts.

    A few coworkers were happy to copy/paste the .zshrc file that I shared and begin using it. A few others wouldn’t because they knew that I didn’t know what some of it did. Fair enough.

    After a few attempts to convert them and getting nowhere, I opted for a different approach.

    First, I reorganized my .zshrc configuration, which involved breaking it up into a collection of smaller files. My thinking here was that this would a) help me better understand how all of these bits worked while b) helping educate my peers when they went to read the code.

    Pre-empting their next question, “how do I get this to work on my machine?”, I drafted the first setup instructions.

    Most importantly, I packaged all these files into a shiny new git repository. I figured that if I tossed it up on Github, my peers would be able to collaborate with me on improving it.

    While not a huge leap, it was a step above inviting people to copy/paste a text file from Pastie.

    On Aug. 28th, 2009, Oh My Zsh was born.

    …but, wait a minute!! Where are the themes? Where are the plugins? Installation scripts? Logo?

    This might come to a surprise to most of the Oh My Zsh user base, but none of those were features that I had considered. My goal with the project was not to build a framework for maintaining Zsh configurations but to share my own config with my coworkers so that they’d use Zsh.

    Within a day of sharing it with all of my coworkers, everyone at Planet Argon had migrated from Bash to Zsh.

    Victory! …or so I thought.

    The first feature request came in the next day.

    “How do I customize MY prompt?”

    Two coworkers asked me how they could customize their prompt. They wanted to change the colors and the information that was displayed.

    What the hell!? Wasn’t my prompt compelling enough for them? So nitpicky. ;-)

    I pointed to the prompt.zsh file and said they could modify that.

    Quickly, this became an issue as they now had their own version of that file. As a result, this would add some complexity if we all wanted to share some of our shortcuts and features as we’d have conflicts to deal with.


    So, a day after first announcing Oh My Zsh on my blog, I began introducing the initial concept of themes.

    Meanwhile, I got my first external pull-request from Geoff Garside to add a few aliases for TextMate. (Notice how that went straight into a catch-all aliases.zsh file)

    A day later, another theme was sent over. Groovy, I better add a link on the README to see some screenshots on the wiki.

    Within a month, we had a dozen themes contributed to the project.

    This began to be a really popular aspect to Oh My Zsh and we had to start hitting the brakes on accepting themes once we passed 100. (we’re currently at ~140 and rarely accept new ones)

    Simplifying setup with an installer

    It occurred to me that the initial setup was requiring people to run a handful of commands. Rather than asking people to re-type and/or copy/paste a handful of commands, I felt that it would be more efficient for both parties (as it’d reduce the questions my coworkers would have when they hit a problem and/or skipped a step).

    An installer was born.

    My initial thoughts were to handle save folks a few steps by automating the installer. If everyone ran the same commands, then we could cut down on human error (skipping a command, typos, etc.). I also wanted to be mindful that people might be switching from either Bash or an existing cobbled-together Zsh configuration. To help them with a possible switch back to the previous shell, we made a backup of their original configuration file. Finally, we’d switch their default shell to Zsh.

    “Hooray! Oh My Zsh has been installed.”

    Oh, right. How will people be able to stay updated with the new changes to the project?

    The next day, I added an upgrade script that strolls over to the Oh My Zsh directory, fetch updates from the git repository, and returns you to your previous working directory.

    Far from rocket science.

    About three weeks later, it became obvious that my coworkers weren’t manually keeping up with all of the new updates to the project. Rather than reminding them to do that from time-to-time, I added functionality that would periodically prompt the user to check for updates.

    Up until this point, this felt like the most complicated piece of code in the project. I wish that I could remember who gave me the great idea to use an epoch value here.

    In my opinion, it was also the turning point for the project.

    While a handful of people were using it, this functionality would allow nearly every user to stay up-to-date on project changes and more importantly, stay engaged. When they would run the updater, they’d see a list of files changed and that would, subtly, introduce them to new features… a la, “I wonder what that theme looks like..”

    Sadly, not everyone has been a fan.

    Despite a few vocal opponents over the years, I’ve stood by my decision to keep this as a default setting.

    Back in 2012, we made a change to reduce the frequency of auto-update prompts by 50%.

    The auto-update has allowed us to ship new features, performance improvements, and bug fixes without relying on everyone manually doing it. I’m convinced that this feature has helped keep the community engaged.

    This Muffin Needs Candy

    While the project was attracting a lot of themes, I really felt like the project could benefit from branding.

    My solution? Ascii art.

    I have no idea what prompted the git commit message.

    My thought process here was… sure, you get a bunch of useful shortcuts and themes when you begin using Oh My Zsh, but I really felt like the first impression after the installer would run was an opportunity to delight new users.

    People have been asking me to print shirts with the ascii art for quite some time. (we’ll likely do that this summer — follow us on twitter)


    Ten months after open sourcing the project, users had begun to request the ability to not have everything get loaded up. For example, a Python developer might not need the Rake and Capistrano related aliases to get loaded like a Ruby developer would.

    So, we implemented a basic plugin system that would allow folks to decide which to load on initialization by changing a value in .zshrc.

    When this feature was released, there were five plugins bundled.

    Within a few months, I started to get pull requests for new plugin ideas.

    Within a year, I had accepted over 40 plugins.

    Within two years? Over 70 plugins.

    Currently, we have plugins for adb, ant, apache2-macports, archlinux, autoenv, autojump, autopep8, aws, battery, bbedit, bgnotify, boot2docker, bower, branch, brew, brew-cask, bundler, bwana, cabal, cake, cakephp3, capistrano, cask, catimg, celery, chruby, chucknorris, cloudapp, codeclimate, coffee, colemak, colored-man-pages, colorize, command-not-found, common-aliases, compleat, composer, copydir, copyfile, cp, cpanm, debian, dircycle, dirhistory, dirpersist, django, dnf, docker, docker-compose, emacs, ember-cli, emoji, emoji-clock, emotty, encode64, extract, fabric, fancy-ctrl-z, fasd, fastfile, fbterm, fedora, forklift, frontend-search, gas, gem, git, git-extras, git-flow, git-flow-avh, git-hubflow, git-prompt, git-remote-branch, gitfast, github, gitignore, glassfish, gnu-utils, go, golang, gpg-agent, gradle, grails, grunt, gulp, heroku, history, history-substring-search, httpie, iwhois, jake-node, jhbuild, jira, jruby, jsontools, jump, kate, kitchen, knife, knife_ssh, laravel, laravel4, laravel5, last-working-dir, lein, lighthouse, lol, macports, man, marked2, mercurial, meteor, mix, mix-fast, mosh, mvn, mysql-macports, n98-magerun, nanoc, nmap, node, npm, nvm, nyan, osx, pass, paver, pep8, per-directory-history, perl, phing, pip, pj, pod, postgres, pow, powder, powify, profiles, pyenv, pylint, python, rails, rake, rake-fast, rand-quote, rbenv, rbfu, rebar, redis-cli, repo, rsync, ruby, rvm, safe-paste, sbt, scala, scd, screen, scw, sfffe, singlechar, spring, sprunge, ssh-agent, stack, sublime, sudo, supervisor, suse, svn, svn-fast-info, symfony, symfony2, systemadmin, systemd, taskwarrior, terminalapp, terminitor, terraform, textastic, textmate, thefuck, themes, thor, tmux, tmux-cssh, tmuxinator, torrent, tugboat, ubuntu, urltools, vagrant, vault, vi-mode, vim-interaction, virtualenv, virtualenvwrapper, vundle, wakeonlan, wd, web-search, wp-cli, xcode, yii, yii2, yum, z, zeus, zsh-navigation-tools, zsh_reload.

    In total… 214 plugins. Admittedly, not everyone has been impressed by this.

    I do agree that could be drastically improved.

    The few times that I considered it, I found the proposed approaches to be too complicated for folks who aren’t yet familiar and/or comfortable with the terminal. Perhaps a more sophisticated approach for version 2 of the framework. (more on this later)

    There has, also, been a part of me that has felt like this project would only be of interest to people for a few years. As users gained more experience and/or as technology evolved, the framework would be left behind by shiny new projects that solved problems far better than we had.

    I never thought Oh My Zsh would still be building momentum nearly seven years later.

    Where do all these new users keep coming from? I ❤ you people!

    While I have many stories to share (and intend to write more on this topic), I wanted to speak to those who have been debating the idea of open sourcing a project.

    Eight Considerations For Your Open Source Project

    Don’t start with a wildly ambitious goal. Start your project with a simple, attainable goal. What does success look like? In my scenario, I wanted 1–2 people on my team to use my scripts. The project was a success in under 24 hours.

    Everything since has been extra-credit.

    Don’t try to account for every scenario. If I had gotten hung up on some long-term details for the project, Oh My Zsh would never have happened. Nearly everything that has been added to the project has come organically post-initial release.

    One of the beautiful aspects of an open source project is that your user base can help shape it.

    Don’t try to make it perfect. Worrying how other people are going to react about your code shouldn’t be your biggest concern. Does it work? How do they feel when they’re interacting with it should be a higher concern. In my case, I’ve had some great contributors over the years who have helped tidy up and improve the quality of the code that I originally released.

    Rarely has anyone said anything critical about my old code — maybe they should have, though. ;-)

    Don’t try to be everything to everyone. There have been a few points in the history of the project where we hit a crossroads. In particular, there was a time when a huge rebuild was proposed, which I was quite excited about until I was able to wrap my head around some of the changes.

    As a result, a fork was rebranded and we agreed to follow different paths. Not everyone was happy with my decision here, but it was during this period that it became clear (to me) that I wanted to focus my attention on folks who weren’t too comfortable with the terminal and/or git.

    Don’t stop thanking contributors. If anybody helps your project out, please let them know how much you appreciate their effort. I can’t thank my contributors enough. One of my biggest self-critiques related to this project is that I’ve not been consistent enough in being vocal about my appreciation.

    There are 910 people from all over the world who have their code accepted into the master branch of Oh My Zsh at the time of writing this.

    It’s such a long list that Github can’t even list them all.

    In particular, thank you. (you know who you are)

    Don’t forget the documentation. Over the years, documentation of plugins and functionality has been vital to helping inform users on how to take advantage of the framework.

    I wish we had adopted this convention several years before.

    The README file is going to be seen the most…so make it count. In my case, I opted to introduce people to my personality and dry sense of humor.

    Honestly, seeing tweets like this means the world to me.

    Don’t forget about the rest of your life. Again, I never anticipated the project turning into what it is today.

    Are you familiar with the anecdote about the frog in a pot of boiling water?

    It took me 3–4 years, too many, to finally bring in another person to help maintain the project. I kept thinking that I could catch up with all the open pull requests and issues. What I kept telling myself was that folks who know how to fork the project can make their desired changes and work off of that, so reviewing and approving pull requests is a nice-to-happen versus a need-to-happen.

    In practice, it’s somewhere in between. I do feel a bit bad for old pull requests lingering, but I also don’t keep Oh My Zsh as one of the top few projects on my plate.

    Outside of Oh My Zsh, I run a 19-person agency, play guitar in an instrumental post-rock band, sit on the board of directors of a local homeless shelter non-profit, travel with my camera a lot, ride my motorcycle, ride my bicycle, and try to keep a social life with my friends. Oh My Zsh fits somewhere in amongst all of these.

    It’s not at the top of my priority list. It’s not at the bottom. It’s somewhere between. This isn’t an excuse to not being able to keep up with the community, but more of a reminder that those other things should matter to you, too, if you’re about to start your own project.

    (I will write more on the topic of leading an open source project w/maintainers in another story… ❤ are you following me? ❤)
    Don’t forget to have some fun. When you start your project, decide if this is going to be serious work time or play time. Perhaps it can be somewhere in the middle.

    Oh My Zsh has, always, been a play time activity project for me.

    Knowing that one of my playful projects has been and continues to be enjoyed by people is such a wonderful feeling.

    Some might call it a passion project. I call it playtime.

    Interested in my fun open source project?

    You can learn more at http://ohmyz.sh.

  • 00:10:08

    Ep. 33 - Code dependencies are the devil

    The freeCodeCamp Podcast starstarstarstarstar

    Have you built your app on someone else's code? And beyond that, does the "secret sauce" of your product depend on external libraries or frameworks? While it's tempting to use the latest and greatest tech as soon as it comes out, that's not always a great idea. In this episode, Bill explains why, and what to do to protect your code.

    Written by Bill Sourour: https://twitter.com/BillSourour

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2HerXO5

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    “Change is the only constant…” – Heraclitus (Philosopher)

    The tools, libraries, and frameworks we use to build our web applications today are drastically different from the ones we used just a few short years ago.

    In a few short years from now, most of these technologies will have changed dramatically again. Yet, many of us make these a central, inextricable part of our apps.

    We import, use, and inherit from the flavor-of-the-month frameworks as if they’re all going to be around and unchanged forever. Well… they’re not. And that’s a problem.

    After 20+ years of developing, designing, and architecting web applications, I’ve come to appreciate two important truths:

    External dependencies pose a great threat to the long term stability and viability of any application.

    It’s increasingly difficult — if not impossible — to build any kind of non-trivial app without leveraging external dependencies.

    This article is about reconciling these two truths so that our apps have the greatest chance of long-term survival.

    The rabbit hole is very deep indeed.

    If we start thinking of all the things our web apps depend upon it’s easy to think of a dozen or more before we even get to the code:

    Server Hardware (CPU, Disk, Ram, …)
    Virtualization Platform
    Container Platform
    Operating System
    Web Server Platform
    App Server Platform
    Web Browser

    As developers, it’s good to be aware of these things, but there’s often not much we can do about them. So, let’s ignore them for now and talk only about the code.

    In code, there are three kinds of dependencies:

    1. Dependencies we control
    This is code written and owned by us or our organization.

    2. Dependencies we don’t control
    This is code written by a third party vendor or open-source software community.

    3. Dependencies once removed
    These are the code dependencies our third-party code dependencies depend upon. (Say that three times fast!)

    We’re going to talk mainly about dependencies we don’t control.

    Dependencies we control and dependencies once removed can still cause headaches, but in the case of dependencies we control, we should be able to directly intervene and mitigate any problems.

    In the case of dependencies once removed, we can usually rely on a third-party to take care of it for us, since they are dependent on these, too.

    Why third-party code dependencies are good

    A large portion of your web application exists to solve common problems: authentication, authorization, data access, error handling, navigation, logging, encryption, displaying a list of items, validating form inputs, and so on...

    Regardless of which technology stack you use, there’s a good chance that common solutions to these problems exist, and are available as libraries that you can easily acquire and plug-in to your codebase. Writing any of this stuff completely from scratch is generally a waste of time.

    You want to concentrate on code that either solves an uncommon problem or solves a common problem in an uncommon way. That’s what makes your application valuable: the code that implements the business rules that are unique to your app alone — the “secret sauce.”

    Google’s search and page ranking algorithm, Facebook’s timeline filtering, Netflix’s “recommended for you” section and data compression algorithms— the code behind all of these features is “secret sauce.”

    Third-party code — in the form of libraries — allows you to quickly implement those commoditized features of your app, so you can stay focused on your “secret sauce.”

    Why third-party code dependencies are bad

    Take a look at any non-trivial web-app built in the last couple of years and you’ll be absolutely astounded by the amount of code that actually comes from a third-party library. What if one or more of those third-party libraries changes drastically, or disappears, or breaks?

    If it’s open-source, perhaps you can fix it yourself. But how well do you understand all the code in that library you don’t own? A big reason why you use a library in the first place is to get the benefits of the code without having to worry about all the details. But now you’re stuck. You’ve completely tied your fortune to these dependencies that you don’t own and don’t control.

    Perhaps you think I’m exaggerating, or speaking from a purely academic point of view. Let me assure you — I have dozens of examples of clients who completely snookered themselves by embedding third-party code too tightly into their app. Here‘s just one recent example…

    A former client of mine built their app using a Backend-as-a-Service provider owned by Facebook, called Parse. They used a JavaScript client library provided by Parse to consume the Parse service. In the process, they tightly coupled all of their code — including the “secret sauce” code — to this library.

    Three months after my client’s initial product launch — just as they started getting some good traction with real, paying customers — Parse announced it was shutting down.

    Now instead of focusing on iterating on their product and growing their customer base, my client had to figure out how to either migrate to a self-hosted, open-source version of Parse, or replace Parse completely.

    The disruption this caused for a young, fledgling application was so huge that my client eventually scrapped the app entirely.

    Balancing the good and the bad

    Several years ago, my go-to solution for overcoming the risks while retaining the benefits of third-party-libraries was to wrap them using the Adapter Pattern.

    Essentially, you wrap the third party code in an adapter class or module that you’ve written. This then works to expose the functions of the third party libraries in a manner that you control.

    Using this pattern, if a third-party library or framework changes, or goes away, you only have to fix a bit of adapter code. The rest of your app stays intact.

    This sounds good on paper. When you have self-contained dependencies that only provide a few functions, this will do the trick. But things can get ugly fast.

    Can you imagine having to wrap the entire React library (including JSX) before using any of it? How about wrapping jQuery, or Angular, or the Spring framework in Java? This quickly becomes a nightmare.

    These days I recommend a more nuanced approach…

    For each dependency you want to add to your codebase, evaluate the level of risk it will introduce by multiplying two factors:

    The likelihood that the dependency will change in a material way.

    The amount of damage a material change to the dependency would do to your application.

    A third-party library or framework is less likely to change when some or all of the following things are true:

    It has been around for several years and has had several major releases.

    It is widely used by many commercial applications.

    It has the active support of a large organization — preferably a household name company or institution.

    A third-party library or framework will do less damage to your application when some or all of the following things are true:

    It’s only used by a small portion of your application, rather than being used throughout.

    The code that depends upon it is not part of that “secret sauce” I talked about earlier.

    Removing it requires minimal changes to your codebase.

    Your entire application is very small and can be rewritten quickly. (Be careful with this one — it’s rarely true for very long.)
    The riskier something is, the more likely you should be to wrap it or avoid it altogether.

    When it comes to the code that is really central to the value proposition of your application —your “secret sauce” — you need to be extremely protective of it. Make that code as independent as possible. If you absolutely need to use a dependency, consider injecting it rather than directly referencing it. Even then, be careful.

    Sometimes this means saying “no” to a third-party library you think is really cool, or that you really want to use for one reason or another. Be strong. Trust me, it will pay off. Just ask all those people who invested heavily in the very first release of Angular, or my former client who used Parse everywhere. It’s no fun. Believe me.

    Speaking of fun, take a look at this…

    The image above is the dependency graph for an application called TinyTag Explorer.

    Generating a dependency graph for your existing apps is a great way to understand the level of risk being introduced by your dependencies. I’ve put together a list of free tools for generating graphs similar to the above in a variety of languages including JavaScript, C#, Java, PHP, and Python. You can get it here.

    Help me help others

    I want to help as many developers as I can by sharing my knowledge and experience with them. Please help me by clicking the ❤ recommend button (green heart) below.

    Finally, don’t forget to grab your list of free dependency graph generators here (link in original article).

  • 00:43:37

    Ep. 32 - How you can start a career in a different field without experience

    The freeCodeCamp Podcast starstarstarstarstar

    Austin had a biology degree, a poor GPA, and a job in the medical field, but he wanted to transition into tech. He had no experience, but he figured out how to gain it quickly and landed offers from his dream companies. In this episode, he shares his advice and methods so that you can do the same.

    Written and read by Austin Belcak: https://cultivatedculture.com

    Original article: https://fcc.im/2LydTlZ

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    In this episode I’ll show you how to quickly gain experience in any field, as well as how you can leverage that new experience to land job offers in that field.

    I personally used this strategy to transition from the medical field — where I was working in hospital operating rooms — to the tech industry, where I received offers from Google and other tech companies (along with a 200% raise).

    Myths about things you DON’T need when switching fields

    Before we dive in, I think it’s important to address a few “myths” about changing industries:

    You don’t need an extensive network of contacts. In fact, you don’t need any contacts at all — you can make them all on your own.

    You don’t need a degree in the field you want to switch to. Perception is reality, and results speak volumes when it comes to perception.
    They are worth more than any degree or previous job title. More on that later.

    You don’t need money. Everything you need to know can be learned for free. In fact, I’m going to show you how this process can actually help you generate a second stream of income.

    Next, I’m going to outline the exact steps I used to land a job in a totally different industry so you can make it happen for yourself.

    Part 1: Painting a picture of the perfect candidate

    The good news about entering a completely different field is that you are a blank canvas. You can choose your skills and mold yourself into the perfect candidate.

    What does perfection look like?

    In order to become the ideal candidate, we must first understand what “ideal” looks like in the eyes of the people who will be hiring you. There are two ways to accomplish this:

    Job descriptions

    Job descriptions are essentially resumes in reverse. They spell out the exact skills you need in order to be successful in that particular role. That sounds obvious, but we are going to be looking at this from an atypical lens.

    Let’s take a look at this Growth Marketing Analyst role that I grabbed from Facebook’s site:


    - Leverage data to understand our products in depth, identify areas of opportunity, and execute projects to drive growth and engagement of Facebook users.
    - Drive projects focusing on new user growth, mobile usage, and revenue — working closely with design, product, engineering, and data teams.
    - Work both on core Facebook products like news feed, notifications, and mobile, and offsite marketing channels like SEO, SEM, and email.
    - Use tools like Hadoop/Hive, Oracle, ETL, R, PHP, Python, Excel, MicroStrategy, and many other internal tools to work efficiently at scale.

    Minimum Qualifications

    - BS or MS in Engineering, Computer Science, Math, Physics, Statistics.
    - 1+ years experience with SQL.
    - 2+ years of quantitative or statistical analysis experience.
    - 1+ years of experience managing a project.
    - 1+ years of experience in marketing, advertising or growth.
    - Ability to process and analyze data sets, and interpret them to make business decisions.
    - Communication skills and ability to manage a project or product.

    Preferred Qualifications

    - Software development experience.
    - Internet Marketing experience.
    What do you see here? What does the ideal candidate look like? What do they need to get hired?

    My guess is that you’re thinking, “Ok, they need a degree in computers or math. Then they need at least two years of experience coding and managing projects at a company.”

    Well, here’s what I see:

    Facebook is looking for someone who understands how to identify trends/patterns within big data that will have a direct impact on revenue. That person also has enough knowledge of programming to efficiently make those discoveries and present them in a simple, concise fashion.

    The main issue a lot of people have is that they think the only way to get “experience” is to work at company or have fancy degrees. This is one of the biggest myths when it comes to job searching.

    In order to understand it, let’s take a step back and think about why companies hire.

    They want someone who will come in and have a large, positive impact on their bottom line.

    Someone could have a PhD in Computer Science and be fluent in all of the programming languages mentioned above, but if they lack the ability to clearly convey results, the company isn’t going to benefit.

    On the other hand, someone who may not have a degree or total fluency but understands how to find impactful insights and presents them in a concise, actionable manner is extremely valuable.

    Your goal is to become that second person.

    Informational interviews

    In addition to combing through job descriptions, it’s equally important to get in touch with people who work in the industry.

    They will be able to help you prioritize the skills you found in those job applications, as well as give you some inside info on the intangibles (nuances of the hiring process, putting you in touch with their contacts, etc.).

    I’ve found that the best way to make this happen is by leveraging LinkedIn’s advanced search filters.

    You can search for people at specific companies, with specific titles. If you have LinkedIn Premium, you can even search for people who used to work in your industry and now work in your target industry — or even at your target company.

    Then you can use this email script to reach out:

    Subject: Quick Question

    Hi [Name],

    My name is Austin and I currently work at Cultivated Culture. I was browsing through LinkedIn and came across your information — I hope you don’t mind me reaching out of the blue here.

    I saw that you have extensive experience in Facebook’s Growth Analytics vertical and I’m very interested in learning more about that space. I would love to have the opportunity to run some questions by you, as well as tap into any advice you may have given your knowledge of the industry.

    I know that your time is extremely valuable so please don’t feel to need to respond in depth. If you do have 5 minutes to chat, I would really appreciate it.



    When they agree to a meeting, you’ll want to prepare some questions. They should focus on:

    Identifying which skills are the most crucial for performing daily activities (this will allow you to prioritize)

    Providing some background on how that person got to where they are (you’d be surprised at how many people came from other industries)

    What they would do if they were in your shoes — trying to get this job with little to no experience in the field

    Here are those bullets in question form to help get you started:

    I’ve been doing some research and it seems like [Skill 1] — [Skill 3] are common in the space. Which of these do you think is the most crucial to success?

    I was looking through your LinkedIn and saw that you came from [Previous Role/Company]. How did you initially get involved in this industry and how did you end up at [Current Role]?

    Let’s say you were in my shoes — you’re new to the industry and don’t have too much experience. How would you go about getting your current job? What specific steps would you take?

    Bringing It All Together

    Now you have an understanding of the skills that you need, where they stand in terms of priority, and a roadmap from someone who has/had the role you want.

    Next, you need to build a foundation with those skills and use them to generate results that directly align with the company’s goals for that role.

    Part 2: Nailing The Basics (On The Cheap)

    Over the next month or two we’re going to focus on building a rock solid understanding of the basics needed for the skills you identified above.

    For now, the best ways to do this are by reading books, taking courses, and creating a sandbox you can use to test your knew knowledge.

    Reading Up (For Free)

    Books are a fantastic way to understand the basic concepts of a specific subject. They also happen to be very easy to get for free.

    Remember that public library your parents wanted you to check out when you were a kid? It’s actually still there! Amazing, right?

    The good news for you is that even public libraries have caught up with the times and now carry ebooks. You can borrow them for free like any other book, but they will be sent directly to your phone so you can read them anywhere, anytime. All you need to do is install the Kindle app (which you can get for free for iOS and Android).

    In order figure out which books to read, I would Google “best books on [subject]” or go ask some folks on Quora.

    Taking Courses (For Free-ish)

    While books are giving you the 30,000 foot view of your topics, courses will help you figure out the nitty gritty. They are a better way to learn the actual skills because they tend to be interactive and are updated regularly.

    One of the best resources for our purposes is Coursera. Coursera aggregates courses from the best professors at the best schools in the country (I’m talking Princeton, Stanford, Harvard — they don’t mess around).

    These courses are fantastic because they are structured like an actual course you would take in college. They have videos, but they also have tests, projects, and forums where students can collaborate. This is key because it helps make the course “sticky” due to the fact that you are committing to all the above rather than just watching a few videos.

    Best of all, at the end of the course, you can receive a certificate stating that you passed the course. It will even have the seal from that university on it! It does cost ~$49 but it’s well worth it because you can put that right on your resume:

    Subscribing To Industry Blogs & Newsletters

    Next, you’re going to want to sign up for some newsletters.

    Blogs stay in business by having the highest quality, most up-to-date information and getting it out there as quickly as possible. This is the easiest way for you to stay on top of current events in the industry while picking up tons of knowledge along the way.

    You can find them using the same method you used to find the books — Googling and hitting up Quora.

    Additionally, try to find a niche blog as they tend to have highly detailed information on your topic. Here are some examples:

    SEO: The 10 Chapter Beginner’s Guide To SEO

    Content Marketing: The Advanced Guide To Content Marketing

    Facebook Ads: The Ultimate Guide To Making Money With Facebook Ads

    Free Resources (Where Applicable)

    Many industries and fields have a ton of free resources out there to help your learn. For example, if you’re an analytics person — Google Analytics is completely free to set up. Additionally, Google offers an entire course on the platform for free.

    If your plan is to break into the development field, you’re already in the right place. Free Code Camp is one of many great resources that will help you learn the basics of programming for free.

    Be sure to do a thorough search on your industry. Chances are good that free training resources exist.

    Bonus Pro Tip: Google Alerts

    Google Alerts are an awesome way to save yourself hours that you would have spent searching for articles on specific topics or companies.

    You can set them up for anything that you could feasibly search for in Google, but probably want to stick with the salient points like a specific industry, certain skills, the company you want to work for and Beyonce.

    Then, every day, Google will crawl the web and find the most relevant (and worthy) articles on your specific subjects and deliver them straight to your inbox.

    You can sign up for Google alerts here.

    Part 3: Getting Paid To Hone Your Skills

    Yup, you read that right. We’re going learn how to have someone pay you to learn the skills you need to change industries.

    Building Credibility & Real-World Results

    Now that you understand the basics of these skills, it’s time to really develop them.

    I’ve found that the best way to truly learn something is by doing it. I can’t think of a better way of “doing” than selling your skills for some cold hard cash.

    Rapidly Develop Your Skills By Freelancing

    While it may seem like a daunting task, it’s fairly easy to get started in the freelance world even if you have no prior “experience.”

    As Tim Ferriss says, the definition of an expert is someone who knows more than the person they are dealing with.

    There are two ways of going about finding clients when you’re starting out — freelance aggregator sites and traditional cold outreach:

    Upwork (A Freelance Aggregator)

    Upwork is a community where business owners come to find freelancers for everything under the sun.

    The beauty of Upwork is that it removes the need for you to invest a lot of time in marketing yourself. It is an inbound site meaning your services will show up to people who are already looking for that particular service, making them more likely to hire. That may also be attractive to someone who is uncomfortable with a traditional sales process.

    The trade off is that, while you save time, Upwork charges a hefty fee for saving you that time. For our purposes, that’s not too terrible because you’re mostly in it for the learning while the money is icing on the cake.

    I recommend using Upwork if you’re having trouble managing the sales process on your own, or if you’re just starting out and need to build up a few success stories.

    If you really want to expand your initial reach, check out Hubstaff’s comprehensive rundown of Upwork alternatives and get yourself on multiple platforms.

    Cold Outreach

    The second option, and the path that I recommend, is handling the sales process on your own. That way you get to keep 100% of the revenue and remove the middle man.

    This can be a bit tougher initially because those businesses may not be actively looking for your services and if you don’t have much sales experience, the learning curve can be steep.

    In this section we’ll through the steps that I used to land my initial clients, build success stories and then use those results to expand my portfolio (and increase my revenue).

    Define Your Niche

    Our first step on our freelancing journey is defining our target prospect. Most articles out there tell you that when you start a business your niche should be laser-focused, like Male Golfers, Ages 47–54 who suffer from back pain.

    While I agree that it should be targeted, it’s not reasonable to expect that you’re going to know your target audience in that level of detail before you’ve even worked with a single client.

    You’ll begin to hone in on your ideal niche as you go, but for now we’re going to use the following process to determine our target audience (actually, we’re going to choose 3).

    Defining Your Initial Target Prospect

    Start by making a list of 50 people that you know. It can include everyone from your best friend’s parents to a connection on LinkedIn you met at a conference last year. The only criteria they need to meet is that you must feel comfortable reaching out to that person.

    Add these people into this spreadsheet I created for you along with their company type and industry (ignore the email column for now, we’ll get to that later):

    Now that we have our people, let’s take a look at their company type and industry. Which industries and company types match up best with your knowledge and skill set?

    If we take my list, I know that my marketing skills could benefit a tech company, but they could also benefit a health & wellness startup looking to build an audience. Additionally, know that it’s much easier to sell into startups than corporations when you’re first starting out. With that in mind, my ideal mix is:

    Company Type: Startup

    Industry: Advertising, Tech, Web Development & Health/Wellness

    Now we have one “niche,” but my list here is only 10 people. I want you to try and find 3 different niches where one or more of your skills apply. Then I want you to assign each niche a number and label your spreadsheet (you can also highlight too if that helps):

    Awesome! You just defined 3 areas that you can sell into and you have your first set of prospects.

    Key Takeaway: Don’t get caught up in finding a super-specific niche before you’ve ever booked a client. Keep things broad, take on a few initial clients and your niche will narrow over time.

    Create Time & Be Consistent

    I have spent a lot of time reading about success. I’ve also spent a lot of time building businesses in hopes of chasing it. After sifting through the thousands of pages and lessons, I found that one thing had the greatest influence on whether I was successful or not:


    The ability to work on something every single day — regardless of how you feel, how crazy your job is or how many friends tell you to go to happy hour — is the difference between succeeding and failing when you start a business.

    In order to be consistent, you have to create time. Time that you know is not going to be interrupted. For me, that means waking up at 5:30am. For you, early may work, or maybe late at night is your thing. Whatever you do, make sure that it’s a natural fit for you. You don’t want to feel like you have to drag yourself to do this, otherwise it will never work.

    Put It In Your Calendar

    Start by opening up your Google calendar and finding a 1.5 hour block of time that works for you at least 5 days every week (yes, that includes weekends).

    Create an event and set reminders for 1 hour before and 15 minutes before. Mark that time as “busy” on your calendar:

    Hold Yourself Accountable

    Now it’s real — ink on paper. However, your calendar invite isn’t going to get you out of bed the day after you went out a little too hard or help you say no to those free concert tickets to see Kanye. If we truly want to stick with this, we’re going to need a little outside help.

    I personally recommend StickK because I’m a competitive person who doesn’t like losing. StickK basically lets you bet yourself that you will start your business.

    You put down a dollar amount (I recommend $100) and you set a goal. Then you’ll be assigned a “referee” who will hold you accountable. If you complete your goal, you get your $100 back. If you don’t, that money is donated to the charity of your choice.

    I can personally tell you that the thought of $100 being yanked out of my wallet has helped me push through many hangovers.

    Getting Your First Client

    Now that we’ve got our service and our niches nailed down, it’s time to get some paying customers.

    Since we don’t have much in the way of a portfolio, we’re going to want to start by aiming for a prospect where we have a personal connection. Then we’re going to leverage the current experience that you have to land the deal.

    Let’s head back to our spreadsheet and look through the list of names that we highlighted in each niche. I want you to go ahead and rank each of these people in the order of how likely they are to help you. Then we’re going to reach out to each from top to bottom.

    Finding Emails

    If you don’t already have their email, you can easily find it by using VoilaNorbert or FindAnyEmail.net. Once you have it, go ahead and plug it into your spreadsheet for future reference.

    Reaching Out

    Now we’re going to reach out to our contact and ask them if they can help us set up a meeting. Here is the exact email template you can use for that:

    Subject: Quick Question

    Hi [Name],

    Hope you’re doing well! I wanted to let you know about a business I’m starting up called [Company Name]. It’s aimed at helping companies [Insert Value Prop].

    Most recently we were able to [Insert Success Story]. I did a quick audit of [Prospect’s Company] and I have some ideas that I’d love to share with you. Could you help me get in touch with the correct person? Either way, would love to catch up soon!


    [Your Name]

    All you need to do is fill in their name, your skills and press send.

    I would also highly recommend getting an email tracker such as Hubspot (free) or Yesware (better, but costs $). These will allow you to see if your prospect read your message and help you determine whether or not to follow up.

    If they open your email once, that trail is dead. However, if they open it multiple times across multiple days, feel free to follow up with them after 4–5 business days. I have personally followed up with people 8–10 times before eventually getting a response that led to a deal.

    Preparing For The Meeting

    Once the meeting is set, we want to make a compelling case for why this company needs your services. The best way to do that is using what I like to call The Audit Technique.

    It’s extremely simple and effective:

    Carefully review our prospect’s current set up (website, social media, content, copy, health — whatever fits your service)

    Identify as many issues/improvements as we possibly can

    Determine the measurable impact of fixing these issues

    Share specific strategies for solving 2–3 of the issues and then showcase the potential result of fixing all of them

    Tell them that, regardless of whether or not they hire you, they can keep the audit report

    Boom! Easy.

    Closing The Deal

    In the beginning, most of your prospects aren’t going to be seeking you out. That means that you have to convince them that your services will be worth their time and money. The best way to do that is via the following framework:

    1. Address

    We’re going to start off the meeting by addressing the issues that you found with their site. Don’t be too critical. The goal here is to make them feel good about their business while also letting them know that there is a lot of untapped potential out there.

    Hand them your Audit Report and walk them through each of the issues. Explain what is happening, why it’s hurting their business, and what the solution is.

    2. Illustrate Potential

    Once you’ve explained the issues, you want to clarify what the prospect is missing out on. The more quantifiable this is, the better. For example:

    Your call to action on the site isn’t strong enough. Your conversion rate is probably 5% lower than where it should be. If your site gets 30,000 visitors a month, that’s 1,500 people we’re not capturing!

    Instagram accounts like yours typically see 100–300 followers every day, but you are only netting 20–30. If you implement the strategy I laid out here you should see an immediate boost within a few days. That could mean an additional 2,400 followers each month!

    Show them how this is impacting their bottom line. Walk them through the math:

    You: What is your typical sales conversion rate from your email list?

    Prospect: Hmmm, it’s around 3%

    You: Wow, that’s pretty good! And how much profit do you make from each sale?

    Prospect: Typically we net around $150 per sale.

    You: Awesome. Based on my audit, I’m seeing that we’re missing out capturing an additional 3–5% of your site’s traffic due to poor copy and CTA placement. I poked around and saw that your site gets ~30,000 visitors per month which means that we could be capturing an additional 1,500 people every month. Based on the numbers you just gave me, that’s $6,750 per month!

    If you charge $2,000 per month, that’s a no brainer for your prospect. Any business owner would pay $2,000 if they knew it would result in an incremental profit of $4,750 — and you just made $24k this year!

    Ask Them For The Sale

    Now that you’ve proven out the value — ask them for the sale:

    Tell them that the Audit Report is theirs to keep regardless

    Reiterate the potential opportunity they have to gain

    Outline what next steps look like for hiring you

    Ask them if they want to move forward

    Chances are good that they’ll want some time to think about it. No worries at all — drop note on your calendar to follow up with them 72 hours later.

    You just booked your first client!

    Now I want you to rinse and repeat this process for everyone on your spreadsheet. If you can get your foot in the door, you can expect about a 5%-10% close rate.

    Consolation: Offering Your Services For Free

    Since we’re mostly in this for the learning, this is great option to consider if the above process isn’t initially working out.

    I found that it was much easier to land clients when I had success stories I could speak to. It’s important to figure out a way to get some results before you go all-in on pitching for money.

    You can reach out to businesses, same as above, and offer your services for free. This takes away all of the risk for the company, making them much more likely to agree, while allowing you to get right to the learning and create real-world results.

    Remember, we’re in this to try and find a job we love that pays us what we deserve. That is worth a LOT more than a few paid freelance contracts. If the freelancing turns into a source of revenue, that is icing on the cake.

    Leveraging Your Results To Land Your New Job

    There you have it — a step-by-step plan to build the experience you need to land a join a different industry. Now it’s time to get out there and get your foot in there door.

    First up, edit the resume.

    Add Your Experience To Your Resume

    As soon as you have some concrete results under your belt, you’re going to want to add them straight at the top of your resume.

    This will be the first thing that your potential employer will see and it helps remove any doubt about your qualifications.

    Way back up at the top of the article we took a look at why companies hire. The qualifications of X years is just an arbitrary number set by the company to make them feel like they are hiring someone who can do the job.

    Adding in your freelance experience not only shows that you can do the job, but also that you have an understanding of how to run a business. This knowledge is extremely valuable to an employer, especially for a technical hire because technical folks typically get tunnel vision and have trouble seeing how their work relates to the larger picture — making money.

    Identify Influencers At Your Target Company

    Now that you have the relevant experience, you’re going to want to start connecting with influencers who can help refer you into your dream job.

    I outline that exact process in my article How To Land A 6-Figure Job In Tech With No Connections so be sure to check that out when you’re ready.

  • 00:09:10

    Ep. 31 - Good coding instincts will eventually kick you in the teeth

    The freeCodeCamp Podcast starstarstarstarstar

    Some people have very strong coding instincts. They can solve problems just by looking at them, and feel like rockstars. But being a rockstar coder can only get you so far. You need one other crucial element: discipline. In this podcast, Bill shares his disciplined approach to writing code and to work in general.

    Written by Bill Sourour: http://twitter.com/billsourour

    Read by Abbey Rennemeyer: http://twitter.com/abbeyrenn

    Original article: https://fcc.im/2IzwWdH

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    I wrote my first few lines of code almost 32 years ago, when I was 6 years old. I developed very strong coding instincts. I could look at any problem and immediately know how to solve it, just by intuition.

    By the time I started coding the web for a living, I felt like a rock star. I found and fixed bugs faster than any of my co-workers. My team started assigning me all the most challenging features and the most nagging bugs. They even started calling me a “wizard.”

    But following your intuition can only take you so far. I hit a plateau. And no amount of coding instinct was going to push me past it.

    The trouble with trusting your gut

    Unfortunately, intuition as a technique for learning and problem solving doesn’t scale very well. When you rely on instinct and intuition alone, you get a curve that looks like this (See original article for graph).

    Of course, you can choose to accept your limits and only ever deal with problems below the line. This will indulge your “rock star coder” fantasy, but it will quickly begin to limit your growth and your career. Plus, it’s boring.

    As I pushed myself further and further ahead in my career — and started to really challenge my own abilities — I began to notice a disturbing trend. I was no longer the fastest kid on the block.

    I had always known that I’d eventually run into people smarter and more talented than me. (My delusions of grandeur were still grounded in reality. I’m no genius.)

    But when I looked around, I realized that some of the people beating me were not using a superior intellect or some sort of innate gift for code. They just had a secret weapon that I sorely lacked: discipline.

    It turns out that a consistent, repeatable, methodical approach to learning and problem solving will eventually outperform any natural gifts — or instincts — that you may have developed.

    Let’s tool up those problem solving abilities

    Regardless of who you are, how much passion or natural talent you have, you will eventually hit a hard ceiling. I’m going to share with you a few techniques that will dramatically improve your disciplined problem solving abilities.

    I’m assuming that, if you have a debugger, you’ve already run it, Googled the output, and had no luck.

    I’m also assuming that if the problem was reported by someone else, you have been able to reproduce the problem. This second assumption is a big one. If you can’t reproduce the problem, then that needs to be your first step.

    You need to compare the context and environment in which the problem occurred to the context and environment in which you are trying to reproduce it. Start eliminating any differences you can, one by one, until you can reproduce.

    Once you can reproduce the problem, and after the debugger has failed to be of any use, you can try the following disciplined approaches.


    Read the documentation, you fool! (Admittedly this isn’t what RTFM stands for exactly, but there may be children reading.)

    Actually read it — more than once if you need to. Don’t just skim it looking for something you can copy, paste, and pray will work.

    The problem is you want an answer fast. You want that thrill of victory. But you’re not willing to put in the work. So slow down. Take a breath. Grab a coffee. And read the relevant documentation all the way through.

    If you have no documentation, consider creating some, then sharing it with others after you’ve fixed the problem.

    Test Your Assumptions

    If you expect something to work and it doesn’t, it’s because you’ve made a bad assumption somewhere along the way. Take an inventory of your assumptions and try to prove that each one is true.

    Start with the most basic assumptions that can be quickly tested. Is the server actually running? Is it connected to the network? Is everything spelled correctly? Are all the brackets and semicolons in the right place?

    If you don’t start with the simple things, and it does turn out to be one of these things, when you finally figure it out you will want to jump out a window. So save yourself the headache.

    Disassemble and Reassemble

    Remove components from the solution until it starts working again, then put the components back one-by-one in order to find the broken piece.

    This feels tedious and scary, but it is one of the most effective, disciplined ways to find the cause of a bug in your code. Make sure you have a backup before you start though, in case you accidentally end up with Humpty Dumpty code (code that you can’t put back together again).

    By the way, if you find yourself in a situation where you don’t know how to reassemble the code back to how it was, this is an indication of a potentially bigger problem: you don’t understand the codebase you’re working with. That’s bad bananas, my friend.

    If you’re on a tight deadline, seek help immediately from someone who understands the codebase better than you. If no such person exists, dig in for a long night, and prioritize getting to know and understand how this code works, so that you can fix it.

    Eliminate Variables

    Anything that can change from one trial to the next should be made to remain static while you’re debugging. You can’t hit a moving target. This is where Test Driven Development (TDD) comes in handy. If you’re using TDD, then you should have some mock objects at your disposal.

    Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. — Wikipedia

    If you didn’t do TDD, then you’ll need to mock out any moving parts now, so that you can find the bug under stable conditions.

    Here’s a tip: if you mock an object and the bug suddenly goes away, then the bug is likely in the object you mocked.

    Use the “Saff Squeeze”

    There’s a technique called the “Saff Squeeze” — named and popularized by Kent Beck — that is sort of a cross between the two ideas above.

    He describes it this way:

    “To effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.” — Kent Beck

    So instead of formal mocks or code disassembly, you simply add the body of the functions that you’re testing into the test itself, then move the assertions down until the bug goes away.

    This has the added benefit of leaving you with smaller, more specific tests.

    Edit: Thanks to Jim Balter for pointing out this link to a good example and explanation of the Saff Squeeze.

    After You Fix It, Break It and Fix It Again

    Never leave a bug until you fully understand how you fixed it. You should be able to reproduce the bug and fix it again at will.

    I can’t stress this enough. If you fix a bug and you’re not sure exactly what caused it or how you managed to fix it, that bug will come back to bite you at the worst possible time.

    What About Those Instincts?

    Now that you’ve learned these techniques, does that mean you should always use them first instead of relying on your instincts? No. Absolutely not.

    What I recommend is that you give your instincts a time box in which to succeed. If you have a strong hunch about what the problem might be — and you can test your hunch quickly — do that first. If the bug is below the green line in the chart above, chances are that your instincts will be the fastest path to a solution.

    Once you’ve quickly tried your first or second hunch and been wrong though, stop the shotgun approach and start doing things methodically.

    Having both instincts and discipline will make you one of the top coders on any team.

    To help you even more, I have put together a free PDF list of my five favourite code refactoring techniques — that lead to fewer bugs — get it by clicking the link in the original article.

  • 00:13:18

    Ep. 30 - Craigslist, Wikipedia, and the Abundance Economy

    The freeCodeCamp Podcast starstarstarstarstar

    You’ve heard it before: “There’s no such thing as a free lunch.” We're taught so from an early age. But history has shown: you often can get something for basically nothing. In this episode, Quincy discusses how we can all enjoy the abundance economy and - for all intents and purposes - get a free lunch.

    Written and read by Quincy Larson: http://twitter.com/ossia

    Original article: https://fcc.im/2wxPlpS

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02

    Check out the book Abundance: The Future Is Better Than You Think by Steven Kotler and Peter H. Diamandis


    You’ve heard it before. Maybe you’ve even said it. “There’s no such thing as a free lunch.”

    “You can’t get something for nothing.”

    “Somebody has to pay.”

    People recite these sayings with confidence, as though they were quoting Newton’s Laws of Motion.

    But history has shown: you often can get something for basically nothing.

    And even when somebody has to pay, that somebody doesn’t have to be you, and the amount doesn’t have to be very much at all.

    In some cases, the benefits so vastly outweigh the costs that it is — for all practical intents and purposes — a free lunch.

    How we eradicated Polio from the face of the Earth

    In the early 1950s, the US was recovering from its worst Polio epidemic ever. Thousands of children died from this virus, and many more suffered life-long paralysis.

    No one was safe from this horrible disease. Even US president Franklin D. Roosevelt contracted it at age 39. He spent the rest of his life in a wheelchair.

    Enter Jonas Salk, a medical researcher who had mainly studied flu viruses before turning his efforts toward Polio.

    Dr. Salk spent 7 years assembling a team of researchers and working to develop a Polio vaccine.

    He conducted the most extensive field test ever, involving what historian Bill O’Neal says were “20,000 physicians and public health officers, 64,000 school personnel, and 220,000 volunteers.”

    The vaccine was a success. So Dr. Salk set to work immunizing everyone on Earth. He pushed the marginal costs of the Polio vaccine as low as possible — to just the raw materials necessary — by forgoing any financial benefits his intellectual property would have brought him.

    When asked about his patent, he said, “There is no patent. Could you patent the sun?”

    Dr. Salk stared down a massive problem and threw himself into it with everything he could, without any aspiration for personal gain. And in the process, he and his colleagues basically wiped out one of the worst diseases ever.

    Today, everyone’s life is better off as a direct result of this one massive free lunch.

    “The reward for work well done is the opportunity to do more.” —Dr. Jonas Salk

    Free lunches are important

    Before I run through some modern-day examples of free lunches, let me give you some background on myself, and why the notion of a free lunch is so important to me.

    I run a nonprofit, open source community where you can learn to code, practice by building software for nonprofits, then get a job as a developer. Thousands of people have gotten developer jobs so far. And it’s free.

    I was so committed to the idea of it being free that I put the word “free” in the name.

    Free can mean both libre — free as in free speech, and gratis — free as in free beer. Just like the “free” in “Free Open Source Software” (FOSS), the “free” in “freeCodeCamp” means both of these.

    But still, every day I encounter people who are skeptical. They tell me they don’t use freeCodeCamp because “it sounds too good to be true.”

    “There’s no way all this can be free,” they say. “I’ll sign up and give you my email address, and only then will I find out that I need to pay $20 a month, right?” Or: “You’re free for now, but soon you’ll throw up ads and paywalls, like everybody else does.”

    Well, I’ve said this publicly a hundred times, and I’ll say it publicly again: freeCodeCamp will always be free.

    We operate on the fringe of capitalism. The frontier where marginal costs asymptotically approach zero, and the very laws of classical economics begin to unravel. A place called the abundance economy.

    And we’re not alone.

    Low overhead engineering with lichess.org

    Meet Thibault Duplessis, the founder of lichess.org — the second most popular chess website on the planet.

    As of a year ago, lichess had 78,000 unique daily visitors, who play a total of 260,000 games of chess each day.

    Thibault has no employees. He doesn’t even work on lichess full-time. He still has a job at a development consultancy.

    Lichess’s main competitor, Chess.com, is a privately-held behemoth that makes millions of dollars each year off of banner ads and premium membership up-sells, then spends that money acquiring their competition.

    Contrast this with Thibault, who has open-sourced lichess’s server code. He has promised that lichess will be free forever, and that it will never show ads.

    But wait — how can he do this?

    Because of the nature of modern web applications, and the economics of their near-zero marginal costs.

    Despite lichess’s complexity — and the scale at which it operates — Thibault’s server costs are a mere $416 a month.

    This cost is covered by merchandise and donations from his grateful users, who increasingly include some of the best chess players in the world.

    How Craigslist covers costs by charging only 0.1% of its users

    Remember classifieds?

    People used to pay a dollar per word for tiny ads that appeared in the backs of newspapers, sandwiched between other ads.

    Then, 20 years ago, Craigslist utterly disrupted classifieds. They provided a directory of ads online, for free.

    It was searchable. You could use as many words as you wanted, and include pictures. You could repost your ads as many times as you wanted, in as many nearby cities as you wanted.

    But if placing ads on Craigslist was free, how did Craigslist make money?

    Well, if you asked a random Craigslist user, they probably wouldn’t be able to tell you. Most people just assume that Craigslist is a nonprofit, supported by donations or something.

    But Craigslist made $400 million last year.

    They did it by charging to post in a few key categories within a few key cities. If you want to list an apartment in New York City, or a job in San Francisco, you have to pay Craigslist a small fee.

    This means that less than one in a thousand people who use Craigslist actually pay any money to do so. Those real estate agents in New York City and those recruiters in San Francisco are paying for everyone else’s free lunch.

    Craigslist doesn’t have investors. It keeps things simple. It has a small team of about 40 people.

    Craig still works at Craigslist. He handed over the role of CEO to his long-time friend so he could focus on doing what he loves: providing support for Craigslist users around the world.

    Like the other people mentioned in this article, he doesn’t seem to care about money. From what I can tell, he donates most of his money through his charity CraigConnects. And he spends his downtime advocating for causes he cares about, like supporting veterans and helping more women start their careers in tech.

    Crowd-sourcing contributions with Wikipedia

    Before Wikipedia, the most popular encyclopedia was written by paid experts, and printed in massive books. The Encyclopaedia Britannica was so expensive that they wouldn’t even tell you its price in their TV spots. (It cost $1,400.)

    Jimmy Wales — Wikipedia’s visionary leader — had a better idea. He leveraged the power of the internet and the wisdom of volunteer contributors. And he made it free.

    The number of volunteer-contributed articles on Wikipedia exploded. It quickly surpassed traditional encyclopedias in the scope of its content.

    Instead of waiting for a new physical edition to hit the press, Wikipedia editors could instantly publish updates to articles. Wikipedia was so up-to-date that many people started using it for news on current events.

    Traditional encyclopedias were quickly backed into a corner. They were paying expert writers and editors to create their content. Surely this resulted in more accurate information than Wikipedia’s volunteer-driven free-for-all.

    But in 2005, a major academic journal published an analysis comparing the factual accuracy of Wikipedia versus the Encyclopaedia Britannica. It found:

    “Jimmy Wales’ Wikipedia comes close to Britannica in terms of the accuracy of its science entries, a Nature investigation finds.” — The abstract from Nature’s analysis

    In a last-ditch effort, The Encyclopaedia Britannica pushed back, but Nature upheld its finding.

    This was the final blow to the encyclopedia industry, which had flourished for decades by selling stacks of books door-to-door to guilty parents.

    A decade later, Wikipedia is now the 6th most visited website on the planet. And covers its operating costs through more than $70 million in donations each year from grateful patrons.

    But despite all of Jimmy’s accomplishments, people seem to be much more preoccupied with his money. Or rather, his lack-there-of.

    Here’s what you get when you type “Jimmy Wales net worth” into Google:

    Below this result, Google shows you pictures of people who started other large websites. Each of them has a net worth that’s five orders of magnitude larger than Jimmy’s paltry $1 million.

    People have a hard time accepting that someone would set out to build something as important as Wikipedia without bothering to make money out of it.

    One person went so far as to ask straight up on Quora: “Is Jimmy Wales rich?”

    Jimmy responded:

    “By any sane standard of measurement, yes, of course I’m rich. Nearly half of the people on earth live on less than $2 a day. I spend more than that on my cellphone bill.”

    There’s so much more to life than money.

    Why are people so preoccupied by money, and the net worth of famous people? Because they’re operating in a scarcity mindset.

    They are so preoccupied by the risk of not having enough that they can’t see the real risk: missing out on the potential for so much more.

    The traditional scarcity mindset approach to creating value at scale goes something like this:

    Figure out a problem you can solve for a large number of people

    2a. If people will pay for your product, sell it to them, then re-invest the profits into growing your business (bootstrapping)

    2b. If your solution isn’t something people will pay for, raise a bunch of venture capital to fund development. Once it’s big enough, make money some other way — usually by selling ads.

    But there’s an alternative. An abundance mindset.

    This approach shrugs off concerns for basic needs (worst case scenario, I have to get a job in fast food) and instead focuses on upside potential.

    When you apply an abundance mindset, you approach problems from a different perspective. You try to identify opportunities for free lunches.

    Your approach to creating value at scale will look something more like this:

    Figure out a problem you can solve for a large number of people

    Keep costs low, fund development yourself, and ask for donations, sell merchandise, or find a few users with deep pockets who can subsidize everyone else.

    This is how all of these organizations I’ve discussed here operate. And this is how they can always be free.

  • 00:11:00

    Ep. 29 - Finding time to become a better developer

    The freeCodeCamp Podcast starstarstarstarstar

    There’s no time for anything. At least that’s how it feels doesn’t it? No time to refactor that ugly code, no time to work on documentation, no time to actually live your life. But if you take the time to listen to this podcast, you’ll find yourself with more time for what’s important.

    Written by Bill Sourour: https://twitter.com/BillSourour

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2rqbKAp

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!

    Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.

    I used to think that the only way to be a great developer was to work myself sick. My health, friendships, and family all suffered because of it. Understanding the following 5 truths about time management for a developer is what saved me.

    1. You don’t need to learn every new thing in order to stay relevant.

    There is no question that a good developer should always be learning, but where you focus your learning can make a huge difference in the amount of time it takes to stay on top of your game.

    “The old thing is dead. Long live the NEW, about-to-be-old thing!”

    First of all, don’t get suckered in by headlines on dev blogs that announce a new standard every 37 seconds. Most new technologies, frameworks, and features will never get any real traction and you’ll never need to know them. Those that do emerge will take a lot longer to gain adoption than the blogosphere — and the vendors who hock these new technologies — would have you believe. Companies are invested in their tech stack and, other than a handful of tiny tech startups, they can’t just turn on a dime. So, relax, your career is safe.

    Focus your learning on three areas, in the following order of priority:

    Fundamentals — It’s a lot easier to pick up new skills when you have a real command of the underlying fundamentals. For example, if you understand JavaScript deeply, you can master any new JavaScript framework in record speed. If you understand Object Oriented Programming deeply, you can master new object oriented languages quickly, too. Deeply learning the fundamentals will 10x your learning efficiency. Always focus on improving fundamentals above all else.

    The latest version/feature of the stack(s) you use the most — There’s a stack of technologies that you probably use every day. These are the tools that will put food on the table for you and your family. When new versions of these tools are released, it’s worth investing the time to learn about them.

    In-demand tech that is backed by market leaders — if a big, well established company like Google, Facebook, or Microsoft puts out something new and it starts getting some buzz, it’s worth looking into. There were a hundred and one JavaScript frameworks all vying for attention and then Angular and React showed up and wiped them off the map. I’m not saying there won’t be disruptors that come from nowhere and become the next big thing but, more often than not, no-name tech is just noise.

    Learning time should be a part of your schedule. Set aside a specific amount of time for learning every day. It doesn’t need to be a lot of time, even 25 minutes of reading and experimentation every day adds up quickly.

    2. Writing good code takes less time than writing bad code, BUT it doesn’t feel that way.

    You probably feel like the time you spend on a new feature ends when you run the code and it appears to work. But that’s just the beginning of your time investment. Time spent on a feature includes time spent debugging that feature later and also time spent refactoring and working other code around any poor design decisions you made when implementing that feature. When you start to understand your time investment this way, it becomes obvious that, in the long run, fewer errors and better design are a worthwhile investment.

    There are two things you can do that will reduce errors in your code and lead to better design.

    Use test-driven development. Write the test first, then write the code that satisfies the test. This not only leads to less buggy code but also to better design, because when you have to structure code in a testable way, you end up making smaller, simpler functions that have fewer dependencies.

    Use an iterative design approach. Don’t spend time trying to make code perfect before you’ve spent time trying to make the code work. You’ll never, ever get it right completely in your head. You have to get those fingers banging on a keyboard and produce code that runs and does what’s expected. The problem is that developers tend to make one of two common mistakes; either they spend too much time thinking and not enough time actually doing, or they don’t spend enough time improving their first solution. Follow the mantra first stated by Kent Beck: “make it work, make it right, make it fast” — and in that order.

    3. Working 24/7 does NOT make you a hero. Managing expectations does.

    This is the one that nearly killed me. I used to agree and commit to any crazy timeline my boss or client could come up with. I was afraid of saying “no.” I was afraid of letting anyone down. I would do whatever it took to deliver. I have literally slept under my desk, and pulled multiple caffeine-fueled 40+ hour marathon coding sessions.

    At first I was a shining star. I would get a big pat on the back and I felt like a hero. But I set an expectation that was impossible to live up to. Working like that is unsustainable. Eventually, I started to burn out, get sick, and miss deadlines. I started getting a reputation as unreliable and inconsistent. It was bad news.

    What I eventually came to understand, and what you should commit to learning too, is that the real heroes are the ones who are consistently reliable. They say what they’ll do and do what they say. The only way to be that kind of hero is to manage expectations.

    You need to take control of the timelines so that you are always and without fail delivering high quality work exactly on time. This is incredibly difficult at first. It means having to say “no” and having to push back.

    In the beginning, your boss or client won’t be thrilled by your resistance, but once you demonstrate that you are trustworthy and reliable, everything will start to change.

    Over time, other developers will be late, deliver sloppy work, or burn out and become unreliable. Then you will become the real hero of your team. In fact, learning this made me one of the most in demand consultants in my market. I’ve built a stellar reputation for quality and timeliness, because I vigorously manage expectations.

    4. Not all time spent “improving” code has the same ROI.

    Spending time is an investment. Like all investments, it’s reasonable to expect a return on investment (ROI). You should be getting back at least as much — and hopefully more — value than you put in.

    We talked about “make it work, make it right, make it fast.” It’s a good mantra but there is a trap: “right” does not mean perfect, and “fast” does not mean absolutely as fast as possible.

    “Right” means that the code works consistently and is easy to refactor. “Fast” means that the speed of execution does not have a negative impact on the overall user experience. The most important thing is that your application feels fast to the user.

    So, don’t waste time trying to shave time off a function that is barely used, or trying to save another few milliseconds on something that already runs faster than a human can blink (~300ms). And don’t waste time trying to refactor working, well-structured code because you just learned some new technique or approach that you’ve convinced yourself you suddenly have to go back and apply to everything you’ve ever done.

    5. Scheduled down time makes you more productive.

    This was a very hard one for me to learn and accept. How can you possibly be more productive when you’re not spending all your time producing? Well, it’s true.

    According to Allison Gabriel, an assistant professor of management at Virginia Commonwealth University who studies job demands and employee motivation, “There is a lot of research that says we have a limited pool of cognitive resources. When you are constantly draining your resources, you are not being as productive as you can be. If you get depleted, we see performance decline. You’re able to persist less and have trouble solving tasks”.

    Always working sets off strain reactions, such as stress, fatigue, and negative mood. These drain your focus and your physical and emotional resources.

    The brain’s ability to self-regulate — to stay disciplined — wanes with each exercise of self-control during the day. It’s a loss of resources that must be replenished. Otherwise it becomes harder to stay on-task, be attentive and solve problems.

    Your mind and body need down time, and they’re going to get it whether you like it or not. So, schedule that down time. Actually plan and put on your calendar real scheduled breaks. This will allow you to take down time without feeling guilty about it. It will make work-time easier to endure because you’ll know that you have a scheduled break right around the corner.

    More help and resources

    To help you even more, I’ve put together a list of free and useful resources (videos, tutorials and websites) that can help you better understand and implement the insights I’ve just shared with you. You can get it here: https://www.devmastery.com/signup/time/index.html

  • 01:01:09

    Ep. 28 - How to land a six figure job in tech with no connections

    The freeCodeCamp Podcast starstarstarstarstar

    Austin was stuck in a job he hated. But given his non-traditional background and lack of Silicon Valley network, he knew he'd have to work extra hard to launch a career in tech. In this podcast, he details the steps he took to land interviews at Google, Twitter, and other prestigious companies that led to his dream job.

    Written by Austin Belcak: https://cultivatedculture.com

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2F8uE2H

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    Shortly after college, I began chasing something many people want but few ever get: a job they love.

    I left school with a biology degree and a job in the medical field. It took me about two weeks to realize I absolutely hated it.

    I was working 6 days a week, waking up at 3:30am in order to be at the hospital by 5:30. Making next to nothing, I quickly racked up $10,000 in credit card debt. I knew I deserved more, but I had no idea how to get it.

    I saw people in my graduating class living in New York or San Francisco, making six figure salaries and going on exotic trips. I often wondered what they had figured out that I hadn’t. What was their secret?

    I dedicated the next 12 months of my life to finding the answer. In this article I’m going to share everything I learned along the way.

    First, I’ll walk you through the exact process you can use to get a job interview at your dream company even if you don’t know a single person there — you won’t even need to apply online.

    Next, I’ll teach you how to ace the interview process, get the offer, and land a salary you deserve.

    I personally used these exact strategies to get interviews and offers at companies like Google, Uber and Twitter. They are also the same tactics that my students have used to land interviews and offers at Google, Microsoft, Slack, Deloitte, PWC, American Express, ESPN and more.

    Referrals Are The Most Effective Way To Get Hired
    A recent LinkedIn survey on talent trends showed that 1 in 3 people were actively looking for new work. As of January 2017, the population of employed people in the United States was 123 million. This means that, at any given time, 41 million people are looking for work.

    On average, an open role at a well known company gets ~250 resumes. 75% of these resumes came from some sort of online portal (like the company’s online application, or a career aggregator site like Indeed.com).

    Once submitted, these applications are screened by Applicant Tracking software that scans them for keywords. At the end of the process, ~5 resumes make it into the hands of a recruiter. That’s 2% at best.

    Additionally, The Wall Street Journal published an article stating that 80% of jobs aren’t advertised online.

    That means that 75% of people applying for jobs are all competing for 20% of the opportunities!


    When it comes to getting hired, referrals are the most effective way to secure an interview and land the offer. Here are some stats from a recent Jobvite survey:

    40% of hires come from referrals, the next largest channel is via career sites at 21% (almost half as many)

    Referrals get hired in an average of 3 weeks while other applicants take up to 7 weeks

    Referrals get paid more on average than cold applicants

    40% of hires come from referrals (courtesy of Jobvite.com)

    Finally, over 50% of six figure jobs are filled via referral.

    Moral of the story? If we want to get hired at our dream job, we need to find another way to get a referral from an insider.

    The problem is, many of us don’t happen to have friends or family working at places like Google.

    Part 1: How To Get A Job Interview When You Don’t Know A Single Person At The Company

    Know Your Role (And Find It)

    The first step is having a solid idea of the specific role you are looking for, down to the company and title if possible.

    Next, you need to make sure that role is available. For today, let’s assume that you want to be an Account Manager in the Technology B2B vertical at Google. Looks like a spot is open in New York:

    Locate Potential Influencers

    Next, you are going to find someone who not only knows about the role, but could potentially have an impact on hiring for it. Time to fire up LinkedIn.

    In the search bar, plug in the company name + all of the information I highlighted above (title, vertical/industry, preferred city). However, before you hit “Search,” we need to remember that you are looking for someone who can influence the hiring process.

    With that in mind, I usually use a title that is one level up from the position that I’m looking for.

    If you’re not familiar with title hierarchy structures in the corporate world, here is a quick guide (if you are already familiar with how titles are structured, feel free to skip this section):

    Side Note: A Brief Guide To Company Organizational Structures By Title

    Every company has a hierarchy starting at the top with the CEO/Founder all the way down to the entry level employees. When researching companies, especially people to speak to within those companies, it helps to know where certain titles fit in the food chain. That way you can ensure you are talking to the right person.

    Here is a general list of titles that fits almost any company, starting at the top:

    C-­Level (CEO, CTO, CFO, COO, etc.)
    Vice President (VP)
    Senior Manager
    Coordinator (Entry Level)
    Associates, Executives, and Seniors

    In many companies, the above titles have some sort of variation that allows for greater segmentation within that level. The most common forms of this are Associate, Executive, and Senior. Here is what those mean:

    Associate: this title is usually given to someone who is halfway between positions for some reason (maybe there is typically a 4 year gap between levels and they are 2 years in). A person with Associate in their title is usually one notch below a person with the original title.

    For example, an Associate Account Manager would most likely be one level below an Account Manager.

    Senior: ­this title is the more experienced version of an Associate. People with Senior in their title are usually one notch above the original title. For example, a Senior Account Manager would be one notch above an Account Manager.

    Executive: ­this title is usually given to people who are very senior, or around the level of Vice President. The two most common cases are

    Sales Executive/Account Executive (synonymous terms for a senior salesperson) or Executive Vice President who is two notches above a Vice

    President and one notch above a Senior Vice President. That should be all the info you need to make an educated decision around where people stand within the company you are researching.

    Now that you’re familiar with the company structure, let’s get back to finding that influencer who can help you land this job.

    Since we are looking for an Account Manager role, the next step up would be Senior Account Manager so your LinkedIn search would look like this:

    Our first result? A Senior Account Manager who works in B2B at Google:

    Obtaining Contact Info

    Now we’re going to reach out and set up a meeting. It’s best to do these in person but over the phone can work well if you’re dream job is in another state or country.

    In order to get in touch with our influencer, we’re going to need their contact info. Here are 3 strategies you can use to find almost anyone’s corporate email address:


    This one is obvious but it’s a big time saver and definitely worth the 10 seconds it takes to check.

    On the person’s profile, right under their picture, there can be a button labeled “Contact Info” (I say “can be” because people have the option to remove it). Occasionally, people will have their email address listed right there — voila!

    If not, let’s move right along…

    Reverse Lookup

    Head over to Voila Norbert and enter the first and last name of the person you are searching for, as well as their company’s website. For example, if we were trying to find Larry Page’s email, our form would look like this:

    Once it spits out their email you can confirm it using MailTester.

    Matching Formats

    If that doesn’t work, you can try finding someone else’s email at the company and use that format reverse engineering your target email address.

    For example, using Larry Page again, if I know that my buddy John Smith’s email is john at google.com then I can assume that Larry’s email is larry at google.com.

    The easiest way to get a hold of a company email address is to reach out to someone in sales or media because both of these departments usually have inbound lead forms and people on the other end ready to pounce on those leads.

    We can also use our LinkedIn method here and target salespeople.

    Salespeople almost always have their corporate email listed on their LinkedIn because it’s a free win for them. If someone is looking for their product and then finds them on LinkedIn, boom — they just got an effortless inbound lead.

    Once you have the format, you can use MailTester to confirm your target email address.

    Research, Research, Research

    Now that you have your potential influencer, it’s time to do some research so you can effectively reach out and build that relationship.

    Start with the usual suspects — LinkedIn, Facebook, Twitter, Instagram, etc. and look for common points of interest. To be honest, most people are better at this online research thing than I am, so I’ll get back to the meat here.

    One thing I will say is, don’t skimp. The more you get to know this person beforehand, the better your chances of landing a referral from them.

    Some people have said to me, “Austin, isn’t this a little weird? I feel like I’m kind of stalking this person.” I totally get it. However, this information is critical for quickly building a strong relationship and getting that referral.

    Also, in my experience, people tend to expect that you’ve done some research on them. The key is to understand what is kosher to bring up out of the blue and what isn’t.

    People are OK with you checking out their LinkedIn, but they may be a little weirded out if you mention that picture from Saturday’s Bar Crawl you saw on Facebook.

    My general rule of thumb is this: if it exists on LinkedIn, it’s fair game to bring up. If you found it somewhere else (Twitter, Facebook, etc.) use a different method. For example, if I see that my influencer is a skiing fanatic, I may bring up that I went on a ski trip a few weeks beforehand.

    Sending The Email

    Now that you have your potential influencer and their contact info, it’s time to reach out. Not only is this one of the scarier parts of this process, it is also the most pivotal.

    To help you get past that hump, I’ve included the exact email script that I used to reach out to people. In this case, I’m reaching out to
    Tim who works at Google:

    Subject: Quick Question

    Hi Tim,

    My name is Austin and I currently work at Cultivated Culture. I was browsing through LinkedIn and came across your information — I hope you don’t mind me reaching out of the blue here.

    I saw that you have extensive experience in Google’s Technology B2B vertical and I’m very interested in learning more about that space. I would love to have the opportunity to run some questions by you, as well as tap into any advice you may have given your knowledge of the industry.

    I know that your time is extremely valuable so please don’t feel to need to respond in depth. If you do have 5 minutes to chat, I would really appreciate it.



    There are a few key points to the email above:

    Address the person you are emailing by name

    State who you are and make it personable

    Include some flattery that positions the person as an “expert”

    As for the subject, Fast Company did a study where they emailed 1,000 C-level executives from Fortune & Inc 500 companies. They found that the subject line “Quick Question” made up 66.7% of total replies. I saw similar results.

    All of that said, this script is just a framework. You will most likely need to tweak your emails to fit the situation.

    When that time comes, I recommend checking out Sam Parr’s incredible guide on how to cold email like a boss (Sam has started conversations with Jeff Bezos and Brian Lee (aka Jessica Alba’s Honest co-founder) via cold email). It’s the same guide I used to help craft my email templates.

    Now hit Send!

    Prepare For Your Meeting

    In order to prepare, we have to know what we’re preparing for. The goal of your meeting is to position your influencer as an expert, make them feel special, and build a relationship.

    You should not and will not mention anything about the opening at their company. People innately enjoy helping others and if you follow the steps above, they will bring this up naturally.

    You will want to prepare a list of questions that gets them to open up about themselves and the company. I like to ask them several softballs to get things warmed up and then hit them with a few questions they are guaranteed to remember.

    Here is a quick set that I’ve had success with in the past (I’ve found the last one really seems to stick):

    I saw you worked at [Previous Companies]. How did you end up going from [First Industry] to becoming interested in [Current Company]?

    You hear a lot about [Current Company] in the news, but I’d love to hear more about why you love working there. What’s your favorite part?

    What is one totally unexpected lesson you’ve learned from working at [Current Company]?

    The “Million Dollar” Question

    Regardless of the questions you choose, there is one that you must always be sure to ask:

    “What is the biggest challenge your team is facing right now?”

    Really dig in here, get them to be specific. This information is going to be critical in helping you land a referral from this person, as well as getting the offer farther down the road.

    Your Homework: Adding Value (In A Big Way)

    Okay, so you met with your influencer, things went great, and you identified a major pain point that the team is having. Now we’re going to focus on that last piece.

    Over the next week you are going to research the crap out of your influencer’s problem. Then you are going to come up with a solution and draft up a proposal for how you would solve it. Your proposal should include:

    A summary of the problem (to illustrate that you understand their pain)

    A step-by-step framework of how you would solve this problem

    A brief outline of how your skill set positions you as an asset to implement that solution

    Truthfully, this process deserves a post of its own but this should give you a good idea of what you need to do. If you’re the type of person that likes concrete examples, check out this guerrilla usability test that Raghav Haran ran for Airbnb.

    Once you have all of this information, consolidate it into a Word document, head over to Upwork, and hire a graphic designer to make your proposal look amazing. If you’ve never hired on Upwork before, here is an amazing guide by Dave Nevogt on how to do it right.

    Following Up With Your Proposal

    Now we’re going to reach back out to our influencer with the proposal. Here’s the template I used:

    Hi [Influencer],

    Thanks again for taking the time out to chat last week.

    I spent a lot of time thinking about what you said regarding [team’s biggest challenge]. In fact, I created a short framework that should help you solve it. Please find that attached.

    If you have some time, I would love to chat about it in more detail.

    Please let me know if you have any questions, I’m looking forward to hearing your thoughts!



    It’s very important that you do not mention the open position in any of your emails or the proposal. Be patient and wait for their response. When they do get back to you, they will not only bring up the opening but they will ask you if you’re interested.

    Kindly accept and play it cool. You’re in!

    Part 2: How To Breeze Through The Interview Process

    Fast forward — our influencer passed along our resume to HR and they have reached out to set up a phone screen. Once we get past that, we’ll be on to interviewing with the team, and then getting the job.

    A note to developers: The advice below does not cover technical interviews, which are typically required for developer/software roles.

    However, the advice below will help create more time to prepare for technical interviews by minimizing the amount of preparation needed for other parts of the interview process. If you are applying for a development role, I suggest you read Cracking The Coding Interview by Gayle Laakmann McDowell.

    Interviews can be daunting, especially at companies like Google, Amazon, or Uber. I’m sure you’ve read the horror stories about crazy questions they ask people like “Quick — How many golf balls can fit inside a school bus,” or, “how many gas stations are there in Manhattan?”

    The truth is, most of these companies have done away with those questions. They crunched the numbers and found that the answers didn’t correlate with high employee performance (shocker, I know). In fact, Google’s own Senior Vice President of People Operations called them a “complete waste of time.”

    These companies have since reverted back to the standard style of interviews, which is great for us because it makes it much easier to identify patterns. We can essentially “guess” what questions will be on the test and prepare answers that will blow our interviewers away (it works way better than it did in college, I swear).

    Here is the process I used to prepare for each one.

    Nailing The Basics: Questions You’ll Get In Every Interview

    According to renowned career guru Penelope Trunk, one of the easiest ways to be a better interviewer is to prepare for the most obvious questions. You may be saying “well duh,” but you’d be surprised by how many people spread themselves too thin by trying to prepare answers to every possible question.

    99% of the interviews you go on will follow the exact same template. If you can master the format, your confidence will skyrocket and you’ll be prepared for almost any situation you get thrown into.

    The Universal Job Interview Format:

    Tell me about yourself (your experience, why you are interested in this role, etc.)
    A mix of behavioral questions, which we’ll dive into shortly
    What questions do you have for me (the interviewer)?
    Let’s tackle each individually.

    Tell Me About Yourself

    This is your first impression. More importantly, it’s the only part of the interview that you totally control. Do NOT rattle off your resume like a grocery list.

    In order to nail this part you need to craft an interesting story — your story. You want it to be concise (around 2–3 minutes) and you need to think about what you want to convey. I recommend:

    Choosing 2–3 themes to build your story around (for me, those themes were Persistence, Agility, and Success)

    Including quantitative metrics whenever possible

    Addressing the question of why you want to leave your current position (they are going to ask you this anyways, addressing it early shows that you’re aware it’s a concern of theirs and helps put them at ease)

    To help get you started, here is what my story looked like. To give you some context, I was a biology major who was interested in landing a job in digital marketing:

    Growing up, like most people, I wanted to be a doctor. I went to [college] where I majored in biology and planned my course to medical school. Not long after, I decided that pre-med wasn’t for me. I wanted to get into digital marketing, and I wanted to be in New York. I set my sights on this goal and created a plan that would get me there.

    In 2013, I graduated with my biology degree and took a job in medical device sales where I worked from 5:30am — 12:30pm covering surgical cases in the operating room. Then, every day, I would come home and study digital marketing until 8:00pm. In order to gain relevant experience, I got certified in Google Analytics & AdWords and created my own consulting firm that focused on using search engine marketing to generate leads for private golf communities. We were able to increase home sales by an average of 20% while reducing the cost per lead by around 10%. Armed with my new credentials, I began to look for positions in New York.

    Eventually, I was offered a position at my current company (a promotional analytics company in New York). During my tenure there I have grown my book of business by 467%, spearheaded the creation of an internal group dedicated to marketing the company on the internet, and helped close the second largest deal in company history.

    However, the company has restructured several times since I was brought on. I’ve had 3 different managers over the past year, as well as 3 titles with different sets of responsibilities. I’m looking for something a bit more stable and [company I am interviewing at] has been somewhere that I have wanted to work since I got into this industry. I’m really excited to have this opportunity.

    Pro Tip: You are telling a story. Don’t be afraid to embellish a bit. I’m not saying you should lie or make up stories, but you want to sell yourself and you can bet your butt that your competition isn’t afraid to inflate their credentials.

    Behavioral Questions

    Next up is the dreaded set of behavioral questions. The ones meant to tease out your thought process and your ability to be a “team player.” This is the part where our educated “guesses” are going to come in handy.

    The behavioral section is broken down into two parts that I call Standard Questions and Company Specific Questions. Let’s start with the former.

    Standard Questions

    You are going to be asked a variation of one, if not all, of these questions in every single interview you go to:

    Why do you want to work for us?

    Tell me about a time you exhibited leadership

    Tell me about a time where you had to work as a team

    Tell me about a time you’ve had to work with a difficult person, or difficult people

    Tell me about a time you failed

    Tell me about a time you overcame an obstacle

    Tell me about a time when you had success

    If you can answer these 6 questions, you can handle 9 out of 10 interviews with no other preparation and be totally fine. Just follow the same set of rules I mentioned above in the Tell Me About Yourself section:

    Craft a concise story

    Make sure to include quantitative metrics that illustrate your success

    Anticipate and address objections

    Company Specific Questions

    These are questions that fall in the middle of the 7 listed above and “why are man hole covers round?” Never fear though, we can anticipate these too.

    Head over to GlassDoor. If you’ve never heard of GlassDoor, it’s a great resource for any job seeker that includes salaries, reviews, and interview information for almost any company in the world.

    First, you are going to search for the position you’re applying for. In keeping with our theme, we’ll search for “Google” under Companies & Reviews:

    Next, we’re going to click on the “Interviews” Tab:

    Then scroll down and click on “Filter Interviews” which will bring up some advanced settings. Here we’ll type in the title of the job we want (Account Manager, in this case) and the location (New York, NY). We’ll also select “Received Offer” because the people who didn’t receive offers tend to be slightly, ahem, biased:

    This will pull up a list of reviews from everyone who interviewed and received an offer for that position. The general comments are really helpful, but we want to focus on a section called Interview Questions towards the bottom. I usually comb through 10–15 of these and add all of the interview questions into a Word doc so I can answer them later:

    Now you have your second set of questions to prepare for.

    What Questions Do You Have For Me?

    Finally, once they are done peppering you with questions, your interviewer will ask if you have any questions for them. This is the most crucial part of the interview.

    Why? Because so many people neglect it. If you can ask some questions that are even slightly outside of the box, I’ve found that really sticks with the interviewer more than any other part of the meeting.

    After every interview I’ve been on, I asked for feedback. Without fail, the interviewer made a positive comment about the questions I asked. The good news for you is that I asked the same exact questions in every single one. Here they are:

    What is your favorite part about working here?

    What is the biggest challenge you are facing right now?

    Let’s say that, in one year, you are looking back on this hire. What has that person done to exceed expectations on every level?

    Ask about a current event (for example — I saw that [Competitor X] came out with this product. How do you see that affecting your business?)

    What is the most unexpected lesson you’ve learned while working at [company]?

    Tell me a little bit more about you, what do you like to do outside of work?

    These questions work because they are based on specific principles of behavioral psychology. They break down barriers and help build a positive association in your interviewer’s mind. If you’re interested in the details, you can read more about it here.

    Say Thank You

    While we’re on the subject, be absolutely sure to send a thank you note to everyone you interviewed with. Also include a personal touch to each one (something that you gained from that last question).

    Many people I talk to say “but I don’t have their email.” Ask for it! At the end of every interview always, always ask for a business card or write down the person’s email in your notebook.

    If you forget, try using the techniques I outlined above for finding people’s emails and you should be fine.

    Part 3 — Following Up & What To Do If They Say No

    This is one of the most common mistakes I see from job applicants. I understand how nerve wracking it is to sit there and wait while everything is completely out of your hands.

    One of the toughest things I had to learn throughout my interview process was that, while this is a HUGE deal to you, it’s really just another agenda item on the hiring manager’s schedule.

    They will get back to you, and if they don’t? You don’t want to work for someone who doesn’t have the courtesy of replying to the people they do business with.

    When Can I Send Them A Reminder?

    The rule of thumb is one business week. If you interviewed on a Tuesday, wait until the next Tuesday to email them (as J.T. O'Donnell says, never send a nudge on a Monday). When you do, don’t push or be blunt. Keep it short and sweet:

    Hi [Interviewer],

    I hope you had a great week!

    I wanted to quickly follow up and see if there was anything else I could help with regarding the application process. If so, please let me know.



    That’s it. If they don’t respond to that after another 3–4 days, you have your answer and it’s time to move on.

    What Happens If They Say No?

    Ugh. The worst case scenario. Don’t get down just yet though, we’re not done here.

    I have this quality where I have trouble taking “no” as an answer. When I was interviewing with Google, the initial screener told me that she wasn’t going to put me through because she “didn’t think I was qualified, and didn’t want to waste the team’s time.”

    I was not happy. So I sent her this:

    Hi [Recruiter],

    Thank you again for carving out the time to speak this afternoon. I really appreciate your feedback, and I wanted to add one final note:

    I completely understand your concerns regarding my experience with [skill]. You are correct that I didn’t have much experience with that at [previous company]. That said, this doesn’t stem from an inability to produce results, but rather a lack of opportunity to do so.

    While my experience on paper may not match up to the initial expectations of the position’s description, I have do have two qualities that work in my favor: I am an extremely efficient learner, and am also very effective at translating those learnings into practice. Second, I’m much more tenacious than your average individual. My career has hinged on these two qualities.

    I left college with no digital experience and a biology degree — all of my digital knowledge was obtained through self study. I spent 8 months selling myself without the on-paper experience to back it up. When I was finally given the opportunity to apply my knowledge in a business setting, I playing a critical role in landing the company’s 2nd largest deal in history. I am confident that I can have the same success in this role. I have the resources necessary to learn what I need in order to be successful at [company], and am prepared to do whatever it takes to make that happen.

    I understand that [company’s] interview process is extremely challenging, and that only the top talent ends up with an offer letter at the end. I also believe that I am worthy of a shot at that letter. [Company] is known for hiring people who excel at the intangibles, as well the ability to learn new things and apply them to existing knowledge. That is my forte.

    I am not asking for an offer. I am simply asking for the opportunity to speak with the hiring manager to make my case for the position. I’m sure you will find the best person for the position, I would just like to have a legitimate shot at being that person. If you give me that chance, my next set of answers will not disappoint.

    Thank you again for your continued consideration.


    Now that may be a little aggressive…

    Ok, it was pretty aggressive. But she wrote me back an hour later and pushed me through to the next round! Mission accomplished.

    The moral of the story here is, don’t give up if you get a “No.” Try to identify why you were turned down and then send a note to hiring manager addressing those items (feel free to copy mine).

    Taking Action

    There you have it. The exhaustive, step-by-step guide to landing an interview and then getting an offer from the company of your dreams. What are you waiting for? Get out there and start researching!

  • 00:16:00

    Ep. 27 - Hackers stole my website...and I pulled off a $30,000 sting operation to get it back

    The freeCodeCamp Podcast starstarstarstarstar

    For several days not that long ago, Jordan Reid's site, ramshackleglam.com, did not belong to her. She got it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a massive sting operation. Here's her story.

    Written by Jordan Reid: https://twitter.com/ramshackleglam

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2EA3OjL

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    For several days not so long ago, RamshackleGlam.com — the domain name that I have owned and operated since March of 2010 — did not belong to me, but rather to a man who goes by the name “bahbouh” on an auction website called Flippa, and who was attempting to sell off the site to the highest bidder (with a “Buy It Now” price of $30,000.00). He promised the winner my traffic, my files, and my data, and suggested that I was available “for hire” to continue writing posts (alternatively, he was willing to provide the winner with “high-quality articles” and “SEO advice” to maintain the site’s traffic post-sale).

    I learned that my site was stolen on a Saturday. Three days later I had it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a sting operation that probably should have starred Sandra Bullock instead of…well…me.

    Of course I’ve heard of identity theft, and of cyber hacking, but honestly, my attitude towards these things was very much “it could never happen to me.” And even if it did…I didn’t exactly understand why it was such a huge deal. Couldn’t you just explain to people what had happened, prove who you were, and sort it all out? We live in such a highly documented world, it seemed completely impossible to me that someone could actually get away with pretending to be someone else with any real consequences beyond a few phone calls and some irritation.

    It’s much, much worse — more threatening, more upsetting, and more difficult (if not impossible) to fix — than I’d ever imagined.

    I found out about the hacking from my father. His friend Anthony (who runs a web development and consulting company called ThoughtBox) had been surfing around on Flippa and had — in an impossibly lucky coincidence — noticed that my site was up for auction, with what appeared to be a highly suspicious listing. Suddenly, I remembered the email I had gotten the day before — an email that I had disregarded as spam — from someone “interested in the purchase” of my “weblog.” I remembered the notification from YouTube that someone had accessed my account from a different location — a notification I had ignored, assuming that I had logged in on a mobile device or that my husband had accidentally logged into my account instead of his own.

    But even after I saw the listing, I didn’t panic: this seemed like something that could be fixed with a couple of emails. Except the auction site was located in Australia and didn’t appear to have a phone number, and when I sent an email with a scanned ID and proof of ownership what I got back was a form letter. And when I called HostMonster, the site I pay to operate my website, I discovered that I was no longer the owner of my site: someone had used their email confirmation system to authorize the transfer of my domain name into a private account at GoDaddy (another web registrar service of whom I’m also a client).

    Why is this a big deal?

    If you have a business that depends on a URL, you understand why this was such upsetting news: With control over my website’s domain name, a hacker would be able to take the site down, or redirect it elsewhere. Further, it was later verified that the hacker had control over all of the site’s content, as well; he could have just rerouted everything I’ve ever written to any location he wanted.

    Ramshackle Glam may be “just” a lifestyle blog about things like parenting and fashion and decor…but it’s also a site that I’ve spent five years of my life building, and the idea of it falling into the hands of someone with malicious intent was heartbreaking. I could switch to a new URL and export a copy of my content (which I do back up), but that would result in the loss of a substantial amount of traffic. The website is my primary source of income, and with a house, two children, a book coming out, and a husband in business school, this was not a joke. The loss of my URL had the potential to be devastating for my business and for my family in a very real way.

    So what did I do?

    The events of the next few days were complicated, so rather than go through them chronologically I’m going to explain how each path I took ended up panning out (I’m going into detail so that I can be as much help as possible to anyone who goes through this themselves).

    1. I tried to resolve the situation directly with GoDaddy and HostMonster. This did not work.

    From Sunday through Tuesday, I spent most of the day (and much of the night) on the phone with GoDaddy, HostMonster, or both at the same time, and nearly every person I spoke with gave me the same response: “Sorry, can’t help you.”

    HostMonster maintained that because they no longer controlled the domain name, there was nothing they could do. GoDaddy maintained that because the account was private and the person had obtained ownership of the domain through a transfer from HostMonster, there was nothing they could do.

    What finally made a difference: I cited ICANN’s policy on Domain Name Dispute Resolution.* This got my case upgraded, but it did not result in action.

    Here’s why: the legal department at HostMonster informed me that in order for them to initiate a transfer dispute that would result in GoDaddy releasing the domain back to me, their “internal investigation” would have to turn up evidence that they had done something wrong in releasing the site. In other words, they would have to admit that they had screwed up…which would in turn open them up to a lawsuit.

    Needless to say, I never heard from the legal department again. Despite the fact that everyone seemed clear on the fact that I owned my website and that it had been transferred without my authorization, nothing was going to be done unless I initiated a time-consuming and costly lawsuit that, in any case, would not result in action quick enough to save my domain name from being sold.

    So that avenue came to an end.

    2. I called the FBI. This was a major step in the right direction.

    The morning after I found out about the unauthorized transfer, I also called the FBI. I felt silly and dramatic making the phone call, but the reality is that this is an international cyber crime issue, and that’s FBI territory. And this is my business. It’s how I support my family, and it may be a “small matter” in the grand scheme of things, but it is not a small matter to me.

    And let me tell you: of all the surprises I’ve had over the past week or so, most surprising of all has been the FBI. They responded immediately, with follow-up phone calls and emails, an in-person interview with two special agents at my own home within 24 hours, and a follow-up visit from two agents yesterday. Beyond that, each and every agent I have interacted with over the past week has been, without fail, compassionate, thoughtful, invested, respectful, and committed to action…in addition to treating me not like a case number, but like a human.

    What I expected was to leave a message with a general mailbox and at some point receive a form letter; I certainly did not expect to see an active investigation opened immediately. I’m not going to write more about the investigation because it’s still ongoing (although I did ask for and receive permission to write about this), but I think it’s important to say how absolutely blown away I have been by the FBI’s response.

    3. I tried to regain control by dealing directly with the “seller”. This worked, but not without considerable drama.

    While all of the above was going on, I was also working to regain control over the site directly from the individual who was trying to sell it.

    I didn’t want to contact the “seller” directly, because I felt that if he thought the “real” owner of the site was aware of the sale, he would try to extort more money. So I asked Anthony — the person who had found the original listing, and who had an active account with a positive history on Flippa — to DM “bahbouh” to see if he was interested in a “private sale”. After some back-and-forth we reached an agreement, and it was decided that a third-party money-transfer website (Escrow.com) would be used to make the sale: the money would only be released to the seller upon confirmation that the domain name had been transferred.

    This appeared to be going smoothly until Tuesday night, when the seller suddenly demanded that the funds be released immediately (prior to receipt of the website). When we pushed back, he announced that he was selling it to someone else: “Sorry, bye.”

    So here was my thought process: if we did not release the money to the seller, we were guaranteed to not get the website. If we did release the money to him, there was a possibility that he would take the money and run, and also a possibility that he would deliver the site as promised. It wasn’t a gamble I wanted to take…but I didn’t see any option. And so I authorized the wire transfer.

    I spent twenty minutes sitting in front of the dummy GoDaddy account I had created to receive the domain name from the seller, waiting to see whether I was out thousands of dollars and a domain name, or just thousands of dollars.

    And then it came through.

    I immediately transferred the domain into a different account and placed it (and all of my other domain names) on what amounted to lockdown. And then I called the wire transfer company and placed a stop on the payment.

    The end result

    RamshackleGlam.com is back in my possession, thanks to a number of people who dedicated hours (in some cases days) out of their lives to doing whatever they could to help me. My other accounts — bank accounts, et cetera — have been secured. I don’t have my money back yet, but the man who stole my site from me doesn’t have it, either, and won’t be getting it, ever.

    And that’s an ending I’m pretty damn thrilled with.

    So why am I still angry?

    Of course I’m angry with the person or people who stole the site, but that’s out of my hands. The reason I’m writing this post is to let people know that this really can happen — to anyone — and to offer suggestions for how to minimize the chances that it will happen to you (below), but beyond that, I’m writing this post because this incident made me very, very angry at GoDaddy and HostMonster. And I want you to know why.

    No one at either company questioned my statement (supported by written proof) that the website belonged to me. No one doubted that it had been transferred without my authority. And yet I had to spend days — days during which the hacker could have done virtually anything he wanted — trying to reach one single person who was able to do anything, because the support staff and supervisors I spoke with (who had to have numbered fifty or more) were completely uninformed as to how to handle this situation beyond saying, “Jeez, that sucks. Can’t help you.”

    And once I reached people who could help me — who could literally make a single phone call or push a single button and return my property to me (or simply freeze it so that it could not be sold or destroyed) — they would not. They hid behind their legal departments and refused to do anything, knowing full well that their inaction would force me to either interact with and pay off a criminal, or lose an essential component of my business.

    And hackers know that these companies will do this.

    They rely on it.

    There is a serious problem when a criminal enterprise not only exists “despite” a company’s policies, but actually thrives as a direct result of that company’s prioritization of their own interests over the security of the clients they allegedly “protect”. Do I understand why companies like HostMonster and GoDaddy are focused on protecting themselves against lawsuits? Of course I do. But the fact is that they not only do not “help” their customers, but actively contribute to creating situations that threaten small businesses and the families that they support.

    And these companies know that when they stonewall clients whose property has obviously been stolen that these clients will have no other recourse than to pay off criminals or watch their businesses — sometimes their very lives — collapse. They know that by standing in the way of immediate action they create the very environment that these criminals depend upon to perpetuate their business model. And they do nothing.

    This has to change.

    My opinion, for what it’s worth

    Support personnel at hosting companies should be made intimately familiar with ICANN regulations involving domain disputes, and should be able to initiate a plan of action the first time a client makes them aware of a situation, not after hours and hours of repeated calls.

    Further, the establishment of a TEAC** should result in an immediate freeze on the account in dispute until the situation has been resolved. This should not require an admission of culpability on the part of any parties; simply an acknowledgement that a dispute exists and an awareness that while the dispute exists the domain must be held safe from sale or transfer.

    What you can do to reduce the chances that this will happen to you:

    Have a really, really good password, and change it often. Your password should not contain “real” words (and definitely not more than one real word in immediate proximity, like “whitecat” or “angrybird”), and should contain capital letters, numbers and symbols. The best passwords of all look like total nonsense.

    If possible, use a separate computer (an old one or a cheap one purchased for this purpose) for things like banking; if your family computer is the same one that you use for bank transactions you risk having your kids click on a bad link that results in a hacking.

    Turn off your computer and personal devices when they’re not in use.
    Have antivirus software on your computer (but remember that virus scans only catch 30–40% of viruses, so unfortunately a “clean” check doesn’t necessarily mean that you’re safe).

    Purchase CyberRisk Insurance (learn more about it here; it basically protects businesses from cyber attacks and data breaches.

    But if it does happen to you, here’s what to do:

    Begin taking careful notes (and screenshots) immediately. Don’t delete any emails or other information; it could all be important later on.

    Immediately change all of your passwords (including — but not limited to — domain registrar, website hosting, website login information, email, bank accounts, wireless home electronics, and Apple ID) according to the rules stated below. I changed mine every few hours while this situation was still up in the air, and am continuing to change them every few days for the time being.

    Contact the registrar(s), citing the ICANN policy below, and see if together you can arrive at a speedy resolution. Don’t be surprised if you find yourself running into dead ends.

    Make sure to inquire about “filters” and “rules” that may have been placed on your email (basically, any kind of device that the hackers may have placed to forward emails, et cetera).

    Contact appropriate law enforcement (I contacted the FBI because it appeared to be an international issue, and was at the very least an interstate issue because Escrow.com is located in California, and I’m in New York).

    Note: Every situation is different, and I can’t wholeheartedly recommend the steps that I took that ultimately resulted in me regaining control over my domain name largely because they involved interacting with criminals. Obviously that isn’t ideal, and can have unpredictable consequences. (Although my husband says that he would like it to be known that he thinks I’m a huge badass. While this is ordinarily very far from the truth, in this specific instance…I’ll take it.)

    The End. (That was long. Thanks for reading.)

    *ICann.Org is the Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and coordinating the Domain Name System (DNS). ICANN’s policy on Domain Name Dispute Resolution essentially states that in the case of a domain dispute, the Losing Registrar (the registrar that maintained possession of the domain name pre-transfer, as opposed to the “Winning Registrar”, who maintains possession of the domain name post-transfer). must immediately establish a Transfer Emergency Action Contact (“TEAC“) in an effort to get the ball rolling in the direction of resolution right away). Once I had this information, my case was immediately upgraded.

    **TEAC: A contact that is established by ICANN and used by other registrars and ICANN if there is a need to quickly address issues with domain transfers between two registrars. The contact must respond to inquiries within four hours, though final resolution may take longer.

  • 00:28:12

    Ep. 26 - The Essential Guide to Take-Home Coding Challenges

    The freeCodeCamp Podcast starstarstarstarstar

    Jane wanted to help others with non-traditional backgrounds succeed on take-home coding challenges. So she wrote an extensive guide for anyone who has received such a challenge and wants to attack it in the best possible way. She divulges mistakes to avoid, how to get organized, and how to go above and beyond.

    Written by Jane Philipps: https://twitter.com/janephilipps

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2t5215F

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02



    Hi, I’m Jane. I wrote this guide because I want to help others with non-traditional backgrounds succeed on take-home coding challenges. Please read it, take notes, apply the material, and let me know about your results. You can reach me via email at jane@fullstackinterviewing.com.

    This guide is intended for anyone who has received a take-home coding challenge as part of the technical interview process and wants to attack it in the best way. This Essential Guide is a distilled version of a longer Ultimate Guide to Take-home Coding Challenges, which goes into much more detail and walks through an example challenge from start to finish.

    So, if you’ve just received a challenge and are anxious to get started, start here, and then check out the full guide when you want to learn the material more deeply. Good luck!

    Mistakes to avoid making when working on a take-home coding challenge

    There are several mistakes you can make with take-home challenges. Some of these are small mistakes that are easily correctable, while others will leave you frustrated and unable to finish your assignment. I want to address these mistakes first, so when you’re given a take-home challenge, you know exactly what not to do.

    Here are four mistakes you can make:

    1. Time management and scope creep

    2. Trying to learn too many new things at once

    3. Making too many assumptions

    4. Starting to code right away

    Let’s look at each one in detail.

    1. Time management and scope creep

    Time estimation is one of the hardest problems in programming, and even experienced engineers struggle with it. This plays into take-home challenges in a couple of ways.

    First, some challenges come with “estimated time.” I usually ignore these, as they are rarely based in reality. Second, some challenges are open-ended. Many people, especially newer developers, will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you keep the scope relatively narrow, but finish everything you set out to do. In this situation, it’s better to do one thing really well than to do a million things poorly.

    A good question would be: what counts as “going above and beyond” versus what counts as “scope creep?” My rule of thumb would be if your idea accomplishes or improves on the requirements of the assignment, that is likely a good idea, but if it seems tangentially related or “just cool,” it’s probably scope creep. But, as I describe later, always make it work first.

    2. Trying to learn too many new things at once

    While a take-home coding challenge can be an excellent opportunity for learning, it is possible to take on too much learning. If you’re given a challenge where you must use a specific language or framework, but you’re not familiar with it, don’t add additional complexity by setting out to learn something new on top of that. For example, if you are using a new backend framework for a full stack app, stick to a frontend framework that you’re already comfortable with.

    If your challenge is language/framework agnostic, but you’ve been itching to try out some new technology, pick JUST ONE to experiment with. Between reading the docs, getting your challenge properly set up, and getting used to any new syntax, you will have your hands full. Even learning one thing will eat up a lot of your time, so I would highly suggest limiting yourself to one new piece of technology per challenge.

    3. Making too many assumptions

    As a developer, if you make too many assumptions, you are bound to build an application where the requirements are off, or the user experience is bad. When given a set of requirements for a take-home challenge, ALWAYS take the time to review the requirements and make sure you fully understand them. And, if you have any questions at all, always ask.

    First, this shows that you are willing to ask for help when you don’t quite understand something, an important trait for a developer to demonstrate. Second, many companies will intentionally give you product requirements that are vague or not fully fleshed out in order to see how you react in these situations. They are actually testing your ability to make sense of requirements that may have gaps in them.

    So, when in doubt, ask questions. Asking questions is also a signal that you are engaged and interested in the challenge.

    4. Starting to code right away

    One last mistake you can make is to jump in and start coding right away. I guarantee if you do this, you will regret it. Why? Two reasons:

    Without proper planning, your code will suffer

    Without first getting organized and making sure you fully understand ALL of the technical requirements, you may find yourself missing edge cases or rewriting parts of the functionality. I know it seems counter-intuitive, but you will actually SAVE yourself time if you plan ahead.

    You will spin your wheels trying to get your app set up properly

    Especially for newer developers, initial app setup can be one of the hardest parts of a take-home coding challenge. It’s not something you do every day, so it often takes some research and reading documentation to get reacquainted with the process and ensure you’re going about it in the best way.

    So, there you have it — a summary of mistakes to avoid making. You’ll find that a lot of these are also applicable to your day to day work as a developer. In the next section, we’ll dive into further detail on how to get organized before you write a single line of code.

    Get organized: how to plan before you write a line of code

    Now it’s time to get to work! But, it’s NOT time to write any code YET.


    Because, as you’ll see, a lot of the work actually happens before you write a single line of code. This may seem counterintuitive, but again — the more time you spend up front planning, the less time you will spend writing code.

    So, now you have your coding challenge in hand and you are ready to get started with the planning process. Here are my six suggested steps:

    1. Understand the requirements and ask any questions

    2. Identify technical decisions you need to make

    3. Technical design & whiteboarding

    4. Test plan

    5. App setup plan

    6. Organize your tasks

    1. Understand the requirements and ask any questions

    First, you need to make sure you completely, absolutely, 100% understand the requirements of the project. If any part of the requirements are unclear, it is up to you to reach out to your contact and ask questions.

    Sometimes companies will purposefully make their requirements vague, in order to see how you approach the problem. In these cases, it is always best to ask questions as it shows you are thinking about the problem and not just making assumptions and building an app to a vague spec.

    2. Identify technical decisions you need to make

    Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time.

    3. Technical design & whiteboarding

    Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes:

    You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes.

    Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions.

    Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources.

    4. Test plan

    Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later.

    5. App setup plan

    If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly.

    If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck.

    6. Organize your tasks

    The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road.

    Here is an example task list for a classic Tic Tac Toe app:

    - Understand requirements
    - Choose technologies
    - Brainstorm test plan
    - Hello World app setup
    - Build board with HTML/CSS
    - Implement Tic Tac Toe gameplay with Javascript
    - Add reset button
    - Make board responsive
    - Add ability to add additional boards
    - Error handling & tests
    - Code cleanup
    - README

    Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks:

    - Add a click handler to each square that logs a message
    - Get click handler to add an X to the square that is clicked
    - Get clicks to alternate between X and O
    - Don’t allow a square to be clicked more than once
    - Implement a function to find the winner and end the game
    - Handle a tie game

    3. Writing tests: just do it!

    Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing.

    Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine.

    First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook.

    Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more!

    How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases:

    1. Test the happy path

    For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins.

    2. Think about variations on the happy path

    A variation on the happy path would be if O wins, or if there is a tie game.

    3. Think of edge cases

    An edge case would be if a player tries to play a move in the same square more than once.

    4. Test anything that is complex

    The algorithm to find the winner is the most complex part of this example.

    Here’s a sample test plan:

    - Test that the initial state of the board is correct (i.e. board is
    visible and empty)
    - Test that a move can be played
    - Test that moves alternate between X and O
    - Test that a move can be played to a square only once
    - Test that a winner can be found in a row
    - Test that a winner can be found in a column
    - Test that a winner can be found in a diagonal
    - Test that a draw can be found

    So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write.

    4. Make it work, then make it pretty, then make it fast

    The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER:

    1. Make it work

    2. Make it pretty

    3. Make it fast

    1. Make it work

    When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else.

    This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components.

    So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization.

    Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing.

    2. Make it pretty

    Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it.

    If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature.

    For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks.

    3. Make it fast

    Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy.

    You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long?

    If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things.

    How to make your code shine

    When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine.

    When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files.

    There are several things you can do to make your code stand out. You want your code to be:

    Easy to follow
    Well organized
    Clean (properly indented, free of syntax errors and unnecessary whitespace)

    These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations:

    1. How to name things

    2. How to use comments effectively

    3. How to format your code as you write it

    1. How to name things

    Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand.

    For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick.

    One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them.

    2. How to use comments effectively

    Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it.

    Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments.

    Here is where you most likely do not need comments:

    When you declare a variable
    When you declare a function

    The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name!

    Here are some examples of where comments can be useful:

    Technically tricky lines of code

    First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of s. Comments can be a good way to signal which tags close which sections.

    In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update.

    Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application.

    One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment.

    You are almost done learning how to make your code shine! Just one more step.

    3. How to format your code as you write it

    I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal.

    So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything.

    Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others)

    Indent your code properly as you go so that it stays readable and isn’t all over the place

    Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code.

    Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it!

    Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app.

    Always leave a newline at the end of every file

    That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward!

    How to take your challenge to the next level

    Here are 3 ideas for how you can take your coding challenge to the next level:

    1. Bonuses

    2. UI/UX design (for front-end or full-stack challenges)

    3. Data validation and error handling

    1. Bonuses

    Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer.

    2. UI/UX design (for front-end or full-stack challenges)

    Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it.

    3. Data validation and error handling

    Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations.

    How to write an awesome README

    You may be done writing code, but you’re not done writing yet — it’s time to write your README.

    Why you should include a README

    READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation.

    Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games.

    Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge.

    How to write your README

    Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include:

    1. Installation instructions

    2. Discussion of technologies used

    3. A section demonstrating that you met the requirements

    4. If there are bonuses, a section demonstrating that you met them

    5. For algorithms and data structures, time and space complexity

    1. Installation instructions

    When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README.

    2. Discussion of technologies used

    This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs.

    3. A section demonstrating that you met the requirements

    Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it.

    4. If there are bonuses, a section demonstrating that you met them

    Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work.

    5. For algorithms and data structures, time and space complexity

    If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation.

    One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer.

    Final steps before you hit send

    Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist:

    Re-read the take-home challenge instructions to make sure you didn’t miss any requirements

    Review your app’s code to ensure that it shines

    Run your app’s automated tests and make sure they are all passing

    Test your app manually and make sure everything is working properly

    Test your app installation instructions from your README

    Start an email draft and copy your README into it for convenience

    If requested, make sure to attach a zip file of your code

    Write an email to your contact at the company

    Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example:

    Hi ,
    I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions.
    Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at , so I’m looking forward to hearing from you!

    Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time.

    Now, finally, hit send!


    I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at jane@fullstackinterviewing.com.

  • 00:07:05

    Ep. 25 - I'm 56 and learning to code. Here's an epic beat-down of my critical inner self.

    The freeCodeCamp Podcast starstarstarstarstar

    If you're over the age of 20, you might think you're too old to learn how to code. But 56 year old VM Vaughn's here to tell you that's not true. In this podcast, he shares his epic beat-down of his critical inner self and lays out his path towards an exciting second career.

    Written by VM Vaughn: https://twitter.com/vmvaughn

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2oJnBY1

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    I’m 56 years old and learning to code.

    Why? Because I love it. And I’ve got a knack for it.

    That doesn’t mean it’s easy. It’s hard. And that’s OK.

    I love losing myself in an algorithm challenge. I love squeezing in a few extra minutes testing just one more thing. I love thinking “maybe I’ve got it this time.” And getting to “Yes! It finally works!”

    But here’s the thing. I’ve never been one for hobbies. I don’t like activities that don’t pay. I can’t keep on doing something simply for the fun of it.

    What I work on during my off time has to have some economic upside for me.

    OK, coding pays. It can pay big. So what’s the problem?

    Well, before I could fully embrace myself as a 56-year-old programming rookie, I had to deal with my Critical Inner Self (let’s call him CIS for short).

    Learning all this stuff is hard enough without my CIS whispering in my ear the whole time.

    If I can give my CIS an epic beat-down, then I should be able to handle anyone who appears to work on his behalf. And these agents of CIS often appear out of no where, asking critical questions.

    CIS: Why are you doing this at your age?

    Me: What you really mean is how much longer will I live. And do I really have enough time left to make money programming. Let’s break that down.

    I’m an American. My life expectancy is 78.8 years. So that means I’ve got a better than average chance of living another 22.8 years. That may not seem like a lot when you’re 20, but I’m 56 and dancing in the street over here.

    (And because I’m 56, I’ve got better odds of making it to 78 than a 20 year old. But that’s beside the point.)

    Now, let’s say I’m a snail and it takes me 4 years to finish Free Code Camp’s 1-year curriculum to become a fledgling full stack developer. That puts me at 60 years old looking for a job as a junior developer.

    Let’s say it takes me another 2 years to land a job because of my age, and let’s assume that 70 is the limit for how long an employer wants me hanging around.

    That’s 8 years to practice my craft. That’s plenty of runway to get pretty good. And because I’ve been around the block and know the grass ain’t always greener on the other side, I’m much more likely to stay with that employer who hired me first.

    What 20-year-old stays with their first developer job that long?

    CIS: But who’s going to pay you the kind of money that you already make now?

    Me: You could ask me that even if I didn’t learn to program. But I know what you’re getting at. Chances are an entry level developer job will pay me less than I’m making now.

    Well here’s a thought for you. My paycheck is less today than it was five years ago. And that’s with 5 more years of experience.

    There’s no guarantee that the job I have now will last. And when it doesn’t, I’ll have to find a new job anyway. At my age, I very well may have to accept entry level wages doing something… anything.

    I’d rather have the skills and portfolio to go for an entry level position that can lead to much greater earnings — or at least the ability to beat the bushes and pick up some freelance work.

    CIS: But all the big tech companies want to hire young kids right out of college.

    Me: That’s easy. I don’t want to move to Silicon Valley and I’m not looking to work for a big tech company.

    You’ve read the same stats as me. By 2020 there will be 1,000,000 more programming jobs than people trained to fill them. Not all of those openings will be at the “big 4” — Google, Facebook, Amazon, or Microsoft. In fact, most programming jobs aren’t even in the technology industry.

    My first computer job was in a hospital. I didn’t program, but most of the employees in the IT department were programmers.

    And that was way back in 1982.

    CIS: Then how are you going to get a job?

    Me: First things first, I’m going to apply to a lot of jobs, build a network of hiring managers, and make sure I get a lot of interviews. It’s a numbers game and I’m going to play it.

    All that wonderful stuff I did before the year 2000? Gone from my resume.

    Once I’m in the door for an interview, it’s not like I’m going to act like someone’s grandfather. I’ll be just another candidate who’s passionate about programming and excited to learn more. And I won’t act like I know more than I do.

    And most importantly, I’ll be prepared for common coding challenges and whiteboard interview questions.

    I’m sure I’ll mess up a few interviews. But the good news? There are plenty of companies out there hiring developers. I’ll keep trying.

    CIS: Programming teams are full of young people. How are you going to fit in?

    Me: If by “fit in” you mean how do I become one of the bros? In that case, you’re right. I won’t fit in.

    At my current job, I show up every day knowing that somebody at work has something to teach me. So I listen. I don’t presume to know everything that’s going on in my boss’s day, so I give him a break. And when I mess up, I say so.

    That’s how I’ve fit in at every job I’ve had over the last 36 years.

    CIS: You’ve got a decent job. Why not just accept it? You are where you’re going to be, especially at your age.

    Me: Accept it? Too late. I’ve already re-framed it.

    Learning to program energizes me. Working toward a second career gives me the boost I need to get through the daily slog of the one I’ve got now.

    And really? You know where I’m going to be at 60, 70, and (hopefully) beyond? I sure don’t.

    CIS: How do you know you’re not just wasting time?

    Me: What you’re really asking is: “What if you don’t get a 9-to-5 paycheck after this?”

    My answer: “So what?”

    I can get good enough, in time enough, to program well enough:

    to build web apps to build an audience…and offer them even more value from my billable services.

    to grow a web business helping local businesses grow and nurture their own customers.

    to combine my programming know-how with existing SaaS APIs to offer a productized service to a niche community.

    To put it another way, I can learn how to build an idea. To put it out there for people to use. To offer value. To make money.

    With or without a 9-to-5 J.O.B.

    So that’s why even though I’m 56, I’m learning to code.

  • 00:16:48

    Ep. 24 - How to run a successful development process (even if you're not technical)

    The freeCodeCamp Podcast starstarstarstarstar

    This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team’s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome.

    Written and read by Jonathan Solórzano-Hamilton: https://twitter.com/jhsolor

    Original article: https://fcc.im/2GW6xFX

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    Laurence Peter formulated the principle that “managers rise to the level of their incompetence” in 1969. In particular, non-technical leaders have earned a poor reputation with software developers.

    Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic “Pointy-Haired Boss.”

    This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team’s water-cooler jokes. I’ll share what I’ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University.

    The biggest lesson I’ve learned is that the key to sustaining successful software releases is completely non-technical.

    It’s about process.

    Some aspects of a development process benefit from technical know-how, but it’s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone.

    For the purpose of this article, we’ll assume you’ve already agreed to start building something. The product approval pipeline is a different process. Today we’re focusing on getting the agreed-upon product from concept to production.

    What to build

    Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too.

    Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well.

    Technical expertise lets you use these schematics to critique your team’s architecture and ensure they’re on the right track. Even without technical skill, these schematics will be critical.

    You can use them to drive productive conversations about product completion. No more will you have to draw a “% complete” out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components.

    There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement.

    What not to build

    Your team can’t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build.

    Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team’s time should go toward supporting that differentiation.

    The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses.

    Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range.

    The first Tesla prototype simply converted a pre-existing electric sports car from lead-acid to lithium batteries. Their first production run was mostly a Lotus Elise roadster (a pre-existing sports car) that had a Tesla battery and motor.

    The lesson for your team is to use what already exists wherever possible. If you can use or adapt a FOSS package, do it. Even if you need to license for-pay code from somewhere else, it’s almost always worth it.

    Get all the scaffolding in place quickly so you can test your “lithium-ion battery.” Then you can iterate through and replace whatever will help further differentiate your product without stressing about delaying production-readiness.

    The second checkpoint of your development process is to review the planned architecture with your team and identify what very limited part they intend to build from scratch.

    If it sounds like something that already exists, and it’s not the core focus of your product, challenge your team to see why they believe they need to re-do it.

    Don’t just throw it over the wall

    Once you have identified what pre-built technologies you’ll use, make sure to review these with your production support group.

    Database and server administrators will need to plan for installing and supporting any new technologies. This is the third checkpoint in your development process: operations readiness.

    Keeping the production support team in the loop early is 90% of the secret sauce known as “DevOps.” If you haven’t heard of this, DevOps is the idea that software development and production operations teams should unify under common goals.

    The proposed benefits include much quicker releases, more reliable code, and more time spent developing due to automation. These are all great boons, but they follow from a strong communication process. Automation follows, not replaces, collaboration.

    Implementation and Testing

    Now your team writes the code. Collaborate with your implementation team to devise a process for dividing the work among themselves. There’s no one-size-fits-all approach, and this is where the “soft skills” of leadership dramatically outweigh any technical skill.

    Some developers will want to hog all the “interesting” work and ignore any drudge work. They may believe that they’re the smartest person in the room and should get their pick of assignments. Others may resist change and only want to do the same kind of work they’ve done before.

    Lead your team into an equitable distribution of work. Challenge everyone to grow appropriately and to share and collaborate.

    One more technical aspect of the implementation is that the code must include sufficient automated tests. These are code-defined tests that a test system can execute.

    If the code’s going to crash, don’t you want these guys’ resumes to be on the line instead of your own? (public domain: US Government photo)
    Manual “test scripts” where a human interacts with the code to see if it works are insufficient and reflect technical debt. Your technical team should at least include unit tests. Test-driven development is a popular approach for ensuring that critical code is always tested.

    You can drive a non-technical conversation with your team about their “test coverage” (the portion of the code that is tested). It’s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions.

    The checkpoint at which the code is believed complete by the developers is referred to in my shop as dev-complete. It means the primary development (dev) process is over, but additional code may be written to address issues that come up in the review process.

    In an agile development process, you will typically divide the implementation process into multiple checkpoints instead of one all-or-nothing deadline. These are typically called iterations.

    Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you’ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk.

    As you complete the iterations, you can push the code to an environment for “acceptance testing.” This involves pilot or test users (or an internal team playing that role) who interact with the partial product. They test to ensure it meets the design expectations and provide feedback on how it could be better.

    Acceptance testing is not a substitute for the unit testing mentioned earlier. It serves a different purpose. Letting your development team lean on acceptance testing to catch basic functional bugs is a recipe for disaster.

    Feedback from the acceptance testers can be incorporated into the next iteration. This is another good reason not to bite off a big chunk of the product all at once. You want to leave room to change course once people start playing with the product.

    Once you’ve accumulated enough tested code to constitute a sufficient product release, you’re ready to begin the release management process.

    Looking for bugs in all the right places

    Your developer or team has reached a point where they believe the code is done. Acceptance testers are satisfied with the way the product is working. The next checkpoint in the process is to validate the belief that you have code ready to become a product. Let’s start reviewing the code!

    You may not be comfortable or have sufficient technical know-how to review the team’s code yourself. That’s ok! You don’t have to. Your process has to.

    Work with your team to identify a process for code review that works for them. If you have more than one developer, peer code review works great. If you don’t, are there other developers in your organization outside of your team? Work across team boundaries to establish a peer code review program.

    If there really is only one developer, then sit down with them and have them walk you through the code. Use your schematics as a reference point, and ask them to tell you how the code accomplishes the schematic’s goals.

    At the conclusion of the code review process, the developer and reviewer(s) should feel comfortable with being held accountable for the code.

    The code review is also a good time for reviewing two other critical points: documentation and security.

    I’ve already written about a sustainable documentation architecture — check it out if you’re interested!

    Security review should be a part of any code review. In general, this involves taking a second look at the code to spot weaknesses where an attacker could exploit it to reveal private data or gain control of the server. It must be done by a technical person.

    The Open Web Application Security Project (OWASP) publishes a free comprehensive guide to security review.

    Your developer can do this if they’re the only one on the team, even if they just run an automated security code analysis tool. There are free tools for helping with this process which are linked through the OWASP wiki.

    Eject, eject, eject!

    The code has passed the review process. It’s ready to become a product. But that doesn’t mean it’s ready for production.

    The last checkpoint to clear is deployment readiness. Is your code in a state where it’s easy to deploy to production? This should involve as few manual steps as possible.

    It also means you need to have a plan for reverting the change in case the code doesn’t work as planned. This is called a “rollback plan.”

    If you have a separate software operations team, this is where they come back into the picture. They should review the deployment and rollback documentation and let you know if it’s sufficient.

    If you don’t have these personnel you can perform this step yourself. Make sure that there are clear, simple instructions for deploying the product. There should be very few manual steps, as each manual step introduces a chance for human error.

    There should be a clear, sufficient plan for returning to the prior state of affairs if the deployment doesn’t succeed. This may be as simple as restoring a backup, or it may involve customer communication or data conversion.

    Whether the plan is sufficient depends on how thoroughly your team tested the code, and how widely the product is being released. Consider also any risks associated with the product or with this particular release.

    Once you’ve passed this checkpoint, push that code into production!


    Succeed or fail, it’s important to circle back and review how the process went.

    Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed.

    How is the product running in production? It’s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road.

    Where are the remaining gaps in your product? If they’re in third-party code, now’s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release.

    Above all, hold yourself and your team accountable for the results of your effort.

    Accountability facilitates independence and promotes individual growth. As your team grows accustomed to being held accountable for each step in this process, they’ll adjust their performance accordingly.


    You don’t have to be the least bit technical to run a successful software release process. Technical skill can help, but it can also become a crutch.

    The key to successful software release is a well-documented, well-understood process for moving software through the pipeline from idea to product. You now have a starting point for drafting your own software release process.

    What’s most important is that you participate with your team in filling in the blanks and creating a repeatable process that works for all of you.

    It doesn’t have to be perfect for anyone, but it does have to be understood by everyone.

    You also need to ensure that the velocity of your product through these checkpoints matches the demand for the product. None of these items need to be multi-day show-stoppers. It could be a simple one-page checklist. You need to define a process that fits your environment.

    As with any process, you should also iterate. Just like with the code, your first, untested draft isn’t likely to be perfect. Tune the process on each run-through and you’ll end up with a smooth, predictable software release path.

    And remember to brush your hair. You don’t want it looking…pointy.

  • 00:12:45

    Ep. 23 - We studied how students performed in technical interviews. Where they went to school didn't matter.

    The freeCodeCamp Podcast starstarstarstarstar

    Given the state of college recruiting today, your chances of interacting with companies on campus are slim - unless your campus is a top school. It’s not fair, and it sucks, but that's the way it is. But does it have to be? Does where you went to school really affect your performance in technical interviews? Turns out: it doesn't.

    Written by Sam Jordan: sam@interviewing.io

    Recorded by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2Dg3HJA

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    interviewing.io is a platform where engineers practice technical interviewing anonymously. If things go well, they can unlock the ability to participate in real, but still anonymous, interviews with top companies like Twitch, Lyft and more.

    Earlier this year, we launched an offering specifically for university students. It was intended to help level the playing field right at the start of people’s careers.

    The problem

    Here’s the sad truth: given the state of college recruiting today, if you haven’t attended one of a very few top schools, your chances of interacting with companies on campus are slim. It’s not fair, and it sucks, but university recruiting is still dominated by career fairs. Companies pragmatically choose to visit the same few schools every year. Despite the fact that the career fair is one of the most antiquated, biased forms of recruiting that there is, the format persists. This is likely because there doesn’t seem to be a better way to quickly connect with students at scale.

    So, despite the increasingly loud conversation about diversity, campus recruiting marches on, and companies keep doing the same thing expecting different results.

    In a previous blog post, we explained why companies should stop courting students from the same five schools.

    Regardless of how important you think this idea is (for altruistic reasons, perhaps), you may still be skeptical about the value and practicality of broadening the college recruiting effort. You probably concede that it’s rational to visit top schools, given limited resources. Society is often willing to agree that there are perfectly qualified students coming out of non-top colleges, but they maintain that they’re relatively rare.

    We’re here to show you, with some nifty data from our university platform, that this is simply not true.

    To be fair, this isn’t the first time we’ve looked at whether where you went to school matters. In a previous post, we found that taking Udacity and Coursera programming classes mattered way more than where you went to school. And way back in the day, one of our founders figured out that where you went to school didn’t matter at all — but that the number of typos and grammatical errors on your resume did.

    So, what’s different this time? The big, exciting difference is that these prior analyses were focused mostly on engineers who had been working for at least a few years already. This made it possible to argue that a few years of work experience smoothes out any performance disparity that comes from having attended (or not attended) a top school.

    In fact, the good people at Google found that while GPA didn’t really matter after a few years of work, it did matter for college students. So, we wanted to face this question head-on and look specifically at college juniors and seniors while they were still in school. Even more pragmatically, we wanted to see if companies limiting their hiring efforts to just top schools were getting higher caliber candidates.

    Before delving into the numbers, here’s a quick rundown of how our university platform works and what kind of data we collect.

    The setup

    For students who want to practice on interviewing.io, the first step is a brief (~15-minute) coding assessment on Qualified to test basic programming competency. Students who pass this assessment (that is, those who are ready to code while another human being breathes down their necks) get to start booking practice interviews.

    When an interviewer and an interviewee match on our platform, they meet in a collaborative coding environment with voice, text chat, and a whiteboard and jump right into a technical question. Interview questions on the platform tend to fall into the category of what you’d encounter during a phone screen for a back-end software engineering role. Interviewers typically come from top companies like Google, Facebook, Dropbox, Airbnb, and more.

    After every interview, interviewers rate interviewees in a few different categories, including technical ability. Technical ability gets rated on a scale of 1 to 4, where 1 is “poor” and 4 is “amazing!” On our platform, a score of 3 or above has generally meant that the person was skilled enough to move forward.

    On our platform, we’re fortunate to have thousands of students from all over the U.S., spanning over 200 universities. We thought this presented a unique opportunity to look at the relationship between school tier and interview performance for both juniors (interns) and seniors (new grads).

    To study this relationship, we first split schools into the following four tiers, based on rankings from U.S. News & World Report:

    “Elite” schools (like MIT, Stanford, Carnegie Mellon, UC-Berkeley)
    Top 15 schools (not including top tier, like University of Wisconsin, Cornell, Columbia)
    Top 50 schools (not including top 15, like Ohio State University, NYU, Arizona State University)
    The rest (like Michigan State, Vanderbilt University, Northeastern University, UC-Santa Barbara)

    Then, we ran some statistical significance testing on interview scores vs. school tier to see if school tier mattered for both interns (college juniors) and new grads (college seniors). Our sample comprised a set of roughly 1,000 students.

    Does school have anything to do with interview performance?

    In the graphs below, you can see technical score distributions for interviews with students in each of the four school tiers (see legend). As you recall from above, each interview is scored on a scale of 1 to 4, where 1 is the worst and 4 is the best.

    What’s pretty startling is that the shape of these distributions, for both juniors and seniors, is remarkably similar. Indeed, statistical significance testing revealed no difference between students of any tier when it came to interview performance.

    Just to note: of course, this hinges on everyone completing a quick 15-minute coding challenge first, to ensure they’re ready for synchronous technical interviews. We’re excited about this because companies can replicate this step in their process as well!

    What this means is that top-tier students are achieving the same results as those in “no-name” schools. So the question becomes: if the students are comparable in skill, why are companies spending egregious amounts of money attracting only a subset of them?

    Okay, so what are companies missing?

    Besides missing out on great, cheaper-to-acquire future employees, companies are missing out on an opportunity to save time and money. Right now, a ridiculous amount of money is being spent on university recruiting. We’ve previously cited the $18k price tag just for entry to the MIT career fair. In a study done by Lauren Rivera through the Harvard Business Review, she reveals that one firm budgeted nearly 1 million dollars just for social recruiting events on a single campus.

    The higher price tag of these events also means that it makes even less sense for smaller companies or startups to try and compete with high-profile, high-profit tech giants. Most of the top schools that are being heavily pursued already have enough recruiters vying for their students. Unwittingly, this pursuit seems to run contrary to most companies’ desire for high diversity and long-term sustainable growth.

    Even when companies do believe that talent is evenly distributed across school tiers, there are still reasons why companies might recruit at top schools. There are other factors that help elevate certain schools in a recruiter’s mind. There are long-standing company-school relationships (for example, the number of alumni who work at the company currently). There are signaling effects, too — companies get Silicon Valley bonus points by saying their eng team is comprised of a bunch of ex-Stanford, ex-MIT ex-and so on students.

    A quick word about selection bias

    Since this post appeared on Hacker News, there’s been some loud, legitimate discussion about how the pool of students on interviewing.io may not be representative of the population at large. Indeed we do have a self-selected pool of students who decided to practice interviewing.

    Certainly, all the blog posts we publish are subject to this (very valid) line of criticism, as is this post in particular.

    As such, selection bias in our user pool might mean that 1) we’re getting only the worst students from top schools (because, presumably, the best ones don’t need the practice), or 2) we’re getting only the best/most motivated students from non-top schools — or both.

    Any subset of these results is entirely possible, but there are few reasons why we believe that what we’ve published here might hold truth regardless.

    First of all, in our experience, regardless of their background or pedigree, everyone is scared of technical interviewing. Case in point: before we started working on interviewing.io, we didn’t really have a product yet. So before investing a lot of time and heartache into this questionable undertaking, we wanted to test the waters to see if interview practice was something engineers really wanted — and more so, who these engineers that wanted practice were.

    So, we put up a pretty mediocre landing page on Hacker News…and got something like 7,000 signups on the first day. Of these 7,000 signups, roughly 25% were senior (4+ years of experience) engineers from companies like Google and Facebook. Now, this isn’t to say that they’re necessarily the best engineers out there, but it does suggest that the engineers the market seems to value the most still needed our services.

    Another data point comes from one of our founders. Every year, Aline does a guest lecture on job search preparedness for a technical communication course at MIT. This course is one way to fulfill the computer science major communication requirement, so enrollment tends to span the gamut of computer science students. Before every lecture, she sends out a survey asking students what their biggest pain points are in preparing for their job search. Every year, trepidation about technical interviewing is either at the top of the list of 2nd from the top.

    And though this doesn’t directly address the issue of whether we’re only getting the “best of the worst or the worst of the best” (and I hope the above has convinced you there’s more to it than that), here’s the distribution of school tiers among our users. I expect it mirrors the kinds of distributions companies see in their student applicant pool as well:

    So what can companies do?

    Companies may never stop recruiting at top-tier schools entirely. But they ought to at least include schools outside of that very small circle in the search for future employees.

    The end result of the data is the same: for good engineers, the school they attended means a lot less than we think. The time and money that companies spend to compete for candidates within the same select few schools would be better spent creating opportunities that include everyone. They could also develop tools to vet students more fairly and efficiently.

    As you saw above, we used a 15-minute coding assessment to cull our inbound student flow, and just a short challenge leveled the playing field between students from all walks of life. At the very least, we’d recommend employers do the same thing in their process. But, of course, we’d be remiss if we didn’t suggest one other thing.

    At interviewing.io, we’ve proudly built a platform that grants the best-performing students access to top employers, no matter where they went to school or where they come from. Our university program, in particular, allows us to grant companies the privilege to reach an exponentially larger pool of students, for the same cost of attending one or two career fairs at top target schools.

    Want diverse, top talent without the chase? Sign up to be an employer on our university platform!

  • 00:10:51

    Ep. 22 - Our team broke up with "instant legacy" code releases. Here's how yours can, too.

    The freeCodeCamp Podcast starstarstarstarstar

    The concept of a legacy usually conveys permanence, value, and greatness. But what about in relation to your code? In this article, Jonathan explains how his team broke up with their legacy codebase, why it was necessary, and how your team can do the same.

    Written and read by Jonathan Solózano-Hamilton: https://twitter.com/jhsolor

    Original article: https://fcc.im/2FEuAcR

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    The concept of legacy conveys permanence, value, and the greatness we bequeath to our children and our successors in the community.

    People make ludicrously generous donations to charitable causes to establish their legacy. They create eponymous endowments or buildings and strive to protect the name their children will inherit.

    It’s therefore striking that software developers have gotten their “legacy” so catastrophically wrong.

    Google “legacy,” and you’ll see the first definition matches what I’ve laid out for you here. It’s a definition that’s persisted since the 14th or 15th century.

    The second definition provides a shocking contrast:

    legacy. adjective (computing) “denoting software or hardware that has been superseded but is difficult to replace because of its wide use.

    Dictionaries around the internet agree with this definition. It applies only to the field of computing. We developers have managed to invert the definition of our own legacy in the historical eye-blink that is computer science. That’s almost impressive!

    If you’re an experienced developer, you’ve certainly been tasked with supporting at least one legacy system in your career. For the uninitiated, well — buy a lot of caffeinated beverages.

    I’m about to relate to you the brief story of our toxic relationship with our legacy codebase. I’ll then describe how we broke up with it, and what we’ve changed to avoid falling back into bad relationships with high-maintenance code.

    The Breakup

    It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul.

    Our predecessors had pushed code into production for years without writing a single line of documentation. In fact, some of it wasn’t even in source control, as we later learned. But that’s another story.

    I’m sure you’ve seen gems like this before:

    ... hundreds of line of incomprehensible code
    // TODO: Fix this bug!!!
    ... hundreds more lines in the same method, no idea where or what the bug is

    That is the approximate ratio and quality of the only documentation we had on the project.

    I wasn’t exposed to direct sunlight again until April, and I’d had enough. It was time for a break-up.

    The importance of documentation

    In his book “The Art of Unit Testing,” Roy Osherove defines legacy code as any code that doesn’t have tests. He was an optimist. I more loosely regard as legacy any code which contains more technical debt than the time it took to write.

    As our organization had, many development teams fall into the trap of instant-legacy code: code that already fits the “legacy code” label at the time of release.

    In my experience, documentation is the most important aspect of avoiding such legacy code.

    I have yet to meet a developer who loves the idea of documentation. On the other hand, I also have never met a developer who loves crawling inside the skull of a stranger to reverse-engineer a legacy implementation without any documentation.

    As they say, breaking up is hard to do. But in this case, I promise it will be worth it.

    So let’s get started on converting your legacy into something you’ll be proud to bequeath to your successors. Let’s get documenting!

    Our approach: four layers of documentation

    We created, and began rigorously following, a four-layer architecture for documentation. We maintain three layers of persistent documentation for the project through its life-cycle. We also communicate through one layer of ephemeral documentation during our release management process.

    The three persistent layers of documentation correlate to three different velocities in our development process. We include documentation review as part of code review to avoid falling back into bad habits.

    // The front lines: in-line comments keep maintainers sane

    The most granular tier of explicit documentation is in the code. We perform complete documentation of all classes and methods, their inputs, expected outputs, and exception pathways. We also document “unusual” code in-line.

    As a predominantly C# shop we use /// documentation ubiquitously. This decorates class, interface, and method declarations. The /// helper auto-generates XML stubs to document the nuts and bolts of the API.

    These pop up when your code is being referenced by an external project or DLL (dynamic-link library), provided that you’ve distributed the debugging files. Our IDE (integrated development environment) renders this as tool-tip help wherever a reference appears. This greatly aids developers, who are diving into our code for the first time, when trying to fix a bug or extend it for a new use case.

    It’s worth researching your language and IDE of choice to learn how to extend it with contextual help for your libraries. If you’re not used to documenting your APIs, I suggest reading these articles to get started.

    We also include regular // comments beyond API documentation. We add these wherever the code is counter-intuitive, or if we’ve found a particularly elegant solution to a problem. We also use these to create “to-do’s” for later refactor when putting in a quick-and-dirty fix.

    These are invaluable to whoever has to come along and revert the change or fix the code.

    Because it’s in-line with the source code, this documentation changes at the highest velocity — right along with the code it supports.

    README: making implementation a breeze

    We use README files as an implementer’s guide. This documentation is for whoever will be consuming our libraries. It serves a secondary purpose as tactical-level documentation of the particulars of the implementation.

    We use GitHub for source control, so we place readme.md (Markdown) files in each folder in our GitHub repository. GitHub very nicely renders Markdown files and automatically shows the rendered readme.md files in each folder. This results in a much more usable help file than a simple .txt document.

    Storing this documentation in the code-base helps developers maintain the documentation. Anyone making a code change can easily open the .MD file in their source code editor or an online markdown editor, and immediately update the documentation.

    Thus the source-controlled Markdown files live next to, but not within, the code they support. It’s also somewhat more “zoomed out” than inline comments. These two factors result in a lower velocity of updates on this documentation. Because you can still include it in the same commits it changes with higher velocity than offline documentation.

    The final advantage of this format is that anyone who downloads the source code has immediate access to the implementation guides. Coupled with the inline documentation, this provides both maintainers and consumers with sufficient documentation. They can develop a basic understanding of the project without jumping into another system, such as a wiki.

    Wiki: where business meets development

    We use the wiki-level documentation to marry the implementation to the business requirements. This documentation consists primarily of requirements, enterprise architecture diagrams and considerations, and tactical diagrams such as unified modeling language (UML) flow charts and class diagrams.

    We also use pages (on the same wiki) as meeting minutes, and to record decisions. We use a wiki which has versioning so that we can see a complete history of how requirements and designs have changed over time.

    We thereby ensure a complete history of the requirements process and how it relates to the changing architecture. Incidentally, GitHub also provides a wiki feature, but we use a third-party wiki which integrates with our project management software.

    Release management: commit and pull request comments

    Our release management process includes code review. Our code review includes documentation review.

    As GitHub is our source control platform, we bake code review into our pull requests. The platform supports commenting upon check-in, inline comment threads on portions of commits, and a conversation thread on the pull request.

    The key to using these communication channels successfully is to ensure that all discussions result in a tangible output. Either clarify the code itself, or extend the permanent documentation in response to questions.

    If the reviewer doesn’t understand the code as it is written, future developers won’t either. Rewrite the code to be more self-explanatory, or extend the in-line or readme documentation.

    It’s not sufficient to end the conversation by replying to the thread: we treat this documentation as ephemeral, and on a long-lived code-base it’s a pain to review the full commit history.

    Bonus round: self-documenting code

    Finally, one quick plug for so-called “self-documenting code.” I’m a firm believer that the code should be self-explanatory at the surface. Explicit documentation should provide context or improve maintainability.

    There are already good articles about this (here’s one), so I won’t go into detail here.

    Final thoughts

    I hope that you learn from our experience. Our four-layer documentation architecture may not work for you, but it’s important to figure out what will.

    The big take-aways? First, it’s necessary to develop a healthy understanding of yourself and your own needs before you entangle yourself with a new code base.

    Second, it’s easier to stay out of a bad relationship with legacy code than to extract yourself once you’re already committed.

    And third, you only leave one legacy. But every commit you make contributes to it. They won’t all be good, they won’t all be bad, but they should at least be clear. Please think about what you’re leaving for those who come after you.

    Together we can reclaim our legacy as developers.

  • 00:06:58

    Ep. 21 - What is an API? In English, please.

    The freeCodeCamp Podcast starstarstarstarstar

    Many people have a vague or incorrect idea of what the fairly common term "API" means. Heads up: it's not a type of beer! Petr lays out the basic details of an application programming interface in plain English so you'll never be confused again.

    Written by Petr Gazarov: https://twitter.com/PetrGazarov

    Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

    Original article: https://fcc.im/2FHPHer

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    Before I learned software development, API sounded like a kind of beer.

    Today I use the term so often that I have in fact recently tried to order an API at a bar.

    The bartender’s response was to throw a 404: resource not found.

    I meet lots of people, both working in tech and elsewhere, who have a rather vague or incorrect idea about what this fairly common term means.

    Technically, API stands for Application Programming Interface. At some point or another, most large companies have built APIs for their customers, or for internal use.

    But how do you explain API in plain English? And is there a broader meaning than the one used in development and business? First, let’s pull back and look at how the web itself works.

    WWW and remote servers

    When I think about the Web, I imagine a large network of connected servers.

    Every page on the internet is stored somewhere on a remote server. A remote server is not so mystical after all — it’s just a part of a remotely located computer that is optimized to process requests.

    To put things in perspective, you can spin up a server on your laptop capable of serving an entire website to the Web (in fact, a local server is what engineers use to develop websites before releasing them to the public).

    When you type www.facebook.com into your browser, a request goes out to Facebook’s remote server. Once your browser receives the response, it interprets the code and displays the page.

    To the browser, also known as the client, Facebook’s server is an API. This means that every time you visit a page on the Web, you interact with some remote server’s API.

    An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses.

    APIs as a way to serve your customers

    You’ve probably heard of companies packaging APIs as products. For example, Weather Underground sells access to its weather data API.

    Example scenario: Your small business’s website has a form used to sign clients up for appointments. You want to give your clients the ability to automatically create a Google calendar event with the details for that appointment.

    API use: The idea is to have your website’s server talk directly to Google’s server with a request to create an event with the given details. Your server would then receive Google’s response, process it, and send back relevant information to the browser, such as a confirmation message to the user.

    Alternatively, your browser can often send an API request directly to Google’s server bypassing your server.

    How is this Google Calendar’s API different from the API of any other remote server out there?

    In technical terms, the difference is the format of the request and the response.

    To render the whole web page, your browser expects a response in HTML, which contains presentational code, while Google Calendar’s API call would just return the data — likely in a format like JSON.

    If your website’s server is making the API request, then your website’s server is the client (similar to your browser being the client when you use it to navigate to a website).

    From your users perspective, APIs allow them to complete the action without leaving your website.

    Most modern websites consume at least some third-party APIs.

    Many problems already have a third-party solution, be it in the form of a library or service. It’s often just easier and more reliable to use an existing solution.

    It’s not uncommon for development teams to break up their application into multiple servers that talk to each other via APIs. The servers that perform helper functions for the main application server are commonly referred to as microservices.

    To summarize, when a company offers an API to their customers, it just means that they’ve built a set of dedicated URLs that return pure data responses — meaning the responses won’t contain the kind of presentational overhead that you would expect in a graphical user interface like a website.

    Can you make these requests with your browser? Often, yes. Since the actual HTTP transmission happens in text, your browser will always do the best it can to display the response.

    For example, you can access GitHub’s API directly with your browser without even needing an access token. Here’s the JSON response you get when you visit a GitHub user’s API route in your browser (https://api.github.com/users/petrgazarov).

    The browser seems to have done just fine displaying a JSON response. A JSON response like this is ready for use in your code. It‘s easy to extract data from this text. Then you can do whatever you want with the data.

    A is for “Application”

    To close off, let’s throw in a couple more examples of APIs.

    “Application” can refer to many things. Here are some of them in the context of API:

    A piece of software with a distinct function.

    The whole server, the whole app, or just a small part of an app.

    Basically any piece of software that can be distinctively separated from its environment, can be an “A” in API, and will probably also have some sort of API.

    Let’s say you’re using a third-party library in your code. Once incorporated into your code, a library becomes part of your overall app. Being a distinct piece of software, the library would likely have an API which allows it to interact with the rest of your code.

    Here’s another example: In Object Oriented Design, code is organized into objects. Your application may have hundreds of objects defined that can interact with one another.

    Each object has an API — a set of public methods and properties that it uses to interact with other objects in your application.

    An object may also have inner logic that is private, meaning that it’s hidden from the outside scope (and not an API).

    From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.

  • 00:23:46

    Ep. 20 - Basics of Machine Learning - interview with Nishant Shukla

    The freeCodeCamp Podcast starstarstarstarstar

    Nishant Shukla is the author of Machine Learning in TensorFlow, and is also the VP of Engineering at a startup focussing on Artificial Intelligence technologies for education. In this episode, he discusses the basics of machine learning. Learn more about his book at http://tensorflowbook.com/

    Interviewer: Beau Carnes - https://twitter.com/CarnesBeau

    Interviewee: Nishant Shukla - https://twitter.com/binroot

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02

  • 00:13:54

    Ep. 19 - Don't worry, be happy: how to build your future tech career in 5 simple steps

    The freeCodeCamp Podcast starstarstarstarstar

    Changing careers is very difficult. Add in a full-time job and a couple of kids, and the task seems nearly impossible. But even if you're busy, you can make the time to build the skills to level up your career. Here's how Michael Tombor did just that.

    Written and read by Michael Tombor: https://twitter.com/michaeltombor

    Original article: https://fcc.im/2BK2vkm

    Learn to code for free at: https://www.freecodecamp.org

    Intro music by Vangough: https://fcc.im/2APOG02


    “Instead of saying “I don’t have time” try saying “It’s not a priority,” and see how that feels.” — Laura Vanderkam

    Changing careers is very difficult. Add in a full-time job and a couple of kids and the task seems nearly impossible. Yet, even if you are busy, you can prioritize and make the time to focus on what matters to you and build the skills to level up your career.

    Engineer your future with code

    I started my coding journey just six months ago. Now I am one project away from completing my front-end developer certificate on freeCodeCamp. I’ve also completed the web developer boot camp course by Colt Steele on Udemy. And I did this all while raising two kids and working in a full-time job.

    When I began using these tips, I saw my progress increase tenfold. I know I would have accomplished much more if I had implemented them earlier in my journey. I have not only benefited from increased productivity, but I feel more balanced and am having more fun than ever before.

    My pivot into web development

    After being in health care for the last five years, I realized that it wasn’t what I wanted to do for the rest of my life. Don’t get me wrong - I loved helping people on their path to health, but I hated seeing the system break down for them. I hated when people could not afford their medication, or when their care plan wasn’t in sync with the treatment they needed.

    I wanted to do more to help these people. But I knew that I couldn’t do more unless I took a step back and looked at the bigger picture.

    I was not always interested in coding, but the more I looked at the forces making real change in today’s world, the more I saw that tech was behind these advances.

    I saw an opportunity to make meaningful change, and that is when I became interested in coding.

    Why are you coding?

    Whatever the reason is, really think about it and pin it down. Use it as motivation to propel you towards your coding goals. Having this end goal will help you bust through plateaus and push through the hard parts (coding is hard).

    Every day that I spend at my current day job motivates me to get home, boot up my laptop, and continue my journey of learning how to code.

    The good news is that building coding skills is simple. All you have to do is code a lot. But unfortunately, this is where the hard part comes in. Fitting time into your busy life to routinely code is difficult, to say the least.

    How to climb the coding mountain

    There is a gap between where you are now and where you want to be. That is why you are reading this article. That is why you work day in and out, and end up sacrificing time with your family and loved ones.

    If we are spending all this time working towards our goal, it is paramount to make the most of the time we spend learning how to code.

    Here are five steps to turn this dream into a reality:

    Create your personalized goals

    To make the most of your time, nothing is more important than making actionable short-term goals. This will not only help you feel a sense of accomplishment every time you meet a goal, but it will help make the coding journey feel a lot less daunting.

    Goals Exercise!

    To help you come up with focused goals, I want to encourage you to do a quick exercise that I picked up from Laura Vanderkam.

    1. Picture yourself one year from now. You have crushed ALL your coding goals and landed your dream job. You have given five talks at conferences around the world, and you built up your App and it was successful. Whatever success looks like to you, picture your future self. Please be ambitious, maybe even dream a little.

    2. What 3 - 5 goals did you accomplish in that year that made it so successful?

    3. Write these goals down.

    4. Repeat this exercise for your personal life goals. It is impossible to work all the time, and to be successful you need work life balance (or you will burn out).

    Now you have 6 - 10 ambitious goals that you want to accomplish during the next year. To break these larger goals down into action items, think about and plan about how you can meet these goals.

    For example, if you want to complete the freeCodeCamp front end certificate, you need to schedule time to work on it throughout the week. If you want to run a marathon, you need to buy running shoes, sign up for a marathon, and schedule time to train regularly.

    2. Make a Schedule

    I’ll be honest - I am definitely not the scheduling type. I thought that I could wing it day by day. But realistically, you need to set time aside to focus, or your goals will pour over into the rest of your life. I found myself feeling anxious about coding during time with my family or when I was putting my kids to bed, because I hadn’t coded yet that day.

    The thing I looked forward to all day (coding) started to negatively impact my quality of life.

    Splitting your time into focused blocks allows you to be 100% in the present moment. When it is coding time, you can have tunnel vision and hack away. When it is time to unwind, or hang out with people you care about, you can be present because you coded that morning, or have time scheduled later in the day.

    I schedule a lot of family time. Family is really important to me. Your schedule will look a lot different, but the point is to create a schedule that will allow you to meet your goals without you hating life along the way. Just try to account for everything, so you can stick to your schedule.

    3. Audit yourself to find time opportunities

    Write down all the activities in a given day or week and see what you really do with your time. You will likely be surprised by exactly how much time you spend mindlessly scrolling through your Instagram feed, or binge watching a new Netflix show (I love Stranger Things).

    I’m not telling you to cut all of it out but keep a balance. You can definitely turn some of that idle time into some serious coding gains.

    There is more time than you think

    If you are still thinking to yourself, “yeah, but I still work a lot and (insert excuse here) so I can’t find time”, then here is a fun fact! There are 168 hours in a week. If you work a full 40 hour week and subtract 8 hours of sleep per night (which I definitely don’t get) you still end up with 72 hours of “free” time.

    Look at all the time you have in your life situation and squeeze as much “good” stuff into that time as you can. There IS time.

    4. Fill your time with quality

    Here are some tools that I use to help me accomplish my coding goals and stay focused on my learning path:


    Seriously one of the best tools for meeting goals. The curriculum is right there for you to follow and work on, it even tracks your progress!

    JavaScript 30

    30 JavaScript projects really help you master array methods while filling up your portfolio with projects (plus it is tons of fun). Wes Bos is a solid instructor who provides a quality free course. You can complete it in 30 consecutive days, or work it into your learning schedule.

    100 Days of code on Twitter

    This 100 day challenge consists of coding every day and tweeting about what you did. It is a great tool for tracking progress and measuring how far you have come. This community is full of inspiring people from all over the world and is a great way to meet like minded developers.

    The Web Developer Boot Camp

    I am almost finished with this course, and it has patched a lot of holes in my coding knowledge. Colt doesn’t just show you how to do something, he also explains why you do it a certain way. Plus, there is now an advanced web developer boot camp that I am going to take once I’m done.

    Live It!

    This isn’t a resource, but you should embrace the tech community by living it. Listen to podcasts while you drive to work or do the dishes. Follow leaders in the industry on Twitter. Read articles. Immerse yourself in tech and you will learn without realizing you are learning.

    5. Multiply your time

    We have set goals, and now have several larger goals broken down into actionable goals. We have gone through how to fit these goals into your busy life and I have helped give you some ideas on how to fill your time. Now, I want to tell you how you can make the most out of the time you put into coding.

    The Answer: Be Happy!

    What does being happy have to do with managing time, you ask? Simply put: it is everything. The idea is called multiplying your time.

    Being present and deeply focused leads to increased productivity. This in turn multiplies the time you spend by increasing efficiency. Plus, who doesn’t want to be happy?

    According to Shawn Achor, who studied the effects of happiness and its link to productivity, your brain performs 31% more productively when you feel happy.

    Dopamine, which floods into your system when you feel positive, does two things:

    It makes you happier (duh!)

    It turns on the learning centers in your brain. They help you learn things more easily, and allow you to spend less time on learning while retaining more information.

    Turn your brain into a dopamine producing machine!

    You can release more dopamine by creating lasting, positive change. There are five things you can work into your routine to turn your brain into a dopamine producing machine:

    1. Write three new things that you’re grateful for each day. This creates the habit of scanning the world for positive things, instead of negative ones.

    2. Journal about a positive experience you had in the last 24 hours. This allows you to relive the positive experience which leads to the same dopamine response.

    3. Exercise. Go on a short walk before a coding session, or bust out a quick workout. Exercise releases tons of dopamine.

    4. Meditate. Meditation trains your brain to focus more on the task at hand, all while releasing dopamine.

    5. Random acts of kindness. Thank someone in your social support network for helping you, or help someone out. This not only releases dopamine for you, it also does the same for the person you helped (and they may pay it forward).

    Use blocks of time to build your future

    Even if we are busy, we must take out time for the things that matter the most. When you focus on what matters, you can build the life you want with the blocks of time you have.