DEV Community: Anna Wijetunga

That First Ticket

Anna Wijetunga — Wed, 11 Dec 2024 15:06:21 +0000

Originally posted with aware3 in 2020. Reposting now for posterity :)

Life in any new job can mean a lot of on-the-spot learning, questions, and stumbling. As a former educator transitioning into tech, life as a brand new Software Engineer felt all the more foreign.

Some of my very first questions to myself:

Sweet! I now have a laptop and an external monitor — oh boy, where exactly did my cursor go!?

Why can’t I stop thinking of boats whenever I hear the word Docker?

Is this the part where everyone finds out I don’t really know what I’m doing?!

Truth be told, my first few days of virtual onboarding and meeting my new team (my new team!) were a treat. New beginnings can be absolutely beautiful.

But what I really, really, really wanted to know was the answer to the very question I asked everyone else when I was job hunting:

What’s a day in the life like? It all starts with a ticket.

Bugs and features. In my short experience thus far, I’ve learned that there are generally two types of tickets: bugs and features. You’re either fixing or building. For my first ticket, I was fixing. I needed to prevent text from spilling outside of a button.

A sea of code. Being brand new at your job means that each task is so much more than solving a problem. That sea of code — that’s what I was swimming in. For the first few hours, I was trying to orient myself. Look at the portal (app) in the browser, inspect some elements, find said elements in the code repo. Well, try.

Replicate. Back to the task at hand, after orienting myself a wee bit, I knew I needed to first replicate the issue. Find the button, see the text overflow, and figure out when it happens and why. Might I say, this part was a hoot!

Find the code. Once replicated, I knew I needed to find the code for that element in the repo. Figuring out what to search for was initially a roadblock, but trial and error proved effective.

Blank stare. I jest, but this was the moment I’d been waiting for. Me, Software Engineer Anna, at bat. After a bit of panic breathing, I thought back to the task at hand. Text, in a button, was overflowing. Overflow. Overflow properties. CSS.

Google. Yes, folks! Yes! Now that I knew what I needed to do, I searched for CSS properties and ways to keep text inside a button and prevent overflow.

Educated trial and error. I knew a few properties that might do the trick, but now I had to compare the standards and styles of the code base at hand.

The other bits. Throughout that process, there were plenty of other tidbits that I picked up. When to start Docker and why it’s important, how to track progress in Jira, which version of Bootstrap we use.

Run the tests. There are tests to be run, to ensure that what I’ve built didn’t break existing code. There will be a time and place to get into the details (the details are great!) but for now I’ll say, testing really, really, really, really, REALLY matters and is a lot to get used to.

That first PR. Once tests are passing and the commits are made and pushed, it’s time to make the pull request. That gorgeous signal that you’re ready for your changes to be reviewed by another team member.

The next steps vary, but here’s what else happens once a PR is submitted. Someone else on the team will review it and leave comments for next steps. But don’t wait for that review — keep going. Either work on a new ticket, work on any other open tickets or pair up with a teammate to review what they’re working on.

And then rinse and repeat. Tickets, pairing up, testing, fixing, building — it’s a beautiful process to improve what exists.

Now that I’m in it and have experienced the day-to-day life of a software engineer, it doesn’t feel all that foreign to me. But while still at Flatiron or even while job hunting, it was THE thing I was most anxious to figure out.

If you’re out there and want to know more about the ins and outs of a day on the job, leave a comment below! Always happy to share.

Cheers, and thanks so much for reading.

Author: Anna Wijetunga, Associate Software Engineer

An Engineering Management Philosophy (i.e. How We Got Sh*t Done)

Anna Wijetunga — Tue, 06 Aug 2024 20:46:08 +0000

You know when something just works? And you don't want to mess with a good thing? Yup, been there. I'm there right now.

My engineering team moved off our tried-and-true engineering management practices in order to practice Scrum. I'm not mad about scrum but I am mourning the loss of the good times, and even if no one else gives a hoot, I wanted to share what made our system shine :).

An Engineering Management Philosophy

