Init

Career/Articles/Brag document.md

@@ -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 20–27, 2025
+
+### 1. Features & Deliverables Shipped
+
+- **Invoicing Module Overhaul**
+    
+    - **QLS Data Export**  
+        • Built a CSV/JSON export so invoicing totals can be reconciled against the customer’s 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.

Career/Articles/Drunk engineer.md

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

Career/Articles/Get your work recognized write a brag document.md

@@ -0,0 +1,200 @@
+[[ReadItLater]] [[Article]]
+
+# [Get your work recognized: write a brag document](https://jvns.ca/blog/brag-documents/)
+
+There’s 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, it’s often more complicated than that – some kinds of important work are more visible/memorable than others. It’s frustrating to have done something really important and later realize that you didn’t get rewarded for it just because the people making the decision didn’t 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 isn’t 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, what’s important to me, what I’m learning, and what I’d like to be doing differently. But they’ve definitely helped with promotions!
+
+You can also [skip to the brag document template at the end](https://jvns.ca/blog/brag-documents/#template).
+
+### you don’t remember everything you did
+
+One thing I’m 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 it’s 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 doesn’t remember everything you did
+
+And if you don’t remember everything important you did, your manager (no matter how great they are!) probably doesn’t either. And they need to explain to other people why you should be promoted or given an evaluation like “exceeds expectations” (“X’s work is so awesome!!!!” doesn’t fly).
+
+So if your manager is going to effectively advocate for you, they need help.
+
+### here’s 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, I’ve been doing that for a long time, it really helps”.
+
+Where I work we call this a “brag document” but I’ve heard other names for the same concept like “hype document” or “list of stuff I did” :).
+
+There’s 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 you’ve 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 it’s 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 it’s 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 I’ve been focused on (like “security”) and listing all the work I’ve done in that area there. This is especially good if you’re 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 isn’t a big shiny ship.
+
+### use your brag document to notice patterns
+
+In the past I’ve found the brag document useful not just to hype my accomplishments, but also to reflect on the work I’ve done. Some questions it’s helped me with:
+
+-   What work do I feel most proud of?
+-   Are there themes in these projects I should be thinking about? What’s the big picture of what I’m 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 didn’t? 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!
+
+### don’t 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 don’t know how to explain why it’s important. But I think this kind of work is especially important to put into your brag document because it’s 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 it’s important to refactor X piece of code?)
+2.  list some things you’ve done towards that goal
+3.  list any effects you’ve seen of the work, even if they’re a little indirect
+
+If you tell your coworkers this kind of work is important to you and tell them what you’ve 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 it’s 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 you’re working on something hard, and an outside perspective from a friend or colleague can really help you see why what you’re doing is important.
+
+Brag documents are good when you use them on your own to advocate for yourself, but I think they’re better as a collaborative effort to recognize where people are excelling.
+
+Next, I want to talk about a couple of structures that we’ve 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 other’s documents, and identify places where people haven’t bragged “enough” – maybe they worked on an extremely critical project to the company but didn’t highlight how important it was, maybe they improved test performance but didn’t say that they made the tests 3 times faster and that it improved everyone’s developer experience. It’s 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. It’s a nice way for people to talk about work that they’re 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 don’t 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 you’re someone who really cares about your work, I think it’s really positive to share your goals & accomplishments (and the things that haven’t gone so well too!) with your friends and coworkers. It makes it feel less like you’re 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.
+
+I’d also recommend the blog post [Hype Yourself! You’re 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
+
+Here’s a template for a brag document! Usually I make one brag document per year. (“Julia’s 2017 brag document”). I think it’s okay to make it quite long / comprehensive – 5-10 pages or more for a year of work doesn’t seem like too much to me, especially if you’re including some graphs/charts / screenshots to show the effects of what you did.
+
+One thing I want to emphasize, for people who don’t like to brag, is – **you don’t 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 that’s 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 it’s 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: don’t forget to explain what the results of you work actually were! It’s 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 you’re 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 it’s a great idea – try listing important things you learned or skills you’ve 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
+
+It’s really easy to lose track of what skills you’re learning, and usually when I reflect on this I realize I learned a lot more than I thought and also notice things that I’m *not* learning that I wish I was.
+
+### Outside of work
+
+It’s 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 you’re thinking about your career outside of strictly what you’re doing at work.
+
+This can also include other non-career-related things you’re proud of, if that feels good to you! Some people like to keep a combined personal + work brag document.
+
+### General prompts
+
+If you’re 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?

Career/Articles/Really good shadows.md

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

Career/Articles/Salary Negotiation - Make More Money, Be More Valued/Salary Negotiation - Make More Money, Be More Valued.md

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

Career/Articles/Salary.md

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