Forem: Kim Arnett 

Let Us Code

Kim Arnett  — Tue, 02 Apr 2024 17:47:52 +0000

The underrepresented don't want to solve the gender gap, the inequality gap, the hushed sexism and racism in side conversations, comments and "jokes". We don't want to worry about how someone will interpret our outfit, our hair, always choosing a careful set of words to be met with disrespect anyway.

We want to be wholly in our jobs, in our work, and have peace at the end of the day that we put our best forward and made a difference in someway. We want to be equally supported by our managers, by our team, and feel like we belong here.

The truth is, I've made it my personal vendetta, erm, mission since 2014, and burnt out so bad it took almost three years to heal. I addressed everything within my control for every excuse that was ever given of why underrepresented people can't thrive/survive in tech. I've watched my fellow women coworkers go above and beyond to be taken seriously, my Black and Brown friends get called some horrid things in the office. I've also had some pretty disgusting sexism shared right to my face, and all of this within my first two years in tech (and of course on ward as well).

They said people weren't in the interview pipelines, I worked on creating blog posts for fixing interviews from both sides of the table. They said people weren't negotiating well, through my meetup LaDev, we had a negotiation and financial wellness session. For every excuse, I had at minimum a blog to address it. At most, I had a session through LaDev, and in some cases even presented at meetups or conferences sharing my knowledge.

While I'll acknowledge the majority of my impact was local, I wasn't the only one pushing forward. Through conferences I met so many wonderful individuals with my same passion for improving things.

Fast forward to 2024, I'm now in a leadership role where I can provide equal opportunities to my team, ensure my interview process is fair, and hope for a ripple effect as other people take note and ask for my input in improving their own. It's not lost on me that my team is an anomaly. I want to keep moving things forward, but I've learned an important lesson.

It's going to take more. This is systematic change we're trying to push for. While things are better, they are not equal or fair. We need leaders who care, and new leaders to help others rise and thrive in tech.

So here's my challenge to the tech world: do better.
Be better than you were yesterday, push your leaders to be better than they were yesterday, and don't settle. The road is long, sometimes difficult, unbearable at times, definitely lonely, but anything worth doing is.

Let us code, for we are freaking tired. <3

What 2 years at Expedia Taught Me

Kim Arnett  — Mon, 25 Apr 2022 00:49:58 +0000

Hey there! It's been a while. As a matter of fact, over a year since my last blog post. Since then, a lot has happened, and I've had a lot of time to reflect on it all! That's another post for another day, but today I want to talk about my experience working at Expedia Group and some of the lessons I learned.

