Forem: Jing

AI for everyone

Jing — Tue, 24 Jan 2023 22:30:08 +0000

This is a summary of the course AI For Everyone by Andrew Ng, an entrepreneur, computer scientist, and professor at Stanford University.

It is designed for anyone who's interested in acquiring a basic understanding of Artificial Intelligence (AI) and what it can or cannot do. It also provides an overview of and some advice on how to approach AI projects.

Week 1

What is AI?

AI basically refers to the simulation of human intelligence.

We can further distinguish between

ANI (artificial narrow intelligence) - only does one task, e.g. smart speaker, self-driving car, web search. There has been a lot of advancement in this area in recent years.
AGI (artificial general intelligence) - can do anything humans can do. There has been almost no progress in this area, and there probably won't be for decades, or even centuries.

Machine Learning (ML) is a subset of AI, and deep learning is a subset of ML. Technically, deep learning employs several layers of neural networks, but the two terms are often used interchangeably. Neural networks consist of input, output and a hidden layer in between. That means, you only need to figure out the input and the output and everything in between is handled by itself.

Supervised Learning is the most common form of ML. It maps labelled input to output. Examples include spam filtering where emails are the input and the output is the categorisation of whether or not it is spam.

Data Science (DS) can be viewed as a cross-cutting subset of all these tools. Unlike ML, it is used to drive business insights from data and does not result in a running AI system. However, the terms DS and ML are not used consistently.

How do you acquire and use data for ML?

To do any form of ML, you need a dataset. You can download it from websites, acquire it through partnerships, observe behaviours in an existing dataset, or manually label data.

The two most common mistakes companies make when it comes to data is

Spending too much time collecting data before talking to the AI team
Assuming that more data is always better

Andrew suggests that IT departments provide AI teams with data early on to receive feedback that can guide the development of the IT infrastructure. For example, the AI team might suggest that a factory collects data every minute instead of every 10 minutes, so as to build a preventative maintenance system.

If the data is messy, the output will be too. Common data problems include incorrect labels, missing values, and multiple types of data, e.g. images, audio and text. The latter is also called unstructured data. Data that lives in a spreadsheet is called structured data.

What can ML do?

As a simple rule of thumb, anything you can do with one second of thought can probably now or soon be automated. Examples include speech to text conversion and the visual inspection of defects.

What it cannot do is analyse a market and write a 50-page report or empathise with people.

However, the rules for what ML can or cannot do are not hard and fast. Sometimes engineering teams have to conduct a deep technical due diligence for a few weeks to see if something is feasible or not.

What makes ML easier is a "simple" concept and lots of available data.

Week 2

How do you build AI projects?

ML algorithms can learn input to output or A to B mappings.

The key steps of an ML project are:

Collecting data (e.g. samples of people talking for a smart speaker)
Training the model, which requires iterations until it is good enough
Deploying the model (e.g. putting the model in a smart speaker and shipping it)

After deploying the model, you will collect new data, which can then be used to maintain or update the model.

The key steps of a DS project are:

Collecting data
Analysing the data with iterations to get good insights
Suggesting hypotheses or actions

Once the changes are deployed, new data is re-analysed periodically.

How do you choose an AI project?

Ideally, you select a project at the intersection of what AI can do and what is valuable for the business. This usually involves a cross-functional team of AI experts and domain experts that conduct due diligence.

The technical diligence involves questions such as

Can an AI system meet the desired performance?
How much data is needed? (depends on the problem)
What is the engineering timeline?

The business diligence involves questions such as

How can costs be lowered or revenue increased in the current business?
Does it make sense to launch a new product or business?

Andrew also recommends conducting ethical diligence, as some projects make sense from a business perspective, but are not good for society.

A brainstorming framework that has been effective in the past focuses on

Automating tasks rather than automating jobs
The main drivers of business value
The main pain points of the business

When do you build or buy AI?

While ML projects can be in-house or outsourced, DS projects are commonly done in-house, as it often requires deep day-to-day knowledge of the business.

A general rule of thumb is to buy things that will be industry standard, and to build things that are specialised to you and allow you to gain a defensible advantage. This is because industry standards will eventually catch up and be built anyways.

How do you work with an AI team?

To work with an AI team, you need to

Specify an acceptance criteria (e.g. 95% accuracy)
Provide AI teams a dataset on which to measure the performance

Since the amount of data required depends on the problem, you should ask your technical team how much data is needed. AI teams distinguish between a training set that is used to teach the model, and one or more test sets to check the existing model and its accuracy.

A pitfall to avoid is to expect 100% accuracy, as there are limitations to ML. Problems include insufficient data, mislabeled data, or ambiguous labels. Some of these can be ameliorated, some can't.

Week 3

What makes an AI company?

Not every company that uses AI can be called an AI company. Based on Andrew's definition, AI companies engage in strategic data acquisition. They actively think about how to acquire the data, and might even launch products solely for that purpose. They also invest in a unified data warehouse, apply automation pervasively, and have new roles such as ML engineers and new ways of dividing tasks among team members.

What are some common roles in a large AI team?

AI Product Managers and traditional Software Engineers
ML Engineers that train and review the model
ML Researchers that keep up with literature and sometimes publish
Applied ML Scientists that are between an ML Engineer and Researcher
Data Scientists that usually provides business insights from data
Data Engineers who help organise data and ensure it is saved in an easily accessible, secure and cost-effective way

How can you help your company become good at AI?

Based on his experience leading AI teams, Andrew has developed an AI Transformation Playbook to help companies on this journey.

Andrew suggests the following steps for a company to become good at AI:

Execute pilot projects to gain momentum: start with an initial project that can succeed and show traction within 6–12 months. It doesn't have to be the most valuable and can be built in-house or outsourced.
Build an in-house AI team: create a centralised AI team and have members work across business units, so they can develop interesting AI projects together. They could also develop company-wide platforms that can help multiple business units. The new AI function can be under the CTO, CIO, CDO, or a new CAIO.
Provide broad AI training: not just to engineers, but also managers, division leaders, and executives to learn how to think about AI.
Develop an AI strategy: this is not the first step, as companies who define the strategy before trying out AI tend to end up with very academic strategies. The goal is to leverage AI to create an advantage specific to the sector. Ideally, the strategy is aligned with the "virtuous cycle of AI". This means that better products lead to more users and more data, which is used to improve the model and product, and creates defensibility over time. Andrew also suggests creating a data strategy and taking into account network effects and platform advantages.
Develop internal and external communications: this includes investor relations, government relations, user education, recruitment, and internal communication around the use of AI and potential worries.

What are some common pitfalls to avoid?

Some common pitfalls include:

