Forem: charliedeveloper

Combatting apathy when learning new coding language

charliedeveloper — Fri, 26 Mar 2021 16:07:01 +0000

Feeling like you can’t be bothered or you don’t care about something is the greatest threat to your own personal progression. Here are a few ways to break through the wall of apathy and get enthusiastic about learning again.

If you’ve experienced trying to learn any sort of coding language, you’ll know there’s usually a honeymoon period while you complete your ‘hello world’ project. You’re flying high, but keeping the motivation and the will to learn after this can be tough.

There are a whole host of reasons why you might lose interest and find yourself taking a ‘meh’ attitude towards finishing what you started: maybe you’re too busy, or perhaps you find that the difficulty really ramps up quickly after step 1, or maybe another shiny new coding language/framework has been released (this happens a lot with JavaScript)…

There are a host of reasons that apathy might begin to creep in. But this is the critical moment, and if you can learn to catch yourself at this point and train yourself to continue, you will vastly increase your chances of reaping the long term rewards.

Your will to complete a task will only ever be as strong as your motivation to begin.

When you hit a dip in learning try to make a conscious effort to remember why you started learning this new language in the first place. Battle apathy by picturing the rewards for adding that coding language to your skillset. It could be anything — more money, a new job, a more senior role or even an ability to build that side project you have always wanted to create.

Right now, when finding learning tough I have to remind myself why I am doing it. My current motivation is to be able to explain difficult technical concepts in more simplistic terms when teaching/mentoring others. (Also one of my side web projects is in desperate need of an update!)

Your ability to learn is only as good as the resources you have at your disposal.

Understanding your most productive learning style is key to making progress. Nothing is more disheartening when learning a new coding language than finding you’re not engaging with the material.

Personally, trying to learn from walls of text in textbooks has me shutting my laptop. I favour having someone standing in front of me spelling it out, but sadly this isn’t always an option. Instead, I opt for the next best thing — a video of someone standing in front of me spelling it out!

No other industry has such a large bank of free high quality learning resources — you can find free ‘how to’ videos on nearly every coding language and often from multiple sources.

Don’t like the whiney voice of a presenter on YouTube? No problem! Try someone else’s video.

When I teach students how to code, they all have their own preferred method of learning — some liked using videos, others listening to discussions and podcasts, watching live demos, doing exercises or structured project work. We all found our best results for learning when we discovered our favourite learning style.

Learning a coding language isn’t all sunshine and rainbows.

Let’s be honest: nothing in life can be fun and super engaging 24/7. You can test this against everything.

“But what about cake?” I hear you ask. Well, someone’s got to make it, plus it’s bad for you if you eat it all the time. “How about puppies?” Puppies are pretty close to being awesome 24/7, but you do still have to pick up their poo in the park. I could go on but I think you get the idea.
Far from this being a negative outlook, what’s really important to see here is that all the best things in life take a little work and sacrifice on your part, and that ultimately victory is made all the more sweet by the toughness endured.

In the same way that marathon runners wouldn’t feel the level of satisfaction they do from finishing a race without powering through ‘the wall’, you must be prepared to dig deep and plough through tough learning patches.

Gaining this mental fortitude is not easy, however it gets easier with practice, so if you are feeling apathetic about whether to continue learning, stick at it and you may surprise yourself!

What are the basic courses/topics a software developer should learn to start their career?

charliedeveloper — Thu, 02 Aug 2018 08:57:48 +0000

Note for devs already in the industry: hopefully this article will be helpful to you when you are inevitably asked how to get into programming as a link you can send to the interested person

So when starting to train, it is important to be using the correct resources. Luckily in the software development industry there are loads!

Assuming you want to be a full stack developer (know a bit of everything) the best place to start is Codecademy’s free HTML, CSS and Javascript courses. They are completed online and serve as a great starting point to some of the basics.

From here try and pick up a backend language, I would recommend PHP as that is what I did, but take a look at job postings in your area and see what technologies that they are looking for. This guys PHP video series is great. I totally understand that PHP won’t be for everyone but one of the benefits is that it sits nicely in between loosely typed languages such as Javascript and strictly typed languages such as C. This means it strict enough to enforce some good coding habits but loose enough to be beginner friendly. Also if you are learning on a mac PHP plays very nicely with the UNIX environment (will take a little arm wrestling to get it going on Windows although it’s getting better). Youtube videos, books and blogs are the best free places to learn this, coding bootcamps are the best if you can afford it and have the time to dedicate to it (however be very picky about which one you go to as they are not all the same).

