That definitely define my everyday job experience.
That definitely define my everyday job experience.
It all depends on the project and the team. On some, you work with and along the PM and all is good, and other times you get dictated unconnected requests that you need to fight or ignore.
I (programmer and team leader) get requests from the king (management and project manager) and pass them to the peasants (code monkeys), clean after their shit (QA and code review). I get peanuts in return while the king keep most of the loot.
For most people the “best music” is the one created during their teenage years.
It all depends on the implementation and need.
In-memory structures are usually faster to work with, but harder to coordinate multiple updates from multiple sources (different applications, services, etc).
Databases have all sort of failsafe mechanisms to ensure data integrity and recovery options, in most times there is no need to reinvent it all over again.
Persistent - do you need to access the data again once your program was finished? How often does the data change by other programs/tasks once you read it? How big is your data and how complex are the connections between your data objects?
Many times the implementation is a mixed approach. It is better to know and calculate the needs before you start your project, but as it usually happen, once you get performance issues, you start optimizing adding in-memory cache or scale to a bigger database.
You start your morning playing mine-field, doing the round squinting for suspicious marks, watching your steps, clearing one room at a time. Today it was the hallway
So there is a solution and the headline should be “Microsoft admits it can’t automatically fix…”