I joined Expedia in Ann Arbor, Mi, in the fall of 2017. Their office (which many, including myself, didn't know existed) began as a young startup called Mobiata that had been acquired early on. That's how Expedia A2, as we lovingly called it, came to be. I thoroughly enjoyed working here; it was indeed a dream job. Not that I'm head over heels about travel, but every person I worked with cared. I didn't know it then, but it made a world of difference from the team environment to the product we built.

Lessons Learned

Interviewing

The interview process was exceptionally refreshing compared to the other interviews I was going through at the time. During the initial phone interview, I had an anxiety attack resulting in extreme brain fog. I was asked about unwrapping optionals in swift and completely blanked on the guard statement, which was ironically my favorite. The interviewer understood and helped guide me to the answer, which allowed me to highlight how I've used the statement to clean up nested if statements in a codebase I was working on recently. Other interviews would have just moved on and written me off. The last phase was a half-day in-person interview to meet the team, the manager, then go through a round of whiteboarding, a live coding session and team lunch. It was long, but it taught me the most powerful lesson about interviewing that I've applied to every role since. Every step of the way, I was never alone. Whoever was interviewing me worked through the problem with me. If I was stuck, I could ask questions or clarification. If I wanted their thoughts, I just asked. Expectations were made clear every step of the way. This is a pairing exercise; we want to know how you work with us, not just on your own. Yes, problem-solving was needed, but this interview was the first process I went through that reflected the team environment.

One Team

"One Team" was a mantra used to drive home that you're not alone in success or failure. Everything we did was as a team. I chose to highlight this mantra because it resonated with me and was evident up the leadership chain. Not only did I feel connected to my leader and his manager, but our benefits were great, our leave was terrific, and no matter what life throws at one of their employees, it seemed like they had your back.

"One Team" also echoed out into the community. One of the perks was a volunteer day, where anyone within the office could attend a local volunteer event to give back to the community. One year we cleaned up invasive species in a local park, and the next was sorting produce for people in need. This forward approach was a refreshing take rather than the typical hands-off monetary match most corporations offer.

When your team and your company are invested in your health, happiness, and community, it makes going to work and putting your best foot forward every day an easy choice. It's been two years since Expedia A2 closed, and I still stay in touch with almost everyone.

Mistakes Happen

While I truly loved my time at Expedia, nothing is perfect. There was a value of "assume positive intent". While it was new to me, it made absolute sense. The more I worked under this model and talked with other people about their lived experiences, the more I realized it was doing more harm than good. While I'd work with many of my co-workers again in a heartbeat, it became evident that some would count on this value to bail them out of their bad choices, conscious or not. The pattern of behaviors made it clear that this was their survival method of staying with the company. As an example of this harm in practice, a prominent lead in the mobile space had a habit of my-way or the high-way. They would listen but were also so wrapped up in their thought process that it never really felt like the opposing thoughts were considered. There were conversations within the greater team to get your changes in before they came online, which is never a good sign. My biggest lesson here is while it may seem like something or someone has good intentions, look for the patterns. As a business, constantly get feedback on your practices and values. When someone says they are experiencing harm from something in place, listen, then act to improve it.

Stay Humble

Working for Expedia was exciting and enough of a toe-dip into the "Big Tech" scene that it was still a good experience. I truly loved the work we did, the product we built, and the team environment we fostered. I didn't consider that it could all change within a blink of an eye.

Expedia went through mass layoffs early in 2020 before COVID-19 tore apart the travel industry. While many excellent staff members were laid off, so was our entire off (small) office. Despite being one of the top-producing teams, and getting great reviews up the leadership chain, we weren't invincible. It didn't make sense to us, but it was just a numbers game. While I mourned the loss of a fantastic job, after seeing what the following year(s) gave the world, I'm thankful it happened the way it did. Without that, I wouldn't have gone for a senior title at my next job. Without that, I wouldn't have been one insincere review away from leaving tech and reaching out to a career coach and talent advisor to see what future I had. I wouldn't be where I am today without those happenstances, leading a mobile team and providing them with the same support and leadership I've enjoyed.

![A group picture of the Expedia A2 team hours after our office closed, at a local bar.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/luvn8h2pftgj3bsi8fjb.jpg)

Responsibilities of a Senior Dev

Kim Arnett  — Mon, 15 Mar 2021 16:50:35 +0000

I let Twitter select my next blog post, and 50% wanted to know what was it like in the shoes of a senior developer! I've been settling in to the title for the last 11 months, and I'm happy to share my experience and how my responsibilities have shifted from mid-level. All of this will be in the flavor of mobile development. The primary differences between mobile and web at this stage, from my perspective, is that mobile developers are also responsible for continuous integration and deployment.

This list is inclusive of my experience and what I've observed at other companies I've worked in. My experience is mostly enterprise app development. If your experience is different, I'd love for you to highlight your responsibilities in the comments!

Solving problems
I'm not talking about code! Things arise all the time that need immediate attention. As a senior dev, it's my responsibility to make sure my team is not blocked by anything, shine light on problems that will help get them resolved faster, or if it's in my wheelhouse, jump in and help out! It could look like an environment problem, a code problem, a build problem, a business problem, whatever it may be. It's my job to ensure things are moving forward, and waving the flag for attention if it's not so we can address it quick and effectively.
Mentoring
A big change for people as they go from mid to senior is they are the ones providing advice and guidance to their team instead of purely absorbing. A quick reminder that everyone is human and we're all sharing and absorbing constantly. For many, this is the first time they've really sat on the other side of the table, and it's great! You're responsible for shaping your new and junior team members to some day take your job. Or at least that's the idea, while you move on into architecture or management, or wherever your heart desires. It is your responsibility to ensure they have the support and tools they need to fully grow into the position and career.
Providing actionable feedback
This is a big one that will show up almost every day. As a senior engineer, you need to be driving the codebase, product and team in the right direction. Apart of that is providing actionable feedback to your teammates that will help reach the end goal. Whether it's official performance reviews, code reviews, pull requests or a pairing session - your feedback is necessary and crucial to your teams success. Learning how to provide feedback that is helpful is critical. Instead of "this could be improved" - elaborate. How could it be improved? What is the original author missing that could help them see the problem. Positive feedback fits here too! "I really like the way you took charge of that meeting" - we all need positive feedback to learn where our strengths are. Let your team know you appreciate them.
Keeping an eye on all the things
This one is a bit much at times, but it's really important to keep an eye on reviews, crashes, analytics, dashboards, abnormalities, test coverage, builds, etc. It's good to check in with your systems every few days to ensure everything's a go. Is code coverage trending in the right direction? Are unit tests functioning after that last Xcode update? Any new crashers with the latest release? Any bad events surfacing to the top, or an abnormal amount of unexpected ones? As a team, keeping an eye on these things will help you be proactive should a problem arise. In previous jobs, we found analytics and crash data to be a very valuable combination to use with our remote feature manager. With seeing a rise in crashes, we were able to take action and turn off a remote feature flag to ensure clients would no longer be effected.
Identify problems and feature planning
As one of the codebase owners, it falls on you to identify any tech debt or refactor spots, and come up with a plan to tackle them. It also falls on you to help architect features and plan for how long a feature will take, to help "business" requirements and expectations.
Build
Especially true as a mobile engineer, the build pipeline will likely fall in your court. Keeping your Continuous Integration pipeline happy, building out improvements, keeping the build passing and unit tests passing all falls on you (and your team). You can certainly share the responsibility, but you're ultimately in the driver's seat is what I'm saying.
Giving credit
This ties closely with number three, providing actionable feedback, but I wanted to call it out specifically here. When you're working with someone else and do a feature together, let them drive. Help them get to the answers, but don't do everything for them. Tied also with number two, mentoring, you're there for their success. Their success means your success, and your teams success means your success. But highlighting your accomplishments solely is (mostly) over. When you're driving a team, it takes everyone, and it's up to you to call out when people do good, when your team delivers, and the features you all flush out.

Thanks so much for reading, I'm really enjoying being a Senior iOS Engineer! While my imposter syndrome does get out of control some days, I'll share some wisdom that really has helped me this past year. Teams work because everyone brings something unique to the table. If you have a weak spot, someone else is going to have that as a strong spot. You don't have to know everything, now go uplift your team and get some stuff done. :)

Technical Debt, Maintenance and Buy-In

Kim Arnett  — Tue, 15 Dec 2020 02:22:12 +0000

Recently I did a blog about managing technical debt mountain and how to go about addressing it. You can read Chipping Away at Technical Debt Here.

That lead into a small discussion on Twitter about getting buy-in from product or higher-ups when feature development continually takes precedence.

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

I had to do some thinking, and reflection if I'm being honest. I've certainly run into this in the past, but remembering the details of a so-common occurrence was difficult. Once memories started flowing back, I had to then think about, was that the right approach? If faced with this situation now, what would I do?

Before you go out swinging to your leaders, take a moment and think about what needs to be done. Here's a summarized checklist from the original post, but please go read it when you're ready to start tackling this debt!

Define Scope
Plan of Attack
Attack!
Maintenance

Once you have scope defined, you can start on your plan of attack, by playing off the below scenarios that fit your situation.

As an example, we'll use a basic hotel booking app. The code in finding a competitive rate for a hotel has proven to be buggy in the past, and it's so old that it's using outdated frameworks. But the effort to update it has been too large to prioritize, so in the debt pile it sits.

When management doesn't care

This is probably worst case scenario, because it signifies there's more serious problems on the team. Another topic for another day perhaps. When you're faced with leaders that don't care about technical debt or project maintenance - you need to sell it, pitch it. This is where talking with money and hours comes in.

Identify the risks/facts.
- With lack of tests, and a code structure that's untestable, we will not be able to easily catch bugs before entering production.
- Outdated frameworks pose a security risk, with known vulnerabilities.
- Maintainability is decreasing with each patch.
- Scope is increasing with each patch.
- We risk losing customers over a poor experience, what if it double books, or doesn't book, or leaves a customer stranded with problems.
- With previous bug fixes, we've spent about 30 hours maintaining this code in the last month alone. That effort grows with each patch as scope increases.
Identify the solution.
- A complete refactor of this code would take about x amount of time with n developers dedicated full time.
- Refactoring this code will allow frameworks to be updated, removing security vulnerabilities.
- It would also allow the architecture to be fixed and we can add automated testing, ensuring that our core functionality will not break with each release.
- With tests, we'd catch problems before shipping software.
- This code becomes incredibly more maintainable and saves hundreds of developer hours in the future because the risks have been mitigated.

That's a pretty convincing argument.

The entire point is to provide quantitive metrics and the outcome in quantitive metrics where possible. You have to hit the company in the wallet. Paying for extra development hours or losing customers are both things that will hurt business.

It's also up to every maintainer on your project to push in the right direction. If your lead dev/team lead/trusted senior dev(s) is dragging their feet, you're not going to get the buy in that you're looking for. Again, larger problems. But even in the worst environments - if everyone is sticking to their guns, someone has to give in sometime. :)

When there's no time / not a priority

This started out as two separate scenarios, but they're so close, we're gonna group them together. If you're behind on features, it can be hard to find the time to fit in these maintenance tasks. Likewise, if everything else seems to be a priority, it's difficult to get these menial tasks to the forefront.

Bring addressing technical debt up early and often. If you see a break coming up between features, bring it up. Work with your leaders to come up with a plan to tackle it. 10-25% of the sprint to focus on technical debt might be a solution. One rotating "maintainer" that only focuses on technical debt is another. Or one sprint a quarter or two, that will focus solely on technical debt. The good news is, your leaders care, but the follow up is find a compromise that can prioritize features/enhancements while not leaving the rest of your project behind.

Wrap up

It's difficult to navigate these scenarios when technical debt mountain is running the show - SO if you're in a position, try to work in a plan with your leaders before you reach the point of no return. Otherwise, apply pressure often and frequently, like a wound. If all else fails, time to find some leaders that will care what their developers have to say. Whew, spicy. 🥵

Chipping Away at Technical Debt

Kim Arnett  — Tue, 08 Dec 2020 14:49:34 +0000

Technical debt is a natural part of software development. New frameworks come out, better ways to do things are found, SDK and languages updates are a thing, plus a hundred other external influences in your project. All of these things lead to old code that needs to be updated to keep on par with the new code your team is writing. If there's not a process to incorporate some of these updates and maintenance, it leads to an outstanding technical debt.

What is Technical Debt?

Technical debt is a backlog of tasks, code, documentation, frameworks or other "things" that need attention, and the level of effort it would take to clear out those to-do items.

Why Should You Care About Technical Debt?

As software developers, we all enjoy consistency within the project and cleanliness in our code. We don't enjoy referencing things we'll never get to, //TODO: marks, or //HACK: marks, or outdated comments. There's n number of things that could be applied here, but these are some examples of the most common I see. Anyway - if you're not addressing debt as apart of your process, it grows. It grows quickly, and before you know it - it's a large effort to make a simple change. Addressing technical debt keeps your project clean, team mates happier, and maintains the most updated information you have at that time.

Ok, Where Do I Go From Here?

The first step in tackling anything is defining scope. Talk to your team about what bothers them in the project. There are tools like Sonar that can get you started as well, identifying areas with low test coverage or duplicated functions. This step will vary team to team. I personally like identifying unused files, duplicated functions or functionality, and areas with messy logic where a bug is likely hiding.
Once scope is defined, the next step is plan of attack. This will vary from team to team. If you need buy-in from the requirement side of your job, have those conversations early and often. Pulling 1-2 stories in your sprint to start should be an easy goal without much implications to the requirement goals. Remember, this isn't just a nice to have, cleaner, consistent code is more likely to be bug free, tested, and easier to maintain in the long run. A few hours now will save hundred of hours in the future.
Attack! As you're knocking out stories, whether outside of the sprint as you can or apart of the sprint, document any other problem areas you find that could use a touch up. Add tests to anything you do if they don't exist, and if they do, yay! With existing tests, you'll have confidence that your refactor update didn't break anything. Which is why it's important to add them if they don't exist!
Maintenance - going forward follow the above steps to ensure you and your team are staying on top of any technical debt that arises. The beautiful thing about end of the year slow downs around holiday time is that there's often lack of features being built due to code freezes and everyone being on vacation. This is the perfect opportunity to make sure your code is in good shape for the new year!

That's it! Go on and make your projects beautiful and less stressful for future you. Report back on how it's going. :)

