!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

The first time I realized I wasn't as good as I thought I was when I met the smartest dev I've ever known (to this day).

I was hired to manage his team but was just immediately floored by the sheer knowledge and skills this guy displayed.

I started to wonder why they hired outside of the team instead of promoting him when I found that he just didn't mesh well with others.

He was very blunt about everything he says. Especially when it comes to code reviews. Man, he did /not/ mince words. And, of course, everyone took this as him just being an asshole.

But being an expert asshole myself, I could tell he wasn't really trying to be one and he was just quirky. He was really good and I really liked hanging out with him. I learned A LOT of things.

Can you imagine coming into a lead position, with years of experience in the role backing your confidence and then be told that your code is bad and then, systematically, very precisely, and very clearly be told why? That shit is humbling.

But it was the good kind of humbling, you know? I really liked that I had someone who could actually teach me new things.

So we hung out a lot and later on I got to meet his daughter and wife who told me that he had slight autism which is why he talked the way he did. He simply doesn't know how to talk any other way.

I explained it to the rest of the team (after getting permission) and once they understood that they started to take his criticism more seriously. He also started to learn to be less harsh with his words.

We developed some really nice friendships and our team was becoming a little family.

Year and a half later I had to leave the company for personal reasons. But before I did I convinced our boss to get him to replace me. The team was behind him now and he easily handled it like a pro.

That was 5 years ago. I moved out of the city, moved back, and got a job at another company.

Four months ago, he called me up and said he had three reasons for us to meet up.

1. He was making me god father of his new baby boy
2. That they created a new position for him at the company; VP of Engineering
and
3. He wanted to hang out

So we did and turns out he had a 4th reason; He had a nice job offer for me.

I'm telling this story now because I wanted to remind everyone of the lesson that every mainstream anime tells us:

Never underestimate the power of friendship.

dear anyone looking to teach kids programming (especially organizations):

- please be realistic. teach things your students can use. how to debug, how to solve realistic, real-world problems. not how to make a turtle draw a circle, that's not programming.

- please don't have blocks. just don't. they hurt.

- focus on your content instead of putting up posters on the wall with celebrities talking about the importance of programming

- don't call it 'code,' call it 'program.' do you know how different muggles think they are?

- please teach in a logical order. too many times have I seen commands --> functions --> variables/variable types --> then back to functions and return types.

- don't set an appropriate "age" to do it. please. its enough for people to learn to program, but to be told they're too "old" for a course? I can't tell you how many forgetful seniors and special needs students have been insulted. and don't even get me started on being too young. knowledge is knowledge, skill is skill, ability is ability.

- teach concepts with programming. don't separate them. they work better when they're taught together.

- understanding is more important than style. for beginners, fuck style. all of your program could be all on one line for fucks sake. I've had teachers chose style > functionality, because, fuck working programs, right?

- let your content speak for itself. this is not the place for celebrity endorsements.

- give resources for after a lesson is complete. when a beginner is finished, recommend more resources. you're never done learning.

most of these were things code.org did wrong. fuck them. I was in a constructive criticism mood today…

I try as hard as possible not to be judgemental towards incompetent colleagues, motivating myself with the knowledge that we were all incompetent at some point, and that people need a chance to learn, and that sometimes too much pressure will lead you to believe that they're bad. Or sometimes, people just aren't good at the stuff you want them to be good, and you just need to discover that niche where they will be very useful.

Mostly that goes well.
I've had the incompetent late bloomer who was a family man who started too late to dev, and wasn't really serious. A bit of harsh talk, some soul searching over a few beers, made him into a really valuable asset. Not the brightest rock, but reliable, steady-paced developer who earned his stay.
Then there was the girl who wasn't really good at coding, but saved our team from disaster many times by keeping things into account, and realizing what must be developed or tested at every step.

However, there are exceptions. I've worked with people who have been nothing but a menace, through their incompetence AND attitudes.

