We’ll start this article off with a weird insight: why being able to build a complete Fiat is better then being able to build half a Ferrari. As always, such a blank statement doesn’t work all the time - and could possibly even sound illogical - but hear me out: I’ve learned this the hard way, and I’m sharing it with you for free 😉

A desk with a open laptop with some code on it Image from Unsplash

1. It’s better to know how to build a complete Fiat then half a Ferrari

For the longest time in my web development career, I’ve tried to be the “front-end” guy.

This somewhat worked, but as time went on, I began to realize a pattern. Any competent “full-stack” web developer was cherished by their teams a lot more than either a front-end or a back-end web developer.

It seems so obvious from this standpoint.

A competent full-stack web developer is very valuable to any web-development company.

A specialist front-ender or a specialist back-ender are nowhere nearly as praised or cherished.

Here’s a metaphor of what a front-end developer, or a back-end developer can deliver to a client:

  • A single brand new shoe (when the client really needs two)
  • A remote control without batteries
  • Half a business suit (so that the client “can” go to a business meeting)

Obviously, none of the above are very useful for the end client. 

So, the first tip, trick, or lesson learned from experience is: It’s much better to be able to build a complete Fiat than half a Ferrari. You can be the greatest front-end developer in the world, or a mediocre full-stack developer, and the chances are that many, many companies would rather take the latter.

This is because even a mediocre full-stack developer can deliver a complete solution to a client.

Even better: It’s actually easier to be a semi-competent Fiat builder rather than a super competent half-a-Ferrari builder.

However, please take this advice with a grain of salt. If you’re just starting out your career, aim for being that Fiat guy. Long term, however, your career trajectory should go on in the following stages:

  1. “I can build a complete Fiat” (for example, “I can build a custom WordPress site for a client, put in on a TLD, teach the client how to use it, and be able to debug and update the site as needed”)
  2. “I can build a complete Fiat, and I can also build half a Ferrari” (this means that you’re competent enough in doing the “easy stuff” - as a full service; but in addition to that, you can also do some specialized stuff on a lot more demanding technology - i.e “a Ferrari”)
  3. “I can build a complete Fiat, and I can also build a complete Ferrari” - this one is unicorn teritorry, it’s not easily achievable, and it’s a pretty fluid thing

Throughout your career, you’ll probably be somewhere in between any of the above three points, at any given time, in a number of tech stacks. What can I tell you, it’s a crazy industry.

2. Don’t believe the hype, aka “WordPress is not really coding”

I drank the cool-aid too.

For the longest time I listened to the nay-sayers, proclaiming that “WordPress is not really coding”.

Similar to how people justified the reason to learn React with: You don’t really know JavaScript if you don’t use React. 

Don’t believe the hype.

Let’s define a “WordPress” developer as a person who can:

  1. Set up hosting, emails, and top-level domain for a company or an institution
  2. Upload and customize WordPress for it
  3. Utilize existing plugins or write their own so that the specific business’ use-case is taken care of

When you compare the above with the “geek-vetted” approach of: “I’m so smart that I can build all of that from scratch” - without any regard for the unknown unknowns, as well as a client’s budget, the timeframe of the project, etc. - in many cases, the WordPress choice is simply a smarter way to do things.

3. Passive Learning VS Active Learning

At a certain point of my professional career, I was watching long tutorials on web development, day after day.

Some of them were 20+ hours long.

I was doing everything in my power to acquire that knowledge and retain it. Then, a month would pass and I’d be staring at a blank screen not sure how to go about writing some code - and I was supposed to know this stuff! After all, I’ve gone through the entire course, and I tried to build it!

There’s a difference between passive and active learning.

Active learning is slower - sometimes much, much slower.

But learning actively, you end up retaining the things you learned.

The difference between passive and active learning is such a big deal, and it’s so massively important, that I’ll write an entire separate article about this specific issue (not yet published).

