DEV Community: Skill Pathway

The #1 Way To Grow Your Personal Brand As A Developer

Matthew Collison — Thu, 29 Aug 2019 00:20:46 +0000

We've had a lot of messages lately surrounding how to build your personal brand as a developer. And a lot of it is down to Adam Barker, who on Episode 5 of our podcast talked about how one of his best hires was someone he found through Instagram.

This seemed crazy to a lot of people, but the truth is, having a strong personal brand gives you even stronger job prospects - whether you're writing articles on DEV, posting #100DaysOfCode updates on Twitter and Instagram, or live streaming your code on Twitch - it all adds up.

So when we had Benjamin Ha on the podcast, who is a developer and Instagram growth expert (who has worked with the likes of Kylie Jenner and other larger celebrities), we asked a ton of questions surrounding growing a personal brand over there.

A lot of his advice is actually fairly timeless and can be used across platforms - one strategy however stuck out, and that is

Engaging with your followers is the most important thing to do when growing a personal brand

And when we vetted the profiles that were messaging us asking us for advice, most were simply not engaging with their following.

If you engage, you build a real connection. We call this "Warming Up Your Audience" - they're not used to someone on the other end replying, and when they do, they feel cared about, and a lot will come back and continue to engage and become real fans and consumers of your brand.

Engage meaningfully - having a copy and paste response doesn't cut it

Really taking the time to think about your responses is key here - people know when you haven't put the time in, and the more contextual your response is, the better your chances of building a real long term connection with the person you're talking to.

Listen to the full episode for more personal branding strategies from Ben

Ben has tons of timeless personal and business branding advice, and a lot of advice specific to Instagram too. We tried to extract as much of this as possible in this latest episode, so check it out on Spotify or Apple Podcasts if you want to learn more:

A CEO's #1 Tip On How Stand Out As A New Full-Stack Developer in A Competitive Market ⚡

Matthew Collison — Mon, 26 Aug 2019 16:43:23 +0000

Want to listen to the full episode? Check the bottom of the post!

Andrew Brown (CEO of ExamPro.co) joined us recently to talk about a load of topics that would be helpful to anyone looking to get a job in development.

A recurring theme we talked about was how bootcamps (and from what we see, university) tend to set everyone up with a very similar skillset in what are extremely competitive job markets.

That's why a lot of graduates can apply to 200 jobs and hardly get any responses, let alone interviews.

So how do you stand out from the crowd?

Pick a highly demanded skill to add to your technical hamburger 🍔

If a company has to pick between full stack developers, one of the easiest way to decide is to go with the developer with skills that complement their role. Particularly if the skill adds real value to the business.

We like to call this "Supercharging Your Skillset" because it opens up a bunch of new opportunities for your career and even the projects you work on.

In this podcast snippet, Andrew talks about how cloud computing is one of the best choices. Here’s a visualisation of this he posted recently:

And there's many others you can pick from, such as:

UI Design

Most developers think they are terrible at UI Design. The truth is, you just need some simple, actionable principles to follow to level up your designs.

If you can really get a more theoretical understanding of UI Design and what makes a good and bad design, not only will your personal work stand out, but you can bring tons of value to a company you work for by being able to produce better quality prototypes and even giving them a hand in other areas.

User Experience

We all have instincts on what feels right and wrong with our own user experience journey on applications and websites we've used. There are however a set of techniques and research methods you can learn and implement on projects to work towards excellent user experience, and this is something companies really want.

Here's a fantastic post from Emma Wedekind on the "UX Engineer" job title and what it means.

Article No Longer Available

Data Science

As companies collect more and more data, and our computing power and availability with cloud and the tools becoming available become far more advanced and accessible, we've moved into an age where we can use that data to improve so many aspects of our products and businesses. And companies pay a lot of money for people who do this as a specialization.

Also, check this awesome A-Z post out from Helen Anderson, she’s an experienced Data Analyst and Advocate for the industry, and really this is one of the best comprehensive top-level references available

Article No Longer Available

Copywriting

Ever used a great looking website to feel like some of the buttons, sentences, documentation and other pieces of text just didn't make sense, went on too much or just didn't feel right? That's where copywriters come in.

Not only can understanding copywriting principles help your own projects, it improves your resumé, portfolio, cover letter and can be an invaluable asset to any company you work for.

Security (not just the basics, there are specialisations that pay a lot!)

