Tag Archives: Computer Science

OSU CS467 Update

Wanted to provide a brief update on my CS467 class at Oregon State. This week, we hit our midpoint, so I’ve created this fun demo video to talk more about where the team is at, what we’re working on, and what we have left to do.

In my video, I call this out, but one of my favorite dynamics of our group is our weekly group programming. I’ll dive more into how our group is really using this to drive our project forward.

Group Programming

Each week, my teammates and I meet for 2-5 hours across 1-2 meetings. The purpose of these meetings is to give updates and brainstorm, but it’s turned into one of the best places for us to knock out key initiatives.

Our project involves 15 rooms and a parser to navigate between those rooms and perform actions on objects within those rooms. This makes it incredibly easy for each group mate to own 5 rooms and the functions that occur in their rooms. However, we quickly recognized that there was some shared navigation and other verbs that crossover between our rooms.

In the first week we started coding, we transitioned our group meeting from an update meeting to an actual working session on navigation. Then our second meeting to a working session on our parser. These incredibly important brainstorms and group programming sessions has allowed our group to not spin our wheels independently working towards the same solutions but rather put our heads together and knock out things much more quickly.

These group programming sessions have been fundamental to us staying ahead of schedule and have made it so much easier for each team member to knock out their sections so much more quickly. Because we’ve worked as a team to discuss these things and all get on the same page, there’s no confusion on how to use these overlapping functions when we begin to work independently.

Implementing Group Programming

Though this is likely not the perfect solution for every project, I’ve found it incredibly valuable and a great reminder that taking the time to source feedback and brainstorm with others, though sometimes time-consuming, can actually allow a team to operate at a much higher efficiency.

This also doesn’t have to be independent to the actual backend or programming. I can think of several scenarios in my own work in Revenue Operations where I’ve been presented a problem, gone about executing a solution, and then been sent back to the drawing board when it didn’t quite meet the moment upon roll out.

There’s a lot more people involved in workplace solutions than just the programmers, developers, and project managers. Though you may not want to bore a salesperson, customer or other end user with the actual execution, it’s so critical to consistently be re-engaging with these parties to make sure you’re staying on track with the end goals and not getting too deep into just making the code work.

What’s Next?

The rest of our project timeline is dedicated to knocking out our individual portions independently and using our group time to improve the game’s usability. I’m feeling really confident about where we’re heading and even more confident that the dynamic we’ve built as a team is allowing us to do that much more quickly.

I’m really learning a ton in this course and surfacing some new ideas for collaboration that I’d really love to take back to my workplace. Group projects can be incredibly difficult, but I’ve been pleasantly surprised at how well our team has worked together and want to scale that dynamic into other projects I’m working on outside of school.

Criticism vs. Feedback

Since I started this blog for my Capstone cource, it’s about time we dive into an update on how the project is going! This week, I want to get a bit vulnerable and call myself in to be a bit better as a teammate.

One of my teammates had an “Aha! moment” this week, which is what I usually call it when a programmer just has a break through on how to fix a really complex problem. You may get it in the middle of the night, during work, taking a shower, etc., but it comes out of nowhere. All the sudden you have a breakthrough on how to solve a really complex problem and it’s time to hit the keyboard.

For my teammate, that came this week in solving some of the key requirements for an input parser on our text based adventure game. He went above and beyond to knock out hours of coding to bring the team forward weeks in our progress simply on pure motivation and excitement to fix the problem.

Where I’d like to call myself in, is in my response to that. My group mate was so incredibly excited to have built our input parser to handle all the scenarios, but all I was focused on what the length of the solution and how it could be done better to minimize it.

As I spoke through recommending that we try going with a different solution, I quickly recognized I was deflating my group mate’s excitement. Though I was trying to help us forward the project by making recommendations, I was not being a part of the solution and rather info dumping ideas back on someone who had done incredible work to remove a potential roadblock for our team.

I was practicing a behavior that I myself hold as one of my biggest pet peeves: delivering criticism over feedback.

My “Aha! moment” on Criticism vs. Feedback

