DEV Community: Anna J McDougall

How to Support Junior Developers

Anna J McDougall — Mon, 14 Jun 2021 11:12:26 +0000

Introduction

I am in a unique position right now: I am a Junior Software Engineer filling in for a Tech Lead for two weeks, covering two internal projects filled with other juniors, trainees, and interns. This means that I am both a junior and acting as a guide for juniors at the same time.

This isn't the first time I've played this 'double role': when I was completing my year-long training in web development, I was both a student and a class tutor: learning and teaching at the same time. There is a lot to be said for this: namely, that teaching helps you learn as well.

Additionally, this unique position allows me to provide insight on how best to support junior developers with the advantage of both perspectives: that of the junior, and that of the supporter.

All that said, let's talk about ten things you can start doing to better support your juniors today. *Spoiler alert: * a lot of it comes down to communication!

Table of Contents:

Define expectations and timelines
Emphasise trust
Provide choices
Avoid minimisers
Avoid solving problems for them
Ask questions
Review tickets with why
Give regular feedback
Go beyond technical conversations
Ask for regular feedback
Conclusion

1. Define expectations and timelines

It can be extremely disorienting to enter not only a new workplace but also a new industry. If you are in charge of guiding the path of a junior, it is your job to explain to them as early as possible what that path will be, what is expected of them, and what kind of timeline they'll be working with.

"For the first month or so, you and I will be working closely to have you trained up in Java for the backend, including testing and basic microservices. There is no set timeline for this, but once you feel you're ready to move on, we'll then look into Docker and other containerisation technologies. The goal is that by about six months into your time with us, you'll be comfortable and confident coding the backend for bigger projects."

Alternatively, you could speak more broadly:

"As a junior, we really want you to focus on learning and asking as many questions as possible. You'll have a chance to explore a lot of different technologies, and after around a year we can talk more about which you'd like to specialise in."

