Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Enterprise Experience

churchofturing.github.io

Post reply on HN
Print view View original

141–150 of 158 posts

Re: The Enterprise Experience

#141

Post by pavel_lishin »

claw-el wrote: post #35
3eb7988a1663 wrote: post #28

Missing - new leadership will push out the old guard and replace them with friends - groups get renamed for the Nth time in N years. People continue to do the same job, but now the department has an additional "Innovation", "Discovery", or "Leadership" inserted into the title

> - groups get renamed for the Nth time in N years. People continue to do the same job, but now the department has an additional "Innovation", "Discovery", or "Leadership" inserted into the title Sometimes, I wish we name the team ‘Pikachu’ and continue on working. This way, others would know the name does not really matter, so they would stop changing the name. The amount of work to change the documentation and lets…

I was on a pair of teams (why two teams? who knows) that worked with a given project for about five years. Every year or so, we'd change names - so I've been on "$PROJECT Access", "$PROJECT Insights", and some third thing I forget the name of.

I unironically suggested we just call ourselves $PROJECT RED and $PROJECT BLUE, and refer to the entirety of the team-pair as $PROJECT PURPLE. Nobody liked that, but it is what we ended up calling ourselves internally.

Re: The Enterprise Experience

#142

Post by pavel_lishin »

charles_f wrote: post #94
claw-el wrote: post #35

Earlier quoted context omitted.

> - groups get renamed for the Nth time in N years. People continue to do the same job, but now the department has an additional "Innovation", "Discovery", or "Leadership" inserted into the title Sometimes, I wish we name the team ‘Pikachu’ and continue on working. This way, others would know the name does not really matter, so they would stop changing the name. The amount of work to change the documentation and lets…

God do I hate teams and systems with cute names. It's all cute and fun until you're the one from another team who needs to integrate with you and decode what Pikachu and Tyrion are responsible for, and discover that Fassbender is just a nickname for a Postgresdb maintained by the "It's over 9000" team. AuthService, CacheService, Db and EntrypointTeam are perfectly fine names. I don't care that namespaces are still al…

The upside of having cutesy team names and mascots is that nowadays people just throw something into an AI image generator prompt, and you get a mascot that has clearly been trained on furry fetish art, and during Zoom meetings you get to look around and see who else is trying to stifle laughter when their slide comes up on a presentation.

Re: The Enterprise Experience

#143

Post by cratermoon »

codingdave wrote: post #126

> At this point I hadn't realised that finding who is responsible for something in a large organisation is very much not straightforward. This resonated strongly with me. Last time I worked in an Enterprise shop, I happened to inherit the approval system - every app in the entire org, whether an internal app or from a vendor, got configured into this home-grown monstrosity of an access approval system. It actually wo…

I did a contract at an airline. I was tasked with figuring out why the barcodes a new system was generating weren't scanning. I never did find a person still working there who knew what was wrong, but by sheer persistence I finally found an old email someone had saved a copy o to their space on the company SharePoint. The problem turned out to be the wrong kind of cryptographic signature on content.

Re: The Enterprise Experience

#144

Post by LeftHandPath »

jiggawatts wrote: post #47
BrenBarn wrote: post #23

Always worth keeping in mind Remy's Law of Enterprise Software ( https://thedailywtf.com/articles/graceful-depredations ): if a piece of software is in any way described as being “enterprise”, it’s a piece of garbage. Joking aside, I was intrigued by the list of good things at the end of the post. Some I could understand, but some seemed to fall into that strange category of things that people say are good but really…

> ... Remy's Law of Enterprise Software ... the list of good things at the end of the post. Like the poster of the blog article, I too have worked in very large enterprise. Think 200K staff, 10K distinct servers, etc... I had the lucky opportunity to assist the CTO in hundred-million-dollar enterprise software purchasing decisions. I got to interview vendor after vendor, grilling them to see if they're compatible wit…

Great list. I remember being called in to look at software my company was thinking of buying, once... Only our finance/accounting people had looked at it so far. The thing barely worked. The desktop window kept flashing. Special characters were accepted and then broke the output. Extreme lack of features needed for the supposed goal.

I was able to find us an open-source / self-hosted solution that worked far better (bookstack). But I was amazed at how far the company selling the software got with us -- seems like most never get pushback, they just make sales by labeling themselves as fit-for-purpose regardless of whether or not they generally work.

