DEV Community: Kaleb M

Honeypot Cult Article: Anyone Can be a Software Engineer

Kaleb M — Sun, 08 Aug 2021 17:40:23 +0000

Growing up in a small rural town during the late 1990s and into the 2000s meant having only dial-up internet speed (0.056mbps) for many years. We eventually leveled up to DSL (~3Mbps) around my first year of high school; which, as you can imagine, was still slow.

Our high school had an intro to technology class, but it centered around Microsoft Office without the inclusion of macros in Excel; no programming classes were offered.

Further, It wasn’t as easy back then to load up YouTube for tutorials on any topic. There were resources online to learn programming, but I wasn’t grokking it much on my own. My main focus at that time was a balance of playing video games and sports, as receiving a basketball scholarship and attending university was my main objective.

As it became clear that my basketball scholarship wasn’t forthcoming, getting accepted at the only school I put in an application for, James Madison University (JMU), became ever more important.

The acceptance letter finally arrived in snail mail and… I was waitlisted. I felt my future crashing down around me - how could I learn programming if I didn’t get into my school of choice? Why didn’t I take more time on the application?

Fortunately, as I visited our guidance counselor, he helped me write a letter explaining my situation and why I would love to be accepted. A few months later a phone call came from JMU - they asked me to accept!

I was an average college student.

I still remember struggling with my intro to programming class assignments. Our Teacher’s Assistant (TA) Zaid assisted in truly helping me understand the code I wrote. He would say: “don’t just hit run and hope it works”. Our intro class programming assignments were due every two weeks; I quickly learned that if I visited the TA’s in computer labs on the first week, the labs were pretty much empty.

With procrastination being a thing most of us knew well in college, the few evenings before assignments were due the labs would be packed. In other words, If I didn’t procrastinate, then I would have a lot more time with the TA and end up with better grades. I tried taking full advantage of that!

My university years passed by in a blur and my final GPA was 3.01. As a college student working 20+ hours a week, I was proud, even though I didn’t make top marks. I’ve since learned that my grades weren’t everything though, since many other lessons and knowledge came from my various experiences during that time.

It was because of that 3.01 and my work experiences (my internships and first full time job helped me grow so much), I landed a job at General Electric in their IT Leadership Program. This led me to travel the world, learning from amazing leaders, and working with so many great people; something I would not have guessed would happen to me.

As a few years passed, my time at GE came to an end. I moved to New York City, where I eventually found my way to Disney Streaming Services in early 2020, a few months after the launch of Disney+. Working on a product I sign into and watch amazing shows on regularly has been a dream come true for me.

Even so, I find myself pondering how this happened. I wasn’t top of my class in high school or college, nor am I the best tech expert in the world. Instead, I recognize that one, I was very lucky in some of the timing of opportunities brought my way; and two, it was my attitude and grit that has led me through many parts of the journey.

It’s not about being smart, it’s your grit

Computer science and programming don’t require being a wiz at math or being the smartest technical expert. Of course, these things help. Learning to speak the right jargon and knowing data structures is very important, but without grit when fighting through a new challenge or learning something new, you will only fight so hard before giving up.

Many of us struggle finding our way through tough bugs. We sometimes battle learning a new subject or technology that isn’t making sense. It can be frustrating.

Like wanting to throw your computer out of the window frustrating.

But once solved, whether it’s a few hours or a few days later, the rush of dopamine from the accomplishment is unmatched.

This same feeling happened many times while learning how to program. Some would say learning to do so is impossible for them - I’d disagree! Persistence and grit is key, which is in your control :).

The key is continuously learning and staying positive throughout! Trust me, it’s worth it.

Programming isn’t just math or writing if statements; instead, we get to own the creative process we use to solve tough problems without straightforward answers. We learn and research every day while collaborating with teammates, high-fiving or fist-bumping with happiness when something finally works. Together our teams create art and display our elegance as a story we tell in code.

We are in charge while expressing ourselves and solving problems; it’s amazing!

Thinking About Grit in My Own Career

Grit and attitude shows up throughout my own career. First and foremost, I listened to feedback from people smarter and more experienced than me. It’s not always easy when someone gives constructive criticism, and you don’t have change every time someone does, but listening and reflecting to determine whether or not to incorporate the feedback is key. Having an attitude of growth and learning will take you far!

Secondly, reading books about soft skills, leadership, and personal development helped me develop the correct mindset as a life-long learner. People are experts and author books based on a whole life’s worth of experiments or expertise; we’re lucky enough to have the opportunity to learn from it from the pages they write!

Lastly, I tried my best to look at each challenge as a growth opportunity. This meant being comfortable being uncomfortable, leading to failures and successes that taught me important lessons that I will never forget.

Anyone Can Become a Software Engineer

There are countless people in the industry who have similar stories: People who switched careers in their 30s, 40s, or 50s. People who had no formal schooling that became great engineers. I’ve met high schoolers at hackathons, learning and developing. Colleagues who went from spreadsheets and macros to learning SQL and managing databases, because they found it more fulfilling.

We continue to see the growth of demand for software engineers, while the supply can’t keep up. There are jobs with great salaries and benefits, working on great products that help change the world.

There’s a misconception that working in tech or even at a great tech company means being the absolute best technically speaking, but there is much more to being a Software Engineer than technical expertise. Being able to adapt and learn, work well with others, and persist through tough challenges are just as, if not more important. I’ve put together a guide for interviewing in the past - learning those fundamentals and growing your soft skills can be done by anyone, not just “smart” people.

By sharing my story, I hope to inspire and show that being a Software Engineer demonstrates one doesn’t need above-average smarts or super math skills. All you have to exhibit is a positive attitude, some grit, and a continuous learning mindset. Three things anyone can do!

Using Mental Models to Make Better Decisions at Work

Kaleb M — Sun, 11 Apr 2021 12:26:08 +0000

This article was authored as a contribution to the Honeypot Cult Community - you can read it there too!

Have you ever heard of the following proverb?

“To a (wo)man with a hammer, every problem looks like a nail”

It shows that people who have minimal tools for solving problems will use the tools they have, even if it’s the wrong one to solve it.

A basic example: imagine you only have a hammer and screws (no nails) while putting together a new piece of furniture. The option to hammer the screws is there, but it won’t get you very far in accomplishing your goal. https://giphy.com/gifs/xUNd9AYEql4m1Jj1mg/html5

This proverb, also known as the Man with the Hammer Syndrome is one of many mental models. Wait what is a mental model?

Defining Mental Models

A mental model is an idea that represents how something works in the real world; it can refer to frameworks, ideas, or worldviews that explain how the world works from your unique perspective. The complexity of our world makes it difficult for us to understand and remember how everything works together, so our brain uses models to comprehend it. It creates mental models and relates them to each other, which makes sense because our world is so intertwined (similar to a huge micro-service architecture across an enterprise).

Another simplified way of thinking about these ideas and how they relate can be discipline areas like Science, Engineering, or Psychology.

The big ideas from these disciplines are mental models, and learning mental models from the large disciplines gives you a position of strength when solving challenges because you can relate them to various models, across these various disciplines, solving problems in ways those who specialize may not.

Here’s an example of Elon Musk using the First Principles (Physics) to make batteries more cheaply: https://www.youtube.com/watch?v=NV3sBlRgzTI

Creating a Latticework of Models is Key

Charlie Munger, Vice-Chairman of Berkshire Hathaway and Warren Buffet’s right-hand man, noted the importance of mental models in his own life’s successes in a 1990’s speech. It was during this speech he said the following:

“Well, the first rule is that you can’t really know anything if you just remember isolated facts and try and bang ’em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form.

You’ve got to have models in your head. And you’ve got to array your experience both vicarious and direct on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and life. You’ve got to hang experience on a latticework of models in your head.”

The latticework of mental models can be compared to the specialization versus generalization debate in the tech world. It’s not that specialization isn’t good in many cases, but it does leave you open to blind spots in areas outside your expertise.

For example, frontend versus backend development. It’s possible to become specialized in either discipline.

Depending on your project and team, you need both to create a strong product. The full-stack engineers that sit between those two anchors, the specialists, are the glue that understands the way the different services disciplines work together - creating solutions that bring forth answers that make both systems better. That cross-discipline knowledge prevents falling victim to the (wo)man with the hammer syndrome.

Additionally, one can use mental models from disciplines outside the tech industry to be a better engineer and decision-maker on a team.

Margin of Safety from Engineering

When architects build bridges, they will be given the number of kilograms the bridge must support. Let’s say based on the length of the bridge, with the average and weight of an automobile, a specific bridge must support 20,000 KG. Architects will add a margin of safety to the weight that the bridge can handle, maybe 30%, so it can actually hold 26,000 KG.

The reason for this is similar to why there is always an extra cushion in monthly budgets because things can go amiss. The estimates of the number of cars at a given time might be off in a rare circumstance, and it’s much better to add in that margin of safety than hope it never happens - saving lives in the process!

Now imagine you’re Netflix and know at peak hours you need X amount of data to be streamed per minute, which requires Y number of clusters spun up. Can you imagine how a margin of safety can be applied here too?

Inversion from Mathematics

When engineers are working towards their next promotion, they typically use forward thinking to determine how they can best accomplish their goal: “What are the top things I can do to get promoted this year?”

There’s nothing wrong with the question and it can generate great ideas. But I doubt many people also ask themselves the following:

“What are the top things that could ruin my chances to get a promotion?”

