DEV Community: Alli Teration

Retros that don't suck

Alli Teration — Wed, 05 Jul 2023 14:09:23 +0000

How we do retros at our early stage startup.

In the earliest days of furl, we decided to prioritize retros. Retrospectives ("retros" for short) are intended to increase the team's quality and effectiveness, and we wanted to build those in from the beginning. We were just learning how to work together, and we wanted to make sure we were putting in place processes that set us up for success instead of bogging us down.

Doing retrospectives this early on might be surprising. As a small startup, we only have so many hours in a day, and we don't want to spend our time in unproductive meetings. We asked ourselves: As a small startup, how can we make sure our retrospectives are productive and worth our precious time?

Successful retrospectives focus on outcomes. They keep people engaged, encourage people to open up, and most importantly: enact meaningful change. Here's how we run valuable retros at furl.

Keep people engaged

In order to get the most out of your retro, the team needs to be engaged so they're bringing up real problems that the team can solve. To do this, we switch up the format.

Switching up formats can inspire creativity and help team members come up with new ideas and topics. Googling “retro formats" or “retro ideas" will return hundreds of suggestions. Here are a couple we use that you could try:

The Marie Kondo retro

Marie Kondo wrote the bestseller The Life-Changing Magic of Tidying Up, where she suggests going through your things and keeping what “sparks joy" and discarding what's no longer serving you.

Keep - What sparked joy since the last retro.

Throw Away - What did not spark joy—what's no longer serving the team.

Recycle - What could spark joy if we made some changes or did it in a new way?

Rants, raves, and ruminations

This format encourages team members to really dig into what's bothering them, as well as what's been on their mind lately. It's a great format for encouraging team members to open up and center discussions around important topics.

Rants - Things that have been bothering the team.

Raves - Things that the team wants to celebrate.

Ruminations - Things the team has been thinking about.

Values retro

Occasionally we do a “values" retro, where we reflect on how we're sticking to our five company values: authenticity, empathy, grit, innovation, and excellence. We discuss what we can be doing to embody our values better as a team, and plan changes to help us maintain our values.

Encourage sharing

To have a successful retro, team members need to feel comfortable opening up about what's bothering them about the work or the team's processes. Team members need to feel that their thoughts will be heard, and they won't be judged or blamed during the process. Here's how we do this at furl:

Always include wins: Every retro includes a place for celebrating what went well. This adds positivity to the retro and helps keep the team motivated.
Lead by example: Leaders fully participate in retro and aren't afraid to dig into areas that need improvement, as well as celebrating wins from team members.
Ban blame: Figure out the why behind a problem, not the who. Strive to find solutions.
Valuing authenticity: We strive to build a culture where we can be open with each other not just during retro. If a company has a culture that's full of blame, where people don't feel comfortable being themselves and taking risks, you can't suddenly expect your team to feel and behave differently during retro.

Certain retro formats can encourage sharing: The Rants, Raves, and Ruminations format above is a particularly good one to bring out if you want to inspire your team to open up.

Make meaningful change

The biggest take-away here is this: if you want successful retros, your retros have to drive a positive impact for your team. It's the opposite of Vegas: what happens at retro needs to go beyond retro. The best way to do this is by summarizing the discussion, creating action items, and following up with the team.

During the retro: Highlight general themes, document decisions, and assign action items.
After the retro: Write up a summary including the themes, decisions, and action items. At furl we like to include an overlying theme for the retro called a kaizen, a Japanese word that means “good change" or improvement. Share the document with the team.
In-between retros: Complete action items and implement the great ideas that came out of the retro. Review action items when we sync up as a team.
The next retro: Follow up! Review the document for the previous retro and reassess or reassign incomplete action items as needed.

Even better retros

Having a retro process that's engaging, open, and brings about meaningful change will help you and your team get the most out of your retrospectives. Even the smallest of startups can benefit from running retros furl-style.

At furl we believe in continuous improvement which is one of the reasons we have retros in the first place. What are you doing in your retrospectives to keep them captivating and receptive? How do you make sure your retros lead to progress within your company?

Cross-posted from the furl.ai blog.

Quick Github Tip: View Your Documentation Changes Before Publishing

Alli Teration — Thu, 29 Oct 2020 13:58:24 +0000

Have you ever updated documentation for a GitHub repository only to discover after you pushed your changes to production that you misused some markdown and now your documentation looks weird? Maybe it's just me, but I didn't figure this out until after doing it the hard way one too many times.