It is also important to speak directly about what you expect (or don't expect) from them:

"Our expectations in your first few months is that you get to the point of being able to solve a few tickets, but we don't expect you to be an expert or to complete them without any assistance."

By having these conversations, the journey of their first year won't seem quite so daunting: this kind of structure can provide a better sense of security. This allows them to have some soft goals to work towards, but also gives them an understanding that they are not expected to be an expert.

2. Emphasise trust

A lot of juniors will be entering the industry straight out of some sort of study situation, be it a bootcamp or a degree or self-study at home. As a generalisation: the younger or newer to the workplace a junior tends to be, the more they will tend to try to impress you and not tread on any toes. This is not a good thing: you want honesty and you want to know exactly where they stand with the technology.

Often juniors are so caught up in trying to impress you, since they're often suffering from Impostor Syndrome and trying to prove themselves, that it will be hard for you to get an honest assessment of their skills and abilities, and any attempt you make to do that directly could embarrass them.

Instead, try to build a relationship of trust.

For example, when I first began I told my Unit Lead that I had a dentist appointment on that Friday and I wanted to know if that was "OK". His response was perfect:

"I'm not here to micromanage you. I trust you to handle your own schedule and complete your hours as you see fit."

Additionally, you need to be transparent about not knowing things, and to talk about it openly with your juniors. One trainee asked me about the difference between casting and parsing, and my response was:

"Great question! I think I know, but let me check so I don't feed you false information."

This models the kind of behaviour you want to see: honest conversations about what we do and don't know, and an openness to being wrong and checking for the latest info.

3. Provide choices

Very often, a company or team will have a structured onboarding process. This is usually a great idea, but there has to be wiggle room for individual responses. Where possible, try to find small ways where you can provide options. Give optional 'bonus assignments', provide multiple tracks of specialisation, or offer for the junior to come into meetings they wouldn't normally be in so they can see how things run.

Early on in my time at Novatec, I was invited into a few meetings with the Software Reliability Engineering team in our Spanish office. I barely said two sentences, but getting to see how different teams worked together was highly valuable for me, and I felt special being invited.

Now, as an Acting Tech Lead, I've offered opportunities for trainees and students to work with me on topics, or to sit in on workshops that are too advanced for them (for a half-hour or so), so they can get a taste of what is to come. Nobody has to do these things: they are offered up as choices for additional involvement/observation/learning, and the junior is free to take it or leave it.

From your perspective, this is also a good way to see what opportunities interest individual juniors, and what opportunities don't. This can only help you further personalise your interactions, and perhaps also flag early which areas could be their future specialisation.

4. Avoid "Easy", "Simple", "Basic", and "Obviously"

This is one of the most important but most difficult habits to break.

In my position, we work with a lot of trainees with little or no programming experience.

How do you think this person will feel if I talk about how "easy" HTML and CSS are and then they get stuck learning Flexbox?
What about when they ask me how to turn a string into an integer and I say "Well obviously you need to parse it" and they don't know what parsing means?
What if I tell them to try some "simple exercises" and they get stuck only 5mins into trying?

As someone with a bit more experience, it's easy to forget how hard things are at the beginning, and how much of a change in thinking programming often requires. Things that are easy, simple, and obvious to you are not necessarily that way for a junior.

Your goal might be to make concepts seem less intimidating, but what the junior hears is "you're supposed to know this and you're ignorant if you don't". Remember Impostor Syndrome? A lot of juniors are also career changers, and when they have it implied that something is obvious that they don't know, it can trigger a broader fear of not belonging.

That, in turn, means they're less likely to ask the follow up questions they should ask:

"Flexbox seems to be holding up my progress, do you have any good resources on it?"
"Sorry, what does parsing mean?"
"I'm stuck on the first exercise, can you help?"

5. Avoid solving problems for them

Let's say, though, that they do ask the right questions. They do ask for help. What comes next? Presumably, like any good mentor, you're ready and willing to help them solve it. Wonderful!

If you're in a position to guide a junior, then you most likely are a problem solver, and your instinct will be to solve their problem as quickly and easily as possible.

Unfortunately, that instinct is not the right approach. You need to give them enough resources to solve the problem, without actually solving it for them.

For many beginner issues, the problem will be not knowing the correct terminology to Google: in this case, the answer could be as simple as saying "Try looking up information on CORS".

But let's say they have the information, and still don't know how to proceed. The next question should be "What have you already tried?". This achieves two things: it ensures they've actually tried to solve it themselves (which helps promote initiative); but it also gives you an idea of how they're thinking about the problem and its solution.

In short, try to ask leading questions or make suggestions for future research, rather than just saying "Oh that's easy just use a loop".

6. Ask questions

It's not just the junior who should be asking questions, it's you as well. Asking questions allows the junior to repeat and articulate concepts that may otherwise be unclear or not totally solidified in their minds.

Try some of these:

"What kind of problems do you anticipate for this ticket?"
"What kind of tests will we need to write?"
"What should happen if a user enters text instead of a number?"
"Do you think we should use an integer or a double here?"

This step is particularly important for juniors and trainees who aren't asking a lot of questions themselves. These kinds of points allow you to gauge where a junior is at in terms of their knowledge, which means you can better tailor your responses to their level. If they can answer the fourth question clearly, but can't answer the second question, then you know they have decent programmatic knowledge but less testing knowledge. This is good information and means you can help them with finding appropriate resources.

7. Review tickets with "Why?"

Your junior has completed a ticket and/or has asked you to review their code, terrific! One great piece of advice I received recently from my own Technical Lead, is to always ask "Why" in these scenarios.

This is especially the case if, like me, you're still new to the project yourself. Even if not, trying to understand the perspective of your junior is always worth the extra time it takes to ask more probing questions.

If someone has solved something in a way that would never occur to you, this is especially important to ask, as it avoids you perhaps jumping to the conclusion that it is just wrong. Sometimes the fresh eyes of juniors can bring things to our attention that are new or different, and taking the time to understand that perspective could actually help you improve your codebase.

In addition to that, asking 'Why' might also highlight misconceptions the junior has about the codebase itself, which in turn could help you with refactoring or making the flow of information cleaner. After all, we want human-readable code that is as simple to follow as possible.

8. Give regular feedback

One of the hardest things to do as a senior is to give honest, regular feedback. Let me teach you a simple strategy for doing so, called the "compliment sandwich".

Lead with a compliment
Insert some constructive criticism
End with a compliment

Here's an example of a compliment sandwich:

"I wanted to share with you some general feedback about your progress, since you've now completed your first week. Overall I'm really happy with how many questions you've been asking: it's clear you're really engaging with what you have to learn and are being honest about your progress. I got a comment or two from coworkers that sometimes** you interrupt them in group discussions*, so ideally that's something you could work on for next time. Other comments I received said that **your sense of humour is really refreshing* during routine meetings, though, which I know is greatly appreciated by all of us!"

This gets the point across: "people are noticing when you interrupt, and it's a behaviour which isn't good for the team". However, it's also not making it into a bigger deal than it needs to be, and the junior won't come out of the engagement thinking that everyone hates them, which is naturally a concern of someone new to any type of group.

The other benefit to this type of feedback is that it leaves room for a different approach when something more serious does happen. If someone is yelling at teammates, for example, or making discriminatory "jokes", you can pull them aside and be far more direct, and they will know that it is serious because THERE IS NO SANDWICH.

9. Go beyond technical conversations

Sometimes you see a junior lose the wind in their sails. They look deflated and defeated, and are not being their usual selves. This is the time to enter "Mentor Mode" and shoot them a quick message or have a quick chat with them: "Hey, you don't seem quite yourself today. What's going on?". If they make it clear it's not to do with work, then you need to also make it clear that that's OK: "No worries, you can still tell me about it."

I have been on both sides of this conversation. Both times, I have come out feeling closer to the other person and it has built trust between us. It feels good to know that someone is noticing when I'm down, and that I'm not bound by what is considered typically professional when something is impacting my work. Similarly, knowing what is happening in the personal lives of others, especially when it is serious and impactful, means that we won't rush to make judgements about their work performance or personalities.

You might also find that someone is dealing with typical issues such as impostor syndrome. In these scenarios, it's a good idea to share your own experiences, how you felt when you started your first tech job, etc. Knowing that you understand, or at the very least acknowledge, the impact of these feelings can lead to even further trust and helps establish a solid working relationship.

Of course, if the issues are beyond the scope of your abilities to handle or support, there is also nothing wrong with saying so: "I am here if you need someone to talk to, but I'm not a professional and this sounds like something you need to discuss with someone who knows more about it". Definitely don't give unsolicited medical advice for medical issues (e.g. depression, anxiety, phobias, etc.).

10. Ask for regular feedback

Last but not least, remember that the flow of information should never just be one-way. None of us are perfect, and we all mess up. Similarly, we all have skills we can work on. If you're new to guiding juniors, take the time when giving them feedback to ask them "Is there any way I can support you better?" or "Have you got any feedback for me from our time together?".

Try not to phrase a request for feedback as a statement, such as: "I hope you've found our time together useful". This begs for a compliment and does not provide an open environment for honest critique.

Better still, if there are a few members of the team who you know tend to brutally honest or lack a filter, then it's worth shooting them a message and saying "If you have or hear any feedback on me, good or bad, I'd love to know". This again builds trust, but you also know that if word starts going around 'on the grapevine', you'll hear about it.

Although of course, you have to be ready to hear negative feedback, just like when you were a junior yourself. Honest critique, even when constructive, can still hurt; but it is essential not only to your own progress, but to that of the future juniors you take under your wing.

Conclusion

Build trust, have an open ear, and be ready to read between the lines. Nurture your leadership of juniors and their progress will not only reward your company, but your soul. You can probably recall someone who lifted you up and gave you faith in yourself in your early days. Be that for someone else and you can change their lives, even if only for 20-40 hours per week.

You got this.

How I Became a Junior Software Engineer in Under a Year

Anna J McDougall — Mon, 01 Feb 2021 19:52:32 +0000

Follow Me on Twitter @AnnaJMcDougall

Today I announced my first official job as a developer after accepting a position as Junior Software Engineer with Novatec GmbH. I see this job as a long time coming, and the culmination of years of interest in technology and coding, but the truth is that I will be starting only a year after I began programming in earnest.

Firstly, let's begin by stating something obvious but necessary: Finding your first job in tech is not an easy process, and it is different for everyone. As with everything, a combination of skill, preparation, networking, and luck, is essential. With that out of the way, let's have a look at how I got to this point.

1. Early Interest

I have an entire blog post about my life story and how I got to the point of deciding to pursue programming as a career. The short version is that I always loved computers and technology, and as a teenager (in the early days of at-home internet accessibility) I often created websites. I even studied Software Design and Development as one of my high school subjects, but never pursued it: in large part because I was the only girl in the class. Nevertheless, I did make a few more websites over the years, even as alternatives to essays for a few subjects in my Media and Communications degree.

2. The Floating Thought

We all have what I like to call 'floating thoughts': those thoughts you have that "I'm sure I could do that if only...". For me, programming was a 'floating thought'. Plenty of my friends over the years were men and women involved in software engineering and web development, and whenever I met someone who worked in tech (for example, at a party) I would get super excited and blurt out something along the lines of "I love technology and programming!" before realising I didn't actually have much to say on the topic, because I hadn't actually learned anything beyond HTML as a kid.

Learning to code was a "floating thought" that I was sure would happen once I had some time, or was looking for a new hobby, or felt like I could handle it. However, year after year passed, and it remained there, floating. Once we get to the end of this article, I'll let you in on my only remaining floating thought!

3. The Push

In May 2019, my daughter was born. This precipitated an unprecedented change in my life, not only because of the impact being a parent has had, but because it made me take a long, hard look in the mirror about my career as an opera singer. As much as I love being on stage, it was not fulfilling my ambition or my intellect in a way that would be sustainable in the long-term. I knew a change had to happen, and as soon as the end of maternity leave began to loom, that floating thought wafted down from the heavens and landed squarely on my shoulders. It was March 2020. It was time.

4. The Test Run

Enter The Odin Project. I had mentioned in a Facebook group for mums that I wanted to learn to code, and one of the women sent me this link. I had tried a few online tutorials but they had all involved just 'coding along', without giving me an understanding of what was actually happening. The Odin Project is a free written course with an incredible Discord community, where I was able to not only learn web development languages, but also learn web development set-up: from IDEs and npm packages through to Git and ES6 modules.

I studied The Odin Project every day, 3 to 6 hours a day, for 60 days straight... yes, including weekends.

In addition, my activity in the Discord community meant that I quickly was able to have a senior developer act as a sort of mentor to me, who told me that it wasn't just my imagination: I was learning the content of the course quickly and thoroughly. He encouraged me to keep going and to look into local options as well.

Despite deciding to move on from The Odin Project, it is still my #1 recommendation for those wanting to become developers, as you can see in this YouTube video from last month:

A fun side-fact is that during my time learning with The Odin Project, I also kept daily "check-ins". Here are a few to give you a taste of how it came along!

5. The Course

After speaking to a local recruiter and investigating several bootcamps in my area, I decided not to go that route, but instead to sign up for a year-long web development course that was fully government accredited. I knew that even if I did a 3-month bootcamp and nailed it, it would be tough for me to convince an employer that I knew what I was doing if I didn't have 'the paper'. I live in Germany, and they LOVE certificates. It would be far easier for me to prove my abilities with a one-year, government-accredited certification than with a three-month paid programme. Furthermore, it would give me time and space to truly become an expert in what I learned.

So in June, I began studying Web- and Software Development with Digital Career Institute in Leipzig. It was supposed to be an in-person course, but as it turned out we never did transition back from Zoom. I quickly realised that the pace of the course would not be at the same speed as my learning, and I ended up being more in a position of helping the other students than learning much myself. It turns out that those two months with The Odin Project were enough to get me months ahead of my fellow students. I ended up being hired by the course provider as a Class Tutor (quasi Teaching Assistant) and was also chosen to be Class Representative by my peers. These two positions, to my mind, were able to reflect both my technical expertise and my love of helping others and lifting up the whole team. The added bonus, of course, being that it also acted as great 'proof' to potential employers that I would be a good hire.

Although many students found the pace of the course to be too fast, for me it was noticeably too slow, and so I spent my "spare time" getting ahead of the curve: purchasing a NodeJS course from Flavio Copes, learning React, and building my portfolio site. By the time we started on our backend modules, I knew we were about to cover the last (and probably only) section I didn't feel confident in.

6. The Job Search Begins

Truth be told, my job search was almost thrust upon me. I had mentioned in a few NYE tweets that "This will be the year I get my first job as a developer", thinking I would slowly put together my documents and start applying in February or March. I began getting messages: "Apply for this job at my company and tell them I referred you!". Nervous but also excited, I applied to a few places with a haphazard English-language CV I'd thrown together. I quickly realised that the skills I had worked to develop, and the seemingly natural talent I had for learning programming concepts and syntax, were more than enough to start looking for a job now, and so the search began in earnest.

7. The Video aka THE AVALANCHE

There is an incredible YouTube series from Danny Thompson all about how to improve your LinkedIn profile to find work, and one video in the series involved him talking to Taylor Desseyn, also known as "the recruiter against recruiters". I had been following Desseyn's posts on Twitter and LinkedIn for a long time, since I love his energy and frankly think we'd just have a blast if we ever got to share a beer. On top of that, he knows his stuff. One thing I'd seen him recommend (truthfully I can't remember when or where) was the idea of recording a short video answering the most common first-interview questions in your field.

I had already planned to record some YouTube videos one night, so before I began to talk about array methods, I jotted down some common questions I'd encountered from German employers and answered them on camera, complete with a backdrop matching my portfolio website theme. I found some royalty-free music and dropped it into the background, and after some editing the whole thing came out at a bit over two minutes.