Humans are bad at estimating.

Estimates are inherently unreliable and should be treated with caution. You know I'm right!
Self-reported data cannot be trusted.
Validate and cross-check self-reported metrics.

Small user stories are key.

Encapsulate one definition of “done” in acceptance criteria.
Small scope limits risk and focuses engineers.
Break work down to enable each team (BA, QA, Dev) to build a stable, quality product.
Small changes allow for faster, more confident progress.

Author acceptance criteria on every ticket.

Look for "and" in the title to avoid combining tasks.
Use Tech Discovery and Tech Notes to limit scope early.
Utilize investigation tickets for unclear bugs.
Avoid promoting tickets that are actually multiple tasks.

Work categories.

Roadmap, Testing, Escalated, DevOps, Tech Debt.
Allocate weekly capacity percentages to each category.
Adapt percentages to meet stakeholder needs.
Predictably manage expectations outside engineering.

Ticket velocity.

Measure on an 8-week average.
Plan capacity to include pairing, training, learning, PR reviews.

Stakeholder meetings.

Align priorities every Friday.
Engineering provides capacity, stakeholders bring priorities.
Strategically choose tickets for “the plan”.

Mid-week escalations.

Allow off-plan blocker tickets.
Escalations should be discussions, not dictations.
Minimize disruptions through automated testing and technical debt reduction.
Proactively prevent issues before integration.

Sprint planning and accountability.

Capture prioritized tickets for upcoming sprint/week.
Hold accountable to commitments.
Capture and review off-plan solved tickets.
Use retrospectives to prevent future off-plan tickets.

Metrics and discipline.

Measure 8-week velocity per work category.
Visualize trends and coach teams to align with targets.
Deliver with precision against target percentages.
Resist stakeholder pressure to over-promote tickets.
Remove impediments to stay on plan.
Track metrics and maintain discipline.

The golden rule

Plan the work, work the plan.

Sigh. That felt great. Thanks for letting me get that all down on the page and relive the good times of high performance and rarely missing a delivery date.

In other news! THANK YOU for reading this far! If any of this piques your interest, contact me so we can talk shop. I'd love nothing more than to hear your engineering management philosophy and your take on mine.

Debuggin' Test Output

Anna Wijetunga — Thu, 07 Jan 2021 17:29:35 +0000

An Explanation
Tests are slippery things. Because code is constantly being updated, a test that passed with flying colors one day may fail with the latest merge.

Because of that, we're always looking for failures, but also for warnings.

Besides taking up space, warnings indicate an issue bubbling up. Best to figure it out now.

The Scene:
Test output for JavaScript(Vue).
All tests pass but output shows Vue warnings.

The Problem:
The warnings are bulky and clutter test output.
The issue behind the warnings needs to be fixed.

The Solution:
Think fast but GO SLOW.
Work through the warning, and trace it to the root.

Off to the Races - Where's My Horse?
Having learned to write tests only months ago, debugging test output seemed important and exciting but I was at a loss for how to solve this.

I channeled my inner Alan (test expert on my team) and knew I first had to slow down. Before I even thought about fixing anything, I had to find the test with those warnings.

1. Where are the warnings coming from?
From the CLI output, it looked like the warnings originated from this test:

But locally, that test had no warnings. Boo hiss.

I re-ran the tests, scouring the output as it was emitted, and I found the warnings under a different test:

2. Trace back the warning message.
The warning: WARN: '%cUnhandled rejection Error: cancel

I did two things here.

First, I read through the warning message (which was at least a dozen lines long) slowly and thoroughly, looking for any clues. Second, as another expert on my team says, I did some Googles.

From what I'd seen and read, I surmised that the warning had to do with promises.

3. Phone a friend.
Writing tests with promises is tricky business, so I called in our test expert, Alan. His experience and exposure to test writing has made him an incredible source and teacher.

We looked at the tests together and noticed a few methods: open() and cancel().

