Caleb Mellas

Sent out a bunch of invites for ShopDev Alliance this weekend. I'm finding it real interesting that some folks don't really put any sort of effort into an online presence, or an online application for a paid Slack community that positions itself as being for experienced Shopify Devs. Maybe we're not doing a good enough job setting expectations. To fix that, here are some signals that can help convey you are an experienced developer (to other developers or technical stakeholders) - Website Arguably, this doesn't tell me much. Anyone can spin up a website simply enough. But at least it tells me you've got the "bare minimum" setup invested. Bonus points though if your portfolio site is on a customized Shopify theme. Professional Social Media Presence We focus on individuals in SDA. I don't want you applying as an agency. Anyone can spin an organizational account up online so I want to see a personal profile that has some actual information. Posts are some version of helpful content, but realistically doesn't always tell me much. Not every developer or freelancer has the time to create content - it's incredibly time consuming. You know what I can see with your profiles? Comments. Everyone who spends any amount of time online leaves comments. If all your comments are just responding to someone's post to get their "top 20 tips for CRO" then you're not gonna make it. If you only post, "yes, I'm interested check DMs" for someone looking for help on a job, you're not gonna make it. Checking in on replies and comments, I can "listen in," to real online conversations and get a sense on whether or not you're a developer. Publicly Accessible Code References It can be a Github or Gitlab profile, just someplace online that indicates you're touching code at some point. I don't even always need to see repos - know what I can see? Contributions. You don't have to be building in public. Github can show contributions for private and public repos. Code Pen can also be a good place to show off code samples as well. Any Form of Content Creating any form of content online, whether it's your website in a blog post or tutorial, a YouTube channel, on your social handles, etc. can help give a sense on your technical abilities. Content includes public coding projects, so open source contributions or publicly accessible code in Code Pens even are a great way to showcase some form of skill. Don't just rely on completed projects. Talk about a technical problem related to those projects. It's easy to copy a boilerplate anything from somewhere online. --- The next steps for SDA will likely revolve around relying on personal referrals from active members. We have a global group covering many timezones and cultures, so it is definitely not a perfect process currently. We're always going to be learning and growing. Hopefully this is helpful in some regard so others can grow too. Because if I'm looking for this stuff, you better believe others are too.

30

"Si non confectus, non reficiat". I started to use "If it's not broken, don't fix it" (yes, the one from Vetinari for those that know) as a motto in development teams - initially as a joke (or in my Slack status). After a couple of years, I'm more and more convinced that it's probably worth graduating from a joke to an actual principle. The meaning behind is that as developers we tend to look at a lot of things (first and foremost our own code) as being imperfect and in need of being "fixed". While that may be true (I can take my code from yesterday and make it better), the fact is that most of us operate in scarcity environments - ie, teams where we have more tasks than we are able to work on. This requires to make choices - decide what's the most important things to work on right now. On the business side, but also on the technical side. So this data transformation there that could be written in a better, this query that could be more efficient there - if they are not hurting, juste leave them to be. Let's focus on what matters.

8

The feeling your engineers get when they sit down for a deep work block and that Slack ping comes in... Want to quantify the impact of interruptions on developer productivity? Ask about Uplevel's advanced Chat Interruptions model, which provides a unique (and uniquely accurate) picture of how your team is actually spending their time. #developerproductivity #deepwork #engineeringleadership

13

1 Comment

An email landed in my inbox today making a crazy claim. What do you think? Can even the best developer tool 5x your engineering productivity? Probably not. And any product that claims so probably makes other less-than-transparent claims. Ellipsis (YC W24) doesn't. Our AI code reviews & bug fixes will improve your engineering productivity by ~10%. We don't need to make crazy claims because our product actually works. If you're buying AI developer tools, do your research. You can install in 2 clicks and start a free 7 day trail at https://ellipsis.dev

26

I've been thinking about the challenge of preserving the "low priority voice" as software products scale. As teams and projects grow, folks outside of development and product positions seem to get more and more quiet—or maybe they're just harder to hear. Sure, a typo here, some inconsistent spelling there; these don't really rise to the level of "bugs" since nothing's technically broken. But when these little things accumulate, they can start to chip away at the users' trust in the product and the company. Curious to know, how are others tackling this within their teams? #SoftwareDevelopment #TeamCollaboration #QualityAssurance

15