Preparing For Your First iOS Interview

Kim Arnett  — Sun, 16 Aug 2020 00:35:27 +0000

Congratulations on your potential new job! I know it's a super nerve-racking process, but this is a major opportunity for you to find a great fit. In the last few years I've helped juniors nonchalantly, and this question always seems to come up. Especially for those headed into a technical role for the first time. I hope to lay out the good and bad here, so you can go in ready to tackle it all.

When can I start interviewing?

As soon as you feel "ready"! There is no metric, no knowledge you can acquire that will get you there. It really is a gut feeling. Here's the secret: no one knows everything (we'll cover this more deeply below). When you feel confident enough and have some code under your belt - go for it!

Do I need a portfolio?

Absolutely not. As an interviewer - all I'm expecting is a resume in document form. Sometimes I'll look at code samples on Github if listed or a candidates website, but not all the time. I've found code on Github to generally be years old, and websites that don't highlight what I want to know about someone. Talk to me about what you know now, things you're doing to learn/grow, and where you wanna go in your career.

Should I wait to apply?

Nope! So many have waited until X happens, with X being "my website is ready", "my app is approved", "my app is recoded from the ground up because I don't like it (raises hand)" etc. If you're ready in your gut, then you're ready to hit that apply button.

What material should I cover before the interview?

