Forem: Learning Locker

Pink is Professional

Learning Locker — Thu, 04 May 2023 15:11:08 +0000

From early education right through to secondary school, we were educated in an all-female environment. In retrospect, we can clearly see we had the advantage of growing up in an environment filled with strong, successful women. The idea that we couldn’t become whatever we wanted simply didn’t cross our minds.

It wasn’t until we started working in the STEM industry, that we realised just how male dominated the sector is. As developers, senior colleagues - most of whom happened to be male - have commented on us having a pink theme during a live demonstration.

We were then labelled as the “pink team” and whilst we love this name, it dawned on us that no one else with a blue or grey or any other colour background was being categorised.

So, who decided pink wasn’t professional?
Well, it certainly wasn’t us! Our names are Caitlin and Jemma. We met in university where we studied Computer Science at Ulster Magee. We’ve always had similar interests and career aspirations and this led to us working together in Learning Pool as software developers, making us the ultimate dream team. We didn't go into this industry to be “women in STEM”, we went into this industry to be like every other developer. We were drawn to this line of work as it is a challenging and dynamic space that provides excellent career opportunities.

We expected to work hard. What we didn’t expect was to have to work even harder to be seen as equals to our male counterparts. On the bright side, Learning Pool has given us an excellent platform to speak about the challenges women in our industry face.

Barriers to women in STEM
It’s important to first acknowledge the female experience in the workplace. A 2011 study found that women in STEM experience an informal culture which positions them as outsiders, they have a major lack of role models and experience outright sexism (De Wekde and Laursen, 2011). Many participants in this research describe the workplace as an ‘Old Boy’s Club’.

The difficulty is the majority of the workforce in STEM (in other words, men) are completely unaware of these barriers because they simply do not experience them..

Drawing on our personal experience, we strongly recognise a lack of female role models. Going back to 2009, there were 124,075 women working in the UK tech industry. By 2019, this figure had increased to 180,600. Whilst this sounds encouraging, it’s important to remember how quickly the tech industry is growing; in 10 years the percentage increase of women in tech has only improved by a measly 0.7%.

Progress continues to be painfully slow. During the academic year 2020/21, 3340 undergraduates studied computing in Northern Ireland, with only 22.55% of students being female. It is clear that there is much more work to do.

Does the issue start in schools?
So, why are careers in STEM not attracting enough women? Is it lack of awareness and education? Biassed stereotypes? Or is it just pure and simple misogyny? We can’t answer this question in one blog post - but perhaps the problem starts in school.

Professor Looney, Executive Dean at the faculty of Engineering and Computing at Dublin City University argues that many women are simply not aware of the opportunities and career progression within this industry.

Professor Looney goes on to suggest that more needs to be done at school level to educate our young women about the vast array of career opportunities within the STEM sector. It is imperative that young women understand that studying computer science does not mean that they must become software developers.

Girls Who Code
Reshma Saujani,the founder of Girls Who Code, found that 74% of girls resonate with careers that impact and change the world -for example, a doctor or an activist.

Reshma highlights that part of the problem with computer science is that women don’t have an accurate image of what it means to work in the tech industry.

She found that many women’s image of a computer programmer was a solitary male, surrounded by energy drinks who works long hours and is no longer in tune with society. Many women want a more meaningful, sociable and impactful career. They are failing to see how STEM can help shape society and change the world for the better.

With this research in mind, it sparked our initiative to set up an outreach program that involves going out to schools and educating young female students on the benefits of various career paths within the IT sector.

Over the past few months, we have successfully set up this outreach programme and visited St Genevieve’s High School in Belfast. It was clear that the students lacked awareness of all the different career paths available in the IT industry and how they can get there. The majority of students underestimated their potential to get into the university course, never mind make it in the industry.

It needs to be made clear to our young female students that everyone has the opportunity to have a successful career in IT and there are many ways to achieve this. The students were concerned they needed high A Level grades and to go to university before being considered for a job.

There was a total lack of awareness about the different routes into the sector. For example, apprenticeships, tech, coding bootcamps, online courses etc. Perhaps if getting into STEM was made more accessible, we would attract more young women into our field.