Expecting AI to solve everything: instead, be realistic about the limitations of technology, data and engineering resources.
Hiring 2–3 ML engineers and rely on them for use cases: instead, pair engineering talent with business talent to work cross-functionally to find feasible and valuable projects.
Expecting the AI project to work the first time: instead, plan for the development process to be an iterative one.
Expecting traditional planning processes to apply without changes: instead, work with an AI team to establish a process.
Thinking you need superstar AI engineers to start: instead, keep building the team, but start with the one you have.

What are some common AI application areas and techniques?

Major application areas include Computer Vision, Natural Language Processing, Robotics and General ML with structured and unstructured data. Since structured data tends to be more specific to a single company, the media tends to cover AI progress in unstructured data (images, audio, text) more. But both are creating tremendous economic value today.

Major AI techniques include Unsupervised Learning, Transfer Learning, Reinforcement Learning, Generative Adversarial Networks (GANs), and Knowledge Graphs.

Week 4

What are some social and ethical implications of AI?

Andrew rightly points out that the topic of AI and Ethics could be a standalone course. Many of these topics can be discussed in great depth. This is just a quick overview of some considerations and concerns:

Hype around AI: when discussing AI, there are usually some people who are overly optimistic and believe in superintelligent AI and others who are too pessimistic and think an AI winter is coming. Truth is that AI cannot do everything but it will transform industries.
Performance imitations and explainability: apart from the limitations mentioned earlier (e.g. lack of data), the explainability of some high-performing AI systems is still work in progress.
Discrimination and biases: AI is biased through the data it receives. Some AI tools apply unhealthy stereotypes and discriminate against groups of people. For example, some hiring tools discriminate against women and some facial recognition software work better for light-skinned than dark-skinned people. There are some technical solutions to this such as using more inclusive data. Some companies have also started introducing auditing processes and focusing on creating more diverse teams to address this.
Adversarial attacks: since AI works differently from humans, almost imperceptible changes to images and other data can confuse the model. This can lead to false results and other undesired effects. Even something as simple as drawing graffiti on a stop sign can lead to it no longer being recognised by AI. There are some defences, but they incur some costs, and we might end up in an arms race to build them.
Adverse uses: some people are using DeepFakes, AI-generated images or videos, and fake comments for malicious purposes, and some governments are using AI for oppressive surveillance.
AI and developing countries: the question is how to ensure that AI creates wealth and uplifts all countries. Some suggestions include contributing to AI communities, focusing on AI to strengthen a country's vertical industries, public-private partnerships to accelerate development, and investment in education. This is because AI is still so immature, which provides plenty of opportunity for new learnings and effective leadership.
AI and jobs: a McKinsey report estimates that 400–800 million jobs will be displaced and 555–890 million created by 2030. The question is how to navigate the impact of AI on jobs. Some suggestions include introducing a conditional basic income that incentivises learning, building a lifelong learning society, and exploring further political solutions. In response to the question of whether or not to switch jobs, Andrew suggests learning and applying AI on top of one's existing expertise to make oneself more uniquely qualified to do valuable work.

And that's it. A summary of Andrew Ng's course AI For Everyone. I hope you learnt a thing or two, and that you will continue learning about AI. I certainly will. I wish you happy learning! ✨

Cover image by Possessed Photography on Unsplash

Dealing with Imposter Syndrome

Jing — Sat, 04 Dec 2021 19:34:01 +0000

When I started my first developer role about a year ago, I was both excited and worried. Excited to code on the job, and worried that they'd fire me when they found out that I didn't actually know how to code.

I had just written my first lines of JavaScript a couple months ago, and the knowledge gaps I had seemed infinite. It felt strange to call myself an Engineer when others who started with me clearly knew so much more than me.

At first, I attributed these self-doubts and feelings of insecurity to my career change. After all, people's professions often form an important part of their identity, and mine had just changed completely. But over time, I realised that a lot of people around me felt the same, regardless of their background.

I also realised that there are moments when I feel more like an imposter and moments when I feel less like one. And while I still have self-doubts every now and then, there are some practices that have helped me to feel more confident in my skills over time. So I thought I'd share these with you in the hope that they'll help you too.

Recording achievements

I know I have mentioned this one in another post before, but it really helped me a lot. It was actually my manager who suggested I record my achievements when I first started. It was mainly intended to help me pass probation. But it eventually turned into a reassuring habit that also helped me later down the road.

Looking at my personal achievement sheet from time to time made me realise two things: 1) We forget so much more than we realise, and 2) however little you think you know now, you most likely know more now than you did yesterday.

You think you'll remember all the amazing things you've done and learnt along the way. But every time I look at my sheet, I stumble upon something I completely forgot about. And it's hard to feel a sense of achievement over something that you don't remember.

Looking back, I at one point also realised that there are so many things on that list that seem small to me now, but probably wouldn't have to my past self. Thinking about it this way, the sheet highlights all the progress I've made since the very beginning. And that feels very reassuring. To know that however little I think I know, I know more than I did yesterday.

Pairing up and asking lots of questions

Pairing up with others is not only fun, but also helps to put things into perspective. Initially, I had a tendency to think that everyone around me knew and understood everything. But while pairing up and asking lots of questions, I slowly realised that that wasn't the case. Instead, every member of our team seems to have their own area of expertise that simply overlaps with that of others. But no person knows it all.

I still remember pairing up with our lead engineer for the first time. Every time I asked a question, I fully expected him to launch into a lengthy explanation of the details of what I wanted to know. So every time he responded with "I don't know" I felt a strange sense of reassurance. Even after over 10 years of experience in the field, there were things he didn't know. That doesn't mean that he wouldn't be able to find out, but it's a gentle reminder not to put yourself under too much pressure to absorb everything.

Treating yourself like your best friend

This is a tip I've come across at one point in my life that I've never forgotten since. When we experience self-doubts, we often engage in negative self-talk. Instead of lifting ourselves up, we tend to enter a downward spiral where we beat ourselves up over the mistakes we have made. We also tend to compare ourselves, which only makes us feel worse. But imagine it wasn't you who was struggling. Imagine it was your best friend. Would you say the same things to them as you would say to yourself?

If one of your closest friends came to you and said "I can't seem to solve this problem, I'm so bad at coding". Would you discourage them from continuing? Would you dig out whatever doubts they might have shared with you? Would you encourage them to compare themselves to others? I don't think you would... or at least I wouldn't. I'd try my best to remind them of all the progress they've already made and encourage them to take a break before continuing. That's what I'd do.

For some reason, a lot of us seem to find it easier to be compassionate toward others than ourselves. While I'm not sure why that is, thinking about your closest friends and the way you'd treat them in the same situation might help you to avoid negative self-talk and treat yourself better.

Finding a go-to person

I was lucky enough to be assigned a mentor at work that did not only help me become a better developer, but also became a good friend over time. But even if you weren't formally assigned a go-to person, there are still many ways to find one.

