"Don't solve tomorrows problems because you don't know what they are". Beautiful.

Dining-Kroger effect is when I go to the grocery store to buy a side dish for dinner, but leave with a Kroger rotisserie chicken instead.

This article is written by a business major who accidentally fell into IT.

So much focus on the programmer(s) here, when this is clearly 99% an issue of management. Who is approving these programmers' project plans? Who is challenging their tech stack? Who is signing off on their pushes? Who is either not soliciting, or outright ignoring, the feedback of the rest of the coding team as the complexity keeps rising?

I think the most healthy mindset a programmer can possibly have is basically how can I solve the problems at hand effectively (note: without solving tomorrows problems as well) with as little code and as few dependencies as humanly possible WHILE imagining that I will die in a car crash tonight and a junior dev straight out of school is going to take over the project tomorrow.

This reminds to how German General Hammerstein-Equord categorized people: There are smart, dumb, hard-working, and lazy people. If someone is smart and hard-working, this qualifies him for the General Staff. Some people are dumb and lazy, these are qualified for routine jobs. If someone is smart and lazy, this qualifies him for leadership positions as he will not lose his nerve easily. But beware of those who are dumb and hard-working as they will only do harm.

This is something of a problem in the interview process. We interview front-end devs as if they're building rocket ships or are budding mathematicians when their actual job is going to involve either making web pages or "web applications" (application software in drag.) It's no surprise you're going to end up with over-engineered nonsense if your interview selects for people who are going to churn out overengineered nonsense.

Summary of the article: "The worst programmers are those who are better than me, because they make me feel like a noob".

Any article that unironically says that passionate and hard working software engineers are a red flag is in itself a red flag. It sounds like this team needed a better engineering manager. And if the author was that guy then the author needs to find a new career path.

I kind of get it. Some of the worst developers are talented and motivated people who just lack experience and don't hava a senior to guide them. Without guidance they will come up with lots of smart but complex solutions to simple problems.

Oh I remember this article! The guy missed completely. I believe he wanted to point at people who don’t stop to reflect, or like you said more generally lack wisdom. He seems a bit blinded by envy to me, in the end he described passionate engineers who took risks in doing what they believed was right. Agree 100% with your take here.

I think the most important line in that article is when he says "the rest of the team was happy to slack off while requirements were in the works". In any team, there will be a spectrum from hyper-productive people who can't stand to do nothing, to glorified bureaucrats who are happy to have endless meetings and alignment discussions. If you let the culture develop more towards the latter, you turn most of your developers into slackers, but the hyper-productive ones are going to work to solve for their particular idea of the future, while most of the team is planning for a hypothetical one, and everyone loses grip on what is actually being developed in the present.

5:00, really agree with this one. "An idiot admires complexity, a genius admires simplicity" -Terry Davis

this was written by a malding scrum master

Dude I'm so split on this. It's like this article just externalized my internal monologue. I write fancy things to learn stuff, and I try to find excuses to use them at work. So far though, I've only been allowed to build things with technologies I deeply dislike despite their status as industry standards. In so doing, I've been very humbled by how quickly complexity can escalate in allegedly "simple, well-supported" solutions like Node and React when there are too many requirements to balance within a single mind. I became a lot more aware of what teams are for and how the diversity of perspectives can avoid those complexity wormholes when I started pulling my colleagues in more closely who had previously just mostly left me to it (which is why I kind of agreed with this article about the late 20's early 30's bright guy effect). I love learning, but that is mainly because it increases my confidence and helps me feel more competent. Therefore, competence is the real goal for the learning. Performing effectively and efficiently can achieve the same goal and will probably help more people in the process. Good article even if it asserts some things that we can agree to disagree on.

