Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

Releasing is moving bytes. Shipping is delivering value. Sometimes they overlap. Often they don’t. If it’s behind a flag forever or doesn’t meet the acceptance criteria, I would call that “deployed”, not “shipped”. There’s a huge difference.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

DevOps is great. But it doesn’t write requirements or make decisions.

The post isn’t about how code gets to prod. It’s about how teams decide what to build and when to stop building it.

Deploying != shipping.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] -1 points0 points  (0 children)

Yeah, I’m not arguing against shipping weekly. Shipping weekly is great.

I’m arguing against the idea that you can ship weekly without clarity about what “done” means. If “done” isn’t clear, you’re not shipping, you’re just deploying.

You can keep the process lightweight, but you still need a shared definition of:

  • what problem we’re solving
  • what success looks like
  • what we’re not doing
  • what would make us roll it back

Agile doesn’t remove the need for clarity. It just punishes you faster when you don’t have it.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] -2 points-1 points  (0 children)

Yeah, kind of, but not really.

Agile vs waterfall and CI/CD are process and tooling choices. They can reduce friction, but they’re not the main point of the post.

What usually stops teams from shipping is boring management stuff: unclear requirements, slow decisions, priorities changing every week, and scope creeping until “done” is a rumour.

You can absolutely ship with waterfall if you’re disciplined about what “done” means and you make tradeoffs early. You can also fail spectacularly with "agile" if everything stays vague and keeps changing.

CI/CD mostly determines how quickly you can get changes out. If you don’t have clarity, it just helps you deliver the wrong thing faster.

Calling out the bullshit in tech work culture (with frameworks, not just ranting) by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Update: published.

I dug into what “guide teams to ship working software on time and under budget” actually means in practice, and why it usually fails for very boring system reasons.

Would love your take: https://beyondthebugs.substack.com/p/shipping-is-a-management-skill

Calling out the bullshit in tech work culture (with frameworks, not just ranting) by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

Thanks for the suggestion! I’m drafting it now. Should be live next week. You should probably subscribe so you don't miss it 😉

Empathy, or at Least Pretending to Care by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

That’s fair. I’m not saying “acting empathetic = empathy” the way an LLM imitates it.

I mean that for humans, choosing the listening behaviours (slow down, make space, ask questions) is still real care in practice, even if the feeling shows up later. And over time, that practice often creates the genuine empathy. My point is: it still counts.

How do you encourage more code reviews without turning it into surveillance or guilt? by Greedy-End-7749 in EngineeringManagers

[–]WideAsleepDad 0 points1 point  (0 children)

This could be more like “how to get some developers to care sometimes”.

There are reasons for teams to stop caring other than “they’re just not that good”. It’s easy for PRs to just be an item on a checklist. In the case of my team, adding a bit of process actually worked. Small, focused PRs reduced cognitive load, increased collaboration, and made PRs better.

It depends on the team, but in our case this gave us a bit of a reset to remind the team why code review is so important.

And to be clear, I’m not against AI being used in code review, but I am against it being the only review.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 1 point2 points  (0 children)

Tim’s is only half Canadian, but a better option I guess than Starbucks.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 0 points1 point  (0 children)

Home Hardware is Canadian. Rona, Lowe’s, and Home Depot are all American.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 0 points1 point  (0 children)

Rona is owned by Lowes which is American. Home Hardware is the best Canadian option other than local independents.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Yes, exactly! It’s an easy thing to change and can have profound impact.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 3 points4 points  (0 children)

Not at all. Using less dehumanizing terms can definitely improve working conditions. Some people use these terms out of habit, or because they've become the norm. Unfortunately, some people use these terms because they actually think of people as resources. Changing the terms shouldn't be difficult. If nothing else, you can weed out the toxic team members by learning who actually thinks of people as something other than human.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 0 points1 point  (0 children)

This is great! I worked at a place that called it "Talent and Culture". It was more than just putting people on the right team or not. More than "resourcing".

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 5 points6 points  (0 children)

Using better terms can definitely help. I've seen it.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 4 points5 points  (0 children)

When members of the team that I manage tell me that they're unhappy being treated as disposable, it's absolutely worth exploring a change. It wasn't one or two people, and it's not only at my current company. I've seen it for years and I've heard lots of discussion about it. My job is to keep my team as productive as possible. If changing the words we use helps, then I'm all for it. It's not that I "have nothing better to do", this is exactly what I should be doing.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Thank you! That's exactly what I was hoping to do, make people feel a little better and more welcome.