Security comes in all shapes and sizes - from basic security, to penetration testing, to cloud-specific security practices. Learning some more advanced principles can not only get you a much higher paying job (especially when it's your main skill-set) but you'll have a skill set that a lot of CTO and VP of Engineering types will be very impressed to see on your list of skills.

Andrew recently gave a talk on how to implement security in AWS and posted it here on DEV:

34:20

The Fast Track to AWS Security - Feb 26 2019

Andrew Brown 🇨🇦 ・ Mar 30 '19

#aws #security #certification

Unix

Learning more advanced Unix principles and how to actually set up servers locally rather than just through the cloud is something that a lot of developers struggle with - particularly because it's one of those weird things some of us tend to avoid.

Learning it more in-depth and understanding your way around Unix on a more than just basic level is another big way to set yourself apart.

The list goes on but these are some of the things companies hire entire teams of experts for - and if you can pick one or more of these to really stack up those technical skillsets, you massively increase your chances of being considered for the jobs you're applying for.

Check out Andrew on DEV 👇

Andrew has written some epic content on how LinkedIn is a hidden gem full of opportunities, and loads of great AWS-related stuff too. Check his stuff out below.

Andrew Brown 🇨🇦Follow

I make free cloud certification courses

700+ Web Developers Asked Me To Give Them LinkedIn Profile Feedback And These Are My 🖐️ 5 Top Tips.

Andrew Brown 🇨🇦 for ExamPro ・ May 29 '19

#career #webdev #beginners #linkedin

Listen to the podcast here 🎙

If you want, you can listen to the full episode from the embedded player below. Andrew has tons of unique left field tips that can really help you accelerate your career progression.

Do You Suffer With Imposter Syndrome?

Matthew Collison — Fri, 09 Aug 2019 00:26:40 +0000

If you don't have it:

What is something you tell sufferers that they might not already know that allows you to avoid it?

If you do have it:

What are your personal reason(s)? And then let the DEV community attempt to bury your doubts and give you supreme confidence™.

This one should be interesting...

4 Actionable Tips To Immediately Improve Your UI Shadow Design (Design File & Code Included)

Matthew Collison — Wed, 07 Aug 2019 23:55:36 +0000

If you want to browse / duplicate the design or see the CodePen, check the bottom of the post

Our recent Instagram poll & DM’s regarding how developers feel with design highlighted something to us; most developers feel really uncomfortable with design.

With 93% agreeing, we think it would be a good time to help you all out with some beginner design tips, starting with some solid principles to better shadows.

The Purpose of Shadows in UI Design

Shadows are there to improve the overall general feel of things, and add levels of depth and realism to the user’s visual experience.

Because of this, shadows should

Simulate real world light dynamics such as direct and ambient light
Not be so prominent that they are a distraction. They should effectively blend in.

The following design definitely violates those two principles:

On that note, here are the 4 actionable tips for you to implement in any UI shadow design in your projects, and we'll show you how they add up each step of the way

1) Simulate Direct Light With A Hard (non-blurry) Shadow

Direct Light is light from one source shined directly on an object.

For example: When the sun is out, there will be a hard, defined shadow on the other side of every object. This is direct light casting the hard shadow we’re talking about

If we add direct light to our card, it would look like this:

2) Simulate Ambient Light With A Soft (blurry) Shadow

Ambient Light is light that bounces off all the surfaces around us.

For example: When the sun is hidden behind the clouds, you won’t see any direct light shadows, but if you look under trees, you might see a very soft, shaded area underneath them. This is because there is ambient light in the area, and this causes soft shadows.

If we add ambient light to our card, it would look like this:

3) Simulate Surface Shadows By Using A Similar Color To The Component Underneath

This is a bit of a trend at the moment, and it also gives another level of realism to your design - in the real world, things don’t just get “blacker” when a shadow is cast on them, they become a darker shade of the colour they already are.

So in that case, we colour-pick the background and make it a much darker and more saturated shade of the colour. Here’s how it looks:

It's a very subtle change by itself, but this in conjunction with all the other tips stack together to make for a great UI shadow.

4) Use Medium-Soft Inner Shadows On User Generated Images

User-generated images such as profile pictures or any other form of uploaded image will sometimes have colour that is similar to the background it’s on.

Here's a little comparison of how the profile picture looks with and without an inner shadow:

The Final Product

This looks much better than what we started with:

We Coded This Up

Here's the CodePen if you're interested - feel free to steal this and use it in any way you want (it looks much better if you press "Edit With CodePen" because it's not responsive):

Get The Design File

You can click here to be taken straight to Figma - feel free to duplicate it and make it your own. You don't need to attribute us, we can't afford lawyers anyway!

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

We worked for a couple of months on a professional design and 4 hours 20 minutes of video content to bring you our free crash course showing you how to code this portfolio website (which we constantly encourage you to customise to your own style)

If that’s something that would interest you, and you’d like to learn more about HTML, CSS, SCSS, Bootstrap 4, Git, GitHub Pages and a sprinkle of JavaScript and jQuery, you can register today, for free, from this link here.

4 Reasons To Stop Caring About Picking The “Best” Language / Framework To Learn - Read or Watch

Matthew Collison — Tue, 06 Aug 2019 23:43:25 +0000

Watch the video or read the blog post - whatever one you prefer! The content is basically the same on both :)

Here’s a common misconception in the development realm: “I need to pick the best language and framework or it’ll be outdated in months / the jobs will dry up”.

As developers, sometimes we place too much pressure on ourselves to pick the “best” or the “right” framework and language combination to learn. There is no best or right framework. Only best and right for you and the task at hand.

The 2 Reasons We Think This Misconception Exists

Quite simply;

Over-opinionated Senior Developers or “Bandwagon Developers” that want to hate on a particular language and/or framework. Sometimes, these people are become ideological Evangelists (obsessed and think it’s the best ever) for a particular language / framework / methodology. *Please don’t be one of these people. Being open-minded to different tech stacks is a sign of an excellent developer!
We worry that we’ll spend months training in a particular discipline to get a job and a salary that we want and the tech stack we use will become out of date. We simply don't want to waste all of that time to have to retrain.