We traced them to the component itself (vs the test):

    methods: {
        open() {
            if (this.modalOpen) {
                return this.deferred.promise;
            }

            this.modalOpen = true;
            this.deferred = this.createDeferred();

            return this.deferred.promise;
        },

        cancel() {
            this.modalOpen = false;
            this.resetForm();
            this.deferred.reject(new Error("cancel"));

            return this.deferred.promise;
        },

cancel() caught Alan's eye - specifically this part:

this.deferred.reject(new Error("cancel"))

This was our problem. Our warning message (WARN: '%cUnhandled rejection Error: cancel) contained the word "cancel" and that word was coming directly from within our cancel() method.

Finally, connecting the dots!

The other piece Alan knew (that I did not) was that for this particular test, we were using Bluebird (a third-party promise library).

And because of Bluebird, we know that an error will always be thrown.

And, we need to DO SOMETHING with that error - primarily catch it - or Vue will scream at us.

4. Mini celebration - we (ahem, Alan!) found the root issue.
Yay!

5. Back to the test.
There did not seem to be one perfect solution but many ideas to test out.

We first settled on wrapping our expect statement in a catch block:

app.vm.deferred.promise.catch( () => {
    expect(app.vm.hasError).to.be.false;
    done();
});

We re-ran our tests, et voila - warning messages disappeared.

6. Yee old refactor.
Although we did not end up refactoring, it's worth mentioning that there was great deal of discussion about possibilities. To avoid the chaining, to make the code cleaner, to stick to standards set elsewhere. All up for consideration.

In the end, the best solution remained our first solution, but it was a great lesson for me - there will always be pros and cons to the way we code/test.

Big Sigh, Happy Day
No two warnings are the same and debugging this stuff will always present a challenge. But there is hope. As test-expert-Alan kindly and wisely always says, "It's just a matter of practice."

Cheers to practice and cheers to more challenges.

If you have great practices for test debugging, comment below and let me know! And thanks so much for reading.

That First Ticket

Anna Wijetunga — Mon, 14 Sep 2020 13:52:26 +0000

Life in any new job can mean a lot of on-the-spot learning, questions, and stumbling. As a former educator transitioning into tech, life as a brand new Software Engineer felt all the more foreign.

Some of my very first questions to myself:

Sweet! I now have a laptop and an external monitor - oh boy, where exactly did my cursor go!?
Why can't I stop thinking of boats whenever I hear the word Docker?
Is this the part where everyone finds out I don't really know what I'm doing?!

Truth be told, my first few days of virtual onboarding and meeting my new team (my new team!) were a treat. New beginnings can be absolutely beautiful.

But what I really, really, really wanted to know was the answer to the very question I asked everyone else when I was job hunting:

What's a day in the life like?

A Day In The Life

It all starts with a ticket.

Bugs and features. In my short experience thus far, I've learned that there are generally two types of tickets: bugs and features. You're either fixing or building. For my first ticket, I was fixing. I needed to prevent text from spilling outside of a button.
A sea of code. Being brand new at your job means that each task is so much more than solving a problem. That sea of code - that's what I was swimming in. For the first few hours, I was trying to orient myself. Look at the portal (app) in the browser, inspect some elements, find said elements in the code repo. Well, try.
Replicate. Back to the task at hand, after orienting myself a wee bit, I knew I needed to first replicate the issue. Find the button, see the text overflow, and figure out when it happens and why. Might I say, this part was a hoot!
Find the code. Once replicated, I knew I needed to find the code for that element in the repo. Figuring out what to search for was initially a roadblock, but trial and error proved effective.
Blank stare. I jest, but this was the moment I'd been waiting for. Me, Software Engineer Anna, at bat. After a bit of panic breathing, I thought back to the task at hand. Text, in a button, was overflowing. Overflow. Overflow properties. CSS.
Google. Yes, folks! Yes! Now that I knew what I needed to do, I searched for CSS properties and ways to keep text inside a button and prevent overflow.
Educated trial and error. I knew a few properties that might do the trick, but now I had to compare the standards and styles of the code base at hand.
The other bits. Throughout that process, there were plenty of other tidbits that I picked up. When to start Docker and why it's important, how to track progress in Jira, which version of Bootstrap we use.
Run the tests. There are tests to be run, to ensure that what I've built didn't break existing code. There will be a time and place to get into the details (the details are great!) but for now I'll say, testing really, really, really, really, REALLY matters and is a lot to get used to.
That first PR. Once tests are passing and the commits are made and pushed, it's time to make the pull request. That gorgeous signal that you're ready for your changes to be reviewed by another team member.

The next steps vary, but here's what else happens once a PR is submitted. Someone else on the team will review it and leave comments for next steps. But don't wait for that review - keep going. Either work on a new ticket, work on any other open tickets or pair up with a teammate to review what they're working on.

And then rinse and repeat. Tickets, pairing up, testing, fixing, building - it's a beautiful process to improve what exists.

Now that I'm in it and have experienced the day-to-day life of a software engineer, it doesn't feel all that foreign to me. But while still at Flatiron or even while job hunting, it was THE thing I was most anxious to figure out.

If you're out there and want to know more about the ins and outs of a day on the job, leave a comment below! Always happy to share.

Cheers, and thanks so much for reading.

Keep the Marathon Going

Anna Wijetunga — Tue, 11 Aug 2020 19:51:00 +0000

I'm a runner, and I run marathons. It's a crazy thing to run 26.2 miles, but boy, do I enjoy it.

I will tell you that for a marathon, runners strategically plan their race. When to eat. When to drink. Each mile carefully paced.

I will also tell you that I always rely on marathon volunteers during the race. Those aid stations typically come every few miles and water never tastes so good.

And the crowds, my gosh! Crowds are my fuel and motivation to keep going. Usually, people yelling at me is my worst nightmare but in a marathon? YELL LOUDER.

This past May, however, I embarked upon a different kind of marathon.

The job hunt marathon.

The Starting Line

My job hunt marathon began in May after graduating from Flatiron and yes, there have there been so many ups and downs.

Those first few days and weeks were exhilarating. New schedule, new routines, and a brand new task ahead. Here I come, world!

Whelp.

Did you see it coming? Did you guess?

It didn't take long before overwhelm and uncertainty took over.

Am I spending my time the right way? Does anyone really want the skills I offer? What was I thinking changing careers?!

Thank goodness for those aid stations.

My Flatiron community! Tech Twitter! My coaches and mentors! My family!

I never had to sweat for long before finding a kind word, a gentle nudge of encouragement or guidance.

Rinse and repeat.

That cycle would repeat on a weekly basis, folks, and that's no joke.

I became so grateful for and relied heavily upon my aid stations, my community. They always helped me keep going in the right direction.

Something Incredible

You're about to find out that I've made it to a landmark spot in the marathon - the halfway point.

Mile 13.1

A band is playing an earsplitting rendition of Eye of the Tiger, confetti is flying, the crowds are WILD, and you feel you could just burst. Happiness, exhaustion, pride, all of it.

I am beyond honored and grateful to say that aware3 is mile 13.1 of my marathon.

They are graciously taking me on as an Associate Software Engineer.

Keep Running

The marathon's not nearly over, but heck if this isn't the motivation and support to keep going.

I can't believe I'm lucky enough to be a part of this, yes THIS, community. So grateful for the support that's carried me this far - can't wait to see what comes next.

If you're running your marathon and job hunting right now, leave a comment below! I always appreciated when folks would share with me how they found their job and what they learned along the way - would love to pay it forward!

What We Give

Anna Wijetunga — Mon, 13 Jul 2020 21:21:52 +0000

My cohort mates and I graduated from Flatiron in April. Such good eggs, they are.

A handful of those good eggs were as active as I was in our Slack channels, but not being tied to the curriculum any longer, communication was petering out (sad face).

Nelson, a cohort mate, suggested a study group to continue sharing resources, and I jumped at the chance.

Ultimately, my cohort mates and I wanted to code in front of each other because that is the most intimidating part about technical interviews (cue the cold sweats).

So each week, we choose a LeetCode problem, pair off into groups of 2 or 3, and we work through a problem together.

It's been a few months of our study group's Friday afternoon Zoom calls, and I have to say, this has been THE most impactful part of my week. Not to mention the best motivation to stay the course and keep practicing for those technical interviews.

Here's why.

Accountability

It can be so easy to make excuses for not coding.
It's much harder to make excuses when your gang's waiting for you.

Support

You're surrounded by like-minded individuals.
There's an abundance of positivity.
It's very hard to feel discouraged together.

Education

You get to watch other people code.
You get to compare notes and learn from each other.

Fun

Job hunting is stressful! THIS is not!
We laugh! We are friendly! We have fun!

Celebrations

We've, so far, seen 2 of our good eggs get hired! DID YOU HEAR THAT?!
This is a place to welcome good news, unconditionally.

One Last Thing

Having just finished The Splendid and the Vile (Erik Larson's book on Churchill), something Churchill said struck me:

"We make a living by what we get, but we make a life by what we give."

These good eggs who gather on Fridays, we are indeed a group who give. The sharing of time, resources, and kindness has not gone unnoticed, and our group continues to grow because of it.

(Well, except for the folks who leave to work their new, real jobs, but we forgive them.)

Are you looking to practice for interviews? We welcome you! Respond to this post, and I'll share the details for how you can join us.

Thanks for reading!

OAuth & Heroku Play Nice

Anna Wijetunga — Wed, 01 Jul 2020 18:22:34 +0000

Hosting my Rails app on Heroku was A Lot. But that story ended in success!

And yet, when I tried to log in using Google, no dice. My OAuth authentication that worked seamlessly prior to hosting on Heroku was now broken.

I won't tell you exactly how long it took for me to address this issue, but I will approximate: 2 months, shame on me!

My ever-patient-and-generous friend Noah helped me get the ball rolling, and I owe this guide and this knowledge to him.

In the event you are in a similar spot and need to get your OAuth authentication working on your hosted app, Godspeed and may this help.

Assumptions

1) You have built a Rails app with third-party authentication using OAuth.

2) You've already gone through the initial setup of Google APIs and created your original OAuth Client IDs - which you used within your app.

3) OAuth authentication is working when you host your app locally.