You don't necessarily have to go up to a person and ask them to be your mentor. What you can do is pay attention to the things other people are good at that you'd like to learn and ask to pair up with them on certain tasks. That way, you can also get a sense of how patient they are and how comfortable they are with you asking lots of questions before making them your go-to person. Or at least that's what I did. That way, I actually found myself another person I'd consider a mentor even though we don't have a formal mentoring relationship.

A go-to person is someone I often turn to for feedback or for questions that I might not feel comfortable asking in a bigger group.

And if you can't find a person at work or want to find one outside of work, why not try one of the many free mentoring platforms out there.

Focusing on learning

Or more specifically, focus on learning things that you're curious about.

This is something I sometimes neglect by accident. But I've noticed that I tend to feel more positive about development and my coding skills more generally when I take the time to explore technologies and frameworks that I'm curious about. They don't necessarily have to have anything to do with work. That's where my problem lies, because I sometimes get so caught up in learning whatever is directly relevant to my work that I spend less time exploring topics that are not.

But it's important that you do, especially at the beginning of your career, because that's how you find out what you really enjoy and what you'd like to focus on. I can't say that I've been particularly good at it, but I want to make it a priority for 2022. I know, I know it's never too early to start... but mentally, I still find the end of the year a good time to wrap things up and start with somewhat of a fresh mind in the new year.

Of course it's even better when what you're curious about and want to learn and what you're working on overlap, but that's not always the case. And that's ok.

Helping others

And finally, helping others. Whether it's helping new joiners at work or people outside of work - it's a way for you to apply your skills. Even if you think you're not ready for it, there is something you know that another person doesn't. And when you try to help others, you'll find out what it is.

Of course there will be things that you don't know from time to time, but sharing is not only caring but also a form of learning. Being a buddy at work, for example, does not only remind me of the progress I've made since joining, but also makes me realise where the gaps are that I need to fill. It helps me narrow down what I need to focus on in terms of learning.

Concluding words

And that's it. Those are some of the practices that, in hindsight, have helped me to feel less like an imposter. That doesn't mean that I don't experience self-doubts from time to time, but it has definitely helped me to feel more confident in my skills over time.

Apart from the above and a general willingness to learn and improve, I think that a supportive team is also very important. I consider myself lucky in that regard, but I just wanted to mention this, as I've been in less supportive environments before and have definitely felt the difference. So it's not always you.

And at this point, I should probably also mention that if you are a more experienced engineer and want to help new starters and career changers feel more comfortable around you, there are two things you can do today: 1) avoid using acronyms or explain them properly the first time you do, 2) say "I don't know... but I'll find out" more often.

That's it (for real this time). Thanks for reading and have a nice day! 😊

Cover image by Timothy Dykes on Unsplash

Tips for starting your first developer job

Jing — Tue, 07 Sep 2021 16:58:10 +0000

Last week a new developer started in our team. Even though it's not her first role in engineering, it made me think about my own experience as a new joiner. I had just learnt how to code a couple months before, and it was not only my first job as a developer, but also my first role in tech.

Looking back, there are some things I would have done exactly the way I did, and others that I would have done differently. So here are some tips for those of you who are about to or have just started your first developer job.

1. Take notes

This is a piece of advice I came across elsewhere on the Internet that proved to be invaluable. From the moment I walked through the doors of the company, I started to take notes and organise them carefully. I paid particular attention to the engineering workflow, architecture, acronyms, terminal commands, keyboard shortcuts, and anything else that might come in handy. This helped me a lot in getting up to speed, without having to ask my colleagues about things that they had already told me once.

Being completely new to life as a developer, I literally wrote down the steps I would have to take to get from a ticket to a merged pull request. These included things like creating a branch, starting a simulator, committing my changes, pushing my changes to the remote branch, creating a pull request, and so on. I then used these as a general guide until they became a habit, and noted down the mistakes I made along the way.

My notes have become a personal documentation tailored to my work that I still refer to now. Even though it might slow you down a bit in the beginning, it really saves you a lot of time later on, as you don't have to ask again and wait for a response. It also makes it easier for you to help other people as you might have exactly the information they need but lost in one of the many messages you exchange at work. And in some cases, you're even able to convert your notes to proper team documentation.

📝 Develop a note taking system

Since you will probably not stay at the same company forever, I would suggest using a personal account for note-taking. I have separated company-related information from learning notes, organised by different technologies (e.g. React, TypeScript, GraphQL, and so on). That way, I can easily delete any company-specific information that I might be asked to delete later, but keep my personal knowledge library.

When it comes to tools, I personally use Notion, but I might migrate my notes to GitHub at some point. GitHub can be used offline, while Notion only works online. It's also free to share your notes with as many people as you want and have them contribute to a set of notes together. Notion requires you to have a team plan for full collaboration. There's a free trial, but once this has been used up, you have to get a subscription.

2. Scrutinise the codebase

When you're just starting out, there will probably be someone who shows you the codebase and gives you a higher-level overview of how things work. Or at least that's what happened in my case. I then had some time to go over it myself, but since our codebase consisted of a monorepo, basically one huge repository shared between teams, I just skimmed through our feature. I thought I'd get to know the codebase better over time anyways.

And I did. But in hindsight, there are a lot of questions that popped up along the way, or mistakes that I made that could have been avoided by taking a proper look at the codebase. So if I were to start again, I would spend more time doing that. For example, by going over the whole flow of the product in the simulator or on the web, and really trying to understand how the data travels through the codebase and ends up where it's supposed to be.

Be critical and keep asking yourself why things are done in a particular way. This does not only help you get used to reviewing other people's code, but it also helps your team identify potential issues with the code. I was quite shy to do that in the beginning, as I often just assumed that it was somehow my problem that I couldn't understand parts of the code. But whenever I did ask, it usually turned out that that part of the code was either deprecated, superfluous or not very readable in the first place.

It also helps to take a proper look at the package.json, which usually lists all dependencies and scripts that you can use. It helps to understand which other teams interact with your feature and vice versa, and also familiarises you with some scripts that you can use in your daily work. Some of my teammates weren't aware of some of these useful scripts either, so this is also another way to be helpful.

3. Ask thoughtful questions

When I first started, I had a lot of questions. And lucky for me, I was assigned a buddy and mentor that I could ask these questions. And in most cases, she knew the answer. This was great, but I later realised some things that I could have done better.

Before I started, I asked her what tech stack the team worked with, so I could do some preparation. This question I would simply have asked earlier, as I only thought of it like two weeks before I joined when I was busy organising my move to Berlin. So I caught up on some stuff later, but it helps to read at least an intro to the technologies you've never worked with before.