This ones tricky because it's very dependent on the potential team you're interviewing with. So here's my advice - build a simple app in Swift with some UIKit controls, table, button, input. Then see if you can hook up to an API and understand the core components of that plumbing (Codeable / Decodable). This alone will give you great experience to show off and talk about. Observe pain points you had and how you overcame them, and talk about that in the interview if given a chance. You've proven that you're a self-learner and can debug a problem when you encounter it. Way to go!

What is the next step if I already have been coding?

That's great! I would encourage you to either publish an app or work on an open source project. Observe what people with more experience are doing, ask them why or research what maybe the reason. Example: Someone's using a guard statement, so you might look it up and notice it's a good way to unwrap an optional for use within a function. Growth, and you learned a fancy new way to flatten out some if statements.

What if they ask a question I don't know?

It's ok, and expected that you're not going to know everything! I wish I could get all the hours back that I crammed last minute knowledge, hoping to avoid this awkward scenario, but I've since learned to embrace it. Every year a new iOS version comes out - new features, deprecated code, new code, new architecture patterns, etc. Every year, and all year long I learn more and more. How can anyone keep up? You can't. So, you say "I'm not familiar with that - could you highlight it for me?" or "I'm not sure - but I'm going to jot it down and research it later" (then follow through).

What can I expect out of the interview process?

