Dear Apple,

We've sent you a new message regarding your app, Xcode. To view or reply to the message, go to the Resolution Centre.
----------------------------------
We noticed that your app did not fully meet the terms and conditions for reasonable fucking update size. Your latest app update requires over 40 GB of free fucking disk space. Please bear in mind that many of your own fucking laptops only have 120 GB of disk space. For optimum user experience, it would be best if the user didn't have to uninstall other apps from their system just to run your shitty update system.

Next Steps:

To resolve this problem, we recommend that you fix your shit. If you are unable to fix your shit, we recommend that you don't take 30% of all iOS developer's income so that you can make giant fucking glass donut buildings, and instead use that ridiculously disproportionate monopoly-abusing cut and invest that money in fixing your shit, to lighten the load of developers on whose backs you have become the most cash-rich company in human history.

Resources:

There are plenty of resources such as Stack Overflow to take advantage of, in order to learn how not to create a bloated piece of shit IDE.

Once you've completed all required changes, please upload a new binary to the App Store.

Every week is the same. Wake up, new jira ticket. “Build us a pink house”.

*i build a house*

Next day, “URGENT BUG REPORT!!! CRITICAL ISSUE IMPORTANT IMPORTANT IMPORTANT”, click on ticket, “bug report: the house doesn’t have sprinklers”

They didn’t ask for sprinklers. This is not a bug. *i add sprinklers*

Next day, “URGENT BUG REPORT!!! CRITICAL ISSUE IMPORTANT IMPORTANT IMPORTANT ASAP ASAP ASAP”, click on ticket, “bug report: the house is pink.”

HOW IS THAT A BUG TWO DAYS AGO IT WAS LITERALLY A REQUIREMENT

Meanwhile management makes triple my salary

To compiler warnings:
Thank you, thank you, thank you

Welcome to the future guys.

To anyone new to the corporate world I have this advice: there's a game no one tells you about in school or university. It's a game of politics. The good news is that you can choose not to play the game. The bad news is that others who do can change that decision for you, if you give them a reason to. So here's my tips to keep yourself from common bad situations:

* Some people will say they'd "prefer that people were honest". This is an outright lie.
* Be guarded - if a scenario could be taken out of context assume it will be.
* Mimic the office culture, don't try to rock the boat.
* Be polite, but always stay neutral between colleagues, picking a side means you're playing the game. Unless that side is your company vs another company in which case-- you are 100% on the company side and everyone else is stupid and incompetent.

Do not assume that the current codebase is perfect, or even remotely close to an example of acceptable style/structure.

Listen, before you talk...

Question everything!

Comments lie.. sometimes code does too.. Customers..they lie the most..and are sloppy..

Don't be like customers, don't be sloppy. If you were sloppy own it & don't lie about it!

Pick your fights (trying to fix vs rewrite the shit out of it)..you will know what to do more with experience..

RTFM & docs.. If things still unclear, ask before your dick gets stuck in a toaster!

Ask away, learn about the customers & how they use your product.. you'll be surprised how something intuitive to you might be a rocket science for them..meaning more room to fuck things up when using it..more ways you can adapt & prevent things..

Most of all, don't fuckin lie.. ever!!
If you lie on you're CV, we will find out.. If you fuck up something & lie about it, we will find out.. but it will cost us precious time when solving it from scratch.. People fuck up..that's a fact..how you go about it is what makes/breaks it for me. So don't ever fuckin lie to me!!

And don't be arogant.. if you complain about fixing bugs, this is not a job for you.. if you can't even fix the obvious ones you've put there in the first place..twice as bad..

So think before you code..what do you want to do, how you want to accomplish this, is it reusable, can it be extended, does it introduce new technology into the project, will it fuck up current setup.. once you have this shit figured out, code will write itself..

Did I mention already you're not to lie to me, ever?!

And don't try talking about me behind my back either..I've seen it backfire before, results were not good..

<<prev. #wk235 advices>>

~ Study the Error log deeply, Google each line if needed. Don't give up.
~ Learn by doing. Don't just read/watch.
~ Practice breaking down the problem statement first in different components and hierarchies. Don't jump into coding right away.
~ Write some, review some. Don't put off review for later.
~ Even if you don't exactly follow the best security practices - always ensure that your program is safe for use. Especially for user-inputs, etc, pay attention.
~ Never distribute code with passwords/keys written in it.
~ Don't hard code stuff, use Config file, environment variables, etc.
~ Try to automate repetitive stuff like build and deploy etc
~ Save and backup you code.
~ No one knows everything, also, today's knowledge gets outdated tomorrow. Continuous learning is synonymous with this field.

<<next #wk235 advices>>

Always under promise and over deliver

Don’t put pressure on yourself to understand everything. No single person understands it all, that’s why there’s a bunch of us.

1. Trust no one even yourself
2. Ask questions even if they are stupid
3. Test your solutions, even manually
4. Write comments
5. Take your time to solve problem, even if it looks like easy see point 1
6. Take some time during work to get familiar with code and read something about technology that is part of your current work - even if you know it - see point 1
7. Always try to see a big picture - see point 2 - why is it implemented is more important then how is it implemented