Start here

1) Go here: Google APIs.

2) In the left-side menu bar, click on Credentials.

3) There you should see the header, OAuth 2.0 Client IDs.

4) Create a new URI (and keep the existing).

https://your-app-url/auth/google_oauth2/callback

6) Save your updates.

7) You'll then need to set your google client id and secret, and you can do so within your terminal.

Run the following two commands:

heroku config:set GOOGLE_CLIENT_ID=yourclientid

heroku config:set GOOGLE_CLIENT_SECRET=yoursecret

It will set the id and secret and after each, restart the app.

8) Thought that would do it! But, login via Google continued to fail, and this time I received a semi-helpful error message about cross-site request forgery (csrf).

To combat this, I added the following to both my Users Controller and Sessions Controller - both of which deal with login:

skip_before_action :protect_from_forgery, raise: false

And that did the trick.

If you've given this a try, or even if you've figured out how to do this already, sure would love to hear about your experience!

Thanks so much for reading - until next time.

The Git Pull Guide

Anna Wijetunga — Sat, 20 Jun 2020 19:56:28 +0000

GitHub is powerful and often magical.

But learning the ins and outs has been stressful.

Recently my programming partner and I started building an app and realized, we had no idea how to contribute to a shared repo.

OH BOY.

A lot of trial and error led us to push and pull requests like we were born to do them.