Re: The Enterprise Experience

#145

Post by pavel_lishin »

senectus1 wrote: post #110
johnhamlin wrote: post #16

Been at $ENTERPRISE for 18 months. This is true it hurts.

I've been at $ENTERPRISE for 20 years... I dont mind it tbh. Its only soul crushing if you let it be.

It only crushes your soul if you let it eat at you 24/7.

Clock in in the morning, clock out in the evening. It's just a job (I repeat to myself like a mantra.)

Re: The Enterprise Experience

#146

Post by pavel_lishin »

al_borland wrote: post #30
time0ut wrote: post #22

It hurt to read this. I have seen all of this and more. - Teams that produce negative output for years with no consequence - Six figure monthly AWS bills on unused resources - Technical people who can't use a computer - Constant re-orgs and turn over Wait until this guy experiences the wrath of big consultants... It is hell, but it pays. I get my fulfillment building my own things outside of work and dream of the day…

I don’t have the energy to build anything outside of work. I spend all of my free time trying to mentally recover. I’m left drained after work. If I’m going to do extra “work”, I always think I should do more work stuff, to attempt to get ahead on some project and reduce the stress of things than have been hanging over my head. The only time this shifts is when I have a couple weeks off. During that period I will ine…

> I always think I should do more work stuff, to attempt to get ahead on some project

Are you a manager? Are you, personally, responsible for this stuff working or not working?

If not, don't let it hang over your head. You work at the circus with the monkeys, but they are not in any way meaningfully your circus or your monkeys.

Re: The Enterprise Experience

#147

Post by Agingcoder »

BrenBarn wrote: post #100
Agingcoder wrote: post #80

Earlier quoted context omitted.

projects beyond a certain size in a large org imply things which are very different - people, networking, money, regulations, politics, business, security etc all things which don’t look spectacular when you have three people, but become very important and much harder with hundreds of people. So career development really means ‘learning a completely different skillset which is not technical’

That's a good way to put it and is something I've often thought as well, although not just in the technical realm. I think of it as "doing a different job". You used to be a teacher but now you're the principal; you used to hammer in nails but now you direct the construction crew; you used to be writing software but now you manage other people who write software; etc. Personally I'd struggle to consider that "develop…

This can be mitigated by learning other technical fields ( infrastructure, security, etc ) and using your technical knowledge to steer things in the right direction - but yes, you’re otherwise right and I understand your point of view.

Re: The Enterprise Experience

#148

Post by kaffekaka »

lelanthran wrote: post #104
BrenBarn wrote: post #99

Earlier quoted context omitted.

I've never understood why anyone would care about titles at all.

> I've never understood why anyone would care about titles at all. I cannot understand this sort of notion at all. 1. You don't care about $SOMETHING - great, I can understand that. 2. You don't understand why others care about $SOMETHING - Sure, I can understand that too. 3. You feel a need to broadcast this lack of understanding to the world - wtf? I mean, I'm ignorant on a lot of subjects, but I hardly ever boast…

Aren't you doing exactly the same thing yourself? Your reply literally begins with the words "I cannot understand ..."

Re: The Enterprise Experience

#149

Post by tomaskafka »

codingdave wrote: post #126

> At this point I hadn't realised that finding who is responsible for something in a large organisation is very much not straightforward. This resonated strongly with me. Last time I worked in an Enterprise shop, I happened to inherit the approval system - every app in the entire org, whether an internal app or from a vendor, got configured into this home-grown monstrosity of an access approval system. It actually wo…

That’s because denial of responsibility is one of purposes of enterprises. It’s not an accidental byproduct.

Re: The Enterprise Experience

#150

Post by stackskipton »

NearAP wrote: post #82
stackskipton wrote: post #49

Earlier quoted context omitted.

Disagree that it's written in lawsuits, it's written to please every customer under the sun and due to this, code base has become Rube Goldberg machine that few people understand.

> it's written to please every customer under the sun Disagree with this. In the places I’ve worked, I’ve lost count of the number of times we turned down feature requests with the explanation that - this isn’t common practice and seems to be unique to you.

I think you are one working at Unicorn. Most Enterprise software I've dealt with ends up with internal coding engine so it can be extended to do whatever the customer needs. Bonus points of getting to charge massive implementation consulting hours for all coders that come along during implementation.
Post reply on HN