Init

Career/Resources/Don't make me think.md

@@ -0,0 +1,90 @@
+> 
+## Don't Make Me Think
+The goal is not to make an interface that leads to the least amount of clicks, it should be the least amount of thoughts.
+
+Thinks that make people think are:
+• Not knowing the meaning of text, so use simple language.
+• Not knowing what to interact with.
+
+So things should be self-evident, or at least self-explanatory.
+
+## How We Really Use the Web
+
+Web pages are not read they are scanned. People need to find something, they dont need to read everything and are good at scanning.
+
+Also people look for a reasonably good option instead of the best one. They are in a hurry, there is little penalty for guessing wrong.
+
+Users are there to muddle through.
+## Billboard Design 101
+
+Some quick conventions
+• Make use of conventions
+- Use visual hierarchy .1'm portent things are prominent.
+	• Related things are visually related
+	• Nested things are a part of • Break up pages into areas
+• Show what is clickable.
+• Eliminate visual noise
+• Format to support scanning
+
+## Animal, Vegetable, or Mineral?
+
+Navigation becomes difficult by not knowing where to click, it number of clicks is less relevant.
+
+Omit needless words
+
+Keep text short or hidden in order to:
+- reduce noise
+- make use full content more prominent
+- make pages shorter
+
+The same holds for instructions, people only read them if muddeling through does not work.
+
+## Street Signs and Breadcrumbs
+Some users are search dominant others are link dominant.
+
+After a browsing click, the user should know it was the right click.
+
+Compared to normal navigation web browsing gives no sense of scale, direction or location. This needs to be added.
+Away to get this is, persistent navigation. Which should include, the site identification, its sections, utilities and a search.
+
+Give users to option to limit the scope after they have seen the scope is to wide.
+
+Due to search engines, people are dropped randomly in a site. Make sure that they know where they are.
+Site > Page name > Sections > Local navigation > you are here > Search
+
+## The Big Bang Theory of Web Design
+
+Things a homepage needs to do:
+- Site identity and mission, where am I?
+- Hierarchy, where to go next.
+- Search, help?
+- Teases, hint at the good stuff
+- Content promos, the top content
+- Feature promos, the top sections
+- Timely content, the reason to come regularly
+- Deals
+- Shortcuts, utility
+- Registration, utility
+
+Some abstract objectives:
+- Show people what they want to see or how to get there.
+- Expose people to new stuff.
+- Establish credit-lily and trust.
+
+Given that every has an option about what needs to be on the frontpage. Remember them the page is for the user, not for them.
+
+While doing all this, keep in mind the first questions:
+- What is this?
+- What do they have here?
+- what can I do here?
+- Why should I be here?
+
+## Usability Testing on 10 Cents a Day
+
+Testing should be done during the entire design stage.
+Don't use focus group, one is for testing peoples feelings. Usability is about a single person getting the site.
+
+See the rest should we even start testing.
+## Mobile; It's not just a City in Alabama Anymore
+
+There is not much difference between desktop and mobile, people just read even less and scroll faster.

Career/Resources/Implementing domain driven design/Aggregates.md