Get involved
We strongly believe that if we can get more women into STEM then we can change the way women are treated in the workplace. Having more female role models and colleagues will result in a more inclusive working environment.

More people need to be a part of this movement and join the fight. It’s imperative that if we want to see more women thrive in IT, we ALL need to do better - industry wide.

While encouraging women is a great first step, companies globally need to change their attitude towards women in the workplace, so women feel comfortable to work within the sector.

We couldn’t find an answer to the question who decided pink wasn’t professional? But perhaps we can start to change attitudes towards women and femininity in the workplace by simply saying this. Pink is more than professional– it is powerful.

More Information
Learning Pool creates learning experiences that deliver extraordinary outcomes for workplaces investing in the performance and skills of their people. Supporting thousands of businesses investing in learning experiences for their global learners, Learning Pool’s innovative AI learning platforms and skills solutions, combine integrated technology and adaptive content to produce actionable insight on every learner’s performance.

STEM, an acronym for Science, Technology, Engineering, and Mathematics, refers to a group of academic fields that focus on problem-solving and innovation in the areas of science and technology.

How we learned to paginate data

Learning Locker — Wed, 04 May 2022 14:58:40 +0000

As part of our REST APIs, we commonly have to implement pagination, allowing our users to retrieve large quantities of records via a series of short requests that avoid blocking our servers. There are two common solutions to pagination, the simpler skip/limit technique, and the more complex cursor technique. Here we’ll delve into the differences between the two techniques, the issues involved and why we have come to prefer cursors.

Skip/Limit Technique

Imagine you have the following JSON records in your database table.

{ user: 2, score: 7 }
{ user: 3, score: 9 }
{ user: 4, score: 3 }
{ user: 5, score: 4 }

Now imagine you want to retrieve the records using pagination with 2 records per page. To get the first page, you would skip 0 records, and limit by 2 records providing you with the following records.

{ user: 2, score: 7 }
{ user: 3, score: 9 }

To get the second page, you would skip 2 records, and again limit by 2 records leaving you with the following records.

{ user: 4, score: 3 }
{ user: 5, score: 4 }

As you can see, despite the contrived record limit, this technique is pretty simple. However, this technique has a problem when you sort records as shown in the next section.

Skip/Limit Problem

You start to run into problems with the skip/limit technique when you introduce custom sorting options. Imagine you have the following JSON records in your database table.

{ user: 2, score: 7 }
{ user: 3, score: 9 }
{ user: 4, score: 3 }
{ user: 5, score: 4 }

Now imagine you want to receive the records in descending order of score and paginate to 2 records per page, perhaps to create some kind of leaderboard. To get the first page, you would sort the scores in descending order, skip 0 records, and the limit by 2 records. This would return the following two records from the full record list above.

{ user: 3, score: 9 }
{ user: 2, score: 7 }

Now imagine that you want to get the second page. To get the second page, following the skip/limit technique, you would sort the scores in descending order, skip 2 records, and limit by the 2 records. However, imagine that since retrieving the first page, a new record has been added (highlighted below), so now you have the following JSON records in your database table.

{ user: 2, score: 7 }
{ user: 3, score: 9 }
{ user: 4, score: 3 }
{ user: 5, score: 4 }
{ user: 1, score: 7 }

Following the skip/limit technique, when you retrieve the second page, you will actually receive one of the items from the first page again (highlighted below).

{ user: 2, score: 7 }
{ user: 5, score: 4 }

This duplication of records is the problem with the skip/limit technique and it’s exacerbated when you have more records, but even worse when records can be updated/mutated. If you can avoid updating records then you can use the cursor technique (explained in the next section) to avoid this problem. In our case we often work with xAPI statements which we avoid updating because they’re supposed to be immutable.

Cursor Technique

So starting from the same place as the last two sections, imagine again that you have the following JSON records in your database table.

{ user: 2, score: 7 }
{ user: 3, score: 9 }
{ user: 4, score: 3 }
{ user: 5, score: 4 }