I've been in and a part of various interviews, and the process seems pretty similar among companies. My experience has been mostly corporate, where the start-up interviews have been more straightforward. Remember, you can and should always ask what the next step will be in their process.

Phone Screen - Here you may talk with a manager, some team members, a recruiter, or a mix of all three. Usually this is a casual conversation around your experience (yes, side projects are experience) and what you're interested in from a tech stand point. You may get some high-level tech questions here. It will vary off your experience, but some examples: "What's your favorite app and why", "describe the parts of an if statement", "when would I use ______".
Technical Screen - If your first screen is done without technical people on the call, sometimes this step will be there for a conversation with technical people. This can align with number 1, but include more tech-driven discussions.
Take home assignment* - This one hasn't been done in every interview, so hard to say what will happen. But I've had it before and after in-persons also! It's a real wildcard. Anyway - for this step, you'll be given directions on creating an app at home. You'll have so many days/hours to do it, sometimes it's timed over commits to git.
In Person / Virtual - Usually the last stage in an interview. With this new COVID world, results may vary. However, here you can expect to meet members of the team face-to-face, have some more discussions on your background, career aspirations, and get some questions around problem solving, coding, iOS as a platform, and more. This is often where white-boarding takes place and live-coding. Another post for another time - but if you find yourself in either a white-board or live-code session - Have a conversation with the people there about it. If you get stuck, ask for help or tips.

Unwritten rule of interviewing: Always have questions to ask. You can read more in another post of mine: Interview Questions You Should Ask

So there you have it! I hope this gives you a better idea of what to expect ahead of your new adventure and BEST OF LUCK in your interviews! You're going to rock it.

Class vs Struct in Memory | iOS & Swift

Kim Arnett  — Fri, 20 Mar 2020 18:02:45 +0000

Hey everyone, long time no blog! What better time to get back at it then between the two week span of being laid off and facing a global pandemic, am I right? So, to stay grounded I offered the following, in which someone asked a great question, that I felt like deserved a blog post instead of a quick response. Mostly because I have to remind myself of the answer multiple times a year. :)

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

Question is: Mutability in Structs vs Classes

If you're cruising around an iOS codebase, chances are you've come across some objects declared as structs, and some declared as classes. What gives? If you've googled for an answer, you probably found something talking about reference types or value types and other boring programming words. I'm going to cover the basics of what you need to know. If you want to dive deeper, by all means please do! Here's a great starting point from Apple's Swift docs on Structures vs Classes.