In most cases, avoiding the big mistakes that hamper your promotion will be more helpful to you. The best part is this: it’s easier to avoid a few big mistakes than achieving all forward-thinking ideas. It reminds me of Warren Buffet’s reputation quote: “It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently.”

You can quickly see that avoiding some big mistakes prevents that from happening!

My Side Project: The Mental Model Dictionary

If you’ve made it this far, then you can understand just how intrigued I became in the world of mental models. They are an amazing way to make better decisions, avoid big mistakes, and continuously learn throughout your life. All good things!

As I started researching and learning the big ideas, I noticed that yes, there were many lists with summaries of the mental models or long blog posts about individual ones, these were helpful of course, but not accessible enough to me daily.

I wanted quick access to specific mental models with summaries, examples, and more resources on each. Thus, The Mental Model Dictionary was born!

The idea was to create a “dictionary” with “entries” of mental models in one place and grant users the ability to author their own mental models.

I ended up being the only crowd-sourcing author; overall though, I truly enjoy looking at the entries and hope to contribute more towards the project development in the future. More entries need to be added, but that too will come!

By combining the ability to document mental models, easily search for them, I hope to make them more accessible to everyone - inspiring them towards continuously learning in their life!

Honeypot Cult Article: 6 Ways To Maintain Good Mental Health as a Software Engineer

Kaleb M — Sat, 20 Mar 2021 19:53:55 +0000

This article was authored as a contribution to the Honeypot Cult Community- you can read it there too!

Software Engineers are puzzle solvers, but the puzzle isn’t pieces that fit together in the real world. Instead, it’s breaking down user stories, feature requests, and bug fixes into smaller chunks and solving them without breaking previously solved pieces. Imagine a puzzle that was ever-changing, the pieces changed sizes and shapes, new pieces were introduced with colours that don’t match expectations or assumptions when first putting it together. Your job is to continuously put the puzzle together.

In essence, Software Engineers do this every single day.

But, that’s just the tip of the iceberg when it comes to being a Software Engineer. We don’t work in silos and we certainly don’t make all decisions on our own, that’s where our team comes in!

Similar to any group of people trying to solve a challenge, there are sometimes disagreements on the best path forward. That’s why soft skills are an imperative part of being a great asset to a dev team. It can also be a huge stressor as we aren’t trained or taught how to be a great teammate or communicator in our Computer Science or Bootcamp classes. Developing features effectively takes hard work and strong leadership from members of the team.

These two pieces, completing the changing puzzle pieces and working with a team are both gratifying; also, they can be very stressful.

Deadlines increase the pressure of our work. Bugs or writing tests might cause dates to be pushed because our misjudgment caused an underestimated workload.

It happens - that’s why they are considered estimates - but too often they are treated as final, no ifs, ands, or buts about it; engineers must do what it takes to meet them for strong annual reviews that influence their compensation. 2020 added its own flavour to the stress recipe, dealing with a pandemic and working remotely became the new normal.

Teams that functioned in-person adapted to remote work quickly, striving to find productivity and collaboration without a whiteboard or real meeting rooms. For many of us, our socializing needs haven’t been met, and while we feel stuck in our apartments, healthcare workers take on the brunt of it with their diligent work ethic as they help save the world.

It’s not always fair to compare one’s problems to another since we all know you can’t compare apples to oranges. Regardless of the severity of one’s problems to another, how privileged one is compared to another, at a basic level, we all must take our mental health seriously!

I hope to help you do just that with a few simple ideas that can help you maintain good mental health as a Software Engineer!

1. Handling Imposter syndrome

Imposter syndrome boils down to believing you are not qualified for the position or work you have credentials for. It’s a common challenge in tech due to its fast-paced always changing nature.

I’ve written about it in the past: check out Battling Imposter Syndrome by Understanding the Dunning Kruger Effect to learn more!

2. Take breaks

Have you taken a short walk with or without headphones in the past few months? If so, think about how you’ve felt afterwards. Did you feel any different?

When learning we would be working remotely for the foreseeable future, our organization organized a How to Transition to Working From Home Lunch & Learn to help ease our transition. Taking breaks, real breaks , not making coffee, or grabbing a snack while looking at your computer screen truly makes a difference in productivity.

Breaks are key when weight training or when I was attending practices for high school athletics. Our body needs time to recover between sets within a workout regiment, without them, our muscles are depleted of energy, and our reps in later sets suffer.

Similar to our physical body, our brain too needs breaks.

Software Engineering requires intense concentration, knowledge, and patience. Our frustrations while solving a tough bug or angst when user error feels like computer error should not be taken lightly. We need time to recover throughout the day!

There are many different options here, so I’ll talk about two.

Option 1: schedule two 20 minute blocks on your calendar; one in the morning and one in the afternoon. This is your get up, walk around, listen to an audiobook, read a paperback book, meditate, or free up your evening by taking up house chores time. You can literally do ANYTHING you want during this time except for work and looking at a screen.

The productivity gains from this can be felt immediately when getting back into the zone.

PS: sometimes we have to reschedule or miss a break, it happens. Forgive yourself and work on doing so the next day.

Option 2: the Pomodoro technique (nifty timer for this). This technique breaks productivity sessions into three different time blocks: 25-minute work sessions, 5 minute short breaks, and 15 minute long breaks. Take four 25-minute work sessions with short breaks in between. Follow the fourth session with a long break. Repeat!

3. Friends and Family

The pandemic has introduced a significant challenge for seeing loved ones on our usual cadence. Instead of holiday get-togethers or watching nieces and nephews play sports with members of the family, we only have virtual opportunities that our brain knows aren’t the same.

Still, the rejuvenation and refreshed feeling after catching up with your close friends or family (or both) can’t be discredited. There’s something we feel all the way in our bones when we’re with the people we love and who love us most.

I’m not recommending calling someone or catching up with every person every day. I’m encouraging you to schedule a time for these important people in your life every once in a while.

The feeling of closeness in tough times goes a long way - let’s not take on these challenges alone!

4. Practice Mindfulness Meditation

We live in a VERY busy world full of so many different types of noise at one time. Coding while slacking, reading while responding to text messages, walking while listening to music. We rarely focus exclusively on one thing! When do we sit down and give ourselves the time required to listen and observe our thoughts, accepting and understanding them with patience instead of avoiding them?

Many of us don’t. We quickly can see why practising mindfulness has become so popular.

From Benefits of Mindfulness at HelpGuide: “Mindfulness is the practice of purposely focusing your attention on the present moment—and accepting it without judgment. “

Taking time to practice mindfulness slows us down, granting us the ability to reap all of its benefits! What benefits you ask? Check out these to read all about it:

5. Exercise

An important part of mental health, believe it or not, is exercising (learn about the Exercise Effect). Weird right? How can physical activity help out our mental well being?

Exercising requires discipline, which means accomplishment by sticking to it. That accomplishment releases dopamine, making us happier. It relieves stress and keeps our heart working as it pumps blood through our bodies. Software Engineers typically sit throughout most of our day, so we must combat the effects on our bodies for doing so.

Whether you’re hitting the gym with an intense routine or not, at the very least taking smaller walks every evening or a few times per day rejuvenates us and improves our well-being. Check out the Mental Health Benefits of Exercise for more information on why some exercise is better than none.

As a New York City dweller, the difference in the number of steps per day taken this year versus last year has been night and day. From at least one-to-two miles walked every day to less than one because the forcing function of a commute has evaporated.

There has been no better antidote than grabbing a mask, putting on my headphones, and loading up an audiobook as I gain knowledge while exercising - true concurrency at its finest!

6. Hobbies / Passions

This has the fundamental idea of taking time away from your required obligations to do the things you love. It is your guilt-free, do whatever it is that makes me feel joy time of day!

This can be reading Fantasy books (Stormlight Archive anyone?), binge-watching The Mandalorian on Disney+, or just lurking your favourite subreddits.

It can be woodworking projects, making music, playing video games, or creating a wonderful home-cooked meal. The options are endless and the only requirement is that you are happier after the activity has concluded!

Giving myself time to be happy and enjoy the little things in life has made a large impact this year. If my body and mind didn’t feel productive and motivated to write or work on side projects, I listen to it.

When your body and mind require time to recharge, it is so important to listen. It will make the words or code come easier when you get back to it! Our minds need time to cope with the huge changes in our daily life, and that is totally ok :)

Wrapping Up

Software Engineering jobs can be stressful, full of pressure to deliver tough tech challenges by the project deadlines. Further, finding solutions to ghastly issues drains our brain’s energy day after day. Our soft skills and interpersonal skills must remain sharp because collaborating effectively brings about better results.

In fewer words, being a Software Engineer can be exhausting, especially for our minds.

It’s easy to see based on that conclusion the importance of mental health.

Taking time for self-care to recharge and enjoy life outside of our work makes us better engineers. It rejuvenates us. It makes us more productive. And it makes work more fun. All of which makes developers happier!

Honeypot Cult Article: What I learnt from almost getting promoted

Kaleb M — Sat, 20 Mar 2021 19:43:31 +0000

This article was authored as a contribution to the Honeypot Cult Community- you can read it there too!

On a random Friday around nine months into one of my past roles, the tech lead of our team, and also my manager, announced they would be leaving the company for a new job. We all congratulated our colleague as the happy yet bittersweet feeling led us into the weekend.

On my commute home that evening, I couldn’t help but think that backfilling my manager as Tech Lead was a real possibility. Even though I was quite new to the team, I had demonstrated my technical expertise and leadership experience.

It was an opportunity for me to grow with both people management and leading technical architecture decisions; but, I had some hesitation since I hadn't been in the role very long. Would management really take a chance and promote someone this new in the organisation? There was only one way to find out!