Another update for ShopDev Alliance 🚀 Appreciate everyone's patience while David Lindahl and I work through hundreds of signups at this point. The response from the community has literally been overwhelming! This was something I had hoped would resonate with maybe 30-50 individuals at best - not 200+. We've got initial requests out to our limited Founding Members spots and have started to onboard those who have jumped through the hoops. We'll give it a couple more days and then as of this week we'll send out invites for our general membership tier. A big thanks to the folks that have reached out and offered their support and encouragement. I keep saying it has been overwhelming in all the best ways to work through this process and get such a good response from our Shopify Developer community. That being said, please do be patient with us while we work through the process and also understand early on there might be a bit of "settling down" while we get folks onboarded. As always, please reach out with questions as we get folks started here. After this week of onboarding folks who had signed up previously, we'll update the site and general announcement for signups outside of the folks who were first to sign up.

41

5 Comments

Three reasons I love doing DEFTs! We just wrapped up another DEFT for another great client. What's a DEFT you ask? It's our "Developer Experience Friction Audit Tool". Put simply, it's a holistic evaluation of your #DX / developer journey, from the perspective of your potential developer customer. Here's three reasons why I love performing DEFTS for our clients: 1. I get to meet great people who really care about their organization's developer journey / developer experience. 2. From new technologies and APIs, to frameworks and new types of learning resources, I get to learn new things all the time. Each project not only broadens my scope of experience, but allows me to see what's driving the pulse behind today's top companies and technologies. 3. DX audits are a chance to make a real difference for our clients and their developers. From identifying what's working, to areas of opportunity, it's rewarding when we uncover things our client's may have never thought about before. Want to learn more about DEFTs? Check out: https://lnkd.in/g3tNEneu

4

3 Comments

Here’s a Sunday question for y’all, particularly those in frontend engineering; How do you go about communicating details on a technical project to a c-level executive who only cares about the 10,000-ft view? Not everybody has the time or interest to understand your technical detail. What strategies for knowledge nuggets can you share about how to speak to senior people/executives about your progress without diving deep into the weeds?

1

4 Comments

Can someone explain to me how to get "more experience"? I have 16 years of full stack software engineering experience, mostly in C# .Net 4.2 through 8, including .Net Core 2.x & 3.x, along with WCF, WPF, Winforms, Razor/Blazor, HTML, CSS, and JavaScript, with Entity Framework, Dapper, Linq, SQL Server, MySQL, SQLite, Oracle, NoSql, and other databases. And a few of those years include a combination of Java, PHP, and C/C++. I've also used MarkDown, PowerShell, MVC framework, Swashbuckle/Swagger, Newtonsoft, JSON .Net, TopShelf, and a variety of testing frameworks. But apparently that's not enough. In the past 3 years alone, I've learned ReactJS, TypeScript, Xamarin, XAML, Maui, NodeJS, Terraform, AWS, and Azure, and I'm currently learning Angular, but that doesn't cover the 3-5 years of experience jobs want. I've learned some of these skills through jobs, but also some on my own. Except that as often as companies want us to learn these skills outside of work, they only count professional experience when it comes to hiring. My last interview said I needed more experience, as if the previously mentioned 16 years wasn't enough, and neither was the 15 years of computer repair and networking before that, which their interview questions also covered. So if no one is willing to hire because people don't already have experience, how are we supposed to get the experience? And don't say "open source projects", because they don't count as professional experience. Or do I have to take a 50% pay cut to take an "entry level" job that still requires 3-5 years of experience that I somehow still don't have? People are quick to say that "no one wants to work anymore" when they can't get hired, but they never seem to think "businesses aren't willing to teach anymore" when they refuse to hire people. Why? Is it that we are so conditioned to think that it's always the individuals fault for not living up to expectations, instead of the businesses fault for setting unrealistic and ever changing expectations? So, I ask again, how can I get the required experience when employers refuse to hire unless I already have experience?

2

If culture fit isn't the most important aspect of adding another developer to your team I know you don't ship much. I follow so many small companies that out deliver large ones it's crazy. 3- 10 person teams, ship ship ship ship ship...Why? The mission is ____ing LOCKED in, everyone is on same page from character to keyboard. Let me give y'all hiring managers a tip. When you have those two candidates, one has ALL the tools technically but you vibe better with the other who wants the gig more? Hire the latter, train 'em up. That 4 week ramp up they need on 'X' will be well worth it long term, 100%. #softwarejobs #java #javascript #typescript #react #reactnative #vue #angular #svelte #astroJS #htmx #go #golang #rust #ruby #rubyonrails #scala #kotlin #closure #haskell #elixir #csharp #aws #azure #ai #aiml #tensorflow #python

7

3 Comments