Oh man. Totally had something similar happen. My boss put a lot of trust in the guy that had been at the company longer than I had on a new project (makes sense). It was mostly a data entry tool for an insurance client of ours. He came out of the depths a couple months later with this cobbled mess of MS MVC Framework, MS Entity Framework, and OG Angular JS. All of our data was stored behind stored procedures... unless it wasn't. It was a MVC(UI) framework on top of a MVC framework (Server) on top of an ORM (sometimes). The guy left a week after he came up from air from this. My boss thought I was an idiot for not being able to easily extend any of it, the guy was "good" and "really smart". I was just dumb an inexperienced. He got so fed up with my lack of productivity that he called in a friend of his that did some contracting/consulting work for him sometimes. Really "good" and "really smart". I must have spent at least 3 weeks going over how everything was cobbled together. End result: This contractor showed up as an employee at the company I had eventually moved to.

BTW: Starting too simple, specially with the DB model, can give you a headache in the near future. It's easy to refactor code, it's very hard to refactor your DB, specially if you have a zero downtime goal.

This article be like > observes people who are productive and passionate and also don't know when not to use the latest hype technology > concludes that being productive and passionate is a flaw Like, sure, being productive and passionate are prerequisites for being able to turn the real problem into a serious problem for others, but that's just because being productive and passionate increases the amount of anything, good or bad, that you do.

This whole article can be summarized as: be mediocre, hate your life never dare to enjoy your job

This is one of your best commentary videos IMHO. Loved it. :)

It's interesting how the carefully written article with the tendency of making it sound very processional, can give you a lot of wrong ideas. I mean people that the guy in the article has described literally carry the company, especially on critical times. Management never calls these shallow philosophers to solve a critical production bug, these developers who are looked in the wrong way today are the reason things work. It's amazing how programming has been commercialized as such a level that a highly skilled, proficient and critical thinker is treated like an obstacle for the business.

My opinion. Start stupid, make it work. Take refactoring and testing into account for your estimation. Find common pieces of code, do whatever 'magic' (abstraction, common methods etc.) that is needed to it in a way that still makes sense. Don't fall for premature optimization. Only do it if you know you know right away it will have a significant performance boost. Always consult your team about decisions that have impact. Get juniors working on the code base. Write tickets for them and review their work. Support them, explain everything they need to know about the project and guide them with your knowledge, they are the future of the project and the company.

13:30 I think this boils down to the existence of two kinds of managers: The ones who you barely see and (when talking about on-site work) are probably not even in the same building as the team they are managing. The ones who actually meet the people they manage regularly.

Your rebuttals/commentary on this article is on point and relatable af. I also wrote a lot of shitty code at 21 and still do, but now I know how shitty it is when I write it and only do it when I know I can go back later to refactor. Writing that shitty code in the past let me gain experience from burning myself enough times on the bad practices to know I should work better practices in earlier on. And as someone on this platform once pointed out to me, who really has time (or funding) to refactor these days? So hopefully your work allows you to take the time to learn and improve on your current and past projects

I use semi-colons in Python

The inverted contentious points all points to management issues. Attacking the core skills of software engineering and trying to turn *engineers* into managerial cogs is a deep misunderstanding about the very role of management which is to *moderate* between two worlds. NOT forcing one onto the other. Management issue. again. Just hire GPT and enjoy the low-code life (but remember to inflate your cybersec and QA teams)

The Dumbing Kruger effect - making sweeping generalisations that bear no relation to the point your making. The author might as well have included star signs and diet as signs to be wary of. The root cause of this is a combination of inexperience and wilful ignorance across the team.

Being able to scale work out to multiple contributors of varying skill levels is extremely valuable. Engineering something to be as simple and easily updatable as possible is the ultimate goal and worthy of respect. Sometimes with simplicity comes rigidity, but creativity also shines even with constraints to adapt to most problems. As engineers, pride, ego, and not liking teamwork need to be put to the side. A good engineer does what is necessary to deliver, as optimally as possible. When you start seeing good human interaction and collaboration as ways to increase productivity and scale work out, it becomes easier to work on those aspects of yourself. They are just new skills/tools to better deliver on your project and further advance yourself as a person and your career.