The most noteworthy example was an intern that we sought out, by talking to professors to point us to their best students. So we got that intern on board. He seemed strange at first. Kind of perfectionist. Talked serious, with an air of royalty, and always dressed sharply. He really gave the impression that one must be worthy to receive his blessing. The weirdest part was his handshake. It was as if he was touching an iron hand heated to 3000 degrees. It was over before you even knew it. Leaves you kinda offended. Especially when he always took a wet wipe after that and wiped his hands. Am I really that gross?
But that's fiiiine. I mean we're all different and weird in our own ways, right? So he's a germophobe, so fucking what? We just gotta find a way to work together, right?
WRONG.
As soon as he started (and remember, he's a paid intern, who barely knows how to code, and has zero industrial experience), he started questioning my architecture solutions, code implementations, etc. I don't mind discussion and criticism, which is why I welcomed his input. But it seemed like he wasn't willing to accept any arguments, so I started looking for excuses not to talk to him.
Meanwhile, the most productive team member we had, to whom you could just give and describe an idea, with architecture and stuff, well, and you'd see it implemented the next week, with only the most well placed questions asked, started going into fights with this intern for the same reasons I was avoiding him.
.....
And here's the kicker.
Get this:
This intern comes to me (I was the team lead), while that guy is not in the office, and with a straight face, dead serious, starts telling me that that guy was making stupid decisions and being a bad team member because he doesn't ... I quote him almost verbatim... "follow my indications". He said that I had to do something because he refused to work with him together.
I was stunned.
This good for nothing imagined superhuman, who was completely useless and an amazing annoyance to pretty much everyone in the team, came to me, telling me that the most capable and productive developer in the team is bad, because he doesn't follow his orders, and that I had to pick between the 2.

I couldn't believe what I had heard.
I had so much emotion in me right then. I was angry, but at the same time I could barely abstain from laughing.
I just told him calmly that he was wrong, and that I wouldn't mind if he never came back. I didn't see him for 5 years after that.

Anyway, later that week our team went for a dinner + beer, and the stories from all the team members started pouring in. They didn't want to talk him down either, but now that he was gone, it was a weight off, and everybody could tell their story.

What a fucking asshole.

So 5 years after I stumbled on him as he was entering a church. Still an arrogant bitch. Barely exchanged 10 polite words and I continued on my way as he was disinfecting his hands from my filthy handshake.

I have a junior who really drives me up a wall. He's been a junior for a couple of years now (since he started as an intern here).

He always looks for the quickest, cheapest, easiest solution he can possibly think of to all his tickets. Most of it pretty much just involves copy/pasting code that has similar functionality from elsewhere in the application, tweaking some variable names and calling it a day. And I mean, I'm not knocking copy/paste solutions at all, because that's a perfectly valid way of learning certain things, provided that one actually analyzes the code they are cloning, and actually modifies it in a way that solves the problem, and can potentially extend the ability to reuse the original code. This is rarely the case with this guy.

I've tried to gently encourage this person to take their time with things, and really put some thought into design with his solutions instead of rushing to finish; because ultimately all the time he spends on reworks could have been spent on doing it right the first time. Problem is, this guy is very stubborn, and gets very defensive when any sort of insinuation is made that he needs to improve on something. My advice to actually spend time analyzing how an interface was used, or how an extension method can be further extended before trying to brute-force your way through the problem seems to fall on deaf ears.

I always like to include my juniors on my pull requests; even though I pretty much have all final say in what gets merged, I like to encourage not only all devs be given thoughtful, constructive criticism, regardless of "rank" but also give them the opportunity to see how others write code and learn by asking questions, and analyzing why I approached the problem the way I did. It seems like this dev consistently uses this opportunity to get in as many public digs as he can on my work by going for the low-hanging fruit: "whitespace", "add comments, this code isn't self-documenting", and "an if/else here is more readable and consistent with this file than a ternary statement". Like dude, c'mon. Can you at least analyze the logic and see if it's sound? or perhaps offer a better way of doing something, or ask if the way I did something really makes sense?

Mid-Year reviews are due this week; I'm really struggling to find any way to document any sort of progress he's made. Once in a great while, he does surprise me and prove that he's capable of figuring out how something works and manage to use the mechanisms properly to solve a problem. At the very least he's productive (in terms of always working on assigned work). And because of this, he's likely safe from losing his job because the company considers him cheap labor. He is very underpaid, but also very under-qualified.

He's my most problematic junior; worst part is, he only has a job because of me: I wanted to give the benefit of the doubt when my boss asked me if we should extend an offer, as I thought it was only fair to give the opportunity to grow and prove himself like I was given. But I'm also starting to toe the line of being a good mentor by giving opportunities to learn, and falling behind on work because I could have just done it myself in a fraction of the time.

I hate managing people. I miss the days of code + spotify for 10 hours a day then going home.

Here's a real tip for people new to the industry.

It's one of those things that's been said over and over again but very few can really seem to employ. I suggest you learn it /well/.

You are not your code. Criticisms of your code, ideas, or your thought processes, is not a criticism of YOU. You absolutely cannot take criticisms of your work personally.

We are engineers. We strive to seek the best solution at all times.

If someone has found a problem with your code or with an idea or whatnot, it is coming from a place of "this is not the best solution", NOT "you're an idiot".

It's coming from a place of "I'm closing this PR because it is not a change I feel suits this project", NOT "I'm closing this PR because it's coming from a woman".

It's coming from a place of "This feature request is ridiculous/this bug is not actually a bug", NOT "you're a fucking idiot, fuck you".

It's coming from a place of "I've already had to address this in a number of issues before and it's eaten up a considerable amount of my time already", NOT "I don't even know you and this I don't have time for a nobody".

You do not get to be bitchy to maintainers because they denied your request. It's not a reflection of you at all. But if you're arguing with someone who has maintained a piece of code for almost a decade, and they're telling you something authoritative, believe them. They're probably smarter than you on this subject. They've probably thought about it more. They've probably seen their code used in many different places. They have more experience than you with that codebase in almost all cases.

Believe me, if we cared about who was behind all of the issues, pull requests, etc. we get, we'd get NOTHING done. Stop taking shit personally. It's a skill, not a defense mechanism. Nobody has the time to sugar coat every little thing.

Let's normalize directness and stop wasting time during technical discussions into opportunities for ego-stroking and circle-jerking and back-patting.

Our current programming teacher actually being able to teach us good practices and give us constructive criticism on our code.

"I don't want to offend you but well clearly you're not an artist. "

From the client i tell repeatedly "Web design is not my strong point so if there is a design you want we should bring on a designer"

And actually i was an artist. But i didn't like all the subjective criticism. Criticise my code when it doesn't work. I didn't ever sell you Web design

Time for a REAL fucking rant.

io_uring manpages say you can set the CAP_SYS_NICE capability to allow SQPOLL to work. You can't, you still get an operation not permitted errno result.

Why? I checked, it says 5.10 mainline is required. Pretty sure I just manually downloaded and installed the Deb's myself. uname reports that I am at 5.10. So what gives?

Maintainer submitted a patch because they fucked up and made the *actual* capability check look for what's basically root permissions (CAP_SYS_ADMIN... c'mon...) and is now trying to rectify a glaring security shortcoming.