Here’s one key takeaway: If you’re solving a problem at work, watch a tutorial and try to solve your problem. This helps a lot in understanding the material you’re learning, with the added benefit of solving real-life problems at your dayjob.

4. Even the best player in the world still has a coach

Pride is a funny thing.

For the longest time, I thought that “if I ask others for help, I’m weak”. 

Or sometimes I’d think “Other developers probably know as much about this subject as me, so there’s no point in going around asking them for advice”.

Yet some other times, I’d think that “It’s better if my team members don’t know what I don’t know - if they did, they might think I’m at junior level”.

The problem with all these examples is that they are sometimes true.

And very often, it’s very hard to ask for help.

Additionally, due to how many of the smaller, boutique IT companies work, it’s often very hard to reach out to your co-workers and ask them for help:

  • sometimes they’re too busy to help
  • sometimes they have a vested interest in you failing - possibly because the IT company lost a major outsourcing client - and now there might be a down-sizing of the workforce - or for a number of different reasons

There are even platforms that fill this mentoring niche, like codementor.io.

But the fact remains, it’s very hard to find a mentor, and keep one.

If you do manage to find a mentor, you’re in luck. It’s literally the difference between failure and success.

And if you still think that you don’t need a mentor, or can do without one, just remember that even one of the best tennis players of all time, Novak Djokovic, has a coach.

So, maybe you should instead ask yourself a rhetorical question: “Is there any sports person that doesn’t have a coach?”

5. Pair-programming is very useful for knowledge acquisition and retention

This is another important trick to keep in mind.

Having a reliable partner to pair program with will do wonders for:

  • your knowledge
  • your self-esteem
  • getting “un-stuck”

Learning to code can sometimes be a lonely experience, but when you’re pair programming, the whole thing becomes so much easier.

6. Understand that it’s a marathon

We live in a world of instant gratification.

Everything is available at the click of a button.

There are even books with titles like Teach Yourself C++ in 24 Hours.

If we assume that the author of this book had an honest intention to teach you as much C++ as possible in a single day, the title is still a bit misleading, because:

It makes it seem easier than it is.

Or maybe nobody would buy a book titled Teach Yourself C++ in 24 Years.

But the second title would be so much closer to the truth.

Anyway, the point that I’m making here is: You need to understand that it will take at least 5 years for you to become somewhat competent in the web development field. You might think that you’d do it a lot faster, and that’s possible, but:

  • You must be genius-level smart, or
  • You must have some kind of an extremely unfair advantage, or
  • You must not have a life (you can in fact sit by the computer 24/7 for the next 5 years)

So, while web development is a satisfying and lucrative career, you need to be aware of the fact that it will take years to become good at - if you’re planning on being really, really good.

Luckily, you can cut down the time significantly - by “getting a foothold” in “being able to build a full Fiat”. It’s probably best to start with WordPress development, but offer it as a “full-stack” service, where you’ll do all the setup for the client, including the hosting, the domain purchase or transfer, the emails set up, the WordPress development and training the client to use it, and finally, the ongoing servicing of the website - the upgrades of plugins etc. Then you can offer this service either to an employer, or as a freelancer.

7. Knowledge acquisition and culture are two most important things in your day job

Ok, so let’s say that you somehow manage to convince someone to hire you in a web development role even without previous knowledge. After all, this is possible, I’ve seen it happen numerous times.

What you need to strive for is not the paycheck. Starting out as a junior, you need to:

  1. Find a way to learn from your co-workers
  2. Find a culture worth working in

This is a tough one. I’ve seen many, many IT firms where:

  • co-workers don’t share knowledge
  • there is no sense of community

Sometimes, it’s like a bunch of lone wolves sort of “agreeing” to stick together because there’s some bacon they need to bring home. But there’s no knowledge-sharing, no internal training, etc.

I’d even argue that many, if not most IT firms are that way.

