You know what?

Young cocky React devs can suck my old fuckin LAMP and Objective-C balls.

Got a new freelance job and got brought in to triage a React Native iOS/Android app. Lead dev's first comment to me is: "Bro, have you ever used React Native".

To which I had to reply to save my honor publicly, "No, but I have like 8 years with Objective-C and 3 years with Swift, and 3 years with Node, so I maybe I'll still be able help. Sometimes it just helps to have a fresh set of eyes."

"Well, nobody but me can work on this code."

And that, as it turned out was almost true.

After going back and forth with our PM and this dev I finally get his code base.

"Just run "npm install" he says".

Like no fuckin shit junior... lets see if that will actually work.

Node 14... nope whole project dies.

Node 12 LTS... nope whole project dies.

Install all of react native globally because fuck it, try again... still dies.

Node 10 LTS... project installs but still won't run or build complaining about some conflict with React Native libraries and Cocoa pods.

Go back to my PM... "Um, this project won't work on any version of Node newer than about 5 years old... and even if it did it still won't build, and even if it would build it still runs like shit. And even if we fix all of that Apple might still tell us to fuck off because it's React Native.

Spend like a week in npm and node hell just trying to fucking hand install enough dependencies to unfuck this turds project.

All the while the original dev is still trying TO FIX HIS OWN FUCKING CODE while also being a cocky ass the entire time. Now, I can appreciate a cocky dev... I was horrendously cocky in my younger days and have only gotten marginally better with age. But if you're gonna be cocky, you also have to be good at it. And this guy was not.

Lo, we're not done. OG Dev comes down with "Corona Virus"... I put this in quotes because the dude ends up drawing out his "virus" for over 4 months before finally putting us in touch with "another dev team he sometimes uses".

Next, me and my PM get on a MS Teams call with this Indian house. No problems there, I've worked with the Indians before... but... these are guys are not good. They're talking about how they've already built the iOS build... but then I ask them what they did to sort out the ReactNative/Cocoa Pods conflict and they have no idea what I'm talking about.

Why?

Well, one of these suckers sends a link to some repo and I find out why. When he sends the link it exposes his email...

This Indian dude's emails was our-devs-name@gmail.com...

We'd been played.

Company sued the shit out of the OG dev and the Indian company he was selling off his work to.

I rewrote the app in Swift.

So, lets review... the React dev fucked up his own project so bad even he couldn't fix it... had to get a team of Indians to help who also couldn't fix it... was still a dickhead to me when I couldn't fix it... and in the end it was all so broken we had to just do a rewrite.

None of you get npm. None of you get React. None of you get that doing the web the way Mark Zucherberg does it just makes you a choad locked into that ecosystem. None of you can fix your own damn projects when one of the 6,000 dependency developers pushes breaking changes. None of you ever even bother with "npm audit fix" because if security was a concern you'd be using a server side language for fucking server side programming like a grown up.

So, next time a senior dev with 20 years exp. gets brought in to help triage a project that you yourself fucked up... Remember that the new thing you know and think makes you cool? It's not new and it's not cool. It's just JavaScript on the server so you script kiddies never have to learn anything but JavaScript... which makes you inarguably worse programmers.

And, MF, I was literally writing javascript while you were sucking your mommas titties so just chill... this shit ain't new and I've got a dozen of my own Node daemons running right now... difference is?

Mine are still working.

!rant

New job (first CS job).

