It sounds like you've been hurt by the some terrible management practices, I'm truly sorry that some managers think their job is to control their subordinates.

However, regarding ticketing systems, in team environments, it is very effective and helpful to have a system that manages the data about the work that has been completed, is being worked, and is planned to be worked on .

Part of that system might be defining restrictive workflows for some teams, not for control, but to ensure the agreed upon process is followed for quality or consistency.

One of the many problems Jira has is that if you don't have a Jira admin on your team, it's impossible to build an effective and efficient workflow for your team. Coupled with Jira making many things global by default (it takes a lot of care to make a change that only affects specific Jira projects) most configurations end up being a pile of garbage automatically inherited from changes an admin(that is not part of the team) made when intending to change something for another specific team.

Caveat: this is going to be a meta comment rather than a comment about the topic proper, and so maybe not appropriate for HN, but I think it's worth discussing.

> It sounds like you've been hurt by the some terrible management practices, I'm truly sorry that some managers think their job is to control their subordinates.

When we assume someone was hurt, and imply they hold an opinion only because they were hurt, we risk delegitimizing their position. The interpolated message we might be sending is "your experience is personal and not representative of the subject at hand, and so your thoughts are only applicable to your situation; so, after we express our sympathy, your thoughts can be dismissed." Or the message we might be sending can be patronizing: "you hold your opinion for emotional, rather than rational, reasons; I'm sorry that you are so unfortunate."

To be clear, though, I'm sure this wasn't your intent, and it makes me glad to see someone being compassionate (i.e. that you bothered to consider the experiences and feelings of the parent commenter).

A personal story: I was raised devoutly religious but left the church in my twenties. My family and friends assumed I left because I wanted to be free from guilt, had been hurt by a culture that belied the doctrine, and so on (and they said as much). My change of belief occurred after recovering from a few years of mental illness, and while it is true that I may not have left when I did were it not for the opportunity to reexamine my beliefs (while trying to piece back the fragments of my life into a sense of self), the reasons why I left were the result of a lot of research and thinking. It was mildly frustrating when people assumed my decision was made for emotional convenience, when in reality, the research was uncomfortable and contemplating an unfamiliar universe was scary.

I recognize the irony here – the issue I'm highlighting in this comment may be something that only I feel is an issue, born from a personal experience. But I think it's more common than that.

I sincerely appreciate your articulation of this, thank you for taking the time.

>ensure the agreed upon process is followed for quality or consistency

That is what I mean here by "assembly line" and "control." Making sure that processes lead and individuals follow.

Citing consistency as a terminal value in the same breath as quality is also exactly what I mean by the middle-manager aversion to local differences.

Beyond trivial scale, you need good processes so that individuals can do their jobs. If you have no processes, change and development becomes extremely difficult because people will be hunting for documentation all the time, stepping on each other's toes, and making mistakes that they should not be making because they forgot a trivial procedure that was a prerequisite to solving their actual problem.

I work with a variety of different environments, and depending on the environment I can either solve my problem in minutes and get it deployed in another few minutes or solve the problem in minutes and spend hours figuring out how to safely deploy it without breaking everything. JIRA is terrible if you do anything that it offers by default, but when used properly it can absolutely help with this.

To add to that, and perhaps educate your downvoters a bit, it can be very hard to imagine why or when such strict processes are helpful without having direct experience with organizations of sufficient scale. It literally boggles the mind but the process truly is king when there are hundreds (or thousands) of individuals working on a single product.

Agreed. An essential part of blameless engineering culture is "the outage isn't any one person's fault, it's the fault of the tooling and processes for allowing them to do that". Good processes prevent everyone from making the same mistakes.

IMHO the "correct" or at least humane organizational design is that most things happen in local teams, which are of trivial scale and can get along just fine with informal, ad-hoc, or locally varied processes.

Obviously not all work is this way. Sometimes you need to drive a migration that touches every team, and then the technologies of bureaucracy and process become important. But most work should be done in human-scale groups that can be more towards the self-organizing and trust-based end of the spectrum.

However some middle managers take offense to the idea that their different sub-teams have different operating models internally, and lean on technologies like JIRA to try to make them all the same. Middle managers at my company have tried this, not very effectively , so it hasn't hurt me too bad. But I've seen their vision and recoiled in horror.

>However, regarding ticketing systems, in team environments, it is very effective and helpful to have a system

I think the point is that Jira is particularly granular in the way that it lets you do things with permissions, workflow rules, roles, metrics, etc. There's a fair number of places that use that granularity to create a weird digital sweatshop.