When it comes to code-related questions, I initially often focused on what I wanted to do rather than what I had already done. But this would often lead to suggestions I had already tried. So now, I always tell people straight away 1) what I'm trying to do, 2) what is not working, 3) what I have already tried, and then ask my question. This saves time and makes it easier for people to help you.

When it comes to team practices or company-specific information, I could have asked more often where my buddy got the information from. Because I later realised that some of the questions I asked were already well-documented. As a new starter, I just didn't know where to find them.

4. Avoid context switching

I think one of my biggest misconceptions about life as a developer was the assumption that developers spend most of their day coding. And in some places that might be exactly what they do. But in bigger companies, you will most likely spend a significant amount of time in meetings, waiting for your build to complete, waiting for code reviews, waiting for another team to get back to you, waiting for the designer to comment, and so on.

This can lead to a lot of disruptive context switching. Things like the review process, the design handoff process and the amount of meetings you have will probably also depend on your team. But there are also some things you can do to try to avoid it.

These include:

asking to be marked optional in non-essential meetings
declining optional meetings, especially if they're recorded
blocking out some focus time in your calendar
scheduling your learning sessions at the start or end of the day
collecting stakeholder questions and asking them at once
only joining messaging channels you really need
if you use Slack, turn on Do Not Disturb mode

While I realise that these suggestions might not work for everyone, they helped me reduce the amount of context switching I do. In the beginning I attended every meeting I was invited to, regardless of whether or not my input was necessary. I thought this would help me get a better overview over everything, but instead it often ended up draining me. So I hope you can be smarter than me and start prioritising sooner 🤓

5. Join or create study groups

This one I have to mention with a word of caution, because if you're anything like me, you might be tempted to join 50 study groups at the same time. Study groups really helped me stay consistent and finish bigger projects like passing the AWS Certified Developer - Associate exam. But they can also be distracting if you don't organise your time accordingly. That's why I am now only part of exactly one study group, and why I schedule my learning sessions either at the start or the end of the day.

We get a Udemy Business subscription at work. Most companies have some form of learning budget, so you'll probably also have access to some learning platform. In the beginning, I started studying some topics by myself, but I rarely finished them. All the Udemy courses I have completed so far were part of some study group. It really helps because you feel a sense of responsibility and have people who hold you accountable.

That's why I recently started my own study group. I created a learning path that I shared with others on a similar level as me and a Notion space that lists the to-dos for the week. That's also where we collect possible questions for discussion that might come up during our self-studies. We agreed on the course we want to do, and have weekly check-ins. It's not been long since we started this, but it's going well so far. So if I were to start again, I would try to form a study group from the get-go.

It's also helpful to be able to apply your knowledge straight away, so you might want to discuss your learning plan with your manager or mentor at work. That way, you can align it with the tickets you're working on. For example, shortly after starting to learn TypeScript, I converted some of our JavaScript files to TypeScript. I could then use the issues I encountered as a basis for further learning.

6. Record your achievements

This is probably one of the most important tips here. It's a suggestion that my manager made when I first started. And I'm very glad that I took it more seriously than he had initially meant. Because it did not only make it easier for my manager to make a case for me passing probation, but it also helped me feel less like a fraud. I will probably write a separate article on imposter syndrome at some point, but either way, make sure to record your achievements.

There is just so much you do in your daily life that you simply forget. And at one point you might be standing there, looking back and wonder what you actually did. That has happened to me a lot since I first started working as a developer about a year ago. There are moments where you might doubt your skills and feel like you're not learning fast enough. Or moments where it seems like everyone else knows so much more than you. And that's when your achievement sheet can remind you of all the things you've done and learnt, and all the progress you've made since walking through the door.

In my case, I just opened a Google doc that I called "my achievements" and noted down every ticket I worked on and what I learnt in a particular month. While quantity is not as important as quality, I also recorded the number of the ticket I was working on, as it felt like a personal milestone to me. In the first six months, I would also write a short summary every two months. I organised my achievements in reverse chronological order with the most recent work on top.

Recording my achievements is actually something I wish I had done much sooner in my career. It only takes a couple minutes a day to write some bullet points of what you did and what you learnt. But you can use it well beyond your current job. It does not only serve as a means to motivate and encourage yourself, but also helps to refine your CV, to talk about the things you've done at interviews, and to make a case for yourself more generally. And it helps your manager too. Because a good manager wants you to succeed, but is often preoccupied with their own work and career.

So it's not only a means of advocating for yourself, but also makes it easier for others to do so. Depending on what you've done, you can also share some achievements publicly to inspire others at some point, as I have seen some people do before.

And that's it.

Those are the tips I have for people who are about to or have just started their first developer job. I hope that they help at least some of you 😊 And finally, good luck and much success to those of you just starting out. You can do it 💪🏼

Cover image by David Travis on Unsplash

Create your own Dockerfiles, Images and Containers

Jing — Mon, 30 Aug 2021 20:49:21 +0000

In the first part of this series, I described what Docker is and how it works.

To recap, Docker is a service that helps us package and isolate our code in containers. Containers are standardised, independent units of software and running instances of images. They contain our code and all required dependencies. Images are read-only templates for containers that are built by the Docker Engine and based on Dockerfiles. Dockerfiles are text files that you write that include all the commands needed to build a specific image in the order in which they should be executed.

Now that we've covered the most fundamental Docker concepts, let's take a look at how you can create your own Dockerfiles, images and containers, assuming you've already installed Docker on your machine.

How to create a Dockerfile

To create your own Dockerfile, simply start by creating a file named Dockerfile 😄 It doesn't have an extension and shouldn't include one.
If you want to create a base image, one that isn't based on an existing image, start by writing

FROM scratch

However, most images are based on a base image, also called a parent image for that particular image. Since the exact process for a base image will depend on what you want to package, we will focus on creating an image with a parent image. If your code is written in Node.js, for example, you'd start by writing

FROM node

Then you specify the requirements needed for your image, using further commands. A full list of commands and their meaning can be found here.

You usually end a Dockerfile with a command that will run when a container is started based on the image.

If you'd like to run app.js in the container, for example, you'd write

CMD ["node", "app.js"]

If you specify several CMD, only the last one will be executed. If you specify none, the CMD of the parent image will be executed.

An example Dockerfile for a simple node application might look like this:

FROM node 

WORKDIR /app 

COPY ./someFolder /app 

RUN npm install 

EXPOSE 80 

CMD ["node", "app.js"]

FROM specifies the base image or parent image, in this case node
WORKDIR tells Docker that all subsequent commands should be executed inside a particular folder, in this case the app folder, including COPY and RUN
COPY copies the content of one folder into a folder in the image file system, in this case it will copy the contents of someFolder into the app folder. If the app folder doesn't exist yet, it will be created in the image file system. What you specify depends on which files on your local machine you want to go into the image
RUN specifies the command that will be run when the image is created, in this case npm install to install all the dependencies of your node application
EXPOSE, as you might have guessed it, exposes a specific port in the Docker container, in this case port 80, which can be accessed by a local machine
CMD makes sure node server.js will be run when a container is started