@@ -0,0 +1,27 @@
+Collection of objects clustered together for the purpose of data changes. Designed to keep data transactionally consistent.
+
+> Like splitting orders into orderlines. Maybe view them as very closely coupled models/ entities. Something where the main model owns the interface with the world. So the root entity
+
+A design consideration is the size of the aggregate, as storing race conditions become a problem. To find a boundary consider the need for consistency, if transactional consistency is needed it is likely within the aggregate. It could well be that most aggregate consist of a single entity, the root.
+
+> If eventual consistency is fine. Maybe store this in another aggregat and couple them using a event.
+
+Not every use case that modifies multiple aggregates warrants the combining of the aggregates into a single one. First find out if eventual consistency is acceptable. Domain experts are often more comfortable with eventual or delayed consistency. This happens in the real world all the time.
+
+>But don't forget to tell them!!!
+
+>A way to force an aggregate is to keep its relation methods private. Keeping it's interaction going through the root model.
+
+Or consider single use actions / commands. There are however reasons for changing multiple aggregates in a single transaction.
+- User Interface Convenience, think bulk editsor simply complex interfaces. This does not mean all the aggrates involved should be a single aggregate.
+- Not having the technical means to do eventual consistency. Or introducing it for a single case.
+- Global transactions Transactions spanning multiple domain
+- Database preformance. All the data is there, just use it.
+
+## Implementing Eventual Consistency
+An event is published which then wakes some listener. While this is happening in the background, the user may need to be informed by some visual indication of the system stil being in transit.
+> Frame automation like a college doing the work for you but it may take some time before they get to it.
+
+> Build in a version attribute into each Roof Entity. This way depenancies are clear and we can speak of a real version.
+
+No dependency injection into an aggregate.

Career/Resources/Laracast/Eloquent Performance Patterns.md

@@ -0,0 +1,23 @@
+### Getting one recode from a has many relation
+addSelect(['value_name' => Model::whereColumn('a','table.b')->take(1)])
+
+
+
+### Dynamic Relationships Using Subqueries
+The relation column can be added using a addSelect
+
+### Calculate Totals Using Conditional Aggregates
+case exists
+
+### Optimize Circular Relationships
+Manual set relation to the model instead of loading it again
+
+### Getting LIKE to use an Index
+Dont use wildcards on both sides
+
+### Use Unions to Run Queries Independently
+Where in
+	derived table
+		find users by x
+			union 
+		find users by y

Career/Resources/Laracast/Laravel Security Through Examples.md

@@ -0,0 +1 @@
+bla

Career/Resources/Laracast/Learn Redis Through Examples.md

@@ -0,0 +1,4 @@
+You can make most populair articles with redis, it has (sorted) lists, hashmap etc.
+
+Move stuff you want to cache in a repository, maybe with a non cached version.
+

Career/Resources/Laracast/Modular Laravel.md

@@ -0,0 +1,19 @@
+He put everything in a modules folder / namespace. Inside a module the default Laravel structure is use.
+
+Each module gets a service provider, with a loadMigrationsFrom, mergeConfigFrom and registers other providers.
+
+Each model gets a route service provider.
+Each model gets a event service provider.
+
+Tests are put in the modules and bound in the phpunit.xml. FYI starts are followed
+'/modules/\*/Test' works. Also add modules specific base test case.
+
+To bind factory, define model and newFactory method.
+
+When you need to use models from other modules, instead use Data Transfer Objects which can then be used to encapsulate behaviour.
+
+Make your dto's readonly and enforce properties to be primitives. When breaking a boundary a easy fix would be to make placeholder class a module and inject it into the other module.
+
+Then behaviour is put into actions.
+
+To uncoupling make dto's from your models and start moving all the things you need into those dtos

Career/Resources/Mac Setup.md