This is a great perspective article. If you do majority of the work in your organisation you seriously need to think if what you're writing will be workable by your coworkers. Now you may scream skill issue hearing that take but the truth is that you cant control the hiring of your coworkers most of the time they're already there. Being hard on them will do them no good because unlike yourself they're probably normal people wanting to do normal jobs but they found themselves in the hellhole called IT and are probably just scraping by, or unlike yourself work life balance might matter to them and they just can't sit and learn all the time in their time off.

Primeagen version: "A superior pilot is one who uses his superior judgement to avoid those situations that would require the use of his superior skill." Article version: "Let's see what I can make this plane do today."

“Focuses on the process, not the outcome”. That results in exceptions that prevents automation. Prime example is when the process isn’t followed in an ERP for, say, Inventory Management. At my old job, which was in Aerospace, we regularly bypassed the process we were supposed to use in the ERP to issue parts to assemblies. It resulted in the serial numbers actually used not matching what was issued in the ERP for that assembly. We had paper “routers” where all the SNs were correct, so we technically met traceability requirements, but it made it an absolute pain in the ass to trace parts. What should have been an easily automated task (finding where a SN was in our system) became a logistical nightmare because management said “stop being so obsessed with following a non-safety related procedure. It’s the results that matter”. They were right that it wasn’t safety related, but it made it absolutely impossible to trust the system for certain tasks that could otherwise have been automated

In some sense this article makes sense, I have been with a group of people who were so focused on the tools and trends that they forgot what this entire thing was about , it was the project that needed technical solution. The senior engineers I worked with presented me with solution only for me to find out it was the actual problem. Things only can move so far ahead into the future being loose chain. Having wisidom to know when to do something is the best a programmer can be.

This describes exactly a project I've been in. They also used Rxjs. And yes debugging was hell. I personally love solving bugs, especially if they only occur kind of random. I had to debug one in that project with rxjs. Damn that was hard. Until this day I don't know why anyone would use it.

The article hints.. nay, it kinda flies over some valid issues at 10,000 feet, but draws the wrong conclusions: by all means have your basement dwellers who can bootstrap their own OSs on the floppy controller of a C64, but know that there's a reason you keep those in the basement, away from normal people. Doesn't mean they're not valuable or even indispensable; they're just not to be watered after dark.

Most sane JDSL enjoyer.

We all start off cocky and stupid and the only way we learn is by suffering the consequences of stupid. So sadly I think this will be an eternal source of "reminders" not to be stupid. Now excuse me while I go create another reminder.

Written by: The manager who actually failed this project

I'm happy this article got published. Opens up an amazing discussion. Great criticism from ThePrimeTime!

I am extremely new to the world of programming. Wanting to get into mobile development and picked swift as my first language. I’m listening to as much programming videos and trying to get familiar with the terminologies and I came upon this video. Even though I am only understanding maybe 10 percent of what you are talking about, I about died laughing around the 16:02 timeframe.

I hate how people aways want to make the argument that being smart and capable leads to these bad habits. The issue is not smart people being "too smart" or "overengineering". The problem is bad engineering, bad practises and quite likely non-technical management misidentifying talent. I haven't worked in a traditional software design environment but I deal with a very similar situation rife with anti-intellectualism. Generally most of these people really were never very good they just baffle people who are extremely Junior or have no idea what they are doing, or they are super bright but lack experience and just go with trends they see online and push to generate more and more. Anyone can pick a fancy new technology they read about on the Internet and then start producing insane amounts of terrible code. The manager should have known enough about software engineering to prevent these problems. The team should have had other capable people who could have called bullshit. The project as a whole lacked a sufficient critical mass of educated and talented people. If highly intelligent people ruin everything all the time then how did Carmack produce what he did at id? Why do major software companies select people using IQ? The answer is because everything else you need can be taught and that is the best predictor of productivity where productivity is about getting meaningful work done not just generating trash code.

