Apr 25, 2017 Author dannaisadork Posted on 25 Apr 2017 25 Apr 2017 Categories Self-study Tags coding, mooc, Programming, review, Self-study, udacity One thought on “Udacity CS101: Intro to Computer Science, a review”. 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 pla.
- R B Greates Hits Videos 2017 And 2018
- Joe Robinet Survivor Videos 2017 And 2018
- Budweiser Clydesdales Videos 2017 And 2018
- Latest Audacity Cs101 Videos 2017 And Torrent 2017 Torrent
Udacity offers some great content in theirNanodegree programs. If you don't havethe money, and/or just don't want to pay for them, you can take many of thecourses for free.
While it's no substitute for the actual Nanodegree programs(which include project reviews, additional student and career guidance, and ajob guarantee) there is some great content available for learning.
NOTE: I have NO affiliation with Udacity or Google
Why are only some of the Nanodegrees listed here
The focus of this project has always been making learning accessible. Assuch, I've chosen to only list Nanodegrees with free content. All ofthe Nanodegrees programs listed here meet the following criteria:
- Nanodegree lists syllabus on it's public-facing (non-logged in) page
- Links to each course in the syllabus are available on the public-facing Nanodegree page
- Individual courses are available to take for free via their public facing course page
Lately, as Udacity adds more and more great (and relevent) programs, thenewer Nanodegrees haven't been listing the courses and/or linking to them andthis list hasn't been updated as frequently.
What about pull requests, I'd like to contribute
Awesome! As long as your PR meets the same 3 criteria in the last section:
- Nanodegree lists syllabus on it's public-facing (non-logged in) page
- Links to each course in the syllabus are available on the public-facing Nanodegree page
- Individual courses are available to take for free via their public facing course page
Table of Contents
Front-End Web Developer Nanodegree
Master the skills required to become a Front-End Web Developer, and startbuilding beautiful, responsive websites optimized for mobile and desktopperformance.
Learn the fundamentals of how the web works and gain a working knowledge of thethree foundational languages that power each and every website: HTML, CSS andJavaScript.
Full Stack Web Developer Nanodegree
This program will prepare you for a job as a Full Stack Web Developer, and teachyou to build complex server-side web applications that use powerful relationaldatabases to persistently store data.
You’ll learn to build applications that can support any front-end, and scale tosupport hundreds of thousands of users.
Part 1: Developer Tools
- Git & Github - Part 1, Part 2
Part 2: Databases with SQL & Python
Part 3: Servers, Authorization, and CRUD
Part 4: Deploying to Linux Servers
Extracurricular Material
Senior Web Developer Nanodegree
No longer listed on Udacity
This program begins where our Front-End Web Developer Nanodegree program ends,and is designed to give intermediate developers the chance to build on existingfront-end skills and master the newest technologies available.
This program ensures you’re supremely well-prepared to succeed in a Senior WebDeveloper role.
Data Analyst Nanodegree
We built this program with expert analysts and scientists at leading technologycompanies to ensure you master the exact skills necessary to build a career indata science.
Learn to clean up messy data, uncover patterns and insights, make predictions using machine learning, and clearly communicate critical findings.
Machine Learning Engineer Nanodegree
Machine learning represents a key evolution in the fields of computerscience, data analysis, software engineering, and artificial intelligence.
This program will teach you how to become a machine learning engineer,and apply predictive models to massive data sets in fields like finance,healthcare, education, and more.
Predictive Analytics for Business Nanodegree
As more and more companies incorporate predictive analytics into their datastrategies, demand for business analysts with these skills is growing rapidly,and salaries are rising. This Nanodegree program will equip you with these veryin-demand skills, and no programming experience is required to enroll!
You’ll master the most important predictive techniques, work with leadingtools in the space, and learn to deliver high-value solutions to importantbusiness problems.
Android Basics Nanodegree
Android apps are everywhere, and learning to build them can be a fantasticcareer move. No programming experience? No problem! The skills you learn in thisbeginning Nanodegree program will accelerate your journey to becoming a workingAndroid Developer.
Android Developer Nanodegree
For intermediate Java developers pursuing Android specialization, this programteaches the tools, principles, and patterns that underlie all Androiddevelopment.
The skills you learn in this Nanodegree program will help you master theexisting platform, and prepare you for the exciting opportunities in Android'sfuture.
iOS Developer Nanodegree
Being an iOS Developer is a remarkable occupation, and we’ve designed thisNanodegree program to teach you the skills required to launch your career.
For those with previous object-oriented programming experience, you’ll learnSwift and build a multitude of portfolio-worthy iOS apps to demonstrate yourexpertise as an iOS Developer.
Mobile Game Developer Nanodegree
No longer listed on Udacity
If you want the skills to turn your game ideas into reality, or get ready tojump into professional game development, this is the program for you!
The core of this Nanodegree program is libGDX, a powerful cross platform gamedevelopment framework that allows you to release your game on a variety ofdevices and operating systems.
Tech Entrepreneur Nanodegree
No longer listed on Udacity
Our Tech Entrepreneur Nanodegree program teaches you the skills you need tocreate your own revenue-generating app, and build a successful business aroundit. You’ll learn to succeed the Silicon Valley way!
Built in partnership with Google, this program mixes theory and practice toshow students how to transform ideas into market-ready products.
Episodes
On today's episode, Quincy Larson interviews Ali Spittel. She's a Washington DC-based developer and artist.
Ali runs the popular Zen of Programming blog, where she writes about design, data visualization, and other programming topics.
She talks about how her interests in political journalism lead to a passion for data and data journalism.
Ali also talks about her love of Python. She reads the poem 'The Zen of Python' and talks about how it has influenced her programming style and her way of thinking about software development.
Interview by Quincy Larson: https://twitter.com/ossia
Ali Spittel on Twitter: https://twitter.com/aspittel Zen of Programming website: https://zen-of-programming.com/Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
On today's episode, Quincy Larson interviews Laurence Bradford. She's the creator the LearnToCodeWith.me blog and podcast, and the Newbie Coder Warehouse Facebook group.
As a college student, Laurence was so technologically illiterate that her school made her take a remedial computer class. This made her doubt that she had a future in technology. And she ended up studying Economics instead, and moving to Asia to work in economic development.
Years later, Laurence decided to learn some basic web development skills. She found a help-wanted ad on Craigslist and landed her first gig as a freelance developer.
Since then, Laurence has worked as a developer and a product manager. She's written extensively about technology and programming in Forbes and on her blog. And she's interviewed nearly 100 developers on her LearnToCodeWith.me podcast.
Interview by Quincy Larson: https://twitter.com/ossia
Laurence Bradford on Twitter: https://twitter.com/learncodewithme LearnToCodeWith.me Website: https://learntocodewith.meLearn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Missing episodes?
- On today's episode, Quincy Larson interviews Alexander Kallaway, the creator of the #100DaysOfCode challenge. In addition to talking about the 100DaysOfCode challenge itself - a challenge which, at this point, thousands of people have taken - Alex and I also talk about how he and his wife moved from Russia to Canada to advance their careers, and how he used freeCodeCamp to gain the skills he needed to get his first developer job. Alex is an incredibly motivated person, and in this interview we'll delve into how he keeps himself so fired-up day after day.
Interview by Quincy Larson: https://twitter.com/ossia
Alexander Kallaway on Twitter: https://twitter.com/ka11away 100DaysOfCode Website: https://www.100daysofcode.com/Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Dylan is a software engineer, YouTuber, and creator of several programming courses. Quincy talks to him about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job. On top of that, you'll learn how he was able to leverage a few job offers to get a massive raise at his current company.
Quincy Larson: https://twitter.com/ossia
Dylan's YouTube channel: https://fcc.im/2NypFgS
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Description: On today's episode of the freeCodeCamp podcast, Quincy Larson interviews Dylan Israel. Dylan is a software engineer, a YouTuber, and the creator of several programming courses. We talk about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job. We also talk about how important his YouTube channel has been in helping him land job offers. And Dylan shares some details of his latest job search, which resulted in 4 job offers. Dylan was ultimately able to use those job offers a bargaining chip so he could get a massive raise at his current company without having to change jobs.Are you trying to get a jump-start on your tech career while you're still in school? Have you found that perfect internship - or job - but you're not sure how to approach it? If so, this is the resource for you. Michael discusses how to craft your résumé, how to prepare for interviews, and much more.
Written by Michael Deng: https://twitter.com/themichaeldeng
Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn
Original article: https://fcc.im/2BCESfo
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Transcript:
Seven semesters ago, I started college with no programming background. The only thing I had was lofty aspirations of working in tech.
When recruiting season first rolled around, I applied to a bunch of companies. I got a few callbacks, but that’s it. No follow-ups. No onsite interviews. Nothing.
I kept trying. I applied to over 150 companies. I faced dozens of interviews.
I failed way more than I succeeded. But that’s all right. Because those failures made my moments of triumph all the more memorable.
Along the way, I met helpful mentors and guided ambitious mentees. These people are now working at places like Airbnb, Facebook, Google, SpaceX, and Snap.
As for me, I landed an internship at Uber last summer. And I’m on track to accept a full-time job at one of my favorite companies when I graduate.
Now that I’m in my final year of school, I want to share everything I’ve learned over the years. This isn’t meant to be the ultimate handbook. It’s only a modest guide born out of my love of helping others reach their goals (and my love of Legos).
By the end of this article, you’ll know everything I wish I had known when I first started sending in applications.
A few words before we begin…
Don’t let your struggle for the perfect job take over your life. School is a time of self-discovery and all-around personal growth. So go out there and meet people who are doing different things. Join diverse student organizations and take part in activities outside your comfort zone.
It’s all too easy to associate your self-worth with how prestigious of a job you can get. But remember: there are so many more important things in life than work.
My best memories of college aren’t spending weeks on end prepping for interviews or even getting offer phone calls. They’re exploring San Francisco for the first time with my closest friends. They’re playing volleyball with my hilarious teammates. I value these unique experiences I shared with people I love much more than any job.
To paraphrase my favorite quote by Twitter and Medium founder Ev Williams: “Failure of your [work] is not failure in life. Failure in your relationships is.” Don’t lose sight of what’s important.
It’s also no coincidence that everyone I know with a strong support system eventually found success. When you fall into a slump — and all of us do — you need your friends to be there for you. I would never have made it through my first year without amazing friends who kept me afloat.
Now, let’s get started. You pumped? I’m pumped!
Building fundamentals
Before we get to the good stuff, you need to build solid fundamentals. Seems obvious? Absolutely. But this is the hardest step of this guide, so listen up.
Now, this guide is designed for college students, so if you’re in high school, scram! Just kidding. In fact, I admire your initiative. When I was in high school, I didn’t have the faintest idea what I wanted to do.
Leading up to college, your top priority should be solidifying your math skills. Computer science relies heavily on mathematic concepts like probability, logic, and number theory. Without math, you’re not going to get far in hard weeder classes and technical interviews.
If you’re already proficient in math, keep reading. Most of this guide is just as applicable to you as it is to college students. Skip to the online classes section below and progress through the rest of this guide. Landing an internship as a high schooler is challenging, but certainly not impossible.
OK. Back to college students.
Building fundamentals starts with your intro programming classes. Pay attention and master the basics. A popular but misguided notion is “GPA doesn’t matter.” Although it’s true that most companies won’t scrutinize your GPA, any gaps in your fundamental knowledge will come back to bite you later. By getting a decent GPA, you’re also most likely getting a grasp of the basics.
Your classes will cover a lot of basic knowledge, but they’ll barely scratch the surface of modern technology. Go explore interesting topics around the core concepts taught in class. This is how you gain a breadth of knowledge and come up with future project ideas.
If you’re not studying computer science, don’t worry.
I have friends who changed their minds and started CS their Junior year. They still graduated on time with great job offers, so you’re not too late at all. This said, you will need to make sacrifices and take extra classes every semester.
If you’re not able to take CS classes in college, there are plenty of awesome online resources to help you out.
Two of the best online intro courses are Harvard CS50x on edX and CS101 on Udacity. After this intro, you need to master data structures and algorithms. I recommend Princeton Algorithms Part 1 and Part 2 on Coursera, or CS61B by UC Berkeley.
To make sure you’re on track, reference Google’s Technical Development Guide.
Don’t worry if you struggle at first.
A few weeks into my first semester, I was completely overwhelmed. I spent days studying concepts that took other students hours to grasp. I thought about giving up every week. “How am I ever going to catch up to those prodigies?”
But if you ask me or any of my friends who made it through, we’ll all tell you the same thing: Learning to program isn’t about how talented you are or how early you started coding. It’s about perseverance.
Building up your programming intuition takes a long time — much like learning a human language. You won’t see the light at the end of the tunnel for a long time. But trust me. If you take one step at a time, you will eventually get there.
Staying motivated is difficult, but there’s a secret.
Focus on mastery instead of results.
Make it your goal to get better at a skill rather than achieve a certain result. Dr. Heidi Grant Halvorson did a study where she asked two groups of people to solve various problems. The first group was told to score as high as they could. The second group was told to treat the problems as a learning opportunity.
The results were surprising. The first group got frustrated, whereas the second group persisted and solved more problems.
By focusing on mastery, you view obstacles and time pressure as things that will help you grow. In contrast, a result-oriented mindset frames problems as irritating roadblocks impeding your way.
What’s more, you’ll see continual progress if you concentrate on mastery. Every time you read a new paragraph or solve a new question, you’re improving your skills. This kind of continuous gratification is incredibly satisfying.
So next time you’re studying for class or practicing for interviews, focus on getting better instead of acing the exam or landing the offer.
You can read more about this tactic in Edmond Lau’s Quora post.
Beyond basic coding skills, you need to know what’s happening in the tech industry.
This goes beyond sounding smart during recruiting. By paying attention to the industry, you’ll be the first to discover new opportunities to propel your career forward.
For online reading, check out TechCrunch, Techmeme, Product Hunt, and Hacker News. If you’re a frequent Twitter user, follow tech news sources. On Medium and Quora, personalize your feeds to get insightful takes on the industry.
If you’re into email newsletters, look into Axios Pro Rata, CB Insights, and Mattermark Daily.
To do a deep dive on a particular company, use Crunchbase and the company’s blog. You can also learn about the company’s culture from Glassdoor.
Finally, don’t forget to actually talk to people. I learned so much about the tech world from casual conversations with friends and classmates.
Over time, you’ll read about a lot of interesting companies. Begin compiling a spreadsheet of companies you’re interested in from day 1. When you apply to these companies in the future, use this spreadsheet to track your progress.
Once you have the fundamentals down, it’s time to apply your skills. One of the best ways to do that is by…
Building projects
If you’re like me, you don’t have much experience to begin with, and that’s OK! The first step is populating that empty resume with projects.
When I first decided to work on a project, I had decision paralysis for days. “What should I make? What if it’s not original? What if people don’t like it?”
Later, I realized it doesn’t really matter what the project is. Learning something and finishing what you start is much more important. But this doesn’t mean you can make whatever you want. If your project is too trivial, you won’t impress any recruiters. If yourq project is too complex, you’ll lose momentum before completing it.
Aim to do a project you think you can complete in one to two months. The project should involve data structures, algorithms, and design decisions. And do something you’re interested in so you’ll actually take it all the way to completion.
Here’s a compilation of project ideas on Reddit for inspiration.
After coming up with an idea, take some time to plan, but don’t take too long. You want to start as soon as possible. Now, you might be wondering “Isn’t it irresponsible to jump in prematurely?”
Generally, yes. But personal projects are different from company projects. Personal projects should teach you something new and strengthen your background during recruiting. Unlike company projects, you don’t need to obsess over design and code quality.
If you’re feeling stuck at the beginning, write down some code — any code. Building a personal project is like writing, you just start. Don’t worry if it doesn’t make sense. Seeing code in an editor will get your juices flowing.
Track your project with version control. If you don’t know what that is, make a Github account and learn how to use Git. You need Github as it’s the primary way you save and display your projects.
If you can, make your project live so recruiters can play with it. Most recruiters won’t inspect your code, so a live demo is the best way to show off your project.
Aim to complete three to five projects by the time you start applying.
A terrific first project is a personal website.
You learn the basics of web development and get your own space on the internet to display your work.
Codecademy has two excellent tutorials on building websites:
Make a Website teaches you the basics of HTML, CSS, and Bootstrap.
Deploy a Website teaches you how to put your website on the internet. Step 3 of this tutorial isn’t necessary, just use the free .github.io domain.
Too easy? Convert your personal website into a dynamic blog. To do this, you need to learn a web development framework like Rails or Django. Check out the Ruby on Rails Tutorial or The Django Girls Guide.
The Muse and Awwwards have examples of personal websites if you need design inspiration. Also, you have to check out this wicked personal website.
Hackathons are great for motivating yourself to do projects.
Schools and organizations around the world host hackathons, which are project-building competitions lasting several days. In this short span of time, you’ll learn a lot, come up with unique ideas, and meet interesting people.
Many hackathons reimburse travel, so there’s no excuse not to go. Use Hackalist or Hackevents to discover upcoming ones.
Some of the top North American hackathons I know of are PennApps, HackMIT, HackNY, MHacks, HackTech, HackIllinois, CalHacks, TreeHacks, Hack the North, YC Hacks, and Greylock Techfair.
You can also contribute to open source projects.
Working on open source is an awesome way to add value to meaningful projects. Plus, you learn a lot from seeing code written by more experienced engineers.
Jumping into open source for the first time can be intimidating. Two good entry points are Google Summer of Code and Sayan Chowdhury’s article on open source for beginners. Github also just released their very own open source guide. Find a cool project and dive in. You’ll get the hang of it soon enough.
Research is an alternative to projects.
If your school has a student research program, great! Apply asap. If it doesn’t have one, look up what research your professors are doing. If their work seems interesting, email them and ask if you can contribute. You’d be surprised at how receptive they are to eager undergrads.
In the future, you can even ask your team to refer you to cutting-edge companies. Keep in mind research belongs under Experience rather than Projects on your resume.
It can be tough balancing projects and school.
One complaint I hear frequently is “I don’t have time to do side projects while taking classes.” I’m personally guilty of saying that from time to time.
It’s tough to set aside time for projects because, unlike school, you’re not held accountable by deadlines and exams. After a day of studying, it’s tempting to choose social media or video games over your project. But if you keep putting it off, the semester will be over before you know it.
To combat procrastination, force yourself to work on your project a little bit every day. Even if it’s just 15 minutes, you’ll form a habit of making continual progress.
This is also why hackathons and research projects are so great. They impose external deadlines and expectations so you can’t drag your heels.
Now that you have some experience, you need to put it somewhere.
Creating a resume
Writing a resume might seem pretty straightforward, but there are lots of nuances. After all, it’s the first thing recruiters will read about you. It’s crucial to make a good first impression.
…And you need to make that impression fast. Recruiters spend an average of six seconds reviewing a resume. You heard that right. Six seconds.
Almost all that time is spent on your name, companies, job titles, start/end dates, school, major, and project titles. Everything on your resume should be tailored towards helping recruiters find these key pieces of info as fast as possible.
Here are some important guidelines.
Easy to scan.
Stick to one page.
Keep it black and white if you’re not skilled at design. Colors are noisy.
Stick to a standard format (chronological, no weird fonts, 10.5 to 12 pt font size, 0.5 to 1 inch margins). Standard formats are more readable by resume-parsing programs and easier to skim by recruiters.
Keep it concise. Text walls discourage readers.
Highlight the key points
Make your name big.
Highlight company names, job titles, start/end dates, school name, major, and project titles.
Important content should be higher up. For a student, the order of importance is usually Education > Experience > Projects > Skills.
Cut the fat.
Objective and Summary are unnecessary.
Descriptions should say something tangible. “Exceptional team player” doesn’t work. “Increased user conversion rates by 20%” does.
People without technical background will be reading your resume, so get rid of convoluted details.
Don’t neglect the details:Include the higher of your cumulative GPA and your major GPA. If they’re both less than 3.0, leave it off.
Include links to a live demo or Github repo for each project.Don’t include anything you wouldn’t be comfortable answering questions about. Most people make this mistake when listing their skills.
After finishing your resume, have your peers review it. Ask them to be honest and harsh. My first draft was awful compared to my tenth draft.
Use online resume builders if you’re short on time.
Standard Resume and CakeResume are two outstanding tools that make it a breeze to generate a handsome resume.
If you don’t have a LinkedIn profile, create one.
LinkedIn enables recruiters to find you and helps you maintain your professional network. Plus, you need it for the cold-emailing recruiters later.
With a few projects under your belt and resume in hand, you’re ready to begin preparing for interviews.
Getting battle-ready for interviews
Interview problems can be separated into two buckets, behavioral questions and technical questions. You need to start practicing both at least two months before applying. Since recruiting season kicks off in August/September, summer break is a good time to begin.
Behavioral questions
The purpose of behavioral questions are to find out more about your background and if you actually did what you said on your resume. Don’t take the behavioral interview lightly. A poor performance can sink your chances of getting the offer.
To ace behavioral questions, you need a strong answer to “Tell me about yourself” and three stories to handle all other questions.
“Tell me about yourself” is the most common behavioral question you’ll get and you need to crush it.
Don’t make the cardinal mistake of regurgitating your resume. Instead, tell a story.Capture the attention of the interviewer with a strong introduction. Then, transition into a commentary about your key projects and experiences. Don’t prattle on about the details — keep it simple and emphasize the outcomes. Finally, explain why you’re interested in the position.
It’s tempting to talk about every single thing you did, but you’ll lose your interviewer. Keep it concise. Your answer should be one to two minutes long.
Prepare three stories you can tell in response to all other behavioral questions.
Typically, you’ll be asked to give examples of leadership, overcoming a challenge, or failure. Each of your three stories should show at least one of these themes.A story needs an initial summary, a problem, three to five action steps, and a final outcome. Here’s an example.
Summary: Lead an unmotivated team to complete CS project
Problem: Two team members didn’t do their work and wanted to drop CS
Action 1: Talked to them one-on-one to understand why they’re studying CS Action 2: Told them although it’s tough now, they can succeed if they work hard
Action 3: Emphasized that they’re invaluable to the rest of the team
Action 4: Used google calendar to plan meetings and Trello to track progress
Action 5: Held social events to bring the team closer
Outcome: Finished the project and all got at least A-
This story can be used to answer any question about leadership or overcoming a challenge. Now go think of your own!
Not all your stories have to be about tech. For example, I always talk about how I helped my volleyball team overcome defeat.
With this, you should be able to pass any behavioral interview. To learn more, read the Behavioral Questions section in Cracking the Coding Interview.
Technical questions
Technical questions are the essence of the tech interviewing process. Here’s a list of topics you need to know to pass technical interviews. To master these topics, use the following four resources:
Cracking the Coding Interview (~2 months before applying)
LeetCode (~1 month before applying)
Mock interviews (~2 weeks before applying)
Glassdoor (~2 days before interviewing)
Cracking the Coding Interview is one of the best resources out there.
Gayle Laakmann McDowell’s Cracking the Coding Interview is the quintessential tech recruiting manual. First, read the Technical Questions section. Take notes to help you remember the main ideas.
As for practice questions, concentrate on the Arrays and Strings, Linked Lists, Stacks and Queues, Trees and Graphs, Objected-Oriented Design, Recursion, and Sorting sections.
Also, familiarize yourself with the Bit Manipulation, Scalability, Databases, and Threads and Locks sections.
If you’re having trouble with any of the topics, study the first couple pages of that section. They contain a short and sweet explanation of the topic.
Attempt each question for at least 30 minutes before looking at the solution. After reading the solution, you should still implement it and test it on your own. Otherwise, you won’t fully understand the logic.
Finishing CtCI should take three to four weeks of dedicated effort.
LeetCode is the second resource you should tackle.
It has a huge list of problems ranked by difficulty. Each problem has its own tests, time complexity requirements, and solutions.
Aim to complete 30 to 50 questions and be comfortable with medium level questions before you start applying. If you do just three a day, you can finish 42 in two weeks.
It’s easy to get frustrated by Leetcode at first. In the beginning, I couldn’t solve a single easy problem. I improved over time, but I still get stuck frequently on medium and hard level problems. The good thing is interviews are different from Leetcode. In an interview, you get hints if you’re stuck. Plus, deducing the correct logic is more important than writing runnable code.
Although Leetcode isn’t the best simulation of real interviews, it’s phenomenal for building problem solving intuition.
Mock interviews are highly effective if you do them right.
The trick is emulating a real interview as closely as possible.
If you’re the interviewee, be professional, ask questions, and talk out loud. If you’re the interviewer, time the interview, engage in the conversation, and write down feedback.
I suggest booking a private room on campus and grinding through back-to-back interviews. Make sure the room has a big whiteboard to draw on.
Take turns interviewing and being interviewed by a friend who’s also recruiting. Being able to understand the interviewer’s perspective will improve your own interviewing skills.
Glassdoor is an invaluable resource for company-specific info.
In most cases, you don’t need Glassdoor until a few days before your interview. Unless the company is very large, Glassdoor won’t have many specific interview questions.
Glassdoor is better for learning about the company’s general interview process. Navigate to the Interviews section and filter by the position you’re applying for. Sometimes there are different labels for the same job, so look through all of them.
Read candidates’ experiences and think through the interview questions they posted. You likely won’t get the same questions, but working through them will give you an idea of what to expect.
Making your application stand out
It’s finally time to send out applications and start seeing your hard work pay off! Recruiting season begins in August/September, but you can reach out a month or two earlier. For off-season jobs, apply at least 6 months before.
First, you need a list of companies to apply to.
If you’ve been following the tech industry, you should already have some companies in mind.
To add to your list, check out The Breakout List, Wealthfront’s Career-Launching Companies List, and the CrunchBase Unicorn Leaderboard.
For more ideas, here’s a list of 163 companies I looked at when I was recruiting.
Don’t be picky about which companies to apply to. If you think the product is interesting or you’ve heard good things about the company, then apply. Worry about choosing after you get a few offers.
The application process
I recommend first applying and interviewing for companies you’re less interested in. This is a good way to train for future interviews of companies you want more. But don’t do too many — you don’t want to burn out.
When I recruit, I try to keep the process under 3 months and not do more than 10 onsite interviews. Anything more than that, I run out of steam and my performance suffers.
When you’re scheduling your interviews, spread them out. Interviews are mentally draining, so you need time to rest in between. Companies won’t mind if you ask for a week or two before starting their process.
Once you’re ready to apply, use a 5-pronged approach:
Referrals
Emailing recruiters
Career fairs
Online applications
This list is ordered by success rate and time commitment. For example, referrals have the highest success rate but require the most time.
Referrals are the single best way to land interviews.
When an employee refers someone, that’s the golden endorsement. Referrals make up for less than 10% of applications, but 20-50% of eventual hires.
Ask your friends or older students to refer you. You can also ask employees for a phone chat or coffee to learn more about the company and request a referral at the end. Don’t be shy about this. If you get hired, the employee who referred you gets a bonus — it’s win-win for both of you.
Cold-emailing recruiters is the next best thing to referrals.
For smaller companies without a formal recruiting pipeline, reach out to an Engineering Manager instead. For even smaller companies, just email the CEO or CTO.
The easiest way to get email addresses is asking your network for recruiter contacts.
You need a LinkedIn account to find email addresses. Look up the companies you want to apply to on LinkedIn and filter their employees by recruiters. Next, install Hunter or Slik, which lets you get the email address from a LinkedIn profile.
Hunter doesn’t like it if you try to sign up using a personal email, so use your school email.
Your emails should be concise. State your interest in a position and include a summary of your background. Remember to attach your resume. To save time, make a template. You just have to change the name of the recruiter, the name of the company, and your statement of interest.
If you don’t get a reply in a week, follow up. If you don’t get a reply in another week, follow up again.
Career fairs get you face time with recruiters and engineers.
For career fairs, check which companies are attending beforehand. Jot down the ones you’re most interested in because you might not have time to talk to all of them. Print out 10 to 20 copies of your resume to pass to recruiters. Be ready to answer questions about your experiences and projects.
I recommend going early — miss class if you have to. You’ll avoid the lines and catch recruiters before they’re exhausted from chatting nonstop.
Don’t feel pressured to ask recruiters questions if you don’t have any. You won’t offend anyone if you get straight to the point and ask if they have openings.
After your conversation, make sure to get their emails so you can follow up later. Oh yeah, and actually follow up! Don’t let those business cards gather dust with the free t-shirts and drawstring bags.
For hackathons, you’ll be targeting one company you really like instead of 10 to 20. Company sponsors will set up shop at the venue. This is your in.
Before the hackathon, find the sponsoring company you want to target. When you arrive, introduce yourself to its engineers and recruiters. Use their API in your project and interact with them throughout the hackathon.
On the last day, go show them your project. Then, ask about job/internship opportunities. At this point, they’ve already seen your work ethic, creativity, and interest in their company. You’re pretty much guaranteed an interview.
Hackathons can function as indirect career fairs also. I know people who’ve landed interviews through talking to engineers and recruiters from sponsoring companies at hackathons. For more advice on this strategy, read Ryan Norton’s article.
Online applications are the easiest way to apply.
Use a shotgun approach. Most applications only ask for your resume, so it’s easy to apply to a lot of companies in one go.
Intern Supply, the Easy Application List, and your school’s career website are essential for finding open positions.
Most of the time, you don’t need a cover letter. But if the company makes the cover letter mandatory or asks for a short answer response, be careful. In this case, the company really cares about fit, so craft a meticulous response.
I’ve been burned many times by disregarding mandatory cover letters and short answers. Take your time when writing — a hurried response will show.
For applying online, I also recommend TripleByte. You first complete a coding quiz. Then, TripleByte matches you with top companies and fast-tracks you through their hiring processes. Bear in mind this resource only works for finding full-time jobs.
Conquering the interview
For many people, this is the most nerve-wracking part of the process, but there’s no need to be anxious. The interviewer is on your side (even if it doesn’t seem like it).
Before we go any further, there’s one thing you have to keep in mind.
Show enthusiasm!
Enthusiasm plays a huge role in whether you get an offer. Companies these days love to talk about how much they value culture fit. What they basically mean is they want someone who’s enthusiastic about their mission and product.
The truth is most candidates aren’t good at being enthusiastic. The best way to ensure you do it is preparing a list of things you like about the company in advance. When answering behavioral questions or asking questions, bring up the items on your list. Use the company’s blog and its Crunchbase profile to find things you can talk about.
Now, let’s go over some best practices for technical interviews.
When you first hear the problem, write it down. Then, clarify with your interviewer what you think the question is asking. Don’t assume you understood the question the first time you heard it.
Next, write down a few example inputs and outputs and verify they’re correct. This gives you time to think of a solution and provides tests you can run later.
If you need more time to think, don’t be afraid ask for a minute to brainstorm. It shouldn’t be too hard to devise a brute-force solution. Talk through it with your interviewer while thinking of ways you can improve it.
Continue bouncing ideas off your interviewer until you come up with a better solution. Explain it to your interviewer and only start coding after they’re satisfied.
While you’re working through the problem, continuously communicate your thought process. How you think is more important than the actual answer. Be outspoken, but don’t blab on endlessly. Take pauses to think and let the interviewer make suggestions.
Don’t space out or look distant. You should direct your full attention towards the interviewer to engage them. If they’re engaged, they’ll give you positive signals if you’re on track and hints if you’re not. What’s more, they’ll be emotionally invested in you and want you to succeed.
At the end of the interview, you’ll get time to ask questions. Remember an interview is two-way. Don’t just ask questions you think the interviewer will like to hear. Ask questions you actually want to know the answers to. I suggest asking about personal experiences to get more authentic answers.
Remember these tips and you’ll be ready to ace technical interviews.
The average interview process looks like this:
Coding challenge > Recruiter chat > Phone interview > Onsite interview
The process varies by company. Sometimes the recruiter chat will be first. Sometimes you won’t have a coding challenge. But the general structure is similar.
The coding challenge is a straightforward test.
It’s usually hosted on Hackerrank. I suggest doing a couple of questions on it ahead of time to get familiar with the format.
There’s no trick to the coding challenge. Pass as many tests as you can. With enough practice on Leetcode, this should be a walk in the park.
The recruiter chat is an informal conversation.
It’s usually for setting up the phone interview and answering any questions you have. You might get one or two behavioral questions. Once in a while, you might get trivia-esque technical questions like “Explain how a hashmap works.”
Candidates rarely get rejected at this stage (although I’ve managed to do just that a few times). Treat this as a chance to learn more about the company. Ask high-level questions — recruiters generally don’t know technical details.
Make sure to ask about the format of the rest of the interview process so you aren’t caught off guard by anything.
The phone interview stage is one to two rounds of technical interviews.
Sometimes you’ll do a video chat instead of a phone call. You’ll typically code out the answer in a shared editor like Collabedit.
If the connection is bad or you’re having trouble understanding the interviewer, speak up. You’re not going to get docked points, so don’t try to tough it through.
The onsite interview is three to six rounds of interviews with a lunch in between.
A day of back-to-back interviews is exhausting — get enough sleep beforehand! Onsite interviews are mostly technical, but some companies mix in behavioral and design rounds. The lunch is for you to learn more about the company, so relax a little.
During the interview, use the whiteboard to your advantage. Leave plenty of space on the right side and between the lines so you have room to make edits.
After the interview, don’t dwell on it. Thinking about it isn’t going to change the final result. Treat it as if you were rejected and continue applying and practicing.
Evaluating the offer
Congratulations! You got an offer! Give yourself a big pat on the back — you earned it.
But your work isn’t done yet. First, thank your recruiter and re-express your enthusiasm for the company. Then, ask for your offer in writing.
It’s time to negotiate.
A job offer isn’t an act of generosity — it’s a proposal to strike a deal. Naturally, a deal involves negotiation.
I’m not going to elaborate too much on negotiation tactics. Just read Haseeb Qureshi’s killer guide on negotiation.
Bear in mind some offers are non-negotiable, but it never hurts to try.
Avoid unpaid jobs. In 90% of cases, it’s not worth it. I’m all for prioritizing learning over pay, but at least work for a company that values you enough to pay you.
If you have more than one offer, congrats! You’re awesome. But now you have to make a decision.
Choosing which offer to accept is a nice problem to have. The best offer depends on the specific candidate, but here’s one universal suggestion I hope serves you well.
Make a list of 10 professional and personal goals you want to achieve in the next 10 years.
It could be anything, like paying off student loans, founding a startup, or mastering a new hobby. Choose the job that brings you closest to these goals.
Here are a couple more tips to remember:
Your future manager is vital to your career growth. Find a great mentor who will double as your champion.
Do internships at different companies to gain broader experiences. You’ll learn more and expand professional network.
Optimize for learning and growth over pay, unless the pay is really bad.
Work at one brand name company. It’ll make recruiting in the future easier, but know that it’s not the end of the world if you don’t have one.
Choice of programming language doesn’t matter. What matters is learning good engineering practices and how to work in a team.
Choose an engineering-first company with a software/hardware product.
Don’t forget about passion. It’s an amazing feeling building a product you believe in.
Conclusion
This brings us to the end of this guide. I hope that with this, you’ll be much better prepared than I was when starting a career in tech.
In the beginning, getting an offer might seem impossible, but the key is treating it as a series of milestones rather than one enormous task. If you make a little bit of progress every day, you’ll be there before you know it!
When you do get that dream job, don’t forget to give back. Share your experiences and extend referrals. Pass on the love, and we’ll all fly higher.
In this interview, Simple Programmr's John Sonmez talks to Quincy Larson about how he got into programming, and how he transformed himself from being shy and somewhat lazy into the kind of person who can run marathons and publish YouTube videos almost every day.
Find Quincy Larson on Twitter: https://twitter.com/ossia
Find John Sonmez on Twitter: https://twitter.com/simpleprogrammr
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Intro transcript:
Welcome to the freeCodeCamp.org Podcast. I'm Quincy Larson. On today's episode, I interview John Sonmez.
John is a developer and a prolific YouTuber. He's published than 50 programming courses, and recently published an 800 page book called The Complete Software Developer's Career Guide.
In this interview, John talks about how he got into programming, and how he transformed himself from being shy and somewhat lazy into the kind of person who can run marathons and publish YouTube videos almost every day.
John is one of the most diciplined people I know, and he has a lot of actionable advice.
Without further ado, here's John Sonmez.As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible.
Written by Angela Zhang: https://twitter.com/zhangelaz
Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn
Original article: https://fcc.im/2vAL4io
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Transcript:
As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project.
This article is my attempt at describing what makes a design document great.
The article is split into 4 sections:
Why write a design document
What to include in a design document
How to write it
The process around it
Why write a design document?
A design doc — also known as a technical spec — is a description of how you plan to solve a problem.
There are lots of writings already on why it’s important to write a design doc before diving into coding. So all
I’ll say here is:
A design doc is the most useful tool for making sure the right work gets done.
The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves.
As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too.
Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc.
What to include in a design doc?
A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently.
To start, the following is a list of sections that you should at least consider including in your next design doc:
Title and People
The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated.
Overview
A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max.
Context
A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals.
Goals and Non-Goals
The Goals section should:
describe the user-driven impact of your project — where your user might be another engineering team or even another technical system
specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics
Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page.
Milestones
A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long.
Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this:
Start Date: June 7, 2018
Milestone 1 — New system MVP running in dark-mode: June 28, 2018
Milestone 2 - Retire old system: July 4th, 2018
End Date: Add feature X, Y, Z to new system: July 14th, 2018Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates.
Current Solution
In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it.
A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases.
Proposed Solution
Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams.
Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described.
Alternative Solutions
What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own?
Monitoring and Alerting
I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why.
Cross-Team Impact
How will this increase on call and dev-ops burden?
How much money will it cost?
Does it cause any latency regression to the system?
Does it expose any security vulnerabilities?
What are some negative consequences and side effects?
How might the support team communicate this to the customers?Discussion
Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on.
Detailed Scoping and Timeline
This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc.
Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping.
I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference.
How to write it
Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class.
Write as simply as possible
Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using:
Simple words
Short sentences
Bulleted lists and/or numbered lists
Concrete examples, like “User Alice connects her bank account, then …”Add lots of charts and diagrams
Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams.
Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change.
Include numbers
The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?).
Try to be funny
A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though.
If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip:
One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.”
Do the Skeptic Test
Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively.
Do the Vacation Test
If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended?
The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback.
Process
Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it.
First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project.
Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master.
After that, as you start to have some idea of how to go about your project, do the following:
Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary.
Go into a conference room with a whiteboard.
Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!).
Then explain the implementation you have in mind, and convince them this is the right thing to build.Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on.
Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer.
On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design.
Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma.
Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person.
Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus.
In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc.
Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders.
Finally, let’s get really meta for a second: How do we evaluate the success of a design doc?
My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this:
You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture
You get feedback from reviewers that X is the riskiest part of the proposed architecture
You decide to implement X first to de-risk the project3 days later, you figure out that X is either not possible, or far more difficult than you originally intended
You decide to stop working on this project and prioritize other work insteadAt the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.
Everyone makes mistakes, especially when they're first learning a new skill or tool. If you've just entered the world of programming, chances are you'll make your fair share of mistakes, too. In this episode, Jack discusses some of the missteps he's taken early on in his career, and how you can learn from them and avoid them.
Written by Jack Finlay
Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn
Original article: https://fcc.im/2mOhFfY
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Transcript:
When you first start out in the world of software development, things may seem daunting and unknown. Leaving university and venturing into the real world is a big step, and you will stumble many times on the path before finding your feet and confidence.
You may have confidence in your abilities already. But I ask you, “How many mistakes have you made?”
The start of a career in software development is the start of a journey in mastering your craft. As with any field, there will be challenges and chances to be correct, and chances where you can be completely wrong. This piece acts as a reflection on the mistakes I have made early in my career — and a guide to avoiding them.
Getting the job
Landing your first job out of university isn’t always easy. Make sure it’s the right one for you.
A company has to be a good fit for you, and where you want your career to go.
Find out what you are worth
I made this mistake twice. When I got my first software development job during university, in my second year, I was struggling financially. This led me to accept the first salary offer I was given. I felt I needed to just take the offer, as it was great compared to the abysmal pittance I was receiving from student benefits. Little did I know that it was well under the market rate for the location, position, and time.
As I said earlier, I made this mistake twice. Upon graduating, I managed to land a job elsewhere. They were going to pay me 25% more than I was earning at the time!
It was still at the low end of the market rate. I was low-balled, and I was happy to take it. I hadn’t learned yet that not all the power is in the employer’s hands.
You too can make an offer. If I had taken the time to do some proper research, I would have seen what I was really worth. I recommend sites like PayScale to give you an indication. You can even use sites like this as a source when negotiating.
Read the reviews
Glassdoor is a great resource. Real employees of the companies listed have taken the effort to rate the companies they work for. Generally the reviews can be quite polarized as to whether employees have had good or bad experiences.
Search out some of each and you’ll find the middle-ground for yourself. Had I read some of these reviews earlier, I would have avoided some terrible experiences when interviewing and beyond.
Know what you’ll really be working with
Earlier in my career, I was so keen to work for a particular company (a friend was working there and was enjoying it) that I forgot to stop and ask what I would actually be working on. It turned out that I would not be in the same department as my friend, and that I would be on the other side of the building, and later even on different floors. And I didn’t take the time to make sure the job would really fit me.
Another side of this mistake was not asking enough about the environments, tools, and languages I would be using.
When going for the next step in my career, I made sure to ask about the following:
Version control strategy and tooling
Is it industry standard? Git, TFS, SVN or Mercurial? If you’ve heard of it, it should be okay.Is there CI/CD tooling and environments in place?
Deployments should be as automated as possible. It’ll make your life so much easier.How often are deployments?
What frameworks/languages will I be working in?
What tooling do you use? Which IDE?
Visual Studio, Rider or IntelliJ are some good options.What kind of projects will I be working on?
What kinds of technologies will the company be looking to use next? Also, what kind of horizon are these changes at?
How far off are they from becoming day-to-day in use at the company?In the job
The challenges don’t stop once you are in the job. Every day will present some new way to challenge you.
Code is never self documenting
“My code is self-documenting, I don’t need comments”. ???? I thought this when I first started programming professionally. I don’t make this mistake anymore.
Comments are the most powerful feature of any language. They can convey where your thoughts were at the time. You need to capture that in comments.
I’ve read countless sections of code where a single, simple comment would have made that complex code and the algorithms much easier to understand and update.
Commented out code is worse than no comments at all. When you are deep in investigation mode, trying to discover how something works, all that commented out code will do is make your job harder. As soon as you comment out a line, the next person to read it will have no idea why you did that.
Be judicious with your comments. Good comments will not only lighten the cognitive load, they will help you spot errors.
If something doesn’t look like it matches up to the comment, it’s probably wrong. Or it’ll give you a good chance to put the following section into practice.
Ask questions early
Don’t wait until you are down the wrong rabbit-hole before asking for help.
Waiting to ask for help may just lead you to the wrong conclusions, or worse, you’ll break something. Ask questions early, even if it’s just a quick Google search. Part of not asking questions when you really need to, through fear of appearing like an idiot, is how you end up building the wrong thing.
Asking questions is one of the most important things you can do to accelerate your learning, and to help get involved in projects right away. If you don’t ask questions when you need to, you may make some wrong assumptions.
Assume nothing
Assumptions are an important part of defining what you need to be building when you are working on a project. There will often be assumptions recorded against the tickets you’ll be working on (if your company uses a ticketing or task system).
Not every case has to be catered to when you’re designing a solution. A correct set of assumptions will help guide you towards the correct solution.
I have spent hours building things incorrectly and even building the wrong thing because I made incorrect assumptions. Usually, tasks will be quite fleshed out when they arrive from the Business Analysts, but often there will be gaps.
Don’t make any assumptions unless they have been stated for you, or you’ve asked about them.
Working from home
Don’t be afraid to ask to work from home every once in a while. Sometimes it’s a great way to get away from the stresses and distractions of the office and really focus. There are whole companies built on a remote workforce. It certainly works.
There will also be some companies that are fully against it. I worked for over a year with a team in Australia, from our office in New Zealand. Collaboration and cooperation still happened online. Through email, chat, and old fashioned phone calls, distance doesn’t stop you working with your peers. There was no practical difference whether I was in the office or at home, but I was forced to be at the office anyway.
Look out for the opportunity to spend the day working from home or somewhere different wherever possible.
Time actually programming
Unfortunately, you will not be programming 100% of your week. As much as this may pain you, it’s not all bad. Programming isn’t 100% code anyway.
Much of your time will be spent in meetings, usually to the point of reducing the amount of time you need to spend programming. This comes through making sure that you are writing the minimum amount of code possible to engineer the best possible solution.
Outside the job
Some say that it doesn’t really matter, but others say that what you do outside the job is just as important as what you do in the job.
Programming on your own time
Once I realized the crushing reality of how terrible proprietary tooling and languages really are, I started to work on skills that I knew would be transferable to another company.
If you find yourself stuck in the same type of environment, knowing a few things about more mainstream technologies will help you in finding your way out. It’s a polarizing opinion, but I believe that time spent on career development in your own time has a great effect on the opportunities you will become open to.
Read
Now I have made my way through a few, I wish I had picked up some more books earlier. There are countless things to learn from books. Grab a few and read them on your downtime, at the office, or on your way there. Most people I know have some kind of commute, and it’s a great way to pass the time.
Write
Writing can be a great way to further your career. That’s what I’m attempting here. This isn’t just an advice piece, it’s a reflection. A good blog can also help you when you face a particular issue you may have faced before. If you keep a log of what has challenged you, it may just come to your rescue.
It may seem strange at first, but writing things down is a great way to decompress and exhale after stress. I make (most of) my writings public, but you don’t have to. Half of my posts are still sitting in the drafts folder.
Exercise
For the first two years of my career I didn’t regularly exercise and it certainly caught up to me. As a programmer, most of your day will be spent sitting, generally inactive, staring at a screen. You will not get to program all day, sure, but between meetings and time at your desk, you won’t be moving much. Try to exercise as much as you are capable of.
Taking some time off
As important as it is to be available all the time for work, it’s also important to take some time off every now and then. If you are not saving up for a big holiday, it’s sometimes nice to just make long weekends extra long, or take a few days off here and there. Many countries provide a varying number of guaranteed weeks of leave. Make sure to take advantage of this wherever possible.
I made the mistake of saving up as many leave days as possible and getting burned out in the process. It was a good decision financially, but not for my mental and physical well-being.
Thanks for reading!
I hope this reflection of my first two years of programming as a full-time job provides some insight into where you may head in your career. This has been an interesting reflection for me, and I hope you can take something from it.
Learning how to code can be overwhelming - especially if your intro course asks you to build a Facebook clone. But if you focus on the fundamentals, have the right guidance, and develop a strong inner motivation to succeed, you'll master the basics and be ready to move on. In this episode, you'll learn how to do just that.
Written by Rainer Hahnekamp: https://twitter.com/rainerhahnekamp
Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn
Original article: https://fcc.im/2LOmUao
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Transcript
I have been programming for more than 20 years. During that time, I’ve had the pleasure to work with many people, from whom I learned a lot. I’ve also worked with many students, coming fresh from university, with whom I had to take on the role of a teacher or mentor.
Lately, I have been involved as a trainer in a program that teaches coding to absolute beginners.
Learning how to program is hard. I often find that university courses and bootcamps miss important aspects of programming and take poor approaches to teaching rookies.
I want to share the five basic pillars I believe a successful programming course should build upon. As always, I am addressing the context of mainstream web applications.
A rookie’s goal is to master the fundamentals of programming and to understand the importance of libraries and frameworks.
Advanced topics such as the cloud, operations in general, or build tools should not be part of the curriculum. I am also skeptical when it comes to Design Patterns. They presume experience that beginners never have.
So let’s look at where new programmers should start.
Test-Driven Development (TDD)
TDD brings a lot of benefits. Unfortunately, it is an advanced topic that beginners are not entirely ready for.
Beginners shouldn’t write tests. This would be too much for their basic skill levels. Instead, they should learn how to use and work with tests.
Each programming course should center around exercises. I extend my exercises with unit tests and provide the students an environment which is already setup for running those tests.
All the students have to do is write their code and then watch the lights of the testrunner turning from red to green. The resulting gamification is a nice side effect.
For example: If the selected technology is Spring, I provide the exercises and tests within a Spring project. The students don’t need to know anything about Spring. All they need to know is the location of the exercises and the button to trigger the tests.
Additionally, students must know how to use a debugger and have a Read-Eval-Print Loop (REPL) handy. The ability to analyse code during runtime and to have a playground for small experiments is essential in TDD.
The main point is to ensure students don’t have to learn basic TDD behaviours after they’ve acquired core programming skills. Changing habits later in the students’ career will be much harder than learning those habits now. That’s why they should live and breath unit tests from the beginning.
Later in their professional life, they should have an antipathy for projects without unit tests. They should intuitively see the absence of unit tests as anti-pattern.
Fundamentals First
I hear very often that rookies should immediately start with a framework. This is like teaching people how to drive by placing them in a rally car and asking them to avoid oversteering. This simply ignores the fact that they still mistake the brake for the throttle.
The same applies when we start students with a framework like Angular. Beginners need to understand the fundamentals of programming first. They need to be familiar with the basic elements and what it means to write code before they can use somebody else’s.
The concept of a function, a variable, a condition, and a loop are completely alien to novices. These four elements build the foundations of programming. Everything a program is made of relies on them.
Students are hearing these concepts for the very first time, but it is of the utmost importance that the students become proficient with them. If students do not master the fundamentals, everything that follows looks like magic and leads to confusion and frustration.
Teachers should spend more time on these fundamentals. But, sadly, many move on far too quickly. The problem is that some teachers struggle to put themselves into the role of a student. They have been programming for ages and have forgotten what types of problems a beginner has to deal with. It is quite similar to a professional rally driver. He can’t imagine that somebody needs to think before braking. He just does it automatically.
I design my exercises so that they are challenging but solvable in a reasonable amount of time by using a combination of the four main elements.
A good example is a converter for Roman and Arabic numbers. This challenge requires patience from the students. Once they successfully apply the four elements to solve the challenge, they also get a big boost in motivation.
Fundamentals are important. Don’t move on until they are settled.
Libraries and Frameworks
After students spend a lot of time coding, they must learn that most code already exists in the form of a library or a framework. This is more a mindset than a pattern.
As I have written before: Modern developers know and pick the right library. They don’t spend hours writing a buggy version on their own.
To make that mindset transition a success, the examples from the “fundamentals phase” should be solvable by using well-known libraries like Moment.js, Jackson, Lodash, or Apache Commons.
This way, students will immediately understand the value of libraries. They crunched their heads around those complicated problems. Now they discover that a library solves the exercise in no time.
Similar to TDD, students should become suspicious when colleagues brag about their self-made state management library that makes Redux unnecessary.
When it comes to frameworks, students will have no problem understanding the importance once they understand the usefulness of libraries.
Depending on the course’s timeframe, it may be hard to devote time to frameworks. But as I already pointed out, the most important aspect is shifting the mindset of the student away from programming everything from scratch to exploring and using libraries.
I did not add tools to this pillar, since they are only of use to experienced developers. At this early stage, students do not need to learn how to integrate and configure tools.
Master & Apprentice
In my early 20s I wanted to learn to play the piano. I did not want a teacher, and thought I could learn it by myself. Five years later, I consulted a professional tutor. Well, what can I say? I’ve learned more in 1 month than during the five years before.
My piano teacher pointed out errors in my playing I couldn’t hear and made me aware of interpretational things I never would have imagined. After all, she instilled in me the mindset for music and art, both of which were out of reach for me as a technical person.
It is the same in programming. If somebody has no experience in programming, then self-study can be a bad idea. Although there are many success stories, I question the efficiency of doing it alone.
Instead, there should be a “master & apprentice” relationship. In the beginning, the master gives rules the apprentice must follow — blindly! The master may explain the rules, but usually the reasoning is beyond the apprentice’s understanding.
These internalised rules form a kind of safety net. If one gets lost, one always has some safe ground to return to.
Teaching should not be a monologue. The master has to deal with each student individually. He should check how the students work, give advice, and adapt the speed of the course to their progress.
Once the apprentices reach a certain level of mastery, they should be encouraged to explore new territory. The master evolves into a mentor who shares “wisdom” and is open for discussions.
Challenge and Motivation
“Let’s create a Facebook clone!” This doesn’t come from a CEO backed by a horde of senior software developers and a multi-million euro budget. It is an exercise from an introductory course for programmers. Such an undertaking is virtually impossible. Even worse, students are put into wonderland and deluded into believing they have skills that are truly beyond their reach.
No doubt the teacher is aware of that, but creates such exercises for motivational reasons.
The main goal of an exercise is not to entertain. It should be created around a particular technique and should help the students understand that technique.
Motivation is good, but not at the sacrifice of content. Programming is not easy. If the students don’t have an intrinsic motivation, coding might not be the way to go.
Newbies should experience what it means to be a professional developer. They should know what awaits them before they invest lots of hours.
For example, many business applications center around complex forms and grids. Creating these is an important skill that exercises can impart. Building an application similar to Facebook might not be the best lesson for students to learn right away.
Similarly, a non-programmer might be surprised at how few code lines a developer writes per day. There are even times where we remove code or achieve nothing.
Why? Because things go wrong all the time. We spend endless hours fixing some extremely strange bugs that turn out to be a simple typo. Some tool might not be working just because a library got a minor version upgrade. Or the system crashes because somebody forgot to add a file to git. The list can go on and on.
Students should enjoy these experiences. An exercise targeting an unknown library under time pressure might be exactly the right thing. ;)
The sun isn’t always shining in real life. Beginners should be well-prepared for the reality of programming.
Final Advice
Last but not least: One cannot become a professional programmer in two weeks, two months or even a year. It takes time and patience.
Trainers should not rush or make false promises. They should focus on whether students understand the concepts and not move on too fast.
Learning to code - or learning any new skill - is hard, but it doesn't have to be overwhelming. In this episode, Preethi discusses her tried and true strategies for learning, how to tackle challenging problems, and the methods that help her add new tools to her kit.
Written by Preethi Kasireddy: https://twitter.com/iam_preethi
Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn
Original article: https://fcc.im/2uG4B0F
Learn to code for free at: https://www.freecodecamp.org
Intro music by Vangough: https://fcc.im/2APOG02
Transcript
Being an efficient learner is at least as important as being an efficient coder.
When you’re a developer, your job requires you to learn every single day — in spite of the constant lure of distractions like Hacker News, Twitter, Reddit, and Facebook.
You constantly encounter new code bases and new technical challenges at work. Home is no better, as you tackle open source repos and personal projects, each with their own processes and challenges to tackle.
The tech world changes fast, and it can feel like a full-time job just keeping up with the latest tools, languages and frameworks.
Long story short: learning is hard. Yet, we need to be able to learn quickly and effectively to thrive.
In the past year, I went from not knowing how to use the Chrome debugger to working as a software engineer for a leading cryptocurrency company. In the process, I rapidly learned a new skill (coding).
That said, learning didn’t come easy for me.
Honestly, every new concept was a struggle. There were too many unknowns, and too much uncertainty.
“How in the world is this sustainable?” I thought to myself.
“If this is what learning to code is supposed to feel like every day, I’ll be miserable. Is this really my passion?”
“Wouldn’t this be easy for me if this was my passion? Do artists struggle to produce art? Do writers struggle to write a great book? Do athletes struggle to do well in a race? Are we supposed to struggle when we’re pursuing our passions?”
“Shouldn’t I be finding pleasure in this?”
Does it ever get easier?
Yes, it does. A year later, tackling new programming concepts is still “difficult” in the sense that it requires discipline and hard work.
But it’s also become an enjoyable process, rather than an overwhelming one.
What happened in the last year to make that shift possible?
Simple: I changed my perspective on learning. What once struck me as “difficult” became “engaging.”
In the rest of the post, I’ll explain how this transformation happened.
Just getting started
Learning to code is hardest at the beginning.
For example, think about the first programming language you have to learn. You want to tackle the small things like syntax and style. But first, you have to comprehend difficult core concepts like values, types, operators, control flow, functions, higher order functions, scopes, closures, recursion, and so much more.
It feels like learning to juggle — but starting with eighteen pins instead of two.
When I first learned about closures, it took me many weeks to truly understand the concept. I thought I understood it when I read about it. But when I tried to identify and use closures in practice, I’d find myself stumped.
That wasn’t unusual. I’ve observed this process as a teacher as well: new concepts don’t usually click the first time around. Or the second. Or even the tenth.
But for those who stick it out long enough, there will be a “breaking point” where things suddenly begin to make sense. In my example, I read literally every blog post, Stack Overflow post, and spec on the internet about closures.
Everything I read and experimented with gave me a new perspective, until eventually, I had a 360-degree mental picture of how closures worked. Closures “clicked.”
Getting to a point where I felt this sense of understanding of closures was super important, because it was rewarding and encouraged me to go for more — including writing my own blog post that explained the concept.
Learning is a process, not a goal
If we see learning as something we “have” to do, then we rush to get it done so that we can spend the rest of our time doing something more “fun” — something we “want” to do.The problem is that it’s impossible to know everything about anything, so viewing learning as a race leads to burnout and disappointment.
Instead, if you see learning as a process, you’ll appreciate the small victories and insights along the way. This will drive you to constantly move forward.
You can compare it to exercise. Workouts hurt, and then the pain ends as soon as your workout ends. But it’s never gone. It’s waiting for you the next time you workout. Except each time, the pain becomes less piercing. You learn to cope with it. You become familiar with the pain, and it just becomes part of the routine. You are rewarded by better health and a better physique and are incentivized to keep going.
Exercise creates a positive feedback loop.
The same is true for learning.
Turning learning into an engaging process
Imagine building your very first web application.
At first, all you’ve got is a daunting, blank text editor. The task of building the app seems almost insurmountable. You know nothing, and have so much to learn before you can make this happen.
Thankfully, you decide to go for it anyway.
From then on, your main focus becomes to do one small step at a time.
First, you create an idea. What will you build? Who’s the end user? What are the constraints?
Second, you prototype or sketch out some rough designs for what you think it might look like. You ask your friends or the internet for feedback, and iterate to make it better.
Third, you research languages, tools, and frameworks that will work best with your requirements.
Step by step you discipline your mind to channel all its energy towards this one goal.
Sometimes you’re writing code.
More often than not you’re stalled at some bug or error.
Sometimes you’re too tired to do any work, so you take a break.
Other times, you don’t feel like writing code. That’s okay. You spend your time researching or reading up on topics related to your project.
Eventually, after a few weeks of hard work, you’ve built a foundation that can handle your big ideas. Suddenly, working on your app doesn’t feel as painful. You see the reward of the initial set of hard work, and now it’s just another piece of code you need to write or another bit of refactoring you need to do — which you’ve done 100s of times already, no problem.
You turned what was once a daunting or dreadful activity into one that is complex and engaging.
This is how we grow. This is how we get better. Whether it’s programming, dancing, running, or reading: it’s not easy, and there won’t ever be a time or place when you’re “done” learning.
Instead, enjoy the process of investing your energy into something, and enjoy the pain that comes along with it. You’ll start to notice that you no longer describe it as “pain” — because what was once painful becomes a symbol for what’s next: a sense of personal accomplishment and self-satisfaction.
In other words, struggle and enjoyment will start to mean one and the same thing. Remember the cycle:
One approach to learning technical topics
Let me tell you a little about the learning process I follow. This isn’t the be-all-end-all of learning styles, so if something different works for you, please share it in the comments! In case you can’t tell, I’m a nerd about this stuff :)
Let’s use the process of learning the React.js library as an example.
What is the motivation for learning this?
First step: I’d start with a Google search for the React.js documentation and read a bit about the background and motivation for the library.Knowing the “why” behind any topic is incredibly helpful for framing the learning process. It answers questions like:
How is this different from other solutions?
How useful is this to me?
What problems does this solution aim to solve?
Is this just a new shiny tool that’ll only be useful for a few months or will it fundamentally change the way I think and code?
Reading and understanding core concepts
Second, I’d read through any intro articles or examples provided in the docs.
Notice I’m not touching any code yet. Reading and sinking in the core concepts comes before hands-on experimentation. It’s incredibly important to do this because it lays the foundation for the rest of my learning.
Even though I might be able to get away with blindly using React.js without learning the core concepts, eventually it’ll catch up to me when I run into a bug.
First time coding
After spending some time on the above steps, I start to get the gist of what’s going on, or maybe even feel like I totally get it. Then it’s time to jump into some code.
I typically try to build something really small with any new tool by following a video tutorial (e.g. on egghead.io) or a written tutorial before jumping into custom projects.
When you get stuck
…And then, inevitably, I get stuck.
Reading the docs seemed like a piece of cake, but actually using it in practice makes me realize I have no idea what’s going on.
This is when I start to feel that dreaded “just give up” feeling. But instead of giving in when the going gets tough, I remind myself that pain gain. Turning back would be cowardly.
Here’s what I do instead:
I first narrow down and figure out what I’m actually stuck on — i.e. define the problem. Then I come up with a hypothesis for what I think could be the root cause or causes of the problem. Even if I have no idea, I just make a guess.
Then I step away from the problem and my computer and do something that relaxes me. This is incredibly hard to do when I’m so upset about the problem I’m stuck on, but letting go of the problem works wonders. (Ever notice how great ideas always strike in the shower?)
Now I try to debug with my hypothesis in mind. I get as far as I can on my hypothesis without looking for answers online — there’s something beautiful that happens when you try to solve problems by truly thinking deeply about them on your own first. Even if you’re going down the wrong path, the fact that you made the effort teaches you a lot and you remember the problem space much better next time you run into it.
If my hypothesis leads to an answer, hooray! I’m done. If not, I Google search for documentation, blog posts, or Stack Overflow posts that could help me get closer to the answer.
While reading, I take notes on any and all pieces of information that could potentially be helpful.
Still no solution? That’s fine. I’m sure I learned something valuable by reading through all that, even if it didn’t directly help me solve the problem at hand. Who knows when this knowledge might come in handy next time?
At this point, if I’m truly stuck, I will either post a question on Stack Overflow or ask a co-worker or developer I know.
Otherwise, I rinse and repeat until I get closer to the final solution. At some point, the answer always comes.
At times this process takes a few seconds, and other times it takes hours (or days). Either way, the process itself is incredibly beneficial to your skill set as a developer.
Getting stuck on a bug feels like stumbling in a dark tunnel looking for a ray of light. You eventually find it, but along the way you discover so much about the tunnel — and it’s knowledge about the “tunnel” that makes you strong as a coder.
Think of debugging as a chance to explore rather than a detour from your goal, and it becomes much more fun.
Rinse and repeat
By this point in the learning process, I’ve built something small and tackled some small hurdles along the way. As you can see, it was a struggle — clearly, I need some more practice with the new tool.
So, once again I try to build something on my own. Rather than jumping straight to a big custom project, I’ll look for a repo to base my application on.
For example, if there’s an online CRUD todos example (of course) using React.js, maybe I’ll build a different type of CRUD application. Just different enough to keep me engaged, but not so different as to make me discouraged if something goes wrong.
Mastery
Mastery requires repetition, so I keep building more small projects until I feel like I’ve got the core concepts down.
Eventually, I begin to be able to piece things together on my own without constantly referencing documentation or examples. Only then do I finally adventure out and build something from scratch on my own.
Throughout this process, I aim to make the process fun and engaging. I’m constantly pushing myself to work on things that are harder than what I am capable of in the moment, but not throwing myself into the deep end so that I get discouraged and never finish.
Finally, I make sure to step away as soon as I find myself getting too frustrated to enjoy the project.
Learning is fun
With some effort and structure, learning programming turns out to be incredibly fun. At first it’s incredibly complicated, and in my opinion that’s why so many people get scared away — not because it’s “boring,” but because it’s “hard.”
After you go through this learning process a few times, processing new information becomes a muscle memory. You don’t really think about it. You just learn to ride the pain wave and find joy in the reward.
Like magic, it becomes “easier” to learn.
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
Transcript:
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.
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
Transcript:
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>
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
Transcript:
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.
Ledgers
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!
Problems
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.
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
Transcript:
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.
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
Transcript:
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.
Hmm…
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)
Plugins
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.
R B Greates Hits Videos 2017 And 2018
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.
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
Transcript:
“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:
Power
Connectivity
Firewall
DNS
Server Hardware (CPU, Disk, Ram, …)
Cooling
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).
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
Transcript:
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).
Joe Robinet Survivor Videos 2017 And 2018
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:
Responsibilities
- 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.
Best,
Austin
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:
Consistency
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!
Best,
[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.
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
Transcript:
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.
RTFM
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.
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
Budweiser Clydesdales Videos 2017 And 2018
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
Transcript:
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.
Latest Audacity Cs101 Videos 2017 And Torrent 2017 Torrent
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.
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
Transcript:
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