@@ -0,0 +1,107 @@
+## TODO's
+Tweak spotlight settings 
+
+```bash
+/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+```
+
+### Add Spacers to Dock
+```bash
+defaults write com.apple.dock persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}' && killall Dock
+```
+Small space
+```bash
+defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="small-spacer-tile";}' && killall Dock
+```
+
+<https://github.com/nicoverbruggen/phpmon>
+
+Xd
+Amphetamine
+AnkerWork
+Bitwarden
+DBngin
+Firefox
+Chrome
+Handbrake
+ImageOptim
+iTerm
+ohMyshell
+LM Studio
+Logi Options+
+Microsoft Suite
+Obsidian
+Ollama
+PHP Monitor
+PhpStorm
+Pocket Casts
+Postman
+Rectangle
+Second Cock
+Signal
+Stretchly
+Sublime Text
+SitchHosts
+TablePlus
+Vs Code
+
+### Brew
+antiword		jpegoptim		node@22
+aom			jq			npth
+apr			krb5			nspr
+apr-util		leptonica		nss
+argon2			libarchive		oniguruma
+aspell			libassuan		openexr
+autoconf		libavif			openjpeg
+awscli			libb2			openldap
+bash			libde265		openssl@1.1
+brotli			libdeflate		openssl@3
+c-ares			libevent		optipng
+ca-certificates		libffi			p11-kit
+cairo			libgcrypt		packer
+capstone		libgpg-error		pango
+certifi			libheif			pcre2
+cffi			libidn			php
+composer		libidn2			php@7.4
+coreutils		libksba			php@8.1
+cryptography		liblqr			php@8.2
+curl			libnghttp2		php@8.3
+dnsmasq			libomp			pinentry
+dog			libpng			pixman
+dumps			libpq			pkgconf
+fontconfig		libraw			pngquant
+freetds			libsodium		poppler
+freetype		libssh			pycparser
+fribidi			libssh2			python-certifi
+fswatch			libtasn1		python-packaging
+gd			libtiff			python@3.10
+gdbm			libtool			python@3.11
+gettext			libunistring		python@3.12
+gh			libusb			python@3.13
+ghostscript		libuv			python@3.9
+giflib			libvmaf			readline
+gifsicle		libx11			redis
+git			libxau			rtmpdump
+git-lfs			libxcb			shared-mime-info
+glib			libxdmcp		sqlite
+gmp			libxext			svgo
+gnupg			libxrender		terraform
+gnutls			libzip			tesseract
+gpgme			little-cms2		tesseract-lang
+graphite2		luajit			tidy-html5
+grep			lz4			tldr
+harfbuzz		lzo			tree
+highway			m4			unbound
+htop			mackup			unixodbc
+httpie			mailhog			webp
+icu4c@75		mas			wget
+icu4c@76		mpdecimal		wp-cli
+imagemagick		ncurses			wrk
+imagemagick@6		net-snmp		x265
+imath			nettle			xorgproto
+jasper			nginx			xz
+jbig2dec		node			youtube-dl
+jpeg-turbo		node@16			zstd
+jpeg-xl			node@18
+
+#Snippets 

Career/Resources/Max Children.md

@@ -0,0 +1,4 @@
+```bash
+sudo grep 'seems busy'  /var/log/php8.3-fpm.log
+```
+#Snippets 

Career/Resources/New Laravel.md

@@ -0,0 +1,13 @@
+- [ ] Change font
+- [ ] Add flare
+- [ ] Enforce morphmap
+- [ ] Add the mixins
+- [ ] Add laravel actions
+- [ ] Add eslint 
+- [ ] Add laravel deployment actions
+- [ ] barryvdh/laravel-debugbar
+- [ ] driftingly/rector-laravel
+- [ ] staudenmeir/eloquent-has-many-deep
+- [ ] Add telescope
+
+#Snippets 

Career/Resources/Nginx.md

@@ -0,0 +1,13 @@
+### Header to big
+Add 
+```bash
+    location ~ \.php$ {
+		include fastcgi_params;
+		# Bla bla
+        fastcgi_buffers 16 16k; 
+        fastcgi_buffer_size 32k;
+    }
+```
+
+#nginx
+#Snippets 

Career/Resources/Packages/Holidays.md

@@ -0,0 +1,3 @@
+<https://github.com/spatie/holidays>
+
+#Carbon #TimeKeeping

Career/Resources/Packages/Laravel Deploy Operations.md

@@ -0,0 +1,6 @@
+https://github.com/TheDragonCode/laravel-deploy-operations
+```bash
+composer require dragon-code/laravel-deploy-operations && \
+php artisan vendor:publish --tag=config --provider="DragonCode\LaravelDeployOperations\ServiceProvider"
+
+```

Career/Resources/Packages/Minimal Identity Map for Laravel Eloquent.md

@@ -0,0 +1 @@
+https://ollieread.com/articles/a-minimal-identity-map-for-laravel-eloquent

Career/Resources/Packages/Recurr.md

