That's an interesting observation. I can see both sides of that coin.
137 karma · joined January 31, 2013
To my eye, the whole line from personal technology in the 80s -> through UX on the internet -> through app platform lock-in -> through subscription-centric "ownership" have been providing us all with the promise that we can buy our way into less friction. The next device or subscription solves problems or enables us one way or another. We see this line of history, draw it into the future and see a utopian future with zero friction.
Zero friction meaning zero difference between how you want to feel about the world and what you get out of it. More feeling empowered or satisfied or comfortable or right.
The parts of our culture that embrace friction are the slow parts - grousing with neighbors, weeding a garden, letting the other car go first. These are the parts where we meet with the reality of other people or nature. Maybe there's a tool or framework or gadget that could help, but we know and accept that there is something immutable outside of ourselves and we have to find a way to flow with it.
I'm getting older, I'm finally starting to see the limits of pursuing a frictionless life.
FWIW, I'm struggling with documentation that support the mix of roles on the team in addition to coders/contributors - QA engineers, product owners, project managers, support teams, etc. A big part is the capture of requirements flowing into proposed solutions and out into support documentation.
In reply to _kb, it did occur to me that there are many job descriptions at play here, and that change is inevitable. Perhaps the answer is simply that it takes many people and several genres of software to keep things from falling through the cracks.
The idea that a reader of a piece of documentation is approaching it with a particular goal is spot on. I suppose I envision either more or perhaps another layer of goals/contexts in addition to what this is outlined here.
A set of use cases I'm thinking of involve the process of changing what a piece of software does. As design documents arise that may or may not apply to a future version of the software, where should that live? Perhaps during the design phase of that release it belongs in one place while designers are iterating on its contents, and later it moves to another place when it is considered a stable reference document?
Plenty of capital P Process behind this question, I suppose. And perhaps there's no getting around some amount of the "librarian" work moving content around to reflect its use.
With a team of folks with different skill levels, when there's information to capture, I'd like there to be a clear single place for it to live so that it's easy to place there and easy to find again.
* To ensure accuracy of transactions, he should have built reporting to meet the needs of accountants.
* To support change, he should have kept his components separate and provided modest testing examples.
* To support developers and operations, he should have found and documented the external dependencies along with steps to verify that they are in place.
Whether product managers didn't uncover these requirements or the business didn't prioritize them, these aspects of the definition of "done" have more to do with thee environment the engineer is working in and less to do with his or her work.
> In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.
Reviewers are human too, and can occasionally get lost in the weeds nitpicking a PR/CL.
What strikes me most about PHP is the fundamental request/response execution model. Your execution context begins when a request is received and ends when we send the last byte or terminate the request. There's no startup healthchecks, no cache warming or any other bootstrapping of your service unless you jump through convoluted hoops on your own. Your service is either accepting requests or it isn't. You either lazy load your data into APCu or you don't. I've leveraged AWS healthchecks to achieve these in the past, but that path is not very maintainable.
Inevitably in the course of maintaining a service, I find use cases for a phase of execution that should occur before the server is live or shared static memory that should be available at all times, but (unless I don't know something) those are things that PHP doesn't do.
This is the reason that I find PHP to be a bizarro language - for its fundamental design assumption!
I agree with you about the value of training... adopting these practices should come with a change of mindset since good judgement is required to succeed in practice.
Who knows if that is circadian rhythm, conditioning, a combination of both...
Does anyone have similar references for doing 0-downtime migrations? For example, building your indexes with CONCURRENTLY to prevent table locking.
From what I'm reading, I think you're looking for the ability to deeply immerse in problems when the time is right.
When you're deeply immersed or in a flow state, your conscious and unconscious are completely aligned on a common goal. In fact, your conscious mind participates less and less in the tasks - only providing high-level strategy notions to your work, letting your subconscious tactical problem solving, recall and muscle memory do the work of getting the solution out into the world.
When it's working:
- your working memory (i.e. the classic 7+/-2 figure from psychology) is filled with the task at hand, and nothing else. Not only are you not thinking about other things, but you also have no doubts or second thoughts about what you're doing or how you are doing it.
- you have short feedback loops in place, letting your brain's pattern recognition work effectively.
- you have all of the tools you need at hand to solve the problem, and don't need to switch tasks to build/acquire them.
When you're in this state, you don't need a dopamine rush from anything else - you're caught up in in the problem, and don't need something to synthesize the excitement of discovery. You're getting that from the task!
Conversely, some examples of how it can break down:
- The steps required to reproduce your test conditions overflow your working memory, especially when decisions or analysis is required. Any conscious thought put towards the steps to recreate a test case is a task switch away from the problem you're solving. You might want to invest in scripts to automate some or all of the work.
- you're not sure if your approach is the right one. Now you're spending some of your problem solving energy on the "meta-problem" of how best to solve the problem. Take a moment to prove to yourself that the approach is at least worth investing in and then move forward.
Finally, know that deep immersion has its own drawbacks! Most importantly, while deep into solving one problem, it's easy to "over-invest" by going down the wrong path. For now, you might consider that a good problem to have and a sign of success at acquiring this skill. Honing the skill of choosing between the two approaches is level 2 ;)
I suppose I was wondering if there are any good drills, exercises or puzzles to help internalize these skills. Instead of a daily crossword, maybe there's a daily estimation puzzle somewhere.
memorizing useful facts, selecting facts that lead to a meaningful estimate, the mental math to compute the final result
With both Pomodoro and GTD, ideally you'd learn to switch more quickly between the planning brain and the doing brain. This allows you to decide what to focus on, acquire full confidence that it's the right thing to do now, and act on it. This helps you tie the immediate need to your larger goals, channeling your motivation for big rewards into the task at hand.
See also: no alcohol sales before noon on Sunday, no discounted liquor at restaurants, and every bar/pub that sells liquor must also sell food.
Let's run with the conclusion a bit - What would society be like for there to be a critical mass of critical thinkers, aware of new developments, in a position to act and motivated to speak up?
The cynic in me sees that list and despairs. How can we expect the average parent of 2 to keep C-SPAN on throughout the day, calling their senators on lunch breaks, and boycotting products that would give them an extra hour back every week that could be spent playing with their children.
That's how it would look, right? Instead of skimming political/technical news that entertains us while validating our viewpoint, we'd be parsing legalese like it's a pull request. Instead of binge watching Netflix, we might be driving to a store to buy something that could have arrived yesterday via Amazon Prime.
It's all quite doable. It's just not immediately comfortable. It's also not a priority in our lives, since it's so easy to prioritize anything else with immediate feedback or gratification. However, humans are very good at internalizing and normalizing. When motivated, we can make virtually any behavior livable, or even comfortable.
So that's the trick. How do we normalize critical thinking, due diligence, and active engagement?
It provides examples of the kind of active listening and questioning mentioned in the article.
https://en.wikipedia.org/wiki/Nonviolent_Communication#Four_... https://www.amazon.com/Nonviolent-Communication-Language-Mar...
For example, if you are building up a queue of commands to be run in sequence with a bit of preprocessing, you might create a class that exposes: `addStep`, `preprocess`, and `run`.
At least for me, the impulse to create a DSL was always a secret desire to hide implementation details from readers so that they can see the intent of the code more clearly. Really, those implementation details are critical for maintainers to understand. Otherwise a DSL's magic is likely to hurt a maintainer when their expectations are off.
Can you put your finger on what you boss does that is unacceptable? Is it because of:
* the way she/he makes decisions? * the way she/he provides feedback? * the way she/he defines success for your tasks? * the way she/he socializes?
If you uncover the underlying behavior that could be better, this should help you do a bunch of things:
* Decide for yourself how you would handle these situations * "Manage up", by framing what you bring to your boss differently and giving feedback, if possible * Learn not to behave in this way for others * Recognize these traits in others more quickly so you can get ahead of the behavior and in the worst case avoid those people.
I know none of this answers your question. To find an environment that you thrive in might take a good bit of trial and error over the years, plus a good bit of "character building."
I'm not a fan of adding features that make poor choices less painful, but I could see using it for a little while as I'm getting to know a non-ideal environment.