We had RxJs on the back end in a project I was in. The back end lead insisted that Rx was a really nice way for him to structure his code. I've never hated using a library more in my life. Everything was an observable. Even simple control flow was a pain. Then, it was a huge pain to use other libraries with it. Run the other way if you see Rx

13:50 You don't have to adapt your speech when talking to children. Children arent as stupid as most adults think. You don't have to change your voice, you don't have to talk slower. As long as it's not highly technical, you just talk to kids as you would talk to any other person. And if something is too complicated, you explain the details. Just like you would when talking to adults.

KISS: "Keep it stupid, stupid"

Someone once said that people's understanding of the Dunning-Kruger effect is a perfect example of the Dunning-Kruger effect

> if you try to cram the hot overcomplicated tech into a project, you are a fool Proceeds to do a project in Rust

I was kinda with the article until the scrum praise.. We're just in the process of removing most scrum rituals (-standups -grooming sessions) and I can't be any more happier about that. Can't say I've seen any drop in productivity, even among the junior team members (there's just more Slack discussions) and I can't say that scrum had prevented the whiteboard masturbation even one time, more like there was just a wider audience.

Concur on the selection bias naivety. It's also a problem when a person can't differentiate between correlations and causations. Then we get a horrible cycle of blame that completely misses the mark.

Agree with Prime, working hard and caring about your work are NOT red flags. Competent people with these attributes will be your top performers all day.

His error WRT Duning-Kruger is that he's effectively saying smart people who are bad at things overestimate themselves more than regular or unintelligent people who are bad at things. The non bright people will be worse than the bright people he's targeting. first result from google: "The Dunning-Kruger effect occurs when a person's lack of knowledge and skill in a certain area causes them to overestimate their own competence. By contrast, this effect also drives those who excel in a given area to think the task is simple for everyone, leading them to underestimate their abilities." A bright persion will develop knowledge and skill faster... That's what being bright means...

I think I understand the idea of the article if you see it in a more abstract sense; you need to optimize your code in an organization towards the kind of programmers you hire - and you need to optimize the kind of people you hire towards the code that you have. Ofc. it's bad if it's only a few people that can really develop new features correctly in the codebase, but more abstract (and complex) methods can be very fruitful, if you know what you are doing. I.e. as you said, wisdom is essential.

I'm working in a very small company. Last year we took over exactly one of this projects. In total we were 2 people trying to work in a codebase which was already sprinkled with workarounds from the developers before who either tried to fill gaps in their framework or didn't understand what they were doing.

I am stupid

"I don't want your monoids, you can go endo-fuck off" might be my new catch phrase as a Haskell dev

really enjoyed this article

Are you struggling with RXJS? how to debug RxJS? put a tap with a console.log after each step. Not receiving anything? verify if you're subscribing. If you are subscribing, you're probably messing up some filter or maybe some "mergeMap" maybe is messed, basically, look step by step and you will find it.

I don't know, this article comes off to me as really whiny. The problems the author identifies are legitimate, but the conclusions about where those problems are coming from and the solutions are completely off base. I don't see how management failures such as lack of team cohesion and underutilization of team members is the fault of the high performers. Management failures are management failures. Then again, I am a student who has never worked a day in industry so maybe I just have no experience to be talking about this.

This is one of the takes of all time. I tried to give it the benefit of the doubt. Prod at where it's coming from. But it genuinely just seems super bitter, while praising all the wrong things. Scrum would be a solution to what he's suggesting, but that's because scrum implicitly requires someone to micromanage everyone, and who in their right mind wants to be micromanaged? I agree, if you allow the smartest most passionate people in the room to go out and just do literally whatever they want without any accountability, that can quickly become a problem. At the same time if you don't allow them room to experiment, and heavily micromanage them, you'll never know if there actually was a better solution out there to the problem. It takes a pretty knowledgeable team lead to be able to pull the reins back the right amount. Where people don't love you, but also don't hate you. Just sounds like the problem is that management never even tried to pull the reins back. Which admittedly, is probably a problem at a lot of small software companies. There's no one with the technical knowledge & will to pull the reins.

prime I don't know how but you post the perfect video for my situation 😂. few days ago I was so stressed about my job and then you posted reaction video of neetcodes. Now i was trying to solve a future problem creating a monorepo (nest.js, react.js, shared types) i was unable export the shared types to both nest.js and react.js (because of module type). now im gonna remove the shared types repo 😂

The problem with being able and willing to put in many hours of work is that the additional hours are usually used for firefighting and making things operational rather than building a proper viable solution. This has the consequence of management never understanding the seriousness of the current state of the system until the key person that keeps the lights on leaves. Furthermore the extreme efforts of single individuals is often used to bully or pressure other employees to work more without taking into account that they might be in different life situations. I have been a 50+ hr/week employee for years, but I have always made it clear to management that it was unacceptable to put pressure on people who couldn't deliver that amount of time and I have seen the consequences of people working closely with people who did not care about this pressure.

The cause of the Dunning-Kruger effect is the fact that the skills one needs to accurately appraise ability tend to be roughly the same skills that one needs to have the ability. When you couple this with the human tendency to prefer a narrative that bolsters confidence rather than one that challenges it you get the symptoms described by the effect. This is because normally for a person with some experience in an area they would have lots of information and feedback to argue against their own self-bias. When you have a novice they lack that knowledge that helps to temper their ego. As an example you might write something that runs as a novice and think "wow I'm so great". If you write that same thing as a pro you'll probably say "yeah it works but I've used stuff that works way better". I'd guess this probably is a little more common in youth as that can be a common reason for a lack of experience but it would be foolish to look at that as axiomatic. Any one of any age will have some corner of the world that they think they know better than they actually do and will probably never find out otherwise.

Scrum is good if you do it by the book. Most shops don't do Scrum well. For example, the ones that do story points. The focus should be on Value and Goals.

Omg, I can relate to this Angular debacle so well. Thousands of lines of code in one single component, intermixed with absurdly excessive amount of JavaScript and any types, convoluted data fetching, spaghetti test cases, it was good times running through all of these😄

I've been binge watching your content, especially evident in this clip is the lack of experience in non-web related projects. For example, I design automation and test & measurement systems. I relate to most of your logic and experience. Realtime (large systems ), safety critical tasks, high throughput, and traceability and management of limits are fascinating fields, and none of them use JavaScript, Rust, or any ot these new programming languages . Yet still, I love learning what's happening in Web/Internet domain and evaluating what I can bring over to my daily life.

My issue with Angular or many such complex front ends is that once they go sideways for one reason or another, you are rewriting the whole front-end application from the ground up.

Hey Prime, longtime lurker, first time commenter. Regarding that topic of wisdom and how to use it - I did this presentation once about how to approach code at work. I identified 3 step process to writing good code. 1. (using your) Intelligence - e.g. find the smartest solution to cover all possible cases 2. (using your) Wisdom - e.g. find the stable solution that covers most cases. 3. (using your) Knowledge - e.g. find the optimized solution that covers all cases in least amount of code. I think each of these steps as a refactoring approach, and in a way it's very similar to how "try/catch/resolve" works. As the famous saying says, "If at first you don't succeed, try try again" aka keep refactoring. On another topic - team leads - one important skill you need to have is the ability to delegate. You literally get your own coding minions to do as you whim. Use them, don't waste your own resources.

man the little edits with the music and quotes got me laughin wild asf💀 love it its hilarious

Meanwhile at my company, team manager forced scrum onto us, basically everyone is fullstack, everyone has to do devops and everyone was forced to get a microsoft certificate for those things.

Your videos are always the best💯 I do receive a notification each time you post a new video.. We'll have regrets for things we did not participate in...Investment should always be on any creative man's heart for success in life.

I think every dev should climb the Kubernetes mountain one time, because it's good for devs to get exposed to many kinds of software that's well-designed for what it does.

I never worked in a large team of programmers, but I always follow the belief that you should write your code like you want to inherit it. If there's a complicated piece of code, wrap the statement in a function name that makes sense. Build your code around tests and document what it does. Refactor constantly. Remember that 6 months from now you won't remember what you were doing. When using a library/framework avoid the latest and greatest and build on industry standards because they'll probably still be around in 5 years. Angular made some sense at the time (since it's Google) but React seems like the one to use right now in corporations.