@@ -0,0 +1,3 @@
+<https://github.com/simshaun/recurr>
+
+#Carbon #TimeKeeping 

Career/Resources/Packages/Rewind.md

@@ -0,0 +1,3 @@
+<https://github.com/avocet-shores/laravel-rewind>
+
+#Versioning #packages

Career/Resources/Packages/Rich Test Laravel.md

@@ -0,0 +1,3 @@
+<https://github.com/tonysm/rich-text-laravel?tab=readme-ov-file>
+
+#WYSIWYG

Career/Resources/Rector.md

@@ -0,0 +1,42 @@
+```bash
+composer require driftingly/rector-laravel && ./vendor/bin/rector
+```
+
+```php. rector
+<?php  
+  
+declare(strict_types=1);  
+  
+use Rector\Config\RectorConfig;  
+use Rector\Php74\Rector\Closure\ClosureToArrowFunctionRector;  
+use Rector\Php83\Rector\ClassMethod\AddOverrideAttributeToOverriddenMethodsRector;  
+use Rector\TypeDeclaration\Rector\ClassMethod\AddVoidReturnTypeWhereNoReturnRector;  
+use RectorLaravel\Set\LaravelSetList;  
+  
+return RectorConfig::configure()  
+    ->withPaths([  
+		// bla bla
+    ])  
+    ->withPhpSets()  
+    ->withSkip([  
+        ClosureToArrowFunctionRector::class,  
+        AddOverrideAttributeToOverriddenMethodsRector::class,  
+        AddVoidReturnTypeWhereNoReturnRector::class,  
+    ])  
+    ->withPreparedSets(  
+        deadCode        : true,  
+        codeQuality     : true,  
+        typeDeclarations: true,  
+        privatization   : true,  
+    )  
+    ->withSets([  
+        LaravelSetList::LARAVEL_110,  
+        LaravelSetList::LARAVEL_CODE_QUALITY,  
+        LaravelSetList::LARAVEL_ELOQUENT_MAGIC_METHOD_TO_QUERY_BUILDER,  
+        LaravelSetList::LARAVEL_CONTAINER_STRING_TO_FULLY_QUALIFIED_NAME,  
+        LaravelSetList::LARAVEL_COLLECTION,  
+    ]);
+```
+
+#Snippets  
+#PHP

Career/Resources/Switch to new locaization package.md

@@ -0,0 +1,8 @@
+
+```bash
+composer require dartmoon/laravel-localized-routes && php artisan vendor:publish --provider="Dartmoon\LaravelLocalizedRoutes\LaravelLocalizedRoutesServiceProvider"
+```
+
+Switch out **Route::localized** for **Route::localize**
+
+Current route names are no longer prefixed with local

Career/Resources/The Mythical Man Month/Ch 1. The Tarpit.md

@@ -0,0 +1 @@
+Not much to say.

Career/Resources/The Mythical Man Month/Ch 10. The Documentary Hypothesis.md

@@ -0,0 +1,9 @@
+Critical documents for building a software product include:
+
+- Objectives: This document outlines the specific needs to be met, along with goals, constraints, and priorities.
+- Specifications: This document includes both the manual and performance specifications. It is typically one of the first documents generated and one of the last to be finalized.
+- Schedule
+- Budget: This document not only serves as a constraint but also acts as a tool to drive decision-making and the creation and management of policies.
+- Organization Chart: This document defines the hierarchical structure of the project team, highlighting the roles and responsibilities of each member.
+- Space Allocations: This document determines how physical or virtual spaces will be allocated for different project activities and resources.
+- Estimate, forecast, prices.

Career/Resources/The Mythical Man Month/Ch 11. Plan to Throw One Away.md