Patch hasn't been accepted or even addressed yet but they already updated the manpages with the estimated mainline kernel release as if it had made it into the release candidate. Manpages have made it into latest debs but the actual change has not.

Where the fuck is the Linus Torvalds that would ream the fuck out of shitty developers doing shitty things? The political correctness climate has discouraged such criticism now and the result... this. This fucking mess, where people are allowed to cut corners and get away with it because it would hurt their feelings when faced with pressure.

I'm not just guessing either. The maintainer has already said some of the "tone" of criticisms hurt his feelings. Yes, sorry, but when you claim 90% speedup over a typical epoll application using your new magical set of syscalls, and nobody can even get 1-2% speedup on a similar machine, people are going to be fucking skeptical. Then when you lower it to 60% because you originally omitted a bunch of SECURITY RELATED AND CORRECTNESS CHECKING CODE, we're going to call you the fuck out for fudging numbers.

Trying to maintain the equivalent of academic integrity within the computer science field is an exercise of insanity. You'd be fired and shunned from publishing in journals if you pulled that shit in ANY OTHER FUCKING FIELD, but because the CS scene is all about jerking each other off at every corner because the mean people keep saying mean things on Twitter and it hurts your feelings therefore we're all allowed to contribute subpar work and be protected from criticisms when others realize it's subpar.