As with the previous section, you want to receive the records in descending order of score and paginate to 2 records per page. To get the first page, we must again sort the scores in descending order, but in order for the “cursor” technique to work, we must also sort them in ascending order by some unique identifier. In this case our unique identifier is the “user” property, however, it’s more typically the “id” or “_id” property. Following this sort, we limit by 2 records as usual and this would return the following two records from the full record list above.

{ user: 3, score: 9 }
{ user: 2, score: 7 }

Imagine once again, that a new record has been inserted (highlighted below) before you retrieve the second page. So now you have the following JSON records in your database table.

{ user: 2, score: 7 }
{ user: 3, score: 9 }
{ user: 4, score: 3 }
{ user: 5, score: 4 }
{ user: 1, score: 7 }

To get the second page we can use our last record from the first page as the “cursor”. For the cursor to work, we must again sort the records by score in descending order and sort them in ascending order by our unique identifier. This puts the records in the following order. Note that the new record is highlighted and the records from the first page are also highlighted.

{ user: 3, score: 9 }
{ user: 1, score: 7 }
{ user: 2, score: 7 }
{ user: 5, score: 4 }
{ user: 4, score: 3 }

Following the sort, we use the cursor to filter records with a score less than or equal to 7 and a user property greater than to 2. Then as usual we limit by 2 records to get the following records in the second page.

{ user: 5, score: 4 }
{ user: 4, score: 3 }

Notice that whilst this means the new record is not retrieved, it avoids duplicating the record from the first page in the second page which causes confusion, especially when dealing with a larger volume of records.

Join us

We’re often hiring - you can find all our job listings on our website.

A day in the life of a Learning Locker Developer

Learning Locker — Mon, 25 Apr 2022 08:59:53 +0000

Today is Monday and my alarm goes off at 8:50 a.m. (I have been working from home since I joined the Learning Locker team, hence this luxury). I usually brew a coffee ☕ as I log onto my MacBook.

Communications are very effective, so there aren’t hundreds of email threads to catch up on. Instead, it always takes only a few minutes to read through a couple of Jira email notifications and possibly a few Slack messages.

After checking communications, I start planning my priorities for the day and week ahead. I put things in the calendar and set Slack reminders for myself. I also take a quick look at existing tickets on our two Jira boards.

It’s 10:15 a.m. and our daily scrum starts. One of the team members will be leading according to a weekly rota. Each of us share what we worked on yesterday, plan for today and any blockers or concerns.

Normally the daily scrum takes around 10 minutes (max 15 mins). After everyone has had their turn, now is the time to raise anything else that’s more generic. We also might ask some of the team to stay afterwards to talk about an issue, or to schedule a meeting such as a paired programming session.

As a close-knit team, we prefer the meeting to be light so we can spend time doing rather than saying. We all very much value this little bit of “face time” from time-to-time and since we can’t be in the office in-person, we start and end each meeting with a friendly wave 👋. There are also efforts to keep meetings worthwhile, so we also have things like “no-meeting Wednesdays”

As we operate in two-week sprints, fortnightly on Mondays, we have a sprint planning session scheduled after our daily scrum. This is another short 30-minute meeting. It’s led by the Scrum Master and Product Owner, where we select the tickets that we will aim to complete in the current sprint.

Team members can pick up any ticket in the “To Do” column of our Jira board as the tickets have all been discussed and estimated beforehand. This means there is already a sense of priority and familiarity from our well-managed backlog.

In the rare case that it needs further scoping, I can ask questions in the ticket comments by tagging the Product Owner or necessary team members. This ticket is now my focus until moved to Code Review - then I can pick up another ticket.

On a Monday at 4pm we have our company-wide weekly all-hands meeting which lasts half an hour. It’s great to listen to updates from other departments (with a coffee of course). It’s also a chance to hear what's up and coming in Learning Pool and how our project and product team fits into the exciting big picture for the company's award-winning suite of products.