@@ -0,0 +1,11 @@
+In most projects, the first system build is barely useable. The question is not weither to build this pilot system, you will anyway. The question is weither or not to expose the customer to this system. Doing so wil result in distractions to the builder while they redesign and a bad reputation. So plan to throw pilots away, you will anyhow.
+
+Change will happen and thus should be embrassed. To do this the ability to change should be build in the system. And in the team.
+
+The last reason to throw away is that as a system is used, fixed, maintanced and expanded. Entropy will increase ountill the system devolves into unmaintanable obsulasence
+
+In most projects, the initial system build is often not fully functional. The decision to build this pilot system is not a question, as it is usually necessary. However, the important consideration is whether or not to expose the customer to this system. Doing so can result in distractions for the builders as they work on redesigning. Also this will lead to a negative reputation. So plan to throw pilots away, you will anyhow.
+
+Change is an inherent part of any project, and it should be embraced. It is crucial to incorporate the ability to adapt and accommodate changes both in the system itself and within the team.
+
+Another compelling reason to dispose of systems is that over time, as the system is used, fixed, maintained, and expanded, entropy increases. This gradual increase in disorder and complexity can render the system obsolete and extremely challenging to maintain.

Career/Resources/The Mythical Man Month/Ch 12. Sharp Tools.md

@@ -0,0 +1 @@
+Is about the need for good tools and examples from decade ago.

Career/Resources/The Mythical Man Month/Ch 14. Hatching a Catastrophe.md

@@ -0,0 +1 @@
+Schedule slippage is not typically caused by large events, as those events often prompt immediate action. It is the accumulation of unnoticed small issues that leads to delays. Hence, the implementation of milestones becomes essential.

Career/Resources/The Mythical Man Month/Ch 15. The Other Face.md

@@ -0,0 +1,16 @@
+User-facing documentation should include the following;
+
+1. How to use a program:
+    - Purpose: Clearly state the main function of the program.
+    - Environment: Specify the necessary hardware and configurations.
+    - Domain and Range: Define the input and output parameters.
+    - Implemented Functions and Algorithms: Explain the precise workings of the program.
+    - Options: Outline available customization or settings.
+    - Running Time: Provide information on the program's performance.
+    - Accuracy and Checking: Describe the program's reliability and verification methods.
+2. How to validate a program: Present a brief demonstration to prove the system's functionality, including:
+    - The main use case.
+    - An edge case where the system barely functions.
+    - An alternative edge case to show the system's capabilities.
+3. How to modify a program:
+    - Provide instructions on making changes or updates to the program.

Career/Resources/The Mythical Man Month/Ch 2. The Mythical Man Month.md

@@ -0,0 +1,13 @@
+The reasons why estimations often go awry are multifaceted. Firstly, estimating techniques are often poor and can fail to accurately predict the time and resources required for a project. Furthermore, these techniques can confuse effort with progress and assume that men and months are interchangeable, which is not always the case.
+
+Another reason why estimations can go wrong is due to uncertainty, which can lead to a lack of stubbornness in adhering to schedules. Additionally, schedules are often not monitored, and schedule slippage is often countered with increased manpower. This can result in a further decrease in productivity due to communication issues and the time it takes for new team members to become familiar with the project.
+
+Programmers are often optimistic, perhaps due to their youth, and assume that there will be little implementation difficulty in their work.
+
+Due to the absence of productivity and bug incidence figures, estimates can be inherently poor. However, in such cases, programmers should stick to their estimations rather than engaging in wishful thinking.
+
+The man-month measure is only useful when no communication is needed between workers. However, communication is necessary for effective project management and can become increasingly difficult as the number of workers increases. The effort of communication must be factored into the estimation process, as training grows linearly with the number of workers and intercommunication grows exponentially.
+
+System tests are the most challenging part of a project and are often done last, resulting in the greatest cost. A recommended schedule for a project would be to allocate one-third of the time to planning, one-sixth to coding, one-quarter to component testing, and one-quarter to system testing.
+
+When faced with schedule slippage, it is important to ask whether the original estimate was too low locally or universally. The cost of adding more men is N times the training, and communication can become exponentially harder. Finally, the number of men required is dependent on the number of individual subtasks.