How to create Images and Containers

Once we have written a Dockerfile, we can run docker build in the terminal, along with the path or url where the Dockerfile is located. This command tells the Docker Engine to build a custom image based on the Dockerfile. The image is built with a specific id that you can use to run a container based on the image.

Creating Images

To build an image, use

docker build <file or url of Dockerfile>

Images are read-only. That means that you need to rerun the docker build command and rebuild your image if you've made any changes to your Dockerfile.

The order of the commands in a Dockerfile matter, because images are layer-based. When you build an image, every command in the Dockerfile creates a new image layer and the result of each command is cached, so it's not rerun if nothing changes. If you modify the port in the Dockerfile above, for example, by writing EXPOSE 50 instead of 80 everything before that command will not be rerun.

You can also tag an image by using

docker build -t name:tag

You might want to use tags to version your images, though they can be used for all kinds of purposes.

Creating Containers

To run a container based on an image, use

docker run <image id or name>

You can use --name to name your containers.

docker run --name <your chosen container name> <image id or name>

If you don't, Docker will assign a random name for you.

You can also run Docker containers on a specific port. If we want to use port 3000 on our local machine to access port 80 in the Docker container that we specified in the Dockerfile above, for example, we could write

docker run -p 3000:80 <image id or name>

where p stands for publish.

How to manage Images and Containers

After creating some images and containers, you might want to manage or delete them. Here are some common commands that will help you do that.

Managing Images

To list all locally stored images, you can use

docker image ls

To rename an existing image, you can use

docker tag <old name> <new name>

To inspect an image use

docker image inspect <image id or name>

To remove an image, you can use

docker rmi <image id or name>

Please note that images belonging to a container, whether running or not, cannot be removed. To remove those images, you need to remove the corresponding containers first.

To remove all unused images, you can run

docker image prune

If you want to remove all images, including tagged ones, use the -a flag with this command.

Managing Containers

To see all running containers, you can use

docker ps

where ps stands for processes. If you want to see both running and stopped containers, you can run

docker ps -a

where a stands for all.

To stop a container, you can use

docker stop <container id or name>

If you're in a hurry, you can also use docker kill, which will stop the container immediately instead of giving it some time to shut down gracefully.

If nothing has changed, you can restart your container by running

docker start <container id or name>

A difference between docker run and docker start is that the former runs the container in attached mode by default. This means that the container is started in the foreground and the output is printed in the terminal, which you cannot use at the same time. docker start on the other hand, starts the container in detached mode, so it's running in the background and you can still use your terminal.

To attach a running container that you started in detached mode, simply run

docker attach <container id or name>

If you want to restart a container in attached mode, simply run

docker start -a <container id or name>

Similarly, you can also use the -d flag for detached with the docker run command.

To run a container in interactive mode (if your programme requires user input for example), use

docker run -it <container id or name>

where -i stands for interactive, and -t basically for the terminal.

To remove containers that are not running, you can use

docker rm <container id or name>

You can remove several containers at the same time by listing several container ids or names while leaving a space between them like so

docker rm <container id or name> <container id or name>

To remove containers automatically after they are stopped, use the --rm flag.

Sharing Images on Docker Hub

To share your images on Docker Hub, use docker login to log in to the default Docker Hub repository or to a specific registry, and docker push <image id or name> to upload your image to the Docker Hub. To use an image from the Docker Hub, simply run docker pull <image id or name>.

When you use docker run <image id or name> and you don't have a local image with that name, Docker will automatically pull the latest version from Docker Hub. If you do, Docker will not check that it's the latest version, so to ensure that it's the most recent version, you need to pull it from Docker Hub first.

Final Words

And that's it. Those are all the commands you need to create, manage and delete some images and containers, and to share your images on Docker Hub. I realise that it's quite a lot and I might create a summarising cheatsheet at some point, but this is it for now.

If you're new to Docker, I'd suggest creating a simple sample application in a language you're familiar with and playing around with the Docker commands above.

Happy dockering! 🐳

Cover image by Phoebe Dill on Unsplash

Docker - What it is and how it works

Jing — Fri, 27 Aug 2021 07:19:11 +0000

When I first started working as a developer, Docker seemed to be everywhere. I kept hearing docker this docker that, and often had to run some docker commands to get things working. But I didn't actually know what exactly Docker was, so I spent some time learning about it, and here is what I learnt.

What it is

Docker is a service that helps us package and isolate our code in containers, so you can run it on different machines. It's like putting everything in your house into a huge shipping container with all that is needed to use your stuff. It doesn't matter where the container is, you will be able to use the things inside the container the same way you would in your house.

This is important in software development, because you develop applications in a specific environment, and what works on your machine might not work on another. Your code might run perfectly on your computer, but stop working on your friend's. If, for example, your code is written in Node.js, the reason might be as simple as them having a different version of Node installed that is incompatible with the one you used.

How it works

Docker helps us create and manage containers. Containers are standardised, independent units of software that we can run. Modern operating systems have built-in support for containers, and technically, we don't need Docker to create containers, but it's a tool that makes it much easier for us to do so.

Containers are running instances of images. Images are like read-only templates for containers. They contain our code and all required tools, and we can create multiple containers based on the same image.

Images are based on Dockerfiles. Dockerfiles are text files that specify the requirements for a specific image and include the commands a user can run in the terminal to build it. Images can be stored and shared in repositories on Docker Hub, which is a hosted registry and like a GitHub for Docker images.

How Containers differ from Virtual Machines

Docker containers are sometimes compared to virtual machines, as they also provide an isolated environment for your code. But unlike containers, virtual machines contain their own operating system. It's like another computer running on your computer that takes up space on your hard drive and can therefore be quite slow. While the environment configurations for virtual machines can be shared and reproduced, this can sometimes be quite troublesome.

Containers run on top of the Docker Engine. The Docker Engine is a technology that takes care of the containerisation of your applications. It is a client-server application, which consists of three components:

A client, the Docker CLI, which allows us to interact with Docker using the command line.
A REST API that sends our commands from the client to a server, which can be a local or remote machine.
A server, a local or remote machine that has the Docker daemon running. The Docker daemon, also called dockerd, listens for API requests and manages Docker objects such as images and containers.

While Docker containers can contain an operating system layer on top of the Docker Engine, it's usually much more lightweight than that of a virtual machine. This makes containers faster than virtual machines.

However, Docker containers are stateless by default. If you don't connect them to a persistent storage, your session data will be lost with the removal of the container. Virtual machines can be both stateful or stateless.

