What are the biggest differences between FCC and real dev work?

Career Advice
1

Hey everyone,

So I’ve been studying 30-40h per week since the beginning of November and I’ve just finished the JavaScript projects. I know nobody knows when to really start looking for jobs but I figure once I’ve got through the libraries section (here in Munich, seems like everybody is asking for SASS and React) then I’ll be prepped to start looking for work as a dev.

My question is this: what are the major differences between solving problems on FCC vs. actual work? Obviously there is a lot more reading of other’s code and less hand-holding (and probably more coffee-brewing? Haha) but I wonder what the set-up is like. I’ve read a lot on Medium and technical excerpts from You Don’t Know JS and The Front-End Developer Handbook 2018 but I don’t know what to expect in the workplace; I mean, I don’t even know if people use IDEs or write in text editors, haha.

What were the things that surprised you most when you started working after FCC?

1 Like
2

Working for a company is very different from studying on your own in so many ways that I don’t really know how to answer that. If you poke around the Getting a Developer Job section of the forum, you’ll see lots of people talking about their work – from the size of their teams to the technologies they use, to photos of their cubicles. Maybe reading more of those will help you articulate more specific questions that we can answer.

3 Likes
3

team work is the biggest difference. You can learn on your own all you want (I did) but working with others will be the main thing that is 100% going to be different. Stuff like knowing how to use git, github, bug/issue trackers, read/write requirements are all things that are “outside” of dev work you might run into.

Now for the development part, Id say it’s similar. Depending on where you end up working, you might have your own station with set tools, or you can do whatever you want.

I personally work for a smaller company, so everyone more or less uses what they feel comfortable, but there are standards once the code “gets pushed” to github, and standards as to what gets pushed and how. Standards will differ from place to place, but they almost always exist.

PS. If your working somewhere and people are working in basic text editors (like notepad) quit ASAP :stuck_out_tongue:

4

Probably the difference is working with others and having to do code reviews. Instead of working on your own projects with your own freedom to choose features - your manager/PM gives you tasks that you have to complete by end of sprint.

Failure to complete FCC work is no big deal - you have time to complete your tasks. Failure to complete your assignments at work will lead to - missed deadlines for the sprint, headaches for your coworkers and by that point you’re on the way out lol.

The other thing is that your work is going to be constantly reviewed by your coworkers and if the work you put out is garbage well … It’s not going to be like FCC where you kind of get to do your own thing and people here are generally pretty nice when reviewing people’s work.

5

That’s a lot of good information, thanks :slight_smile: The fact that code has to be of good quality is obvious but I suppose after the first two FCC certificates I still don’t know where mine sits; I check with the solutions and I’m usually using declarative approaches like the intermediate and advanced solutions, but never quite as elegant as the solutions provided. I think I’ll start browsing through github a little more and trying to practice reading and working on other’s codes. Thanks a bunch :slight_smile:

6

I guess I need to start working on some of my own projects at this point because mostly I have only really worked on the FCC curriculum and so I haven’t really encountered the problem of failing to complete assignments because they’re all so short as it is. Thanks for the information :slight_smile:

7

I suggest going on Github, finding a project and reading through some Issues and Pull Requests. When you have a real job, you’ll work according to some software development “methodology” (you can look that up as well if you want) that is kind of a system for organizing how the work is done. But mostly it comes down to splitting the work up into tasks, documenting / investigating the tasks until you’re ready to implement (write the code), and then somebody reviews your code and either accepts it or asks for changes.

8

There are many differences, but two stand out. First, in a professional environment, the apps will be HUGE compared to the projects you do here at FCC. Perhaps a 100 times as big. Imagine 3-4 developers working full time for 2 years. That’s a lot of code. So much code that you could never read it all. Overtime, you will develop strategies for dealing with this, but I highly recommend having a look at a real world project and dealing with the OMFG factor before you start your first job.

Second, working in a team using Agile and a workflow tool (most likely Jira). You won’t be building the app. You will be given a series of distinct jobs to do, such as fixing a bug or extending a feature. Not as crap as it sounds!

1 Like
9

Some very good answers already, but just to add on and try to put things as plainly as possible:

With FCC, or really any online tutorial-type platforms (including MOOCs), usually you’re the developer and designer. In most instances, you get to write an entire app/site from scratch. You decide how to do it, how you want it to look, and everything you want to include, and then you do it.

Most jobs aren’t like that. In most jobs at larger companies, you’ve given a set task, or you’re told what to do—“fix this issue”, or “add this feature”, or “figure out what’s going wrong and then fix the problem”. Or for small- to medium-sized companies and agencies, a designer might give you a mock-up, or high-level managers might give you a development specification for a project that meets the needs of a client. Something along those lines. You’re rarely going to be able to write a new app from scratch, from the ground up, using your own creativity throughout the entire process from inception to delivery.

That’s not to say those kinds of jobs don’t exist though, because they do. If you want that kind of job, you basically need to became a senior-level developer and work for a startup that has a new idea they want to build. Those are the jobs where you’ll get the most development freedom and will basically be able to creatively envision and influence whatever app you’re working on.

Generally, very small companies are the ones where you’ll have that freedom, but such companies will also usually demand the most skilled (read: senior-level) developers who will be able to deliver and adapt quickly. As company size increases, it gets more likely that your work will allow for less creative (and technological) freedom and that you’ll become part of a larger team effort (but no less important).

Also, as mentioned the apps made by large companies will be HUGE and will often be too big to comprehend by any one person. Take a look around GitHub and look for large projects with open issues. Try to read and understand an open issue, and if you think you can implement a solution, then try it. Resolving open GitHub issues on large projects will give you the best understanding of how “most” real devs work (not all devs of course, but a large cross-section for sure).

The largest companies, especially those who deliver enterprise “B2B” products, typically use IDEs of some sort, whether it’s IntelliJ, Visual Studio (not Code but the full app that usually runs on Windows), etc. Inevitably these companies adopt a certain stack of products for development, like Microsoft’s for example, by using C# and .NET with SQL Server.