The Conversation with my Manager

Before I made any decision towards the tech lead position, I took two actions over the weekend; first, I discussed it with a few mentors, explaining the situation, the opportunity, and my hesitations. And second, I went through my checklist for making big decisions.

The end result? I decided to go for it and have a conversation with my manager first thing Monday morning. The worst thing that could happen was being told no right? I arrived at the office (wow do I miss the office) around 9:00 am and immediately scheduled a meeting with my manager for 11:30 am.

It felt like an eternity watching the clock as it slowly ticked towards midday. I tried focusing on my usual work instead of watching the clock, it didn’t help much, but eventually, I found myself walking towards the meeting room.

As the conversation began, I acknowledged the team appreciated all of the hard work and dedication displayed during their time as our manager. Following up on that, I detailed some of my achievements on the team and highlighted my leadership experiences in past roles. I ended by explaining that the tech lead role offered me growth opportunities in two areas: management and architecting high-level technical decisions. Both would be really helpful in my career!

My manager replied with their approval and informed me there were a few candidates being considered, with me being one of them. Obviously, there was no guarantee that it would end up me, but consideration was a great first step and I was excited by the opportunity!

He informed me that the decision wouldn’t be made for another week or two; but in the meantime, I’d be given any updates.

There was one big challenge - our Engineering Manager was out on paternity leave, making it a bit difficult to easily decide on the next steps, communicate the decisions to our team, and make sure everyone was on the same page.

Splitting Our Team & Working on a New Project

Losing my manager put the team in a bit of a bind since we were smack-bang in the middle of a huge project. The goal of this project was to essentially revamp the design of our product and release a new version, while in parallel updating features in the current version. Initial talks on how we would proceed had already begun.

In the blink of an eye, the two weeks between the announcement and my manager’s last day flew by. The sequence of events that happened once he left went something like the following.

First, it was announced that our team would be splitting up into two parts: one to focus on maintaining and adding features to our current application, with the second focusing on developing the revamped design version.

At the time, we had two Senior Engineers on the team, me being one of them. Each of us would be in charge of leading one part by coordinating with our partner teams and contributing features that met product requirements. We also had two associate Engineers, who would be also split up into each area. Another developer with strong domain knowledge of the organization’s architecture and data flow would be our “tech advisor” if we needed any assistance.

Basically, we split the team in two with each focusing on the respective priorities, where both Senior Engineers would be acting tech leads and had an extra resource that could help make sure our architectures fit into the overall system appropriately.

You can imagine my exhilaration on leading the new architecture; I immediately got to work!

The Almost Promotion

The situation became quite interesting in the following few weeks.

Initial Conversation with Leadership

Approximately one month or so after our manager had left, a meeting was sent over on my calendar by one of our leadership team members. This wasn’t out of the norm, as we met with leadership every so often; and, I’d have the opportunity to ask questions about the future of our team.

It was in this 30-minute meeting I was told that my acting tech lead role would become permanent! The tech lead role expectations were read out loud to me, and I graciously accepted and stated I was confident in meeting them. Further, one of the associate engineers on our team would now report to me, meaning I’d have my first direct report!

Lastly, during the meeting, I was informed that our tech advisor would be backfilling my old manager’s role and would be my new manager. With so much changing, I was asked to wait until announcing it to the team as other conversations were still in the works; eventually, leadership informed everyone on our team of the new team structure. Immediately I changed my LinkedIn profile, my e-mail signature, and told my friends and family the news!

A Month Later…

The initial changes and unknowns for our team’s future had become old news and our Engineering Manager was back from paternity leave after a few weeks had passed.

I was growing curious while anxiously waiting for communication from the HR team. It’s common that an increase in responsibilities (especially having a new direct report) results in additional pay, promotion raises typically being anywhere from 10-20%. That process can be slow and I exhibited the virtue of patience to the best of my abilities.

That patience had run out at the month mark, and after asking my manager for an update; I ended up setting up time with the Engineering Manager instead. I broached the conversation with a simple question of status regarding my promotion and quickly became flabbergasted.

“I’m not sure what promotion you’re talking about, could you give me more details?”

“Sure, I can do that,” I said, following up with the details of my conversation with the leadership team member regarding our team split and tech lead role.

“I’m sorry to hear this, as I had no knowledge of that conversation and we don’t have any tech lead positions available that you could be promoted into.”

The response came like a bullet to the gut. I’d be lying if I didn’t feel like a brick was residing in my stomach. It was very apparent a miscommunication had occurred, and a wave of embarrassment came over me as I walked back to my desk.

The main question that played like a broken record player in my mind was: why would you announce it before the HR team had verified it?

The Lessons Learned

I reconciled in the knowledge that it boiled down to a communication issue, similar to the “telephone game” we played when we were younger. I felt pride in knowing that the opportunity was considered for me by leadership, yet disappointed in taking on new responsibilities with the assumption of changes in pay.

It was important to reflect on what areas I could control and take the following lessons away for the future!

Miscommunications Happen

We can all understand that messages across different mediums like Slack or Zoom cause misunderstandings, especially when there are multiple levels that a message travels from.

There were evolving situations changing every day when my original manager left, and with his manager being out while huge projects were moving forward, I can empathize with how intentions were misinterpreted.

For big decisions and important conversations, it is important that all of your ducks are aligned before communicating them - especially for something like a promotion.

Trust but Verify

Trusting others should be seen as a positive in one’s character; the world runs on our trust in each other.

The lesson here for me was verifying the promotion with HR, or verifying that the process was started instead of assuming it. There’s nothing incorrect in the behaviour of verifying moments that have a large impact on you when they depend on others. It isn’t a breach of trust and something I’ll be doing in the future.

Understand Your Company Promotion Process

This situation was the first and last time I would be promoted without the knowledge of the full promotion process in my organization. In the future, I will know how the pay increase works, how the title change happens, and how one tracks it throughout.

I highly recommend you do the same!

Abundance vs Scarcity Mindset

Being passed over for a promotion or being told you’re getting promoted when you actually don’t create a flurry of emotions. Give yourself some processing time, then remind yourself that promotions will be available in the future at your current company and there are many job opportunities in other organizations as well (abundance mindset).

In other words, put it into a big-picture perspective so you can see this one blip in your path isn’t a show-stopper. Make it your motivation going forward instead!

Concluding Thoughts

Organizational structure ebbs and flows. People are promoted when opportunities arrive, people change companies as they find exciting growth opportunities, all the while we each go to work each day with different objectives. Some fight for their promotions by going above their responsibilities every single day; while others love what they do and enjoy the comfortable feeling of where they are.

No matter where you are in your career, I hope that writing about this situation can help you avoid it in your future. Mistakes don’t define you and learning from them is the surefire way towards becoming the person you envision yourself to be!

Honeypot Cult Article: Effectively Onboarding New Teammates

Kaleb M — Wed, 17 Feb 2021 13:30:24 +0000

With the new year comes new opportunities!! For many companies, it means newly approved headcounts which allows development teams the opportunity to grow their ranks!

This creates an opportunity to hire! So in the spirit of hiring, I’d like to write about the onboarding process, and how employers can successfully onboard new Software Engineers.

In a previous article, I wrote about how new joiners can best start on the right foot in, The First 90 Days - How to Start Your New Role Off with a Bang. While that article focused on the employee’s perspective, this one’s for the employers.

Let’s begin by defining the importance of the onboarding procedure.

Defined Orientation & Onboarding Process

Having a defined process reminds me of an important life quote:

“Failing to prepare is preparing to fail.”

It’s widely accepted that properly onboarding a new employee lays the foundation for success; as engineers, we should take it as seriously as upgrading a large complex system.

Every company decides and influences the culture embodied by their organization. To adequately introduce that culture, onboarding is a key step. I recommend starting with this base question: What are the goals of our organization’s orientation and onboarding process?

We can achieve each by working backwards from the answers agreed upon.

Orientation vs Onboarding

There are two main gears that drive the onboarding machine: orientation and onboarding.

Orientation introduces you to the company and the tools required for your job, while onboarding teaches you how to use them; or, metaphorically: orientation orients you to a new land, while onboarding assists in you navigating it properly.

Both lend a hand in employee success, but how can we complete either effectively?

The funnel approach!

The Funnel Approach

If you can imagine filling a funnel full of onboarding topics, then you can see that even if all onboarding topics are poured into it at once, only so many of them can exit the funnel at one time.

Bringing that idea back into the reality of onboarding, we recognize that in presenting a large amount of information via slide decks and videos, only part of it will be comprehended.

This isn’t fake news; in my experience, becoming overloaded has been common with too much information in too short of a time frame happens when joining a new company.

How could we do better? Use the funnel approach and its two principles.

Pour only the biggest and most important ideas first
Spread the detailed and less urgent ideas over time

Both principles can be followed in orientation and onboarding.

Orientation Overview

Introducing the company’s structure, culture, benefits, and office space are the main responsibilities of orientation; it’s typically handled by the HR team and volunteers. Close coordination between the HR, IT, and the team of the new joiner is important here: HR will be leading the orientation schedule and going through your new benefits, and IT teams will be assisting you to set up your computer with tools and access.

These first few days are an important part of not only telling but showing newcomers the inclusive culture they’ll be a part of.

The next stop on the train begins as orientation concludes - onboarding with the new team!

Onboarding Overview

Onboarding introduces the team members, product, tech stack, and team processes that you’ll be working with. From the team’s perspective, Onboarding a new dev team member can be a difficult task, as it requires coordination, resources, and an open mind.