So the 4 reasons in this post are going to directly address those points, and provide you reasons to stop caring about this trivial issue.

1) Close-minded developers perpetuate that there’s a best framework or language from a place of ego.

And the reason we know it’s ego is because for every one utterance of “PHP is terrible” or ”OOP is an anti-pattern”, you’ll find 100 very well architected, nice to work on applications that scale to the millions built with these very technologies.

This bias against or towards certain tech stacks gets extreme when people start hating on certain technologies in a general sense.

2) Tech stacks don’t just disappear from the job radar in a matter of months

You worry you’ll train in Angular but hear loads of opinionated devs saying how React is going to take the lead and everything will become irrelevant?

There are still jobs for old frontend frameworks going that 99.9% have probably never even HEARD of, let alone a leader like Angular.

The reality is, if you pick a leading framework in a language where it has a stronghold in the language it’s in, you’re going to be fine

3) Even if your tech stack goes out of date, you will adapt to a new one

Adaptability is another sign of an excellent developer - and you can learn it. Heck, you’re already learning whatever you’ve chosen to learn - and once you get there, it will be 10x easier to learn the next framework or language you pick (unless you’re going from JavaScript to Assembler...)

4) It will lead you into narrow minded thinking that hinders your growth as a developer

Maybe those over-opinionated developers have a point. Their narrow view on what the best framework is enables them to feel safe in their job, and they feel good in the knowledge that they’re working with the best technologies out there.

What we’ve came across instead though, is developers who are so unable to have a conversation about anything other than the thing they work in, and create such inhospitable atmospheres when it comes to talking about the “thing they hate”, that they are in a little bubble and don’t tend to learn much beyond what they know.

They might be right, they might be wrong, but this is the mindset that causes people to get stuck on working with a framework that had 10K downloads a day a few years ago, and in the present hasn't received security patches for months and probably gets downloaded < 10 times a day.

Staying in that place will halt your progress and hold you back from the wealth of new technology available in this day and age.

So what are some more practical criteria for picking a language and framework?

Here’s what we go by when trying to advise newbies;

Look at the type of work you want to do (Websites, Mobile Apps, Desktop Applications, Machine Learning, Games) and look for the highest proportion of languages and frameworks used for that discipline. Pick one that you think has the best community.
Something with LTS support is also great - although anything can have LTS - chances are that it’s got it because the community uses it regularly because it’s high quality and has been used in thousands of enterprise projects.
Something with a wealth of resources from tutors that you like available - since you have such an abundance of choice, you could hop between a few languages and browse DEV, YouTube etc looking for tutorial posts and see which has better resources for you.
If you’re looking at this as a career choice, look at the jobs in your area and try find the commonly used languages and frameworks - it might be a good idea to go for those

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

Come on our podcast - or shout out someone you'd love to hear as a guest!

Matthew Collison — Tue, 06 Aug 2019 14:06:04 +0000

I'm Matt, and I'm the Founder / Creator of all the content you see from us - I also run a podcast called The Learning Developers Podcast that we've been running since April.

It's got 2000+ listens from the first 5 episodes, and after an intense 3 months of building our free course, we're finally ready to begin giving community members a voice to share their experiences, get advice, and community leaders a chance to give their own advice at scale to our audience of beginners (although we do have some mid-level and further on listeners too!)

Know Someone You'd Like Us To Talk To?

Don't want to be a guest yourself, but know a voice in the community you'd love to hear on? Please shout them out in the comments, and we'll politely get in touch to see if they'd like to chat to us. We'd really appreciate it as we want to have a good mix of leading voices and genuine people who are in the process (... aren't we all)

You Can Be A Guest Too!

If you're someone who has something to say to newbies, or maybe you're a newbie with some experiences to share that you'd love to talk through on a podcast (we'll even help you with anything you want help with), we really want to talk to you. We have so much fun on these episodes and it's really interesting not only getting to know people, but to give our listeners some sound advice through the conversations that can happen.

These types of conversations always happen off air and could provide value to so many people, so bringing "non-community leaders" can be just as valuable as bringing community leaders on most of the time.

If you're considering becoming a guest, just drop us a DM on here and we'll have a chat about what you want to say and see if it makes sense.

But I've Never Been on a Podcast Before?

It might seem scary to you, but we want to clear up as much of the process to remove any unknowns

I do a lot of research and pre-planning to ensure it's comfortable for you and we have a surplus of topics to talk about.
We have an online call beforehand to get prepared for some of the questions we'll go through, and have a bit of pre-discussion so we know it's something you'd want to talk about
We'll then talk for anywhere between 30 minutes and 1 hour, and we'll record the voice from it and use that
You're welcome to talk about any product you own if it's something that will benefit our community - it's an informal conversation and we're here to bring value
Worried about making errors? You're welcome to listen to the unedited audio beforehand and tell us anything you want us to remove. It's super easy for us to do that
I'll do any intros and outros in post production