The diagram below illustrates the difference between a virtual machines and a Docker containers. A Hypervisor is a software that creates and runs virtual machines. The Bins / Libs layer provides the software libraries and services needed for the app to run.

Summary

Docker is a service that helps us package and isolate our code in containers. Containers are standardised, independent units of software and running instances of images. Images are based on Dockerfiles and created by the Docker daemon, which is part of the Docker Engine. Images are stored and shared on Docker Hub.

Unlike virtual machines, Docker containers do not contain a separate operating system and are stateless by default.

Cover image by Phoebe Dill on Unsplash

How I passed the AWS Certified Developer exam

Jing — Tue, 24 Aug 2021 07:07:17 +0000

This week I took and passed the AWS Certified Developer – Associate exam 🥳 Since then, some people have asked me which resources I used, so I thought I'd spend some time writing about my experience and approach, including the resources I used.

Getting Started

If you're completely new to the cloud, I suggest you start with this article. It's a general introduction to cloud computing that tells you what it actually is and something about its history, benefits and drawbacks.

After that, it's good to spend some time on the AWS Fundamentals course to go over some core concepts and mental models that AWS is built on, which I wish I had done before I had dived into the material below.

The Course

The AWS Certified Developer Associate course by Stephane Maarek

The exam was part of an AWS study group at work, and this is the course that it was structured around. The course is divided into around 30 sections based on different AWS services and each section consists of a theoretical part and a hands on session. There is also a practice exam at the end, along with some tips to pass the exam.

Initially, I followed the pace of the study group by going over around 3h of video material a week, but I and some others eventually fell behind. We still had bi-weekly meetings, where we would discuss the topics we had learnt, but I ended up going over a lot of the material at once in several days instead of gradually week by week.

If you have the time, I would strongly encourage you to spread it out more, and set smaller goals like one section or one service a week. That way you will have more time to explore a particular service and the concepts associated with it in detail before moving onto the next one.

If you have less time or are more of a text-based learner, I would suggest going over the lecture slides instead of the videos. The instructor follows the slides quite closely and most of the added context comes from the hands on sessions rather than the theoretical lessons.

Practice Exams

After completing the course above, I went over two sets of full practice exams, and an official Pearson VUE practice exam.

Practice Exams by Stephane Maarek & Abhishek Singh
Practice Exams by Neal Davis & Digital Cloud
Pearson VUE practice exam - you can request a free voucher here

Both sets of practice exams are quite good and include detailed explanations as to why an answer is correct and why the others are wrong. There also some repeating questions, but most are unique. Comparing them, I'd say that the first set by Stephane and Abhishek was slightly more difficult. But I could be biased as I did those first and was already familiar with the format when I did the second set. Both sets provided a great preparation for the actual exam.

It took me around 30-45 minutes to do one practice exam, and I spent a considerable amount of time going over my mistakes afterwards. On Udemy, you can filter your responses to show only the incorrect ones. The explanations also reference the official AWS documentation, so you can continue reading if you need more details.

I found the practice exams quite difficult and failed most of them on my first attempt. This got me really worried about failing the actual exam, so don't feel discouraged if that happens to you too. I just retook the practice exams I failed until I scored above 80% in all of them. While going over my mistakes, I didn't only pay attention to the correct answer, but also as to why the others were wrong. This helped me eliminate some answers more easily going forward, which also benefitted me in the actual exam.

The Pearson VUE practice exam only included around 20 questions instead of 65, and no explanations at the end. But it familiarised me with the setup that I had in the actual exam, which included the ability to flag questions to come back to at the end.

Cheat Sheets

I used these AWS cheat sheets to review important concepts and details. I only came across them later, after I had already done some practice exams, but I would suggest going over them before you do the practice exams.

AWS Certified Developer Cheat Sheets by Neal Davis & Digital Cloud
AWS Cheat Sheets by Tutorials Dojo

I primarily used the first set of cheat sheets, but also looked at some of the latter ones. Digital Cloud has several sets of cheat sheets tailored to different exams, so their set is really tailored towards the AWS Certified Developer exam. They also include exam tips that I've found very helpful, as they highlight some details you need to know.

AWS Website

And finally, the official AWS website. I used the documentation, FAQs sites and whitepapers as a reference and went over the AWS Certified Developer exam guide and sample questions here.

A couple of hours before the exam I also went over this article by Danny Steenman on some tactical tips to increase your chances of passing the exam. Mainly because I was nervous, but I found it quite helpful.

Final Words

And that's it. These are all the resources I've used to prepare for the exam. Overall, it took me around a month of study, a couple hours every evening, to prepare for the exam. But as mentioned, I would highly suggest spreading it out over a longer period.

Hope that's helpful. Good luck and much success to those of you who are preparing for the exam right now. You can do it 💪🏼

Cover image by Dallas Reedy on Unsplash

My favourite free resources for learning how to code

Jing — Fri, 13 Aug 2021 18:45:20 +0000

Since switching careers from politics to software engineering, some people have asked me how I learnt to code. At some point I noticed that I just kept repeating myself, so I've decided to write it all down.

Getting started

Before diving into it at the time, I did some quick research on what you actually need to learn to become a developer. For the web, the answer was pretty much HTML, CSS and JavaScript. So that is what I started with.

Khan Academy - I went over the AP/College Computer Science Principles section to learn more about the foundations of computer science and programming.
Codecademy - I took the HTML, CSS and JavaScript courses. Their explanations are quite clear and they generally try to visualise where they can.
SoloLearn - A learning platform with bitesized lessons, little quizzes and challenges for all kinds of languages. You can collect points and level up as you complete more lessons. There is a web and app version. I used the app on the go to revise my knowledge of HTML, CSS and JavaScript.
freeCodeCamp - I did the Responsive Web Design certification, and most of the JavaScript Algorithms and Data Structures section. Don't feel intimidated if you're just starting out. It took me some time to solve my very first algorithmic challenge. If you get stuck, the best thing to do is to take a break, and then write down what you want to do and break it into little steps on a piece of paper. Talking it through with another person is also really helpful. FreeCodeCamp also has an active YouTube channel and a Discord server that you can join.
The Odin Project - This is my favourite. I started with The Odin Project after having spent some time on Codecademy and freeCodeCamp, but it eventually became my main resource. It's a open source curriculum for learning fullstack development with JavaScript or Ruby on the backend. The Odin Project requires you to set up your own environment, which can feel daunting at first, but it's a great step towards coding your first project :) They also have an active Discord server where you can find study buddies and share your progress with fellow learners.

Whilst these were the main resources I've used to get started and returned to throughout, there are many more websites that I found very helpful.

For CSS