Here are some questions to get you started:

Where is the best place to begin the onboarding process?
How can we make our team feel open and inclusive?
We haven’t set up our development environments from scratch in a while, are instructions up to date?
How can we best explain our architecture?
When should we expect our new teammate to begin contributing to sprint work?

Once answered, break it down into phases; I like to break it down as such:

Before the new team member starts
Meeting the team and getting an overview of the product
Dev environment set up and overview of architectures
Learning the intricacies of the codebase and begin contributing

These four phases break down the onboarding process into manageable pieces for the team.

1 - Before They Start

Being prepared is key to creating a positive first impression. Here are a few prep items we can take care of for them!

Order Equipment

I’ve always appreciated having all the hardware ordered and delivered at my desk within the first week of starting a new gig — bonus points if it’s on the first day!

If possible, reach out before a new teammate’s first day with options of equipment available. Things such as their preferred computer model, monitors, docks, or standing desks.

Once preferences are received, order them! A proper work environment on the first day contributes to a much smoother onboarding and gives the impression that the team is productive, supportive, and organized.

Have you ever joined a new company and the first week is spent waiting for your computer to arrive? Talk about a blocker for getting things done.

Update Documentation

Another prep task - updating all documentation managed by the team. Whether that’s a wiki or repo ReadMe files, having it documented reduces the friction for getting started and set up.

Assign a Mentor

A mentor or sometimes called buddy should be known and assigned before they start. This volunteer should be available for all questions and ease any troubles that come up during the onboarding process.

Create a ticket

Creating a ticket with all of their onboarding tasks helps track and gives a methodological agenda to follow. The ticket should outline links to important documents to read, helpful resources such as slack channels to join, the people responsible for different parts of the architecture, and the software they should get access to or download.

The main idea here is to give them a clear path to follow, assuring they never have a “what should I be doing?” type of moment.

2 - Meeting the Team & Product Overview

We spend a great deal of time with co-workers, collaborating through discussions while helping each other solve challenges. Like any type of relationship, it can take time to form and strengthen - onboarding offers the first opportunity to start!

Each team member should set up a time to welcome the new teammate, learn more about their story, and give overviews on parts of the tech stack. Doing this over the course of their first week or two will help continue the funnel approach of only allowing so much information at one time.

3 - Dev Environment Set Up & Architecture Overview

Setting up local environments might take a considerable amount of time - updated documentation speeds it up. Team members presenting tech stack overviews initiate the next step of onboarding.

This should be done in conjunction with the teammate 1-on-1s or in separate sessions. The end goal here is that a new developer has all local environments set up and understands the high-level architecture, patterns, and features of the team’s application(s).

These are the biggest and most important ideas for the information funnel, and once those have exited from the funnel, diving deep into the code will happen over time as one contributes to the sprint via tickets.

4 - Contributing to the Sprint

The last phase of the onboarding process will be contributing to the sprint.

There are different approaches to doing this, but my favourite is giving simple tickets while simultaneously lowering expected capacity in the first few sprints.

A concurrent benefit task that should be considered - updating test coverage - awards both the code health and the developer, since writing tests requires an understanding of the underlying code.

The second part of this process will be collaborating and asking even more questions - this is where the high-level understandings transition into low-level code changes. Additionally, he or she will be going through code reviews as they learn new team code conventions.

Once the new team member begins to complete tickets, sprint capacity normalizes. The new dev is officially incorporated! Onboarding is complete!

Wrapping Up

Onboarding a new team member can be a daunting task, but one that leads them to success when done properly. By learning and iterating through feedback gathered after onboarding ends, we can teach new employees the culture, benefits, processes, and code-bases more effectively - leading them to faster impact, higher productivity, and of course, more fun!

Onboarding someone new has always been a fun moment for me throughout my career. I always enjoy getting to know someone’s story, learning from their experience, and watching them grow into their new role. After reading this, I hope you can find some joy in the process too!

Cheers!

2020 Review And My First Year at Disney!!!

Kaleb M — Fri, 01 Jan 2021 20:50:50 +0000

Thinking back to the first day of 2020, it feels unreal that I lived in a different apartment, worked at a different company, and commuted to Manhatten without a mask.

Early January brought with it the long-awaited on-site interviews I'd scheduled in mid-December because of the holidays. Additionally, I was hoping more would open up as new headcounts would open from a few companies that I passed the technical phone screening but didn't have available headcount at year end.

This meant that the grueling interview prep that started two months ago continued. Living in a studio apartment didn't make it easy; Frankie endured me waking up at 5:30 am, making a fresh cup of coffee, and working through Leet Code, AlgoExpert, or System Design practice questions every single day.

I was near burn-out and hoped the upcoming interviews would go well! Interviews are two-way streets, especially as you gain experience in what makes you happy in a working environment such as: a product that you believe in, growth opportunities, culture, work-life balance, and respectful team members you'll be working with every single day are all important.

PS: See my guide on preparing for interviews to learn more!

Long interview story turned short, by the end of January I had accepted my new position as a Software Engineer working at Disney Streaming Services!!

Disney Plus had ~20 million subscribers a few months after launch, and I was ready and excited for my new opportunity starting in February!!

Outside of interviews and job changes, we visited both Boston and Mexico in the first two months of 2020 - our timing was impeccable and unintentional. I'm thankful we stayed safe and we were able to get back home before travel bans had begun.

The Pandemic Hits

February arrived slowly, my commute didn't change much and I hit the ground running with my new gig thanks to an awesome onboarding process. I'll never forget being in orientation, seeing all of the Disney swag, watching videos from Bob Iger about the company, inspirational videos with Disney characters, introducing the magical culture I'd now be part of.

I was just getting into the new routine, learning the new tech stack, and hitting the gym during lunch - all was going well...until one month in, we went from an in-person dev team to remote!

The First Few Months

It really hit home we'd be working for a while as NYC cases surged and we began having lunch & learn sessions on how to work from home. Frankie was working from home soon after, and all of a sudden our studio apartment felt much, much smaller.

We were anxious and scared. Thankfully a friend had urged us a week or two prior to stock up on food and supplies, so at that moment we were fine.

Reflecting though, at this time - there was much less knowledge from the scientific community about the virus, no one knew what was safe and what wasn't. We listened and watched the leadership of the nation, of NY, and of NYC on how we could stay safe and help out our fellow citizens

I remember following a few general principles:

Cloth masks were recommended, if you had other kinds donate them as supplies were limited
Only leave your apartment for necessities
Order from local restaurants to help them stay open
Donate to food banks and other organizations if you can, because we were in it together

Frankie and I both recall the unprecedented number of ambulance sirens throughout the day, it was non-stop and nerve-wracking. Queens was hit hard at that time.

Every evening at 7:00 pm, we joined our fellow New Yorkers in clapping and making noise for our healthcare workers. It gave us a feeling of closeness to people we never met before. Friends and family worried about us, but we assured them at we were safe.

For three months, we didn't leave our studio apartment.

We wanted to do our part in stopping the spread and keep hospital beds available for others, constantly telling ourselves we weren't stuck, but safe at home. Many artists and businesses entertained us through virtual means, and like others, we all appreciated it. Especially with all non-essential businesses closed and big events canceled indefinitely.

One humorous side was Frankie discovering how often Software Development teams collaborate (news flash, all day long), requiring close coordination as we avoided being on calls at the same time.

A Brief Summer

The warm weather of 2020 felt like it came and went in the blink of an eye.

Social Unrest

June brought feelings of helplessness as protests erupted across the world.

Frankie and I were at a loss of words and infuriated, how does one cope with a pandemic followed by George Floyd and Breonna Taylor being murdered?

It wasn't an easy time.

We used work and recommended reading as a source of distraction as we learned more. It wasn't new but its importance was reinvigorated. Rewatch the first two seasons of Fresh Prince of Bel Air, aired in the 90s, and pay attention to themes presented in some of the episodes from 30 years ago. Guess what? They are the same!

The history we learn in school - lacking. Driving a Benz while black - dangerous. And many others.

A lighthearted show demonstrating real issues, and I was so disheartened at not doing enough so far. I'll be fighting harder going forward, that is certain!

Finally going outside

The summer brought with it a lapse in case numbers for New York City; we left our apartment and even dined outside. We snuck in two small beach trips, one in Long Beach and another in Montauk with a focus on outside activities. They were both equally refreshing.

I was ecstatic just taking walks around our neighborhood parks, and I never appreciated seeing others doing the same (masks on most of the time) as much. It was a good feeling just being around other people, reminding us of how incredible living in NYC usually feels.

Back to Cold Weather and Quarantine

It wasn't long though that warm weather turned chilly and cases spiked, leading us right back into the apartment except for essentials. Frankie joined a new team in the Fall, and with more meetings throughout both of our days, we decided it was moving time. Signing a lease for our new apartment in September - we quickly were all moved in and unpacked by the end of October.

Since then, life has been routine with home-cooked meals, work, video games, books, and occasional appointments such as visiting the dentist.

We're doing our best as responsible citizens in a few ways:

Supporting local restaurants and businesses
Wearing masks
Reducing all non-essential travel
Relying on outside activities to prevent the spread
Donating to organizations that are helping people (hello Actors Fund!!)

It's been a different type of year, but we've been cognizant of our blessings and empathized with the hardships of others. There have been extreme difficulties and amazing silver linings, and we can only hope 2021 will be better for everyone!

Now that the mandatory Covid summary, here are some other parts of the year that could be of interest!

My First Year at Disney