Mostly to remind myself how to do this again (full disclaimer), but also to be a guide anyone else learning (kudos to you!), I present:

The Git Pull Guide

First and foremost, this guide was my saving grace.

But the reason I'm writing my own is that I varied from the above guide in a few ways to make it work for me.

Here's my take.

1) To fork, or not to fork?

The author of the original guide would advise you to first fork the original repo.

This caused me to pull my hair out (when I eventually tried to push changes to the original repo), so I did not do that.

A kind reader suggested the following perspective (thank you Jennifer Davis!), and I wanted to share it with you here:

"As for forking or not, it all depends first on your workflow and how you want to work and if you have owner/maintainer privs on the source repo. If you aren't an owner/maintainer you definitely have to fork the repo."

Great tips, Jennifer!

2) Clone the repo.

git clone https://github.com/<YourUserName>/demo

Note: when cloning, I ran into a few hiccups using the SSH version, but after helpful wisdom from Jennifer Davis (yup! she's done it again!), I'd now recommend using SSH, with this helpful GitHub resource.

3) Switch into your new directory.

cd cool-app

4) Create a new branch.

git checkout -b new_branch

5) Create a new remote for the upstream repo.

git remote add upstream https://github.com/name/appname

Here, "upstream repo" refers to the original repo.

And now, you should be in that branch.