Where Can I Listen To The Podcast Now?

If you want to listen to get an idea of the conversational style, or maybe you're just interested in the episodes, you can tune in on these platforms:

Spotify
Apple Music
Overcast
Podcast Republic
Our Own Website

Google Play wouldn't approve european podcasts for some reasons... That's probably changed now so we'll try get there soon as well.

What Is The One Website / App You Would Build If You Had All The Necessary Skills to Do It Yourself?

Matthew Collison — Mon, 05 Aug 2019 18:01:04 +0000

We’re super curious on this one. Maybe you can follow it up with actually learning the skills necessary if it doesn’t seem too impractical?

4 Important Software Design Principles with Quickfire Explanations

Matthew Collison — Fri, 02 Aug 2019 01:06:12 +0000

Understanding design patterns in programming gives us tools that work in many different contexts to improve the overall quality of our code.

We think the explanations you find online are far too complicated, so we've made it our (side) mission to simplify these so they're accessible to everyone. Let's look at 5 today:

YAGNI (You aren't gonna need it)

Real World Example
Imagine a couple - Jack and Jill.

Jack is living in constant fear of the apocalypse, and the resurgence of the black plague.

He's built a Doomsday shelter and he wears a biohazard suit everywhere he goes. He has a "you can never be too safe" type of attitude.

Jill feels frustrated for Jack and his over-compensation for things that are probably never going to happen. Jill understands the need to prepare for the future, but not to the point where you're investing a lot of energy for something which is highly unlikely to provide any valuable return.

In Programming Terms
Ok, that WAS an extreme example. In the business and personal project world, it's a little more subtle, so you need to think of YAGNI in the context of the business or project you're working within.

I.e, if you're working for a well-funded startup that has a 3 year plan and is fairly set on where it's going, it might be good to make precautions a few months ahead of time.

If it's a personal project, you probably don't need all those bells and whistles - it's better to focus on core functionality.

And the reasonings here can be flipped - This is generally what good CTOs and Senior Developers can spot. It really comes down to the needs of the business/project.

It's also good to write your code in a modularized way where you aren't forced to write functionality in pre-requirement. It might be a "Code Smell" if you're having to write precautionary code for something that's coming months down the line.

Dependency Inversion

Real World Example
Imagine there are two banks - "Bank A" and "Bank B"

In order to withdraw money from Bank A, you put your card into an ATM, enter your pin and you're then presented with a terminal/command line logged into a MySQL server. From here, you have to write an update query to deduct money from your bank balance - the machine then gives you your money.

In order to withdraw money from Bank B, you put your card into an ATM, enter your pin, enter the money you want on the pin pad and the machine gives you your money.

The first one violates this principle, the second one doesn't (you might have guessed...)

In Programming Terms
The key thing to understand is that your classes and functions shouldn't know anything about their dependencies.

This leads to something called "Tight Coupling" where if you want to switch out your dependencies for different ones, it becomes a pain and you have to effectively re-write everything that uses it.

Like in the real world example, if Bank A decided to go from MySQL to MongoDB, all of its customers now have to learn how to write Mongo queries.

In the programming world, if your "ShopModel" can only work with a "MySQLConnection", if you suddenly switch to a Mongo-based architecture, the other 40 models that use that connection now need to change to a "MongoConnection"

Instead they should use a "DBConnection" interface (something that defines what all database connections look like) and a container of some sort should give out the current instance of that. This makes changing things down the line a lot easier

DRY (Don't Repeat Yourself)

Real World Example
Imagine there are two Social Media Agencies - Agency A and Agency B

When Agency A hires a new social media manager on the team, the manager learns the social media strategy by looking at the other managers in the team and copying their process.

If the boss at Agency A wants to make a change to the process, he'll sit down with each one and tell them about the changes. Sometimes he forgets to tell one or two managers and that means they're executing on redundant processes.

When Agency B hires a new social media manager on the team, the manager learns by reading a single google document that everyone has access to.

If the boss at Agency B wants to make a change to the process, he'll make a change in the google document and tag everyone in the Slack channel to read the changes. This means he's updated everyone in one shot.

Agency A violates DRY and Agency B adheres to it.

In Programming Terms
If you find yourself writing a code that does the same thing over and over again, you might want to put that functionality into a re-usable class, method or function in your application.

This isn't always the case, and there's actually mixed opinion as to when you should and shouldn't do this, but as a new developer it's really good to begin thinking about where you can make code re-usable. You'll get the nuances down the line, and this will come particularly when you work with other experienced developers.

Single Responsibility Principle

Real World Example
Phil is a graphic designer. His boss wants him to also manage the social media account, babysit his dog when he plays golf, help stock the shelves and milk the cows.

Phil has too much responsibility; you might say he violates the Single Responsibility Principle.

It's his bosses fault though, he should have hired specialists for each of these responsibilities. That's adhering to the Single Responsibility Principle

In Programming Terms
Whether you're a functional or an OOP programmer, you'll be building "pieces of functionality" into your application - whether it's functions, classes or any other symbol of execution.

If you try and describe the responsibilities that your little slice of code has and you come up with more than 1-2 points, you're probably violating SRP.

FYI: This is a line that becomes clearer with experience, but a way to shortcut your learning of this is by looking at major open source repositories and trying to explain what you think the responsibilities of each file/class etc is and you will start to spot the pattern of where people begin to separate things out.

Give us some other programming principles you want simplified, or tell us to do better on these 4 if you still can't get them

We really want to try and help everyone get access to these "mid-level developer principles" - because they don't have to be mid-level if someone can provide the write explanation.

What are some other principles you find hard to understand?
Which ones did we not explain well enough in this post?

Thanks for your feedback and helping us curate content that you'll find useful!

Any other programming design patterns you find hard to understand?

Let us know in the discussion below, this is the first post in our “Programming Principles for Dummies” series and we want to make as many of them as accessible to beginners as possible. Because it enables us to write better code!

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

Single Responsibility Principle for Dummies

Matthew Collison — Wed, 31 Jul 2019 13:55:42 +0000

Traditional explanations

You’re not a Dummy - here’s why. Take a look at this really simple to understand and quick-to-the-point explanation of SRP:

The single responsibility principle is a computer programming principle that states that every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

That’s our British sarcasm showing there - these abstract and wordy explanations really aren’t very helpful to beginners. We know this because we were beginners once, and until these things were explained in context, definitions like this are useless.

That’s because context takes ”abstract understanding” and converts it into ”concrete understanding”

You know you’ve got an abstract understanding about something if you can’t explain it in simple terms, so let’s explain it in real world terms first and then move onto contextual programming examples

Single Responsibility Principle in the Real World

This is Jim (you’ll find out what he’s sad about in a minute)

Jim works as an HR manager for Pear Inc., a company that sells high end laptops.

This is George, his boss (A sassy demon? IDK, the graphic design department is on vacation apparently)

George is frustrated that he needs to go to lots of different employees to get them to do different things, so he gives Jim more responsibilities

Jim’s responsibilities should just be handling things related to an employees contract, such as holiday, induction and exit

On top of this, George wants him to

Manage the cash flow of the business
Maintain the website
Cook meals for everyone at lunch time
Take pictures of the office dog and post them to instagram
Post produce the promotional videos for the company

George is violating the Single Responsibility Principle. Not only does Jim do too many things, he does not specialise in any one.

What George should do is hire a videographer, a developer, a chef, a social media manager and an accountant - that would be adhering to Single Responsibility Principle.

Single Responsibility in the Programming World

Obviously, any business owner that forces that amount of responsibility on their single HR guy doesn’t have many brain cells. But in the programming world, single responsibility isn’t completely obvious - and you’d be forgiven for violating it.

Let’s look at two examples to see how to spot it. Here’s the piece of functionality we need to write

When the user presses the pay button
We need to get the total price to pay from the items in their basket
We then need to take their credit card information and pass it to the payment provider
We then need to redirect the user back to the payment provider’s page

In both examples, everything will happen in a pay method inside of a ShopController a class - except one will violate SRP, one won’t. Also, they’re over-commented so you don’t need to worry about the language syntax. Just understand all the different things it’s doing

class ShopController {

  // This gets run when the presses “pay now”
  public function pay()
  {
    // Get the basket out of the session
    $basket = $_SESSION[‘basket’];

    // Get the user out of the session
    $user = $_SESSION[‘user’];

    // Initialise a variable that will hold the price to pay
    $totalToPay = 0;

    // Add up the price of all the items in the basket
    foreach ($basket[‘items’] as $item) {
      $totalToPay += $item[‘price’]         
    }

    // Get the credit card information the user sent through
    $creditCardInformation = $_POST[‘credit_card_info’];

    // Get the payment gateway key and post the customer, price and card data to stripe
    $paymentGatewayKey = ‘A82hDiha9hhdaonldtumpr2390Jf’;
    $paymentResponse = API::post(‘stripe’, [
      ‘credit_card’ => $creditCardInfo,
      ‘customer’ => $user,
      ‘price’ => $totalToPay
    ]);

    // If the payment worked, take them to the payment gateway to confirm
      if ($paymentResponse[‘success’]) {
      return redirect($paymentResponse[‘redirect_url’]);
    } else {
      // Otherwise, show an error
      throw new Exception(“There was an error when attempting to pay. - ” . $paymentResponse[‘error_message’]);
    }
  }

}

class ShopController {

  // This runs when the user presses “pay now”
  public function pay()
  {
    // Create a basket to handle our session basket data
    $basket = new Basket($_SESSION[‘basket’]);

    // Get the current user
    $user = (new Authenticator)->currentUser();

    // Create a payment request that holds payment data
    $paymentRequest = new PaymentRequest($_POST);

    // Pay and redirect the user (this throws an exception if there are any issues)
    return $basket->payAndRedirect($user);
  }

}

Let’s take score - in the first example, SRP is violated HEAVILY. It is responsible for:

Getting the user from the session
Handling post data
Making requests to the payment gateway
Summing the total cost of the basket up
Ensuring the payment was successful and throwing an exception if not
Redirecting the user to the payment gateway if successful
Storing the payment key (This is a terrible security risk - your payment key is now in your GitHub repository. Great job, George!)

In the second example, responsibility is offloaded to specialist classes which handle only the things they need to handle. In the second example, the controller is only responsible for:

Taking the request data and passing it to the necessary specialists

We could dive deeper into the Basket, Authenticator and PaymentRequest classes and these classes might even use their own specialist classes. This is Single ResponsibIlity Principle at its finest!

How do I know when to separate responsibilities, then?

This is hard to learn without just coding and refining over time, and reading experienced developers code. It’s a feel thing - you’ll get a better understanding over time, but here’s a good shortcut.

Read the code of major open source repositories (ones that have a good amount of comments)

Looking at how experienced developers go about separating things in their code is one of the quickest ways to understand SRP. Once again, because it’s not abstract, it’s concrete. It’s in the context of real world code.

Any other programming design patterns you find hard to understand?

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

4 Practical Reasons You Should Start a Passion Project

Matthew Collison — Mon, 29 Jul 2019 18:58:25 +0000

We’ve spotted an interesting pattern in our DM’s recently. Developers seem to find it really hard to stick to a project long term and not get burnt out, bored or doubtful that it could ever become something.

The pattern isn’t the subject of the message, but their response to this question: “Why did you start the project?”

The most common answer looks something like this.

I’m looking to make some passive income

While being a developer is one of those weird professions that allows us to build anything, its really impractical to go into a project looking to just make some side income. The amount of work involved is generally WAY more than we expect, from marketing, polishing, support and patches.

It’s all too easy to get overwhelmed before we even get a few weeks into projects like these. Overwhelmed by boredom, fear that no one will buy, fear that no one needs it, not wanting to put our name on something we don’t care about.

Enter the Passion Project

While a passion project isn’t going to solve any money troubles, if you’re someone that finds it hard to stick to projects long term, you’re probably more likely to make money this way anyway - in the form of sponsorships, partnership and monetisation opportunities thanks to the fact you can actually stick to it long term.

Here are our 4 practical reasons why you should start a passion project:

1) You don’t need to motivate yourself, it motivates you

If you work on something you’re truly passionate about, it will give you motivation, instead of you needing to constantly push yourself.

With “Side Hustles”’ that don’t really relate to anything we have a genuine fire for, rather than it motivating us, we have to push ourselves daily to keep working on it - and for most of us, this isn’t sustainable.

2) You’ll experience less burnout, as passion gives us energy