Not having time to learn something new or just master something I already know on some basis ..... this is a struggle I am fighting with every fkn day... But having two kids which participate in 6-7 outclass sports, courses, etc. not only that keeps me away from learning something new but also makes me squeezed like a lemon at the end of the day when I lie to myself that I will at least give 30 minutes before bad to read something and I just end up sleeping with my laptop on me :D

this kind of programmer only exists because JS is disorganization-oriented

the one for the biggest issue that we have with senior developers - is that we (the industry) consider them as "senior" by the amount of technologies that they have in CVs and their ability to pass interviews. a developer should be considered as a senior and gets a lead position only when he can prove, that he can really DELIVER a robust and maintainable solution. there is a HUGE difference between delivering/finishing project and writing/designing code. we need a kind of reputational and recommendatory institution like doctors and lawyers. the mentality "play with new technologies and run away" should not be welcomed.

I came in expecting to hear a self description. Immediately had no idea what it was talking about, felt better.

8:40 oldmanjudo has my heart. "I need to spend about 10 hours a week learning stuff or I start to really hate my existence kind of a lot." Add that to the things I did not know before diving into this rabbit hole that is software development 1. You will lose hair 2. Software becomes an addiction and the withdrawal is hating your existence 3. Try not to increase dosage otherwise the withdrawal crash is worse. As much satisfaction you get when you pour your heart and mind into very challenging problems is as much dissatisfaction you get when you inevitably have to go back to your life and stop working 14h a day. 🐼🐼🐼