Career/Resources/The Mythical Man Month/Ch 3. The Surgical Team.md

@@ -0,0 +1,12 @@
+While small teams of 10x developers are preferred, even these teams cannot be as productive as very large teams. However, by dividing large tasks into smaller segments and utilizing teams of specialized people, productivity can be increased.
+
+Mills proposes that large tasks should be divided into smaller segments, each dealt with by a team of specialists, similar to a surgical team. The team should consist of the following roles:
+
+- **The Surgeon (Chief Programmer):** Defines the functional and performance specifications, codes, tests, and writes documentation.
+- **The Copilot:** Works closely with the surgeon and performs similar tasks but with less experimentation.
+- **The Administrator:** Has the final say on personnel, teams, and expenses but should not spend any time dealing with them. This person can serve multiple teams.
+- **The Editor:** Responsible for documentation, takes drafts from the surgeon, and reworks them into a coherent whole.
+- **Secretaries:** Assist the administrator and editor with correspondence and non-product files.
+- **The Program Clerk:** Maintains technical records in a programming product library, ensuring all information is available to the team, and relieves programmers of clerical chores.
+- **The Toolsmith:** Ensures the surgeon has the necessary tools and assists with testing by supplying data and planning test sequences.
+- **The Language Lawyer:** A specialist in language or framework who can serve multiple surgeons.

Career/Resources/The Mythical Man Month/Ch 4. Aristocracy, Democracy, and System Design.md

@@ -0,0 +1,5 @@
+### Conceptual Integrity
+
+According to Brooks, the most crucial factor to consider in system design is to implement a single set of design ideas and to omit anomalous features and improvements, regardless of their quality. To achieve this, a single or a few like-minded individuals should be responsible for the design, which limits the number of people who can work on the system. However, Brooks offers two solutions to this limitation. The first is to separate the architecture from implementation, and the second is to form teams as described in previous chapters.
+
+The system architect's primary responsibility should be to prioritize the user's needs above all other considerations.

Career/Resources/The Mythical Man Month/Ch 5. The Second-System Effect.md

@@ -0,0 +1,3 @@
+An architect's initial work tends to be spare and clean due to their lack of knowledge and experience, which causes them to exercise restraint. However, as they gain more experience and knowledge, they encounter numerous frills and embellishments that they may want to incorporate into their designs in the future. This can lead to the creation of overly complex and risky systems, making the second iteration of a design the most dangerous one.
+
+To avoid this danger, it's important to keep asking yourself whether any additional compute, time, or effort is truly necessary for the system to function effectively. By maintaining a focus on simplicity and avoiding the temptation to add unnecessary features, an architect can create a robust and efficient system that meets the needs of its users without introducing unnecessary complexity or risk.

Career/Resources/The Mythical Man Month/Ch 6. Passing The Word.md

@@ -0,0 +1,5 @@
+The manual, or written specifications, is an essential tool for the implementation of a system. Any changes made during the implementation should be dated and quantified to ensure that the implementer knows what has changed and which decisions supersede others.
+
+The manual should describe how the user sees and interacts with the system but not the underlying technical details, which is the responsibility of the implementer. However, the architect should be able to provide guidance on the implementation.
+
+When writing the manual, it's important to choose a formal or informal tone and clearly mark any secondary tone. During the implementation, the architecht should keep a log of even minor complaints and questions and resolve them in bulk during a meeting.

Career/Resources/The Mythical Man Month/Ch 7. Why Did the Tower of Babel Fail.md