Day 1: Install Ubuntu
Day 2: Dev said "it was so cute when he asked if he could uninstall windows." Also, first pair programming with engineer of 12 years. First commit (he did all the work, I just tried keeping up."
Day 3: "Here, try this bug " nearly get there. Have to leave early. Team event (Group VR experience, was wicked fun with drinks afterwards. Turns out boss man is a total bad ass. Swam with sharks and giant Wales)
Day 4: Fix bug. Notice odd behaviour. Fix that too. (All on my own). Code review: "This, that but works and is good." Get asked if I want to go to customer to do A, B and C. Tell Boss I only know B. He said "Tell me what you need for A and C."

I'm so God damn happy.

What's code review?
*programming in production*

Wrote 800-1200 LOC
It went through code review which was apparently my first code being reviewed
Took me 1 month and more to fix most changes (per day more than 10-12 hrs of effort)..
That 1 month was a nightmare. Every day I thought of giving up programming. I shouted to myself every night why did I never considered these myself. How can I be so dumb.
Half of the reviews I didn't even know how to implement. Didn't even know what to Google.
I consider it as one of my toughest phase as a developer till date.
I still get goosebumps remembering those days.

TL;DR: I dont work in IT, but I code at work, and the non-IT higher-ups lack of knowledge shows brutally.

So I work in aviation, not IT. Through coincidences, I was tasked to work on our flight plan distribution logic years ago, which was then written in BRL (Business Rule Language). In lockdown 2020, I finally started to learn "real" programming with Python, but soon shifted to Java. Which was good, since all of a sudden a few months ago the company ditched BRL and the godawful IBM ODM IDE for... Java and IntelliJ. Nice. BUT my teammates have zero clue about Java and no real inclination to learn it by themselves. So I have been appointed their mentor, despite me stating Im still a beginner myself. Its somewhat doable, I get the hard problems, they do basic maintenace, basically renaming variables and stuff. One of my yearly goals is to make sure a completely new guy is able to do everything I do by september. It took a LOT to talk them out of it.

In my last yearly review I got some flak for not "selling" myself to other teams enough, whatever that means. So, as a learning project, I designed a new intranet page for our department in Javascript. Its loved by all. It has links to all the stuff we need woth a nice interface and built in tools to make work easier and more efficient. I did it on my own, in my spare time, simply because I was fed up with the old crap and it was an enormously good learning opportunity. Now they want to give some other guy the responsibility over that page/tool because apparently it is "not in my process team description". They even planned a day for me and him so he can "learn Javascript then". Suuure...

I also did a digital checklist tool as a webapp. All this runs from a local folder, no server at all because reasons. I made it work. Now they want it integrated into some other tool some other guy made. He wrote his tool in PHP entirely so merging the two will take considerable time. Which I told them multiple times. No, it does not take about two hours.

Sometimes, comrades, sometimes....
Im still grateful for the opportunity to code at work but the lack of knowledge really REALLY shows. My goal now is to talk management into paying for a Java course for me (they are very expensive here). That way, they get a better employee and I get more knowledge and an actual certificate thats worth something. Usually in this company, this has higher chances of success than straight up asking for more money.

Sorry for the long story, but it felt good just typing it all out, even if nobody reads this.

Last year I signed in for a course called "Best Practices in Programming", and part of the course was to get the code of our current projects reviewed by a professional developer. I had a horribly written (out of inexperience) code in Python. The guy who had to review my code basically said I had no idea about coding but went on helping me a lot. Since then I started to learn some concepts of software engineering, how to code more efficiently, and so on and I've been much better ever since. So kudos to him for putting up with my spaghetti code and sending me in the right direction!

Sometimes it works... :)

Indian web dev companies suck ( for developers )

when I finished 3 year grad program in computer application here in my country (India), I thought life's gonna be fun working as a developer. Oh boy, I was so wrong.

I started out working for a small service based IT company, followed by 2 more. I realized really quickly that they're nothing short of a scam. If your company's only agenda to somehow survive in the market and showing no signs of growth in 8 fucking years, then I'm sorry you're working for scamsters.

Now I'm not saying that all of them are alike. But most of them sorta are.

They don't give a shit about quality, not one bit. Quality means no money in the short run. And they haven't been able to develop any strategy to deal with that. Hence, no growth.

They promise 100 things on their website but only provide shitty services in 10.

There is no pair programming, no code review, no code quality check, no architect, no database designer. They won't give you extra time to write test cases. They use git as a storage device.

They don't put their developers (especially the ones who are learning) under any sort of managed development framework to ensure smooth work.

At the end of the day, their main objective is to somehow NOT deliver a project but finish a milestone and make money out of it.

After cashing out for a milestone, they want you to put your current project on hold and start working on a new project until you have like 10-15 projects in the pipeline and you're severely overwhelmed and you just wanna fucking QUIT.

They would say YES to literally every fucking thing, only to disappoint the client later.

I can't believe someone in the US, or UK thought it'd be a good idea to approach these companies
for their brand new app ideas. They're so fucked.

They're rarely finishing any project.

I'm sorry if I hurt your feelings. I had to get it out of my system.

Hey guys,

this rant will be long again. I'm sorry for any grammar errors or something like that, english isn't my native language. Furthermore I'm actually very sad and not in a good mood.