That's what happens when STEM businesses refuse to hire and pay for veteran professional engineering expertise. Tech will have their version of the airplane-emergency-door-flyoff incident one of these days. The consumers and the society as a whole would be thier biggest vicitims.

I can't stand it when management wants us all to do DevOps... I don't care about that stuff, that's for the ppl who like that stuff. I enjoy programming both front-end and back-end.

I think I'm due for some introspection. Glad I watched that video now as I'm still studying and not in five years.

One of the best takes on SWE. Use the right tool for the job, and sometimes that tool is going to require a skill curve. I've recently been digging into Rust and there's a point where you finally understand why you should never write a single `.unwrap()`. My brain had to look at programs a completely different way and now I feel like I can solve a whole new domain of problems.

editing on point today flip

This author is a champion of mediocrity. Hire all-stars. Cut those who can't perform.

I find the take the article has about devops very fascinating: "Don't make team members do something they are bad at so that they learn, make them do it so they feel stupid." I feel like the article was written by a devops guy who feels stupid for not being able to understand what others are doing and refuses to learn, so blames them instead for "writing to complex code".

You can get caught up on insignificant details both out of passion and fear. This is why I have a personal todo list. Working within and managing large projects, knowing what to prioritize and knowing how to properly work together with other people, is experience.

this hurts because im the 'do all of it' guy because no-one is skilled enough or interested in running things efficiently or securely. and while I do all these, I still think im a noob.

That whiteboard session meme was delivered straight into my brain. Love it.

To me this just sounds like trying to defend the garbage-can of web development in some companies where they only hire bunch of noobs and like 2 average people... There was a guy who owned a business and without jokes asked how is it that "all programmers always say all codebase is shit and need rewrite" - even though they are after the 6th rewrite of the whole and like 4th team completely exchanged. And guy seriously could not spot that the only stable thing in all those versions in himself and probably full shit management style lol.

my boss forced me to use bazel on a service that had just 2 endpoints. the project was supossed to take less that a week. it took almost 2 month with no added benefits whatsoever. And now it the base template since we make such services a lot so basically just me and him are the only people who understand whats going on and we are both planning. the companies budget is so low that they can only hire junior devs.

