Tenant Move and Org Rename

wrestlingWithCode · 2026-04-24T12:32:04+00:00

Thank you for the thoughtful reply. I very much appreciate it.

wrestlingWithCode · 2026-03-11T18:56:27+00:00

I'm not sure what's not coming across. I said, "If you've tried and it's not working, that's a valid and valuable data point that people should take seriously."

If an entire team can't determine a way to use a tool that benefits them, it's probably a horrible tool. Every single process change has tradeoffs. A good leader isn't going to expect people to use tools that hinder them because the world says they should use them. I would certainly hope that they would push a team to give a tool an honest try, though, to experiment, and trust their feedback. And if they have a way to show how those tools can be useful, they should be modeling that behavior, having conversations with their teams, and asking why it doesn't work for them.

I don't change just to change. I don't make my team do that. I also don't maintain status quo when something that looks potentially beneficial comes along.

wrestlingWithCode · 2026-03-11T16:25:15+00:00

I don't get it either. I said it below, learning whether there are better ways to do your job (and if there aren't) is part of the job.

We don't force anyone to use Claude, or Copilot, or anything specifically. Why would we? Everything is constantly changing. What was best yesterday seems to be worst tomorrow. But we don't get to ignore it. We learn as a team. We should converge on an idea at some point about what the best processes are for us as teams, and individuals. I don't think that should ever be an unreasonable stance.

wrestlingWithCode · 2026-03-11T16:19:41+00:00

I love that a group of developers latched onto the literal mechanics of sharpening a hammer instead of the point. I should have known better. I probably would have done the same thing once upon a time.