You can see how your documentation looks by switching to your branch in GitHub and then viewing the documentation page you updated. GitHub displays markdown files (.md extension) as styled text, not as code. Which means they'll show the stylized text for whatever branch you're on. In the below image, I'm in the main branch so I won't see my updates:

To switch branches, find the dropdown that has the name of the current branch you're looking at in the upper left hadn't corner. Click on it and find your branch with your documentation changes and select it. Then go to the documentation file you updated and check out your changes!

Here I've switched to my branch and I can see my documentation changes:

Now you don't need to merge your code every time you try and fix some documentation formatting. Get it looking good in your branch first, and merge when it's ready to go. This can also be helpful when code reviewing a peer's documentation change.

Cover Image: A top-down stock photo of a man writing in a notebook next to a MacBook.

How to Stay Productive and Happy when Working from Home

Alli Teration — Sun, 15 Mar 2020 23:58:32 +0000

UPDATE: I started writing this a while back and intended to publish it later, but with an influx of people working from home for the first time, I got it out sooner. The concept was intended for people who were working remotely by choice. I want to say that this situation is far from normal. Normally, we're not trying to watch kids and work at the same time (not possible). Normally we can head to a coffee shop when we need to get out of the house, and now they're either closed or they won't let us inside (for good reason). There's a lot of far from normal things keeping us from being productive, and many things keeping us from being happy. If you don't want advice right now, that's totally valid. And if this advice doesn't work for you for whatever reasons, that's valid, too. This is far from work as usual, and we're in this together.

I’d planned to write this post at a future date, but given recent events I‘m getting it out early. I’ve been working remotely for two years now and through some trial and error, I’ve figured out how to keep myself productive and happy.

1. Find a place to work

Have a home office? Good, you’re all set. If not, you’ll need to find another place. If you don’t have kids, a central area like the kitchen counter might be fine. If you have kids around, you’ll want a room with a door you can close.

If working from home is a long-term plan, I highly suggest setting up a permanent desk and workspace, so you have a sense of being “at work” even though you’re still at home.

2. Get dressed

Working in PJs might be tempting, but I’ve found that getting dressed in clothes like I’d wear to the office helps me feel like it’s time to work, not time to laze around. Particularly if working from home is new for you—-you’ll want to trick your brain into thinking it’s time for work. Clothes will help.

3. Remove distractions

Think about what might be distracting for you and get it out of your vision. If you think you might be tempted by naps, make sure you can't see your bed from where you're working. If you think you might be tempted to play video games, hide your controller or mouse and keyboard. Limiting distractions might mean keeping other people and pets out of your office. My cat Wally will claw at me and even bite me if I don't pet him enough. After a while, though, he'll curl up on the chair and nap. Sashimi (cover image) doesn't come into the office as much, but when she does she likes to walk all over everything. Here's Wally, about to ask for some love:

I understand that with current circumstances like closing schools, staying completely free of distractions might not be possible. Do what you can.

4. Get up and move around

In Deep Work, Cal Newport talks about a technique where he'll pick a problem to focus on and go for a 15 minute walk. I love this idea. I also take walks when I've been focusing on a problem for too long and need to clear my head. Walk, or stretch, or do jumping jacks. Just remember to move.

5. Find ways to be social with your coworkers

Working in an office means your coworkers are around. You see them, you make small talk, you discuss whatever show everyone's watching. Avoiding people takes work. At home, it can be easy to forget you even have coworkers. If remote work is new for your company, hopefully your company is already figuring out what video conferencing tool you'll use for meetings. It's good to see other people's faces. If you use a chat tool like Slack, I suggest having some channels for non-work-related conversation. At Seller Labs, we have a bookclub that has a slack channel and meets once a month over Google Meet to discuss a book we all read. It's been a great way for me to get to know some people at the company I wouldn't have talked with much otherwise.

6. Set aside time for focused work

If you're in an office and someone physically comes up to you with a question or request, it can be hard to say "I'm busy right now, but I'll take a look at that later." It's easier on Slack: do it. I like to give a time frame for a response: if someone wants to pair program with me, I'll suggest a time and put it on our calendars. If someone has another request, I might tell them when I'll be able to get to it or that I'll do it by the end of the day. Then I follow through.

My company also encourages people to go off Slack for a while if they want to focus on something. You might want to see what your company policy is about how quickly you need to reply to Slack messages or email.