A few years back during my undergraduate degree, I was participating in an engineering challenge at CES (the Consumer Electronics Show). There was just six students participating, and I lucked out in landing on of my good friends from another school on my team. Incredibly exciting, as I knew we already worked well together.

The challenge was to find a technology at CES and present that as something that would revolutionize cars by 2025 (yes, just 4 years from now). We spent a day just wandering the show, then came back to our booth to brainstorm as a group with our group mentor. For hours, we sat and debated without making much progress. It was an incredibly frustrating experience filled with research, several pitches, and several ideas tossed in the recycling bin.

It felt like we as a group were spinning our wheels with no real progress while the team up against us was chugging along on their presentation. Finally, after about that 25th pitch of the day, I recognized that my group mate was consistently the one shooting down ideas for being “silly” or “unfeasible” or “not that interesting”. Whether it was intentional or not, it was clearly getting to the group morale.

Finally, our group mentor, tackled the problem head on saying to the critical group mate, “Your feedback and concerns are completely valid. However, let’s try not to be overly critical without providing a solution or recommendation on how to move forward.”

That moment has stuck with me ever since. It felt harsh at the time, but it completely changed the group dynamic. The teammate that had previously been slightly difficult quickly got our team on track, and honestly completely led our team to create a fun and engaging presentation that had the entire judges and executive team from our company sponsor laughing out loud and actively participating in our project.

The contribution this group mate was capable of giving to the team was incredible, but she needed that push to reframe the way that she was contributing. She needed to take off her criticism hat and put on her feedback hat.

Feedback over Criticism

Criticism is calling out the problems where feedback is also calling out those problems but helping the receiver work towards a solution. Feedback is inherently intended to be constructive and solution-oriented.

The scenario I shared about my bad behavior with my group mate is something I see almost every day in my workplace between cross-functional teams. Feedback is collected or given to the team trying to solve the problem, this team comes to the solution, and the other team complains about imperfections in the solution either privately or directly back to the problem solver.

I see it a ton from my sales reps unhappy with certain product updates. Their concern is obviously valid, but often their criticism is far from productive. Often this criticism lacks context or recommendations of solutions. We simply hear things like, “this does not work for my customers as it leaves out this scenario.”

Though this seems helpful in the moment, the receiving party, the product team, is likely not privy to every single scenario that a customer can face. Product relies heavily on our teams interfacing with the customers to source those scenarios and either recommend their own solutions or share more about how they are solved in current state in order to help the roduct team come up with their own solutions.

Again, the people with some of the best solutions need to be helping the broader team work towards those solutions. If you have your best players just cheering on the team from the bench, you’re missing out on having you’re MVPs dunk on the other team. Having a strong communication between product and sales where both teams trust each other to come with constructive, solution-oriented recommendations is so important to positioning your team to come up with the best solutions.

Where Does that Leave Us?

Let’s bring it back to the Capstone project. As I witnessed my group mate slowly get a little more sad each time I tried to brainstorm ideas with the group, I quickly remembered that CES project team.

What I was trying to deliver feedback on was certainly something I’m incredibly talented at doing. In several group projects, I’ve been tasked to clean up code and help our groups’ solutions become more efficient. However, the way I was trying to deliver that value was incredibly misplaced.

I had spent several minutes essentially playing this back and forth with my group mate where he would share his solutions and excitement, and I would recommend ways to make it better. Instead of giving him the space to share and matching his excitement on this incredible feat, I was too focused on my own agenda and where I wanted to help.

Once I recognized this, I called myself out and immediately apologized for being inconsiderate. Instead of sitting and criticizing, I should have applauded my group mate’s progress. The time he had saved us for future weeks was actually time that I could easily spend working on a separate branch to consolidate before asking the group to review.

That was my final recommendation. I shared my specialty and also excitement for my group mate’s hard work. I offered to be part of the solution and take a look offline before our next team meeting in order to prepare some updates for my group mate’s to review, which was much more welcomed than my consistent “we should do more” comments prior.

My biggest piece of advice is catch yourself when you’re in this pattern. Whether it’s well intentioned or not, it can be hurtful to your team’s dynamic and prevent you from really putting your own skills to good use. Don’t be part of the problem, be part of the solution. Give feedback, not criticism.