Meaning the complaint is more about really deep "micromanagement as a service" than what you might get with lighter tools.

Micro managers are everywhere, even in places that may seem culturally incompatible. I’ve yet to work for a business that prioritizes regularly evaluating managers for their management skills. It’s only addressed when shit really hits the fan. Managers are primarily evaluated by their own managers on deliverables. As long as they’re getting results and entire teams aren’t quitting simultaneously there’s no need to question anything. As long as a manager is toxic in ways that don’t break the law or violate major company policies any attempt to address this by a direct report carries the risk of termination or retribution. Does it contradict your company’s cultural values? Rules for thee.

And I wouldn’t assume you’re not one of them. The worst cases I’ve run into aren’t even the psychos that embrace micro management as part of their “management style”. It’s the ones that genuinely believe they aren’t engaging in the behavior. They’re not micro-ing, they’re “helping” their team because they are an awesome manager and their team is almost awesome, they just need to be monitored very carefully and given “suggestions” until they nail it. But they’ll never nail it. Because no one is as smart, experienced or does a task “just so”. They view themselves as a mentor to all. All decisions must be theirs to make. Jira becomes the perfect tool since the team effectively becomes little boxes that accept tickets or stories and return work both performed and delivered as specified.

For any managers reading this that don’t see a problem with this or see some of those behaviors in yourself please understand that you are sacrificing your team’s happiness and motivation at the altar of your own insecurities. No one can grow where they’re not trusted and no one can improve their skills when they’re never given latitude to make meaningful decisions. Your people will make mistakes. They will accomplish things in ways that are different from how you would do them. It might even be objectively worse. That’s ok. That’s how you grow into a strong team with confident members.

Kanban, by design, was a tool used in production control. It's one of the ways Toyota made their JIT production function.

I worked on the line (Toyoda Iron Works) and used a real-life Kanban implemented by the plant engineers. It was used for quality control, to broadcast quality control and station output, and was checked regularly against their internal estimates and baselines and used also as a gauge for employee output.

Control is what it's designed to do. The very fact that Kanban is the tool of choice should support at least some of OP's points, objectively.

Agreed. This is a problem of scale in my opinion. When we have 10 engineers, it is easy to check in with everyone and know what they are working on and get a status update. When we have 500 engineers, making sure all their tasks are aligning (organizations are one big race condition) is not just hard but impossible without some sort of tracking system. We all want to grow big. To do so, your processes need to change as you add more people. The exceptions (Valve, Netflix, etc.) that can handle being flat or semi-flat are very unique.

Are they unique because their problem domain allows it or because the leadership is uniquely ideologically driven (and competent) to implement efficient, flat systems?

I think it’s mostly the people. They are die hard about their culture. At most of my workplaces, culture is generic and the company would be willing to set whatever culture rules seemed to work.

I was told by a lifetime manager turned successful consultant, that roughly fifty percent of engineering firms govern their engineers basically using fear.

> using fear

Could you elaborate? What kind of fear? “You’re fired”? I wonder how effective it actually is because of the current job market and also because I (and others) react very poorly to this kind of tactics: “you want me to fear getting fired? Joke’s on you, please DO fire me, I dare you”

> I wonder how effective it actually is because of the current job market

Counterpoint: software developers aren't necessarily well paid or highly regarded everywhere, since remote working for companies abroad hasn't quite gotten mainstream enough.

So it might just be effective against some people, or in cases where the hiring process itself has become increasingly unreasonable - the job being working on boring CRUD apps but the hiring process being multiple stages of Leetcode and complex interviews.

That's probably not applicable to everyone since plenty of folk can grokk Leetcode and find jobs without too much trouble, but i still recall "The Unseen 99%" article: https://www.hanselman.com/blog/dark-matter-developers-the-un...

It probably applies to the industries and companies where devs are treated as a cost center and since those companies aren't all out of business, plenty of people must be working in such environments, with sometimes sub-optimal conditions.

I'm guessing it's a sort of a nerd shorthand for "various means that are accompanied with self confusion of users but not with strong rational or scientific or technical basis"

The perf process is basically one big exercise in fear-based control.

> ensure the agreed upon process is followed for quality or consistency.

Isn't that just a more corporate way of phrasing "control"?

Not in a negative way. You want to trust engineers to always have changes built and tested before they go to production, but when something egregious happens you need to go back and see what went wrong. You can choose to interpret that as control, but really the only alternative (often cited) is "Well that shouldn't ever happen, so you don't need tooling to support that situation".