You can easily figure out if you’re being hired into, or already working in a knowledge-first, community-oriented IT company:

  • Is the management actively pursuing the culture of sharing knowledge?
  • Do you have in-house training on the tech stack?
  • Are you pair programming (as a conscious effort of the management to improve and normalize employees’ skills)?
  • Is there an “employee skills development” plan in place? In other words, does your management track the level of knowledge of your workers? Do they have a plan for your skills improvement in the next 3 months, 6 months, a year?

All of the above points can be summed up in a single question: Is management taking skills improvement of workers seriously?

8. Front-end VS Back-end is a false dilemma

Do you want to be a front-end developer? 

Or a back-end developer?

If you picked either, you’re mistaken.

If you’re just starting out your web development journey, you should strive to be a mediocre full-stack developer.

Once you’ve achieved that, only then you would want to “pick a side”: front-end or back-end - or, if the conditions are right and you are able to do it - continue with your full-stack pursuits.

To phrase it differently, don’t try to be “the front-end guy”, or “the back-end guy”. Instead, try to be “the solutions guy”.

It doesn’t matter what tech stack it’s in. Just try to develop the skills to deliver a full service. You pick of the technology is irrelevant. Still, to drive the point home, let’s list possible full service avenues to explore:

  1. “Full-stack WordPress developer”
  2. “Full-stack Magento 2 developer”
  3. “Full-stack Shopify expert”

Notice how the word expert has a better ring to it than developer.

9. Pre-performance routines - aka “Situational practice”

There’s a concept in the theory of sports training, known as “situational training”.

Basically, it’s an attempt to simulate a real-life situation in a real life game, say basketball - with audience and all - so that, when the time comes, the player is used to the distractions of the crowd and can perform to the best of their abilities.

Put differently, the goal of such pre-performance routines is for the player to be able to successfully complete closed skills.

What are closed skills?

A closed skill is an activity with a well-defined beginning and end.

For example, a penalty kick in football. Or a free throw in basketball.

Now that we know what situational training is, how does that translate to learning web development?

It’s simple: When a developer sits down at his work desk to perform his work duties, in a way, they are in a one-person match. They usually have well-defined goals, a specific time to complete them, and pre-defined tools and technologies to use in achieving those goals.

The role of any web development training should be to empower the learners to be able to perform these duties in such a scenario. In other words, all the web development training should be organized as a pre-performance routine.

For example, a full-stack course on a technology should start with two basic concepts from the get-go:

  1. Deploying the app to production, be it a live site or an app for download
  2. Tracking the development with a source version control software (such as Git)

I’ve seen many, many tutorials where instructors go into the intricacies of a tech stack and the specific development implementation, but fail to cover the basics:

  1. Proper development environment setup
  2. Proper production app deployment
  3. Properly working with Git

Even more rare is an introduction into collaborating in Git, on a project, with other developers - and that’s a part of everyday activities for a vast majority of developers. So why is it not taught?

Because you can’t teach some things in a course.

Bonus: Specialists go to Enterprise

This bonus point might be a bit controversial.

If you really want to specialize and instead of opting for a full-stack developer role, you do decide to go for, say, purely front-end web development expertise, try to land a job in a large company with 100+ employees.

Usually, it is enterprise software vendor companies where you can fit a specialist role without having to go out of “your comfort zone”.

Otherwise, you might find yourself in a situation where:

  1. Due to the culture in the company, you can’t truly count on co-workers helping you out
  2. Even though you’re a “front-end specialist”, you’d be assigned to full-stack tasks - which you’ll then have a hard time completing

The reasons for the point 2 above can be various, but they mostly boil down to one of the two reasons:

  1. There’s lack of work, and the only tasks available are those that only a full-stack developer can complete
  2. The manager wants to “throw you in the deep end, and see if you’d sink or swim” - this is literary what I’ve heard one manager say - keep in mind, if he’s a manager, it doesn’t necessarily mean that he’s any good

Working in an enterprise software vendor company has its own downsides, but at least you don’t have to deal with the above-mentioned issues.