When I watched it back, it felt stilted and corny, and I wasn't sure it did me justice. Nevertheless, by the time I'd prepared it the makeup was off and the backdrop had been put away, and I wasn't going to do any more takes, so I sent it to Desseyn via LinkedIn message to see what he thought. The next day I had a message saying he loved it. Despite disagreeing with his assessment, I shrugged my shoulders and posted it on Twitter, complete with a call for my followers to retweet it (which, I should add, I don't recall ever doing before).

The tweet.... did pretty well. I'm writing this with it sitting at 27,600 views.

// Detect dark theme var iframe = document.getElementById('tweet-1350057528361705473-835'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1350057528361705473&theme=dark" }

This is when the messages really picked up. Suddenly, I was being inundated with offers and referrals. I applied to about half of the referrals I got, and had to prioritise based on suitability to my passions, location, and yes, income. If the first half hadn't worked out, then I would have applied to the others, but the truth is that I did not have enough time in the day to put together applications for all of the referrals I was receiving, and still keep on top of the interviews which were coming through.

8. The Winner

Luckily for me, a representative from Novatec had taken a particular interest in me, and invested two hours into a conversation to tell me about why it was a great place to work. The conversation helped me see how the company ticked a lot of the boxes which were important to me: an environment in which to learn; a long-term placement that would give me opportunities to advance; opportunities to speak at conferences and be involved in the community; an income commensurate with the value I know I can provide; a willingness and an excitement about expanding the number of women in tech; an involvement in assisting young people to better engage with technology; and a modern work environment focused on Agile methodologies.

On top of all that: everyone at the company was lovely!

After chatting to an HR rep and my future team lead, I got the best type of butterflies: the type you get after an exciting second date. The question was: "Are they as into me, as I am into them?".

Luckily, the answer was yes! I quickly received an offer in line with my salary expectations, agreed to it verbally, and went about sending my best wishes to the other companies I had been interviewing with.

In the end, I was told that the fact that I did not know their specific stack was, in this instance, less important than the fact that it was clear I was a fast learner; someone who loved programming and adored a challenge; and an open and friendly personality who would be good to work with and potentially a good leader further down the line.

I felt lucky to get them, and they felt lucky to get me: what a great start!

9. Onwards and Upwards

Now it's time to get stuck into the next stage. I'm about to go from being top of the class to bottom of the heap. This will take a huge adjustment of my ego and an ability to be humble, take my time, and ask questions no matter how small and silly. I feel very supported by my new company and by my team lead, who will also act as my mentor and guide through this transition. I will be working in a new field, with new languages, and probably not much involvement with the stack I've spent the last year learning. Nevertheless, anyone who knows me knows that I am fired up by a challenge, and nothing can stop me once I set my mind to something. Bring it on.

Lessons and Conclusions

If I had to distill my own experience down into a few key takeaways, it would be these:

While learning, focus on getting things working, not on getting things perfect.
Always show an active interest: you may not be passionate about coding like I am, but you can always show initiative by going one or two steps further than what is required.
CREATE CONTENT: My 'Video CV' tweet would never have gotten as far as it did if I hadn't already been building a following on Twitter, YouTube, and my blog for months beforehand. I have a video about why every new programmer should create content, and even without knowing you, I know that you should, too.
Lift up others: By supporting others, you show that you are not just focused on your own success, but in that of a team. That is just as important as your coding abilities.
Explain to employers why you'll be awesome: I had to swallow any and all humility and tell potential employers straight-up about how I'm top of my class, about how I can learn in half an hour what others learn in a day, and many other 'fun facts' which make me sound like someone who thinks she's the best thing since sliced bread. 'Bragging' is absolutely necessary.
Every application you submit should have a name in it: That is, someone at the company who has referred you or to whom you've spoken. Do you know how many interviews I got from employers I cold-applied to? Zero.

I will write and record more about each of these points in the coming weeks, but hopefully that gives you an idea of not only my own career change journey into tech, but also about how you can take the initiative to raise your profile and score something excellent for yourself.

P.S. What is my only remaining 'floating thought'? I'd love to be on the Board of Directors for a charity some day!

Interact with the Command Line using "process.argv" in NodeJS

Anna J McDougall — Wed, 06 Jan 2021 14:15:37 +0000

Follow Me on Twitter @AnnaJMcDougall

One of the really cool things I'm discovering about NodeJS is that it allows us to interact more directly with computers, and enables the production of tools using the CLI (Command Line Interface: you may know it as the Terminal).

Just as how yesterday I wrote about the core module fs to achieve some basic file manipulation, today we'll look at one of the big methods in the process core module: argv.

What is the `process` core module?

This module tends to cover anything involving the actual running of Node scripts. It allows us to do things like terminate the program using process.exit(), for example.

What is `argv`?

The method process.argv basically captures what the user has typed into the command line or terminal when the programme runs. It returns us an array of each term entered which was separated by a space. If you're familiar with JavaScript string methods, it basically takes the command entered into the terminal, splits it by spaces, and then returns that array.

For example, if we run this code in the Terminal:

$ node index.js a b c

Our process.argv will return:

[
   'C:\\Program Files\\nodejs\\node.exe',
   'C:\\exercises\\index.js',
   'a',
   'b',
   'c'
]

Here we see the path for node, then the path of the file we're running, and then each of the arguments we've entered into the command line.

The really cool thing about this is that it means if we run a simple slice command, we can pull out whatever the user has entered, and then use that in the program they run.

For example, we could make a quick and dirty madlibs like this:

const [name, number, animal, verb] = process.argv.slice(2)

console.log(`${name} was taking a nice stroll 
along the river when suddenly 
${number} ${animal}s appeared and 
began to ${verb}!`)

Line 1 uses destructuring to assign the four words entered by the user to those variables. So now we can enter:

node index.js Bob 42 frog dig

We now have a fun little story pop out the other end:

Bob was taking a nice stroll
along the river when suddenly
42 frogs appeared and
began to dig!

This might seem a relatively silly example, but this allows us access to the command line and to using typed values in our programmes in all sorts of ways, opening up a whole new world of possibilities for creating tools for our fellow developers.

Reading and Writing Files/Directories in NodeJS Using the FS Core Module

Anna J McDougall — Wed, 06 Jan 2021 14:13:40 +0000

Yesterday, I answered my own SUPER-NOOB questions about servers and NodeJS. Today, I want to have a look at how we can use a core module within NodeJS which allows us to interact with the file system. This core module is called fs (file system).

Let's have a look at some of the simplest operations we can achieve using fs.

A note about asynchronous code

If you aren't already familiar with Promises and the concept of asynchronous code, it is probably best to use the 'Sync' versions of all of the following methods. I won't be covering them here, because they're not what I'm learning, but you can check the NodeJS documentation for more information.

If you kinda get the idea of Promises and/or asynchronous callbacks, then you will probably be fine to get through this.

Asynchronous callbacks in NodeJS

Each of the following methods follows a similar pattern:

The method/function itself, e.g.fs.readFile(
The file or folder it will be working with (aka the path), e.g. './file.txt',
Additional options, e.g. {flag: "a"},
A callback function e.g. (err) => console.log(err ? err : "success"))

Since all of the following methods are asynchronous, the callback function is what will run after the method is complete. It usually takes either one or two parameters, and in all cases listed here, the first parameter is the error message if a problem is encountered.

Now that we've covered the basics, let's have a look at how we can make a new directory.

Setting up a path variable

For the sake of my examples below, I put some nice little code at the top of my file which looks like this:

const fs = require("fs");
const path = require("path");
let currentPath = path.dirname(__filename);

The first two lines import the core module native to NodeJS which we need, and then the third line accesses the file we're in (a simple index.js file) and then pulls out the path into its directory using path.dirname as the method, and the global variable __filename.

By creating the currentPath variable, I can more easily test and play with the following methods. If you don't want to do this or something similar, you can also manually enter the path into the directory in which you want to work. Personally, I feel this is easier.

Now, it's important to note that we don't always need to use the current path/directory in our methods. We could just use ./ or similar, however as I see it, in future we are likely to be needing to work with other paths outside of our source code, so I assume (perhaps wrongly?) that using the full path is a better habit to build. I'd be interested to hear what more experienced developers think about this in the comments!

Using `fs.mkdir` to Create a Directory

The following command simply creates a new directory called testFolder inside our current folder. Using a template literal i.e. a string with backticks\ we can insert our currentPath into our first argument.

fs.mkdir(`${currentPath}/testFolder`, (err) => {
  if (err) throw err;
});

Using `fs.readdir` to Check the Contents of a Directory

You may be familiar with the ls command in the Terminal. This is a similar command, however rather than providing us with a CLI read-out of the files, it returns an array of file and folder names.

fs.readdir(currentPath, (err, files) => {
  if (err) throw err;
  console.log(files);
});

When I ran this in my test file, this is what I got back:

[ 'index.js', 'test.txt', 'testDir2', 'testDir3', 'testsDir3' ]

Additionally, there is a way to get access to what type of file is in your directory. Here's a neat little function I came up with:

fs.readdir(currentPath, { withFileTypes: true }, (err, files) => {
  if (err) throw err;
  files.forEach((entry) => {
    console.log(`${entry.name}, ${entry.isDirectory() ? "directory" : "file"}`);
  });
});