A Salesperson’s Guide to Software Development

Welcome to my first ever “Decoding the Developer” blog post! This passion project has been a long time coming, but I’m excited to finally be kicking it off.

In this first post, I want to dive into the inspiration behind this blog, and the journey I’ve been on to get here. To put it simply, my mission is to merge my own technical and sales backgrounds to help my fellow salespeople walk a mile in the shoes of their product and engineering counterparts.

From Small Town to Corporate America

Don’t worry – we’re not going to start at my childhood. This was just an excuse to share a cute picture from the 90s!

Growing up in middle-of-nowhere Illinois, I never could have dreamed of studying Computer Science or working in Sales. Those career paths just weren’t paths that most adults around me in my small town had taken.

This gave me quite the identity crisis in my first semester of Bioengineering at the University of Illinois. I was surrounded by 54 kids in my program that had taken every AP course known to man and learned much more than Microsoft Office in their high school technology curriculum.

I took my first true Computer Science course that year and struggled my way through it forcing every new college friend to teach me everything they knew. It wasn’t until my junior year that I found my own love for the study. A friend taught me Python, and I got to immediately put to use my new programming skills the very next semester in a Medical Device course I was taking.

It was a little late to switch majors, so I finished my degree in Bioengineering, vowed to keep learning to code, and jumped into an Inside Sales role right out of college at Wolfram Research (yes – like Wolfram Alpha). It was selling Mathematica powered by Wolfram Language that fueled my hunger to go get that Computer Science degree. Enter Oregon State Ecampus.

Marrying Sales and Software Development

It was when my SHPE (Society of Hispanic Professional Engineers) Penpals came to visit University of Illinois that I finally pulled the trigger on going back to school. Their own passion and excitement to be “a woman in engineering just like Sam” inspired me to follow my dreams as well. Working full-time, Oregon State Ecampus was the perfect fit!

I’ve spent the last 4 years continuing to hone my Sales skills and putting my Computer Science education to work to be the most technical Salesperson on every team I’ve been a part of. With an end goal of getting into Revenue Operations, I soaked up all the programming, project management, and general technical skills that I could.

Continuing to marry my more technical education with my work experience helped me create so many resources that improved not only my abilities in Sales but also those on my team. I was able to create reports, scale processes, and do so much more based on the technical skills I was learning in my Oregon State courses.

I finished out my direct selling career at LinkedIn and finally made the leap into Revenue Operations, a space where I felt like my unique skillset would allow me to better the lives of those around me, move up quickly, and leave a lasting impact on the Sales teams I was part of. I joined Bluecrew, a small startup of just under a 100 employees, and quickly carved out a special place for myself as the Senior Revenue Strategy and Analytics Manager just a year after joining.

Decoding the Developer

This brings us to current state. I’m taking my Capstone course while serving as a leader for the Revenue team at this growing startup. Consistently, I’m interacting with both our Product team and Revenue team trying to communicate and escalate improvements for our customers to a Product team with very limited resources.

In doing this, as you can imagine, there’s always a light tension of Sales wants/needs and Product team capacity. I’ve even found myself frustrated or confused due to slow progress or mismatched expectations with our cross-functional partners. It’s in these frustrated moments, that I often try to take my Revenue hat off and put back on my Product Manager hat.

Courses like Capstone with projects that force students to be not only the Developer but also the Project Manager and even sometimes the customer have completely changed my work behaviors. I’ve improved not only my effectiveness in my own role but also improved my relationship and communications with my partners on the Product and Engineering side.

Why start blogging about this now? I’d like to use my current Capstone project and future projects to help my dear friends on the Sales side get a simplified look at what goes on over on the Product and Engineering team. It’s my hope that this will not only spread the compassion I have for my Product Manager and Developer friends but will also help other Sales folks communicate their concerns, needs, and product visions more effectively on behalf of their customers as well as themselves.

Join me in “Decoding the Developer: A Salesperson’s Guide to Software Development”. It’s going to be a fun journey!