Working at Disney this year has been an absolute blast. I still find it surreal playing a role in the ecosystem of a product used by at least 85 million people (and growing!!). Disney+ helped bring happiness when the world has needed it this year; watching Hamilton, The Mandalorian Season 2, Soul, and many others gave me joy.

Delivering Happiness

Working on products that deliver goodness has been and will continue as part of my life mission. This year has been in tune with that perfectly; I love being part of something bigger than myself, and seeing the world respond has been an incredible experience.

It's been absolutely humbling and intriguing as I've been part of architecting and implementing many new features in the internal services I (along with our team) help support. Being part of finding solutions to challenging problems, weighing different architecture options, and celebrating the results built by the team makes me proud of the work we're doing.

There were many opportunities for personal growth, which I find highly rewarding!

Working with an Amazing Team

Engineering isn't an exact science, yet creating art with individuals through discussions and code generates the feeling you get when admiring a beautiful painting - it comes together wonderfully. Working with others who believe in quality engineering principles with various experiences has been fabulous. Our discussions are about finding solutions to challenges that work best, meet user needs, and keeps architecture extendable in accordance with our conventions.

I've written about being open-minded in the past, and still have the opinion that respectful discussions lead to incredible outcomes. That's why diversity of thought is a KEY metric for success.

Becoming More Versed in Angular & SpringBoot

During my interview process, I learned that joining the team as a Full Stack engineer meant working on Angular, Node, SpringBoot, and database technologies.

The previous year at NM consisted of working on a React app with GraphQl...in other words, I was a bit rusty on the backend and didn't have much experience with Angular so far in my career.

I gladly accepted the challenge!

Angular vs. React

Learning the large feature list of the Angular Framework was tough. The docs feel like reading a Brandon Sanderson novel, but I'll admit it grew on me as my experience level increase.

The biggest complaint I have is the various places logic can happen, for example, in the templates, in the component, or parts of angular like an auth guard, interceptor, or resolvers on a route.

It's amazing once you figure out what those are and how to quickly see where they are used, but in the beginning, learning all of these features was difficult. Angular provides standard ways of implementing common features of web applications these days that I do appreciate, and services as a way to share data across components work wonders with managing data in the app. Overall, I find it very useful for an enterprise application.

React still has my final vote of preference (although not by much) with the beauty of combining JSX and component logic in one place, especially with the huge win of opening fewer files while developing one component.

I find many that prefer Angular use the argument of "separating HTML, JS/TS, and CSS in their own files" as their main reason of preference. I've used SCSS in my React projects with separate files, so it boils down to separating out HTML from JS.

It's a strong argument because separating concerns at face value makes sense.

Once you start adding *ngIf, *ngFor, attribute binding, property binding, custom events, and even the <ng-container> tags, it no longer feels like separated concerns in my humble opinion. Instead, you now have HTML entangled with framework features (even if you keep template logic simple).

The huge win of having all implementations of common web app features in Angular, especially when it's supported by Google devs and OSS, is hugely beneficial. I'll never forget that feeling of changing from React Router to Reach Router, only to learn later that Reach Router would be deprecated and one should move back to React Router...when both were created and supported by the same people. It's hard to see that situation happening in Angular (barring AngularJs upgrade to Angular2+ from the convo); and, that's why it has become such a close match for me that I'm fine using either, but vote for React if given the option.

Before gaining this experience, my opinion would be based on the experiences of others instead of my own. If it has taught me anything, it's that Vue, React, Svelte, or Angular can all work well - arguing which is best feels like a mad hatters tea parter. If you can meet the user requirements and the library has strong support, you're in good shape.

SpringBoot & Backend

Upon starting 2020, you could ask me anything about Frontend Development best practices, and I could give you thoughts on approaching problems, features, or architecture based on foundational knowledge and experience. If you ask me something about the best practice of SpringBoot or Java instead, I'll need research time before answering.

My mindset has always been - if you're uncomfortable tackling features on part of a tech stack - start trying to work on it more. That's exactly what I was able to do!

My knowledge has tremendously grown in these areas thanks to many conversations with team members and being part of many architecture discussions (plus reading about architecture in our Disney Tech Book Club).

2021 will bring even more of this and I couldn't be more excited.

I'm unsure why there's a stigma against being a full-stack Engineer in the web dev community, stating it's impossible to have expertise in both. "Expert" has such a general definition, along with it being on a sliding scale, that I respectfully disagree with that notion. It's definitely feasible developing features on both sides of the stack with best practices in mind.

No one, I repeat no one knows everything. Learning a new skill or technology makes working in our field exciting. Who doesn't want to continue increasing the skill base they have, even if they aren't a so-called "expert"?

My First Year as a Freelance Writer

My first blog post was written and published on Google Blogspot back in 2015; the goal at the time was inspiring others through my journey of positive thinking. I've written many different types of articles since then, developing my skills as a writer over time.

I've earned the "Distinguished Author" over at Dev.to over the last two years.

2020 gave me a nice surprise though!

HoneyPot

One of my articles was noticed by an editor over at HoneyPot - a platform that helps developers find new roles. I received an e-mail asking if I'd be interested in submitting a few articles for their new developer community.

Of course I was! We talked through rates and topic ideas over a few e-mails, and BOOM I was a freelance writer.

I couldn't believe that one of my hobbies became a small stream of income. I'm hopeful the trend continues for 2021!

Check out my published articles (a few more to come) on my author page!

My First Full Year of Singing Lessons

Music has always been a love of mine - its power of bringing people together amazes me.

Before November 2019, I was a strong believer that singing was a born talent. It's true that some are born with an innate ability, but just like athletics, there are skills developed too.

I decided 2020 would be the year that I'd at least give it a try!

It was an embarrassing first few lessons (ok maybe more than a few). I still remember sweating as I tried to sing the basic pitches as my teacher instructed; but, I refused to give up!

The progress has been very rewarding! Although I won't sing like John Legend anytime soon, I can hold a few notes and sing through a few songs all thanks to my brilliant teacher.

I'll be singing in my first recital (which raises money for charity) in Jan 2021, something I never would have thought was possible!

My Friend Started a Company

A mentor and friend started a consultant agency for AX Dynamics in 2020! He started the year off strong by hiring full-time employees, and I couldn't be prouder of him!

His grind and persistence this year was definitely admired by all of those he worked with, and I wish nothing but success in 2021 (and beyond)!

A New Year and a New Start

2020 was a challenging year mentally for all of us. It taught many unforgettable lessons:

Catching up with friends and family is key to happiness
Appreciate the little things of life
The Importance of Health - Physical and Mental
Achieving the American dream can still happen, but we need to make sure everyone starts from the same starting line
Help Others During National Cris by volunteering or donating
Voting Matters
Support small businesses
Create routine habits that accomplish goals - systems and environment matter
Continous learning through books, courses, and other means makes a huge difference (see my recommended books in my resource pages - Life and Development)

With the end of 2020 behind us, all we can do is hope for a better 2021. Let's do our part to make it happen!!

Honeypot Cult Article: The First 90 Days - How to Start Your New Role off With a Bang!

Kaleb M — Thu, 31 Dec 2020 21:00:35 +0000

In the day and age of knowledge workers, especially within the tech industry, taking on new roles every few years internally or externally has become commonplace.

In either case, growing our technical expertise in both depth and breadth makes a huge difference; because the opportunity to learn from diverse company tech stacks, cultures, products, and processes grant us the opportunity to impactfully apply experience-based knowledge in each role.

It’s easy to see that over a lengthy career, 30 to 40 years, integrating effectively into a new organization and team becomes an essential skill. The faster we can transition from newbie to contributor on a new team, the more productive and impactful we will be.

In February of this year, I found myself in this exact situation as I began my new journey at Disney! I was ecstatic about the new opportunity to help bring more happiness to the world! With that excitement, the question came to mind - how can I quickly ramp up and become a contributor in this new role?

I recognized that thanks to my time in GE Healthcare’s rotational leadership program, my experience in ramping up quickly was quite high. Starting with my internship during my university years until the first day at Disney, I had onboarded a total of six different times onto new teams.

Still not feeling 100% confident on how well I did this, I started answering my question by reading a recommended book: The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter. By taking the ideas from the author and matching them against my experiences, I was ready to start my Disney career off with a bang!

The first 90 days were key!

90 Day Plan

The 30, 60, and 90-day points each have objectives for starting off the new role on a high note.

After completing the official company onboarding process, find time on your new manager’s calendar or send over an email. The objective of this call or email? Understand their expectations, learn the team process for onboarding, and ask any questions to help create a plan to complete everything that’s expected on time.

The first month begins with learning about the product and getting to know who you’ll be working with!

First 30 Days: Learning the Product & Your Team

Software Engineering requires collaboration and respectful technical debates as we find solutions to challenges or features together - a strong team bond makes that easier. The first 30 days establishes that bond.

Get to Know Your Teammates:

If the team you're joining automatically sets up a time to give overviews of different parts of the tech stack, then take time at the beginning of each session to learn more about their story, how they became a member of the team and their areas of expertise.

Otherwise, set up coffee catch-ups with each teammate instead for the same reasons.

Learn the Product and Product Goals Your Team Supports

At the most basic level - the reason you’ve been hired boils down to filling a resource gap or solving a specific business challenge. This could be supporting an internal business unit or developing an externally sold product.

In both instances, understanding why your team was created and about the business side of the product gives you the purpose and motivation behind your work.

Understand Your Partners

How does a feature go from ideation to implementation? Does it start with the product team, get passed over to design, then finally make it to the development team?

