📚 node [[long term]]

Welcome! Nobody has contributed anything to 'long term' yet. You can:

Write something in the document below!
- There is at least one public document in every node in the Agora. Whatever you write in it will be integrated and made available for the next visitor to read and edit.
Write to the Agora from social media.
- If you follow Agora bot on a supported platform and include the wikilink [[long term]] in a post, the Agora will link it here and optionally integrate your writing.
Sign up as a full Agora user.
- As a full user you will be able to contribute your personal notes and resources directly to this knowledge commons. Some setup required :)

⥅ related node [[longterm]]

⥅ related node [[long short term memory lstm]]

⥅ related node [[long_short term_memory_(lstm)]]

⥅ related node [[long term availability of spare parts]]

⥅ related node [[long term computing]]

⥅ related node [[20210114144435 kautsky_was_right_about_imperialism_in_the_long_term]]

⥅ node [[longterm]] pulled by Agora

📓 garden/jakeisnt/pages/longterm.md by @jakeisnt

becoming an influencer

put the camera down pick something you want to learn about spend the next 10 years mastering your craft pick the camera back up tell people what you have learned kill it

small, sharp tools.

article Rule of modularity: write simple parts connected by clean interfaces. Rule of composition: design programs to be connected to other programs. Rule of Parsimony: write a big program only when it is clear by demonstration that nothing else will do. Build as simple as possible, but no simple. Do not allow the composition of these parts to assemble a tightly integrated system.

Working Effectively

article

Problem: staying 'in the zone' is just not healthy or effective for a programmer! However, long periods of concentration are vital for a programmer to better understand their code and succeed. This crazy dedication helps develop unhealthy habits and can prevent you from properly focusing.
Concentration periods are the most important part of programming. Losing concentration means losing all context, and losing all context means that you'll spend lots of time reorienting yourself and entering a stronger period of focus.
It's difficult to adjust, and this leads to substantially decreased productivity. To improve:

Embrace interruptions. Learn to accept interruptions and avoid giving up through them.
Maintain context outside of your head at all times. Always explicitly comment and track what you're doing, teh decisions you're making. etc. Externalizing thoughts can help you clarify them! Every so often, make sure to record these (the author does this at 30 minute intervals).
Ignore tangental issues. Focus on the singular current task and don't worry about things that could get you sidetracked! Write those down with a ticket system that's fast, lightweight and agnostic to the amount of detail put into these thoughts. The most important thing to do is to put this idea away until it can be summoned in a future context.
Always know of the one thing you will do next.
Prioritize negatively :: assume baseline that you will not do any of the tasks, then assess the negative outcomes of not doing each one. Perform the task that will have the most negative outcome first.
Recognize the benefits of breaks. Breaks have great benefits, encourage better health, and can offer a new context from which the problem can be tackled!

50 ideas that changed my life

https://www.perell.com/blog/50-ideas-that-changed-my-life inversion :: avoiding stupidity is easier and better than being brilliant doublespeak :: saying the opposite of what one means theory of constraints :: focus on the bottleneck, the weakest point of the system, always. preference falsification :: lying to conform to the most socially acceptable opinion at the time mimetic teory of desire: rather than having our own desires, we imitate the desires of others and pursue their ideas mimetic theory of conflict :: similar = fight left off on 10! on automating out of work The best work is done when you do it for yourself. you sign your brains away when you go to work for a big company, and these people will likely be B players – no matter how many great people they hire. most A players have more important things to do with their own time. without ownership, there is a high chance that you will not be at your best. non-technical business :: sometimes daily tasks do not end up driving revenue! the others are driving the revenue, you are maintaining thigns for them. their capacity to define tasks for you may not ever outpace your ability to deliver. automating yourself out of a job could be a goal, but this doesn't work:

system complexity means something can always break!
markets rapidly evolve and parts cease to work in the future!

is self-automation ethical?

automation and the 15 hour work week from keynes
though automation continues, humans find ourselves working longer and longer hours – even though we enjoy benefits from those who use automation and those who owned automated products.
Automation still has the power to reduce the amount of boring work we do.