My exercises are hard to describe in words. I spend a week in physiotherapy at that clinic with 3 sessions a 1.5h a day, where they show you the exercises and correct your position.
I'll try to find videos for you.
1,064 karma · joined October 28, 2016
My exercises are hard to describe in words. I spend a week in physiotherapy at that clinic with 3 sessions a 1.5h a day, where they show you the exercises and correct your position.
I'll try to find videos for you.
In 2008 I had very severe carpal tunnel syndrome for over a year. Then I found a clinic that had specialized in pain patients. They found out that the muscles my neck where shortened and weak. Neck is connected to shoulder is connected to arm is connect to wrists leading to my symptoms. Got a lot of exercises to lengthen and strengthen my neck. That fixed the wrist pains. Whenever they rise again I start do these exercises and it goes away.
My current construction site are the muscles that connect the legs to your hips/lower abdomen. They shorten too, due to the constant sitting position plus going by bike to work. This leads to back pains/slipped disks. Need to lengthen them as well.
However, in my experience working on a big product with multiple teams, the main problems with devs getting creative is
(a) the consistency of the user experience suffers badly
(b) the overall architecture erodes as everybody builds particular solutions fitting their specific problem
I am not sure what the best way is to reconcile Dev happiness and (a,b) in this context.
Wow. I have never thought about it this way. That's quite a profound insight. Thanks.
You start with the JTBD by the customer. Then you identify pains and gains of these jobs.
Then you think of what "pain reliever" and "gain creators" you could offer and how to bundle these in products/services.
I come to think that the whole concept of MVP/prototype became a bane to software development when the management/business side got aware of its existence. Architecture and design sessions can be skipped because we just build a prototype.
I have yet to see a prototype that did not end in production. It's "good enough software", let's move to the next feature.
When you are really lucky you can revisit your prototype a year or two later and try to improve it's design now that you got some data on its actual usage, but you have to figure out again, what the heck you actually did...
- loss of agility in finance, HR, product development as you have to check back with the corresponding divisions of the new parent company to get aligment/green light for any kind of investment.
Worse: not being able to make independent strategic decision in these areas, but only follow orders
- restructuring of upper management that creates disquiet/uncertainty with in teams -> productivity sinks
- Parent company's sales force/marketing does not know how to integrate your product into their current portfolio/process. (Example, when a manufacturing company wants to "go digital", buys other company but their Sales has no idea how to sale digital products)
- focus shifts from "working on your product for your customers" to "integrate with their system/ their other divisions" who have no idea of your customer base.
- corporate politics takes over the decision making process
- general much more "process" creaping in, make you develop much slower. (but that does not have to always be a bad thing)
You cannot immediately inspect the code or check out the type of discussion the devs on this project have around code reviews, issues etc...
What is your real world experience in this regard?
For your mental health I can recommend some of the modern Stoic approaches to life. Most prominent candidate here is "A guide to the good life". Good luck.
But I am wondering: in a professional setup, are there no better tools to analyse and interpret structured log messages out there?
I think the following rules will cover most cases:
1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
2. Never use a long word where a short one will do.
3. If it is possible to cut a word out, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than say anything outright barbarous.
===
[1] https://www.orwell.ru/library/essays/politics/english/e_poli...
https://domainstorytelling.org/
I really like the approach of event modeling recently:
A subclass should behave in a way that it never cause problems when it is used instead of the base class.
In concrete terms:
* No new exceptions are allowed to be thrown, unless they are subtypes of the exception thrown by the base class
* Preconditions cannot be strengthend by the subtype
* Postconditions cannot be weakened by the subtype
For me it is really the focus of using inheritance only if you want substitutability. Otherwise go with composition.
I thought code reviews are the only way and then you need to have every Dev aligned and on the same page on this topic... Which never happens. :/
The amount of cross team coordination is staggering.
Germans need a clear plan/path, how to get from A to B, with concrete steps that need to be taken. If no such plan is in place, the uncertainty makes us feel uncomfortable. We also need to know who is responsible for what, who is the point of contact for which problem and who will/can decide what. That should ideally be clarified in project kickoff meetings. Meetings in general must have an agenda, the goal and which questions must be answered must be clear. This also drives who should attend the meeting.
French not so much. They are totally fine with not having a detailed plan. They just start with the work. They feel/think that "things will get sorted out when the time comes" and "someone will do it" or "someone will remember to bring the item to the meeting". To them we Germans are way to much stressed out about the plan and project structure. Meetings will be announced where there is no clear agenda, the goal is just "to align everybody" which often results in an unproductive mess.
For a long time I thought that our product management just did not have their shit together, that it was always chaotic, with change of plans on short notice, not giving a headsup on important topics and information getting lost in the shuffle or not reaching the right person etc. Their communication style is also more indirect, not confronting people/issues in meetings, but rather sit in silence through it and then later complain/being irritated about what happened in the meeting.
A year ago I was lucky to pick the brain of an much older Begium high profile project lead (from a completely different company/field) who had worked a lot with French and German teams on many different projects. He said he preferred working with German over French teams and roughly described what I was experiencing. Then it dawned on me, that this is not incompetance, this is just how they operate. I talked with my french manager about that and he was like "yeah totally", he outright said that he loves it when the plan is fuzzy and the scope is unclear.
From there on I saw many things through a much more understanding lens and respected their way of doing things. (For example, where we might overthink and over analyse stuff, they just start and get shit done. Or where we stress out about defining in detail processes and responsibilies, they also "just do it".) And actions (or inactions) that sometimes lead to (for us unexplainable) friction became clearer to me. I also realized, that you cannot change the people (and their working style). You have to adapt to it and compensate for the things that bother you (ask for an agenda, ask who will explicitly do what or better just do it yourself, bring the items yourself, etc).
Also when you work across cultures you need to adjust your tone/approach. As a German working with French coworkers, it took me a while to figure this out.
https://hbr.org/2016/11/how-to-write-email-with-military-pre...
Can only say good things about the tool.
My neighbor two house apart from ours had beehives. Through a nifty arragement of his shrubs and bushes he achieved the same effect as in this new bee-box and had his bees go up when leaving the hive. Their flight path was a parabel and they came down again in our yard.
In spring time you could not hang any cloth outside. It would get swarmed with the bees as they were clearing out the poo of their hive that they had accumulated over the winter period. It was such a mess. Every frigging spring.
Did it get deleted? Do you have the hn link?
* Do guerillia gardening a throw seed bombs ever you can.
* Reduce your waste output. Try worm composing when you live in a flat.
* Use a bike or public transport instead of a car.