6. Find ways to focus during meetings

If your mind tends to wander during meetings at work, it's going to be even harder to focus on them when they're over video chat. I find that meetings that require me to speak and participate a great deal are easy to focus on, but those where I'm mostly listening are a challenge. One tip is to keep your camera on: it's less tempting to start playing a game on your phone if everyone else in the meeting can see that you're doing it.

I also knit. I discovered that knitting mindless patterns helped me free up my brain to actually focus on the meeting. It might not work for you, but maybe something else to occupy your hands like a fidget spinner or some play dough would help. I wrote about knitting during meetings here if you're interested.

7. Get out of the house

Ignore this one if you're working from home to avoid catching or spreading coronavirus. I'm including it anyway, for anyone reading this in the future when there isn't a pandemic. (I'm being optimistic.)

Sometimes, particularly in winter, I'll suddenly realize I don't remember the last time I left the house. Don't do what I did. Schedule time to leave the house.

How do you stay productive and happy when you work from home? If working from home is new for you, what are you planning on doing to make it work?

Agency VS Product Company: Which One's Right for You?

Alli Teration — Sun, 15 Mar 2020 01:11:53 +0000

After spending 4 years working for a software agency that built websites and apps for other people I wanted to try out working for a software company that built their own product. I recently hit my two year anniversary at the product company, and I'm here to talk about what it's like to work in these two different environments.

First, some background on the two companies. Both companies are fairly small: the agency being about 25 people and the product company closer to 150. The agency has one office everyone works from, and the product company has a main office in the US, an office abroad, a satellite office, and several remote workers (like me). The agency is almost all developers with a couple sales people, project managers, one marketing person, and couple support staff. The product company has quite a few more non-developers: more sales people, product managers, a marketing department, a customer support team, and a managed services team.

You'll get more variety at an agency

Working on something you don't like? If you're at an agency, wait a few months until the project ends and you can start something completely new. At the agency, I worked on projects for organizations ranging from a local union to a Fortune 500 company. Many projects started as beautiful blank slates just waiting for my code. There's nothing like spinning up a brand new project. At the product company, I've spent the majority of my time working on the same application, which luckily for me, I enjoy a lot.

At an agency, you're closer to the people using your work

This is a pro and a con for both types of companies.

As a lead dev at an agency I regularly met with the people who would be using what I was building. It's obvious why less client interaction would seem appealing, and it definitely reduces stress and gives me more time to focus on coding. But it came with some benefits: firstly, I built connections and relationships with some of those clients. I practiced my communication skills. The biggest benefit was that working with them directly on their apps gave me insight onto how they were using them that I never would've gotten without talking with them directly. My user insights at the product company come second-hand from customer support team members or tools like Fullstory.

One of the best things about working at the agency was the feeling when you show the final product to the clients and they love it. You built what they wanted and you can get that feedback right away, which is more instantly gratifying than deploying something and waiting to see if the users are actually clicking on the right things.

It's easier to try new technologies at an agency (usually)

At the agency, we wanted to try typescript. When the next project came up, we used typescript. At the product company, people were curious about typescript. My experience was fairly positive. We decided next time we started a new product, we'd seriously consider using typescript. The opportunity to create something brand new from scratch with typescript has not come up. And even if we do, we know we might be working on that product for years to come--do we really want to commit to typescript? We also have to consider how much more difficult using typescript might be when on boarding new employees. There's a lot more to consider.

On the other hand, at the agency we wanted to use .NET Core. The next project came in and the clients were very technical themselves, and wanted us to use ASP.NET, because they were familiar with it. At the agency we often had requirements to use specific tools because the company CEO heard about it somewhere. Product users usually don't care so much what tech stack the software product is built on as long as it works.

Deadlines mean less at a product company

One of the biggest culture clashes I experienced coming from an agency to a product company was the difference in how deadlines are treated. At the agency, we had paying clients expecting certain things to be done by a certain time. Deadlines were written in stone. At the product company deadlines felt more like they were written in pencil.

At a sprint retro I expressed distress that we weren't going to meet a deadline for a particular set of features. I was told not to worry, the deadline had been removed. Deadline? Removed? These two words did not belong together. I learned that deadlines were often created somewhat arbitrarily and then ignored by the developers. I've worked with the team to help create a healthier relationship with deadlines: creating them based on estimates using team velocity and actually paying attention to them. I like having them not as rigid, but making them meaningless removes their motivation. Other product companies are likely more deadline-driven, but it doesn't compare to an actual customer expectation.

