When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.
https://www.yegor256.com/2015/07/13/meetings-are-legalized-robbery.html, posted 2019 by peter in business management opinion people
A good software architect, as well as a good project manager, doesn’t need meetings and never organizes them.
Meetings demotivate, waste time, burn money, and degrade quality. But more about that later. For now, let’s discuss a proposed alternative.
timharford.com/2019/06/why-brilliant-people-lose-their-touch/, posted 2019 by peter in business cognition management people
This is not to say that skill doesn’t matter — merely that in a competition in which all the leaders are highly skilled, randomness may explain the difference between triumph and failure. Good luck plus skill beats bad luck plus skill any time.
Standing out, rather than fitting in, could in fact be the smarter route to success. A phrase coined in a study published in the Journal of Consumer Research in 2014, the “red sneaker effect”, revealed we confer higher status and competence on mavericks versus conformists.
So we often perceive someone wearing clothing that deviates from the norm in professional settings as having higher ability, rank and respect than colleagues who conform to dress codes.
This is because diverging from the norm signals you have autonomy and can bear the cost of nonconformity – even if it costs you your job.
But she found that in collective cultures,such as East Asia and Latin America, people prefer norm followers as leaders, because they may prioritise organisational goals over their own.
I’ve never stepped into a leadership role without it quickly becoming clear why a new leader was needed. I think it’s normal for companies to hire new leaders when there are problems that need to be addressed. So I suspect that as the congratulations die down, it’s also normal to look at the set of problems that surround you and ask, “Where do I begin?” (also normal: “What have I done?!”). I suggest instead starting with these two questions:
- How do I create clarity?
- How do I create capacity?
In the year 1930, John Maynard Keynes predicted that, by century's end, technology would have advanced sufficiently that countries like Great Britain or the United States would have achieved a 15-hour work week. There's every reason to believe he was right. In technological terms, we are quite capable of this. And yet it didn't happen. Instead, technology has been marshaled, if anything, to figure out ways to make us all work more. In order to achieve this, jobs have had to be created that are, effectively, pointless. Huge swathes of people, in Europe and North America in particular, spend their entire working lives performing tasks they secretly believe do not really need to be performed. The moral and spiritual damage that comes from this situation is profound. It is a scar across our collective soul. Yet virtually no one talks about it.
A lot of evidence suggests that in cases of this kind, employers will stubbornly trust their intuitions — and are badly mistaken to do so. Specific aptitude tests turn out to be highly predictive of performance in sales, and general intelligence tests are almost as good. Interviews are far less useful at telling you who will succeed.
It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required but management keeps pushing for new features. Now what? We talked to Michiel Rook, a Java/PHP/Scala contractor and consultant about the challenges that walk hand in hand with continuous deployment.
https://blog.skyliner.io/ship-small-diffs-741308bec0d1, posted 2017 by peter in continuousdelivery development management opinion
Every line of code has some probability of having an undetected flaw that will be seen in production. Process can affect that probability, but it cannot make it zero. Large diffs contain many lines, and therefore have a high probability of breaking when given real data and real traffic.
This article outlines the scale of that codebase and details Google's custom-built monolithic source repository and the reasons the model was chosen. Google uses a homegrown version-control system to host one large codebase visible to, and used by, most of the software developers in the company. This centralized system is the foundation of many of Google's developer workflows. Here, we provide background on the systems and workflows that make feasible managing and working productively with such a large repository. We explain Google's "trunk-based development" strategy and the support systems that structure workflow and keep Google's codebase healthy, including software for static analysis, code cleanup, and streamlined code review.