This is similar to the last point - but it’s really important to understand how burnout proof a true passion project is.

Think about those times you feel burnt out - other than reverting back to basic human needs, usually there’s something you’re passionate about that you’ll be craving to go do instead of that thing you need to do.

During this period of burnout, maybe you’re the type of person browse the Pokemon subreddit - perhaps you’re browsing pictures of rescue dogs on Facebook - whatever it is, it’s the thing you do when you’re burnt out. By definition it can’t burn you out.

Embed this passion (which some might call procrastination) into a practical development project, and you’re going to find burnout is drastically reduced or practically non-existent.

3) You can start to properly think long-term, as passions are life-long

When our focus is money, fame or something along those lines, we tend to want to get there as quick as humanely possible. Usually because the road we pick to those things is something we’re not passionate about and we want to stop needing to work on it, and we’re desperate to get that fix as soon as possible.

This is conducive to short-term thinking and (not surprisingly) counter-intuitive to your money or fame goals. There are (practically) no “overnight successes” - these types of people generally worked their backsides off for years before a chain reaction of events happened to give them what they needed.

And you need to be in the mindset of years, even decades - not months - if you want to make any real money. And the most practical way to do that is to tie it into a passion project. And who cares how long it takes - you love working on it! What if it fails in the first year? Rebuild it! Pivot the business to a completely different model.