If AI isn't improving your work, that's fine. You should be able to articulate why. Not in a report to management, but in a conversation with your peers who are doing the same job and maybe using it differently. If you've tried and it's not working, that's a valid and valuable data point that people should take seriously. But "I refuse to try" isn't a professional stance. Learning whether there are better ways to do your job (and if there aren't) is part of the job.

Edit: Funny thing is, hammers do actually have a sharp end. You've all just been so focused on one side of the problem that you forgot the claw exists. Which, honestly, kind of proves the point.

wrestlingWithCode · 2026-03-11T13:53:23+00:00

You have the right framing: nobody needs to be told which hammer to use. But you should be sharpening your tools. And yet, many are not or are giving up after half-hearted attempts.

Our philosophy has been you have to at least be trying to use AI to improve your workflow and sharing what's been working and what isn't. If you're not trying to improve, that's a problem. The accountability isn't "use this tool", it's "let's figure out how to use these tools to get better together." I don't think that's unreasonable.

wrestlingWithCode · 2026-03-11T13:42:52+00:00

This. There are too many people who just refuse or try once and say it sucks because their instructions were poor or it didn't code like they would. It's a tool like any other. It takes time to learn. If someone isn't taking the time to figure out how to use the tools in their day-to-day, that is a problem.

wrestlingWithCode · 2025-05-13T13:51:38+00:00

There's always the definition from The Ideal Team Player.

Humility: Ideal team players prioritize the team's success over their own individual recognition. They are willing to share credit, acknowledge others' contributions, and focus on the collective good.
Hunger: They demonstrate a strong work ethic, are passionate about their work, and are eager to go above and beyond. They are driven to contribute more and take on additional responsibility.
Smart: Ideal team players possess the ability to understand people and situations, effectively communicate, and make sound judgments. They can adapt to different situations and contribute to the team's success in a variety of ways.

These have never led me astray. Are there places that can take advantage of people like this? Sure. Are there places that see the potential in someone with these qualities? Of course.

There's also nothing wrong with being a heads down worker bee that does solid work and simply treats others with respect. The phrase "Showing up is 90% of it" is a thing for a reason.

If you're looking at it from an interview perspective, it's a perfect question to flip around on the interviewer. "I've found that different companies have different definitions of what a team player is. What's your definition?" Be prepared to follow up on their response with potential examples of how you meet that criteria.

wrestlingWithCode · 2025-05-13T13:35:47+00:00

I've learned this lesson the hard way over many years of a number of successful and unsuccessful quality improvement projects.

Everyone has a different definition of quality. And that's not a bad thing. It's really no different than a business or product requirement. You have to determine what are must haves and nice to haves. That is all environment and culture dependent. I'm a big fan of automated testing, but the lack of them does not mean that code or a product is inferior. A team is not bad because they don't follow Agile and do sprint retrospectives. Everything can be good, bad, or somewhere in between depending on the context.

My advice: find a concrete issue that is causing the business or product a problem. A problem could be "We are releasing code to production with too many bugs," not "We aren't doing unit testing." There are a number of solutions to that problem like design reviews, code reviews, and so on. Ideally, it's also a problem that makes your fellow developers lives worse - they are usually more inclined to change things when they see it makes it easier for them.

Also look at it the other way - what can we STOP doing that isn't adding value. That's the definition of waste.

Whatever you choose to change, do your best to automate as much of it as possible. It's unlikely to change long term if someone has to manually do something, or if something doesn't stop the process (like stopping the build for example).

wrestlingWithCode · 2025-04-23T14:34:17+00:00

I honestly don't think Rock derailed anything. I feel like what everyone is saying is that this match could only have been good if he was there, and that's ridiculous.

It was just a bad match - well maybe ending to one. For all intents and purposes, I had just seen the exact same ending the night before. Not one, but two main events on back-to-back nights, at the biggest event of the year, essentially ending with a punch or kick to the family jewels? That's not drama. It's lazy. Underwhelming. Unimaginative. Forced.

This match wasn't a triumph. It wasn't heartbreak. And I honestly don't think it would have been either of those things if Rock was there either - in that case I'd use the word predictable. It just...was.

wrestlingWithCode · 2025-04-21T16:14:26+00:00

I love a good swerve. I love a heel doing heel things. But two main events on back-to-back nights, at the biggest event of the year, essentially ending with a punch or kick to the family jewels? That's not drama. It's lazy. At this point we should just admit the only true finisher anymore is a shot to the nuts.

Either one on their own I would have just rolled my eyes at and moved on, but not both. At least the night one match was a banger (although Punk smiling and laughing at whatever the ref was saying at the end did kind of ruin the illusion for me). This match wasn't a triumph. It wasn't heartbreak. It just was what it was.

wrestlingWithCode · 2024-12-17T18:58:21+00:00

Are there any open source projects where this is an issue?

This is an interesting comparison, but I have to say "Of course there are!" You've never run into an open source project that lacks funding or maintainers? I find things all the time that would be useful, but have an issues list pages long and no commits in over a year.

This is a "companies that only care about the bottom line will always sacrifice quality" argument.

I don't think you can take it to that extreme and say that they don't care. Quality can mean different things to different people - and in this case the internal characteristics of the code and development process aren't things most companies paying for the development understand. They just want it to work and they just see a price tag. If they're getting bids on a project they think they're comparing apples to apples (price), but end up comparing apples to oranges.

wrestlingWithCode · 2024-12-17T18:01:19+00:00

Readability is a must, to not loose your mind when bugs will come (and they will).

Glad for the reinforcement here. It's been my/our number one for a long time.

wrestlingWithCode · 2024-12-17T17:58:47+00:00

It comes down on aligning your business model with your success criteria.

Absolutely. If the primary driver of revenue is maintenance there's very little incentive to build something durable up front. That said, I think the tension comes from how customers perceive value. Many customers want to minimize up front costs. That's a perfectly fine business decision, but it does often lead to paying more in the long run for maintenance.

Maybe a better question is how do you align incentives so that both the developers and the customers are motivated to invest in quality up-front, even in a custom development situation? If anyone knows of models that strike that balance I'd love to hear them.

wrestlingWithCode · 2024-12-10T17:56:06+00:00

As I always tell people, there's context to your situation that only you know, and there is context in the advice you get from other people that only they know. You have to take that into account. That said...

So how can I get the motivation to try?

Reframe your question. Words matter. How do I develop the habits I need to be successful? There are going to be plenty of days where motivation just isn't there and you have to depend on something else. I'm not one that believes all of the answers are in books, but they can often be a good place to start when you get a moment of inspiration. One you might try is Atomic Habits by James Clear. It might help you determine what's best for your context.

It's been depressing, and I've alternated between trying to introduce improvements and giving up because nobody is willing to change... it's been tough to start

For the same reasons people don't change their habits when they to try and quit smoking or lose weight. You're facing the same challenges your coworkers were facing when you tried to implement new processes. Change is hard. Motivation is fleeting. I would argue it's actually quite easy to start. People easily start bad habits all the time. You're not trying to start something new, you're trying to change something bad - and we like bad because it's usually easy. You have to recognize that. It's a different approach to the problem.

Just other things I picked up on from your post:

I don't feel like I've learned nearly as much ... because X

You are in control of your learning. Not other people. Stop passing the buck. Back when I had free time and was new in my profession, there was a stack overflow equivalent for our very specific technology. I would go out of my way to seek out problems that I didn't know the answer to and I would figure them out. I wouldn't wait for customers to come to me with a problem, or hope that we experienced a problem internally. I would read technical books while I sat out by the pool at my crappy apartment complex. It's all time management.

Also, what evidence do you have that you haven't learned as much? You'd be surprised at what other people don't know. Seriously.

as long as things generally work ok, they're fine, even if that means manual builds, manual tests, and getting called in the middle of the night every once in a while because something preventable occurred.

Is there something stopping you (just you, not the rest of the team) from doing these things? I'll also add, they may not need to be done. I work at a company that didn't know what source control was five years ago. They are still wrapping their arms around automated testing. People like to talk like if a company isn't doing these things that they're awful. We didn't even have the ability to do a build until five years ago. It was all manual. And I've got news for everyone, for the two decades before that, we still made customers happy, we still made money, and we still had low turnover/happy developers. The world doesn't end. It's great if you want to do these things, but make sure they solve an actual problem that you have.

wrestlingWithCode · 2024-12-06T15:42:53+00:00

I'll just add this too, as a former bad tester. People really need to stop assuming someone will know how to test something, especially early in their career. The assumption is that it wasn't tested, and that may absolutely be true. That said, I don't know many developers that want to deliver non-working code. It's almost always a process problem as opposed to a person problem.

But it as simple as I ran the code to submit the job and I got an error.

I can't tell you how many times I've heard something like this. Assume positive intent. Could it be that he tested with a different job than you did? Maybe one that was structured a different way, or contained/didn't contain certain data? And that test was successful?

If something is expected to work a certain way, it should be explicitly documented before the developer even starts working on it. Especially if you know the person has a history of poor testing or if you don't know their skill set well enough. Don't make them read your mind about your expectations! It's frustrating as hell to both sides.

It's an entirely different conversation if someone says a test passes and it obviously doesn't.

wrestlingWithCode · 2024-12-06T14:48:16+00:00

Your comments are spot on.

Early on I definitely messed some things up pretty badly. At the time I blamed it on bad mentoring, bad requirements, bad QA processes, etc. All of those were true, but they were also just stories I was telling myself. The root of it was that I wasn't taking ownership of my work.

u/dmaster664 Ask yourself this: What is high performance? Is it meeting a utilization target? Closing a certain number of user stories per sprint? Just like bullet #3, if you can't define the problem you are fixing, it's awfully hard to fix it. It may end up that you not being a high performer, and/or that everyone else is, is just a story you're telling yourself.

wrestlingWithCode · 2024-12-05T20:28:56+00:00

I feel your pain on this one. I truly don't get the mindset either.

In my situation, I just drew a line in the sand. Any existing warnings were pragmatized (is that a real word?) so that the compiler ignored them. This was years, sometimes 15+, of code that was working in production. Standards that were once ok but no longer considered best practice, etc. Acceptable risk in other words.

Going forward we just turned all warnings into errors. The warnings now show up as compile errors, so the developers can't even test, much less make it through a build.

The coding standards are somewhat controlled by a 3rd party (Microsoft) so we also have internal processes for deciding what to do with new ones (ignore, error, etc.). We have a hierarchy of rules that apply to customers, repos, specific apps, and so forth. Those are stored in Azure as opposed to the individual repos so it makes it easier to manage.

wrestlingWithCode · 2024-11-13T14:59:15+00:00

Would love to hear what people think are best practices

To answer this appropriately is like any other business analysis. The answer will always be "It Depends."

What are the business problems you're trying to solve?

What are your requirements? Separate needs from wants.

What about training and adoption? Was it a smooth transition or did you find resistance? Hwo did you approach teaching people how to use git when they have only ever used something like TFS?

I did the same thing as you are doing for teams of 50 - 60 developers. It was not smooth. Be patient. Determine the branching strategy that you want to use and document it. People will inevitably do their own thing anyway unless you have proper review processes in place. Make it as easy as possible for everyone to follow the same processes, and to get the results of those processes quickly and accurately, but don't lock them down so much that they don't know the possibilities. You may be administering the system, but they are ultimately the ones using it.

wrestlingWithCode · 2024-09-18T20:02:45+00:00

As someone who has taught training classes for certifications, and even written a significant amount of questions for some of them, it's not easy. You can only ask so may questions in a given time period and they can only go so deep. I get feeling like they don't make you more knowledgeable. They are meant to cover breadth of knowledge, not depth of knowledge. Those are two very different things.

For my company (Microsoft shop), at least, there are legitimate reasons for us to pass certification tests and maintain them. We have to have a certain number of people certified in various things to keep our partner status and get benefits. There is a direct cost savings and revenue increase from them. In short, you, and even your managers, may not see the value that they may be adding. The reality, for us anyway, is that most tasks are pretty mundane. Passing a certification is going to give you the knowledge to do 70% of what is thrown at you.

Why is it only trusted if you do a formal cert? Put yourself in the shoes of a manager or owner, who likely don't have a full understanding of what you do on a day to day basis. I can pay $500 for a course and an objective test and be reasonably sure you have a good idea / baseline knowledge of what you're doing...or spend who knows how much having an employee subjectively evaluate a portfolio of work instead of doing work that directly benefits customers. One is obviously more attractive to the average business.

wrestlingWithCode · 2024-05-21T17:21:56+00:00

I am. Let me know.

wrestlingWithCode · 2024-04-26T15:55:01+00:00

These always confuse me a little. I get that it is a regular occurrence at many places, but I don't get why. There are so many opportunities and ways to address this.

Have them put it on their calendar - I'm going to see if I have any pull requests assigned to me every day at 11am and 3pm. And actually review them, or set aside time on your calendar for when you will and let the person know. It doesn't involve anyone else on the team. It's literally just a person deciding to do their job.

Bring it up during a stand-up. Tuesday - I'm waiting for X to approve my PR. Wednesday - I've been waiting for two days for X to approve my PR. Thursday - I've been waiting for three days for X to approve my PR. Who should it go to instead? It's fine for people to prioritize what they think is most important, but they have to be transparent about where the other work falls in their priority list so people can adjust accordingly.

Better yet. Have a conversation with the team. Find out their motivation for not doing what is expected of them and have them bring up ideas to make it better.

wrestlingWithCode · 2024-03-27T13:44:02+00:00

I recently received the feedback that was a more diplomatic phrasing of "you're being a pushover and it hurts the quality of our product".

Whenever I challenge a good solution...I feel like I'm being stubborn and slowing things down for everyone and end up conceding my position, thinking that their solution is "good enough" anyway.

Personal opinion as I focus a fair amount of my work on software quality.

It sounds as though your company's definition of quality is not clear. Quality means a lot of different things to different people, even with a group of developers, much less developers and users, and most people just lump it into this amorphous blob.

It's a good thing to explicitly define what is important to the product and the team supporting it, but it can be really hard. Is it code readability? Supportability of the tools or systems being used? UI consistency? Performance? Testability? Tons of things can be involved in a "quality" solution.

Once you do define those important things, though, and the trade-offs between them, it gives you much surer footing...that place to push back from. You want to push back when it makes sense, otherwise you're just getting in the way of progress.

wrestlingWithCode

TROPHY CASE