High level: Structs copy data, classes mutate data.

Let's experiment with structs:

Here I've defined a simple example, one variable.
Full playground example down below

struct exampleStruct {
    var varA = 0
}

If we create two instances of exampleStruct, we can see that changing one does not change the other.

var myFirstStruct = exampleStruct()
var mySecondStruct = exampleStruct()

myFirstStruct.varA = 100
print(myFirstStruct.varA)   //100
print(mySecondStruct.varA)  //0

If we assign the first struct to the second struct, we might expect that it would point to the same memory instance as the first struct, and therefore change with it. Let's see..

mySecondStruct = myFirstStruct
myFirstStruct.varA = 200

print(myFirstStruct.varA)   //200
print(mySecondStruct.varA)  //100

Whaaat. Actually what happened was the second struct took a copy of the first struct in a new memory slot. Meaning, it adopted the values that existed in first struct at the time of copy, but by saving them into a new memory slot, it copies/duplicates and therefore does not adopt any new values assigned to first struct.

Let's experiment with classes:

Another simple example, one variable.

class exampleClass {
    var varA = 0
}

If we create two instances of exampleClass, we can see that changing one does not change the other, same as structs.

var myFirstClass = exampleClass()
var mySecondClass = exampleClass()

myFirstClass.varA = 100
print(myFirstClass.varA)    //100
print(mySecondClass.varA)   //0

So far so good. If we assign the first class to the second class, will it point to the same memory instance as we expected before? Or will it copy like structs? Let's see..

mySecondClass = myFirstClass
myFirstClass.varA = 200

print(myFirstClass.varA)    //200
print(mySecondClass.varA)   //200

The second class pointed to the same memory slot as the first class object, thus aligning them to any values that change going forward.

mySecondClass.varA = 300
print(myFirstClass.varA)    //300
print(mySecondClass.varA)   //300

Thanks for checking this out! There are some other differences worth checking out, again a good place to start is the Swift docs linked above.

Full playground example here:

struct exampleStruct {
    var varA = 0
}

//STRUCT EXAMPLE - Start with two
var myFirstStruct = exampleStruct()
var mySecondStruct = exampleStruct()

myFirstStruct.varA = 100
print(myFirstStruct.varA)   //100
print(mySecondStruct.varA)  //0

mySecondStruct = myFirstStruct
myFirstStruct.varA = 200

print(myFirstStruct.varA)   //200
print(mySecondStruct.varA)  //100


print("-----------------")

class exampleClass {
    var varA = 0
}


//CLASS EXAMPLE
var myFirstClass = exampleClass()
var mySecondClass = exampleClass()

myFirstClass.varA = 100
print(myFirstClass.varA)    //100
print(mySecondClass.varA)   //0

mySecondClass = myFirstClass
myFirstClass.varA = 200
print(myFirstClass.varA)    //200
print(mySecondClass.varA)   //200

mySecondClass.varA = 300
print(myFirstClass.varA)    //300
print(mySecondClass.varA)   //300

The Various Levels of "Senior" | Satire

Kim Arnett  — Sat, 18 Jan 2020 16:06:40 +0000

I’ve been doing this for 20+ years senior
I’ve been here for 5, but my tech is only 10 senior
I’ve seen some shit senior
I watched a tutorial senior
I’ve done front end, back end, middle end, upside down end senior
erase it all and start again senior
10x senior
-10x senior
I started on mainframe senior
I’m still on mainframe senior
I read a blog post about it senior
I can Google senior
Stack Overflow is my doc senior
What's a doc? senior
Your code can't be trusted because it didn't come from me senior
I've brought down production senior

Keep it going in the comments below!

Cross-posted on my personal blog.

I Built My Portfolio With Wordpress

Kim Arnett  — Thu, 09 Jan 2020 15:55:42 +0000

Yup, that's right, and I'm not sorry either. Let me take you on a journey of building my portfolio and a few things I've learned along the way.

In 2012, while searching for my first developer job, it became apparent quick that if I wanted to gain the attention and trust of recruiters/companies, I needed somewhere to show off my skills. Not having a "portfolio" or really any real world experience to call my own, I decided to hold off until I had something to show for myself.

Lessons:

I SHOULD have shown off my school work and group projects! Any experience is valid experience and is worthy of being shared. Especially any pain points that occurred and how you overcame them, hiring teams LOVE hearing about how you've solved problems.