@@ -0,0 +1,20 @@
+Communication between programs should occur through as many channels as possible.
+
+- Informal communication: Clear definitions of intergroup dependencies can encourage informal communication among teams.
+- Meetings: Regular meetings can be held, where one team or programmer presents technical details. This can help to identify and resolve misunderstandings.
+- Project Workbook: A formal project workbook can be created to document the technical details of the project and serve as a reference for all teams involved.
+
+## Project Workbook
+
+The project workbook should define a structured framework for organizing all documents related to the project. It should include, at a minimum, the following sections:
+
+- Objectives
+- External Specifications
+- Interface Specifications
+- Technical Standards
+- Internal Specifications
+- Administrative Memoranda
+
+One of the challenges of using a project workbook is that it requires everyone involved to read it. Therefore, it should be easily accessible, and users should be able to quickly see any changes made to the document, without having to re-read the entire document.
+
+However, not everyone may be comfortable with this approach, as some may prefer to shield individuals from unnecessary complexity. This approach requires that all interfaces are complete and that the necessary documentation is in place.

Career/Resources/The Mythical Man Month/Ch 8. Calling the shot.md

@@ -0,0 +1 @@
+Not much to say.

Career/Resources/The Mythical Man Month/Ch 9. Ten Pounds in a Five-Pound Sack.md

@@ -0,0 +1 @@
+Deals with space constraints, which is not really a problem any more.

Career/Resources/The Mythical Man Month/The Mythical Man Month.md

@@ -0,0 +1,13 @@
+[[Ch.1 The Tarpit]]
+[[Ch.2 The Mythical Man Month]]
+The chapter discusses the reasons why estimations often go wrong, including poor estimating techniques, confusion between effort and progress, and optimistic assumptions. Uncertainty, lack of schedule monitoring, and adding manpower to counter schedule slippage can further decrease productivity due to communication issues. The man-month measure is only useful when no communication is needed between workers, and the effort of communication must be factored into the estimation process. System tests are the most challenging part of a project and should be allocated one-quarter of the time. When faced with schedule slippage, it is important to determine if the original estimate was too low locally or universally, as adding more men can be costly and communication can become exponentially harder. The number of men required is dependent on the number of individual subtasks.
+> In order to improve the accuracy of our estimations, it is crucial to obtain more reliable and precise productivity figures. Specifically, we should focus on gathering data about the amount of time spent on improvement, adjustment, and debugging as compared to the time spent on building.
+> 
+> So for HGBI we should start labeling ticket correctly.
+
+### [[Ch.3 The Surgical Team]]
+The text discusses Mills' proposal for increasing productivity by dividing large tasks into smaller segments and utilising teams of specialised individuals, similar to a surgical team. The proposed team consists of a surgeon or chief programmer, copilot, administrator, editor, secretaries, program clerk, toolsmith, and language lawyer. The text also notes that while small teams of 10x developers are preferred, even they cannot be as productive as very large teams.
+
+>If we where to do this we would need to split of the secretary and the administrator. Also we need to start having an editor. 
+
+>If we where to do this, we need better communication. Our specialists are being bogged down as they also serve as surgeons or copilots.

Career/Resources/The Psychology of Design.md

@@ -0,0 +1,25 @@
+<https://growth.design/psychology/>
+## Hick's Law
+
+Hick's Law predicts that the time and the effort it takes to make a decision, increases with the number of options. The more choices, the more time users take to make their decisions.
+
+> Multiple simple decisions are easier then one large decision. Hence, wizards.
+> Remove navigation options from single use pages, to don't give people the choice to move away. (Maybe show it as a popup)
+
+## Confirmation Bias
+
+People tend to search for, interpret, prefer, and recall information in a way that reinforces their personal beliefs or hypotheses.
+
+## Priming
+
+Subtle visual or verbal suggestions help users recall specific information, influencing how they respond. Priming works by activating an association or representation in users short-term memory just before another stimulus or task is introduced.
+
+## Cognitive Load
+
+Cognitive load is the total amount of mental effort that is required to complete a task. You can think of it as the processing power needed by the user to interact with a product. If the information that needs to be processed exceeds the user’s ability to handle it, the cognitive load is too high.
+
+> Similarly to Hick's law, reduce as much as possible. 
+## Random Stuff:
+### Sniper Links
+For an email confirmation, generate a link dat send the user to their inbox pre-filtered so they can't start reading emails.
+`in:anywhere`: it finds the email **even if it's marked as spam**.