College - freeCodeCamp.org

Things All Developers Should Learn In College

freeCodeCamp — Mon, 15 Jul 2019 15:47:35 +0000

By Ryland Goldstein

Forget About "Lines of Code"

As a developer, you'll hear a lot of crazy, unbelievable theories about what "lines of code" signify. Believe none of them. Lines of code is a ridiculous metric to base decisions on. In very rare cases it tells you something, in all the other cases, it tells you nothing. Using lines of code to make decisions is like rating book quality by number of pages.

Some might make the case that the fewer the lines of code there are in an application, the easier it is to read. This is only partially true, my metrics for readable code are:

Code should be consistent
Code should be self descriptive
Code should be well documented
Code should utilize stable modern features
Code shouldn't be unnecessarily complex
Code shouldn't be un-performant (don't write intentionally slow code)

The moment reducing the number of lines of code interferes with any of those, it becomes a problem. In practice, it will almost always interfere and thus is nearly always a problem. But here's the thing, if you strive to meet the above criteria, your code will be the perfect number of lines, no need for counting.

There Are No "Good" or "Bad" Languages

__ Except for php, just kidding

I see people say stuff like this, all the time:

C is better than X, because performance

Python is better than X, because conciseness

Haskell is better than X, because aliens

The notion, that a language comparison could be reduced down to a single sentence is almost insulting. They're languages, not Pokemon.

Don't get me wrong, there are definitely differences between languages. It's just that, there are very few "unusable" languages (although there are many outdated/dead languages). Each language brings it's own unique set of tradeoffs. In that regard, languages are similar to tools in a toolbox. A screwdriver can do what a hammer can't, but would you ever say a screwdriver is better than a hammer?

obviously the hammer is better

Before I talk about how I evaluate languages, I want to make something very clear. There are very few cases where the language choice actually matters. There are things you can obviously not do in some languages. If you write frontend code, you don't get a language choice. But in general, language choice is usually one of the least important issues for a project.