Who are the product team members that align with us and which designers pass over their ideas? Do we depend on or do any other tech teams depend on us?

Having the answer to these questions will make us a more effective contributor - understanding the partners, users, or designers flow strengthens the partnerships that contribute to successful product development.

Set Up Local Environments

During the onboarding period, the responsibilities we have on the team are at its lowest. Taking advantage of this by setting up and organizing local dev environments accelerates productivity levels in the future.

It’s common that you will be asking for help from teammates when issues come up, so take this opportunity to ask various people on the team. You can see who fits with your learning style best and give the opportunity to bond over fixing anything that needs to be updated in ReadMe files.

Days 30-60: Getting to Know the Code Bases

Code bases vary in size and being familiar with all aspects of them takes time. After the initial focus on your team and teammates, the next step is to familiarize yourself with the code-bases managed by the team.

Understanding Each Repo’s Structure and Patterns

The first step for learning a new code-base starts with comprehending the general flow, patterns, and directory structure of the projects within your team’s GitHub organization. These fundamentals will allow you to begin taking on smaller sprint tickets with a general knowledge of where to begin the implementation.

Ask your new teammates where they might start and if they have any tips for understanding it faster. High-level overviews can be very helpful in this step.

Take Time to Review the Code Base

Every development team has different build processes and team conventions. By utilizing the time during onboarding to look through and note questions to ask teammates, you can avoid early mistakes that will be caught during your first PR submissions. Over time you will become more familiar with the different features of the app you support and the nitty-gritty details of the code that makes them happen - starting small at first works wonders in this process.

If it helps, creating mind maps or diagrams visualizes the new flows.

Days 60-90: Getting to Know the Resources and Processes

Now that you’ve taken the time to learn the basics of the code you’ll be working within the role, it’s time to start taking on more complex features. You should have a good idea of areas in the codebase you might not be familiar with, for example, a new framework or library.

With most of my experience with Polymer and React before starting at Disney, I had to pick up Angular quickly to be able to contribute features on the front end - taking a training course made this much easier, and thankfully my manager gave me the time to do so during the first 90 days.

Completing the Plan

Starting with a plan that has buy-in from your manager helps us accomplish important objectives by the end of the first 90 days.

You will have a stronger bond with your teammates, understand team processes, and a fundamental understanding of the applications you now help support.

Ramping up quickly and showing that you can be part of the team helps us blend in, which you should be doing before standing out!

Blend in Before Standing out

There’s an interesting story about Jacques Pepin, a world-renowned chef who took a job deciding the menus at Howard Johnson’s, over an opportunity to be the White House chef during the Kennedy administration.

With a reputation to get such a job, on his first few days he could have gone straight to the menu creation. But instead, he wrote about his approach in The Apprentice: My Life in the Kitchen:

“...Mr. Johnson rightfully felt that if I was going to be designing menus for his chain, then I should have a first-hand understanding of how things worked on the line in the biggest and busiest HoJo's in the company. Fortunately, I knew the cardinal rule of getting on with one's fellow cooks. It applies in any kitchen and can be summed up in two short words: bust ass.”

The takeaway from Jacques Pepin and his story is this:

Before you start suggesting improvements and workflows, switching up code standards, or mentioning the things you don’t agree with on your new team, first take time to blend in and find out why things are that way. Show you can contribute to the code base and earn the respect of your teammates as a technical expert first, before starting to suggest large improvements or state gaps you see.

Building up this credit will allow you to start introducing improvements in the future, at the right time, with the respect and credibility required to get them accepted into the team.

Wrapping Up

Ramping up in a new job sets you up for long-term success in the role. Setting an intentional plan and delivering on that plan inaugurates your first impressions on a positive note.

It’s obvious these days that changing roles and teams is part of our career, so having a plan and taking advantage of the first 90 days makes a huge difference each and every time!

Honeypot Cult Article: What Happened When Our Tech Lead Left the Company

Kaleb M — Thu, 26 Nov 2020 00:00:00 +0000

This article was authored as a contribution to the Honeypot Cult Community- you can read it there too!

After graduating from GE Healthcare’s IT Leadership Program, a two-year rotational program to help members learn through experience, my first role was a Full-Stack Software Engineer working on manufacturing productivity applications.

Manufacturing Productivity Tools

Our team managed a suite of internal web applications that endowed shops around the globe with productivity gains. We facilitated working faster and smarter through our products and constantly improved them each sprint as users suggested improvements that made their jobs easier.

Our frontend applications used Google’s web component library called Polymer. It promoted strong re-use throughout our various applications and helped keep consistent, simple design patterns. We took advantage of components from GE’s internal component library and developed our own in an effort to truly modernize and modularize our development processes.

Much of our app suite’s success can be credited to these two elements (Polymer and user feedback); which in turn created our flexible development culture and set the stage to test new ideas quickly! Thus, two-week hackathons were introduced!

Hackathons gave both developers and product teams an amazing opportunity to test out new product ideas, determining their feasibility from the tech and user experience perspectives. Our hackathons were a huge success for exploration, and it was at one of these hackathons this story begins in earnest.

A New Hackathon Project – TAKT

One of the ideas submitted for a hackathon product was real-time Takt tracking.

My first step when evaluating this idea of course was to google what in the world Takt was.

What is Takt Time?

From Wikipedia: “Takt time is a manufacturing term to describe the required product assembly duration that is needed to match demand.”

In other words, shops could track how their actual completed cycles were matching up to what they expected. If an assembly line was supposed to complete one pencil every hour, and that line was running for 8 hours a day, then they could reasonably complete 8 pencils per day.

SOURCE: PROCESS STREET

Takt time tracks progress in real-time, meaning line managers could make data-driven adjustments as needed due to unexpected issues, such as running out of materials or a fire drill.

The idea itself manifested into a project for the hackathon, we received designs from the design team and got to work!

The Hackathon

We had two very experienced team members who were in charge of the architecture of the suite. Naturally, they helped every team author initial design diagrams for their hackathon projects.

My manager assigned me to the Takt team; typically, hackathon teams consisted of 4-5 members, but ours only consisted of myself and two experienced team members. With designs and architecture complete, we were ready to deliver the Takt Proof of Concept by the end of the two-week mark.

The hackathon started in a whirlwind of effort. I worked on the frontend with our lead frontend developer, while he worked with our backend lead to making sure the data contract was correct.

We were focused and hacking away, excited to see where the product would land!

Those two weeks went by like a blink of an eye, we started and one blink later the hackathon had reached the end of the second week. That meant it was presentation time!

We loaded up two browsers pointed to our dev environment, excited to share yet nervous it wouldn’t work with everyone watching. We talked through the project, what Takt was, and demonstrated creating a new Takt plan with the same scenario mentioned above.

The screen showed the Takt clock count down and the current status of 0 out of 8. My teammate clicked the complete button and we saw the 0 tick up to 1 on both screens: 1/8 complete! It worked!

We felt like the dream team winning a championship! Takt was tracked in real-time across browsers – no reload required!

We felt like the dream team winning a championship!

App Lead Leaving Company and MVP

The successful hackathon presentation led to the product team asking for a Takt MVP soon after. We broke down the work involved via user stories and started work on them immediately in our following sprint.

It was around this time that we learned of our app lead deciding to take on a new opportunity. We were excited for him, although Takt had officially lost its tech lead and we had lost our most productive team member.

“Who would lead Takt going forward and how would team members' work be split up?”

With my experience working on Takt through the hackathon, my manager asked me to step up and take lead on Takt; additionally, some of my teammates would be 100% focused on helping to develop it too!

We were ready to grow, learn, and enjoy the new opportunity!

Leading the Project

Being an app lead on a new application granted many amazing experiences and lessons for me.

With a new product, users gave feedback quickly, meaning lots of iterations and changes as it matures. Secondly, visiting manufacturing shops using the Takt app, and learning from their feedback was an absolute blast. We learned how different shops sometimes had different processes, so we decided on a configuration-based architecture. Lastly, our Software Team as a whole was new, processes and standards changed regularly. We were able to shape them to work more efficiently.

Upholding Team Standards

Since we had less legacy code with the newer app, the slate was clean to easily meet team standards without much tech debt work required.

Here are the three main application-level standards we upheld:

Implement ESLint and SonarQube
Code Documentation (JS Docs on all methods and components, and architecture and business cases documented (not always in detail, but high level at least))
Unit Test Code coverage at 80%

The Takt team partnered with the product to allocate time as we made sure these standards were upheld on our project – this was one of our proudest achievements as we eventually took on new app projects or roles.

Implementing New Features

Learn by doing – it’s a vibe! Leading the architecture and design decisions in the lead role for Takt helped me learn often through action. We made decisions as a team, brainstorming, diagramming, and weighing the different options against each other. It was the consequences of those decisions, both good and bad, that we learned the most from!

I believe in a principle-based decision-making style. We tried to adhere to the following:

1. Keep our architecture modular

2. Working and improvable, not perfect

3. Enable or leverage re-use across our app and our suite

4. Performant and reliable

With these in mind, we weighed different options to make decisions based on obtaining the best results on our principles. This helped us follow the wise words of Boomi from Avatar the Last Airbender: “Instead of seeing what they want you to see, you gotta open your brains to the possibilities”, because we looked for solutions that best met our principles together!

Concluding Thoughts

Spending two years at GE as a Software Engineer introduced many wonderful experiences into my career.

GE Healthcare manufactures equipment that saves lives – I visited some of these shops and saw how the manufacturing processes led to the fantastic technology hospitals and doctors use every day.