Flexbox Froggy - A game for learning Flexbox
Grid Garden - A game for learning CSS Grid
CSS Tricks - A great resource for more in-depth information and helpful tricks
MDN Dev Docs - CSS - Also a great reference, but not as visual as CSS Tricks
Frontend Mentor - Website for frontend challenges. They provide you with the requirements and images if needed and you try to code the project as best as you can. Once you submit your solution, the community can provide you with feedback. You can also comment on other people's solutions. I used one of the free challenges to practice my CSS skills.

For JavaScript

Wes Bos JavaScript 30 - Thirty fun little projects to learn JavaScript
JavaScript.info - JavaScript tutorials that I used for some topics
Traversy Media - YouTube channel with lots of great intros
Dev Ed - Another great YouTube channel
Web Dev Simplified - Aaand another one (on YouTube)
Code with Ania Kubów - Aaand another one (seriously YouTube is amazing for learning). Ania has lots of tutorials for coding cool games like Mario with JavaScript.
Eloquent JavaScript - A well-written book about JavaScript with helpful exercises
You don't know JS - A book series to learn more about the weird parts of JavaScript
Node School - Tutorials for learning Node.js (JavaScript on the backend). If you get stuck, you can consult this unofficial guide for explanations.
MDN Dev Docs - JavaScript Guide - For reference

For Coding Challenges