Product companies can be more agile

When I started at the agency, everything was pure waterfall. At the end of a project, we'd present this result the client hadn't seen before in its entirety and then wait for the long list of things we did wrong. It didn't work. I was (still am) a Certified Scrum Master at the time and I presented the concept of agile and the scrum methodology to the company. The agile concept was easy to sell: we needed to show in-progress work to clients sooner so changes could be made iteratively instead of reworking large pieces of a project at the very end. We tried out scrum briefly, but with clients paying for work estimated in hours and being billed by the hour, the company was very hour-focused and couldn't leave that behind. Instead, we developed a modified approach that worked better with prescriptive budgets and timelines.

At the product company, scrum is followed almost by-the-book. Occasionally we break the rules, but there's always a good reason.

Product companies can foster a stronger sense of ownership

I've been working on the same application for two years and I'm the tech lead for the product. It's mine. At the agency, I felt ownership of projects when I worked on them, but after handing them off to the clients and time passing, the ownership felt less immediate. It went from "this is my project" to "that was that app I built a couple years ago." It wasn't something I was working on improving anymore. This doesn't mean my current product is perfect: far from it. I'm constantly improving user experiences and adding new features.

What's Better?

I'm not here to say what environment is better. I love continuing to improve a product I know inside and out, but I miss the instant feedback of showing a finished app to paying clients.

Would you rather work at product company or an agency? Let me know your thoughts in the comments!

Cover image via the wocintech stock photo library.

What Happened When I Learned Java and Python at the Same Time

Alli Teration — Tue, 13 Aug 2019 16:56:19 +0000

This is a story of how I learned Python and Java at the same time, and while doing that, learned a few things about myself in the process.

Starting out on a Journey

When I started my current job I'd primarily been a frontend developer. I'd used some PHP in college and dabbled a bit in C#--and I could write a mean SQL query--but that was it. At my current company, we have mostly Java and PHP on the backend. While I still mainly work on our React frontend, I coded in PHP right when I started and then, gradually, began coding in Java.

It started like this: an endpoint wasn't giving me what I wanted. I could wait for someone else to fix it, or I could just take a look in the code and see... yup. There was the part that needed fixing. It wasn't long before I'd created my first Java Pull Request.

Some people were starting up a Python learning group. I'd always wanted to learn Python but never started. Why Python? First of all, the Python developers I knew loved their Python. And secondly, Python just sounds badass. When I tell people I'm a software engineer and they ask what I program in, Python sounds way cooler than JavaScript. So I joined the group.

In the group, we're going through Learn Python the Hard Way by Zed Shaw. I picked that book up and started going through it.

Then I needed to pick a 6-month goal. I thought about Python, but I knew Java would be more relevant. I could fix things here and there but I didn't have a solid grasp of the language basics. I asked a coworker for a book recommendation and he suggested Head First Java by Kathy Sierra and Bert Bates. I made it a 6-month goal to go through the first six chapters.

That's how I ended up with two different programming books learning two different languages at the same time. And I was still coding primarily in JavaScript for my regular job. What was I thinking?

I have no idea.

What I Know Now

Currently I've finished the first six chapters of the Java book and the Python book only has a few chapters left. (The chapters in the Java book are incredibly long, while the chapters in the Python book are just a few pages.)

I definitely wouldn't call myself an expert at either language, not like I am with JavaScript. (You can't compare a decade of using a language to six months of learning a new one.) I know enough of Python that for my next six month goal I decided to build a Slack bot in the language. I'm proficient enough in Java to build new features in our code base and contribute more to Java code reviews than just syntax nitpicks.

I also know a lot about my learning style and what I like, and don't like, in a programming language.

How I Learn

I learned that I like short, bite-sized chapters better than long ones with a lot of information. I learned that I prefer writing little programs to doing elementary-school-like exercises.

