Once I discovered a (for me) new feature in the iOS Google Maps app, showing recently uploaded videos and images for places in my vicinity. I was randomly browsing through it until I found a video of a woman on a car‘s passenger seat trying to pee out of the side window. Wasn’t expecting her to succeed…
Anyhow, reported it and went on, but couldn’t find it later when I wanted to show to friends.
I wonder if smartphone vendors couldn’t provide a test mode which doesn’t require the unlock code for the phone. E.g. if I get my phone display replaced nobody needs access to my full personal data to test of the basics are working.
There could be a special mode accessible which allows testing of standard use cases.
Android already has a boot menu. It would be useful even for consumers to have an option "Self-Test" added to that list. I think the only real concern would be the storage space required if the test suite was large.
What I couldnt find out so far is what the chip manufacturers are producing instead of automotive chips then? There must be another industry which has a significantly increased need or will get a lot of chips earlier than planned. Wondering which industry that will be.
Basically everything we use? Many many things have electronics inside that is chips and as demand have moved from services to things there is more things bought, thus more demand. Then add to this some distortions... These are chips in question, not that there is not also demand on high-end. But that is also makers learning that it's better for them to constrain supply. RAM for example was at one point very cheap.
AMD growth is gone through the roof in general computing, and they're the sole supplier for both PS5 and Xbox's CPU and GPU chips. Unlike Intel who have their own fabs, AMD is locked into TSMC - and when auto manufacturers relinquished slots, they went in.
Nvidia ships a boatload of chips for Nintendo Switch plus GPUs for almost all altcoin miners that can be mined with GPUs and everyday regular gamers.
Car manufacturers released all of their slots at the beginning of 2020 so those were sold to the entertainment industry instead. Turns out there is a price on not dying and it's "a car instead of public transportation".
MBition | Embedded/Backend/App Software Engineers, Architects, Product Owners, DevOps, various roles | Berlin, Germany | Full-time | ONSITE (mobile office possible and currently used by everyone due to COVID-19), REMOTE for special cases possible
MBition is a 100% subsidiary of Mercedes-Benz RD. Traditionally focussing on infotainment software (in-vehicle infotainment, smartphone apps, cloud backend), we are extending our focus to other domains in the car gradually, e.g. ADAS (advanced driver-assistance systems). We have many cool projects going on and generally we try to bring state-of-the-art modern professional software development paradigms to the automotive world. Our shareholders/mothership puts big trust on us. We are a product development and delivery team.
Our stack contains (among others) C++, C, Qt, Yocto, Linux, QNX, AWS, Jenkins, Gitlab.
Telegram is storing your message content in their cloud for „cloud chats“ (default), as those are not end-to-end encrypted.
Telegram‘s „secret chats“ and signal chats are end-to-end encrypted. The servers still may store metadata, and there is no way to tell if they do than either joining them or let a trusted third party verify that.
To check if e2e encrypted message content cannot be encrypted via backdoors on their servers, you need to ensure they use proven encryption schemes and the client encryption does correspond to those algorithms.
MBition | Software Engineers, Architects, DevOps, +various roles | Berlin & Stuttgart, Germany | Full-time | ONSITE (mobile office possible and currently used by everyone due to COVID-19), REMOTE for special cases possible
MBition is a 100% subsidiary of Mercedes-Benz RD. Traditionally focussing on infotainment software (in-vehicle infotainment, smartphone apps, cloud backend), we are extending our focus to other domains in the car gradually, e.g. ADAS (advanced driver-assistance systems). We have many cool projects going on and generally we try to bring state-of-the-art modern professional software development paradigms to the automotive world. Our shareholders/mothership puts big trust on us. We are a product development and delivery team.
Are you open to hires that are looking to relocate? This is an industry I'm super into but live in the US. I'd love to move out to either Berlin or Stuttgart.
MBition | Embedded/Backend/App Software Engineers, Architects, Product Owners, DevOps, various roles | Berlin & Stuttgart, Germany | Full-time | ONSITE (mobile office possible and currently used by everyone due to COVID-19), REMOTE for special cases possible
MBition is a 100% subsidiary of Mercedes-Benz RD. Traditionally focussing on infotainment software (in-vehicle infotainment, smartphone apps, cloud backend), we are extending our focus to other domains in the car gradually, e.g. ADAS (advanced driver-assistance systems). We have many cool projects going on and generally we try to bring state-of-the-art modern professional software development paradigms to the automotive world. Our shareholders/mothership puts big trust on us. We are a product development and delivery team.
I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that all those teams which have a sustainable pace with regards to architecture, technology, quality, output, social behavior, etc have done so while adopting and embracing Scrum in a clean way since the beginning of their existence as a team. All teams severely struggling with their content of work, output and collaboration have also severe issues with regards to Scrum-adoption, and show anti-patterns similar to the Stackoverflow thread creator‘s. However I would say the root causes (which we discussed in maaaany meetings) are certainly neither caused by Scrum nor increased by it, but individual mindset, dysfunctional team dynamics, pressure, weird contracts, etc. and would be there under any other or no process framework.
I am no Scrum fanboy (I think), but this experience and also from former projects make me quite sure to not blame Scrum in the first place when I see struggling teams, but trying to understand the underlying problems and solve those.
One more thing: In answer to Scrum advocates claiming its about doing it right I would disagree and replace it with understanding what is really (really REALLY) the purpose and idea behind it. Don’t worship the cult and don’t fight it because it’s the perfect target of rants, but see the motivation behind it and acknowledge that there may be reasons why it makes sense how it is to some degree. This doesn’t only apply to Scrum but to any other interaction of humans.
Let me try: I think it’s about reflection and continuous improvement and providing a framework to enforce those. Scrum-haters in our group are also notorious for an attitude of negativity and resignation in many matters, while Scrum-friends want to improve all the time and find ways to do so, beyond what is obvious.
I think that Scrum leads to resignation for many people, because it takes away control out of individual and insists on everything being collective. So your personal options to improve or make decision becomes severely limited.
Some people like it, because it allowed them to push themselves on the rest of the team. But people who dont thrive in such constant dominance conflict end up resentful and helpless.
That's an insightful concise description of "agile" experience.
As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic.
Personally, agile hasn't driven me to depression but it has made me target roles that avoid it at all cost. Life is too short and precious to suffer through a detailed status report meeting every.single.day.
I found that testers in particular find agile off putting and some avoid working at such companies if they can. I am not sure why testers specifically end up disliking that.
I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it on the "team". But team is not person, it is set of people.
Second, it kind of assumes that people are socially perfect and everyone is kinda the same and its answer to any social human problem is "that is team dynamic or bad individual". It does not help to deal with predictable human imperfections, emotions and conflicts.
I think UX people should evaluate the different development processes. UX people because they have the concept of that something tasks take more mental effort while other less, e.g. searching for a button within 100 buttons has a cognitive load than searching for a button within 10 buttons.
My guess is that SCRUM has a greater cognitive load than waterfall.
what control do you feel is taken away from individuals? I mean, you discuss tickets with the rest of your team, but that doesn't seem such a big loss of freedom.
These days I sometimes decide not to work on the top priority issue right now, because I suspect it'll take a few hours of uninterrupted log file reading / debugging / thinking to fix, but the day already has three different meetings scheduled.
If that's the last issue in the open sprint, choosing to add another issue to the sprint while there's still an open one tends to be a no-go, or at least causes some discussion, especially if the sprint closes without the issue being closed.
Or sometimes I simply I don't feel like working on a particular issue right now. Maybe there's no rational reason for that. I have no problem overriding that impulse if I know somebody else (either a colleague or a customer) is blocked by the issue, but if it's a case of "we have happened to include issue A in the sprint, but not issue B", having to work on A instead of B against my preference causes unnecessary resentment.
All the control and all the autonomy I would say. There is nothing I would be responsible for where I can make own decision and have them right or wrong.
In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine.
So when there was mess or something was late, it was my fault. I was not due to other people forcing me do things their way and I did not had to fight about every single detail, just because college happen to be anxious or control freak.
Compared to scrum, pretty much any other, quite honestly. The majority of teams I was in did not used named process and for the most part I was alright. Usually there were bigger tasks assigned to people or smaller areas of responsibilities.
For the record, I did not liked when leader had micromanagement/dictatorship tendencies either.
In fact there’s no point in being “agile” in an organization that has no appetite for change (unless those are topdown, consultant-driven, marching orders).
When you’re given the false hope optimization is possible, only to bump into 2-3 layers of middle management and just as many half-broken, Confluence spaces about the “one way of work” for the org... you just content yourself with features and tune out.
My experience with scrum was that it makes issues around bad team dynamic, pressures and weird contracts worst. Basically, it makes it impossible for individual to react to them and defend against worst consequences.
When it is good, scrum powerlesness does not matter, maybe. But when it goes bad, it does.
I would agree that Scrum makes bad dynamics more transparent, yes. I would not agree that it generally makes bad dynamics significantly worse. This may happen and it’s certainly often claimed, but that is not what I can confirm from my experience.
MBition | Embedded/Backend/App Software Engineers, Architects, Product Owners, DevOps, various roles | Berlin & Stuttgart, Germany | Full-time | ONSITE (mobile office possible and currently used by everyone due to COVID-19), REMOTE for special cases possible
MBition is a 100% subsidiary of Mercedes-Benz RD. Traditionally focussing on infotainment software (in-vehicle infotainment, smartphone apps, cloud backend), we are extending our focus to other domains in the car gradually, e.g. ADAS (advanced driver-assistance systems). We have many cool projects going on and generally we try to bring state-of-the-art modern professional software development paradigms to the automotive world. Our shareholders/mothership puts big trust on us. We are a product development and delivery team.