I'm going to post a few challenges I have had as a software QA. I should be relaxing today but those that know me, know my brain is always in thirty places at once. To developers: Trust your QA. Y'all don't know how many times I've heard, "Well, it works on my local". I don't care. In the test environment, it breaks. I do my due diligence to investigate why, present evidence in logs and from the database, present recordings, and meticulously document steps of reproduction and results. And even after, I still get, "It works on my local". Get off the dang local. NO ONE knows this software, app, platform, etc. better than the QA because we live it more than anyone else does. To business analysts: I know you all are overwhelmed. But please stop copying and pasting Acceptance Criteria for similar features. It makes a mess for developers and QA because the AC doesn't match or conflicts with not only the developed feature but integration as well. Which brings me to my next point... What QA is: Everyone thinks of us as just testers. I am sick of that. I spend half my time working with the product owner, BAs, and Devs, just making sure the AC reflects the solution needing to be resolved. I can't tell you how many times I have had to address with the BAs conflicts in a story over AC, nonsensical AC, WTF verbiage, etc. So then the developers get confused and we are in long meetings addressing what is messed up. We are here to help you ask the questions you didn't think to ask. We don't just test..... we look at future issues too. We like process improvements. Automation: Stop asking me to automate a one-off feature test that hasn't even gone through UAT yet. It's time wasted. Too many companies do this. Might as well give me the day off for the time it takes to do that because the automation is useless after UAT. Learn the purpose of automation. Product Owner: When I tell you before a demo not to demo certain things because there are still issues, don't shred me after the demo because you decided to demo them anyway and they break. I TOLD YOU not to do that, and why. Data: QA worst nightmare. My last position I would get two test records to test against 20 AC when I first started. I said "Helz no". I built up a catalog of test records I could use, positive and negative, as I progressed because I want multiple records against every AC. Which I often shared with the developers for their unit tests who loved it. QA needs data, all. You give me two records, don't yell at me that coverage isn't thorough. Probably sounded more a rant. But I'm opinionated. Where many QA are not. And these are common issues. Want to improve QA, improve the above.

54

34 Comments

OK, let's talk about Platform Engineering. Good grief. Platforming is a topic that has grown into a life of its own in tech, and not in a good way. I'm going to row against the current. Platform teams are an anti-pattern. If your developers don't know how to properly provision and maintain infrastructure that is both supportable and minimizes cost and emissions, then you need better developers. Maintaining infrastructure in a consistent, supportable, optimized fashion does not require a team of people. A platform is not infrastructure nor is it the automation to maintain said infrastructure. A platform is a collection of APIs and messages that bind applications together. Again, this does not require a dedicated team of people. Platform teams are waste. Platform engineering is cover for justifying that waste. #platformengineering #platforms

8

13 Comments

If anyone needs an engineering manager / front end JS and PHP skill set, DM me. Fwiw, and more abstractly: It feels odd to put out a feel for a “traditional” dev skillset when code is coding code on its own, and so many companies (including LinkedIn) are marketing “job retraining,” which is just code for the process of figuring out how to replace more humans with code.

2

1 Comment

🔥 Hot take 🔥 : Your first PR reviewer shouldn't be human and shouldn't wait until you push or commit code. Your first reviewer should happen at the moment you write code. If you create custom linter rules, you can enforce standards at no human cost and which will be enforced immediately.

1

What is the one thing you need to do as a software manager if your team has absorbed responsibility for managing more systems or has lost personnel? I hope you said “redo my org mapping.” If you didn’t, take 5 minutes to read what I have to say. You need to identify the gaps in your new org: skills, knowledge, experience, and resources. Gaps represent unbounded risks; risks which tend to materialize at the most inopportune times. Minimization of risk falls under your purview as a manager and it is your responsibility to assemble, quantify, and plan to address as many of them as possible. It is not, however, your responsibility to do this in isolation. If you have never done it before, find someone who has. If that’s no longer an option (RIFs suck, I get it) then do the following: 1. List all the applications your team is responsible for  2. List all the technologies that go into them  3. Ask your team to rank themselves in terms of knowledge of the apps  4. Separately, ask each person to rate their confidence with the technical stacks you now own 5. Finally, ask them to rate their knowledge of the domain Now take that list and sit down with your tech lead, product manager, and if possible, boss. Work out what is or isn’t acceptable. Then figure out what impact mitigating the issues you’ve uncovered has on the quarterly or half year plan. Rumsfeld said it best when he spoke “there are known knowns, known unknowns, and unknown unknowns; with the later being the most difficult.” You have a chance to remove a whole bunch of unknown unknowns before one or more become a catastrophe. #projectmanagement #tech #planning #management #layoffs #softwaredevelopment #leadership #riskmanagement #strategy

2

1 Comment

If you're subscribed to Janet Gregory & my Agile Testing Fellowship newsletter, check your spam folder! November's issue just went out. We talk about the many benefits of user-centricity, inspired by the research in the 2024 DORA report.

10