In 2014, I launched my first iOS app in the store. It was called Recipbee, and was a way for you to store and sort recipes on your device, without being forced to share with the world (hello, Pinterest). I built everything from the iOS app to the service, to the database and although it was rather buggy, I was extremely proud. I took this as an excuse to build out an official portfolio website and kimarnett.com was born. It was very basic, on the home screen was a screenshot of my app(s), the navigation bar was an opaque white to mimic iOS's design patterns, and the navigation linked to my Twitter, my resume, and my blog.

For 2 more years, I updated, managed, cared for this site.. and it honestly took a lot out of me. The kicker was in 2016ish when I found myself hacked. Not going into web development, I was pretty stuck on where to go from there. Eventually with the help from Twitter peeps, I got my site back to a working condition, and even made some improvements. It was then I realized, I really had no business limping this site along from my web education that essentially ended with my last web-focused role in 2014. I also had no time to spend days debugging problems as I had with the hack. Additionally, during a few job-searches I made some realizations:

Lessons:

Not one hiring manager, hiring team, recruiter mentioned, or asked, anything about how my site was built. They cared about the content that was on it, the apps I created and the blog I had. At this point in time, I still had web technologies listed on my resume, so it should have been relevant. Note: I realize my experience could be vastly different from someone looking for a job solely in the web realm.
As mentioned above, limping my site along on out dated practices wasn't helping anyone. I needed to find another solution that maintained itself and was more closely aligned with the content I wanted to focus on: Enter Wordpress.

As Developers, I think we get caught up into the details wayyyyyy too often. It's important to take a step back and analyze what's a better use of your time, and where the investment is worth it.

Today, my website is still sporting Wordpress, and no, it doesn't even have a customized theme. Maybe someday I'll get there, but right now, I'm solely focused on providing content through blogs and a store I'm building around my designs. Wordpress, although a curse word in some communities, has made it a stress-free task for me, and as long as it's meeting my needs.. I'm totally ok admitting my site is not developed by me.

How to Reach Out to Strangers on the Internet

Kim Arnett  — Mon, 07 Oct 2019 16:51:22 +0000

This post was inspired by some of your favorite online developer personalities, with addition to my own experience. PS) We don't hate you, promise. Adding a timely tweet I saw directly after drafting this blog post:
// Detect dark theme var iframe = document.getElementById('tweet-1181240987747667969-843'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1181240987747667969&theme=dark" }

Reaching out to strangers on the internet doesn't seem like a big deal, after all what problems can a simple "hello" cause. Let me stop you right there, and let's back up. I LOVE our online community, and I do my best to help people (without making it my full time job). But, a simple "hello" message will not get a response from me, or most others, but I'll say me for the simplicity of this post.

It's not because I'm rude, or introverted, or hate everyone. Nope, my DM's would not be open if that was the case. If I responded to every "hello", "hi" or "how are you doing", I would never get anything done. Ever... and I really don't have that many followers compared to your favorite online devs. So, if you really want to reach out to someone.. how should you do it?

Respect Their Time

That's it! Don't ask a question that can easily be Googled, or Stack Overflowed (we don't have time to debug your app anyway). Get right to the point. I'm 95% more likely to respond to a message along the lines of "Hey, love your work, I was wondering how you got to where you're at?" or "Hi, do you have advice around not rage quitting your job?" or "Hey, could I bounce some ideas off of you about (problem)?". By opening the message and responding, I know what we're going to be talking about. Otherwise, it's almost too scary to respond. Really.

One more thing to keep in mind - you may have been following me for a while, and you may feel like you know me pretty well.. but keep in mind, we are still strangers. Doesn't mean we can't be "online friends" eventually, but just that no relationship has been built yet. Yet. Thank you for reading this, I hope this post will help you in your journey to network, as it's helped me be apart of a great and safe community.

Tips to Become a Better Interviewer

Kim Arnett  — Sun, 06 Oct 2019 15:45:34 +0000

What tips do you have to be a better interviewer? I have a hard time following people's train of thought while they are problem solving. Also knowing what questions to ask.. basically I just freeze up like I'm the interview-ee. How'd you do it?

Imposter Syndrome, Anxiety && Me

Kim Arnett  — Tue, 06 Aug 2019 21:58:26 +0000

Hey there, it's me. It's been quite a while since I've posted, so I'd like to take this opportunity to dump a lot of thoughts, struggles and vulnerability. Please be kind as this is mostly my inner voice trying to help your inner voice :).