Afterwards I am free to go back to my dev ticket, check Slack or whatever else I have planned for my day. If I need a break from the dev ticket during the day I usually read some tech blogs or resolve a “Dependabot” security warning (if there is one). I also can visit our internal “fun” channel on Slack for some jokes, videos, memes or general banter with the rest of my team.

The day ends at 5:30 p.m. If I’m in the middle of the flow when writing code or a code review, I normally aim to finish those before I wrap up. We are trusted to get our work done and have flexible working times. For example, if I have a plumber visiting I can make up the time the following day or prior to the visit - this flexibility and trust from remote working is something which helps me to perform at my best and feel valued.

There are other ways we could have spent our days as a Learning Locker Developer. Learning Pool offers charity days for employees, where we can go out and contribute our time to a charity as a paid working day.

Every Friday is a Dev Day which we use solely for our self-development and training. This is luxurious! We are free to stay offline to focus on an area of our choice. There is a half-hour Game Time session 🎮 in the early afternoon on Fridays too, to help us look forward to the weekend and have some downtime with the rest of the Learning Locker team!

Join us

We’re often hiring - you can find all our job listings on our website.

Game time

Learning Locker — Fri, 08 Apr 2022 13:31:46 +0000

Weekly on a Friday afternoon, we spend half an hour virtually playing online games as a team. Sounds great, right? When we started working remotely back in the spring of 2020, we realised that we missed the sociality that you get from office-based working. So, this was the perfect excuse to enjoy some social time while working in a distributed, virtual team.

It's nice to have a bit of face time where we're all relaxed, and it means we get to know each other better and improve working relationships. This is especially important when new people join. Also, it's just a bit of fun - work hard, play hard!

Half an hour is enough time to allow us to blow off steam but doesn’t take too much time out of the working day. Obviously, if we have any customer related meetings or high priority tasks then they take precedence and there’s no pressure to join every week.

We have a few regulars, but it’s usually a mixed bunch of people across a few teams. Here's an average week with a somehow well-timed screenshot (promise it wasn't posed!).

Our favourite games are:

SmashKarts - Mario Kart but just shooting each other, no racing. It’s a 3D browser game with simple controls where you can have a private game just for your team. Warning - it gets pretty competitive!
Haxball - Top-down football enjoyed by both football and non-football fans. It’s a 2D browser game with simple controls. Similarly to SmashKarts, you can have a private game just for your team.
Skribbl - Pictionary. It’s reasonably straightforward and a good introductory game.

If we have enough people and we're feeling competitive, it's also fun to go into breakout rooms to discuss tactics. It means you don't get to roast the opposition on the fly, but it can make for a more interesting game - this works especially well with Haxball.

Other games that we’ve played in the past:
Powerline - Massive snake browser game. It’s fun, but you can’t make private lobbies so there’s less team interaction.
Among Us - Remember when this was a trend? I’m not sure that everyone got the hang of it, but it was fun at the time. It’s a bit like Cluedo , only as an app.
Jackbox Party Pack - Lots of games in one. It is a paid for app, but only one person needs to pay. You can use your phone or computer. It’s really funny and not complicated to play.

Join us

If you want to join in the fun, we’re often hiring - you can find all our job listings on our website.

Code reviews

Learning Locker — Mon, 04 Apr 2022 14:10:12 +0000

In the small team of Learning Locker at Learning Pool, collaboration is key to our success. An important part of that is our code review process, which never fails to offer a kaleidoscope of inspirations.

When a ticket hits the code review column, one of the engineers will pick it up and take a look. We have a code review rota where all engineers participate.

Generally, the ticket description gives a clear understanding of what the pull request should try to achieve, so this is a must-read. We also check that the QA notes match the scope of the ticket. Apart from these, there are generally no set rules on the code review process.

Occasionally, there are team reviews too, where multiple team members jump on a quick call to discuss a pull request. To protect efficiency and prevent burdening reviewers, we try to limit to 3 tickets in code review at any one time.

On a basic level, code reviews help the team become familiar with what others are working on. The main purpose of code reviews is to ensure the code is addressing the problem appropriately and to catch any bugs or potential pitfalls.