Make sure you understand object oriented programming (OOP).

Get your head into databases by learning SQL - SQLZOO is a great resource I found useful when learning. Sequel Pro is my favourite GUI to visualise the databases you are working with and will make your life easier. If you do learn PHP use PDO to link it to your database.

Also try and learn a version control system such as Git (this video course is a good starting point), get comfortable using the command line and try and do some research on an agile working methodology such as Scrum (potential employer will be impressed).

Go to meetup and find tech meetups to do with coding in your area - this is a good way to find a mentor. Maintain an active Github (For storing/sharing your code), Stack Overflow (for requesting/giving help) and codepen (like a doodle pad but for code) accounts.

Finally research “software developer technical interviews” and have a go at some free online aptitude tests so that you are not surprised by the interview process (it’s not like other industries).

After all that you should be well placed to have a crack at getting your first gig.

Good luck! Remember to enjoy yourself while your learning otherwise you might find yourself giving up, It’s not going to be easy but it’s an awesome job if you can get it.

A note about procrastination:

Start right now! There is no time like the present. As someone who has experienced learning to code from scratch I became very aware of the negative impact of procrastination. I used to look at forums for hours, posting questions about what to do and how to do it. The truth is that time could have been spent learning. It’s the difference between loving software development or loving the idea of being a software developer - you must make a choice about which one you want to be and get cracking!

...That being said, if you are going to procrastinate then you should do it right. Here is my current favourite place to procrastinate on the internet

Getting started with Slim PHP framework by building a very simple MVC/OOP app

charliedeveloper — Fri, 29 Jun 2018 07:45:27 +0000

Aim:
We are going to build a Slim application that creates a farm pen and outputs the noises that the cow & chicken inside the pen make.

Requirements:
- A pen can only contain a cow and a chicken (will help us practice with slim dependancy injection container)
- Must implement an MVC approach (help us understand how models, views and controllers work together)

1. So we are gonna need the slim skeleton application - open your command line and run:

composer create-project slim/slim-skeleton slimFarm

if you don’t have composer installed globally use the composer documentation to get it

2. On your command line navigate (cd) into slimFarm directory that has been made for you

3. We are going to run a php server so we can see that the slim app is present and working

In your command line run: php -S 0.0.0.0:8080 -t ./public/

4. Go to http://0.0.0.0:8080/ to check its working (you should get the slim default page)

5. Open files in your text editor and make a Classes folder inside src

6. Add your namespace to autoloading in composer.json:

"autoload": {
  "psr-4": {
    "Farm\\": "src/classes/"
  }
},

n.b: this is in addition to the already existing autoload-dev
This will mean we can reference our classes using namespaces rather than having loads of require's everywhere.

7. Open a new tab in your command line and run composer dump-autoload in the command line

This regenerates our autoloading and namespaces to contain the changes we just made in step 6.

8. We need our Cow and Chickens to go in the pen! so make our classes inside Classes/Models folder:

namespace Farm\Models;

class ChickenModel
{
    public $speak = 'cluck';
}

namespace Farm\Models;

class CowModel
{
    public $speak = 'moo';
}

9. Create a Pen class inside Classes/Models folder:
namespace Farm\Models;

class PenModel
{
    public $cow;
    public $chicken;

    public function __construct($cow, $chicken)
    {
        $this->cow = $cow;
        $this->chicken = $chicken;
    }

    public function getCowNoise(){
        return $this->cow->speak;
    }

    public function getChickenNoise(){
        return $this->chicken->speak;
    }
}

10. Lets make a factory so that Pen can be created quickly with its dependencies in just one call.

Make a Factories folder (inside the Classes folder)
Make PenModelFactory:

namespace Farm\Factories;

class PenModelFactory
{
    function __invoke()
    {
        $cow = new \Farm\Models\CowModel();
        $chicken = new \Farm\Models\ChickenModel();
        return new \Farm\Models\PenModel($cow, $chicken);
    }
}

Our factory doesn't need a constructor function, the logic is put inside the __invoke magic method because of the way it is called from our Dependency Injection Container (DIC)

11. So now we have made our factory let's put it in our DIC

Think of the DIC as a big associative array that knows how to instantiate objects for you we put in there for use later in our application
Open up src/dependancies.php
There are preexisting things inside the DIC already
Add our factory like this:

$container['penModel'] = new \Farm\Factories\PenModelFactory();

We are saying "inside our container (DIC) add a new key of 'penModel' and when we ask for that 'penModel' run our factory to instantiate and return a ready made pen object with all the dependencies (cow + chicken) taken care of."

12. Let’s look in our routing file to see how we deal with different HTTP Requests to our application.

Like the defaults already written in here we could use quick anonymous functions to save having to create a factory but we instead are gonna "do it right" so we will make a route and use a controller to call our business logic.
Delete the existing $app->get(.....) routes already in the file (we will create our own)
Set up our route:

$app->get('/makeMeAPen', <where our callback will go> );

/makeMeAPen is the URL extension people are expecting to visit to run our code
But we don't have a controller yet so....

13. Let’s make a controller to call our PenFactory and render out a view:

Create a Controllers directory inside src/Classes
Create PenController inside src/Classes/Controllers/

namespace Farm\Controllers;

class PenController
{
    protected $container;

    //this constructor passes the DIC in so we can get our PenFactory out of it later
    function __construct($container)
    {
        $this->container = $container;
    }

    function __invoke($request, $response, $args)
    {
        //create our pen from Penfactory in DIC
        $pen = $this->container->get('penModel');

        //assign args (variables that will be available on rendered view)
        $args['cowNoise'] = $pen->getCowNoise();
        $args['chickenNoise'] = $pen->getChickenNoise();

        //get the default template renderer out of DIC and pass the response and $args to a template file
        return $this->container->get('renderer')->render($response, 'showFarm.phtml', $args);
    }
}

14. Now our controller exists lets add it in as the thing that happens when our route is hit:

$app->get('/makeMeAPen', \Farm\Controllers\PenController::class);

15. Notice in our PenController we are calling a template file that doesn't exist yet so lets create it:

Create showFarm.phtml in /templates folder
Use the values you put into the $args associative array as normal variables:

<!DOCTYPE html>
<html>
    <head>
        <title>slimFarm</title>
        <style>
            h2 {
                font-size: 10rem;
                color: red;
            }
        </style>
    </head>
    <body>
            <h2>Cows go: <?php echo htmlspecialchars($cowNoise); ?>!</h2>
            <h2>Chickens go: <?php echo htmlspecialchars($chickenNoise); ?>!</h2>
    </body>
</html>

16. Navigate to http://0.0.0.0:8080/makeMeAPen and behold the brilliance of your super advanced app!

Which contentious opinions in programming actually matter?

charliedeveloper — Thu, 14 Jun 2018 13:56:41 +0000

I think this question would breed a toxic comment section if it was posted in most places on the internet but I think the dev.to community is up to the challenge for a positive chat about stereotypical programming opinions! So hold my beer, here goes...

There are more stereotypical opinions floating around the development community than you can shake a stick at: tabs vs spaces, Windows vs Mac, nano vs vim etc...

The vast majority don't really matter in the long run, however I am interested in peoples opinions about which stereotypically contentious issues actually make a difference and have as close to a generally accepted 'correct answer' as you are likely to find in programming?

An example (in my current opinion) to mull over: "the less code you write the better" I find this breeds unreadable code that causes knowledge silos and junior devs to spontaneously combust when they see it.

The difference in opinions in the topics raised are potential powder kegs so please try and be respectful if you respond. If in doubt, just imagine you are discussing it with your granny.

Should we do away with junior/middleweight/senior?

charliedeveloper — Fri, 30 Mar 2018 16:25:31 +0000

Sometimes you have to step back from a situation to see it for what it really is, and I think this is particularly true of the way software developers are labelled as junior, middleweight and senior.

For some reason, it’s become an accepted part of the software development industry that if you’re a junior developer looking to get an junior level job and learn the ropes, you may end up being passed over because you haven’t got — in some cases — up to the necessary three years experience!

Sounds silly right? Junior level jobs that need three years experience?

Well that’s because it is.

Seeing this in a job advert does have its uses however. It serves as a pretty clear warning about the kind of company you’re applying to. There seems to be a growing culture in the software industry of businesses playing the job title game: slap ‘junior’ in front of any job description you publish and you can get away with paying a much lower salary.

The sad truth is that these businesses are going to find it harder to hold on to staff as new starters quickly realise their own worth and spot the gap between the value of what they are doing, and what they are getting paid. In the long run, as word gets around, they’re going to find it more and more difficult to recruit great candidates.