There were tough days during my time there, maybe we had an outage, or Takt had a difficult bug or requirement to solve for. There might have been tough tradeoffs and architecture decisions to make without clear cut answers. Our agile processes evolved and changed to help complete tasks on time as priorities changed for the business.

The role of app lead can be stressful during tough times, but being part of something larger than myself, something that helped save lives, gave me the inspiration and motivation to get through those days. The experiences from my GE Software Engineer days are ones I will continue to cherish, and the team we had was so much fun to be a part of!

Honeypot Cult Article: The Importance of Team Standards... Or Not?

Kaleb M — Wed, 11 Nov 2020 00:00:00 +0000

Duke University’s basketball coach - Mike Krzyzewski, also known as Coach K, has an overall record of 1,157 wins and 370 losses at Duke and has coached the USA men’s national basketball team to a gold medal in the Olympics.

He’s won many coaching awards and has watched his players win many others, sometimes becoming NBA basketball stars or coaches themselves. His accolades prove that he will be known as one of the best college basketball coaches in history; now this is someone to learn from!

Why standards > rules (Coach K)

When listening to Coach Mike Krzyzewski speak at a conference one year, I learned of a fascinating activity that he does every year with his new team. He gathers everyone together to create team standards. They do this by first brainstorming a list of standards, followed by all players voting to agree on the ones they believe in most. Agreement is only the first step, each team member and coach must be held accountable to the accepted ideals – not only by coaches but by each other.

Here are a few examples:

“All players and coaches will arrive for practice at least 30 minutes before start time.”
“When speaking, we will always be honest with each other even when it is challenging.”
“We will always treat each other with respect.”

Coach K wants players to feel part of the culture they create. If coaches dictated the rules, now they are just something to follow because coach said to; instead, by creating standards as a team, everyone plays their part in upholding them!

My favourite anecdote from the story was when he mentioned doing this with the Olympic team – could you imagine creating team standards with people like Kobe Bryant, Lebron James, and other top competitors in the world? Incredible!

Basketball vs Dev Teams

It’s quite obvious that software engineering teams have stark differences compared to basketball teams, but there are certain rules that we observe in both.

The delineation of rules vs. standards hit home for me from Coach Krzyzewski, because as a dev joining a new team, we usually join a team that already has standards or rules to follow that were created before arriving. This leads to following standards you might not agree with or haven’t had any say in.

It’s easy to see how frustrations can occur in this scenario.

Being asked to uphold something you didn’t agree to can instigate internal team conflicts and tension. The “five whys” mental model comes to mind to help resolve frustrations quickly: we must make an effect to first learn the “why” before suggesting a change or deciding against following a specific standard.

If standards on ever-evolving teams can cause conflicts – what’s the point of having them?

Why Do We Have Standards

“Alone we can do little; together we can do so much.” – Helen Keller

Each product built by software engineers has different requirements, structures, frameworks, and methodologies cobbled together by a team. Standards are there to help team members stay on the same page , work together effectively, and create consistency throughout a codebase.

We can use them to keep code formatting consistent and readable or restrict certain antipatterns from being used as best practices are determined. Code reviews can focus on the right things as linting automates catching the little things since rules are configurable and agreed on by the team. Lastly, they help us hold each other accountable to write code to the best of our ability, because it isn’t one person’s code, it's all of ours, and by holding each other to a high standard we make that code base stronger.

Overall, having fundamental principles to believe in and uphold helps teams accomplish much more together than apart.

A Few Common Standards in Web Dev Teams

Story Pointing: Fibonacci sequence or -shirt sizes.

Linting: ESLint to check against established linting rules while we code, commit, or push up to GitHub.

SAST Security Scans: Using static code analyzers for security risks with technologies like CheckMarx and fixing all issues above a certain risk (like medium).

Design Patterns or Language Features: Do we prefer to use React Hooks or Class Components?

Directory Structure: How do we structure our directories for util functions or global typography classes? How do we name files? Determining these beforehand increases productivity for all dev team members.

Code reviews: How many approvals before merging? Automated pipeline checks like tests and linting before allowing merges.

Discussion / Respect: How do we discuss new architecture options? We always must treat each other with respect when discussing different options.

The list goes on and on, right? In my experience these things continually evolve over time – we must record those changes as time goes passes to keep everyone on the same page.

Do standards matter

Should all products or teams use strict standards? Like most things in our profession – it depends.

Each project is different – my belief boils down to three main factors to determine the strictness required:

Project size
Number of developers on the project
Business risk on malfunctions

Overall, by using the three main factors, one can easily decide on the strength and need of team standards for a software project. We want to move fast to deliver features, but not so fast we create a swamp of code that is impossible to change quickly.

Let’s go through some common project types:

Proof of Concepts

Proof of concepts with throwaway code like hackathon projects do not need standards, they need to work by demo time.

Side Projects

Side projects with one or two developers that aren’t for commercial use or with intentions to scale out in the future – then you probably don’t need that strong of standards.

Small to Medium Projects

It’s difficult to size applications because they vary. I’d consider small projects to be a small To-do app similar to those used in many tutorials. Medium is decent-sized projects, but when compared to something like G-Mail or YouTube, they pale in comparison.

Large Projects or Highly Impactful Code

When working on a large product like MacOs or Android, working with many developers, and having a huge impact if a bug affects users, then you will want very high standards. Code should be rigorously reviewed and tested to make sure no impacts on the user will occur.

How can leaders use standards effectively

First and foremost, standards should be created by and for the current team.

If people leave, or new members join, the standards should be reviewed and accepted again. I believe that similarly to Coach K having a new team each year (even though many players are returners), development teams should follow his lead.

Strong principles help drive decision-making based on outcomes instead of opinions because many times results can be measured and objectively decided upon based on those fundamental ideas to uphold.

Teams are able to accomplish so much together that individuals would not be able to.

By having stronger team bonds that we hold each other too, the team works better together and each individual feels part of something bigger than themselves – not only is this inspirational in of itself – but additionally, it helps us work well together!

Leaders should facilitate authoring standards for their teams , doing their best to uphold and evolve them appropriately over time.

If Coach K believes standards are important for winning championships, I believe that standards are important for delivering products that help change the world.

Honeypot Cult Article: Data Lake life: Going from Zero to Two Billion Rows of Data in Six Months

Kaleb M — Mon, 12 Oct 2020 00:00:00 +0000

This article was authored as a contribution to the Honeypot Cult community - you can read it there too!

Upon graduating from James Madison University in the states, I continued my early career in GE Healthcare’s Information Technology Leadership Program (ITLP). The program develops young professionals into next-generation leaders at GE through on the job training, leadership experiences, and mentorship from top professionals.

Every six months over the program’s two-year span, I rotated onto a new team and new project within the IT organization. I, along with my fellow program members, was expected to ramp up quickly and deliver on commitments by the end of each rotation. The program allowed us to experiment with different types of roles and technology to find potential long-term career interests.

This program wasn’t unique to GE Healthcare; it was part of every business within GE’s portfolio, such as GE Aviation or GE Power, with members representing their businesses in different locations. Typically, program members started at and graduated from the same business where they took on their first after program role.

A unique opportunity came up during my second rotation. If I accepted, my 3rd rotation would be in Cincinnati, OH for six months as part of the GE Aviation business, allowing me to meet new people, learn a new business, and venture to a new city.

I was ecstatic to accept!

The New Project

Originally, my role in GE Aviation was focused on project management to implement technology at various manufacturing shops – this quickly changed when arriving on my first day.

Instead of one program member aligned to one project, a group of us would be part of a team of teams experiment.

Six members of the IT Leadership Program would work with members of the Operations Leadership Program (OMLP) as part of a larger project effort. With leadership support, we were tasked with revamping the data lake processes to ingest manufacturing system data – as quickly and efficiently as possible.

That was all that we knew and all that we were told that day.

From Storming to Norming

We understood that there was a large amount of work and not much knowledge about how to do it yet. We didn’t know our operating mechanisms, our contacts, or priorities – only that they would come soon.

Storming Stage

Immediately we had questions.

What has been done before?
Where does the data come from?
How are we going to manage work?
How can we assign tasks?
How can we keep leadership informed and let them prioritize effectively?

The answers led us into our storming stage, where we decided on using the scrum methodology to manage tasks and roadmap.

Our first objective was ramping up, utilizing the various expertise and experience on the team to assign tasks, which gave us the opportunity to knowledge share later.

We learned that the data lake used Greenplum for data and our data loading (ETL) technology was Talend. Further, we established how we would interact with supply chain data teams and how we could get access to the data systems.

Once our internal processes were finalized, we commenced development on our MVP Talend job by the end of the first month. Two weeks later, the team had collaborated through challenges to pass initial testing – we could load test data into the data lake!

Outside of our small team of six, the larger team (OMLPs) and leadership partnered with the functional teams to prioritize data sources; and, it was thanks to this effort, we could then reach out and begin iterating on our process for onboarding new systems into the data-lake.

Hear hear! Let the real data ingesting begin!

You can imagine what happened once we attempted to ingest data from a real system: the bugs attacked!

We immediately started iterating our Talend jobs: update and test, update and test, until finally…

We loaded our first rows of real data into the data lake! A major milestone!

But we weren’t done yet…the data party was just starting!

Norming Stage

With our first real data system ingested and processes normalizing, we were ready to begin our norming phase. Don’t get me wrong, retros still enabled continuous improvements – just not huge shifts like changing from scrum to waterfall. Our fundamental processes stayed consistent throughout the last 3-4 months of our rotation.