Get your code reviewed by as many good devs as you can. Tell them to be harsh, swallow your pride, expect the code to be torn apart. Then rinse and repeat.

It brings the "know it all" fresh grads down a peg or two, and often brings those with low self esteem up a peg or two (when they realise their code is better than they thought.) Anyone can write code that works. But writing decent, clear, well-tested code that stands up to scrutiny is a different ball game - and it's important to learn that quickly.

There's no such thing as an expert programmer. With time you just get different kinda errors. As long as you're not getting same error, you're making progress.

Time spent getting to grips with your OS is usually time spent well. While you're not operations, it really helps being able to solve general problems yourself without calling support.

Oh, and: Set up a good bashrc, and put it on the servers you're working with.

"Many already Know this, but from this point on, Google is your wife."

I can't say how many times there has been a question which had a straightforward answer with one search.

Put away the keyboard. Think about what you're going to do, chart it out, work through the logic and then, when the entire construct is before you, you start typing.

Yes it will take longer, you're a junior, enjoy that nobody expects you to do miracles (yet) and take the time, you'll get it back when you're so used to working through logical problems that it happens on its own as soon as you hear about the problem.

Cutting corners and "hacking a quick solution" without fucking over the entire system is an art form. Before you do art learn your damn craft.

- There are no stupid questions. Please feel free to ask.
- You don't have to memorize, but try to understand.
- Document so you never have to remember.
- Teach so you will master and never forget.
- Even if we have different responsibilities do not ping pong issues because overall the client only sees one company name so we work as one.
- Do not disturb while on vacation leave unless it's life or death.
- Relax, sleep and have a happy weekend.

* KISS (keep it super simple)
* don’t try solve a problem you don’t already have
* admit if you messed up. We can solve a problem early and minimise the damage. People should never be scared to admit when they mess up. No one is perfect.
* voice your opinion. You’d be surprised how helpful this can be to your team, as we need to look at things from all angles.
* help your team. If you see something wrong, make the team aware of it.
* ask if unsure, don’t assume

Comment your code, you'll thank me for that next week.

Know the basics of the tech, don't just dive in with some off the shelf blackbox buzzword then find yourself crippled when you need to debug it going wrong

If you think you found a solution, think twice.
If the implementation is taking too long (too many changes in different functions and classes to fix a single bug) there may be a better solution, it's never too late to reverse the changes and start again, it's not a shame, in the worst case you will reimplement the same solution, but better, in the best you'll find an easier and better one.

Don't run, even if there's a deadline.
It's much worse having to deal with negative feedbacks later.

Work on projects and read a lot of source code like if you are reading a book.

Shut that computer off and go home. You'll think clearer in the morning.

"Not everyone notices the flowers you plant, but everyone will notice the fire you start." - Unknown

Next time you're using some FOSS soft, or bitching about it being buggy or the maintainer not responding to your tickets the same day - remember, that the author of that soft could be enjoying some nap time, playing with hie/her child(ren), having a fun time with fam/friends, playing PC games, going for a walk, cooking and choosing healthy food over fast snacks, doing anything he/she wanted.

But instead, the developer chose to spend that time building a tool, so you could have it, so you could do things faster/easier. So YOU could spend your free time the way you want.

So next time you're bitching about something not working, stop for a moment and first say THANK YOU to the author for that tool. If not for people like him/her, you would still be doing your chores with sticks and stones

Juniors are a fun bunch to work with.
Over confident, hero complex of that fresh graduate high, and then thrown in to the real world! Where there hopes and dreams are crushed in minutes when they see what monolithic applications really look like!!

But don't let that overwhelm you, your not going to be changing all of it any time soon, hell some of this code hasn't been touched in 5+ years and still works without fail.

Don't stress about the work load, you can only write 1 line of code at a time anyway, and hell, even seniors make mistakes.

The key about being able to manage this beast is simple, break it! Because the more you break it, the more you'll understand how a project is put together, for better or worse. Learn from the examples in front of you, and learn what not to do in the future 😎

But more importantly, plan your changes, whiteboard the high level logic of what it is you want to add, then whiteboard in the current codebase and determine where to slice this bitch up, then when it all looks well and good, take out your scalpel and slice and dice time.
Don't worry, your changes aren't going to production anytime soon, hell, you'll be lucky to get past the first pull request with this working 100% the first time, and that's a good thing, learn from tour short comings and improve your own knowledge for the next time!

GOOGLE PUSHES .WEBP

GOOGLE SLIDES: "UNSUPPORTED IMAGE TYPE"

F************

Life would be so easier if they start providing IDE in exams rather than writing all codes on sheets🥺🥺

1. You don't code to add a feature or whatever. You do it to solve Users' problems. It's a User-centric system.
2. You read more code than you write. So help yourself and write code intended to be read.
3. If people don't know you did something, you did nothing!
4. Never answer a call at 3 am if you're not paid to be on night call-duty. You'll become the guy who answers at 3 am.
5. Remember the big difference between you and me is that I failed to do stuff more times than you have tried to do.
6. When you start shaving the yak, stop!