Rigel St Pierre

Transitioning to a new role at Shopify has been a journey filled with both excitement and challenges. Here are a few key learnings from my experience so far. Prioritizing Information: One of the biggest challenges has been sifting through the vast amount of information available. With so much happening across the organization and an abundance of content to absorb, distinguishing between what's actionable and what's just for context is crucial. I've learned the importance of seeking early guidance from my team to help prioritize effectively. This approach has been invaluable in focusing on what truly matters and ensuring my contributions have the most impact. It's about striking a balance between being informed and overwhelmed, and I've found that open communication with colleagues has been key to navigating this. By actively engaging in discussions and leveraging the expertise of those around me, I've been able to streamline my focus and direct my efforts where they are needed most. Embracing Change and Adaptability: This is a dynamic environment where some applications and processes have been around for ages, while others may have been introduced just the month before I started. Some systems endure because they work exceptionally well, while others might be in desperate need of a rewrite, refactor, or replacement. This mix of tradition and innovation requires a willingness to ask more questions than anyone else in the room. It's about understanding the rationale behind existing systems and being game to exploring new approaches. Through all of this, I am realizing that change, while daunting, offers a chance for growth and reinvention. I was ready for a new challenge, and I got exactly what I was looking for. The supportive and collaborative spirit of the team has made this transition not only possible but rewarding. I'm lucky to be a part of this team, where the shared commitment to Shopify's mission makes it very clear we are all rowing together in the same direction. #Shopify #SoftwareEngineering #NewBeginnings #GrowthMindset

64

5 Comments

👋 Hey product hiring managers! You may have noticed dozens of people now with a new certificate from the Alberta Product Leadership Program. If you manage or are prospectively seeking a new PM to join your team, you should know that: 1) The program is selective. You can't just sign-up. Since it's inception, the program has sought to upskill professionals that have shown their motivation for growth and desire to hone their product management craft. 2) The graduates get broader exposure to practices and industries beyond their resume. Our sessions are interactive and facilitate sharing of perspectives and ways of working across multiple organizations - from grassroots startups to FAANG giants. 3) There's more to it than training. During the course of the program, many participants gain mentorship, build a supportive peer group, and get out of their comfort zone. The program is refreshed every year by hiring managers just like you to optimize for the skills we need to hire and promote for. So if you see the APL certificate with a candidate profile, know that candidate choose to do more than your average course. #abtech #yyctech #yegtech #productmanagement

51

1 Comment

The October Montreal.rb talk will be on how to "Tame Complex Queries with Database Views", given by David Cornu, a Staff Software Developer at Patch. Date/Time: Wednesday, October 2, 2024 at 7pm Location: Anticafe Montreal (294 Saint-Catherine St W, Montreal, Quebec, Canada) RSVP link: https://lnkd.in/er8Hz24N Description: PostgreSQL views are a useful tool to make query logic reusable and maintainable. This talk will cover their pros and cons, a couple of real-world use cases, and how to use them in Rails apps using the Scenic gem. Speaker: David is a staff software developer at Patch (a climate tech startup). He cracked open Why’s Poignant Guide to Ruby in 2009 and has been in and out of Rails apps since. #montrealrb #montreal #ruby #rails #talk #presentation #softwareengineering #softwaredevelopment #programming #community

1

Love seeing the process and growth that people experience inside Career Strategy Lab 🎉 Advancing your career is so much more than just external stuff like redoing a resume or portfolio, reaching out to people on LinkedIn etc. Sidenote, SO much growth comes from within and that's when we see things really shift for people – they start getting more interviews, moving further along in the interview process, and finally get offers for roles they actually want! PS: Have questions about Career Strategy Lab (the UX career coaching program I run that's *not* a boot camp) ... then check out the post below or send me a DM here on LinkedIn.)

2

1 Comment