Learn Python the Hard Way and Head First Java are two very different books. Head First Java has long chapters that attempt to teach concepts in different ways for different learning styles. My favorite was the bullied list summaries at the end. I found the chapter length overwhelming (I couldn't read a whole chapter and do the exercises all in one sitting) and most of the exercises seemed pointless. Instead of actually writing Java they have you pull together snippets to create programs, do crosswords, and even matching.

I know the book was purposefully trying to get the reader to remember these concepts with the exercises, but I found them tedious, repetitive, and just something to slog through so I could meet my goal. I did like the casual style that the book used. But here's the thing: I'm not going to finish it. I don't think I'm "done" learning Java by any means (I'll never be "done" learning JavaScript), but I'll find some other methods.

Learn Python the Hard Way has one bite-sized concept per chapter and the chapters are usually 2-3 pages long. I could usually get through them in less than an hour, which was perfect for doing them during my lunch break on Python Learning Group meeting days.

The best part, though, was that I was actually writing and running little Python programs, not doing crosswords. Zed has you type out a lot of code from the book, which seems silly but it helped me get used to the syntax. Then Zed has you make changes to the code, break things, make sure you understand what every line is doing, and add your own stuff. At the end, you're building your own text adventure game and learning new concepts as you add onto it.

The tone of Learn Python the Hard Way is much harsher than Head First Java and Zed Shaw can be quite opinionated about things. (I'll admit, we make fun of him in the Python Learning Group sometimes.) It's not enough, though, to turn me away from the book, even when Zed suggests you memorize a list of things and you decide, no, you're not going to do that.

I'm sold on this supposed "hard way." I think there's a second Python the Hard Way book and I'll likely pick that one up. I'm not sure if the group is going to want to do it, but we might need a break first. If I never need to learn another language, I'll probably look for a Hard Way book. There is a Learn Java the Hard Way book. It's by a different author but uses short exercise-based chapters, so I might pick it up.

How I Code

I like Python more than Java.

I really like Python, okay? Not as much as JavaScript, at least not yet, but I could see it being a possibility. At first I was turned off by Python's specific rules about spacing, but now I'm completely on board. Python code looks good. Python code always looks good, because regardless of who wrote it and when you have to try to make it ugly. Eventually you'll stop getting errors about spacing.

You know what I still get errors about though? Types in Java. Less so in practice code than in the actual Java repo we have at work. I understand the reason for strongly typed languages. I've used TypeScript. I worked with a bunch of C# devs for four years. I always use PropTypes in my React components. I get it. But I don't like being forced to use types. I particularly don't like having to decide which number type I want to use. I know that in Java you're concerned about memory allocation and you want to pick the type that uses the least amount of memory possible. I don't want to worry that much about memory allocation, though.* I don't find that fun. Just like I don't enjoy dealing with inventory management in a video game.

Another thing I don't like about Java is all the recompiling. I remember once I kept making changes in our Java codebase and they weren't working. I told it to System.out.print things and nothing printed. Then someone reminded me that I had to stop and restart the application. BLECK. I think I'll write something to automate that so when I save a change it auto-restarts for me. I'll see if I can write it in Python.

Two at a Time

One language at a time is probably the better way to go. I wouldn't recommend it. It did provide the surprise benefit of being able to compare the languages as I learned. I want to give the Java book some credit--it did a better job of explaining some concepts such as Object Oriented design and programming. It was interesting to see how the different languages tackled things such as inheritance.

Learning two languages at once definitely tripped me up. If I was working through the Python book one day and then tried to write some Java code the next, I'd start to do the wrong comment syntax or forget to put in semicolons. It even tripped up my JavaScript: a few times I forgot I wasn't writing Python and neglected to include parenthesis around my if statement conditions and wondered why VS Code was giving me the red squiggles.

Other than finishing the Python book, I'm planning on continuing to practice the language with side projects. I'm coding in Java regularly and hopefully I'll find some resources that suit me a little better.

*I realize this is so much more complicated than I'm making it out to be here. This is not a post about how different languages handle memory allocation. This is just a gut-level dislike I have towards writing Java.

Cover image by Christopher Gower on Unsplash.
Danger Noodle mug image is a mug you can actually buy! I failed to find the python-drinking-coffee image I really wanted to use for this post.

A Long and Winding Career Path

Alli Teration — Fri, 05 Jul 2019 21:38:25 +0000

My Non-Technical Skills are Valuable. Yours are, too.

When I was 11 and told my dad I wanted to make my own website, I didn't realize it was going to lead to my career. My career journey is long and twisted, and proves there's not one way to become a developer. There are countless paths.

I've met recent coding bootcamp graduates who completely ignore what they did before learning to code as completely irrelevant. But it's not. Your experience is meaningful.

My dad got me setup with some hosting from our local ISP and The Idiot's Guide to HTML. I published my website, and even got an email about it from the mayor of my small Michigan town. It was mostly about me, my pets, and beanie babies. It was the mid-nineties.

Eventually I moved over to Geocities and learned more HTML. I had a GURLpage that won their award and eventually learned CSS, a little JavaScript, and got my own domain.

In college someone on LiveJournal was looking for someone with HTML skills to work with them at their toy company. I didn't write much HTML, instead I worked for about 10 hours a week building an online toy store with PHP mySQL. Later I was hired by my school's Graduate Studies department to redo their website, a job I adored.

I can't pretend you're likely to find a coding job on LiveJournal, but that doesn't mean you can't leverage what you're already doing into something that involves coding. I've heard of people who loved updating their company website and learned to do more from there. I know someone who worked at a mom n pop hardware store and developed a new way to do inventory management in Excel. The Graduate Studies department had many graduate study interns when I worked there, doing mundane tasks like filing. If one of them had stepped up to work on the website, they wouldn't have needed to hire me.

But I didn't think I wanted to go into programming as a career. Even though I loved my Graduate Studies job, I imagined programming as men in a basement with dark screens drinking Mountain Dew and not knowing how to socialize.

I am so thankful that the old developer stereotype is fading. I've volunteered for an organization called Bit Camp that teaches basic web development to middle school girls. I always try to emphasize what the job is really like: creative, collaborative, and no basements (unless you really want to work in one).

It took me trying something completely different to go back to coding. I was interested in linguistics so I graduated with an English degree and went into speech therapy. Halfway into my Speech Language Pathology master's degree in DC, I came to the difficult realization that this career was not for me. My classmates were full of enthusiasm, but I could barely drag myself away from my apartment to go to class much less give actual therapy to real people. I was still making websites for fun. I knew what I needed to do.

I gave myself a month to find a tech job in DC. If I didn't find one I'd move back to Michigan and go back to school. I found one in a few weeks: working for US Congress. I spent half my time working on congressional websites and half the time fixing staff computers and setting up servers. During this job I learned about Project Management and thought that career might fit my skills.

I was hired at a software company for an extra-technical Support/Account Manager-type role that I thought might lead into Project Management. It did, but my responsibilities went beyond managing projects to doing custom development for clients. For some of the projects, I would "manage the project" and then I would do the work.

One piece of advice I give people looking to break into programming but don't have the background or don't know if it's right for them is to consider a customer support role at a web development agency or software company. This gives you an idea of what it's like to work at this type of company, lets you work with programmers to see what their jobs are actually like, and might even come with some training opportunities or tuition reimbursements. At the company I work for now, customer support reps have become QA Engineers and Software Engineers within the company.

My next job was so strange I can't possibly describe it in one paragraph, but I wasn't coding at all and spent more time doing people management. It was a tiny company, and my role also included HR and making sure the day's Seamless order went through. I missed coding. I made a few company websites for recruiting purposes. In my spare time, I figured out what skills I needed for a front-end developer job, and brushed up on them.

At this point I'd been coding in some form or another for over 10 years, but still didn't feel qualified for a coding job. I hadn't heard the term "imposter syndrome" yet; when I did her it, I would instantly think back to this time period. I did a bit of freelance work and eventually convinced a company to hire me as a junior Front-End Developer.

I worked there for four years. During that time: my boss quickly realized I'd undersold my skills and was not junior, I was unofficially labeled "senior" (the company didn't have tiered titles), and I was promoted to Team Lead. All that management stuff I'd done turned out to be good for something.

Your non-tech background is good for something, too. My project management experience meant that when my current company asked developers to demo their recent work to the whole company every sprint, I didn't bat an eyelash. Working for congress means when the customer support folks at my current company are dealing with customer complains, I know what that feels like. I work well with product managers because I've been in similar shoes. And my English degree? I've been writing and editing company blog posts at every job, and companies I've left are still using the job descriptions I penned years ago. My PRs are often used as examples for other developers.

When I left that company I knew exactly what kind of place I wanted to work for next, and I found it. I was hired as a senior-level Software Engineer and after a little over a year I was promoted to Lead Software Engineer. One of the most important things I've learned is that my background, while not traditional, is still valuable.

Image credits: Cover image by Eugene Zaycev on Unsplash. 3 women on laptops photo by WOCTechChat.