6) Make a change to the code and push it to the new branch.

git add .

git commit -m "Add readme"

git push -u origin new_branch

If that goes through successfully, you'll see a message similar to this:

Photo credit to Kedar Vijay Kulkarni

7) Head over to GitHub the repo itself. The green Compare & pull request button will appear in the original repo.

Click it and you'll see the Open a pull request page.

There, you'll see another green button, this one says Create pull request and you can do just that.

8) From now on, you can make a change and push that change via this command:

git push origin new_branch

And create a pull request from there.

Tears of joy, applause, so happy.

Thanks so much for reading, catch you next time!

Unexpected Kindness

Anna Wijetunga — Fri, 12 Jun 2020 17:41:42 +0000

Ever been on the receiving end of unexpected kindness? Then you know it's worth talking about!

I'm a recent career changer (former educator turned software engineer) and am job hunting. During this complicated time in our world.

Which you'd think would be Really Terrible Timing.

You'd mostly be right. But then the unexpected happened.

The Unexpected

It's typical these days to get on the phone with a technical recruiter and talk shop. What's the role? Salary expectations? Are you a real human?

That was my expectation getting on a call with Steve Levy.

Buckle up, folks, that's not what happened.

He declared up front that he didn't take this call to talk about jobs at that company - but rather to help me successfully present myself as a strong person (and candidate) moving forward.

Not sure if that's sunk in for you yet.

He took the call purely to help me.

That alone is a jaw-dropper, and I'm not even done yet.

For 45 minutes, I was taught (taught, folks, taught!):

1) How to turn my resume into a love letter to any employer.

2) How to use my decades of prior work experience as an asset.

3) How to get connected in all the right places.

It's also worth mentioning, Steve was only able to teach like this because he took the time to study my resume and LinkedIn profile ahead of time.

Why This is A Big Deal

I am here to tell you, this is not usual. This is not the norm. This is beyond anything I could have expected, dreamed of, imagined.

A person who doesn't owe me a thing, took extra time and effort to help me.

If you ask him, Steve would tell you that this is completely normal - it's just what he does.

While that may be true, for someone in my shoes, it felt extraordinary. That kindness won't be forgotten.

If you know me, even a little bit, you know that when folks give to me, I like to reciprocate. And if I can't, I pay it forward.

And Now

I'm paying it forward the best way I know how.

Sharing what this experience meant to me, hoping it can you teach you something new, and most importantly, showing my gratitude.

Steve Levy, you keep doing what you're doing, and you're going to change the world. Heck, you already have.

To other folks out there following suit, the world is awfully lucky you're here.

That Second Interview

Anna Wijetunga — Mon, 08 Jun 2020 12:45:46 +0000

All Flatiron grads are quite kindly gifted a free mock technical interview with a rep at Skilled.

To me, this interview felt quite authentic. I had all the nerves and sleepless nights that precede an interview.

And yet. The interview was not only an incredible learning experience but a true delight.

Let me tell you why this surprised me.

1) I finished the interview feeling positive. I'll explain why this is a jaw-dropper.