These aren't mistakes anymore, it's clear you're just trying to farm clout at Facebook - maybe even FOR Facebook.

Fuck you. Do it right, the first time. Sick of shitty code being OK all of a sudden.

When the poet in me fuses with the geek in me:

Will you be the css to my html?

When I encountered you,
My system threw a fatal error
My RAM was overloaded,
And my CPU went haywire

Will you be the css to my html?

I would show you my source code,
And let you merge your branch into mine
I will help you fix your memory leaks
And I will try filling all your nullpointers

Will you be the css to my html?

Your frontend would perfectly plug into my backend
I can compile all your heavy code,
Just in time

Baby just promise me,
You'll provide the JSON
To my API calls

Will you be the css to my html?

This is my first draft... Constructive criticism is welcome!

The people. I find devs to be (obvious generalization) prone to: not take criticism, not understand the difference between fact and opinion, not understanding that it is perfectly acceptable to change your point of view when presented with new information that will conflict with what you currently believe in. It is a sausage fest brought to you by eons of very fragile male ego in the making, and many other qualities that were very much diluted in a lot of the other fields I have worked on: from retail (shitfest) to import/export all the way to military (another shitfest, for different and rather dangerous reasons).

I have met some amazing people in the field, don't get me wrong, but the quirkiest of mfkers i have met make me believe that maybe I AM the one that does not belong in the field (top kek).

On a more technical side, basic stuff like reading comprehension, attention to detail, the ability to translate complex problemd to pieces and that interconnect among the themselves, the ability to understand the grand mathematical scheme of things, the ability to be patient and despite what the above generalization would have you believe...the ability to communicate with other humans with tact and understanding as well as a spirit of collaboration, etc etc, are definitive traits to consider if you want a career in software development that leads above just being a code monkey.

Shit like that.

Few years ago as a junior android dev with couple years of self taught experience of working in startups I submitted a simple android app assignment for a junior android dev role. Assignment had only like 8 requirements so I followed them to the letter. That didn't end well.

App was simple just 3 screens. Login screen with username and password input fields, login button.

Had to call a login endpoint after login button was clicked, redirecting to home screen, calling items endpoint, displaying a list of items and when an item was clicked passing item data and redirect to item details screen.

Needless to say big swinging dick senior was not impressed. UI was not perfect, I forgot to display a loading animation when fetching data, didnt handle back button properly.

I agreed with some points but other comments were clearly just nitpicking: his preferred variable naming conventions, his opinions on architecture that was not up to his standard (official google arch at the time was not up to his standard).

He also was mad that app wasn't prepared for release to googleplay (another out of the ass requirement). Like I would prepare a 3 screen app for prod release that he will forget ever existed after 20min of his review.

Lots more of nitpicking, encapsulation this encapsulation that, omg now hes shocked that there are a few warnings after the project is built.

Regardless my self confidence was destroyed at that point and after few more negative experiences I dropped android dev alltogether for a couple years and switched to game dev.

After game dev ran its course I went back to android dev and found a supportive place where I could grow.

Looking back, they were actually hiring atleast a mid level for a junior position but I was grilled as a senior. The guy literally didnt wrote any single positive thing in that review about my code even tho my senior peers said my project was decent back then, its just that I didnt handle a few edge cases and that's all.