Dude. This was awesome! 👌

Classic example of an entitled Zoomer misidentifying the issues while working under dev's that should have never been team leads.

why does prime think he is one of us, we actually suck he pretends to suck for memes.

This channel has a high level of meta-analysis of software engineering I subbed. Edit: Truly I don't agree with this guy and his articles I think it's highly ironic, but his exp is valid and the meta-cognition he makes on software engineering provides the viewer multiple personal questions.

Something that I've learned with time is to apply KISS; it's something becoming too big of a monolith? Guess what, split it and KISS. Yes yes, it'll be more complex to look at it at first glance, lot's of services, "oooohhh scary". But, you can allow a Junior to be responsible for one of those services and the project will still be working if it fails; you just need to document the flow of things.

I feel like a dUck 99% of the time but i implemented all kinds of stuff in C/C++ like a small nginx or a small shell or wolfentstein3D from scratch and containers like map stack vector etc what ppl say about C/C++ makes me feel pretty good about myself for a minute 😂 thanks for that haha

I don't agree that you're blaming rust being self centered on skill issues of programmers. I mean I absolutely love rust, but I know where the author is coming from saying that golang is a nicer language here. You can't dismiss the point he's making by saying it's a skill issue, because in that case the inability of people to write safe code in C and C++ is also a skill issue. I think of programming languages as tools, and if I need to learn how to use a tool for a long time, that's a bad tool. The best tool is the one you can use best.

Im a noobie wannabe-programmer. Im doing a python bootcamp and I will see how far I can go I found your channel and I enjoy just listening to you talk because you use the lingo and although I dont always understand, its helping me. I learned what refactoring means just from watching this video I know it probably seems silly but just wanted to let you know

I kid you not, the current project I am on has two Tech Leads that don't see eye-to-eye at all and one of them in a gatekeeper. There is no documentation, no comments in the code for this complex platform tool. Been able to hack away at parts of it, but then sprinkle in the many levels of string/variable interpolation between various scripting languages and other tools in the chain makes me wish we could just start the entire thing over from scratch to simplify things.

Wait… let me get this straight. Prime wrote software in node and it bottlenecks in json processing… and instead of alleviating that bottleneck with C++/Rust/Go, he’s instead going to rewrite the entire app in Rust? Why? This needs explanation.

I agree, Scrum is garbage. The rest? That's just insane, if you have a few highly productive members and others that aren't doing shit the problem is management. Sure, some of it might be rushed and lack quality. But there should be documentation for new functions, at least the way they are intended to work. If you have that and go through the code changes before anything major is changed it should be fine. Because others are slow and cannot keep up the pace, why should I slow down and do less? As someone who has always been a highly productive worker (Used to be the one doing about 2-3 times the work of my coworkers while working as a Servicedesk agent, same thing as a 2nd line technician and now the same thing while I´m a full time student + full time worker as a developer) Sometimes people would see it as problematic because I generated more problems than other workers. This is however a dogshit take, it's easy to see for someone who isn't as productive and just focusing on the problems that the productive people create. "This person has caused so many incidents".. Sure, but not compared to the amount of work that person has done. The value added before the issues is often immense and often times people will only focus on the negatives, which in the end will just create a race for the bottom. Is there something you haven't done before? Don't do it, you might fail and then you'll get punished. Are you working too quickly? Stop! You might make a mistake and the managers are only focusing on avoiding mistakes. This is the worst take I've seen, because remove those 2 productive people you'd have a simple, easy to work with, pile of nothing.

this article is what i expect as content on the blog of norm from office space

I think potency is confused with the wisdom of when and where to apply it (i.e. two very different skills). I.e. you're not keeping things simple because you choose to, but because you don't know enough to implement anything more complex (i.e. not wise just weak xD). Probably just a good idea to train both skills. The takeaway for me is to remember to try and balance the training of these skills somewhat