And that is not a useful way of thinking when you have real engineers writing software that people depend on.

I think the problem is that the processes are often not mutually agreed, but instead dictated by middle managers.

JIRA then becomes a tool for enforcing arbitrary rules, e.g. control

This is very likely even if engineers come up with the processes, unless all process is scrapped and done from scratch every time an engineer is hired.

> Selling a % and keep working on it as a product manager, letting everything else to be handled by them.

Why did you start the company in the first place?

If you wanted autonomy, consider that you'll completely lose it by selling (regardless of promises made).

If it were me, I'd look to hire an executive, maybe someone late in their career who could bring in the roles to handle the work you don't care about (running the company). If you found someone in early retirement they may be willing to work for equity and only X hours per week, which would free budget to hire other roles (HR/bookkeeping, marketing, etc). It'd require finding good people that are willing to wear multiple hats, but the right executive might already have great connections.

What I'm learning from this is that anything Jeff Bezos has his hand in is litigious. Amazon did the same thing with the JEDI contract for federal government cloud hosting when they lost the bid.

I'm sure it'd be cheaper for Disney to rent devices locked to their app for a day than pay for these line proctors and the person that's still taking the orders.

I don't know the stats behind it, but I've heard from news that those with the vaccine do still host the virus when exposed and even continue to pass it along (although they experience lesser/no symptoms).

If vaccinated people do become infected at the same or similar rate to unvaccinated (and a whole lot of other assumptions), it almost seems like there is a scenario where the vaccine could be worse than the virus because we're essentially creating many Typhoid Marys that continue to host and spread the virus unaware that they're contagious, giving the virus a massive pool to mutate within.

> If vaccinated people do become infected at the same or similar rate to unvaccinated (and a whole lot of other assumptions)

They do not though. You getting sick from any virus is a function of your particular immune system, the viral load you're exposed to, the virus' infection mechanisms, and your manner of exposure.

Vaccines affect the first two points. They train your immune system to recognize the virus as something its seen before and it has ready antibodies to fight. Your immune system responds more efficiently to the virus and neutralizes it faster meaning that any point during your "infection" you've just got fewer virus particles to shed and spread to others.

If you're exposed to a high viral load you might become symptomatic, your white blood cells can only work so fast, with a breakthrough infection but since your immune system is pre-trained for the virus it'll be a shorter and likely a less severe infection than if you were unvaccinated.

The Typhoid Marys you're describing are the massive pools of completely unvaccinated people getting sick. The unvaccinated remain infected longer and end up producing more copies of the virus from their infected cells. If the virus generates a beneficial mutation (named variant) after a trillion replications and each unvaccinated person produces a billion replications (made up round numbers) then we'd expect a variant every thousand people infected. If a vaccinated person only produces a million replications then it'll take far longer for a vaccinated population to generate a variant. You may never even see a variant emerge if the infection rate drops below pandemic and epidemic levels.

Definitely can agree with the sentiment. I've done frontend dev since '97 and have multiple times skipped a year or two without staying up-to-date with the current browser/development trends without issue.

It's generally pretty trivial to keep up and maintain usefulness by focusing on the fundamentals (I completely skipped the DHTML fad for example -- lots of widgets you could throw into your page that animated around) and instead picked up JS DOM API and CSS once browser support stabilized a bit.

---

Just a note, when I visited the page there's a small bio intro on the post that introduces Rach as a woman.

Ah, thank you for pointing it out. I had a brain fart. I edited and explained in the comment.

It seems like it'd be incredibly difficult to obtain accurate data through a mass survey. I know in work places "anonymous" surveys are often given where employees know/think the data is not truly anonymous and as such do not provide honest input.

I'd imagine this survey could be impacted similarly, either by underreporting because of shame/fear or falsely reporting in an attempt to get their detainers in trouble.

I think it was a joke, I actually thought it was pretty funny

The lag around the Britain bank when busy (even sometimes Moonglow bank) made it nearly unplayable though, and the game was only 2D.

I remember on a player run server (Novus Opiate) we had a random battle one day of red vs blue and we had about 80-100 people in Britain run through a portal into Buccaneer's Den, slaughtering all the reds, and all the reds banded together to kill the blues. It was well over 100 people with minimal lag, with most people on 56k modems.

But Britain bank with lots of people was always laggy. Especially if there wasn’t a server reboot in over a week.

Apple typically has the last newer hardware support of any phone or pc manufacturer. My daughter still uses a 2011 iMac without problems and with relatively recent security updates.