This commit is contained in:
2025-10-25 20:11:21 +02:00
commit fd37421245
700 changed files with 211892 additions and 0 deletions

View File

@@ -0,0 +1,7 @@
## Books
[[Don't make me think]]
> When people arrive at a site, they need to know where they are and what to do next, Like entering a large store.
>
> This is made hard by the fact people don't read. To deal with this, elements need to be in the expected places, labels need to be short and clear (not clever).
>
> Some people click, others search. Make sure there is a search bar.

View File

@@ -0,0 +1,6 @@
- Tell me something about one of your projects.
- What when well?
- What went well that you did not expect to go well?
- What went wrong?
- -_OWhat went wrong even though you did not expect it to give you any trouble
What question do you want me to ask

View File

@@ -0,0 +1,12 @@
Episode one
Before every agenda point mark it if it's about input, decision or awareness. Also make clear the stakeholders and ownership.
Creating structure where others can hook into so they can pace themself. It's not only about being charismatic, it's about creating a process.
**[Agenda Point: Awareness] Stakeholders & Ownership**
Creating structure where others can engage is crucial. This isn't just about possessing charisma; it's about establishing a process that facilitates involvement.
**[Agenda Point: Input] Involvement of Team Members**
Ensure that every team member has the opportunity to provide input. This fosters a collaborative environment and enhances decision-making.
**[Agenda Point: Decision] Implementation of Decisions**
Decisions should be made with clear understanding of their impact on all stakeholders. This approach ensures that decisions are made thoughtfully and inclusively.

View File

@@ -0,0 +1,3 @@
Recomandations on managing people
<https://news.ycombinator.com/item?id=39336840>

View File

@@ -0,0 +1,44 @@
Hi, I am the lead developer at Strixi. I want you to help me build a brag document. A list of all the accomplishments that week, so these can discussed at a later date. For more info see these links:
<https://www.thefountaininstitute.com/blog/brag-documents>
<https://jvns.ca/blog/brag-documents/>
Hi, I am the lead developer at Strixi. I want you to help me build a brag document. A list of all the accomplishments that week, so these can discussed at a later date.
Now I want you to help build this document by start asking questions about what I did last week and why. As I answer, start building this document. No need to ask about specicic ticked numbers, just ask about projects.
## Strixi Weekly Brag: June 2027, 2025
### 1. Features & Deliverables Shipped
- **Invoicing Module Overhaul**
- **QLS Data Export**
• Built a CSV/JSON export so invoicing totals can be reconciled against the customers system.
- **Checklist for Air Waybills**
• Created a step-by-step checklist UI for warehouse staff to verify receipt of AWBs before invoicing.
- **Initial Data Exchange Setup**
- Configured a data pipeline between QLS handling and a third-party customs-declaration service to automate customs data flow.
### 2. Technical Improvements & Bug Fixes
- **AI-Assisted JS→TS Migration**
• Leveraged OpenAI Codex to translate JavaScript modules into TypeScript.
• Identified and patched a styling bug within an hour—demonstrated rapid feedback cycles and improved code robustness.
### 3. Collaboration & Leadership
- **Solo Development & Stakeholder Communication**
• Operated as the sole developer on the invoicing initiative—self-directed requirement gathering, design, and delivery.
• Led all communications with the third-party customs-declaration partner: organized kickoff discussions, negotiated API specs, and coordinated integration timelines.
### 4. Metrics & Impact
- Features deployed June 27, 2025; usage data pending. (Reminder set for July 4, 2025 to follow up.)
### 5. Professional Development
- **OpenAI Codex Experimentation**
• Assessed productivity gains from AI-driven code modernization; uncovered a bug and improved overall TypeScript coverage.

View File

@@ -0,0 +1,137 @@
<https://www.reddit.com/r/ExperiencedDevs/s/ThNlcBi373>
I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.
- The best way I've advanced my career is by changing companies.
- Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.
- There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.
- I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.
- I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.
- If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
- pour another glass
- Qualities of a good manager share a lot of qualities of a good engineer.
- When I first started, I was enamored with technology and programming and computer science. I'm over it.
- Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
- The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
- Related to above, writing good proposals for changes is a great skill.
- Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.
- The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.
- If I ever find myself thinking I'm the smartest person in the room, it's time to leave.
- I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
- We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.
- _sip_
- Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.
- Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.
- The greatest programming language ever is lisp. I should learn lisp.
- For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.
- Tests are important but TDD is a damn cult.
- Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.
- Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.
- Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then _maybe_ they are worth something within this decade.
- Work from home is the tits. But lack of whiteboarding sucks.
- I've never worked at FAANG so I don't know what I'm missing. But I've hired (and not hired) engineers from FAANGs and they don't know what they're doing either.
- My self worth is not a function of or correlated with my total compensation. Capitalism is a poor way to determine self-worth.
- Managers have less power than you think. Way less power. If you ever thing, why doesn't Manager XYZ fire somebody, it's because they can't.
- Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
- Speaking of titles: early in your career, title changes up are nice. Junior to Mid. Mid to Senior. Senior to Lead. Later in your career, title changes _down_ are nice. That way, you can get the same compensation but then get an increase when you're promoted. In other words, early in your career (<10 years), title changes UP are good because it lets you grow your skills and responsibilities. Later, title changes down are nice because it lets you grow your salary.
- Max out our 401ks.
- Be kind to everyone. Not because it'll help your career (it will), but because being kind is rewarding by itself.
- If I didn't learn something from the junior engineer or intern this past month, I wasn't paying attention.
- Oops I'm out of wine.
- Paying for classes, books, conferences is worth it. I've done a few conferences, a few 1.5k courses, many books, and a subscription. Worth it. This way, I can better pretend what I'm doing.
- Seriously, why aren't webdevs paid more? They know everything!!!
- Carpal tunnel and back problems are no joke. Spend the 1k now on good equipment.
- The smartest man I've every worked for was a Math PhD. I've learned so much from that guy. I hope he's doing well.
- Once, in high school, there was thing girl who was a great friend of mine. I mean we talked and hung out and shared a lot of personal stuff over a few years. Then there was a rumor that I liked her or that we were going out or whatever. She didn't take that too well so she started to ignore me. That didn't feel too good. I guess this would be the modern equivalent to "ghosting". I don't wish her any ill will though, and I hope she's doing great. I'm sorry I didn't handle that better.
- I had a girlfriend in 8th grade that I didn't want to break up with even though I didn't like her anymore so I just started to ignore her. That was so fucked up. I'm sorry, Lena.
- You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That's pretty cool.
- There's not enough women in technology. What a fucked up industry. That needs to change. I've been trying to be more encouraging and helpful to the women engineers in our org, but I don't know what else to do.
- Same with black engineers. What the hell?
- I've never really started hating a language or technology until I started becoming intimately familiar with it. Also, I think a piece of tech is good if I hate it but I simultaneously would recommend it to a client. Fuck Jenkins but man I don't think I would be commuting software malpractice by recommending it to a new client.
- That being said, git is awful and I have choice but to use it. Also, GUI git tools can go to hell, give me the command line any day. There's like 7 command lines to memorize, everything else can be googled.
- Since I work in data, I'm going to give a data-specific lessons learned. Fuck pandas.
- My job is easier because I have semi-technical analysts on my team. Semi-technical because they know programming but not software engineering. This is a blessing because if something doesn't make sense to them, it means that it was probably badly designed. I love the analysts on the team; they've helped me grow so much more than the most brilliant engineers.
- Dark mode is great until you're forced to use light mode (webpage or an unsupported app). That's why I use light mode.
- I know enough about security to know that I don't know shit about security.
- Crap I'm out of wine.
- Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.
- If people are trying to assign blame to a bug or outage, it's time to move on.
- A lot of progressive companies, especially startups, talk about bringing your "authentic self". Well what if your authentic self is all about watching porn? Yeah, it's healthy to keep a barrier between your work and personal life.
- I love drinking with my co-workers during happy hour. I'd rather spend time with kids, family, or friends.
- The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would've walked over fire for her.
- On the same token, the best leaders I've been privileged to work under did their best to both advocate for my opinions and also explain to me other opinions 'that conflict with mine. I'm working hard to be like them.
- Fuck side projects. If you love doing them, great! Even if I had the time to do side-projects, I'm too damn busy writing drunken posts on reddit
- Algorithms and data strictures are important--to a point. I don't see pharmacist interviews test trivia about organic chemistry. There's something fucked with our industry's interview process.
- Damn, those devops guys and gals are f'ing smart. At least those mofos get paid though.
- It's not important to do what I like. It's more important to do what I don't hate.
- The closer I am to the product, the closer I am to driving revnue, the more I feel valued regardless of how technical my work is. This has been true for even the most progressive companies.
- Linux is important even when I was working in all Windows. Why? Because I eventually worked in Linux. So happy for those weekend where I screwed around installing Arch.
- I've learned to be wary for ambiguous buzz words like big data. WTF is "big" data? I've dealt with 10k rows streaming every 10 minutes in Spark and Kafka and dealt with 1B rows batched up hourly in Python and MySQL. Those labels can go fuck themselves.
- Not all great jobs are in Silicon Valley. But a lot are.
Finally, if you really want to hurt me, don't downvote I don't care about that. Just ignore this post. Nothing makes me sadder than when I wrote a long post and then nobody responds. So if you hate this post, just ignore.

View File

@@ -0,0 +1,200 @@
[[ReadItLater]] [[Article]]
# [Get your work recognized: write a brag document](https://jvns.ca/blog/brag-documents/)
Theres this idea that, if you do great work at your job, people will (or should!) automatically recognize that work and reward you for it with promotions / increased pay. In practice, its often more complicated than that some kinds of important work are more visible/memorable than others. Its frustrating to have done something really important and later realize that you didnt get rewarded for it just because the people making the decision didnt understand or remember what you did. So I want to talk about a tactic that I and lots of people I work with have used!
This blog post isnt just about being promoted or getting raises though. The ideas here have actually been more useful to me to help me reflect on themes in my work, whats important to me, what Im learning, and what Id like to be doing differently. But theyve definitely helped with promotions!
You can also [skip to the brag document template at the end](https://jvns.ca/blog/brag-documents/#template).
### you dont remember everything you did
One thing Im always struck by when it comes to performance review time is a feeling of “wait, what *did* I do in the last 6 months?“. This is a kind of demoralizing feeling and its usually not based in reality, more in “I forgot what cool stuff I actually did”.
I invariably end up having to spend a bunch of time looking through my pull requests, tickets, launch emails, design documents, and more. I always end up finding small (and sometimes not-so-small) things that I completely forgot I did, like:
- mentored an intern 5 months ago
- did a small-but-important security project
- spent a few weeks helping get an important migration over the line
- helped X put together this design doc
- etcetera!
### your manager doesnt remember everything you did
And if you dont remember everything important you did, your manager (no matter how great they are!) probably doesnt either. And they need to explain to other people why you should be promoted or given an evaluation like “exceeds expectations” (“Xs work is so awesome!!!!” doesnt fly).
So if your manager is going to effectively advocate for you, they need help.
### heres the tactic: write a document listing your accomplishments
The tactic is pretty simple! Instead of trying to remember everything you did with your brain, maintain a “brag document” that lists everything so you can refer to it when you get to performance review season! This is a pretty common tactic when I started doing this I mentioned it to more experienced people and they were like “oh yeah, Ive been doing that for a long time, it really helps”.
Where I work we call this a “brag document” but Ive heard other names for the same concept like “hype document” or “list of stuff I did” :).
Theres a basic template for a brag document at the end of this post.
When I first wrote a brag document I was kind of nervous about sharing it with my manager. It felt weird to be like “hey, uh, look at all the awesome stuff I did this year, I wrote a long document listing everything”. But my manager was really thankful for it I think his perspective was “this makes my job way easier, now I can look at the document when writing your perf review instead of trying to remember what happened”.
Giving them a document that explains your accomplishments will really help your manager advocate for you in discussions about your performance and come to any meetings they need to have prepared.
Brag documents also **really** help with manager transitions if you get a new manager 3 months before an important performance review that you want to do well on, giving them a brag document outlining your most important work & its impact will help them understand what youve been doing even though they may not have been aware of any of your work before.
Similarly, if your company does peer feedback as part of the promotion/perf process share your brag document with your peer reviewers!! Every time someone shares their doc with me I find it SO HELPFUL with writing their review for much the same reasons its helpful to share it with your manager it reminds me of all the amazing things they did, and when they list their goals in their brag document it also helps me see what areas they might be most interested in feedback on.
On some teams at work its a team norm to share a brag document with peer reviewers to make it easier for them.
### explain the big picture
In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?
In my brag document, I like to do this by making a section for areas that Ive been focused on (like “security”) and listing all the work Ive done in that area there. This is especially good if youre working on something fuzzy like “building a stronger culture of code review” where all the individual actions you do towards that might be relatively small and there isnt a big shiny ship.
### use your brag document to notice patterns
In the past Ive found the brag document useful not just to hype my accomplishments, but also to reflect on the work Ive done. Some questions its helped me with:
- What work do I feel most proud of?
- Are there themes in these projects I should be thinking about? Whats the big picture of what Im working on? (am I working a lot on security? localization?).
- What do I wish I was doing more / less of?
- Which of my projects had the effect I wanted, and which didnt? Why might that have been?
- What could have gone better with project X? What might I want to do differently next time?
### you can write it all at once or update it every 2 weeks
Many people have told me that it works best for them if they take a few minutes to update their brag document every 2 weeks ago. For me it actually works better to do a single marathon session every 6 months or every year where I look through everything I did and reflect on it all at once. Try out different approaches and see what works for you!
### dont forget to include the fuzzy work
A lot of us work on fuzzy projects that can feel hard to quantify, like:
- improving code quality on the team / making code reviews a little more in depth
- making on call easier
- building a more fair interview process / performance review system
- refactoring / driving down technical debt
A lot of people will leave this kind of work out because they dont know how to explain why its important. But I think this kind of work is especially important to put into your brag document because its the most likely to fall under the radar! One way to approach this is to, for each goal:
1. explain your goal for the work (why do you think its important to refactor X piece of code?)
2. list some things youve done towards that goal
3. list any effects youve seen of the work, even if theyre a little indirect
If you tell your coworkers this kind of work is important to you and tell them what youve been doing, maybe they can also give you ideas about how to do it more effectively or make the effects of that work more obvious!
### encourage each other to celebrate accomplishments
One nice side effect of having a shared idea that its normal/good to maintain a brag document at work is that I sometimes see people encouraging each other to record & celebrate their accomplishments (“hey, you should put that in your brag doc, that was really good!”). It can be hard to see the value of your work sometimes, especially when youre working on something hard, and an outside perspective from a friend or colleague can really help you see why what youre doing is important.
Brag documents are good when you use them on your own to advocate for yourself, but I think theyre better as a collaborative effort to recognize where people are excelling.
Next, I want to talk about a couple of structures that weve used to help people recognize their accomplishments.
### the brag workshop: help people list their accomplishments
The way this “brag document” practice started in the first place is that my coworker [Karla](https://karla.io/) and I wanted to help other women in engineering advocate for themselves more in the performance review process. The idea is that some people undersell their accomplishments more than they should, so we wanted to encourage those people to “brag” a little bit and write down what they did that was important.
We did this by running a “brag workshop” just before performance review season. The format of the workshop is like this:
**Part 1: write the document: 1-2 hours**. Everybody sits down with their laptop, starts looking through their pull requests, tickets they resolved, design docs, etc, and puts together a list of important things they did in the last 6 months.
**Part 2: pair up and make the impact of your work clearer: 1 hour**. The goal of this part is to pair up, review each others documents, and identify places where people havent bragged “enough” maybe they worked on an extremely critical project to the company but didnt highlight how important it was, maybe they improved test performance but didnt say that they made the tests 3 times faster and that it improved everyones developer experience. Its easy to accidentally write “I shipped $feature” and miss the follow up (“… which caused $thing to happen”). Another person reading through your document can help you catch the places where you need to clarify the impact.
### biweekly brag document writing session
Another approach to helping people remember their accomplishments: my friend Dave gets some friends together every couple of weeks or so for everyone to update their brag documents. Its a nice way for people to talk about work that theyre happy about & celebrate it a little bit, and updating your brag document as you go can be easier than trying to remember everything you did all at once at the end of the year.
These dont have to be people in the same company or even in the same city that group meets over video chat and has people from many different companies doing this together from Portland, Toronto, New York, and Montreal.
In general, especially if youre someone who really cares about your work, I think its really positive to share your goals & accomplishments (and the things that havent gone so well too!) with your friends and coworkers. It makes it feel less like youre working alone and more like everyone is supporting each other in helping them accomplish what they want.
### thanks
Thanks to Karla Burnett who I worked with on spreading this idea at work, to Dave Vasilevsky for running brag doc writing sessions, to Will Larson who encouraged me to start one [of these](https://lethain.com/career-narratives/) in the first place, to my manager Jay Shirley for always being encouraging & showing me that this is a useful way to work with a manager, and to Allie, Dan, Laura, Julian, Kamal, Stanley, and Vaibhav for reading a draft of this.
Id also recommend the blog post [Hype Yourself! Youre Worth It!](http://blog.aashni.me/2019/01/hype-yourself-youre-worth-it/) by Aashni Shah which talks about a similar approach.
## Appendix: brag document template
Heres a template for a brag document! Usually I make one brag document per year. (“Julias 2017 brag document”). I think its okay to make it quite long / comprehensive 5-10 pages or more for a year of work doesnt seem like too much to me, especially if youre including some graphs/charts / screenshots to show the effects of what you did.
One thing I want to emphasize, for people who dont like to brag, is **you dont have to try to make your work sound better than it is**. Just make it sound **exactly as good as it is**! For example “was the primary contributor to X new feature thats now used by 60% of our customers and has gotten Y positive feedback”.
### Goals for this year:
- List your major goals here! Sharing your goals with your manager & coworkers is really nice because it helps them see how they can support you in accomplishing those goals!
### Goals for next year
- If its getting towards the end of the year, maybe start writing down what you think your goals for next year might be.
### Projects
For each one, go through:
- What your contributions were (did you come up with the design? Which components did you build? Was there some useful insight like “wait, we can cut scope and do what we want by doing way less work” that you came up with?)
- The impact of the project who was it for? Are there numbers you can attach to it? (saved X dollars? shipped new feature that has helped sell Y big deals? Improved performance by X%? Used by X internal users every day?). Did it support some important non-numeric company goal (required to pass an audit? helped retain an important user?)
Remember: dont forget to explain what the results of you work actually were! Its often important to go back a few months later and fill in what actually happened after you launched the project.
### Collaboration & mentorship
Examples of things in this category:
- Helping others in an area youre an expert in (like “other engineers regularly ask me for one-off help solving weird bugs in their CSS” or “quoting from the C standard at just the right moment”)
- Mentoring interns / helping new team members get started
- Writing really clear emails/meeting notes
- Foundational code that other people built on top of
- Improving monitoring / dashboards / on call
- Any code review that you spent a particularly long time on / that you think was especially important
- Important questions you answered (“helped Risha from OTHER\_TEAM with a lot of questions related to Y”)
- Mentoring someone on a project (“gave Ben advice from time to time on leading his first big project”)
- Giving an internal talk or workshop
### Design & documentation
List design docs & documentation that you worked on
- Design docs: I usually just say “wrote design for X” or “reviewed design for X”
- Documentation: maybe briefly explain the goal behind this documentation (for example “we were getting a lot of questions about X, so I documented it and now we can answer the questions more quickly”)
### Company building
This is a category we have at work it basically means “things you did to help the company overall, not just your project / team”. Some things that go in here:
- Going above & beyond with interviewing or recruiting (doing campus recruiting, etc)
- Improving important processes, like the interview process or writing better onboarding materials
### What you learned
My friend Julian suggested this section and I think its a great idea try listing important things you learned or skills youve acquired recently! Some examples of skills you might be learning or improving:
- how to do performance analysis & make code run faster
- internals of an important piece of software (like the JVM or Postgres or Linux)
- how to use a library (like React)
- how to use an important tool (like the command line or Firefox dev tools)
- about a specific area of programming (like localization or timezones)
- an area like product management / UX design
- how to write a clear design doc
- a new programming language
Its really easy to lose track of what skills youre learning, and usually when I reflect on this I realize I learned a lot more than I thought and also notice things that Im *not* learning that I wish I was.
### Outside of work
Its also often useful to track accomplishments outside of work, like:
- blog posts
- talks/panels
- open source work
- Industry recognition
I think this can be a nice way to highlight how youre thinking about your career outside of strictly what youre doing at work.
This can also include other non-career-related things youre proud of, if that feels good to you! Some people like to keep a combined personal + work brag document.
### General prompts
If youre feeling stuck for things to mention, try:
- If you were trying to convince a friend to come join your company/team, what would you tell them about your work?
- Did anybody tell you that you did something well recently?

View File

@@ -0,0 +1,16 @@
<https://www.reddit.com/r/webdev/s/sNN2DpeOzC>
![](https://i.redd.it/how-can-you-make-surfaces-on-a-website-look-so-tangible-is-v0-bjazaf6p142c1.png?s=0b4fb36d454bcde0f595a8f4b1db0a95c1f30878)
' Yes, it can be done. Here are my tips with turning CSS shadows into something that looks more tangible.
1. It takes about 3 drop-shadow attributes to make one good-looking, realistic shadow. One very close and very opaque, with very little blur, to represent the ambient occlusion within the shadow, a second one to represent the base shadow (more transparent, more blur, farther from the item), and a third shadow with very high blur, very far distance, and very low opacity to represent the ambient occlusion outside of the shadow.
2. Shadows should be colored according to what light would do in the scenario. So, for example, a shadow should take on the color of the surface it is on, and the color of the surface it would be reflecting light from.
3. Inset shadows are necessary to convey depth on the surface. You must use light colors, again factoring point #2 in mind, and some minimal darker colors as well, and offset them to give depth. Typically you need at least two inset shadows to achieve a good depth: one short-range opaque shadow to replicate the tangible edge of the surface, and one longer-range transparent shadow to represent the general fall-off and light reflection on the broader surface.
4. Very soft gradients can help convey depth, but should not be overtly noticeable. For example, a foreground can be slightly lighter at the top, and slightly darker on the bottom, and if done subtly enough, the user won't even notice it is happening, but it will convey better, more tangible depth to the item. Notice how the backgrounds on both image do this to convey a light source.
Of course all shadows (inset and out) should be angled appropriately to a common light source, and the general distance should be determined by how "thick" you want the foreground to look. Generally, thicker items are harder to convincingly convey than thinner ones.
This takes a lot of work, and I recommend doing all designing in a vector graphics tool like Affinity Designer or Adobe Illustrator before moving into CSS. Excessive shadows can have a negative impact on performance on some older devices, although I rarely see this occur.
Here is a rough and quick codepin demonstrating these tactics: <https://codepen.io/atalkingfish/pen/YzBLgQB>
PLEASE NOTE: Just because you can do this doesn't mean it will look good, fit the application, be trendy, etc. Currently, websites with a lot of depth don't usually look very trendy and current.

View File

@@ -0,0 +1,23 @@
---
created: 2023-10-24 18:47
updated: 2025-06-28 14:54
---
- Companies don't really care about a salary increase
- Never tell them a number focus on seeing if your are a match
- Don't start negotiating until there is a yes if situation
- Use their own words those are convincing to them
- Confirm any promises in an email asking if you understood correctly
- Talk about their problems, that is what they care about
- If you need to stall pretend you need to talk it over with the family
- If they tell you something is out of there control, sympathise and switch to something they can control
[[Salary Negotiation - Make More Money, Be More Valued.pdf]]
#salary
When you are providing revised text,
- ask if the user wants to make any changes to the tone
- ask if the user use specific words.
- ask if the user wants to see multiple versions of the revised text.
- ask if the user wants to see the corrections
- ask if the user suggestions to improve the text.

11
Career/Articles/Salary.md Normal file
View File

@@ -0,0 +1,11 @@
---
created: 2025-07-03 12:09
updated: 2025-07-03 12:27
---
Ziggo Abbo 55,00
Odido Abbo 55.50
Salaery 4737.53
2025-07-03
About an hour overhead, 15min travel, 45 min forced lunch
~7600 all incl ~44 euro an hour

12
Career/Brag Document.md Normal file
View File

@@ -0,0 +1,12 @@
## Goals for This Year:
- Build a proper event based architecture system
## Goals for next Year
## Projects
- What your contributions were (did you come up with the design? Which components did you build? Was there some useful insight like “wait, we can cut scope and do what we want by doing way less work” that you came up with?)
- The impact of the project who was it for? Are there numbers you can attach to it? (saved X dollars? shipped new feature that has helped sell Y big deals? Improved performance by X%? Used by X internal users every day?). Did it support some important non-numeric company goal (required to pass an audit? helped retain an important user?)
### QLS Handling
- Roll out of new bug tracker, allowing users to provide bug reports, lowering the load on first line support
## 2025 W5
Send to customers work floor to comunicate directly with users and extract requiredments and nice to haves.

View File

@@ -0,0 +1,65 @@
---
created: 2025-10-10 16:13
updated: 2025-10-10 16:43
---
# Brag Document
A record of professional accomplishments, projects, and growth.
## 2025
### October
#### Week of October 7-13, 2025
**Projects & Initiatives**
- **Transport Company Self-Planning Feature (QLS Handling)** - Implemented capability for trusted transport companies to independently plan shipments and assign trips to themselves, removing dependency on QLS planners. Feature now deployed and actively used by first transport company.
- **DECO Customs Declaration Integration (QLS Handling)** - Deep dive into Dutch customs authority documentation for DECO process (simplified import customs for declarations under €150 for e-commerce). Preparing to implement customs declaration capability for the QLS Handling project.
- **Codebase Maintenance** - Ongoing work using AI tools to improve housekeeping, simplify test setups, and remove inconsistencies across the codebase.
**Technical Achievements**
- **Authorization & Scoping Architecture** - Modified authorization system and global database scopes to support dual assignment methods: traditional assignment by QLS planners and new self-assignment by transport companies planning their own freight.
- **Complex Documentation Analysis** - Navigated ecosystem of ~20 interconnected Dutch customs documents with cross-references to UN standard data exchange lists and various code lists. Created DTOs and Enums with extensive comments to make information searchable within the editor when AI tools (Claude, ChatGPT) struggled with document cross-referencing.
- **Minimal UI Impact Design** - Leveraged existing planner UI components for transport company self-planning feature, requiring minimal new UI development.
**Impact & Results**
- **Reduced Operational Load** - Transport self-planning feature directly reduces workload for QLS planning team.
- **Improved Transporter Efficiency** - Transport companies can now optimize truck utilization by finding and assigning their own shipments.
- **Feature Adoption** - First transport company already using the self-planning capability in production.
- **Foundation for Customs Compliance** - DECO documentation work establishes foundation for customs declaration capability, critical for e-commerce shipments entering the Netherlands.
**Skills Developed**
- **Customs & Regulatory Domain Knowledge** - Deep understanding of Dutch customs DECO process, message exchange protocols, and the complex regulatory ecosystem of interconnected standards and code lists.
- **Document Architecture Pattern** - Developed strategy for managing complex, cross-referenced regulatory documentation by consolidating into searchable code artifacts when traditional AI tools fail at cross-referencing.
**Collaboration & Leadership**
- Independent project execution with access to consultants as needed (no blockers requiring escalation yet).
**Recognition**
- New feature requests received based on transport self-planning capability.
---
## Template for Future Entries
### [Month]
#### Week of [Date Range]
**Projects & Initiatives**
- [What you worked on]
**Technical Achievements**
- [Technical problems solved, technologies learned, improvements made]
**Impact & Results**
- [Quantifiable outcomes, metrics, business impact]
**Skills Developed**
- [New skills, tools, or knowledge gained]
**Collaboration & Leadership**
- [Mentoring, helping others, leading initiatives]
**Recognition**
- [Praise, awards, positive feedback received]

View File

@@ -0,0 +1,65 @@
# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Repository Purpose
This is a personal career documentation repository for maintaining a "brag document" - a weekly/monthly record of professional accomplishments, projects, technical achievements, and career growth.
## File Structure
- `BragDocument.md` - Main document tracking career achievements organized chronologically (year → month → week)
## Workflow: Weekly Brag Document Update
When the user requests a brag document update, follow this interview process:
### 1. Initial Questions
- What projects or initiatives have you been working on this week?
- For each project mentioned, ask follow-up questions:
- What is the purpose/context of this project?
- What technical work did you do?
- Were there any challenges or interesting problems you solved?
- What's the current status? (complete, deployed, in progress)
### 2. Impact & Results Questions
- What was the impact or benefit of this work?
- Any quantifiable outcomes? (metrics, workload reduction, efficiency gains)
- Is it being used? By whom?
### 3. Skills & Learning Questions
- Any new skills, tools, or technologies learned or deepened?
- Any domain knowledge gained?
### 4. Collaboration Questions
- Are you working solo or with a team?
- Any mentoring, helping others, or leadership activities?
### 5. Recognition Questions
- Any positive feedback, recognition, or praise received?
- Feature requests or follow-up work generated by your accomplishments?
### 6. Other Work
- Any other notable work? (bug fixes, code reviews, meetings, housekeeping, refactoring)
- Roughly how much time spent on each area of work?
### 7. Document Update
Once you have enough information, update `BragDocument.md` under the current week's section with these categories:
**Projects & Initiatives** - High-level summary of what was worked on
**Technical Achievements** - Specific technical problems solved, architecture decisions, implementation details
**Impact & Results** - Business value, operational improvements, user benefits
**Skills Developed** - New knowledge or deepened expertise
**Collaboration & Leadership** - Team work, helping others, independent execution
**Recognition** - Feedback, praise, or follow-up requests
### Writing Style
- Use bold for project/feature names
- Include context (what/why) along with accomplishments
- Focus on impact and outcomes, not just activities
- Be specific about technologies, systems, and domains
- Frame accomplishments positively and professionally
- Quantify when possible (number of documents, days spent, users affected)
### Adding New Time Periods
When starting a new week/month, add a new dated section at the top of the current month, or create a new month section if needed. Keep the template at the bottom of the document for reference.

9
Career/C.V..md Normal file
View File

@@ -0,0 +1,9 @@
---
created: 2025-07-10 14:49
updated: 2025-07-10 14:52
---
vue js pinia
AWS services, RDS, Aurora, VPN, EC2, S3
Responsible for pipeline, Force, Envoyer, Bitbucket
And ofcourse git, although I have no idea how it works I made custom bash functions for just about everything.

10
Career/Career.md Normal file
View File

@@ -0,0 +1,10 @@
---
sorting-spec: |-
Projects
Area
%
Resources
Archive
created: 2025-07-04 07:38
updated: 2025-07-04 07:40
---

View File

@@ -0,0 +1,37 @@
https://programming.dev/post/567025
- How long does it take for code to be deployed after being committed?
- How often do team members move teams?
- What kinds of (soft or hard) skills do you need most on the team right now?
- Do you have a defined onboarding process?
-
- Does the team maintain deployment infrastructure? Production infrastructure? Is there an on-call rotation?
- What does your planning cycle look like? Scrum? Kanban? Meetings?
- Whats one thing you would change or improve on the team if you could snap your fingers?
- What would you like to be doing less and more of on your team?
- How does the product representative interact with the eng team?
- Do you have a career ladder, with levels, and expectations at each of the level defined?
- What is your performance review cycle like? 1:1s?
- what is your policy for overtime or comp time when there are evening or weekend emergencies?
-
### Devops
### Currently working on
- What has your team been working on recently? What new changes have you shipped in the last six months?
- What is the biggest difficulty your team is facing right now?
- How long has the team existed and how long have you been managing it?
### Current working procedures
- What is the remote work policy? And is there is any possibility that, this policy will change?
- Is the team all remote? Are you?
- How often do tasks and priorities change last minute?
- How flexible are they on work hours?
### Expectation
- How long does it take for people to get up to speed as new hires?
- How much would a new hire be doing in six months?
- How often do people tend to need to be available outside of standard working hours?
- What does success in this position look like for me 6 months down the road?

6
Career/Laravel Queues.md Normal file
View File

@@ -0,0 +1,6 @@
---
created: 2025-07-09 08:56
updated: 2025-07-09 08:58
---
By default a job does not throw an exception when timed out.
There is a retry_after parameter in the queue config that should be greater then the timeout in the queue worker otherwise other workers will start to retry already / still running jobs.

View File

@@ -0,0 +1,9 @@
---
created: 2025-01-09 13:45
updated: 2025-07-04 07:19
---
### Export a hosted zone from Route53
```bash
aws route53 list-resource-record-sets --hosted-zone-id {{zone-id}} --output json > zone.json
```
#Snippets #AWS

7
Career/Others/Apache.md Normal file
View File

@@ -0,0 +1,7 @@
## Block Bots / User Agents
```
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Amazonbot|SemrushBot|meta-externalagent|Bytespider) [NC]
RewriteRule .* - [R=503,L]
```

View File

@@ -0,0 +1,51 @@
---
created: 2025-07-03 10:20
updated: 2025-07-04 07:26
tags:
- Laravel
- Snippets
---
```bash
php artisan make:command AuditDependenciesCommand
```
```php
<?php
namespace App\Console\Commands;
use Exception;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Process;
use Spatie\FlareClient\Enums\MessageLevels;
use Spatie\LaravelIgnition\Facades\Flare;
class AuditDependenciesCommand extends Command
{
protected $signature = 'app:audit-dependencies';
public function handle(): void
{
$composer = Process::run('composer audit');
if (!blank($composer->output())) {
$this->warn('Composer audit found vulnerabilities');
Flare::glow('Composer audit found vulnerabilities', MessageLevels::WARNING, ['output' => $composer->output()]);
Flare::report(new Exception('Composer audit found vulnerabilities'));
}
$npm = Process::run('npm audit');
if (trim($npm->output()) !== "found 0 vulnerabilities") {
$this->warn('NPM audit found vulnerabilities');
Flare::glow('NPM audit found vulnerabilities', MessageLevels::WARNING, ['output' => $npm->output()]);
Flare::report(new Exception('NPM audit found vulnerabilities'));
}
}
}
```
```php in kernel
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
```

View File

@@ -0,0 +1,47 @@
---
created: 2025-07-09 10:20
updated: 2025-07-09 10:20
---
```bash
php artisan make:command AuditDependenciesCommand
```
```php
<?php
namespace App\Console\Commands;
use Exception;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Process;
use Spatie\LaravelIgnition\Facades\Flare;
class AuditDependenciesCommand extends Command
{
protected $signature = 'app:audit-dependencies';
public function handle(): void
{
$composer = Process::run('composer audit');
if (!blank($composer->output())) {
$this->warn('Composer audit found vulnerabilities');
Log::warning('Composer audit found vulnerabilities', ['output' => $composer->output()]);
Flare::report(new Exception('Composer audit found vulnerabilities'));
}
$npm = Process::run('npm audit');
if (trim($npm->output()) !== "found 0 vulnerabilities") {
$this->warn('NPM audit found vulnerabilities');
Log::warning('NPM audit found vulnerabilities', ['output' => $npm->output()]);
Flare::report(new Exception('NPM audit found vulnerabilities'));
}
}
}
```
```php kernel
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
```

View File

@@ -0,0 +1,36 @@
h-[1lh]
Tap size target add absolute span in button next to the svg / icon
``` html
<span class="absolute top-1/2 left-1/2 -translate-1/2 size-12 [@media(pointer:fine)]:hidden"></span>
```
scrollable table
``` html
<div class="-mx-parent flex margin-whatever overflow-x-auto">
<div class="px-parent grow">
<table class="min-w-full whitescape-nowrap">
// Bla
<table/>
</div>
</div>
```
Easier if there is a css variable of page padding
Grid stuff
```html
<div class="grid grid-cols-[auto_1fr]">
<a class="col-span-2 grid grid-cols-subgrid">
<icon class="mr-2" />
<label />
</a>
</div>
```
#css #frontend

View File

@@ -0,0 +1,39 @@
---
created: 2025-07-03 09:50
updated: 2025-07-04 07:19
---
h-[1lh]
Tap size target add absolute span in button next to the svg / icon
``` html
<span class="absolute top-1/2 left-1/2 -translate-1/2 size-12 [@media(pointer:fine)]:hidden"></span>
```
scrollable table
``` html
<div class="-mx-parent flex margin-whatever overflow-x-auto">
<div class="px-parent grow">
<table class="min-w-full whitescape-nowrap">
// Bla
<table/>
</div>
</div>
```
Easier if there is a css variable of page padding
Grid stuff
```html
<div class="grid grid-cols-[auto_1fr]">
<a class="col-span-2 grid grid-cols-subgrid">
<icon class="mr-2" />
<label />
</a>
</div>
```
#Snippets #CSS

View File

@@ -0,0 +1,51 @@
---
created: 2025-02-24 13:13
updated: 2025-07-04 07:20
---
### Clone New Release
### Install Composer Dependencies
### NPM
```bash
cd {{ release }}
echo {{ sha }} >> commit_hash.txt
php artisan ziggy:generate
# php artisan translation:generate-vue
nice -n 19 npm ci
nice -n 19 npm run build
```
### Activate New Release
### Artisan
``` bash
cd {{ release }}
php artisan optimize:clear
php artisan horizon:terminate
php artisan migrate --force
php artisan optimize
php artisan filament:optimize
# php artisan generate:sitemap
# php artisan l5-swagger:generate
```
### Purge Old Releases
### Run Deployment Operations
```bash
cd {{ release }}
php artisan operations
```
#Laravel #Deployments

View File

@@ -0,0 +1,10 @@
---
created: 2025-02-24 09:57
updated: 2025-07-04 07:24
tags:
- Laravel/Packages
---
```bash
composer require dragon-code/laravel-deploy-operations && php artisan vendor:publish --tag=config --provider="DragonCode\LaravelDeployOperations\ServiceProvider"
```
#Laravel/Packages

153
Career/Others/Eslint.md Normal file
View File

@@ -0,0 +1,153 @@
---
created: 2025-02-24 09:46
updated: 2025-07-04 07:24
tags:
- BuildTools
---
```bash
npm uninstall @typescript-eslint/eslint-plugin eslint-plugin-unused-imports eslint-plugin-vue eslint eslint-plugin-tailwindcss eslint-plugin-vue eslint-plugin-no-relative-import-paths eslint-config-prettier prettier prettier-plugin-organize-imports prettier-plugin-tailwindcss typescript-eslint @vue/eslint-config-typescript @eslint/js
```
```bash
npm install -D eslint @typescript-eslint/eslint-plugin eslint-plugin-no-relative-import-paths eslint-plugin-unused-imports eslint-plugin-tailwindcss eslint-plugin-vue globals @eslint/js @eslint/eslintrc @vue/eslint-config-typescript @eslint/js
```
```bash
npx @eslint/migrate-config .eslintrc.json
```
```js eslint.config.js
import vue from "eslint-plugin-vue";
import unusedImports from "eslint-plugin-unused-imports";
import noRelativeImportPaths from 'eslint-plugin-no-relative-import-paths';
import {defineConfigWithVueTs, vueTsConfigs} from '@vue/eslint-config-typescript';
import tailwind from "eslint-plugin-tailwindcss";
export default defineConfigWithVueTs(
vue.configs['flat/recommended'],
tailwind.configs["flat/recommended"],
vueTsConfigs.recommended,
{
ignores: ['vendor', 'node_modules', 'public', 'bootstrap/ssr', 'tailwind.config.js', 'resources/js/components/ui/*'],
},
{
rules: {
'vue/html-indent': ['error', 4, {
attribute: 1,
baseIndent: 1,
closeBracket: 0,
alignAttributesVertically: true,
ignores: [],
}],
'vue/block-lang': 'off',
'vue/multi-word-component-names': 'off',
'@typescript-eslint/no-explicit-any': 'off',
"linebreak-style": ["error", "unix"],
"tailwindcss/no-custom-classname": "off",
"vue/no-mutating-props": "off",
"vue/prop-name-casing": "off",
"vue/no-setup-props-destructure": "off",
"vue/require-default-prop": "off"
},
},
{
plugins: {
"unused-imports": unusedImports,
},
},
{
plugins: {
'no-relative-import-paths': noRelativeImportPaths,
},
rules: {
"no-relative-import-paths/no-relative-import-paths": [
"warn",
{
"allowSameFolder": false,
"rootDir": "resources/js",
"prefix": "@"
}
],
},
},
{
settings: {
tailwindcss: {
config: './tailwind.config.js',
callees: ["classnames", "clsx", "ctl", 'twMerge'],
},
},
rules: {
"tailwindcss/no-custom-classname": "off",
}
},
);
```
```js .eslintrc.json
{
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"eslint:recommended",
"plugin:vue/vue3-recommended",
"plugin:@typescript-eslint/recommended",
"plugin:tailwindcss/recommended"
],
"overrides": [],
"parser": "vue-eslint-parser",
"parserOptions": {
"parser": "@typescript-eslint/parser",
"ecmaVersion": "latest",
"sourceType": "module"
},
"plugins": [
"vue",
"@typescript-eslint",
"unused-imports",
"no-relative-import-paths"
],
"rules": {
"linebreak-style": [
"error",
"unix"
],
"vue/multi-word-component-names": "off",
"tailwindcss/no-custom-classname": "off",
"vue/html-indent": [
"error",
4,
{
"attribute": 1,
"baseIndent": 1,
"closeBracket": 0,
"alignAttributesVertically": true,
"ignores": []
}
],
"vue/require-default-prop": "off",
"vue/no-mutating-props": "off",
"no-relative-import-paths/no-relative-import-paths": [
"warn",
{
"allowSameFolder": false,
"rootDir": "resources/js",
"prefix": "@"
}
],
"vue/prop-name-casing": "off",
"vue/no-setup-props-destructure": "off"
},
"ignorePatterns": [
"**/vue-i18n-locales.generated.js",
"**/ziggy.js"
]
}
```

View File

@@ -0,0 +1,108 @@
---
created: 2025-02-12 12:01
updated: 2025-07-04 07:27
tags:
- Laravel/Packages
---
# Install / update
```bash
npm uninstall @flareapp/flare-client @flareapp/flare-vue @flareapp/js @flareapp/vite @flareapp/vite-plugin-sourcemap-uploader @flareapp/vue
```
```bash
npm install @flareapp/js @flareapp/vue @flareapp/vite
```
```bash
composer require spatie/laravel-activitylog spatie/laravel-ignition
```
```js flare.js
import {flare} from "@flareapp/js";
flare.beforeSubmit = (report) => {
// Filter out errors that are not useful
if ([
'Request failed with status code 401',
'Network Error',
'Failed to fetch dynamically imported module',
'is not a valid JavaScript MIME type',
'Unable to preload CSS',
'Request aborted',
'Importing a module script failed.',
].some(v => report.message.includes(v))) {
return false;
}
// Filter silly bots
if ([
'adsbot',
'googlebot'
].some(v => report.context.request.useragent.includes(v))) {
return false;
}
return report;
};
export default flare;
```
```js app.js
import {flareVue} from "@flareapp/vue";
import flare from './plugins/flare';
if (import.meta.env.PROD) {
flare.light();
}
// createApp()
.use(flareVue)
//. .mount(el)
```
```js vite.config.js
import flareSourcemapUploader from '@flareapp/vite';
return {
plugins: [
// bla
flareSourcemapUploader({
key: env.VITE_FLARE_KEY,
}),
],
};
```
```php AppServiceProvider
private function versionStuff(): void
{
\Illuminate\Support\Facades\App::macro('getVersion', function () {
if (app()->isLocal()) {
return time();
}
if (file_exists(base_path('commit_hash.txt'))) {
return trim(file_get_contents(base_path('commit_hash.txt')));
}
return md5(base_path());
});
\Illuminate\Support\Facades\Cache::macro('getVersion', function () {
return app()->isLocal() ? time() : \Illuminate\Support\Facades\Cache::remember('version', now()->addDay(), fn() => App::getVersion());
});
\Spatie\LaravelIgnition\Facades\Flare::determineVersionUsing(function () {
return \Illuminate\Support\Facades\Cache::getVersion();
});
}
private function startLogBatch(): void
{
if (!\Spatie\Activitylog\Facades\LogBatch::isOpen()) {
\Spatie\Activitylog\Facades\LogBatch::startBatch();
\Illuminate\Support\Facades\Context::add('batch_uuid', \Spatie\Activitylog\Facades\LogBatch::getUuid());
}
}
```

View File

@@ -0,0 +1,8 @@
---
created: 2025-07-09 10:20
updated: 2025-07-09 10:20
---
``` bash
npm install @formkit/vue
```

92
Career/Others/Horizon.md Normal file
View File

@@ -0,0 +1,92 @@
---
created: 2025-03-13 14:23
updated: 2025-07-04 07:23
tags:
- Laravel/Packages
---
``` bash
php artisan make:command CheckStatusCommand && php artisan make:notification HorizonIsInactiveNotification
```
``` php CheckStatusCommand
<?php
namespace App\Console\Commands;
use App\Notifications\HorizonIsInactiveNotification;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Notification;
use Laravel\Horizon\Contracts\MasterSupervisorRepository;
class CheckStatusCommand extends Command
{
protected $description = 'Command description';
protected $signature = 'horizon:check-status';
/**
* Execute the console command.
*/
public function handle(): void
{
if (!$this->shouldBeActive()) {
return;
}
if ($this->isHorizonActive()) {
return;
}
$this->error('Horizon is inactive on: ' . config('app.name'));
Flare::report(new Exception('Horizon is inactive'));
Notification::route('mail', 'dev@strixi.nl')
->notify(new HorizonIsInactiveNotification());
}
protected function isHorizonActive(): bool
{
if (!$masters = app(MasterSupervisorRepository::class)->all()) {
return false;
}
return collect($masters)->some(fn($master): bool => $master->status !== 'paused');
}
protected function shouldBeActive(): bool
{
return config('queue.default') === 'redis';
}
}
```
``` php HorizonIsInactiveNotification
<?php
namespace App\Notifications;
use Illuminate\Notifications\Messages\MailMessage;
use Illuminate\Notifications\Notification;
class HorizonIsInactiveNotification extends Notification
{
public function via(object $notifiable): array
{
return ['mail'];
}
public function toMail(object $notifiable): MailMessage
{
return (new MailMessage)
->subject('Horizon is inactive on: ' . config('app.name'))
->line('Horizon is inactive on: ' . config('app.name'))
->action('Goto site', url(config('app.url')));
}
}
```
``` php kernel or bootstrap
$schedule->command(\App\Console\Commands\CheckStatusCommand::class)->everyFifteenMinutes();
```

View File

@@ -0,0 +1,11 @@
---
created: 2025-02-06 11:23
updated: 2025-07-04 07:36
---
### belongsToMany
Argument query
belongsToMany($related, $table = null, $foreignPivotKey = null, $relatedPivotKey = null, $parentKey = null, $relatedKey = null, $relation = null)
```mysql
select `related_table`.*, `table`.`foreignPivotKey` as `pivot_foreignPivotKey`, `table`.`relatedPivotKey` as `pivot_relatedPivotKey` from `networks` inner join `table` on `networks`.`relatedKey` = `table`.`relatedPivotKey` where `table`.`foreignPivotKey` in (?) and `related_table`.`deleted_at` is null
```

View File

@@ -0,0 +1,86 @@
---
created: 2025-01-31 10:42
updated: 2025-07-04 07:36
---
### Dynamic Tenancy Scoping
BelongsToRelation Trait
```php
trait BelongsToRelation
{
public static function bootBelongsToRelation(): void
{
if (static::belongsDirectlyToRelation()) {
static::addGlobalScope(new RelationScope());
return;
}
static::addGlobalScope(new RelationThroughScope());
}
public static function belongsDirectlyToRelation(): bool
{
return !static::getRelationThroughRelationship();
}
abstract public static function getRelationThroughRelationship(): ?string;
public function relation(): BelongsTo
{
return $this->belongsTo(Relation::class);
}
}
```
RelationScope
```php
class RelationScope implements Scope
{
public function apply(Builder $builder, Model $model): void
{
if (!Bouncer::inRelationScope()) {
return;
}
$builder->where($model->qualifyColumn('relation_id'), Bouncer::getRelationId());
if (method_exists($model, 'modifyRelationScope')) {
$model->modifyRelationScope($builder);
}
}
public function extend(Builder $builder): void
{
$builder->macro('withoutRelationScope', function (Builder $builder) {
return $builder->withoutGlobalScope($this);
});
$builder->macro('withOutsideRelationScope', function (Builder $builder, string $relations) {
return $builder->with([$relations => fn($query) => $query->withoutWarehouseScope()]);
});
}
}
```
RelationThroughScope
```php
class RelationThroughScope implements Scope
{
public function apply(Builder $builder, Model $model): void
{
if (!Bouncer::inRelationScope()) {
return;
}
$builder->whereHas($builder->getModel()->getRelationThroughRelationship());
}
public function extend(Builder $builder): void
{
$builder->macro('withoutRelationScope', function (Builder $builder) {
return $builder->withoutGlobalScope($this);
});
}
}
```

View File

@@ -0,0 +1,9 @@
---
created: 2025-03-26 11:35
updated: 2025-07-04 06:45
---
```bash
sudo grep 'seems busy' /var/log/php8.3-fpm.log
```
#PHP #bash #grep

View File

@@ -0,0 +1,12 @@
- [ ] 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

16
Career/Others/Nginx.md Normal file
View File

@@ -0,0 +1,16 @@
---
created: 2025-07-03 10:19
updated: 2025-07-03 10:35
---
## Header to Big
Add
```bash
location ~ \.php$ {
include fastcgi_params;
# Bla bla
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
}
```
After

View File

@@ -0,0 +1,35 @@
---
created: 2025-03-12 14:12
updated: 2025-07-04 07:25
tags:
- Laravel
---
```bash
php artisan down --render="errors::maintenance"
```
```bash
php artisan vendor:publish --tag=laravel-errors
```
```
touch ./resources/views/errors/maintenance.blade.php
```
``` php maintenance.blade.php
@extends('errors.minimal')
@section('title', __('Planned Maintenance'))
@section('message', __('Planned Maintenance'))
@section('description', __('We will be back in a few minutes.'))
```
``` php minimal.blade.php
@hasSection('code')
<div class="px-4 text-lg text-gray-500 border-r border-gray-400 tracking-wider">
@yield('code')
</div>
@endif
```

47
Career/Others/Rector.md Normal file
View File

@@ -0,0 +1,47 @@
---
created: 2025-03-17 14:03
updated: 2025-07-04 07:25
tags:
- Laravel/Packages
---
```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,
]);
```

43
Career/Others/Untitled.md Normal file
View File

@@ -0,0 +1,43 @@
```bash
php artisan make:command AuditDependenciesCommand
```
```php
<?php
namespace App\Console\Commands;
use Exception;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Process;
use Spatie\FlareClient\Enums\MessageLevels;
use Spatie\LaravelIgnition\Facades\Flare;
class AuditDependenciesCommand extends Command
{
protected $signature = 'app:audit-dependencies';
public function handle(): void
{
$composer = Process::run('composer audit');
if (!blank($composer->output())) {
$this->warn('Composer audit found vulnerabilities');
Flare::glow('Composer audit found vulnerabilities', MessageLevels::WARNING, ['output' => $composer->output()]);
Flare::report(new Exception('Composer audit found vulnerabilities'));
}
$npm = Process::run('npm audit');
if (trim($npm->output()) !== "found 0 vulnerabilities") {
$this->warn('NPM audit found vulnerabilities');
Flare::glow('NPM audit found vulnerabilities', MessageLevels::WARNING, ['output' => $npm->output()]);
Flare::report(new Exception('NPM audit found vulnerabilities'));
}
}
}
```
```php in kernel
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
```

13
Career/Projects/AI/AI.md Normal file
View File

@@ -0,0 +1,13 @@
---
created: 2025-07-09 10:20
updated: 2025-07-09 10:20
---
Starting point:
<https://github.com/snwfdhmp/awesome-gpt-prompt-engineering>
<https://m.youtube.com/watch?v=8omTe58MNQE>
<https://docs.text-gen.com/>
[[The Proof Reader]]
MOdels /s

View File

@@ -0,0 +1,11 @@
A cache tied to the model, is automatically clear when saving. This allows for caching without much thinking about cache invalidation.
## Usage
Call the model cache method on the model to access it
## Todo
- [x] Create a class which implements the cache methods and tags all caches. ✅ 2023-10-28
- [x] Create a trait which allows for access to this cache and clears is on saved. ✅ 2023-10-28
- [x] Add readme about usage. ✅ 2023-11-05
- [ ] Allow for the adding of other tags, so the cache can store values dependent on multiple models.
- [ ] Make the cache macroable so complex callbacks and tag configurations can defined just once. Add a cache()->toArray() example.
- [ ] Add a class factory as a place to store these macros.

View File

@@ -0,0 +1,9 @@
A attempt to split Laravel into domains and modules to support large projects without creating a ball of mud.
## Structure
The app folder has been removed and instead of that there are multiple folders in to root. Each resembling the app folder.
These folders are different domains. Pieces of the overal system that are or could be loosly coupled. Information exchange between these domains must use events or by specifically designated services.
Events are used to lat subscribers from any domain know something happened and it's up to that domain to die with that information what is want.
Service are used to query and command other domains.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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

View File

@@ -0,0 +1 @@
bla

View File

@@ -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.

View File

@@ -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

View File

@@ -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

View File

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

View File

@@ -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

13
Career/Resources/Nginx.md Normal file
View File

@@ -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

View File

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

View File

@@ -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"
```

View File

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

View File

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

View File

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

View File

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

View File

@@ -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

View File

@@ -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

View File

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

View File

@@ -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.

View File

@@ -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.

View File

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

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

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

View File

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

View File

@@ -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.

View File

@@ -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 users 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**.

View File

@@ -0,0 +1,42 @@
---
created: 2025-07-04 17:44
updated: 2025-07-04 17:44
---
## 1. Highlights & Wins
- **Project / Area**: QLS Handling — Deployed touchscreen time-tracking for warehouse staff
- **Impact & Metrics**:
- Staff onboarded: ~20 employees
- Time saved: ~1215 hrs/week (manual logging + digitization)
- Error reduction: ~85% fewer missing or incorrect entries
- **Project / Area**: QLS Handling — Kicked off API integration with third-party customs data provider
- **Impact & Metrics**:
- Shipments covered: ~50/day (~250/week)
- Time saved: ~20 hrs/week of manual data entry
- Error reduction: ~90% fewer data-entry mistakes
- **Project / Area**: QLS Handling — Led on-site brainstorming session with the warehouse team
- **Impact & Metrics**:
- Top action items: refine receiving workflow; update inventory labeling; establish daily stand-up
- Quick win: new labeling process (~2 hrs/week saved)
## 2. Challenges & Blockers
- **High urgency / Priority shift**: Compressed timeline forced pausing all other projects so I could devote 100% focus to QLS Handling.
- **Invoicing-flow complexity**: Need to support 4 major cost types (each with ≥ 2 billing variations) plus an upstream “incident” billing path for transport failures—making schema design and testing particularly intricate.
- **Spec dependencies**: Awaiting detailed incident definitions from logistics partners to finalize the upstream incident billing logic.
## 3. Learnings & Growth
- Prepared for AWS Aurora migration: configured the initial Aurora cluster and deepened understanding of its scaling, high-availability, and compatibility features.
- (No time this week for a formal skills deep-dive due to urgent QLS Handling priorities.)
## 4. Collaboration & Mentorship
- **Finance Stakeholder Meeting**: Discussed and aligned on the new invoicing flows requirements and billing model variations.
- **Warehouse Team Sync**: Gathered additional change requests and clarified workflows needed for QLS Handling updates.
## 5. Next Weeks Goals
- [ ] Migrate production database to AWS Aurora and validate performance benchmarks
- [ ] Roll out new warehouse software (built over the last half year) to the warehouse team: onboarding & training sessions
- [ ] Provide quick bug fixes and support for the new warehouse software as issues arise
- [ ] Finalize incident-billing logic once upstream specs arrive
- [ ] Conduct QLS integration smoke tests post-launch and triage any issues