You’re no longer desperate to get it over and done with, so enjoy the process - this is how winners are made.

4) You’ll build something you’re actually proud to put your name on

It’s really cool when you build something you can actually be proud of and want to tell everyone about - when it’s not a money making scheme or something you’re doing for alternative reasons, you’ll feel much more comfortable and proud of the product you’ve created.

It also gives you the opportunity to team up with others who have a similar passion who also buy into your idea - double awesomeness.

What’s your passion project?

Tell us, what do you think your passion project could be - or what is it if you already have one? We’d love to know if you have a similar experience to the one we’re describing.

Skill Pathway is our passion project - it’s the same reason we put out a volume of content without any expectation in return, and in 10 years time we’ll still be loving the process of helping others.

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

4 Ways You Can “Level Up” As A Developer

Matthew Collison — Fri, 26 Jul 2019 13:03:08 +0000

The lines between different “levels” of developer are blurry. Ask any senior developer, development manager or technical director what the difference between beginner, junior, mid-level and senior, and chances are, you’ll receive vastly differing opinions.

Since there is such a wide range of opinions, there’s really no use spending any time on figuring out how to become a “Senior” or “Mid-Level” developer - levels are - for the most part - opinion.

Instead, let’s look at some things you might not have considered, of which if you implement a number of these, will increase your level as a developer.

1) Build a substantial project

React JS calculator? Cool demo, but not substantial. Todo list app? Once again, fun little tool, but not substantial. Most people can follow tutorials we’re talking about something else...