When I first heard the term "Quality Engineer" getting popular a couple years ago, I was a bit skeptical. I know my Canadian friends do not like the term "engineer" for those of us in software development. And I'm hesitant to label anyone so that they sound like they're "in charge" of quality. I was persuaded to embrace the term by João Proença in his talk at ATD USA about it. And this post from Katja Obring also makes a great case for it. https://lnkd.in/eZP4XVKF I do think this is a big part of our future as testing specialists. (and hello, Alan Page and Brent Jensen, I like your "testing coach" term, and personally, I also like "testing consultant"). When I introduce myself, I still say I'm a tester by trade. And, I do think we need a term that conveys the huge contributions QEs/testing coaches/testing consultants/quality advocates make to their organizations. #HolisticTesting #AgileTesting

122

47 Comments

Your developer interview process sucks 🪠: Here’s how to fix it? 1/3 👍 Are top-tier developers slipping through your hiring net? How many "perfect on paper" developers crumble during technical assessments? This is going to be part 1 of a 3-part series on refining your hiring process, specifically focusing on how to effectively qualify a candidate's technical ability. In the past few months, I’ve worked with clients to improve their interview process, and these are some of the things that I think about when designing the interview process. 🟥 Not all developers fit in the square hole – Tech test vs. Paired Programming As a software developer and a recruiter, I’ve been on both sides of the fence. I’ve taken technical tests, given them, and done my fair share of pair programming interviews. The more I reflect on it, the clearer it becomes: these approaches test very different things. Depending on what you're looking for in a candidate, one method might be way better suited than the other. 🤖 Technical Tests are a great tool for verifying a developer can fulfil the duties of their role. You find tech tests resonate best with developers who can work independently and churn out work quickly in isolation. These candidates often excel at solving problems in a controlled environment but are not necessarily the candidates you want in a highly communicative or client-facing environment. These people will often be your top developers, and you don’t want to miss out on them! 🤝 Paired Programming, on the other hand, allows you to assess how someone interacts in real-time. It’s about collaboration, listening, and adaptability. When you are pair programming with a candidate, you can quickly gauge their soft skills, how they approach problems, and how they deal with the unexpected. More importantly, you get to see how they learn and improve in the moment. Often, I find candidates who would excel in a technical test can falter in the paired programming stage due to social anxiety, lack of soft skills, or difficulty thinking out loud under pressure, even though they may be highly skilled technically. 🤔 Ultimately, you need to be more diligent when making your interview processes. Think about what the role entails. What test would best suit that individual? Cater the process to them so they don’t fall through the cracks. 🎯Are you looking for someone to be a production machine? Or a team player who you can work closely with? If you want a team player, you’re going to have a pair programming interview where you can collaborate, teach, and see their process. If you're facing tight deadlines and need a developer who will take ownership of their space - implementing a technical test can help you find that person. Tomorrow I’ll follow this up with some horror story technical tasks I’ve come across and how we can improve them to be 1. Relevant, 2. Fair in terms of time commitment, and 3. Truly reflective of the real challenges developers face on the job.

3

While I am excited for the release of Bubble's Native editor later this year, here are some thoughts to sober you up if you've had too much of the "I've got the next unicorn idea" punch 🍹 I have faith in Bubble's engineering and product team, but if you think it will be easy to inject your web app or idea into the native space, you might be miscalculating: 1) When Bubble released the beta version of their responsive engine a few years back, there was a good six months of bug fixes and tweaks. Since native capability requires a different editor and code stack compared to web apps, I think this release is even more significant. 2) FlutterFlow has been dedicated to creating a platform for no-code native apps since 2020. They're constantly updating and refining (I think I had to update my desktop app 3-4 times in the past month) based on user needs and native store requirements (iOS/Android changes). iOS typically presents more hurdles than Android. Could this be because the underlying code is Flutter, and Bubble is going a different route that is more efficient? Is coding for iOS just that complex? I guess we'll see. 3) Will plugins save the day for capabilities not available as they do in the web app editor? I wanted to integrate OneSignal to send push notifications in my FlutterFlow project...if this were a web app, someone would have already integrated a popular service like OneSignal, and there'd be a plugin for that! Well, no – in FF, it sent me on a 3-week tangent which required custom code, pushing the code to GitHub, synchronizing and making changes in Xcode, back to GH, deploy to the app store. I think there may be hurdles for a while, requiring traditional code for particular features. 4) We're so used to building, testing, and immediately launching a web app to production - this won't be the case with native apps. There is a gatekeeper layer called Apple and Google which mandates certain requirements to get an app to production. To summarize: - There will be a lengthy beta period. - Updates and refinements will be ongoing. - Custom code may be required for many services/features we're used to having plugins for. - Besides learning the new editor, devs will also need to learn the Apple and Android deployment protocols. I hope I eat my words, but I'm setting my horizon to 12 months + past the beta release. What do you think? #nocode #nativeapps #iOS #android Alchemy Apps #softwaredevelopment

