• 0 Posts
  • 33 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle



  • Well, welcome to society, which consists of different types of personalities all mixed together. You want to stress-out everyone else too. That isn’t better. There is no one-size-fits-all solution. As others said: the solution is to have individual exemptions, not preventing everyone from get-togethers in the first place.

    Edit: btw. not even “introvert” is a good-enough category. I am also introvert and am completely depleted of energy after a day in the office or a team event. But I still enjoy it. You need to force me to attend, but afterwards I am typically glad I did.


  • I’ve worked in many projects where I met people only over phone and WebEx or similar. It was always pretty “dry” and tensions rose quickly whenever shit on one end hit the fan. Typically after just one personal meeting (kick-off, war-room, whatever) that changed completely. You start to joke together, you let your guard down more easily. You talk differently, even on the phone and in virtual meetings then.

    I also often enough witnessed people bitch at each other over some formulation in a pull request or a comment in a chat room. In person they completely behaved differently and were able to talk it through.

    Not everyone ticks the same, but in a large team you can be sure to have at least some people who have an easier time reading body language than hearing nuances in a voice filtered through a microphone. And for these people it’s then less stressful to work stuff out in person.








  • I said it takes years. The point is that you can do it incremental. But that typically doesn’t fit with the way enterprises want things done. They want to know a beginning, a timeline and a price. Since they don’t get that, they simply give up.

    But it’s dumb, since those systems run already and have to keep running. So they need to keep engineers around that know these systems anyway. Since maintenance work likely doesn’t take up their time, they could “easily” hit two birds with one stone. The engineers have a fulltime job on the legacy system (keeping them in the loop for when an incident happens without having to pull them out of other projects then and forcing them into a context switch) and you slowly get to a modernized system.

    Not doing anything doesn’t improve their situation and the system doesn’t get any less complex over time.


  • What pisses me off about many such endeavors is, that these companies always want big-bang solutions, which are excessively hard to plan out due to the complexity of these systems, so it’s hard to put a financial number on the project and they typically end up with hundreds of people involved during “planning” just to be sacked before any meaningful progress could be made.

    Instead they could simply take the engineers they need for maintenance anyway, and give them the freedom to rework the system in the time they are assigned to the project. Those systems are - in my opinion - basically microservice systems. Thousands of more or less small modules inter-connected by JCL scripts and batch processes. So instead of doing it big bang, you could tackle module by module. The module doesn’t care in what language the other side is written in, as long as it still is able to work with the same datastructure(s).

    Pick a module, understand it, write tests if they are missing, and then rewrite it.

    After some years of doing that, all modules will be in a modern language (Java, Go, Rust, whatever) and you will have test coverage and hopefully even documentation. Then you can start refactoring the architecture.

    But I guess that would be too easy and not enterprisy enough.