Here are the core aspects (ordered), that I believe should dictate your choice of language (these are it's Pokemon stats)

Density of available online resources (StackOverflow density)
Development Velocity (vroom vroom)
Bug proneness (eeek)
Quality and breadth of package ecosystem (yea npm, it says quality)
Performance characteristics (more dots)
Hirability (sorry COBOL)

There are also some strong couplings that are out of your hands. If you're working in data science, you realistically need to use Python, R or Scala (maybe Java). If it's a hobby project, use whatever will make you happiest. There's only one non-negotiable rule I have. I refuse to use languages that don't have most of the problems I will encounter, directly solved on StackOverflow. It's not that I can't solve it, it's just not worth the time.

Reading Other People's Code is Hard

Source

Reading other peoples code is difficult. Robert C. Martin talks about this in "Clean Code":

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.

For a long time, I assumed that I just sucked at reading other peoples code. Over time, I realized that it's something almost every programmer struggles with on a daily basis. Reading other people's code almost feels like reading a foreign language. Even if you're comfortable with the programming language choice of the writer, you still have to adjust to differing styles and architecture choices. This also assumes that the author wrote consistent and reliable code, which can be hit or miss. This is a really difficult one to overcome. There are a few things I've found helped a LOT.

Reviewing other peoples code will improve your code reading skills immensely. In the past two years, I've reviewed quite a few Github PR's. With each PR, I feel slightly more comfortable reading other peoples code. Github PR's are especially great for these reasons

Can be practiced anytime, just find an open source project that you feel like you want to contribute to.
Practice reading in a scoped context (driving feature or bug of PR).
Attention to detail required, which will force you to evaluate each line.

The second hack which can help you read other peoples code is a bit more unique. It's a technique I came up with, and it's really reduced the amount of time it takes for me to feel comfortable in a foreign codebase. After looking at the style of the code I want to read, I first open up vi and starting writing code in the style used by the project. When you write code in the new style, it will also improve your reading skills. The style will feel less foreign, as you've actually experienced it. Even if I'm just browsing a random project on Github, I'll quickly do this. Try it out.

You'll Never Write "Perfect" Code

Source

I was a "lone wolf" developer for 4 years before I started working on a team. For most of that time, I just had this assumption that every programmer in the industry wrote perfect code. I figured it was just a matter of time and effort before I also wrote "perfect" code.
It's something I used to feel really anxious about. Once I joined a team, it quickly became clear that no one was writing "perfect" code. But the code going into the system was almost always "perfect", what gives? The answer, code reviews.

I work with a team of really brilliant engineers. These are some of the most competent, confident programmers money can buy. Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code. Even if you think you're the next Bill Gates, you will make mistakes. I'm not even talking logical mistakes, I'm talking typos, missing characters. Things that your brain tunes out and will never pick up on. Things you need another set of eyes for.

Strive to work with others that are attentive to detail and willing to criticize your work. Hearing criticism is difficult at first, but it's the only consistent way to improve. Do your best to not become defensive during a code review, and never take any comments personally. You're not your code.

When I'm reviewing someone else's code, I just Google search every choice they make and see if it differs from strong popular opinion. Often times, looking at the same problem with a "beginners mind", can catch things the person would have never gone back and looked at.

Working as a Programmer Doesn't Mean 8 Hours of Programming a Day

This is a very common question, but people never seem to give a clear answer.

Very few people are writing code for more than 4 hours a day

People who disagree with this are either the exception to the rule or work at companies that should treat them better. Programming is a mentally draining, focus intensive task. It's entirely unreasonable to expect anyone to write code for 8 hours a day, 5 days a week. There will be rare cases where you need to meet a deadline or pull a little extra for a stretch, but those are few and far between. When I say "rare", I mean almost never. Do not tolerate a workplace that abuses you and makes you work overtime due to poor planning/under-hiring.

For the record, it's not even in your companies best interest for you to work 8 hours a day. Your boss might think that's the case, but it's shortsighted and ignores the longterm implications, on productivity and mental health.

I highly recommend taking regular breaks during the day, and exercising (even if only briefly). The benefits of exercise on mental fatigue are well documented. I've personally found that exercise especially helps if I'm having trouble focusing.

Conclusion

These are a few of the things I wish they were teaching at university instead of pure theory. In the process of writing this, I came up with a ton of other items but those will have to come in the next post!

How to be The Superstar Intern You Know You Are

freeCodeCamp — Mon, 21 Jan 2019 16:40:58 +0000

By Maple Ong

Curb the Impostor Syndrome and get prepared for your upcoming Software Engineering Internship

_Photo by [Unsplash](https://unsplash.com/photos/Hcfwew744z4?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Christin Hume on Impact

Depending on the company you work at, you may be assigned work that would otherwise be assigned to a full-time software engineer. This is a great opportunity to make important decisions and in turn, have some sort of (hopefully, positive) impact on the team or project. But, you may also be tasked to fix bugs that are long due.

Credits: QuickMeme.com

If you are fixing bugs, you better make darn sure that there are no bugs left when you’re finished. If you are building an experimental project, build it for the long term.

Regardless of the work assigned, you want to maximize the impact you make on your team and project. As always, there is more than one way to make an impact. You could share your ideas in team meetings or take the initiative to learn something out of your scope to contribute to your projects.

If you’re having any doubts on how much work you feel like you are contributing, don’t hesitate to bring it up with your mentor or manager.

Having an impact on your team and project is one of the biggest factors that affect your internship and how you can shine as an intern. This is especially true if you want the opportunity to work at the company full time.

One-on-One Time

As a Software Engineering Intern, you will likely have a mentor, a manager, or both — and you will also be having one-on-one meetings with them.

One-on-one meetings (sometimes called sync-ups) with your mentor are valuable opportunities.

_Photo by [Unsplash](https://unsplash.com/photos/IgUR1iX0mqM?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">NESA by Makers on Get to Know Your Team

Aside from that, it is important to make connections with your co-workers as well. They can give you a good idea of how it’s like to work at the company full-time. Also, they are a good resource outside of your mentor and manager for work-related questions.

I found that having a strong relationship with my coworkers made me feel happier going to work every day. It also increased my work satisfaction.

_Credits: [startupPong](https://startupheretoronto.com/sectors/technology/startupong-wants-torontos-tech-community-to-give-back-with-ping-pong/" rel="noopener" target="blank" title=") — A ping-pong tournament for startups in Toronto

Although it may seem intimidating to approach full-time coworkers, people tend to be inclusive regardless of whether or not you are an intern. A great way to get to know people is to show up to social events outside of work, like board game night or the company’s indoor soccer team playoffs.

Another tip in making connections is to ask questions to learn more about what their role is in the company. People will feel more comfortable answering specific questions about their role and chatting about how their day to day would look like.

This is especially useful if you want to gain a better understanding of how the tech stack at your company works. Which, by the way, will be helpful in gaining more insight for the systems design portion in your full-time software engineering interview.

The Growth Mindset

“In a growth mindset, people believe that their most basic abilities can be developed through dedication and hard work — brains and talent are just the starting point. This view creates a love of learning and a resilience that is essential for great accomplishment.” — Carol Dweck on Mindset

Technical growth is a factor that is proportional to the impact you have on your team and project. However, you could be making some level of impact and not be growing as a software developer because you aren’t absorbing anything new.

With that said, I find that asking myself, “What can I learn next?” or “Where else can I apply this knowledge?” can show me what I need to do to keep taking my technical skills to the next level. The simple act of asking questions and learning continuously will be beneficial to your growth.

_Photo by [Unsplash](https://unsplash.com/photos/MdexOj4D-MU?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Stanislav Kondratiev on Learn Efficiently

Science says that learning styles, despite being around since the 1950s, are a myth. However, expanding your knowledge and learning efficiently is a productive habit to have — especially as an intern. So how can we learn more efficiently?

One of the first things I noticed about my learning style during my first software engineering internship was that I preferred watching a tutorial video to reading a tutorial. My mind gets easily distracted when I try to read a tutorial and then implement something.

On the other hand, I also enjoy reading articles that are written by experts in fields I am unfamiliar with. Unlike in tutorial-focused articles, general articles provide a different level of detail and examples that cannot fit into a 3-minute video.

Fortunately, the internet is overflowing with well-written articles. A quick Google search on a topic of your interest would prove this point.

To learn more efficiently, it is best to focus on the medium you enjoy the most. Perhaps your favorite YouTuber covered a topic you are unfamiliar with. Or a famous CEO wrote an article on that new technology you are curious about. Be open and explore new ways to learn and stick with it.

The key is to self-reflect and learn more about how you absorb information. Don’t be afraid to change things up if you find that reading boring API documentation makes you want to rip your hair out.

Ask Good Questions

People say there are no dumb questions, but for goodness sake — don’t ask your mentor something trivial you can solve with a quick Google search.

Make sure you try to understand and solve the issue to the best of your ability before reaching out for help. There should be a balance between asking for a spoon feed versus having a discussion on the issue.

_Photo by [Unsplash](https://unsplash.com/photos/komOcyIICoA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">rawpixel on ? Action Items:

Set expectations with your mentor/lead for the term: What is your goal for this internship? How can we achieve that together?

Speak up in meetings, don’t be afraid to contribute!

Ask for constructive feedback on both your soft and hard skills

Ask someone on your team to go on a coffee run

Take part in a non-work social event for fun

Find and connect with your coworkers on LinkedIn

Listen to a technical podcast that interests you! I highly recommend Software Engineering Daily.
Talk to your mentor about what you have learned in the past week. How can you apply that knowledge on a project in the future? What would you like to learn next?

You made it to the end of this article — thank you for reading! Please give it a clap if you liked it, and a comment ? if you have something to add.

Connect with me on LinkedIn and say “Hi!”

A Computer Science degree: ticket to your dream tech job or a useless piece of paper?

freeCodeCamp — Wed, 16 Jan 2019 19:57:26 +0000

By Colin Smith

The decision I made

If you were like me when you were first looking to get started with coding, you wanted the easy path to a tech career. I was looking for the fastest, most assured way to get a tech job with the least amount of resources involved. What do I mean by resources in the situation? The most important things to every human being on this planet: time, money, and energy.

I kept going back and forth on whether I should take the plunge and do the degree. The fact is, going back to school did not appeal to me at all. I thought I was done with taking classes back in 2011 but getting the degree would mean re-entering the classroom. I dreaded the thought of being bored out of my mind listening to someone drone on about a topic that may not even end up being relevant to my future career.

Also, failure meant a huge waste of all the resources I listed above. Once I took this route, there would be no going back. And that was terrifying.

I kept trying to find a way around the degree. The issue is, back when I was looking, there were no other options. There were some crappy and hastily put together “courses” on Udemy and other websites that I tried. They were clearly sub par and wouldn’t have gotten me anywhere. I also couldn’t find any articles or stories about people who had succeeded without a degree.

After evaluating my situation and all paths available to me, I decided to go with an online computer science degree. My situation was pretty unique since I was living abroad at the time which limited my options either further. I felt that a computer science degree was the only way to go. When I made my decision, there weren’t other options for breaking into a tech career, such as freeCodeCamp’s amazing online program. So I went with what I knew and what I thought was the only way to achieve a successful career switch.

So now that you know the path I took, and why I took it, would I make the same decision again? The answer is “no, probably not”.

_Money makes the world go ‘round. Photo by [Unsplash](https://unsplash.com/photos/JhKrHWlZcCk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Russ Ward on Reasons to consider another option

The knowledge gained is too small on too wide a range of topics.

Computer science programs are usually outdated.

The cost is prohibitive.

Degrees aren’t necessary for a lot of tech jobs.

Let’s start with the first point. You are getting a very small taste of a lot of different things. The issue is you aren’t learning about any of the topics enough to transfer your knowledge to skills that employers would value. The little sample app you made in your web programming class is definitely neat. But it usually won’t impress an employer unless you’ve gone above and beyond yourself. And this is a major issue in a job economy that highly favors skills. According to this article applicable career skills are number one:

“Instead of emphasizing the need for specific titles and experience, organizations are shifting towards a focus on the skills that a potential employee may bring.”

— Abigail Hess

Jack of all trades, master of none

Another issue is that the information from the classes you will take comes from people that were working professionally 10 to 20 years ago. Which is like 100 to 200 years in tech time (remember when Yahoo could have bought Google for 1 million bucks 20 years ago?).

Things change quickly in tech and the knowledge you are gaining may be out of date the minute it enters your head. Options like bootcamps or freeCodeCamp that are more tailored to being competitive out of the gates tend to have up to date information. They also only focus on the things you need to know without focusing on topics that aren’t relevant to the career you are pursuing.

Some of the classes I took during my degree include assembly programming, networks, databases and algorithms. Did I end up using much of the knowledge I learned in my future career? No, not really. At least not anything derived specifically from the courses.

_Too many things to focus on. Photo by [Unsplash](https://unsplash.com/photos/bBgqqWZAVT4?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">rawpixel on Costs involved

Let’s move on to the cost. According to CollegeBoard, the average tuition and fees for a four year in-state public college for one year of school was $10,230. This doesn’t account for room and board which would bump it up to $21,370. Multiply that by the number of years it will take you (4 years for most people) and you get $85,480. Also fees will go up while you are in school so that final number will definitely be higher.

So that is a lot of money but there is another cost that you will be incurring by getting a degree: opportunity cost. Right now, there is a huge demand for tech jobs and if you can become a viable candidate in this market, you will have a good chance of getting a job. Will that be the case in four years from now? Well, I don’t have a crystal ball, but I can tell you is that there is no guarantee.

Do you really need it?

Back to the job market right now. The fact that tech skills are so highly in demand means that employers are willing to overlook a lack of title or qualifications. Even top tech companies like Facebook are looking past degrees and other qualifications. According to this article on currently in-demand skills:

“Skills really matter the most,”

— Janelle Gale, VP of HR, Facebook

If you can do the job from day one and you have some soft skills, then you have a strong shot at landing a job. In fact, alternative options like freeCodeCamp and bootcamps may even give you a better shot at landing a job. The reason is you will be trained in skills that can be directly applied in a job. You will also get a great portfolio app or website when you complete one of these courses. Having a strong portfolio is a sure-fire way of garnering attention and getting interviews.

_An example of what you might want to do with your computer science degree after finding out the person that sits next to you got their job without one. Photo by [Unsplash](https://unsplash.com/photos/YzSZN3qvHeo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Gary Chan on Common misconceptions

Well, what about getting interviews? Computer science degrees help with getting interviews right? Once again, it depends. I told you I got my degree online. Well some companies look down upon online degrees. I was flat out told during screens that, “an online degree isn’t enough to get you an interview”. I saw this multiple times over chat during an online job seminar. Ironic, right?

I also wasn’t offered much support by my school in searching for jobs. Every lead they gave me either turned me down due to my degree being online, wasn’t a good opportunity or required me to move to the middle of nowhere. I also wasn’t given much help or support by my career counselor. This is usually listed as one of the biggest advantages of getting a computer science degree. Sadly, in my experience, the counseling you receive from public colleges tends to be really underwhelming.

So a degree really only really helps if you got it from a good school with a good counseling program, you attended classes in person, and you have portfolio projects that you can show off. It also only helps for your first job (read here on how to succeed in your first interview). Once you’ve proven yourself at one tech company, the computer science degree becomes much less important.

The Benefits

So enough nay saying. There have got to be some benefits right? Well there definitely are. The first thing is experience with a wide breadth of topics in tech. If you have studied something, you will have an easier time looking up information on the topic. Someone with zero knowledge will struggle to even ask good questions, let alone find answers. Having studied these topics gives you a small base in most things you will come across in your tech career. This means you can tackle somewhat unknown areas in your job and manage to keep your bearings.

The second thing you get is experience with multiple programming languages. The good part is you use them in scenarios that are somewhat applicable to the real world (this varies from class to class and degree to degree).

During my computer science program, I was able to use C, C++, Python, MASM, PHP, and JavaScript. I was able to build small sample projects with each of these languages and get some feeling of how they differ and which one felt the best to me. This also gave me some direction when choosing which career path I wanted to take in the future. I liked C++ and Objective-C was also a superset of C so iOS development made sense as a career path for me.

_Having classmates that are working towards the same career goals as you can help keep your motivation going. Photo by [Unsplash](https://unsplash.com/photos/vdXMSiX-n6M?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Mimi Thian on Mishal Ibrahim on The Verdict

So do all the benefits above make the degree worth it? I’d say no. The main reason for me was that I was saddled with a ton of student debt once the program was completed. I am writing from an American perspective so having debt after completing a computer science course may not be an issue for you. But no matter where you are, a computer science degree will certainly cost you more of at least one of the resources I mentioned above (time, money, energy) compared to a bootcamp or free online course approach. It will be slower for sure.

So whats the verdict? At a higher cost to your time, money and energy, a computer science course may help you with getting your first job (read my article here for some tips on succeeding in your first interview). It may help you keep your motivation through camaraderie with other students and will give you a wider breadth of knowledge. Without a computer science degree, you will almost certainly save on the resources I mentioned above. But this comes at a higher chance of having a harder time securing your first job. Those are really the main things I would take into consideration when making your choice.

And don’t worry too much about which choice you take. As long as you take small steps forward, you will find yourself where you want to be. I could look back and wish that I went with a free course like freeCodeCamp and be much richer in time and money. But I made my choices and still ended up where I wanted to be. I achieved what I wanted in the end. And the fact you are reading this article means that you have also just taken a small step towards your shiny new tech career too.

Liked what you read?

Feel free to check out some of my other articles:

My story, how I went from an assistant language teacher to working at a top tech company.

How to be successful in your first tech interview.