I looked up the guy in linkedin, turns out hes a uni dropout who posts all books that he red about software dev in his education section of his linkedin profile. Found a bunch of other narcissistic stuff on his profile. Guy was a fucking idiot. Even if I worked under him it would have probably sucked.

Learned some important lessons I guess. Always get a second, 3rd and 4th opinion and dont take criticism too seriously. Always check what kind of person is providing feedback.

Not the code review itself, but having repeatedly to nag my project leader just to get a review is the worst.

I'm "only" a student and it's a project without fix deadlines so it's alright with me that it is low priority.
But - I want to learn something here, I really do, I'm new to C# and far from mastery. Apart from that my focus was mainly hardware during the last years.
I need some fucking brutal and honest criticism on my code, damnit!
That's all.

These are the programmers who I had encountered and detest intensely:

1. Programmers who addicted to take other programmers' failure as an achievement.

2. Programmers who are overly arrogant. (Hey just because you know something , that don't make you a God)

3. Programmers who stealing my code without crediting me, and yet he got paid.

4. Programmers who discourage new developers.

5. Programmers who can't take criticism (Once I told a dev that his code is not clean as he decided to name the variable like __fuckingFuckingFuckningVar = "Fuck"; , he yelled at me that i am a MF. Which it's completely childish in my opinion, as a software engineer, I think programme a clean code for easy maintain and understandable for others, it is a responsibility.)

6. Programmers who compare me with others.