There’s a huge difference between a developer looking for his or her first job and someone who has been working in the industry for three years. You might think I’m advocating a new term for another strata of developer to be introduced, but quite the opposite.

From my own experience I have found it easiest to grow professionally when working within a flat structure where developers are simply called developers. There are no senior developers, no middleweight or junior developers… just developers.

Maybe it’s psychological, but I’ve found that this kind of structure goes a long way to encourage opinions and input from newer coders in meetings, whilst also taking the pressure off those who have been doing it longer who may feel (and this is often unnecessarily) that they need to carry the team and almost take on a managerial role. It means that developers are judged solely on what they know and on their actions.

This is not to say that everyone learns at the same pace. I would encourage people to consider that years aren’t a reliable comparator across developers. Due to the volume of complex technical knowledge that makes up the industry it’s not uncommon to have incredibly intelligent long term coders not know very basic stuff about a rudimentary technology. Similarly there are plenty of very new coders who have abilities far beyond what you would expect based on their time in the industry.

I’m certain that coding abilities across a group of devs after three years in the industry could look very different, based on the relative speeds at which they each pick up new material. In that case, the labels of junior, middleweight and senior are pretty unhelpful when it comes to choosing the best candidate for the job.

The answer? Employers should be gleaning information about skill levels from aptitude and developer tests coupled with interviews, rather than relying on number of years experience. As an industry, we should break free of the labels that plague the developer job search. When time is taken to find out what people are capable of rather than how long they’ve been in the workplace, everyone wins!

How to stop being a n00b at wireframing

charliedeveloper — Thu, 15 Mar 2018 14:42:11 +0000

Are your wireframes wack? Are you embarrassed to be seen with them in public? Do they end up useless because you can’t face looking at them? If you want to get better and aren’t sure how to go about it, this article is for you!

First, are you actually attempting to create wireframes at all? Nine times out of ten when starting a project, it feels like it’ll be easier to dive head first into writing code. By the time you realise that you need a wireframe to guide you, it feels too late. But the good news is, it’s never too late for a wireframe. Many a project has been rescued with an overdue wireframe. Think about the benefits of having a plan before attempting anything - in life or in coding. You wouldn’t set out toward a destination you’ve never driven to without first looking at a map or setting up your sat nav. Give yourself the best opportunity to succeed and by creating a wireframe to follow before you start.

Whether you’re a new dev or someone with more experience, you might find the idea of learning to wireframe a bit intimidating. The truth is, there’s no bad time to learn something new in development, so either practice in private or on collaborative projects. Often, others will offer positive assistance when asked for constructive criticism.

So how do you actually get better? Here is a handy to do list:

1. Keep it low fi
All you need is a pen and paper. This is the fastest, easiest way to transfer ideas from your head into a wireframe, and you don’t have to get used to using wireframing software. Plus, if you don’t like the result, you can chuck it and have another go.

2. Strip out unnecessary detail
Be sure to make your wireframe fit for purpose. If you’re just using the wireframe to guide your structure or layout, it doesn’t have to be an all singing, all dancing design document with every element beautifully detailed. It’s perfectly acceptable for a wireframe to be a collection of boxes on a page indicating where content will go.

3. Label as you go
More specifically, label the things that are going to help you do your job and save you time when you come to building. This means identifying HTML tags such as divs. Extra marks for using HTML5 semantic elements such as header, footer, section and main to better structure your document. This will get you thinking about how your HTML structure will look before you have even switched on your laptop.

4. Build the things you wireframe
The process of turning a sketch on the back of a napkin into a glorious website will help you learn more and you’ll develop a deeper understanding of what you need from your wireframes in the future.

5. Document changes as you go
Just as an entrepreneur understands that the best business plans are the ones that are kept up to date and used as a guide all year round, you too will have to keep your wireframe up to date as you go to get the most out of it throughout your build. Changed that <div> into an <aside>? Moved that element to be on a new line? Make sure you record the changes. The good news is you did it in pencil. Now where is that eraser...?

7. Keep hunting for inspiration
Get out there and cruise Codepen, check out design blogs and seek out developer portfolios - these are a great places to find incredibly innovative work that may get you creative juices flowing and give you ideas for your next exciting wireframe layout.

These are just a few quick wins for stepping your wireframe game up and increasing your ability in what is a hugely useful skill to have. Just keep practicing and you’ll have the confidence to wireframe like a champ in no time!