New Job, New Programming Language

Published on Friday 1 November 2019.

For the last ten years, I’ve used PHP as my language of choice but in July I started a job where I’d be learning a new programming language — Ruby.

It’s been a wild ride! I’ve learnt so much and on the way, I’ve cobbled together a few tips on how to make learning a new programming language at a new job as smooth as possible.

The Job Hunt

It’s common not to have all the skills a modern tech job asks for, but if you think the job fits and you’re willing to learn then why not take a shot? Good companies will be able to look beyond what skills you may be lacking and see the enthusiasm you have. This is something that can’t be taught and is always a brilliant asset to have on a team.

The most important thing is to be upfront. Many experienced developers are polyglots so knowing you need to learn their language won’t be offputting. Knowing early on in the process will help tailor the interview and onboarding processes.

In interviews, it’s important to be positive so acknowledge you have things to learn but highlight examples from your experience where you’ve had to adapt to new techniques or pick up new skills. You may already know a second language; maybe you’ve taught yourself something that could benefit the team, like Webpack 😉?

Good Code is Good Code

The principles of software engineering are language agnostic, the difference between languages is in how you apply them. Let’s take The Substitution Principle as an example.

PHP has interfaces that allow you to define how an object is used, but not how it’s implemented. Using Type Hinting and Dependency Injection you can pass instances of an interface to a class which can then use them. This class is not concerned with how its dependent is implemented as long as it conforms to the interface; the dependent class can then be substituted with a different implementation of the interface without having to modify its usage of it.

<?php

interface RacingCar
{
    public function ignition();
}

class Ferrari implements RacingCar
{
    public function ignition()
    {
        // Start the Ferrari.
    }
}

class McLaren implements RacingCar
{
    public function ignition()
    {
        // Start the McLaren.
    }
}

class Driver
{
    public function __construct(RacingCar $car)
    {
        $this->car = $car;
    }

    public function start()
    {
        $this->car->ignition();
        // ...
    }
}

$cars = ['McLaren', 'Ferrari'];
$car = $cars[mt_rand(0, count($cars) - 1)];
$driver = new Driver(new $car);
$driver->start();

In the example above the Driver object does not care what car it receives, it is only concerned that it implements the RacingCar interface.

Ruby doesn’t have interfaces, it uses Duck Typing. Duck Typing states that “if it walks like a duck and it quacks like a duck, then it must be a duck” — if the class being used behaves as expected then it can be assumed to be what we want.

class Ferrari
  def ignition; end
end

class McLaren
  def ignition; end
end

class Tesla
  def move_electrons; end
end

class Driver
  def initialize(car)
    @car = car
  end

  def go
    @car.ignition
  end
end

# Ducks.
ferrari_driver = Driver.new(Ferrari.new)
mclaren_driver = Driver.new(McLaren.new)

ferrari_driver.go
mclaren_driver.go

# Not a Duck.
tesla_driver = Driver.new(Tesla.new)
tesla_driver.go # Erm...

In the Ruby code above an error will be thrown when the Tesla driver tries to start their non-existent ignition.

❤️ Code Reviews ❤️

I love code reviews, they’re so helpful for people learning a new programming language. I’m super lucky to have patient colleagues who will not only highlight where something could be improved but will also take the time to explain why. Deep understanding is important to them so they’re super happy to help me work on that too. Look for, and encourage, an environment where engineers seek to improve themselves and each other.

Be humble when receiving feedback. If you react well to it then the quality and usefulness of subsequent reviews will be even better which will help you learn and be a more useful contributor.

Coming from the other side, give good code reviews and use them as a way to further your knowledge. Ask, or figure out for yourself, why things have been written in the way they have. See a function call you don’t know? Check out the docs.

Use reviews to explore existing codebases and discover how things fit together. Give considered comments, and don’t just comment on things you think could be done differently - highlight code you think is great!

Don’t Neglect Comments

Self-documenting code is important. I should be able to read it and understand what it does. Self-documentation won’t tell me why it does whatever it does in the way it does it. Comments help give code context.

I’m not saying every line needs a note, far from it; if commenting is required too regularly it’s a surefire sign that something is amiss. That said, comments are super useful when making your way through a codebase as a newbie.

Celebrate!

Learning a new language is hard. You will make silly mistakes and you will get things wrong but don’t beat yourself up about it. Getting things wrong is not a bad thing, it’s how people learn! Always take time to look back and see how far you’ve come.