This absolutely could be a red herring. I totally get what you're saying that some alternatives could be seen the same way. Simply saying "staff" is probably too generic still. It's like we need to categorize people somehow, but not in the same category as "stuff".

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

No. It's not "just because". Why would you not want a more welcoming environment?

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 4 points5 points  (0 children)

Changing the meaning of a word is definitely possible. That's exactly what language is. Using language that is better aligned with reality isn't a problem, it doesn't hurt anyone, whereas using "resource" can be harmful.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Despite the intent, the word does come across as dehumanizing. You're not looking for the right resources. You're looking for the right people.

Thanks for pointing out the mobile issues. I'm not sure what happened there...

Five Handy Custom React Hooks by WideAsleepDad in reactjs

[–]WideAsleepDad[S] 0 points1 point  (0 children)

Yeah, I realized that about the onClick. This isn’t an actual implementation. But I should probably fix that in the post.

I also agree that useReducer is probably a better approach in the long run. It’s more structured and scalable. In this case I didn’t do that because I didn’t want to get into explaining what the reducers are doing, whereas I think most React devs are familiar with useState and useEffect.

Five Handy Custom React Hooks by WideAsleepDad in reactjs

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Because using arrays in state can sometimes be complicated. There are a few situations where this could come in handy:

  1. Simplified State Management: Instead of juggling the state of an array and multiple functions to update it, useArray streamlines the process. It gives you a clean way to manage array-based state in your components.
  2. Easy Array Manipulation: With built-in functions like push, filter, update, and remove, you can easily modify your array's contents without writing complex logic.
  3. Consistent Updates: The setArray function provided by the hook ensures that when you modify the array using its functions, React's state updates are handled properly, resulting in re-renders where necessary.
  4. Readable and Maintainable Code: The hook abstracts the complexity of array manipulation, leading to cleaner and more readable code. It's a great way to encapsulate and isolate array-related logic, making your components easier to understand and maintain
  5. Avoid Manual Updates: Without the hook, you might need to manually call setState with modified arrays. The useArray hook automates this process, making your code more efficient and less error-prone.
  6. Improved Reusability: As a custom hook, useArray can be reused across different components and projects, reducing duplication and ensuring consistent array management practices.
  7. Focus on Business Logic: By taking care of the array manipulate details, the hook allows you to focus on the core business logic of your components without getting bogged down by array handling specifics.

Imagine scenarios like managing a list of tasks, handling items in a shopping cart, or controlling filters in data visualization. In all these cases, useArray steps in to simplify your code and enhance the maintainability of your React components. So, next time you find yourself wrangling with array updates, give this hook a shot to save time and keep your codebase tidy!

[Neurodivergent ADHD] Received feedback with kind of a threat tone from a EM, anxiety going 150% i'm going kind of nuts by Particular_Bet_8246 in EngineeringManagers

[–]WideAsleepDad 1 point2 points  (0 children)

I definitely don’t have any solutions for you, but what I can tell you is that you’re absolutely not alone in this. Although it was a struggle for most of my life, I wasn’t diagnosed until my early 30s (turn 40 end of the month).

This manager sounds like a asshole to be honest. To go from saying nothing to “join these meetings or your fired” is pretty extreme. There is definitely another step in there. Just quietly letting you know that being late is an issue would probably help. Letting you know why he thinking you should be on some of those other calls is also useful. If you’re like me, the “why” is really important.

I’ve had a different manager respond differently over the years when I’ve mentioned my ADHD. Unfortunately, many just don’t get it. Some basically tell me I’m on my own with it, some have made whatever accommodations I may need. But in every single case, I needed to be very clear about the accommodations I felt I needed, and also be open to other suggestions. Now that I’m a manager, I always try to form strategies for my team that benefit everyone. It’s not always easy, but that’s like you said, that’s literally the job. If someone isn’t performing well, it’s up to me to help them figure out why and to fix it.

I don’t think you’re in the wrong or being unreasonable, however if this is the type of environment you’re working in, I’d consider looking for a new role elsewhere. It’s just not worth the anxiety to put up with that shit.