22

5 Comments

A lot of companies are going to learn quickly that having principal/staff PMs aren’t a silver bullet. If senior PMs can’t make reasonably good progress in a company, you have problems elsewhere. Principal/staff PMs are more experienced, obviously, but a lot of work doesn’t require principal / staff level experience (or shouldn’t require if, at least).

120

13 Comments

WAIT Are you telling me that now Shopify is using LLM's to make more simple the generation of GraphQL queries?? 😮 .dev Assistant gotta be one of the best features for developers from Shopify, you don't know how complicated it can be for someone to jump into GraphQL without previous knowledge (and the docs are not so easy to read for the beginners). This definitely will push a lot of new features and developments within stores! 🙌 🙌 🙌 This is an amazing way, and a very useful one too, of using LLM's instead of just adding a chat helper to your favorite instant messaging app 😅 Check a demo video from Shopify here! https://lnkd.in/eQcbUg2D #Shopify #ShopifyPlus #GraphQL #Storefront #APIs #LLM #FrontEnd #Learning #Lifehacks

7

1 Comment

This is a final reminder for the October 2024 Montreal.rb Ruby Meetup, "Tame Complex Queries with Database Views", taking place tonight at 7pm at Anticafe, Montreal: https://lnkd.in/dXhQ6k2G Please remember to follow these instructions when you arrive at Anticafe by 7pm (294 Saint-Catherine St W, 3rd floor, Montreal, Quebec):  - Upon entry, please check in on Anticafe's computer in the 2nd floor (free coffee and snacks are available in the 2nd floor).  - After checking in, please head to the 3rd floor to attend the Montreal.rb event  - When the talk ends (around 8pm), please leave immediately to the Networking Event location next door: NYKS Bar (1250 Rue de Bleury, Montréal, QC) - Upon leaving, please mention that you are with Andy to have your fee covered by Montreal.rb. The event is maxed out already, so if you haven't RSVP'd, you can RSVP for the next month's event instead, before the topic is chosen (if you are a Software Developer with 6 years of experience, you are welcome to present; just submit a title, description, and bio to get your talk booked): https://lnkd.in/d7RrRnQW See you all tonight! #ruby #montreal #meetup #talk #rails #db #sql #database #databaseviews

1

4 Comments

Final Reminder! Don’t Miss Out on Our Upcoming Workshop: Unlocking Product Market Fit! 🚨 We’re just a few days away from our interactive WIP Montreal workshop on Product Market Fit, and tickets are going fast! 🎟️ Join these really talented ladies Sabrina Damato, PPCC, Reforge alumni and Elitsa Asenova for an evening of hands-on learning, networking, and practical insights to take your PM skills to the next level. Wondering what you’ll work on? Here’s a sneak peek of the exercise: 🔹 Example Exercise: Let’s say your team selects a “Remote Work Productivity Tool.” Using a Lean Canvas, you’ll define customer problems, target segments, and outline potential solutions. This collaborative approach helps you gain real-world experience in validating and achieving product-market fit! 📅 Event Details: • Date: Thursday, November 7th • Time: 5:30 PM – 7:30 PM • Location: Nakisa Inc (2000 Rue Mansfield, Suite 301) 🗣️ Don’t miss this chance to learn, connect, and walk away with actionable strategies. Get your tickets here: https://lnkd.in/en_HTpcK See you there! #ProductManagement #WomenInProduct

16

2 Comments