Something with many different views, endpoints and pieces of functionality, that is unique and demonstrates some developer creativity.

What are some examples of what we’d consider a “substantial project”?

Tinder for dogs.
A miniature social network for Pokemon lovers.
An skeleton web backend or frontend framework that others could use - not that you expect to compete necessarily, but to give you an understanding of how to build one!
Build a package in that primary programming language that you work with - one that you’d use in multiple projects.

There are some funky examples there but here’s the point - either build a larger project around something you’re super passionate about or build something that thoroughly pushes the boundaries of what you currently understand. By definition, both of those things are going to “level you up” because you’ll be coming across concepts

2) Contribute to open source

This means build your own open source packages / applications or contribute to existing repositories.

Your own package

If you’re going to build your own packages, just make sure it’s not from a tutorial and something you actually want to put out to the world that others could use.

Document your process

Bonus points if you create a blog post or video series around how / why you built it and your thought process. This not only allows you to think of it from a storytelling perspective and gain new insights, but it’s strong evidence of your abilities AND thousands of others trying to learn what you’re learning get to benefit from listening to how you went about this project.

Someone else’s repository

Chances are, your favourite node, PHP, python, java packages and plugins are on GitHub. There’s an even strong chance that there’s at least a dozen open issues on these packages.

Check the repository contributors guidelines, usually in a .MD file in the root of the code, get a good understanding of it and go away and fix an issue. Better yet, add some functionality to it that would actually be useful.

This serves many purposes

Evidence that you can following coding guidelines (Good for potential employer)
Evidence that you’re part of the open source community and a named contributor on a repository
You’ll learn about forking, pull requests, commits more in-depth
You’ll see what a community maintained package looks like and have a chance to adopt some better programming practices

3) Look at a senior developer’s code (or a programmer you know is more experienced than you)

This is one of the quickest ways to “level up” as a developer. Because (most of the time) you’ll be staring at code that is almost certainly a level above yours.

Attempt to understand it - compare it to your own to find what patterns you can implement to improve yours - take note of all the little technical things they do that you could implement to your own workflow.

This isn’t always possible if you’re not currently working in a company, and if you’re not you can always look for open source projects from your favourite community developers who are highly experienced and read the code and try to understand.

It’s also great if the developer whose code you’re looking at is available to ask questions and happy to answer them - just let them know that you’re trying to better understand what a senior’s code looks like and get their permission to ask a few questions about things you’re trying to understand. A lot of people will be happy to help out.

4) Understand more programming design patterns and principles

Look into SOLID, KISS, YAGNI, MVC, and the vast list of other odd-sounding abbreviated design patterns and principles. There’s a massive Wikipedia page of them right here and another one right here.

Read through the definitions of each one and google for examples of each - examples are super important as if you have context about how a pattern is actually implemented, you’ll be able to understand it better.

Chances are, there’s a bunch you’ve not heard of. Most of the hiring managers here can’t recall all of them, and a quick read through some of them refreshes our memory and allows us to look at how it would improve our coding process.

We’ll probably put out a blog post with some contextual pseudo code examples of this in the future - programming patterns are something that a lot of developers never even try to fully understand, and we understand why: because they make no sense as an explanation. We need examples!!!

What are some other things you can suggest to help others “level up”?

This is a small selection of things we think can help - please share yours with the world so other developers can benefit! No suggestions are invalid - there’s probably thousands of other developers who haven’t thought of the basics when it comes to moving forward in their learning. That’s why we’re all blogging here after all!

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

Want To Be A Freelancer? Here Are Some Actionable Tips & Strategies

Matthew Collison — Tue, 11 Jun 2019 12:47:06 +0000

If you're a developer considering going freelance, the leap you want to take looks really scary. Especially if you've been employed now for any significant amount of time.

And rightfully so - if you've been employed, the consistency of your income, schedule and rate of work make you feel relatively comfortable - at least when you compare that to being a freelancer. If not, you it feels like a mountain ahead of you because it's hard to value your work until someone starts paying for it.

So if you're motivated to make the switch, but want to remove some of the fear and doubt from the decision, we've got some tips that might help you out.

Tip #1 - Get a handle on your finances

This is the #1 most important step before making the transition - because you can make the leap without understanding your finances inside out, because you're taking a massive risk.

We've put together a simple formula to make this as easy as possible to figure out:

How much money do you need to pay the bills and live comfortably each month? (Go into your payment history and calculate this)
What is 2x that amount
How long would it take you to save 6 months worth of 2x living expenses at your current job?

Once you've got that, you've now got a specific amount of money you need to save before you can comfortably quit your job and fully focus on freelancing.

This is because, even taking into account emergencies, you know if no money comes in for the next 6 months, you're going to be able to live comfortably (although we'd recommend budgeting to give yourself a bigger safety net!)

And obviously, you can save less and still go freelance, but the more you save, the less you have to live in fear of money going dry due to any emergencies.

And what if after 6 months, I can't make a sustainable income freelancing, you ask?
Well, that's exactly the point of 2x'ing your living expenses - the career will always be there - your job doesn't just disappear in 6 months.

