There was a project that I was on that did get a little ridiculous. It was a major German airline and we were redoing their website (front and back). Team was in three countries including India. Maybe 25 developers? We had a spec document that we had to code to, including the front-end wireframes. If there was an obvious mistake in the spec, like a misspelling for a button, we still had to code to the spec along with the misspelling and then file a bug against the spec. They fix the misspelling in the spec and now there's a bug in the website...
So a bit more flexibility than that and the project would have been great.
I mean it’s possible somebody just writes like that, but I wouldn’t bet money on it.
Separately, do you have any thoughts on the subject matter? Whoever or whatever put these words in a row, they resonate deeply with my lived experience of the last several years.
I dabbled in writing, I would have hated for random people to assume my posts where AI generated, especially given that such a claim is practically unfalsifiable at this point.
(Comment guaranteed 100% human generated.)
EDIT: Although with just how generic the advice here is, and the ChatGPT images, this feels like a particularly egregious example of just dumping out LLM-generated content.
So "LLM-written" works as an insult, but it doesn't seem useful as a category for written works.
Besides, aren't some of the biggest SF companies all about AI right now? Aren't the big investors, developers, and thought leaders in AI present on, if not owning this site?
As an individual, you can only downvote, comment, or leave; if it's really important to you, leaving is unfortunately the only choice and in all likelihood nobody will miss you / it won't have made a difference. But it'd be better for your own sanity.
Ok sure maybe you didn’t write it, but if the team working on the tickets don’t scope and question them you’re doing it wrong. Of course things are going to turn out badly.
> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.
That's tangential to tickets.
We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.
That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.
Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.
Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.
> “Yeah, good thought, but just stick to the ticket for now.”
That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."
> Ask why the feature matters? You’re overstepping.
Ask why the feature matters and you're a good dev!
But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!
Now with tickets there's an opportunity for dialog and a paper trail on decisions.
> Suggest a refactor while in the code? Not in scope.
This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.
> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.
Those aren't gold plating, they're part of code quality checks that go into reviews.
The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management. Before I had tickets, developers worked on what they wanted to work on
In support, most of the time "solving the actual problem" is irrelevant, and "closing the ticket" is paramount.
Looking back on it, yeah it absolutely felt like I was being told to stop thinking.
breckenedge•7mo ago
I didn’t meet the first full-time designer in my career until 2013. If there were designers around, it wasn’t their only role or they were mostly contract. Before that, developers were intricately involved with the design process. It maybe wasn’t as pretty but it sure wasn’t was buggy.
And project planning used to be done by engineering leads. Now you have specialized PMs who really know nothing about engineering practices. Engineering managers were responsible for whole project plans. We lost a lot when we gave up that role —- there’s a lot more trust and collaboration between an engineer and an EM versus an engineer and PM.
I’ve liked my career less and less over the last 10 years or so because I’ve seen every company go this direction. I think companies do it to de-risk, but it makes the whole process more expensive.
koakuma-chan•7mo ago
You mean a UI designer?
hansmayer•7mo ago
Cheer2171•7mo ago
breckenedge•7mo ago
jonstewart•7mo ago
breckenedge•7mo ago
sarchertech•7mo ago
When I took software engineering classes in school, talking to customers and subject matter experts and figuring out what they wanted was a core part of what we covered.
All these extra layers really are just an absurdity. You hit the nail on the head with your point about de-risking. It seems companies would rather hire 10x the people and spend 10x the money for a 75% chance at producing something mediocre than taking a shot at making something great.
To some extent you can go work for startups to reduce your exposure to this kind of environment, but these days any startup with more than 5 employees thinks they need a PM.
Don’t get me started on UX designers. I’ve taken rigorous HCI classes in grad school. It’s a real academic discipline with tons of theory behind it.
What most UX designers are doing now isn’t close to that. What happened is that number of print design jobs collapsed, and everyone who had a basic understanding of design principles decided to call themselves a UX/UI designer.
So now in many companies you have entire teams of PMs and designers who have next to no engineering understanding designing features and systems before anyone who actually knows how to build the thing even hears about it.
My long term plan is to find some small niche where performance, correctness, and reliability are highly valued and build something that a modern software factory or a VC backed startup with a move fast and break things attitude can’t compete with.
My suspicion is that what I’m looking for is a very small slice of the customer base of an existing very boring piece of business software.
spacemadness•7mo ago
xnx•7mo ago
Absolutely. Graphic designer != UX professional. A background in graphic design is often negatively correlated with making logical and ease to use interfaces.
bryanlarsen•7mo ago
The best had a good rapport with both customers and engineers. Engineering experience helped gain this, but I've seen good ones without a lot of engineering experience. But I've never seen a good one without any engineering experience.
sarchertech•7mo ago
The problem is when companies try to create scores of “mini CEOs” (this is actually how PMs were explained when they started popping up) to oversee every aspect of every product.
A CEO of any but the smallest companies will have many other responsibilities, so they’ll have no choice but to delegate the majority of the decision making to the people actually building the product.
A PM running the search feature or the user onboarding experience or the notification system doesn’t have this limitation.
Also don’t get me wrong, I’ve worked with some fantastic PMs, but they were fantastic despite the role not because of it. Every good PM I’ve ever worked with had the capacity to be a good engineer even if they didn’t have the experience.
bryanlarsen•7mo ago
spacemadness•7mo ago