9/10 Software engineers would never talk about this happening in their career but I will: → Snowballing. Snowballing is a sugar-coated word for the blame game. We've all seen it - a bug gets reported, and everyone starts pointing figures. The game starts, you’ll hear "It’s Front-end's fault!" "No, the back end needs to fix this!" When no one even tries to understand the bug. Everyone immediately starts snowballing, and no one bothers solving the bug. I’ve seen this mostly happening among junior software engineers. Sometimes, they take the reported bugs quite personally and it backfires. See, no one will be punished if a bug is reported. Our only priority is to understand and fix it. So, when a bug comes up, you should: - find out its origin (front-end or back-end). - and flag it to the respective team. It would be better if you took the initiative to: - find the bug’s origin. - and solve it yourself. Remember, you're part of the project, and everyone will appreciate you as you solve the whole team’s problems. The wins & bugs reflect on everyone involved. So, take ownership and be proactive rather than snowballing. Believe me, this is a good skill if you want a strong career ahead. – P.S: How do you deal with bugs?

109

6 Comments

Sharing a very insightful interview of Jean-Michel Lemieux (former VP at Atlassian, former CTO at Shopify). He talks about what he calls "time horizon friction" where people spend too much time talking about the future to the detriment of spending time building the present. One thing he mentioned that I definitely took notice is that he tries to talk with his team for only one hour a week. I've been a manager of ICs and a manager of managers. One of the things I preferred doing was having only one weekly hour-long meeting with the team, and if we're working on a cross-team or complicated project, we can also have another weekly hour-long meeting on that project. We can talk about blockers, what we'll work on next week, etc, but it should all fit within that hour-long time frame. I did not like having daily in-person stand-ups (the disruption to people's flow is not worth what we gain from them), and I was always hesitant to adopt too many Agile practices. But it seems like so many other people in the industry prefer having more weekly planning than I prefer, that I sometimes question whether or not my own methods are too naive or underdeveloped. So it's really affirming to hear someone with Jean-Michel's experience talk about not spending too much time planning every week. #leadership #engineering #process

6

🚫 Product Discovery Isn’t the Destination 🚫 Here’s a hard truth: Product discovery is not the final goal. Yet, I've seen teams fall into the trap of treating it like it is. 🤔 When a team tells me that their only deliverable for the sprint or even the quarter is a discovery document, my alarm bells start ringing. 🔔 Discovery is important, but it's just one piece of the puzzle. It’s not the solution we're offering to our customers. We’re not in the business of selling documents or ideas; we’re here to solve real problems. 📄❌ ⭕ Why This Mindset is a Problem: 1 - False Sense of Progress: A discovery document might look impressive, but if it’s the only output, what have we actually delivered? Customers can’t use it, and it doesn’t solve their problems. 2 - Unrealistic Expectations: Documents can create hopes, but without tangible results, they risk creating false expectations. If we spend months in discovery without delivering value, we’re missing the mark. 📉 3 - Delayed Value: Customers deserve concrete value, not just promises of what might come. Teams should be shipping features, not just ideas. 🛳️ ✅ What Teams Should Focus On: 1 - Deliver Concrete Value: Every sprint or iteration should produce something that users can see, touch, or benefit from. It could be a feature, an improvement, or a bug fix—something that adds real value. 🚀 2 - Balance Discovery and Delivery: Discovery should inform your roadmap, not become it. Use insights to guide decisions but prioritize delivering solutions that customers can experience. 3 - Set Realistic Milestones: Break down discovery into actionable steps that align with delivery goals. Make sure each step moves you closer to a tangible outcome. 🎯 The Bottom Line: Discovery is just the beginning. If it's your team's only output for the quarter, you're doing it wrong. Let’s focus on delivering real, impactful solutions—not just dreams. What do you think? How do you balance discovery and delivery in your teams? Let’s discuss below! 👇 #ProductManagement #Discovery #Delivery #Leadership #CustomerValue #Innovation

26