Sure, we had new job updates to improve the data load time and items, but our main focus shifted from learning to executing!

Like the long hand of a clock ticking off each second, our onboarding process and communication mechanisms between all of the teams were in constant forward motion.

The functional team tackled which systems were most important, while the data teams began finding ways to use the data. Leadership support was constantly helping us move faster by removing roadblocks – enabling more and more data to be ingested at a faster pace.

We were running full steam ahead!

Results

Day after day, more and more data was loaded via our jobs on various schedules. Some data was loaded daily, some weekly, etc.

At the end of each sprint, we presented a data chart showing the number of total rows ingested into Greenplum. It went from zero to one hundred thousand, from one hundred thousand to one million, from one million to one hundred million, and kept going!

The numbers accelerated as the prioritized systems were marked off the list. Before the rotation’s last sprint demo, we began to analyze our ingested data totals once more.

2 billion rows! We couldn’t believe it!

How does a team of teams project go from zero rows of data to two billion within six months?

I will tell you how – teamwork, prioritized work, innovation, and focus!

Plus, some fun along the way :).

Lessons

Teamwork vs Individual Contributions

The ITLP team had experiences ranging from project management, business expertise, web development, and Java.

Our team leaders were fantastic at keeping us updated and communicating between all of the different stakeholders on schedules, timeline, and work involved.

Executives came to our stand-ups as they offered help to speed us along.

We interfaced with contractors, data lake team members, and our colleagues in OMLP as we all rallied around the main goal: get data in the data lake and get it in there fast!

There was no doubt hard work correlated with strong results from this adventure, but it was empowered by all of the amazing partnerships and experiences from the teams working together!

Priority Defined Work

The data lake initiative was colossal – even after checking in on the team a year later, it was still on-going. There’s always more data, more transformations, and more value to add.

The size exposes just how much potential work there was, thankfully we had it prioritized.

Because of prioritization, we took on chunks of work each sprint that added the most value to the business.

Innovation and Focus

All teams involved with the simple problem statement were focused on doing just that. Leadership helped remove the extra noise, and we collaboratively innovated to make it work on the technical side.

It’s always amazing how quickly a problem leads to results when you give people time to focus on discovering a solution.

Wrapping Up

The six months spent in Cincinnati were six months that won’t be forgotten. The lessons and memories of those days continue to shape the way I approach problems today.

There are moments in our career where we are working on large impactful projects, with fantastic coworkers, all having so much fun. Unfortunately, they also come to an end, so we must take a second to recognize those moments and enjoy them to the fullest!

This was one of those moments – we all definitely enjoyed it!

Angular Lightning Quick Tip: [ngClass] and Compound Logic

Kaleb M — Thu, 16 Jul 2020 00:00:00 +0000

An interesting question came up in a pull request recently that led to a new TIL when dealing with ngClass in Angular, so I thought it would be worth sharing.

ngClass Overview

When creating components in Angular, it's common to change classes on particular HTML Elements in your template based on variables or logic. [ngClass] handles this for you.

<div [ngClass]="{'one': shouldHaveThisClass}">Random div</div>

When the class property of shouldHaveThisClass has a truthy value, then the class of one would be added to the div.

In interactive web apps, you can see why this feature helps us out.

NgClass Documentation for more details

Compound Logic

What happens when multiple classes are used and how does Angular decide which classes to add?

// template class
// editMode = true;
// isPrimary = true;
// isSecondary = false;

<div
  [ngClass]="{
    'edit': editMode
    'primary': isPrimary, 
    'primary-edit': isPrimary && editMode, 
    'secondary': isSecondary,
    'secondary-edit': isSecondary && editMode
  }">
Random div
</div>`

What class or classes would be added to our div here?

The key line from the Angular docs:

"Object - keys are CSS classes that get added when the expression given in the value evaluates to a truthy value, otherwise they are removed."

No precedence rules are used here.

All classes would be added that have truthy values: edit, primary, primary-edit.

This was a great question and something to keep in mind when designing our components in the future to make sure the right classes with the right styles are used.

Honeypot Cult Article: Find Yourself a Mentor and Let Them Change Your Life

Kaleb M — Tue, 07 Jul 2020 00:00:00 +0000

This article was authored as a contribution to the Honeypot Cult community - you can read it there too!

Growing up in a small rural town taught me many values that I believe make me who I am today.

Sports were a significant part of that culture and being part of a family with many great athletes, it was natural to follow suit. Athletics introduced me to many values that are still critical in my life today: deliberate practice, strong work ethic, teamwork, integrity, and humility.

Summers brought in the joy of swimming and fishing as we hopped in our canoe for a journey floating down the river. Winter meant snowball fights, snow-shoveling, and hot cocoa nights. Since there wasn’t much to do, we learned to appreciate the little things: nature, community, and patience.

I’m thankful for the small-town life that taught me so much through my younger years! But there were two pieces missing from it – corporate life and professionalism.

Transitions

Entering the corporate workforce introduced to me a new environment, one that I had no experience working in before.

The transition from college student to corporate life:

I was honoured to be chosen for an internship at a medium-sized company (~700 employees) in my college years. I felt behind as my knowledge of professionalism was low and my experience was even lower at that time. My new manager, Matt, was a joy to work for and the team I was working with was so helpful.

I trudged on through the projects assigned to me that the first summer, with the help of my teammates, they went well and the team invited me back the following summer! I was able to work on different projects throughout my college years part-time, leading to a full-time position offer during my last semester! I was exuberant!

The transition from medium-size to Fortune 100

Around the time of my college graduation, I accepted a new role in GE Healthcare’s IT Leadership Program. This would give me the opportunity to work for a larger corporation and learn from top leaders in the Healthcare industry.

During my first two weeks, we had the opportunity to learn from program members as they presented on how the program was run, what to expect, and how to be successful as a program member.

My first 6-month rotation was in Project Management - something I had never done before. I had no idea how to run conference calls or set up real project plans. I was learning how to network and conduct meetings with different colleagues. It was hard to say no to extracurricular activities as a new employee and presenting in front of people was not a skill that I had much practice at.

You could say I had quite a lot to learn. I needed some help.

The two transitions above were the largest by far in my life - both having many moments of discomfort as I grew through a new experience. I had no idea what to do at times and quickly recognised that others could help. Thankfully, they were up for sharing their knowledge - my transitions were successful due to having great mentors help me throughout my journey.

Mentors are Important

Experience: one of life’s greatest teachers.

There are others in your organisation who have experienced similar situations that you’re currently going through. They have the skills you want to develop and can help you get there. They have perspectives that are vastly different than yours because they have lessons that were created from mistakes; mistakes you can now avoid if passed down to you.

These wonderful people full of wisdom within your organisation are all in reach - it just takes a little courage to ask for help or set up that first meeting!

Find people you aspire to be

Mentors offer you their stories, experiences, and knowledge as you navigate your career. You can allow them to be a sounding board, guiding you down the path that’s best for you and urging you to get out of your comfort zone.

Mentors are veterans that want to pass the torch of their success to you!

Internship Example

During my internship, I learned the value of forward-thinking and learning fast from one of my senior teammates. He was professional, humble, and respectful to all while dealing with tough deadlines in an intense project. He was always able to lend a helping hand to me and take on tough tasks for the project to help the business. I learned how vital people are for different aspects of projects. He mentored me throughout those years, and many of the characteristics that he demonstrated were things I respected and aspire to be every day.

GE Example

My program manager at GE could quickly demand the respect of the room through the power of her voice and words. She expected you to be great and as a mentor, she offered time to help you get there. I recall presenting a run-through for a presentation to CIOs to her, and based on my performance, it was clear I wasn’t ready. She offered me to set up a time with her to practice a presentation to our CIOs - which of course I did. Susan could be tough on you, but she was also the first one giving praise on a job well done. She knew how to lead and impact the lives of those in her program and gave opportunities for everyone to grow.

She absolutely changed my life.

It was apparent after meeting with her a few times that this was someone who had traits that were admirable. How many people do you know who have people who they managed calling them for advice 20 years later?

Ask For Mentors

I believe that the mentor and mentee relationship is much more successful when there’s an admiration factor. It's easier to listen and believe in the advice given by someone you admire and respect.

Choosing the right mentors makes a huge difference in the advice and lessons you can take away. Once you identify a potential mentor - set up a time to meet them and learn their story.

If there is a connection and the moment feels right, have the courage to ask: "will you be my mentor?"

This solidifies it and gives the mentor a chance to make sure they are in it, too. Now you must build.

Building the relationship

Strong relationships take time to build because they require trust, self-disclosure, and effort.

Here are a few tips that can help:

Learn their story - where are they from and how did they get to where they are?
Tell them your story and how you got here
Set up meetings with your mentors to check in--typically quarterly via lunch or coffee
Be prepared for meetings--agendas are essential when asking for someone's time. If you have no reason to meet then don't waste someone’s time
Trust and listen
Ask questions and tell them how you’re doing
Ask for advice when a situation comes up you’re not sure of
Be kind and respectful

Building a new relationship means building new trust and making the time for it to grow. Asking someone to be your mentor means that both people are now committed to growing that relationship, time will do the rest!

Concluding Thoughts

Transitioning from country town life to full-time employee at large corporations has been an absolute blast. I’m very grateful for the amazing people who took time from their responsibilities to teach, guide, and constructively criticise to make me a stronger professional; without their guidance, I would be learning many of the lessons on my own.

Finding a mentor that has the characteristics you strive for makes a huge difference in your career. I urge you to start looking for one today.