Complexity of professional front-end web dev vs FCC front end advanced

Could someone who works as a professional front-end web developer share some insight into how much more complex the programming and design becomes compared with the FCC front-end advanced projects and algorithms. By this I mean, on a day-to-day basis, is the complexity of the front-end applications written going to be far greater than those done in the advanced FCC front-end and data visualisation sections. I’m only asking about front-end and not back-end.

I’ve just noticed that for myself and others as well, even after a number of years spent learning front-end JS, anything on a level more advanced than the FCC front-end advanced and data visualisation projects is going to be way over our heads.

3 Likes

I’d be interested in seeing this myself :slight_smile:

The later algorithms probably contain more complexity than 90% of day to day web work, most things are beginner level if you could actually look at them in isolation from the business/organisation they serve. But you can’t do that. The hard part of dev isn’t to do with code you write most of the time; hard part is partly to do with figuring out other people’s code, mainly to do with understanding how business rules are described by the code. Latter is the most important part of any job, FCC/any tutorial cannot train you for that.

5 Likes

Let me start by defining what is “complexity” in front end development in my experience.

In the case of a front-end professional, complexity doesn’t come from having to solve huge complex problems that requires (too much) logic, algorithms, and intricate time/space performances.

The real complexity comes from the needs of familiarity with tools/technique you may or may not know.
Or in other words: you have to learn fast.

Let me elaborate a bit about it.
If I compare the “professional” myself now, with the “learning” myself a (little) while ago I guess the main difference is that now I cannot spend too much time prototyping, trying and researching.

If I receive a request now to implement something, I cannot trial/error my way to the solution like I did while learning.
I have to already know how to proceed, do a little research while working, and be confident that what I’m doing will be right.

The same applies when learning new tools.
It’s obviously that you cannot know everything, but it’s required that you learn the least minimum to start working and be productive in a shorter time that what you may have been used to while learning.

This does not means that the job is “easy” and you are just a typing code machine.
Often you’ll be asked to implement something that will require you to actually sit back and think about it and that legitimately you have no idea how to do it.

The learning myself would simply dismiss it with a “I can’t do that, I’ll do it this other way that I know instead and it will work regardless”.
On the job this attitude is not permitted, you can’t just change the requirements because is more convenient for you.

Here the best advice I can give you is the same my senior gave me a while back when I was confronted with the same problem:
In CS there’s no “it can’t be done”. There are just things you know or don’t know how to make.


And that’s why in my opinion the best asset you can have to “be hireable” for a junior/starting position is to show that you’ve already developed some projects for yourself.
Because, as said, on the job confidence is the key; and practice is what helps you build it.

If you have any more questions I’ll be happy to reply :slight_smile:

3 Likes

This sums up what I was going to say better than I was going to say it.

The projects are much more complex. They are bigger, have more elaborate requirements, may use in-house tools there is no documentation for, are written mostly by other developers (many of whom may not be around to talk to anymore), and already exist with all this complexity on the day you show up.

1 Like

This reminds me of something I heard a lot in the Army “Theres no such thing as thats not in my job description” If you were told to do it, no way no how was your response ever to be, thats not my job or… i don’t know how to do it. The only acceptable response was…Yes sir/sergeant! or if you’re extra motivated Hooah! :laughing: and then you bust your ass trying to figure it out cause you know it better be done, and its gotta be done right.

The responses about professional work is really encouraging actually, cause thats the thought process Ive applied to my freelance work. Notably, when I first started out, I only knew HTML…when I was asked if I could create a database to keep track of customers, I was like…of course!!! Then I poured myself into learning SQL so I could figure it out. I actually really enjoyed the challenge, to go from knowing nothing, to creating something that the company ended up relying on and used for for nearly 15 years right up til I left the company last year. Theres a lot of awesome in that feeling.

Huge relief too though that the problems in the Adv algos is not an everyday on the job sort of thing, though sorting through someone elses code does scare me a little (a lot…a whole lot) since thats something Ive never really done. Trying to get more involved with helping on FCC and really need to put some effort into helping with more JS problems. Cause right now, Ill understand the question, and look at the code and I have no idea what Im looking at…when I should.

This probably differs a lot amongst developers but here is my take…

Especially on the front end, most of the code required to do what I need isn’t overly complex. If it is my approach is probably bad or I am reinventing the wheel and there is a library to do what I need. As a front end dev your challenge will probably not be cracking algorithms in vanilla javascript. Things that challenge me day to day are:

  1. Building things that don’t have bugs.
  2. Building things that work well on all browsers and devices
  3. Tweaking libraries to suit my needs, and making everything play nice together
  4. Reading the code of others, and using their code successfully
  5. Writing code that I can come back to a month later and still understand
  6. Writing code that doesn’t become useless if your requirements change

All that being said, a solid grasp of CSS & JS is always handy, and will make all of the above easier

That’s a really good explanation of things. It’s still good to have experience with the hard stuff so when it comes up you’ll be prepared :slight_smile:

1 Like

Definitely. Getting skills as much as possible to the point of being muscle memory is extremely important - speed and accuracy and ability to write easily-understandable, performant code in the small means that when programming in the large, I can concentrate on getting applications working rather than being tied up with minor syntactic concerns.