7. Programmers who are not friendly. (Don't be like Stackoverflow).

I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly.
Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.
Working independently is a must. It's okay to ask questions, but ask sparingly.
Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.
These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

Here we are, three years later. Our system breaks down at the slightest load. An architecture is hardly recognizable anymore. The code consists of methods that have been refactored beyond recognition. The so-called architects came and went, leaving behind an ever-growing fiasco. Wrong decisions are concealed, criticism of them dismissed as ignorance. Our clients are on the verge of having us all killed. Daily crisis meetings are the norm. The remaining developers skulk around the unmaintainable code like emaciated ghosts. Everyone who has even the slightest chance to escape takes a parachute. Our dailies are made up of lies to cover up yesterday's lies. Our Mondays have become days of dread, because that's when the weekend disaster news has to be analyzed. Yet there are still developers who turn a blind eye. Who recommend this and that workaround in a good-humored tone. The code consists only of workarounds. Sarcasm has replaced any normal discussion. Reasonable suggestions on how to basically refactor the whole thing are rejected for cost reasons. In the process, our entire budget is eaten up by maintenance costs. Middle management should be put up against the wall. Why am I still here? This deceptive feeling that one could still turn the tide. This is eating me up.

Positively accepting criticism is a superpower I hope to acquire one day. As in jump in joy and violently smile when they say my code is shit level of positive acceptance.

I don't really hate or reject criticism. I am simply saddened by it, on a good day.

so yes, if you have this superpower, where's the source?

I am working in a cool company where during our coding principles conversation , I was giving a walkthrough of my code. I accepted some valid criticism. Shit hit the fan, when my I tried to explain it to them why I have written modules and the necessity of them in this application. So instead of writing several functions , I have created a common module for handling these tasks . After a lengthy argument , I am told that I should write understandable and lengthy code instead of complex and small one. This is what I think so too, that code should be readable by human but at some point , one also has to look decide if this practice is suitable for every carse or not. Man this is fucking killin me. Then I am also told that to rewrite the code and write it in such a way that's naive and easy to understand

How do you guys cope with being a junior dev and constantly receiving criticism about your work from your team leader?
I started working as a developer quite late: I did go to college in my early years but I was lazy at the time, so I didn't complete it. So I worked about ten years in a totally different industry, but I always wanted to go back to being a developer.
I've managed to do it when I was 34: I was a web developer in a small company and I was pretty much the only dev, except for an older dude who only knew Visual Basic 6 and kept programming things with it (in 2020ish!). In those years I always felt like a was way ahead of my colleague, and my efforts to apply best practices were not so welcome.
I eventually got tired of that situation, because I was feeling like wasting my time: I was already quite old and stuck in a jurassic environment
Then, I landed in a new company. Completely different environment: they use modern frameworks, TDD, static analysis, code reviews and stuff, and they do one to one meetings every two weeks. From the beginning, I felt like I was the dinosaur there: they were way ahead of me and I struggled to keep the pace. I immediately said that to my manager, but he was like "don't worry, it's just the start. I'm sure you will do great". Except I did not. I started collecting criticism about my work and I keep receiving it. When I tell my manager that constant criticism is not good for my self esteem, he replies "I can understand, but you have to manage it and I cannot avoid to correct you when you make mistakes". But it became really difficult for me to receive constant criticism, I very rarely have a compliment or a good word about what I do.
Is it just me? Should I finally grow up now that I am almost 40 and accept that working always sucks and you cannot be satisfied of what you do? Or am I simply a bad developer and should look for another job?
I am starting to get tired of this situation.

I went to a meeting full of business senior management and IT senior management and proceeded to dress them down for treating me and my team like code monkeys. I was quite pointed in my criticism. Now, I'm just trying to deliver to minimize the blowback. I was right, but not my finest example of communication.

Can we all please try to keep emotion out of coding? It never ever helps to get upset at a code review.

Please please please accept constructive criticism, and dish it back to me! You can hate my code just don't hate me. :/

Hi I’m a Python Developer, tired of doing internal applications using Excel as a UI. I’m thinking of proposing to turn most of our projects into internal web apps instead. Has anyone gone through this sort of problem?

My team is quite pro at using Excel, so naturally they prefer to use the tools I build from Excel. Some of those tools are also used by external teams, but they are not as capable with Excel, so they need supervision and guidance.

There are multiple concerns that arise:
- I code on Mac, but they need to run it on Windows, so compatibility issues
- Some of their laptops might not have enough resources to run the tasks
- Errors are harder to trace and could be very user-specific.
- New developers might not be familiar with Excel and the way to integrate with Python

I would like to know your opinion or criticism

After I have been using tabnine and Grammarly for quite some time, I thought I follow this years' hype and give GitHub Codepilot a try, before eventually considering chatGPT.

Added Copilot to my IDE, proceeded to extend behavioral test descriptions in JavaScript.

Copilot suggests the most redundant and irrelevant inline comments I can imagine. They would be a legitimate target of criticism in every code review.

Wasn't it supposed to add some code that's actually useful? Well, tabnine and JetBrains IDEA annotations already did that anyway.

What did I miss?

When your coworker is a "yes...but". If your solution is either non-existent, or vague, and mine is actual code, PLZ STFU. Nobody wants your "constructive criticism".

I am honestly fine with people who criticise my code. It could be a bad or good criticism, I'm honestly fine with that. Because it is from that criticism that I get those 'ahaaa' moments or those 'ooowh I see now' moments.

What are you supposed to do in an environment where your peers can't take criticism on the code and their approach to problem solving? They like to take shortcuts which end of making the software less maintainable. Is it worth to convince them to use best practices and be labeled as a bad guy who keeps on ranting about stuff they don't understand?

I saved myself headaches and whenever some one talks about this thing, I leave ...

Code gets complicated? Blame the one who forced that coding style in front of management and go to sleep peacefully.

Either work like an adult and accept criticism or go away and let me do what I'm paid for ...

Obviously I'm just now beginning to learn, criticism not appreciated, lol.. Can anyone tell me like.. How to ACTUALLY edit github files in android studio???! Ive tried importing, copying and pasting the code, idk what to do maybe I'm just dumb who knows.. But I cannot for the life of me seem to get any of the code from github files to actually run once it's imported..