Pregnant Engineer?

If you follow me on Twitter, then you kind of knew what was going on. If you didn't well, SURPRISE! Things started slowing down for me around month 6 of pregnancy, aka January. Here's the truth - being a pregnant developer was completely uncomfortable. I waddled to and from meetings, had to wedge my belly under my desk or type at shoulder level, had to hide the pain in my face of being jabbed in the liver.. and let me tell you about trying to code with pregnancy brain.

If you haven't heard about pregnancy brain, it's essentially a decline of cognitive ability. There are no studies supporting this phenomenon, so clearly it's just something pregnant women have conspired together about. ;) So pregnancy brain made being productive very, very hard. I was struggling to compete with myself and what I was able to produce prior to pregnancy. Although my manager and team were incredibly supportive, I couldn't shake the feeling of letting people down.. whether or not that's really what was going on.

Anxiety followed me throughout my pregnancy and got incredibly worse as my due date approached. Anxiety over missing out while I was gone, being productive and pushing forward while physically not being able to keep up. The dr's appointments, the additional tests my situation required, it was all so much on top of trying to keep up in a forever-growing field.

Non-Stress Tests 2x a week for the last 12 weeks, meaning 💩 could have hit the fan at any minute, and these were supposed to help detect it. Not stressful.. what so ever. 😶

Pregnant Speaker?

Furthermore, I was accepted to speak at Codemash! Speaking at Codemash has been a goal of mine for the last few years. Going into it, I was excited to represent women in tech in a different light, and I did (and killed it btw). Checkout this front row capture and my awkward mid-sentence picture, raising the krakens from the presentation.

What I really wasn't expecting during this experience was the feeling of imposter syndrome (and anxiety) that kept haunting me. "What if I forget what I practiced?", "What if someone calls me out after mis-speaking?" (hey pregnancy brain), "What if Xcode decides it's had enough", and the worst one "Do I know enough about iOS to be up here?". Yeah - after upwards of 6 years that thought still likes to barge in my head. Laughable isn't it?

While you were out..

Being on Maternity leave has brought a lot of emotions and thoughts to the table. For one, length of time off. I'm taking advantage of a very generous policy Expedia provides for new parents, whereas it's more industry-standard to return to work after just 6 and 8 weeks! Not to get too friendly, but my pre-pregnancy clothes didn't even fit at 8 weeks. And the hormones.. how do companies expect you to not only be productive, but act normal when you're crying in the bathroom because your code gave you an error?

I digress. The downtime I've had away from code, work, an adult schedule, and everything in between has given me a lot of time to reflect on past experiences. Things that have gone well and things that haven't. I want so badly to share these thoughts with you, to blog and to help others. Truth be told, I've written about 10 blogs in the past month that I have deleted out of imposter syndrome. Thoughts of "Who wants to hear this crap" and "Who are you again?". Imposter syndrome has only ever held me back. I've done well at combating it, but it always finds a way to suck me back in. Lately, it's been tag-teaming with my anxiety to really put on a show.

Furthermore, I've had time to reflect on where I want to take things with my career. When I go back to work, I want so badly to pick up where I left off, to pick up like I haven't been out at all. I know that's not feasible. There's been a WWDC in June, that I still haven't finished watching. There will be a new Xcode and Swift and various other frameworks this Fall. There will also be all the features and work I've missed out on that I'll need to ramp up. This is really just the surface, and I'm sure there's a lot I'll need to catch up on that I'm not even aware of right now, hey there developer community!

Takeaways

Sharing all of this with you has a few points I want to call out

everyone experiences imposter syndrome, no matter how experienced you are
it's ok to take time for yourself or your family, the world will still be here when you get back
it's important to remind yourself of ^^^
having a mental illness can be really inhabiting. It has hindered my career more than it has helped, and if you're in the same boat, I hope you can find a way to cope or overcome.
if you're tired, take a break before it's too late. I've been ready to quit tech more than I'd like to admit, but having this time to focus on personal things has left me feeling recharged, refreshed, and ready to tackle what's next.
if you need to step away for personal reasons, you are supported more than you realize. Take the time you need for yourself, because you can't perform your best if you're not feeling your best.

Thank you for taking the time to read, or skim. I'm hoping that sharing these vulnerable thoughts will give myself permission to get back to blogging, and will hopefully help someone else in the same position.