As a career changer, I struggle to exude confidence about my technical skills. Sure I have 20 years of work experience, but mere months of coding. Months, folks.

In this interview, my interviewer met me where I was. I was highly encouraged and never left "stuck" for long without a nudge.

Not able to complete the coding challenge, I still walked away uplifted because my interviewer said,

"You know what you're doing - you just need to practice. That's exactly how we all get better."

Can't tell you how validating that was.

2) Without nerves, I was the real me.

At the beginning, my interviewer spent a few minutes small talking, and that naturally led into the first gentle interview question - tell me about your coding journey.

But when he asked, it sure felt like he cared. So, every question that followed, I felt I could be genuine in return.

Thus my slowly nerves melted away and the interview became conversational.

This made an impact on me because I discovered that when I wasn't nervous about what the interviewer thought of me and if my answers were right, I could just be me.

3) Interviewing makes me better.

I've always had a wee bit of test/performance anxiety, and that certainly carries into interviews. From test taking to racing a marathon to interviewing, I become a stressed version of myself when the stakes are high.

What has always helped is practice. And yes, I am noticing a theme here, too.

My mindset is shifting around interviewing. My hesitations center around my technical skills - I'm just not good enough, I'd told myself, why interview?

But perhaps that needs adjusting. Maybe it's not up for me to decide if I'm good enough. Maybe I need to keep practicing coding but also keep interviewing.

The only way to get better at something is to keep doing it. If you wouldn't mind, just remind me of that before my next interview!

Thanks, as always, for being here and reading. Always love hearing from folks, so don't hesitate to comment below. All the best.

JavaScript Closures

Anna Wijetunga — Thu, 04 Jun 2020 12:08:30 +0000

Like learning any new language, your knowledge can drip away when your focus shifts.

My focus did indeed shift over the past month - from intense language learning (JavaScript!) to interview prep to strictly coding practice.

What I really needed, silly me, was a sweet lil' mixture of coding and concepts.

Reviewing JavaScript basics, most concepts soaked right back in - except for one.

Closures

Originally a mathematical concept, from lambda calculus (did you know that?! me neither!). But for our purposes here, we know a closure to be a behavior of functions.

And only functions.

An object cannot have closure.

Nor does a class have closure.

Only functions.

For closure to be observed, a function must be invoked.

And, it must be invoked in a different branch of the scope chain from where it was originally defined.

Closure Simply Defined

Each reference from an inner function to the variables in an outer scope is called a closure.

Closure's Purpose

A closure gives you access to an outer function’s scope from an inner function.

The closure is a function that remembers the variables from the place where it is defined, regardless of where it is executed later.

Many (and I mean many) other authors claimed to explain closures simply, but I believe Dmitri Pavluti did it best:

Simple Explanation of Closures

Have a different resource or explanation that helped closures "click" for you? Share below - would love to hear more.

Power of the Journey

Anna Wijetunga — Tue, 02 Jun 2020 12:22:28 +0000

Before we dig in.

2020 has meant:

Australian Bushfires
COVID-19
Black Lives Matter

That's not exhaustive.

What you need to know is that I wake up each morning remembering the weight of the world.

And then I take a step forward.

As I dig into writing about this coding journey here and now, please know I do this because it helps me remember:

Nothing is permanent
Life is constantly teaching, but it's up to us to learn
We can rally together when things get scary

With that in mind, the power of the journey.

Perhaps the best part about changing careers from education to tech has been hearing from the people.

Their stories, their zig-zag paths from here to there, and what they learned.

Although no one has taken the same path from point A to point B, there are beautiful themes emerging:

1) Inquisitiveness is gold. Thinking, "Well that's weird" and then having the gusto to figure it out.

2) Embrace the unknown, because you'll never know all the things.

3) No door has to close all the way. Show your best self always, and maintain relationships. You just never know.

4) There exists a balance amongst business, team and personal objectives. Find a way to further all three.

5) This is a JOURNEY. Invest in it daily.

Cannot wait to keep listening, cannot wait to learn from those before me.

Have something to add? I'm all ears.

Be well.