We've hired 200+ developers since we started Trio. There are 3 crucial skills we look for in every new hire (other than their developing skills): → 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻 - As a remote-first company, clear communication is non-negotiable. You need to be able to convey technical concepts and get your point across plainly through emails, messages, and video calls. No room for guesswork or assumptions. → 𝗔𝗱𝗮𝗽𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 - Things are always changing in the tech world, and we need to keep up. We need reliable team members who can adapt to our evolving projects and priorities. → 𝗖𝗼𝗺𝗺𝗶𝘁𝗺𝗲𝗻𝘁 𝘁𝗼 𝗘𝘅𝗰𝗲𝗹𝗹𝗲𝗻𝗰𝗲 - Our top talent takes pride in perfecting their craft and driving innovation. Mediocrity is not in their vocabulary - they will go above and beyond to wow our clients and push the boundaries of what's possible. What matters MOST is finding team members who share our passion for continuous learning, problem-solving, and desire to create innovative solutions that make a real impact. What about you? What do you think is most important when hiring great talent?

71

2 Comments

Question for engineering leaders (managers, directors, VP's, etc): I'm curious about the current landscape of developer productivity analysis + management tools - things like LinearB and Jellyfish. Which tool, if any, are you using? Any opinions/pros/cons on the tool you're using (or the entire domain overall)?

18

Shopify is such a cool story because of the way their existence totally changed their own total addressable market. Shopify made going direct-to-consumer easy. It's not just the storefront bits - it's the app ecosystem. Shopify enabled companies like ShipBob to turn highly physical processes into a software abstraction, dramatically reducing the capital required to launch a real-world DTC business. AWS did the same for software. Twilio did the same for software/telephony interactions. There's no way to "size" the market for category definers like this before they happen... because their very presence creates new markets.

13

This is an interesting question from Reddit. It gets at the heart of what engineering managers are responsible for: outcomes. If you are an EM, how do you increase urgency? Should you? If you are a developer, what makes you slack off, and what makes you wake up and get back to it? In my experience, deadlines are the best way to make sure your team gets things done. BUT there is a wrong way and a right way to do it. ❌ Wrong way - There's a new feature that needs to be implemented. - Scope gets set. - Your team estimates 4-6 weeks. - You commit them to 4. - It's week 3, and they are clearly falling behind. - You use the deadline to increase urgency. This path leads to burnout and frustration. ✅ Right way - There's a user problem that needs to be solved. - You decide how long you are willing to spend on it (setting the appetite). - Your team builds a scope that can be accomplished within that deadline. - Product agrees, and your team gets to work. - You use the deadline to increase urgency. Your team members are co-owners of the project. Their ownership inspires them to hit the deadline with the scope that they set.

15

11 Comments

We're hiring! Come join my team! We're looking for a frontend-focused software engineer to complement our team. If you're familiar with modern frontend frameworks and best practices, and want to step into a role that gives you autonomy and ownership over the frontend stack, then this is the perfect role. You'll work closely with business stakeholders, help prioritise the right thing to do, design and implement beautiful, functional, and performant UI/UXs for our customers and clients, internal and external. For context, the team has recently switched over to Rust and is interested in using functional programming techniques to write safe and performant software. We also use a wide array of serverless technologies. So if that is an environment that sounds fun to work in/with then we'd love to hear from you! The role is remote. --- A little about us: Switch2 is the market leader in the heat network market. Heat networks are a one-to-many form of heating in which heat is generated in a centralised place and sent out to various homes and properties via a network. Though heat networks only make up on a tiny fraction of the UK heat market, this is a growing market and perfect for massive expansion in the UK - and a brilliant example of how we can meet our net zero targets as a nation. To take an example, by 2035 it is expected that most gas boilers will be phased out of homes and businesses. The challenge then arises of how to heat properties that physically can't have a dedicated heat-pump installed - apartment blocks, Victorian terrace houses, etc. Heat networks are a great way of solving this problem, as the heating source gets moved out of the property and heat is then piped in via a heat network. This will allow all properties in the UK to benefit from the efficiencies of heat-pumps and to decarbonise. To see the potential of this type of heating-system, look to Denmark where they are heating an entire city via heat networks: https://lnkd.in/eXkanNsm You'll be joining a company making this a reality! https://lnkd.in/e7r6USSr

28

3 Comments