On Improvement (Day 11)

14 aprile 2021

No, there are no days from 3 to 10...

See On Improvement for the intro and explanation.

See On Improvement (Day 2) for the first installment.

Here we are, with a set of interesting days on my personal Toyota Kata experiment.

Since March 26, I had a total of 11 working days and I've continued my experiment, tracking daily the plans, the actual happenings, results and learnings.

Here I want to collect all the things I'm supposed I've learnt.

If I'm not able to plan the day properly, I have to get in touch with the rest of the team to understand daily needs.
I should try sending emails, involving the team, instead of direct messages, to probably be more sure someone will get back to me.
Excel is the dark side of information technology, when used as most of the world is using it...
I have to learn JS, React and a gazillion other things.
Again, I was not able to plan the day, so I've almost improvised, but this time worked better since I was at least able to pair and share with team's colleagues.
The connections between people and different departments in a big company is not so easy. Also finding the right person is not easy at all.
I now know which buttons to click to create the things described in the online training, even if I still don't know the goal and the purpose of those things.
It's not that I dislike CSS or React/JavaScript, it's only that after 20+ years with Java, it's not so easy to learn a new syntax and way of programming.
MC has an unstable Internet connection. :D The Mule project setup is very old and not properly managed. Initial setup is not clearly defined inside its README.md file. Software projects shall be kept as much as possible up to date with revisions, versions and external libraries and tools, otherwise becomes impossible (or very very very hard) to let other people work with the project.
Do not trust external contacts or reliability or feedbacks.
Do not use company-internal social network. Never. Ever.
Mule updates are a long process, that require information and mapping for each JSON field that has to be ported. There are a lot of needs, checks and agreements that have to be put in place to complete the overall migration.
Collaboration between different areas and departments is not easy at all. Not sure people are always willing to cooperate, whatever their reasons. About PROJECT products, PRODUCT and orders (and a gazillion other things), there is a lot of mess or responsibilities, contacts, actions, ...
- AC, should probably know about who's in charge of placing orders on PRODUCT, for products;
- UV might have the products data;
- LM is in charge of TYPES only;
- There's someone else in charge of TYPE only;
- MT is pushing for some other info;
- DV knows about PRODUCT, but he's in charge of Distribution only;
- ML is in charge of PRODUCT production plus product masterdata;
- CC and AS are managing the Item Masterfile stream in PRODUCT, whatever it means.
It's important to check all the small technical details and to consider all limitations.
Never trust human-made Excel spreadsheets. And never trust humans that use exHell.
Again, never trust human-made Excel spreadsheets. And never trust humans that use exHell.
PROVIDER has a very bad training courses set, with pointless and quite time-wasting video courses that could become simple documentation on the tool itself.
Network is unstable. Even in Milan. Even gigabit optic fiber.
PROVIDER has a very bad training courses set, with pointless and quite time-wasting video courses that could become simple documentation on the tool itself.
I still hate CSS :) but it's actually getting nicer because I understand it a bit more.
It would be possible to (possibly easily) reuse front-end components that have been created with the goal to be general.
The software documentation cannot always be trusted.
Human beings are not reliable.
It's always hard to fight against the constraints of a framework, specially if the framework does not fulfil its own expectations and functionalities.

On Improvement (Day 11) by Marco Bresciani is licensed under CC BY-SA 4.0