In our Learning Locker team, we put a big emphasis on quality. To name a few items from our pull request checklist, the author is responsible for checking that they have considered situations such as long running migrations, boundary testing, evergreen browser testing, or if they have included tests for any new features.

Additionally, inside each pull request, Codecov bot provides metrics on whether code coverage has increased, and specifies the lines where changes are not covered with tests.

The team enjoys looking at code thoroughly by asking questions and challenging each other through code review suggestions.

We reference our Engineering Guide as best practises for nitpicks, such as naming conventions (the Engineering Guide is being actively maintained and here's a sneak peek). We never forget to give a thumbs-up to a good spot or an insightful comment. Not to mention, it’s also a good opportunity to see new approaches to problems, different coding styles and the latest syntactic sugar!

Upon a “LGTM” the pull request will be thoroughly checked by the QA team, before finally merged and hitting the production platform - a long but worthwhile journey!

Join us

We’re often hiring - you can find all our job listings on our website.

5 ways we keep our code understandable for junior engineers

Learning Locker — Fri, 01 Apr 2022 09:07:06 +0000

1. Code structure

It’s arguably the hardest part of starting a new dev role - being presented with a repository, (or several), and having to figure out how everything works and fits together. At Learning Pool, we aim to structure files and folders in terms of entry points such that we match the structure of the app from a user’s perspective. We find this helps with navigating the code more easily, especially for junior engineers.

This also ties into trying to keep files and functions to a reasonable size, using our linter’s (ESLint) guidelines - below 100 lines of code for files and below 20-30 lines for functions. To do this, we try to limit a file to a single function and make the name of the file match the name of the exported function. This makes it as clear as possible to anyone who is looking for a piece of code they haven’t seen before.

2. Naming conventions

This is an obvious one. If you name a variable or function accurately, clearly and concisely, then when someone new sees it, they know what it’s supposed to do without having to pick through lines of code to figure it out. Improves readability and saves time - no brainer.

Each language is different when it comes to how something should be named. In JavaScript (and TypeScript), we prefer to use UpperCamelCase for the names of all types such as classes, interfaces, types, enums, etc, and camelCase for variable and function names. We don’t try to differentiate the case between variables and functions because functions are data and can therefore be stored in variables. For function names, we expect a verb followed by a noun. For boolean variables, we usually prefix with is or has, (when it makes grammatical sense!).

3. Built-in language standards vs. Lodash

JavaScript is pretty powerful. It has a lot of built in language standards that have improved over the past few years. Before JavaScript had features like the spread syntax and the Array.prototype.map function, libraries such as Lodash were necessary, but now we have a choice.

We prefer to use built-in language standards over libraries in our code for a few reasons:

It reduces the amount of code required to be interpreted and in some cases bundled therefore reducing our load and run times
Junior engineers are more likely to be taught the built-in language features over libraries, so why make it unnecessarily complicated.
Standards are generally better supported than libraries in terms of fixes and security patches. If the built-in standards just don’t cut it, we try to only use one library (in our case lodash) so that juniors don’t have an endless list of things to learn.

4. Pure stateless functions over impure stateful classes (Functions vs Classes)

It’s easy to get caught up in discussing different design patterns and where code ‘belongs’, and there isn’t always a right answer. On Learning Locker, we use React and Redux on our front-end and have done for a few years before Hooks were introduced in React 16.8.

A lot of our code was originally written in classes, but we’ve been moving towards using pure stateless functions over impure stateful classes where possible (and where appropriate).

There are already quite a few places where you can read the pros and cons in detail. We try to avoid endless refactoring, so this is a slow process, and generally follow the ‘Boy Scout Rule’ here.

“Leave this world a little better than you found it.”
— Robert Baden-Powell (founder of the world Scouting movement)

5. Code reviews

It’s common knowledge that the best way of learning is by doing. We include juniors on our code review rota, and pair them with another engineer so that they can explore further parts of the codebase. If a junior doesn’t understand a piece of code that a fellow engineer has written, maybe there’s a good reason. And if not, then at least they’ve learnt something more complex in the process. For an engineer to explain their code to a junior can also lead to rubber ducking moments where a lightbulb moment happens and a bug is discovered.

Join us

We’re often hiring - you can find all our job listings on our website.

Programming as a Dyslexic

Learning Locker — Mon, 28 Mar 2022 11:26:05 +0000

I have always had an interest in computers, I started ‘programming’ at around 10 years old, configuring games as an attempt to increase my frames per second and decrease my connection ping.

I went through school ultimately thinking I was as thick as two planks. I couldn’t read out loud, couldn’t read from the board, got bad grades, and had terrible spelling and grammar. I was always placed in the lower sets and was constantly being told “Paul is capable of more, he just struggles to apply himself”. It was pretty difficult to hear this.

I felt I had all the information locked in my head and was unable to get it on paper (which is how we were graded, right?!). I was eventually assessed for Dyslexia at college after a referral by my tutor. I was 18 years old at this point and I’m grateful times are changing.

Fast forward some years; I had started working for a company in a technical support department. My line manager saw that I enjoyed messing with software and troubleshooting, so as a side responsibility during downtime, I rebuilt our internal FAQ site using HTML, CSS & some JS (it was more of a reward than anything else).

I then ended up building automated Google Script solutions, Bash Scripts and the odd NodeJS script. This was mostly due to my ever-increasing workload, so with the help of mentors, I automated most of the manual aspects of my role.

However, this wasn’t enough, I still thought I wasn’t able to be a software engineer due to being dyslexic. This went on for a further 3 years and I only programmed as a side responsibility, to automate tasks in the business and my team at the time.

In 2018 I took the plunge and was offered the chance to be a junior engineer. What I’ve learnt since is dyslexia makes absolutely no difference. If anything, it’s a bonus skill set to have in this role!

Yeah, you may typo the odd declaration (just add a spell checker extension to your VSCode), but it’s actually a benefit from speaking to other non-dyslexic engineers (bear in mind, we don’t know how to think non-dyslexic); Here’s some of the things I’ve learned that prove advantages. You’ll:

have a holistic view of architectures
be able to spot patterns and in turn spot an oddity
easily generate mental models
bring to the table a different way of thinking
be able to visually memorise a lot
remember syntax preferences for the project
spot syntax oddities
notice things in a PR which others may not
be able to visualise and design processes
easily spot possible bottlenecks.

There’s no doubt more, these are just my personal findings (it’s difficult to be 100% as I only know how to think like this).

A dyslexic is a valuable engineer for any software engineering team and is extremely suitable for the role (a good team is made up of a vast mixture of skill sets after all).

Don’t let past experiences around spelling and reading put you off. Configure your IDE preferences and have a go.

I do also have some tips I would love to share:

Don’t hold back telling employers you're dyslexic. I personally now see it as an added skill set, heck, put it in your CV under additional skills!
One key thing is setting up your IDE and browser to help you;
You could use the OpenDyslexic font (bear in mind, screen sharing). Out of preference I personally prefer Verdana when coding. There is also a Chrome extension to enable the OpenDyslexic font across all webpages - here is a dev.to article explaining how to set up both.
I use the Henna VSCode theme which is extremely dyslexic friendly.

Install a spell check extension for your IDE, I use Code Spell Checker in VSCode.
Browser (specifically for Google Chrome):
I use the hacker vision plug-in as it gives me dark themes for sites/platforms which don’t have this option.
And Grammarly for writing Jira comments, emails, documentation,

Don’t be afraid to keep customising and trying things. What works for me, may not work for you.

TL;DR if you are a dyslexic and have stumbled across this blog post and wish to become a software engineer, don’t let dyslexia hold you back for years like I did. Pick a language on Codecademy (Python is a good starter), find something you wish to automate/script and give it a try.

I have now enjoyed programming full-time since 2018 and I haven’t looked back. I honestly feel I’m cheating at life by getting paid well to pursue a hobby with like-minded individuals. Dyslexia is great. Happy coding.

Join us

We're currently hiring for a lead developer - if you're interested, you can apply here.