Why? What happened? Some of you may already know - I'm doing my apprenticeship / education in a smal company.
There I'm learning a lot, I'm developing awesome features directly for the clients, experience of which other in my age (I'm only 19 years old) can only dream.
Working in such a small company is very exhausting, but I love my job, I love programming. I turned my hobby into a profession and I'm very proud of it.
But then there are moments like the last time, when I had to present something for a client - the first presentation was good, the last was a disaster, nothing worked - but I learned from it.

But this time everything is worse than bad - I mean really, really worse than bad.

I've worked the whole week on a cool new feature - I've done everything that it works yesterday, that everything gets done before the deadline of yesterday.

To achieve this I've coded thursday till 10pm ! At home! Friday I tested the whole day everything to ensure that everything is working properly. I fixed several bugs and then at the end of the day everything seems to be working. Even my boss said that it looks good and he thinks that the rollout to all clients will become good and without any issues.

But unfortunately deceived.

Yesterday evening I wrote a long mail to my boss - with a "manual". He was very proud and said that he is confident that everything will work fine. He trusts me completly.

Then, this morning I received a mail from him - nothing works anymore - all clients have issues, everything stays blank - because I've forgotten to ensure that the new feature (a plugin) and its functionality is supported by the device (needs a installation).
First - I was very shoked - but in the same moment I thought - one moment - you've written an if statement, if the plugin is installed - so why the fuck should it broken everything?!
I looked instant to the code via git. This has to be a very bad joke from my boss I thought. But then I saw the fucking bug - I've written:
if(plugin) { // do shit }
but it has to be if(typeof plugin !== 'undefined')

I fucked up everything - due to this fucking mistake. This little piece of shit I've forgotten on one single line fucked up everything. I'm sorry for this mode of expression but I thought - no this can not be true - it must be a bad bad nightmare.
I've tested this so long, every scenario, everything. Worked till the night so it gets finished. No one, no one from my classmates would ever think of working so long. But I did it, because I love my job. I've implemented a check to ensure that the plugin is installed - but implemented it wrong - exactly this line which caused all the errors should prevent exactly this - what an irony of fate.

I've instantly called my boss and apologized for this mistake. The mistake can't be undone. My boss now has to go to all clients to fix it. This will be very expensive...

Oh my goodnes, I just cried.
I'm only working about half a year in this company - they trust me so much - but I'm not perfect - I make mistakes - like everyone else. This time my boss didn't looked over my code, didn't review it, because he trusted me completly - now this happens. I think this destroyed the trust :( I'm so sad.
He only said that we will talk on monday, how we can prevent such things in the feature..
Oh guys, I don't know - I've fucked up everything, we were so overhelmed that everything would work :(
Now I'm the looser who fucked up - because not testing enough - even when I tested it for days, even at home - worked at home - till the night - for free, for nothing - voluntary.

This is the thanks for that.
Thousand good things - but one mistake and you're the little asshole. You - a 19 year old guy, which works since 6 months in a company. A boss which trusts you and don't look over your code. One line which should prevent crashing, crashed everything.

I'm sorry that this rant is so long, I just need to talk to you guys because I'm so sad. Again. This has happend to frequently lately.

just another day at office
just another code review

On code review .. #itsTrue :)

So a few days ago I shared about the conflict with my colleague on learning React. Today I was let go. Obviously I asked why they would do that and they said they feel the problem isn't even my React knowledge but the fact I don't grasp the fundamentals of OO programming.

Thing is in these 3 months there has not been a single code review. They are either going of what my lying colleague told them (they claimed he was excluded from giving feedback), or the consultants who were hired to help us. And yes, I got feedback I should improve but at the same time the assurance so long as I show improvement it'd be fine. And I was told they could see improvement. So I'm not sure what changed but suddenly there is no budget to keep me on. In any case it feels like shitty corporate bullshit.

But I can't say they are wrong. I struggle to explain simple concepts I know in words. I've worked a series of bad jobs where nobody cared how you did stuff as long as it got done. I feel I'm so behind now and so affected by bad knowledge it's even harder to fix than to learn the first time. So I'm wondering how to fix this.

I'm really gutted too because I loved this company. I was finally getting a fair wage instead of being underpaid. The people were excellent. I felt I could finally relax and feel safe at work. And now I feel betrayed. Which for someone with self esteem issues is very hard. Can't trust in myself and can't trust in others.

I'm gonna try and pick myself up in the morning, but today I feel totally shit. This wasn't how I'd expected things to go. I thought my manager had intended to talk conflicts over but instead I get the boot. And the advice to stop overselling myself. Real useful that. Like it is on me that they hired me despite my subpar interview because my CV looked good. It's a shitty excuse. In any case they're now stuck with a dev that walks out of work, throws false accusations about colleagues, and another person warned me about to not engage because nothing good ever came from it. He's gonna keep over engineering everything and make up for all the time he wastes outside of work creating a dysfunctional environment for everyone. But yeah, easier to fire the new person who does her best despite the odds. And who cautioned against over engineering because we kept missing deadlines. And who believes in refactoring when it is needed because that's how agile works. Yeah better keep someone who has no sense of work life balance and makes others miserable then claiming he's being driven out by your ignorance. And of course the consultants who throw your own people under the bus. Can't get rid of those now.

During a code review I was told that
if(x and y){
if(z){}
}

Will be slower to run than
if(x and y and z){}

I mean if you want to talk about programming practices and uniform code yes absolutely but any compiler will treat these identically, not to mention the assembly being identical. She was a superior though so I just went along with it.

I've started programming when I was 12. Right now I'm 25. I can clearly say that I'm passionate, I've touched I think almost every "type" of programming ever. From game development, through IoT and finished at eCommerce. I never stop learning.

My workmates are pissing me off. For code review sometimes I'm waiting even 3 days when I've changed like 5-6 files. They don't want to introduce "new" technologies (by new I mean who are existing at least 2-3 years, got stable community). They don't want to refactor some core of the application because it's working - they don't care about it as they can later say "legacy system so this basic feature took me a week".

Code quality means for them "use shorthand syntax, this code is ugly" - the basic shit which can do any linter

When I'm doing code review, I'm checking out to this branch, test it, check if the solution is scalable. Then I make my comments. I just hear "stop bitching about it just approve".

Thank God I've made through interview and I'm going to switch job in next week.

When you trying to psych yourself up before your next code review. 🤣

Lessons I've learnt so far on programming

-- Your best written code today can be your worst tomorrow (Focus more on optimisation than style).
-- Having zero knowledge of a language then watching video tutorials is like purchasing an arsenal before knowing what a gun is (Read the docs instead).
-- It's works on my machine! Yes, because you built on Lenovo G-force but never considered the testers running on Intel Pentium 0.001 (Always consider low end devices).
-- "Programming" is you telling a story and without adding "comments" you just wrote a whole novel having no punctuation marks (Always add comments, you will thank yourself later for it I promise).
-- In programming there is nothing like "done"! You only have "in progress" or "abandoned" (Deploy progressively).
-- If at this point you still don't know how to make an asynchronous call in your favourite language, then you are still a rookie! take that from me. (Asynchronous operation is a key feature in programming that every coder should know).
-- If it's more than two conditions use "Switch... case" else stick with "If... else" (Readability should never be under-rated).
-- Code editors can MAKE YOU and BREAK YOU. They have great impact on your coding style and delivery time (Choose editors wisely).
-- Always resist the temptation of writing the whole project from scratch unless needs be (Favor patching to re-creation).
-- Helper methods reduces code redundancy by a large chunk (Always have a class in your project with helper methods).
-- There is something called git (Always make backups).
-- If you don't feel the soothing joy that comes in fixing a bug then "programming" is a no-no (Coding is fun only when it works).
-- Get angry with the bugs not the testers they're only noble messengers (Bugs are your true enemy).
-- You would learn more than a lot reading the codes of others and I mean a lot! (Code review promotes optimisation and let's you know when you are writing macaroni).
-- If you can do it without a framework you have yourself a big fat plus (Frameworks make you entirely dependent).
-- Treat your code like your pet, stop taking care of it and it dies! (Codes are fragile and needs regular updates to stay relevant).

Programming is nothing but fun and I've learnt that a long time ago.

I have a guy sitting next to me in class. We were working on the same project. It's about rewriting a functioning mergesort algorithm in C and doing a presentation about that topic.

Now... the thing is that I was ill on that specific day when we got that project assigned. And he didn't tell me it either. I asked the whole class.
They just said that there was nothing special about that day. These fuckers.

Anyway...
Thé following week we had the same lesson again. Actually there were more than both of us. We were a group of 5 dudes.
3 of them barely have anything to do with programming at all. They just learn for the exams and have bad grades in programming.

Luckily, they already wrote the functioning sorting algorithm.
Since that is the case, I chose to review it to get deeper into that topic.

There were comments in English (we live in Germany) and these comments were written in a different style. My classmates would never comment in such a way.
It was a modified version copied from the internet. The whole source code.
The variables had names like j,k,b,u and so on. It was perfectly obfuscated.

Yesterday, I wasn't at college either.
I had to show up to a given time at a government bureau. They have been working on that project that day. So, I decided to ask them via a messenger, if they can give me the newest presentation files after 1 pm.

They said that they barely have anything to present. They would like to improvise they said.

"Fuck you all" I thought.
I'm done with these fucking illiterate humans.
I hope they all die in hell with satan having a ride on them. Stabbing them from behind right into their assholes and eating their ball sacks (if they have any).

Today is the presentation.
That's when I decided not to drive there during these specific lessons.

Spent 2 hours last night (leaving an hour late) with the IT guy hunting down a problem that affected at least 12 other teams. It didn't crash the app, but did prevent MANY scripts from working, and thus nothing could be committed.
I found the culprit, made a solution, and posted in the email chain my solution. (it required a code review and a client-side update)
Someone responded asking for another dev to confirm my report. That dev did and them dumbed it down for those who can't understand programming talk. Then EVERY EMAIL after that thanked that dev for "fixing the root problem" and "solving their scripts".
And just now, the PO for the bug was replaced to that dev's team. (previously was my team's PO)

Code review, intern style:

Intern: Here is my pull request ...
Colleague: I see a problem with x, y, z. Could cause memory leaks.
Intern: Oh yeah you are correct, i'll fix that in the next one.
Intern: *merged*

Stuff happens...

I prefer pair programming over code review.

So my friend who is currently attending University to major in Computer Science just started programming Java a few days ago. His first assignment was to learn bubble sort and make it organize a table of certain values provided in the assignment with a few other items on the side. Apparently, he was stressing over the assignment and waited till the last night to do this, and was running on 2 hours of sleep. Anyways, a few days pass and he received a 0% on the assignment with the comment "See me on Monday." and questioned what he did wrong (They use GitHub to submit their assignments, even though other classes at the University just commit to the University Server for Computer Science), and asked me to review the code. When I started looking at the code, all he managed to do was just make two tables, one that would print the unsorted table, and then print the "sorted" table. Plus, the catch that got him in trouble, he named his package "fuckthisshit", how does one not realize that when they're submitting their assignments... like seriously? Like I can understand the 2 hours of sleep, but with 1000s of examples out there, how do you manage to fake bubble sort plus end up naming a package "fuckthisshit" and question why he got a 0%. I do feel bad for him in the long run since there aren't many assignments in this class so this was worth 25%.

True story

Not really a rant (?)

I started my first programming job in January this year. I went there staight after Highschool, so i had no real experience, knew only the basics of software development and my written code was quite a mess. So one of my first real tasks (after 2 months) was to write a business logic for batch handling (for a warehouse management system). I invested quite some time to develop a suitable architecture, talked with some other developers and wanted to cover the whole thing with unit tests (which really nobody at the company uses). So I spent about 3 weeks to write the whole thing, test it and improve it many times. It worked perfectly and I got pretty good feedback from the code-review.

1 month ago - the code worked perfectly and was multiple times testet (also by the client) - the client came with some totally new requirements for the batch handling. I tried to impelemt them, but soon found out, that the architecture doesn't supported them, it was not build for the required handling and would soon become a totally mess, if i tried to make it work.

So I was pretty mad, because I had to change the whole fucking thing, but I also wanted to make it better. I hab gained some experience and decided (with some help of a senior dev) to make a completely new try with a different architecture, that can be easily expanded, if needed. I build my concept, wrote and tested the whole new code in 3 days. Fucking 3 days compared to the initial 3 weeks, and it worked, better and even faster.

I was quite pissed to delete the old code, and especially that i had wasted 3 weeks for it and had to struggle with many different things. But I lerarned so much from it and also in the months between, that I was also really glad that I had the opportiunity to write it again.

This whole thing made me now realize that this is, what I really like to do and what I'm good in. I really enjoy learning new things and for me, programming is the best and easiest way to do it. Despite alle the cons and annoying side effects of it, I really found my dream job here.

While it's totally not without its valid use cases, I fucking hate pair programming.

Well, let me elaborate. I hate *remote* pair programming. It completely disrupts my flow and wastes so much time with additional water cooler nonsense, and pedantic argument for the sake of participation. Not to mention "oh hey let me see how you did this... Oh, you know what, I think it would be better to do it this way...". Ok, great, we weren't even discussing that, but sure, let's completely detail this session to refactor something that could have come up at a good transition point, like I dunno, say a code review?

Like I said, there are very good reasons to pair program, but I would much prefer rubber ducking wherever possible.

Agile coach Agiling: We shouldn't need code reviews as long as there is pair programming.

Me Internally: bad code + bad code doesn't make good code :(

Oh shit it's a !rant, if you don't like !rants then scroll past this please.

When out of all my dumb classmates there's actually one that never learned much about programming before going to my school, got interested and is right now developing a library of CLI games... Of course I help him if he has any questions, and I will probably review his code after he's done.

Here comes lots of random pieces of advice...

Ain't no shortcuts.

Be prepared, becoming a good programmer (there are lots of shitty programmers, not so many good ones) takes lots of pain, frustration, and failure. It's going to suck for awhile. There will be false starts. At some point you will question whether you are cut out for it or not. Embrace the struggle -- if you aren't failing, you aren't learning.

Remember that in 2021 being a programmer is just as much (maybe even moreso) about picking up new things on the fly as it is about your crystalized knowledge. I don't want someone who has all the core features of some language memorized, I want someone who can learn new things quickly. Everything is open book all the time. I have to look up pretty basic stuff all the time, it's just that it takes me like twelve seconds to look it up and digest it.

Build, build, build, build, build. At least while you are learning, you should always be working on a project. Don't worry about how big the project is, small is fine.

Remember that programming is a tool, not the end goal in and of itself. Nobody gives a shit how good a carpenter is at using some specialized saw, they care about what the carpenter can build with that specialized saw.

Plan your build. This is a VERY important part of the process that newer devs/programmers like to skip. You are always free to change the plan, but you should have a plan going on. Don't store your plan in your head. If you plan exists only in your head you are doing it wrong. Write that shit down! If you create a solid development process, the cognitive overhead for any project goes way down.

Don't fall into the trap of comparing yourself to others, especially to the experts you are learning from. They are good because they have done the thing that you are struggling with at least a thousand times.

Don't fall into the trap of comparing yourself today to yourself yesterday. This will make it seem like you haven't learned anything and aren't on the move. Compare yourself to yourself last week, last month, last year.

Have experienced programmers review your code. Don't be afraid to ask, most of us really really enjoy this (if it makes you feel any better about the "inconvenience", it will take a mid-level waaaaay less time to review your code that it took for you to write it, and a senior dev even less time than that). You will hate it, it will suck having someone seem like they are just ripping your code apart, but it will make you so much better so much faster than just relying on your own internal knowledge.

When you start to be able to put the pieces together, stay humble. I've seen countless devs with a year of experience start to get a big head and talk like they know shit. Don't keep your mouth closed, but as a newer dev if you are talking noise instead of asking questions there is no way I will think you are ready to have the Jr./Associate/Whatever removed from your title.

Don't ever. Ever. Ever. Criticize someone else's preferred tools. Tooling is so far down the list of what makes a good programmer. This is another thing newer devs have a tendency to do, thinking that their tool chain is the only way to do it. Definitely recommend to people alternatives to check out. A senior dev using Notepad++, a terminal window, and a compiler from 1977 is probably better than you are with the newest shiniest IDE.

Don't be a dick about terminology/vocabulary. Different words mean different things to different people in different organizations. If what you call GNU/Linux somebody else just calls Linux, let it go man! You understand what they mean, and if you don't it's your job to figure out what they mean, not tell them the right way to say it.

One analogy I like to make is that becoming a programmer is a lot like becoming a chef. You don't become a chef by following recipes (i.e. just following tutorials and walk-throughs). You become a chef by learning about different ingredients, learning about different cooking techniques, learning about different styles of cuisine, and (this is the important part), learning how to put together ingredients, techniques, and cuisines in ways that no one has ever showed you about before.

“I apologise for rewriting your code, I didn’t have time to read it.”

- Blaise Pascal

I'm considering quitting a job I started a few weeks ago. I'll probably try to find other work first I suppose.

I'm UK based and this is the 6th programming/DevOps role I've had and I've never seen a team that is so utterly opposed to change. This is the largest company I've worked for in a full time capacity so someone please tell me if I'm going to see the same things at other companies of similar sizes (1000 employees). Or even tell me if I'm just being too opinionated and that I simply have different priorities than others I'm working with. The only upside so far is that at least 90% of the people I've been speaking to are very friendly and aren't outwardly toxic.

My first week, I explained during the daily stand up how I had been updating the readmes of a couple of code bases as I set them up locally, updated docker files to fix a few issues, made missing env files, and I didn't mention that I had also started a soon to be very long list of major problems in the code bases. 30 minutes later I get a call from the team lead saying he'd had complaints from another dev about the changes I'd spoke about making to their work. I was told to stash my changes for a few weeks at least and not to bother committing them.

Since then I've found out that even if I had wanted to, I wouldn't have been allowed to merge in my changes. Sprints are 2 weeks long, and are planned several sprints ahead. Trying to get any tickets planned in so far has been a brick wall, and it's clear management only cares about features.

Weirdly enough but not unsurprisingly I've heard loads of complaints about the slow turn around of the dev team to get out anything, be it bug fixes or features. It's weird because when I pointed out that there's currently no centralised logging or an error management platform like bugsnag, there was zero interest. I wrote a 4 page report on the benefits and how it would help the dev team to get away from fire fighting and these hidden issues they keep running into. But I was told that it would have to be planned for next year's work, as this year everything is already planned and there's no space in the budget for the roughly $20 a month a standard bugsnag plan would take.

The reason I even had time to write up such a report is because I get given work that takes 30 minutes and I'm seemingly expected to take several days to do it. I tried asking for more work at the start but I could tell the lead was busy and was frankly just annoyed that he was having to find me work within the narrow confines of what's planned for the sprint.

So I tried to keep busy with a load of code reviews and writing reports on road mapping out how we could improve various things. It's still not much to do though. And hey when I brought up actually implementing psr12 coding standards, there currently aren't any standards and the code bases even use a mix of spaces and tab indentation in the same file, I seemingly got a positive impression at the only senior developer meeting I've been to so far. However when I wrote up a confluence doc on setting up psr12 code sniffing in the various IDEs everyone uses, and mentioned it in a daily stand up, I once again got kickback and a talking to.

It's pretty clear that they'd like me to sit down, do my assigned work, and otherwise try to look busy. While continuing with their terrible practices.

After today I think I'll have to stop trying to do code reviews too as it's clear they don't actually want code to be reviewed. A junior dev who only started writing code last year had written probably the single worst pull request I've ever seen. However it's still a perfectly reasonable thing, they're junior and that's what code reviews are for. So I went through file by file and gently suggested a cleaner or safer way to achieve things, or in a couple of the worst cases I suggested that they bring up a refactor ticket to be made as the code base was trapping them in shocking practices. I'm talking html in strings being concatenated in a class. Database migrations that use hard coded IDs from production data. Database queries that again quote arbitrary production IDs. A mix of tabs and spaces in the same file. Indentation being way off. Etc, the list goes on.
Well of course I get massive kickback from that too, not just from the team lead who they complained to but the junior was incredibly rude and basically told me to shut up because this was how it was done in this code base. For the last 2 days it's been a bit of a back and forth of me at least trying to get the guy to fix the formatting issues, and my lead has messaged me multiple times asking if it can go through code review to QA yet. I don't know why they even bother with code reviews at this point.

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

I just realized that in my company , the code review is not important.... And the source code is fucked up.... The structure is like functional programming and Oop combine with redundant function everywhere.

And in the source code there's a folder called depreciating service , I asked them what is that , they told me it is the service previously but not recommended for using it.

I was like "you mean deprecated"? Omg

They don't care about code review and clean code here.

My struggle here is they dare to create one class for the entire project and every code are in that class...
This is fucking not acceptable.

our team are responsible to build backend restful API for other team to look up data in DB.
the consumer team just sit beside us.
the interface definition came from our pm in a different time zone. btw he did not have any programming background.
and he insisted that just build what he said and ignore the noise from the consumer team. because each interface change should be considered as new features and need him to prioritize and create user story and he will review the schema with the pm from consumer team and so called architecture who did not coding real shit for years.
we ended up with building shit code not useable by our real consumer.
yes he do manage to keep our team busy building worthless shit and accomplishmented lots of jira items to show we have value to change a useless shit into very hard to use shit

Why comment on the same thing during code review??

I submitted a PR and had to make a design choice that propagated throughout the module i was working on.

During code review, my coworker commented on every...single...line that this change effected asking "why are we doing x here?" instead of just creating ONE SINGLE THREAD with this question for discussion. There were at least 10 review comments on github from their one review that said "why X?"

Is this normal? Ive only had a few programming jobs and this is the first time this has happened to me.

personally, when someone makes a choice like that, i just make a comment and save the rest of the review until that is addressed.

How to disconnect from work after working hours? Im working for the last 4 months as a mid level dev in this company. I mean Im able to problem-solve and do my work but sometimes I get so addicted to problem solving that I get worried and become obsessed, hyperfixated (especialy if Im stuck on something for lets say a couple weeks). It goes to the point where I work from home 12-14 hours a day just to figure out some bug in the flow.

Thing is, our codebase is large and when doing every new refactor/feature some surprises happen. I dont have a decent mentor who could teach me one on one or even do pair programming with. All i have is just some colleagues who can point me to right direction or do a code review from time to time. Thats it.

I dont know why I take this so personally. For example I had to do a feature which I did in 1 week, then MR got approved by devs and QA. After that during regression they found like 3 blockers and I felt really bad and ashamed. While in reality our BA did not define feature properly, devs who reviewed it didnt even launch the code and poke around in the app, and our team's QA tested only the happy scenario. Basically this is failing/getting delayed because of a failure in like 6-7 people chain.

However for some reason Im taking this very personally, that I, as a dev failed. Maybe due to my ADHD or something but for the next days or weeks as long as I dont find solution I will isolate myself and tryhard until I get it right. Then have a few days of chill until I face another obstacle in another task again. And this keeps repeating and repeating.

My senior colleague tells me to chill and dont let work take such a toll on my emotional/physical/mental health. But its hard. He has 7 years of experience and has decent memory. I have 2-3 years of experience and have ADHD, we are not the same. I dont know how to become a guy who clocks out after 8 hours of work done everyday. Its like I feel that they might fire me or I will look bad if I dont put in enough effort. Not like I was ever fired for performance issues... Anyways I dont know how to start working to live, instead of living for work.

I hate who Im becoming. I dont work out anymore, started smoking a lot, dont exercise. I live this self induced anxiety driven workaholic lifestyle.

Good code is a lie imho.

When you see a project as code, there are 3 variables in most cases:

- time
- people / human resources
- rules

Every variable plays a certain role in how the code (project) evolves.

Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.

Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.

Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.

People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?

Too many people working on one thing is only bad when there are no rules ;)

Rules. There are two different kind of rules.

Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.

Coding itself. This is a very critical thing.

Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.

Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.

Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.

Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.

If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.

Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.

There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.

Good code is a lie - because it can only exist at a certain point of time.

A codebase should be a living thing - when certain parts rot, other parts will be affected too.

The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state

After three months of development, my first contribution to the client is going live on their servers in less than 12 hours. And let me say, I shall never again be doing that much programming in one go, because the last week and a half has been a nightmare... Where to begin...

So last Monday, my code passed to our testing servers, for QA to review and give its seal of approval. But the server was acting up and wouldn't let us do much, giving us tons of timeouts and other errors, so we reported it to the sysadmin and had to put off the testing.

Now that's all fine and dandy, but last Wednesday we had to prepare the release for 4 days of regression testing on our staging servers, which meant that by Wednesday night the code had to be greenlight by QA. Tuesday the sysadmin was unable to check the problem on our testing servers, so we had to wait to Wednesday.

Wednesday comes along, I'm patching a couple things I saw, and around lunch time we deploy to the testing servers. I launch our fancy new Postman tests which pass in local, and I get a bunch of errors. Partially my codes fault, partially the testing env manipulating server responses and systems failing.

Fifteen minutes before I leave work on the day we have to leave everything ready to pass to staging, I find another bug, which is not really something I can ignore. My typing skills go to work as I'm hammering line after line of code out, trying to get it finished so we can deploy and test when I get home. Done just in time to catch the bus home...

So I get home. Run the tests. Still a couple failures due to the bug I tried to resolve. We ask for an extension till the following morning, thus delaying our deployment to staging. Eight hours later, at 1AM, after working a full 8 hours before, I push my code and leave it ready for deployment the following morning. Finally, everything works and we can get our code up to staging. Tests had to be modified to accommodate the shitty testing environment, but I'm happy that we're finally done there.

Staging server shits itself for half a day, so we end up doing regression tests a full day late, without a change in date for our upload to production (yay...).

We get to staging, I run my tests, all green, all working, so happy. I keep on working on other stuff, and the day that we were slated to upload to production, my coworkers find that throughout the development (which included a huge migration), code was removed which should not have. Team panics. Everyone is reviewing my commits (over a hundred commits) trying to see what we're missing that is required (especially legal requirements). Upload to production is delayed one day because of this. Ended up being one class missing, and a couple lines of code, which is my bad (but seriously, not bad considering I'm a Junior who was handed this project as his first task at his first job).

I swear to God, from here on out, one feature per branch and merge request. Never again shall I let this happen. I don't even know why it was allowed to happen, it breaks our branch policies. But ohel... I will now personally oppose crap like this too...

Now if you'll excuse me... I'm going to be highly unproductive and rest, because I might start balding otherwise after these weeks...

February will be the first full year at this company as full time employee.

I've updated so many legacy projects, optimized a lot of workflows as well as built new tools to improve efficiency and remove unnecessarily duplicate projects (sometimes literally only 3 variables were different between multiple projects)

My one co-worker taught himself enough code to do the job but doesn't think like a programmer though he is asking me for help and advice to improve what he does since ive proven i know a little. my other direct co-worker I'm practically teaching a Programming 100 course to them

My direct manager at one point said he was so happy he took a chance on me even though I didn't interview well

I like my job, I find it so much better than my last job which was horribly toxic, and more fun than my first 'real' job as a night shift help desk for basically a warehouse environment.

But I feel under paid sometimes for how much i do and all ive improved in my first year, I have my first yearly review coming up. I'm hoping to get a decent raise for all ive done and I want to somehow go over everything with the HR person to justify it. But I have no idea how to talk about my dev work to them in a way a non technical person could understand. I'm also not sure how the review process will work. Like will my manager be there. Or is it just me and HR, is there a paper I'll be sent to fill before hand,

A new job position in programming is going to crop up if programming tools can be created to replace lower tier programmers. It will be a programmer that can manage AI Programmers. Some kind of AI Manager that can sort through, direct, and review code written by code generators. I cannot imagine the shit this person will have to wade through.

I have kind of been put in charge of software development in one department of the company I work at. Only myself and a developer in the IT department have ever done programming as our main jobs and follow formal processes. The issue I am having is I don't know how to approach some co-workers assisting me part time with programming to tell them the code they wrote needs major refactoring. Just after a short review there are hundreds of lines of duplicated code and code that is duplicating features built into the framework etc. I just hate conflict and don't know how to tell them we have a lot of work to do. Any advice?

XXXX programming language does not scale. Nope, it is your code. Review your code and improve it! Don't add more hardware to improve performance, that solution just covers the problem. Review, review and review

What are the most important factors for you while doing code reviews ?

Learn git. Contribute to open source projects - you may learn more from code review on a single PR than from a whole tutorial. Ask questions constantly. Learn more git. Look for the cleanest solution to a problem. Write code that is easy to improve, easy to expand, and easy to debug. Learn even more git. Don't limit yourself to thinking only in terms of OOP, or functional, or procedural, or whatever type of programming you may be comfortable with. Don't be afraid to do some work by hand. Learn git, so that when all comes crashing down and your team crumbles to pieces, when your relationships fail and your friends disappear, when you're down on your luck and there truly is no hope left in life, you can check out of the dangerous world of your current HEAD and return to the home and comfort of your master branch, which you've kept safe, secure, and functional.

Code code code until you make the code look like you haven't seen a code like you have coded!

Agrrr... I hate to do code review of that shit! I hate to write docs for that shit! I hate to talk to PM! I hate dumb developers!
But there are several things about programming that make me calm and happy. When I'm thinking about one of those things I just sit and smile.
One such a thing is the process of upgrading gcc from sources.
1. Build new gcc with old gcc.
2. Build new gcc again with newly built gcc. Call this build A.
3. Build new gcc once more with build A. Call this build B.
4. Compare that A and B are exactly identical to the last bit.
5. You now have self reproducing compiler.
That is just beautiful and literally gives me chills.