CodeWars - Fun way to practice your JavaScript skills. You start at level 8kyu and work your way up to 1kyu as you solve coding challenges and gain points. You can filter challenges by languages and difficulty level. Make sure not to rush through it, but take time to understand why your solution works (or doesn't work). After you've solved a challenge, you can view other people's solutions. Comparing solutions is very helpful in understanding what works and what doesn't. Be careful not to confuse the highest voted or shortest solution with the best one. Pairing on challenges and discussing solutions can be very helpful here. Or finding a mentor.

There are many more code challenge websites out there like CoderByte, HackerRank, LeetCode, and Exercism, but I started with CodeWars and somehow it just stuck.

For Computer Science

Harvard's CS50 Intro to Computer Science - I started with this one, but never finished it. The lecturer is great though, and there are several specialisation courses you can take afterwards if you're more of a university-style learner.
The Missing Semester of Your CS Education - I did the first six sections or so with a particular focus on the command line (don't worry if this doesn't tell you anything right now, but if you want to find out more, you can read about it here) . This is also where I learnt what I currently know about vim (including how to exit it :D). Vim is a code editor that you can navigate using your keyboard only. Some people love it, some hate it, because it's not necessarily very intuitive for everyone... that's why there are jokes about not being able to exit vim :P
BashCrawl - A game to learn how to use the command line. Not technically a Computer Science course, but can be used in conjunction with the previous course to practice your command line skills. You need to know how to clone a repository for this one, which you can learn as part of The Odin Project.

For entire curricula, you can take a look at Open Source Society University (mostly online courses) or Teach Yourself Computer Science (mostly books). I haven't gone through them yet, but I think they serve as a nice reference.

Free Bootcamps

Technically, not all of the below are resources I've used, but since some people have asked me about being self-taught vs. going to a bootcamp, I thought I'd list some free bootcamps I know. While App Academy for example is technically a paid bootcamp, their curriculum is freely available online and can give you a sense of whether you'd like to attend a bootcamp or not.

Full Stack Open - A fullstack course by the University of Helsinki. The content is the same as the one taught at their Department of Computer Science. If you follow the timeline and complete the course, including exercises, you can earn a certificate. Finnish participants are also guaranteed interviews with the programme's corporate partners.
App Academy Open - Uses the same resources as the paid content, but with less support (without live lectures, graded assessments, etc.)
Rithm School - Free courses by a paid bootcamp.
Front-End Foxes - For women, by women.
Class Central - Free, online and open to all. Structured around freeCodeCamp's web development certification.
Codebar - Not technically a bootcamp, but the community holds regular workshops and also has an active Slack channel and Discord server.
Founders & Coders - Non-profit in London. You need to do quite some pre-work to apply, but I've only heard good things about it so far. I went to some of their open sessions to do some of the pre-work with others. During the pandemic, their cohort was online. I think they're back to in-person cohorts but I thought I'd list them anyways.
Open Classrooms - Distance learning platform registered with the Board of Education in Paris. They offer a lot of free courses in English and French as well as paid training programmes in web development.

For more resources

Hackr.io - You can find both paid and free resources for all kinds of languages on here, including JavaScript.
Bento - Learning paths for different topics, including JavaScript.

That's it. I hope this list is helpful for at least some of you. If you're completely new to coding, I would suggest focusing on one resource first and consulting others as you try to learn more. Jumping between websites can actually be quite distracting, or at least it was for me.

Also remember that you don't need to know it all. As someone who's now working as a developer, I can tell you that there's a lot I learnt during my self-studies that I don't actively use at work, and a lot that I only learnt on the job. So the best strategy in my eyes is still to get the fundamentals right, build some projects, and then apply for jobs, so you can start learning by doing as soon as possible. That way, you'll find out sooner what you want to focus on, as there is simply too much for one person to know it all.

So happy learning! You can do it! 💪🏼

Cover image by Aaron Burden on Unsplash

From politics to programming: how I changed careers during the pandemic

Jing — Fri, 01 Jan 2021 15:35:44 +0000

I knew 2020 would be different. Because unlike other years, this one started with a resignation. After almost three years working in politics and policy in London and Beijing, I decided to call it quits; say goodbye to a career I had been working towards for years. It wasn't an easy decision to make, to leave a job without another one lined up, or even a proper plan. But I felt relieved when I finally handed in that resignation. My goal? To transition to a career in tech.

Moving into tech had been in the back of my mind since living in Beijing three years ago and being surrounded by a vibrant tech community. There is just so much you can do, even without any coding skills. But back then, everything was still new and it felt too early to make a decision. Now that I had already worked at different organisations in politics before, in the public, private and non-profit sector, it was time to try something new.

So there I was a few weeks later: bags packed, unemployed and full of hope. I moved from London back home, to a small town in southern Germany. I wanted to take a break before embarking on my career changing venture. But what came next probably sounds all too familiar: more and more countries in Europe started closing their borders. People were urged to stay at home. Hospitals were overwhelmed. A pandemic was raging and taking lives around the world.

How I felt? Probably like much of the rest of the world: anxious, worried, and stuck. I mean, what do you do when you just quit your job and are confronted with news of a pandemic, a declining economy and mass unemployment? Well... first, you take a moment to acknowledge that you probably didn't choose the best time to make a 180 degree switch in your career. Second, you realise that timing is not a decisive factor. Third, you pull yourself together.

Where there's a will, there's a way

So here is what I did. The very first step I took was simply to get my day-night-rhythm back in order. Wake up at a reasonable hour, and go to bed around midnight. It sounds odd to even mention it, but I think a lot of people underestimate the importance of essentials like sleep and food. I also dressed properly, took regular walks and stopped watching the news. Because by then, corona was pretty much all you would hear. And you didn't need to be a fortune teller to know that things weren't going to change anytime soon.

Before quitting my job, I had done my fair share of research. I looked at possible roles, career paths, schooling options, and attended tech and startup-focused events. I did so to get a sense of the industry and the way it was heading. After researching the field and assessing my skills and interests, I narrowed it down to UX/UI design and software development. I wanted to work in teams to solve human-centred problems, acquire skills applicable to different domains, and write at least some code.

But I didn't know which one it was going to be. At the time, I had only touched HTML and CSS and just started to learn JavaScript. Throughout this period, I also read other people's career changing stories, which helped me to stay motivated. While reading those stories, I realised that there was also a lot of switching between roles in tech. And some unicorns did both code and design. So I decided to try both. After all, you won't know until you try.

The Art of Do-It-Yourself

What I did next is what lots of people do when they don't really know what to do: google my way through the internet. And googling I did. I started with freeCodeCamp and The Odin Project, but kept switching forth and back between different sources. From Codeacademy to Codewars to SoloLearn, Skillshare, Treehouse, the Interaction Design Foundation, Youtube and whatever other resource I could find. It's insane how much information is out there. But it can also be quite overwhelming.

After some time, I had read and seen so much that I thought I kinda knew what I was doing. I had experimented with Figma, Photoshop, Illustrator, learned about Git and Github, set up a development environment, solved some JavaScript problems. I was kinda heading in the right direction. Except that I felt stuck at the basics. I tried to create a curriculum for myself, but couldn't quite stick to it. So in the end, I narrowed down my main focus to three resources: The Odin Project, the Interaction Design Foundation and Skillshare.

While going through these resources, I somehow got hooked. I was building projects as part of The Odin Project when I found myself thinking more about coding problems than design questions. By then, I was no longer following a set schedule – I coded when I felt like it and took a break when I felt like I needed it. I also tried creative classes beyond product design. But I still finished one coding project after another until I had a handful to show on Github. They were simple, but presentable. And a way for me to measure my progress.

It's a People World

At the same time, I started talking to more and more people in tech. Since I didn't really know anyone in software development or UX/UI design before my career change, I started looking for online communities to join early on. I became part of whatever tech-related group I could find on Slack and Discord, reached out to people, and attended online events. I also found myself a pair programming buddy through the Odin community and joined a study group through a supportive and helpful fellow learner (thanks Ciaran!).

Those communities are also how I found out about my current job and other opportunities. A recruiter posted the ad in a Slack channel I was part of and I reached out to see if they would also consider self-taught people. There was an initial chat with this recruiter and other people and before I knew it, I was in the midst of several application processes. During this time I also received a scholarship for a new online coding bootcamp, the Coyotiv School of Engineering. Even though I managed to secure job offers before class started, I loved being part of the community.

Since joining Klarna as a software engineer, some people have reached out to me to ask about my career change. And a common question that I get is "how did you know you were ready to apply?". But truth is, I never really felt ready, and I still don't. If I had waited until I felt ready, I might never have applied. I just kept going until I felt like I had enough evidence to prove that I am serious about this career switch, and then I just talked to people. Because after all, we live in a people's world, and your attitude and willingness to learn matters. It's not all about your technical skills, but also about you as a potential colleague.

A New Beginning

And that's my story: how I went from political and security analyst to software engineer in 2020.

Now I can officially call myself a software engineer. But that's just the beginning. I still have a lot to learn and am grateful to Klarna for giving me the opportunity to grow as part of an amazing team. I hope that this story helps at least some people the way all those career changing stories out there helped me. Thanks for stopping by and happy new year! ✨

Cover image by Jukan Tateisi on Unsplash

Free mentoring platforms for developers and designers

Jing — Tue, 30 Jun 2020 17:39:44 +0000

As a career changer, I have spent a lot of time googling my way through coding resources. And if you are part of the DEV community, you probably have too. There are loads of articles on how to learn to code, and sites like Hackr and Bento make it easy to find resources based on topics and tools.

But what about mentoring? If there is one thing I wish I had had at the start of my developer journey, it would have been a mentor. But finding one is actually not an easy task, especially if you come from a different field. That's why I have compiled a list of free mentorship platforms for developers and designers – to make it easier for others to find one when they need it.

List of Free Mentoring Platforms

Merit - a coaching platform with automatic scheduling. You can filter coaches based on fields of expertise or themed playlists (e.g. launching side projects, dealing with imposter syndrome). When you first log in they offer you a list of recommendations based on your needs. It's quite US and Canada-focused, but hopefully that will change over time.
Coding Coach - a platform that provides you with the contact details of coaches. You can filter based on name, country, language, and technology. It also has an active slack channel.
ADPList - a mentoring platform for designers. You can filter mentors based on country, languages and expertise (e.g. AR/VR Design, UX Design, Design Writing). According to their website, there are over 1000 registered mentors from around the world.
Designed - a platform primarily for designers that provides you with the contact details of mentors. You can filter based on topics or tools, location, time zone, language, and gender. It also has an active slack channel.
Re-create - a mentoring platform for creatives. You can filter mentors based on role and country. You have to submit a mentor request through the website. It asks you for the length of the session (3, 6, 9, or 12 months), your reason for wanting to work with a particular mentor, and an example of your work. Due to high demand, you can only submit one request per day.
Office Hours - a mentoring website for designers. There are only a handful of mentors so far, and they all seem to be based in the US. But you can book a meeting directly via Calendly, or reach them on Twitter or LinkedIn.
Mentoring.Design - a mentoring platform for designers in Berlin. They are not currently accepting new mentees, but it might be worth keeping an eye on if you're interested.
Mentor Cruise - general mentoring platform that includes both paid and free mentorship. You can browse mentors based on name, tags, skills, main focus, services, price and availability.
She Says - a mentorship scheme for women in the UK creative industry.
Ambitious Ladies in Tech - a mentoring programme for women working at tech startups in London with less than 3 years of experience. The minimum commitment is 12 months.
Built By Girls - a mentorship programme for female and non-binary students between the age of 15-22. They are US-based, but also offer remote mentoring.

Other helpful websites

Exercism - a platform for coding challenges that offers reviews by mentors.
Frontend Mentor - a website with frontend challenges. Once you submit your solution, you can receive feedback from other developers in the community. It also has an active slack channel.
Elpha - a social and professional network for women in tech. It's a great platform for sharing and exchanging experiences, and CEOs and CTOs regularly offer office hours for any questions you might have.

I hope that was helpful. Feel free to message me if there are any great mentorship platforms or programmes that I've missed.

And if you are looking for other online mentoring platforms (tech and non-tech, free and paid), take a look at this list from Growth Mentor.

Cover image by Christin Hume on Unsplash