This will allow me to see in my console, whether each item is a directory or a file, using another inbuilt method in Node (I am starting to love all these in-builts!) called isDirectory() which comes back on file listings when the withFileTypes: true object is passed in as an optional second argument.

So what do we get back?

index.js, file
test.txt, file
testDir2, directory
testDir3, directory
testsDir3, directory

### Using readFile to Look at File Contents

Let's say we want to look inside the test.txt file and see what it says. Unfortunately, data from this file is going to come in encoded. Let me show you what I mean:

fs.readFile(`${currentPath}/textInfo.txt`, (err,data) => {
if (err) throw err
}

Here's what we get back

<Buffer 54 68 69 73 20 66 69 6c 65 20 69 73 20 62 79 20 41 6e 6e 61 20 4a 20 4d 63 44 6f 75 67 61 6c 6c 21 21 21>

Uhhh... OK. Well, that's not normal, readable text. WHAT DOES IT MEAN?

Luckily, we can specify what format to use to decode/parse this information. In the case of simple text, utf-8, which we see entered here as a second parameter in string format.

fs.readFile(`${currentPath}/textInfo.txt`, 'utf8', (err,data) => {
if (err) {
console.error("ERROR: File reading did not work. Error code " + err)
} else {
console.log("SUCCESS! Here is your data: " + data)
})

Now what do we get??

This file is by Anna J McDougall!!!

Whew, that makes a lot more sense.

Using `writeFile` to Create a New File or Append Text

Now that you're familiar with the pattern of these commands, let's have a look at a simple example where we create or overwrite a text file:

const newText = "Here is some new text!"
fs.writeFile(`${currentPath}/textInfo.txt`, content, (err) => {
if (err) throw (err)
})

Great! We now have a file called textInfo.txt which has the text "Here is some new text!" within it. Let's try to add some MORE text!

const newText2 = "\nI'm so glad we're adding more text";
fs.writeFile(`${currentPath}/textInfo.txt`, newText2, (err) => {
  if (err) throw err;
});

Good work! ...Wait, that's not right...

Where did our first text go? D'oh! That's right! fs.writeFile overwrites existing file contents! So how can we just add some more text onto the end of our original instead? Using the a flag.

const newText2 = "\nI'm so glad we're adding more text";
fs.writeFile(`${currentPath}/textInfo.txt`, newText2, {flag: "a"}, (err) => {
  if (err) throw err;
});

Aha! Well that looks much better:

Using `fs.stat` to Check Your File Details

Last but not least, let's have a little peek in at our file to see what its details/stats are. Here's a fun little method:

fs.stat(`${currentPath}/textInfo.txt`, (err, stats) => {
if (err) throw(err)
console.log(stats)
}

This brings us back the following information:

Stats {
  dev: 647735127,
  mode: 33206,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: 4096,
  ino: 44754521297123880,
  size: 0,
  blocks: 0,
  atimeMs: 1609859928899.2424,
  mtimeMs: 1609859928899.2424,
  ctimeMs: 1609859928899.2424,
  birthtimeMs: 1609859583171.8276,
  atime: 2021-01-05T15:18:48.899Z,
  mtime: 2021-01-05T15:18:48.899Z,
  ctime: 2021-01-05T15:18:48.899Z,
  birthtime: 2021-01-05T15:13:03.172Z
}

Wonderful! Now we have a whole heap of details about our text file. I'm sure one day we'll be able to understand and use this information somehow!

"What does it mean to write/run a server?" Answering My Own Questions About NodeJS

Anna J McDougall — Mon, 04 Jan 2021 14:17:56 +0000

Follow Me on Twitter @AnnaJMcDougall

It's a new year, and I am thrilled to finally be dipping my toes into the waters of back-end development as my class begins to explore NodeJS. Switching mindset from front-end to back-end can be a difficult task, and I had so many questions about what Node.JS is and does in the wider field of web development.

In this post, I want to answer the questions about servers and Node.JS that the 'Anna of Yesterday' had, using the wisdom 'Anna of Today' has obtained. Hopefully, this helps others with similar questions stumbling upon this in their Google searches. Keep in mind that I myself am still new to this field and therefore, as always, the NodeJS learning platform is the best place to get official, up-to-date info.

1. I thought a server was a physical piece of hardware. What does it mean to write/run my own server?

Although the internet as a whole does involve enormous server infrastructure, there has been a move to what are called 'Virtual Machines' which are smaller, rentable units of physical server space into which you can "plug" your own server.

Nowadays, when the term 'server' is used, we are usually instead referring to a programme which, like all programmes, can be written, changed, maintained, etc. This programme's role is to interface all sorts of separate entities we need to run an effective and secure website. This includes the things we've already worked with before (i.e. the front end: click events, UI, the DOM); but also includes the myriad of items we may not be as familiar with (i.e. databases, authentication, encryption, etc.).

This was the big takeaway from me: reimagining servers not as physical locations for the storage of data, but as programmes designed to interface multiple systems which may not otherwise be capable of interacting with each other.

2. Why do we need NodeJS to do this stuff?

The simplest reason, as I understand it, is that JavaScript is not a natural server-side language. Previously, we would have needed knowledge of other programming languages to do the kind of tasks we can today achieve with NodeJS. Part of the reason for this, is that NodeJS has taken the V8 JavaScript engine and put it in its own environment. Behind the scenes it uses C++ to help achieve the features which aren't native to JavaScript, but from our side JavaScript is the only thing we need to know. This is awesome because... well, it's less work to just stick to one language and it means we're able to use JavaScript alone to achieve our entire website infrastructure.

3. Is this the same as web hosting services?

When I think about 'virual machines' and 'interfacing', my instinct is to think in the front-end way: between us and the user. As a result, I was under the impression that the stuff described in Question 1 above was similar to paying for web hosting services. Domain hosting is actually a completely separate entity and is unrelated to writing/maintaining servers: the domain simply acts as a "mask" or entry point for the user.

4. Do I have to pay to run my own server?

As mentioned earlier, you can pay to rent virtual machines and plug your server in there. However, most people reading this are not representatives of corporations who are going to be needing that level of infrastructure. There are many smaller options for people learning, making personal projects, or just looking to host a small business website. I'll be talking more about this in the near future, but one hugely popular option is Heroku. As I've never used it before, I can't speak much to it, but you can be sure that I'll be experimenting and coming back to you with more information. The same can be said for Docker, which works differently but again, I'll bring you more in future.

5. What is the relationship between NPM and NodeJS?

If you're familiar with front-end development, and particularly if you've used React or another front-end framework, you'll already be familiar with NPM, and you may even know that NPM stands for "Node Package Manager". However, the relationship between the two might still feel nebulous.

Simply put, NPM uses Node to bind together features/packages/modules which can expand the abilities of our JavaScript code. NodeJS allows us to use modules in much the same way as vanilla JavaScript, including: "core modules" (globally available modules native to Node) which give us access to systems, data, and network tasks which are otherwise inaccessible; our own modules which we can write and export/import as usual; and external modules which are often commonly known as packages.

When we use NPM in front-end development, we are (perhaps unknowingly) already using Node to bind together different features we wouldn't otherwise have access to.

6. OK fine, so we can do lots of stuff with NodeJS but... What, exactly?

Oh my sweet summer child... SO much. Not only does Node allow us to work with databases in a way which would be difficult, impractical, or downright impossible with plain client-side JavaScript, but it also allows us to work with contemporaneously unmissable features of the internet, such as user authentication. Most highly interactive and responsive web services are made significantly simpler with the use of Node: chat rooms, video streaming, and much more.

Conclusion

I'm sure I'll be writing more about NodeJS soon, because I plan to use it a lot in future, but for now let's just bask in the fact that Node allows us to bring together a whole host of features and implement them all in JavaScript. This is precisely the technological leap that was needed to allow JavaScript developers to work across the entire spectrum of web development, and for those of us who love JavaScript (hi!) that is a big deal.

Ten Tips for How YOU Can Make Your Workplace Friendlier for Women

Anna J McDougall — Mon, 14 Dec 2020 11:09:44 +0000

Friends, let's talk.

It has been a hard year for everyone, and something that happens in hard years is that we have less patience for little annoyances because all our energy is spent keeping... /gestures at everything/ at bay.

So I've been seeing more and more women in tech, who normally put up with all kinds of little pieces of everyday sexism, start to crack. They're starting to wonder if tech is right for them, if everything companies say are just designed to keep them quiet, and to question how they can "be the change" while still keeping themselves sane in environments where they feel unwelcome and sometimes under active attack.

This piece is not aimed at those women. They've had enough of people telling them how they can adjust their attitudes, or (almost worse) pointless platitudes of how they've "got this". None of that solves the problem.

This piece is also not aimed at any men looking for some feminist boogeyman to rail against. Sorry to disappoint you, but I'm just trying to make everyone nicer to each other.

This piece is for the male colleagues and managers out there who want to help but don't know what they can do to make the workplace more friendly for women. Let me help you help this industry to become better.

Ten Tips for Making Your Workplace Friendlier to Women

(P.S. Yes I will turn this into a talk for your next conference, just ask.)

Don't interrupt: So you think you don't interrupt women? OK, the next time you talk to a woman, especially in the workplace, try to be really conscious of it and see if you catch yourself about to do it. If you don't: great! Congratulations! Now, listen to others and if you notice a colleague doing the interrupting, maybe drop a "Hey I don't think Sarah was done just yet... sorry Sarah what were you saying?".
Lift up women's voices and take an active interest in them: Along similar lines, try to notice when women's opinions are being dismissed too soon or not considered in a way which would happen for a male counterpart. In some really bad workplace cultures, you might notice women not speaking up much at all: most likely, they have learned it is pointless. Make an effort to talk to them after the meeting and pick their brains: Do they agree with the conclusion which was reached? Do they think there was anything missed? Sometimes a 1-on-1 chat with a friendly colleague is less intimidating than a room full of people who don't look like you and treat you as either a token or an annoyance (...or both). Doing this in a meeting could seem confrontational rather than friendly and interested, so these conversations are best had individually.
Understand that you don't understand: If are not a woman, then you don't understand what it's like to be a woman in the workplace. For one thing, most of us have developed an instinct for when someone is just a generally condescending person vs when they are being condescending because of our gender. It is hard to understand, especially if you're not a minority of any kind, because you haven't felt it. That's OK: you might not 'get it' and it might sound weird/paranoid to you, but that's because you haven't lived it. There is no shame in not understanding, but don't let that lack of understanding lead to a lack of believing. I don't know what it's like to be a man aiming your pee at a stain on the urinal, and it sounds ridiculous to me, but I believe y'all when you tell me it happens.
Don't constantly bring up gender: Did you know that reminding someone of negative stereotypes against them worsens their performance? It's a known phenomenon called stereotype threat. I know how it seems to you: "I'm lifting her up! Pointing out that she's got it, despite being the only woman on our team!". It is not lifting her up, it is reminding her that she is alone and that there is an implicit expectation that she will do poorly. Calling her a pioneer or a trailblazer is probably historically inaccurate, slightly patronising (she's just doing her job, after all...), and also puts a lot of pressure on her. Ever read this xkcd comic? You're doing the same thing in reverse. The woman you work with is not responsible for representing all women everywhere, and putting that on her makes her less likely to be ready to admit mistakes, learn, and grow. At the same time, she's more likely to make those mistakes because she wants to be perfect so she can "prove" that women aren't shit at tech.
Actively compliment women's skills: Anyone who has followed me for a while knows that I'm a big fan of giving genuine compliments to everyone, but it is especially important for women to know that they are being recognised for their skills, results, and technical knowledge, and not just for how they look.
Call out sexism when you see or hear it: It is hard to be the party pooper, to be the awkward one to ruin the mood. Sorry, but you have to call out sexist talk when you hear it. It sucks. It's hard. It feels super awkward. But it is worth doing because it stamps out a culture that can fester into something truly putrid for your women colleagues. There are also many, many cases of women being pushed out of jobs for "lack of culture fit" when they speak up about these issues: so take the task off their hands. If you're not sure how, try: "Come on, you know better than that" or "Don't be that guy". If neither of these gets the point across, then try "How do you think that kind of talk makes our women colleagues feel?".
Talk openly about your salary: So you're confident everyone in your workplace is being paid appropriately based on their experience? Great! Then there should be no problem talking openly about salaries. Honestly, this is a good thing for all workers regardless of gender, but if you keep this habit as you move up through the ranks you might be surprised at how different those numbers can be. Even if you believe that these differences come down to salary negotiation skills, you being open about your income could give a female colleague the push she needs to ask for what she's worth.
Give credit where credit is due, even if it hurts you: I really, really hope this situation never happens to you, but if you are about to get praise for an idea that sprung from the mind of a female colleague, please do the honourable thing and say that to your manager, director, colleague, whoever is paying you the compliment. Too often, women's ideas are coopted by others and she doesn't receive the credit she's due. If somehow you end up being the benefactor, then you can be a good ally by owning up to it: even if that means your wallet might take a hit. Sure, it's not your fault someone got it wrong: but it is your fault if you don't set it right.
Watch out for jokes that sting: You know the kind of jokes I mean, and you can probably see the women around you tighten their lips, fidget awkwardly, or suddenly be distracted by their phones or something outside the window. Plenty of women won't say anything: that doesn't mean they're comfortable. You need to shut these jokes down. Not only is it the right thing to do, but it takes the pressure off the women in your workplace, because most likely they feel awkward about saying anything for fear of being branded a "bitch", a "nag", or "difficult". If you accidentally said a sexist joke or overstepped the lines of professionalism yourself, then the best thing you can do is to openly apologise (not just to the women, but to anyone present) and commit yourself to not doing the same again.
When you do these things, don't put it back on the women around you: Listening to women's voices and opinions is not the same as forcing them to speak to others about issues of equality. Just because Miriam told you over coffee that she's sick of Jeff's jokes, that doesn't mean calling out Jeff's jokes and ending on "Right Miriam? I know you're sick of them!". Do your best not to put women into awkward positions professionally or socially. Your heart might be in the right place, but remember this is about making women feel more comfortable in the workplace.
Bonus tip: Follow women in tech on Twitter, LinkedIn, Instagram, blogs, etc.: This is an easy one to do and let's face facts: you're doing it right now! Amazing! Go out of your way to find women to follow, ensure you're hearing their voices, try reading books about these issues, and how tech is not an objective industry run by objective people working with objective data.

Not sure where to find women in tech to follow on Twitter? Try starting with some of the women in this thread:

// Detect dark theme var iframe = document.getElementById('tweet-1338235894176882692-844'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1338235894176882692&theme=dark" }

Some parting words... You have power.

If you are a man or a person of any gender in a position of power at a workplace, then your voice is going to be heard in a way that is different to a woman who is a junior developer, for example. You might say the exact same things, but where she's seen as a PITA, you're seen as 'woke' or a 'bleeding heart' or 'defending your colleagues' or similar, depending on who you ask.

Please use this power for good. Back up your women colleagues, listen to them, ensure they are heard and valued for the right reasons. Don't put pressure on them to represent women everywhere. In the end, most women just want to do the work, have a good time with their colleagues, and not have to be bothered by reminders that they are still, in 2020, often stereotyped as less capable.

The time has come for all of us, and particularly men, to stop saying it's all fair, and start making sure it's all fair.

What Is A Variable? | JS in <3

Anna J McDougall — Mon, 07 Dec 2020 19:41:10 +0000

Follow me on Twitter

One of the earliest hurdles to jump over for JavaScript beginners is the concept of a variable. In this blog post accompaniment to my JS in <3 YouTube Series, I'll go into a bit more detail about what variables are and how we use them.

Introduction: "The book is good!"

Imagine the following conversation:

Anna: I'm reading a book at the moment.
Friend: Oh?
Anna: Yeah, the book is called Clean Code and is about ways of making code more readable. I heard about it online and decided to buy it.
Friend: Do you like the book?
Anna: Yeah the book is good but there are some confusing parts.

Now yes, this conversation is a bit clunky, but it's designed to show how we already use structures similar to variables in everyday life. After I mention the name of the book, I don't need to mention it again: instead, I simply say "the book" or "it".

Similarly, JavaScript variables are ways of naming certain values so you don't have to explicitly state them over and over again later.

Variables are labels representing pieces of information

Here is a simple example of using let to assign the value "Hello" to a variable called greeting.

let greeting = "Hello";
console.log(greeting);

EXAMPLE 1 "My Mum": Different variables and constants can hold the same value

There is no restriction on how many variables (or constants) can hold the same piece of information. My mum's name is Virginia, but she isn't only called Virginia. I call her "mum", my daughter calls her "grandma", and I also have a nickname for her which is "marzipan". This common concept can be expressed in JavaScript as such:

var mum = "Virginia";
const grandma = "Virginia"; // This is technically a constant and not a variable! Be careful!
let marzipan = "Virginia";

console.log(greeting, mum); // Logs "Hello Virginia!"
console.log(greeting, grandma); // Logs "Hello Virginia!"
console.log(greeting, marzipan); // Logs "Hello Virginia!"

If we wanted to do a strict comparison of these terms, the program would tell us they are identical. Just as in real life, they are all the same person.

console.log(mum === marzipan) // Logs TRUE

EXAMPLE 2 "The Report": Variables can change (vary) depending on context or results

Another way in which variables can be similar to natural language is the way in which their meaning can change over time.

For example, I might be talking about my previous work for Australian Associated Press, and mention a report that my boss received each day about the news. In the context of this situation, "the report" refers to that summary.

var theReport = "A 10 page summary of the news today";

Later, I read a news article about something and notice a different report. Suddenly, 'the report' has a different meaning for me.

theReport = "A legal case against the Prime Minister of Australia";

Years later, working in project management, I hear about a report a client is working on. This time, "the report" is referring to an environmental impact statement which has to be submitted for minesite approval.

theReport = "An environmental impact statement";

Similarly, JavaScript allows us to redefine and update variables according to context, or depending on the results of different processes. This means we can use variable names like result or count which can change over time. As long as we use let or var to define them and are within the scope of those variable declarations (more on that concept later: don't worry if it doesn't make sense now!) then we can reuse and update them as needed.

Understanding Private Variables in JavaScript Class Constructors

Anna J McDougall — Wed, 04 Nov 2020 09:35:35 +0000

Follow Me On Twitter @AnnaJMcDougall

This week, my class has been looking into factory functions and classes. Naturally, the topic of 'private variables' came up, and has been a source of much confusion. To me, this confusion is similar to the confusion over Closure, which I addressed in a recent blog post: we use them instinctively, they make total sense to us, but when they're given a name we suddenly feel confused and wonder if we don't really get it after all.

So if, like me, you hear the phrase 'private variable' and you begin to sweat, then let me help clarify what we're talking about and why you probably already use them.

Let's set the scene

Let's create a simple User class in JavaScript which will form the basis for our examples:

class User {
   constructor(name, age, favNumber) {
      return {name, age, favNumber}
   }
}

let firstUser = new User("Anna", 33, 7)
console.log(firstUser.name) // logs "Anna"

OK, so we have a super basic class which returns the parameters as properties of the object we create.

Side note: Returning parameters within the constructor

You may have noticed in the third line above, that I opted to simply return the parameters in the constructor. This is the same thing as:

this.name = name
this.age = age
this.favNumber = favNumber

These return values also come in handy later, and for me help me visualise what I'm making 'public' vs what I'm making 'private'. It also helps save some typing, and I'm always in favour of lazin-- uhh, efficiency.

What is public? What is private?

In the above code, all of our parameters are 'public'. Now, don't let the standard ideas of public and private confuse you: we are referring here to the global scope. We can type into the global scope firstUser.favNumber and we will get 7, because favNumber is being returned. In this instance, name, age, and favNumber are all public.

So let's create a private variable, a super secret magic number using our super secret Formula For Success™.

class User {
  constructor(name, age, favNumber) {
    let superSecretNumber = Math.round((age * favNumber) / name.length);
    function logOutcome() {
      console.log(`Wow! Your secret number is ${superSecretNumber}`);
    }
    return { name, age, favNumber, logOutcome };
  }
}

let firstUser = new User("Anna", 33, 7);
console.log(firstUser.name); // logs "Anna"
console.log(firstUser.superSecretNumber); // WHOMP WHOMP: 'undefined'
firstUser.logOutcome();  // logs "Wow! Your secret number is 58"

Voila! That's a private variable in a JavaScript class: superSecretNumber, which we cannot access from the global scope. Trying to log firstUser.superSecretNumber gives us undefined. However, we can also use a Closure (again, read my blog post if this is shaky ground for you) in the form of the logOutcome function, which accesses this private variable and uses it in some way (in this case, by logging it with a message). If you imagine a much more data-sensitive algorithm, you can see how protecting variables in this way is extremely important.

superSecretNumber is not accessible anywhere else in your code, and if you log your object in the browser or elsewhere, you won't see superSecretNumber anywhere in the list of properties. It is hidden from 'public' view. Of course, it is still public in the sense that if someone downloaded your code and read through it, they would see you defining the variable and how you did it: this is why it's important not to take your usual/normal understanding of public and private in this instance.

One last convention worth noting

Take it or leave it, but it is convention to use an underscore _ in front of private variables. So in the above example we would name superSecretNumber as _superSecretNumber instead. There are some libraries that work with this convention so it's worth noting and building into your habits.

Seriously though, what is Closure?!

Anna J McDougall — Wed, 04 Nov 2020 09:07:33 +0000

Follow Me on Twitter @AnnaJMcDougall

Closure: it's not only what you need when a relationship ends, it's also something you need to understand when coding in JavaScript. Unfortunately, it can be a tough thing to explain to those new to programming, and since I only recently feel like closure has 'clicked' for me, I've decided to write a short article to explain it in ways other newer coders can understand. I hope this helps someone out there!

If you can write basic JavaScript functions, you have almost certainly already used closures without even realising it. In fact, for the longest time my main complaint about understanding 'closure' has been: "Isn't that just basic programming? Why do we even need a name for it?". Despite my protestations, I've been assured time and again that this is "a thing" and you need to know it, so let's stop dilly-dallying and get into it.

The basics of scope

Firstly, let's take a step back and think about the concept of lexical scope, which tells us which variables are accessible at any given time. Consider the following code:

function add (a,b) {
   let sum = a + b
   return sum
}
console.log(sum)

You probably already understand that the reason the above doesn't work is that we can't access sum because it exists only within "the world" of the function add. This "world" is known as scope, and it is created by our darling curly braces { and }.

Accessing scope from within and "local binding"

"Local binding" is just a fancy pants way of referring to variables declared within the scope of a function. In other words:

function funkyTown(){
   let localBinding = "this is a local binding"
}

Let's expand on this a bit: if we know that we can access local bindings anywhere within the "world" of a function, then we can add a line like this:

function funkyTown(){
   let localBinding = "this is a local binding"
   console.log(localBinding)
}

funkyTown()

Does the above function call log to the console? YES. We can access localBinding because we're still within the existing scope of our funkyTown function.

Wouldn't you know it, the above example also includes a closure! Our console.log is a function which references a local binding in an enclosing scope (whew!) and is therefore considered a closure.

"Closure" vs "A closure"

I'm going to just to a straight copy-paste from an excellent online resource, Eloquent JavaScript, which clarifies the situation in just a few words (emphasis mine):

"Being able to reference a specific instance of a local binding in an enclosing scope—is called closure. A function that references bindings from local scopes around it is called a closure." - Eloquent JavaScript Chapter 3

In other words, closure as a concept refers to the ability and idea of referring to variables which only exist within the "world" they were created: the scope created by curly brackets. Since we cannot access these variables from outside that scope, closure can only exist from within it. As I mentioned earlier: you have probably known that you can only access variables within their own scope for a long time, but now you know that the ability to do so is called closure.

To expand on this even more, a closure therefore refers to any instance in which you use the above ability in a function. Any function which references variables existing only in its enclosing scope, is itself a closure.

One more example for the road

Since this article is aimed at beginner-to-intermediate learners, I won't dive too deep into the ways in which we can use closure more complexly, I'll just pop another example of a fairly simple closure in here.

 // a function which will only divide even numbers
function divideEvens(num, divider) {                

   // local binding
   let isEven = (num % 2 === 0) ? true : false;   

   // a closure function
   function doDivision() {                

      // references to local bindings                     
      return (isEven) ? num / divider : null;           
   }

   // uses the inner function to refer to local bindings 
   return doDivision()                                          
}

console.log(divideEvens(24, 4))           
// logs 6

Of course the above is not the best way to implement the goal of the code, but simply acts as a verbose example.

Conclusion

As a programmer, you will frequently define and refer to variables from inside the scope of a function. As you do so, and as you use and reuse those variables in that "world", you are unknowingly utilising closure to your advantage. There is a difference between closure as a concept, and 'a closure' as a piece of code utilising that concept. Using closures is an everyday part of programming, and although knowing the name for it sometimes seems a bit odd, you can hopefully now see why they're important and give a relatively simple explanation of them if needed.

How to Give Good Compliments

Anna J McDougall — Mon, 26 Oct 2020 20:43:41 +0000

Follow me on Twitter @AnnaJMcDougall

Delivering genuine, meaningful compliments is a skill fundamental to friendship, family, romantic relationships, and even your work life. The majority of people are spending far too much time worrying about what others think, and far too little time telling others what they think. If we all balanced this out a little, then maybe there'd be a bit less anxiety and confusion in the world.

Last year, an old friend of mine came to visit me in Germany, and as we were sitting having dinner I turned to him and said: "I just want you to know that I am always impressed with how consistently you see your friends. You always make a real effort to see people and follow them up, and it is something I've always admired". I will never forget the look on his face as he thanked me and told me how much it meant to him to hear someone say that. After so many years of meticulously scheduling and catching up with his plethora of acquaintances, nobody had ever just stopped to tell him that they noticed the effort.

Insofar as personalities go, I'm a little on the paranoid side. The better my life seems to progress, the more sure I am that everything is about to go terribly wrong. I've learned to live with this darker personality quirk of mine, but in some ways it has given me good habits. One of those is to always end interactions as positively as possible. I am haunted by the idea of someone I'm close to dying without them knowing how much I love them, and I therefore make an effort to keep that love front and centre in every interaction I have.

Unfortunately, most of us are in the unfortunate habit of not complimenting people we admire in our everyday life. In this article, I'll run through why we tend not to give compliments, when we should give compliments, how to give a compliment, and lastly what not to do.

Why didn't I tell him I loved him?

The majority of people are not spending their social interactions complimenting the people they admire. Let's cover the reasons I've noticed people don't give compliments, and why you shouldn't pay them too much mind.

"They already know what I think/feel"

In a way, this is the easiest to talk about because it is absolutely not true. Every single type of relationship and the communication therein has to revolve around one simple concept: We cannot read minds.

Not only do you not know what someone else is thinking, but they can't know what you're thinking either. Human beings are also pretty terrible sometimes at interpreting others' actions. Have you ever stared too long at a text message which says "OK." and wondered what on Earth it means? Have you ever sent an "OK." and assumed the other person 'got the message'? Do you see how much conflict and confusion this one, simple example can cause?

Never, ever assume that other people already know what you think about them.

"It would be awkward to say"

My husband is the best complimenter I've ever met. Before meeting him, I probably would have agreed with the above statement. As time went on though, I saw how people really responded to genuine compliments: smiles, thanks, a feeling of being 'seen'. People leave interactions with my husband feeling confident, secure, and reassured that the effort they go to is paying off.

I have to admit: compliments do not come as naturally to me. Despite that, as with any skill I have practised and continue to improve, not once has someone seemed confused or freaked out by me noticing their efforts. This is just one of those things you will have to trust me on: even if something feels awkward for you, that doesn't mean the other person feels the same way. Practice is something which helps here: both in terms of 'technique' (which we'll cover later) and in terms of feeling comfortable with your new skill!

"I don't want them to take it the wrong way"

The fear that someone will misinterpret your compliment as a romantic advance is valid, as there is always scope for people to misinterpret any form of friendliness in this way. That said, if you stick to my guidelines below, you should find that this isn't a major problem. I would add that if you're ever unsure if someone will misinterpret your compliment, then avoiding physical touch and adding "Good job" or "Good work" is a great way of ensuring your words aren't misconstrued. I don't know about you but I've never said "Good work" while trying to flirt with someone!

What do I even say?

I'd like to answer this question with a thought experiment. Think of someone you've known for a significant amount of time, let's say over a year or two. For the sake of this example, let's call her Sally. Your new friend, Bob, is meeting you for coffee one day and he says: "Hey I met someone called Sally the other day, I think you know her? Ugh I just can't stand her. Why are you two even friends?".

How would you answer Bob?

The above will tell you everything you need to know about what kind of compliments you should be giving Sally. Does she make you laugh? Is it that she always knows how to cheer you up? Or is she always insightful about issues you used to think were simplistic? Maybe it's because she is great at networking, or because she saved your ass in that meeting where you almost quit in frustration. Chances are, you know what you like about your friends and family: So tell them!

When do I deliver compliments?

I'm going to refer back to my husband again on this one. He is an amazing listener and will extrapolate from peoples' stories why they feel a certain way, based on their character traits.

The most meaningful time to deliver a compliment is when it's relevant to the recipient's life or story.

Let's say Sally is talking to us about a frustrating situation at work where she felt nobody was listening to her, this could be a good time to tell her about that trait we mentioned earlier, and say: "That sounds really frustrating, especially since you always seem to have something insightful to share. They really missed out on your perspective. I don't know if I've ever told you, but I really value the way you make me think differently about issues I used to think were simplistic."

BOOM! You just delivered Sally a compliment that is not only true, but is also relevant to her current situation and is highly likely to make her feel better about a crap day at work.

If in doubt, blurt it out.

Of course, situations like this don't always come up. If there's someone in your life whose presence you really value, it might be worth just spitting it out. In this day and age, with so many different forms of communication around, you really don't have any excuse. Furthermore, if you're more comfortable with the written word, then this can be a good way to practice.

The upside: you can carefully craft exactly how you deliver your compliment, and you can do it any time.
The downside: you miss their reaction, and they might curate their reaction to be something underwhelming.

For example, you might just decide to message Sally out of the blue and say: "You know I was just thinking about that time John broke up with me, and you really cheered me up. I'm not sure if I ever thanked you for that: you always know how to bring a smile to my face, and I really think that's amazing."

Now Sally is not expecting this. She probably appreciates it, but it won't have the same impact as our earlier example. Furthermore, because these are (unfortunately) rare messages to receive, she might respond with something like "Thanks :)". Don't be surprised if people do this: they are also thinking about how they come across, and they don't necessarily want to seem overly appreciative of attention.

How do I give a compliment?

If the above examples all seem relatively straightforward to you, then you might want to just skip this part. However, I know a lot of people need these things really, truly broken down into actionable steps: so let's do that! If you follow these steps, you should be able to deliver a meaningful compliment that doesn't come off as imposing or creepy.

1. Use a 'soft open'

For example, the following phrases:

"I just thought I should say..."
"I'm not sure if I've ever told you, but..."
"Has anyone ever told you that..."
"You know, you just reminded me to tell you that..."

These phrases make the compliment seem more incidental rather than planned to achieve some sort of manipulative end. Real compliments exist to express real feelings of gratitude and appreciation towards each other, not to achieve an end. In other words, a soft open helps take the pressure off.

2. Relay a true, positive impression you have of the person

This is the 'compliment body', so to speak. The important thing here is to focus on something which is absolutely true, and absolutely positive.

If you're in a work environment and/or trying to avoid romantic or sexual connotations, steer clear of physical traits. Focus on things the person does, says, or achieves.

Another thing to avoid is bringing others down to achieve the compliment: "You are such a positive force to be around" is much more powerful than "You're so much nicer than Clare". Don't bring any negative feelings into it or drag anyone else down: keep it a positive interaction!

A note on lying: Sometimes, you want to cheer someone up and so you try to fabricate a compliment in the moment. Don't do it. It will come back to bite you. Sincerity is the core of a good compliment.

3. Relate the compliment to an event or experience you had with that person (Optional)

If there is an example of a situation in which the above trait can be seen in action, talk about it. People always like to know that their efforts have been noticed.

As with the Sally example above, you can relate the compliment either to things which have happened in the past, or things which are happening right now.

4. End with a 'soft close'

For example, the following phrases:

"Anyway, I just thought you should know."
"I thought it was important to let you know that."

As I mentioned earlier, if you're in a work environment, giving some sort of review, or are looking to avoid any misunderstandings, a quick "Good job" or "Keep it up" is a great way to wrap up the chat.

Homework for the next seven days

The best way to improve any skill is to practice! Here are some ways you can put this into action. Try to use the above format, and think about how the core of what you say might change depending on who you're talking to.

Not all of the below will be relevant to you but pick out the ones which are and put them into practice in the following week:

Level 0: Compliment an inanimate object
Level 1: Compliment a pet or child
Level 2: Compliment me in the comments section
Level 3: Compliment a casual friend
Level 4: Compliment a workmate
Level 5: Compliment a parent, close family member or long-term friend
Level 6: Compliment a romantic interest or partner

Follow me on Twitter @AnnaJMcDougall

5 Tips for Learning Grid

Anna J McDougall — Tue, 11 Aug 2020 13:23:22 +0000

Follow Me on Twitter @AnnaJMcDougall

When it comes to structuring your webpage using HTML and CSS, the most commonly used instruments are Flexbox and Grid. This week, my course has been covering Grid in a bit more detail, and I've had a chance to hear several points of confusion among those learning it for the first time, so rather than step you through how to implement Grid, I've decided to drop five tips for understanding it better, which will help you wrap your head around this effective and important concept.

For what it's worth, if you do want a step-by-step guide, I can highly recommend A Complete Guide to Grid. I keep this open in a tab every time I'm working with Grid so I have a quick reference to work with, but the first few times you use it you will probably have to go through it section by section. If you're already familiar with Grid and want to get a bit of practice in with the 'span' property, try out this fun CSS Grid game where you use Grid properties to water a garden.

Now that we've covered that and already gotten two resources under your belt, let's have a look at what you need to understand about Grid:

Grid is used to structure an entire page
What properties apply to containers, and what properties apply to inner elements
Grid works in two directions, Flexbox works in one
You can name Grid areas to make styling easier
It is common practice to use Flexboxes within Grid

...plus I've added one bonus tip at the end to keep your code readable, beautiful, and useful to everyone who visits your site.

If you can understand these Grid tips, and use them to guide the structure of your pages, you will find structuring your pages far easier and your code will be cleaner and more maintainable in the long-term.

1. Understand that Grid is used to structure an entire page

The main use for Grid is the structuring of entire pages. Before the advent of Grid (or Flexbox), the structure of a page would have to be achieved entirely using HTML. This is how coders like me as a little girl learning HTML in the 1990s came to love iframe and table elements, since they represented one of the few ways to give a website structure and form.

Now, you have this amazing tool which can order your elements into a neat structure. Consider yourself very lucky!

Although Grid does allow you to position individual elements, the best way to use it is to structure an entire page. Here is an example of how that can look:

In Grid, this would be a six-cell grid of three rows, and two columns, with the header and footer spanning two columns:

By using Grid, we can secure this structure and know that nothing will shift around on the page.

2. Be clear on what applies to containers, and what applies to inner elements

One of the most common beginner problems when learning Grid is becoming confused as to what properties apply to the grid container vs grid elements. Here are some quick guidelines:

display: grid only applies to the grid container
Any grid properties which apply to the site as a whole should be placed on the container
Anything applying only to a specific box (e.g. anything ending in -self, or grid-column/grid-row) applies to the individual grid element styling

3. Grid works in two directions, Flexbox works in one

It can be confusing as a newcomer to distinguish between Flexbox and Grid. It's true that with mobile design becoming increasingly prioritised, that flexbox is often used for overall page structure, so why does Grid exist? What is the difference?

Simply put, Flexbox works in one direction (either row or column) and if you want more than one element to fill a Flexbox row, for example, you have to specify the width or flex-basis for each element.

In Grid, structural width and height specifications are done as part of the container styling, rather than on individual elements, giving you one place to see the entire structure of your page. In that sense, it is much simpler to have a clear overview of your page structure. For example:

#container {
   display: grid;
   grid-template-columns: 150px auto 300px;
   grid-template-rows: 50px auto 50px;
}

Here, the column widths have been set: 150px on the left, 300px on the right, and the centre space will fill what's left. Similarly, the rows have been set too: 50px on top, 50px on the bottom, and the centre will fill what remains.

To get this same effect in flexbox, you would either need four containers (e.g. one column container and three individual flexbox rows) or you would need to use flex-wrap in combination with specific block sizing. It can get very messy, and using Grid can save you a lot of time when you're after a structure like this.

Put simply, Grid works in two directions and the basic structuring is done in the container element, whereas Flexbox works in one direction only and any structuring beyond that needs to be implemented on the individual elements.

4. You can name Grid areas to make styling easier

To expand on the point about Grid being easier to 'see structure', there is a great feature of Grid which allows you to name Grid areas so that it becomes easier to 'target' certain Grid areas in your CSS.

Here's an example from the structure we saw above:

#container {
   display: grid;
   grid-template-areas: 
      "header header"
      "sidebar main"
      "footer footer"
}

Even without looking at your page, you can already see in your CSS what layout you're using. To 'connect' an element to its corresponding grid area, you can use the grid-area property and simply use the name you gave that section.

For example:

header {
   grid-area: header;
}

footer {
    grid-area: footer;
}

As you can see, this is far easier to read than using row- and column-line indicators or span sets.

5. It is common practice to use Flexboxes within Grid

With all this discussion about the differences between Grid and Flexbox, you might be tempted to think that the two shouldn't mix. This is absolutely not the case! It is common practice to use Flexboxes within a Grid structure.

Taking our earlier example, the header and footer could each be Flexbox containers with the flex-direction: row property, while the body and sidebar could be Flexbox containers with the flex-direction: column property. Let's see how that would look, using blue arrows to indicate flex direction within each section of the page:

Additionally, our individual main content sections could also use Flexbox with flex-direction: row to position the image and text combination. Here red arrows indicate those Flexboxes:

6. BONUS TIP: You should still use semantic HTML elements with Grid

When looking at Tip 4: You can name Grid areas to make styling easier, you might think this means you can avoid using semantic HTML elements such as <main>, <sidebar>, <nav>, etc. It is still a good idea to use semantic elements, regardless of Grid area names. That's because systems such as screen readers don't actually interrogate Grid styling as structural guidelines for those with impaired visual acuity. That kind of assistance can only be rendered from the actual HTML skeleton of the page.

In addition to that, when looking back at your code (or having others review it), it is far easier to get a 'feel' for what is happening by using semantic HTML elements rather than just gazing confusedly into a sea of <div>s.

So please keep using semantic HTML tags regardless of your Grid structure!

An Easy Trick to Stop Apologising

Anna J McDougall — Mon, 10 Aug 2020 12:17:50 +0000

Follow Me On Twitter @AnnaJMcDougall

Have you ever met someone who kept apologising for every question or favour they asked? Perhaps you are that person and you can hear yourself saying "sorry" over and over again for basic and normal requests which really don't need an apology. It is annoying for everyone involved and usually, the person apologising is just in such a habit of doing it that a gentle "No need to apologise" or even "Please stop apologising" won't actually lead to any change.

I heard a great tip a few years ago which could help you escape this annoying habit, and lead to better relationships with colleagues, friends, and superiors. This tip helps avoid a weird power dynamic where you put yourself in the position of someone begging or being needy, and changes it into a collaborative, positive space. In my opinion, it not only helps others respect you more, but leads to you respecting yourself more.

Replace 'sorry' with 'thank you'

We know that replacing bad habits is easier than removing them completely, so every time you feel the urge to apologise for something unnecessarily, try to rephrase it as a thank you. This puts you in a better headspace, but people also feel a lot more comfortable accepting thanks than accepting unnecessary apologies. As said, it also turns a generally negative feeling and frames it positively. You're still showing gratitude without begging forgiveness for an everyday request.

Anna "Apero" McDougall 🏳️‍🌈

@annajmcdougall

Needless and constant apologising can be frustrating for all involved, and can lead to weird power dynamics. Asking someone to "stop saying sorry" is usually ineffective.

Here's the tip that helped me break this habit and never look back:

Turn "sorry" into "thank you"!

12:02 PM - 10 Aug 2020

Here are some examples:

Instead of	Try
Sorry for the inconvenience	Thank you for your time
Sorry you had to wait so long	Thank you for your patience
Sorry to ask, but...	Thanks for seeing me, would you mind telling me...
You helped me so much, sorry	Thank you for helping me so much

These are just a few examples. For me, "thank you for your time" was the most valuable and easy to implement in a variety of situations.

If you try to utilise this technique in your everyday life, you'll see that not only do people respond a lot better to your requests and explanations, but you'll also walk away feeling more like you collaborated, rather than grovelled.

Disclaimer: This advice does not apply for when you truly should apologise. If you hurt someone (even accidentally) or do someone wrong, you should apologise. The above is only applicable when you are in the unfortunate habit of apologising for normal requests.

DEV Community: Anna J McDougall

How to Support Junior Developers

Introduction

1. Define expectations and timelines

2. Emphasise trust

3. Provide choices

4. Avoid "Easy", "Simple", "Basic", and "Obviously"

5. Avoid solving problems for them

6. Ask questions

7. Review tickets with "Why?"

8. Give regular feedback

9. Go beyond technical conversations

10. Ask for regular feedback

Conclusion

How I Became a Junior Software Engineer in Under a Year

1. Early Interest

2. The Floating Thought

3. The Push

4. The Test Run

5. The Course

6. The Job Search Begins

7. The Video aka THE AVALANCHE

8. The Winner

9. Onwards and Upwards

Lessons and Conclusions

Interact with the Command Line using "process.argv" in NodeJS

What is the process core module?

What is argv?

Reading and Writing Files/Directories in NodeJS Using the FS Core Module

A note about asynchronous code

Asynchronous callbacks in NodeJS

Setting up a path variable

Using fs.mkdir to Create a Directory

Using fs.readdir to Check the Contents of a Directory

Using writeFile to Create a New File or Append Text

Using fs.stat to Check Your File Details

"What does it mean to write/run a server?" Answering My Own Questions About NodeJS

1. I thought a server was a physical piece of hardware. What does it mean to write/run my own server?

2. Why do we need NodeJS to do this stuff?

3. Is this the same as web hosting services?

4. Do I have to pay to run my own server?

5. What is the relationship between NPM and NodeJS?

6. OK fine, so we can do lots of stuff with NodeJS but... What, exactly?

Conclusion

Ten Tips for How YOU Can Make Your Workplace Friendlier for Women

Ten Tips for Making Your Workplace Friendlier to Women

Some parting words... You have power.

What Is A Variable? | JS in <3

Introduction: "The book is good!"

Variables are labels representing pieces of information

EXAMPLE 1 "My Mum": Different variables and constants can hold the same value

EXAMPLE 2 "The Report": Variables can change (vary) depending on context or results

Understanding Private Variables in JavaScript Class Constructors

Let's set the scene

Side note: Returning parameters within the constructor

What is public? What is private?

One last convention worth noting

Seriously though, what is Closure?!

The basics of scope

Accessing scope from within and "local binding"

"Closure" vs "A closure"

One more example for the road

Conclusion

How to Give Good Compliments

Why didn't I tell him I loved him?

"They already know what I think/feel"

"It would be awkward to say"

"I don't want them to take it the wrong way"

What do I even say?

When do I deliver compliments?

The most meaningful time to deliver a compliment is when it's relevant to the recipient's life or story.

If in doubt, blurt it out.

How do I give a compliment?

1. Use a 'soft open'

2. Relay a true, positive impression you have of the person

3. Relate the compliment to an event or experience you had with that person (Optional)

4. End with a 'soft close'

Homework for the next seven days

5 Tips for Learning Grid

1. Understand that Grid is used to structure an entire page

What is the `process` core module?

What is `argv`?

Using `fs.mkdir` to Create a Directory

Using `fs.readdir` to Check the Contents of a Directory

Using `writeFile` to Create a New File or Append Text

Using `fs.stat` to Check Your File Details