2 ms·

As a worker one deals best with large companies by maximizing thru put. I always keep more than one project going and when one is blocked I do something to save

As a worker one deals best with large companies by maximizing thru put. I always keep more than one project going and when one is blocked I do something to save state, and pick the next most urgent one to work on. (Where urgent can also mean “fun, no deps and a clear improvement towards the long term goals,” even if relatively unimportant). However for development process, latency is a total killer. Your growth equations vary smoothly between “development work returns simple interest” and “development work pays off as expinentially with time” as the interval between a change and it being fully known to be good in production drops to zero. Put it this way. I am going to have that second cup of coffee. Making the whole pot at once pays off consistently day over day. Will this slightly different way of doing the load balancers pay off tho is less certain. It needs experimentation. And if I can turn the dial and watch the effect in real time, I learn quickly. If I wait one week for each data point, I learn slowly.

lanstin 6y ago
Also the happy path for my save state is just flick away from the given labeled shell/emacs in tmux. Some things need a note jotted down but then I have failed to do something earlier. Sometimes he thing to save state is just put in a syntax error where I am working; that way I can afford to forgot the task altogether. All these pending tasks bear only a light resemblance to the project tracking entities. For that project stuff, I mostly fight to reserve bandwidth among the team to work on long term projects that are experimental (and so not always plannable in advance In detail) but with a highly desirable end state. Like now I am working to make good terraform modules that make the common use cases of change to be simpler and more concise than without the modules. We find a good use case, do a module, iterate a few times based on how it works out, then find a other use case. I refuse to “write stories” for the future tasks in this extremely valuable work because it’s a back and forth between solution space and actual work for actual customers. I don’t need giant modules that are as complex as the raw terraform, I need to solve specific problems in the specific business.

lanstin 6y ago

Also the happy path for my save state is just flick away from the given labeled shell/emacs in tmux. Some things need a note jotted down but then I have failed to do something earlier. Sometimes he thing to save state is just put in a syntax error where I am working; that way I can afford to forgot the task altogether. All these pending tasks bear only a light resemblance to the project tracking entities. For that project stuff, I mostly fight to reserve bandwidth among the team to work on long term projects that are experimental (and so not always plannable in advance In detail) but with a highly desirable end state. Like now I am working to make good terraform modules that make the common use cases of change to be simpler and more concise than without the modules. We find a good use case, do a module, iterate a few times based on how it works out, then find a other use case. I refuse to “write stories” for the future tasks in this extremely valuable work because it’s a back and forth between solution space and actual work for actual customers. I don’t need giant modules that are as complex as the raw terraform, I need to solve specific problems in the specific business.