Tip #2 - Build a strong portfolio of websites / apps to impress potential clients

Your clients need proof that you can get the job done. After all, that's what they're paying for you, right? And if they can see immediate evidence of your abilities, you have a much higher chance of winning bids.

Portfolio Strategy #1 - If you worked on websites in your employment that have enough work to show off, use these (if your contract allows it)

You've already done a bunch of work that demonstrates your experience, and if your employment contract allows this, attribute yourself as doing work on these websites and include screenshots in your online freelancer profiles and portfolios.

Portfolio Strategy #2 - If you haven't or your contract doesn't allow it, build 3-4 substantial website / app experiences that you can complete with 1-2 months of hard work.

Building multiple substantial projects that you can put your name to and take 100% of the credit for is a great way to strengthen your portfolio - and allowing yourself between 1/6th and 1/3rd of your time to build these projects means you can put time and effort into making them high enough quality to properly demonstrate your skillset.

These can form the basis of a fresh portfolio as they will be an honest representation of your experience up until this point.

It also allows you to tailor your projects to maximize the amount of skill you get across to any potential clients.

Portfolio Strategy #3 - Social Media is your new portfolio

You're going to have a website and a GitHub profile as a minimum, but documenting your process, from conception to completion on social media is going to give you such unbelievably portfolio strength, you wouldn't even believe.

Imagine if you're DM'ing local businesses to do work for them, and 5 out of 100 read your message and went to your Instagram profile. If they 10 pictures of you Ski'ing in the Alps, and 20 of your dog Lenny - versus 30 straight posts of the process and work that you do, some timelapses of website builds, and any other content around your work, which type of portfolio do you think will get more responses? Do we need to say any more?

Portfolio Strategy #4 - Do some free work for business you would love to work with & have on your portfolio, just make sure to set boundaries!

Free work is a controversial topic, but if you know how to set boundaries and you truly understand the value of something on your portfolio, you're just building social proof on your terms.

Important Note: Free work is almost always bad when a company comes to you and asks for it. When you go to them and set realistic boundaries - it's a different story - it means you get a stronger portfolio and network on your terms, not theirs.

FYI, boundary settings means, don't go to a business and say you'll re-design their entire website, build them the next big app, go into parnership with them or anything like that - instead, offer to build something small that would be of value to them in return for permission to put a case study of the project on your portfolio.

Tip 3: Make as many bids as you possibly can

You want to become a freelancer for the eventual freedom and comfort it will provide you. Eventual is the keyword here though, it's not going to happen in the first few months, and sometimes even the first couple of years!

So at first, you need to make as many bids for work as you possibly can to maximize your chances of getting work and having a pool options.

Unfortunately, most people fall at this hurdle - they bid for a few jobs, feel down about the fact they didn't get any responses, look at the few highest rated people who are "winning all the bids" and make comparisons and give up.

And who would blame them? It's tough! Let's be real though - you're new to this! It's going to take some time to build a strong presence as a freelancer, and the work you put it in now is going to set you up for the rest of your life. So in the early months, bid like it's you're job as this will absolutely maximize your chances of landing a job.

Let's look at two strategies as to how we can achieve the maximum volume of bids when starting out:

Bidding Strategy #1 - Go to as many freelance bidding websites as possible and place bids on all the projects you could complete.

Pretty simple - go to PeoplePerHour, UpWork, Indeed and even specialist freelance job boards for your particular skillset, and make bids for all the projects you could work on.

It really is just about for applying for as many as possible, as often as possible. And as the strength of your portfolio stands out, you'll eventually get offers and have some real options.

Important Note Sometimes these websites charge for a bids after a certain number of projects. It's worth mentioning as you sometimes it's worth spending the money, but exhausting your free options on certain websites is best to try first. Hopefully with the money you've saved you can afford a few bids as they will be ROI positive once you get work in.

Bidding Strategy #2 - DM at least 500 businesses on Instagram, Twitter, LinkedIn (InMail) and tell them how you can help them improve something about their website, app, etc and offer to work for them

What a huge heading - but that's one strategy that most new freelancers don't even consider, yet is one of the most powerful. You get the picture - if 5 in 100 respond, you're going to get 25 responses, and 2-3 might want to work with you at a reasonable rate based on your portfolio.

It's all about maximizing your reach and getting your name and portfolio in-front of businesses that might want to work with you. The business relationships you make using this type of strategy are also going to be on a more personal level as you helped directly bought them value without them having to ask for it.

Please tell us, what's missing from this guide?

Let us know what other problems you're facing with the move to freelance, or if you're getting started as freelancer. What could we add to this guide as a part 2 that would help you out?

We understand there's a million complexities to freelancing, and one blog post isn't going to give you all the information you need! We were thinking thinking of portfolio examples, proposal templates and other things, but what's most important is giving you what will actually help you, rather than us just guessing.

Check out our podcast if you liked the strategies in this post!

We aim to get guests on that bring you value much like this blog post did, so if it interests you, you can listen to The Learning Developers Podcast on our website, or on Spotify / Apple Podcasts.

We'd love to hear your thoughts and if there's any particular guests you'd like us to have on, please let us know!