The Worst Kind Of Programmer 

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

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.

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

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.

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

this was written by a malding scrum master

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

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.

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

I use semi-colons in Python

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

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.

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

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.

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.

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.

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.

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.

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.

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!

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)

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.

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.

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.

really enjoyed this article

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

I am stupid

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

Dude. This was awesome! 👌

Most sane JDSL enjoyer.

editing on point today flip

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

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

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

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

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.

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😄

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

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.

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.

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.

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

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.

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

What is the role of management in that team? What is the name of the process where the rest of the team has no idea what the two developers are building, and managers completely missed that?

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

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.

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

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

Reminds me of the "brilliant jerks" articles from a few years ago (around 2017). Lots of good and bad takes all under the same buzzword.

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.

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.

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

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.

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

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.

this cyberpunk edits are fucking amaizing. Thanks, flip

I didn't get much out of this. Must be the Danning-Pflueger effect at work.

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.

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.

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.

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

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.

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

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.

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.

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 don't want your monoids, you can go endo-fuck off" might be my new catch phrase as a Haskell dev

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.

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

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

Wisdom: really good realization, Prime. That really is the key.

7:03 - look; I have the 1st one kinda hard. LOVE MATHS! but I always tell people, when they have ideas, to think if they're sure. what does it take to build your idea? then I proceed to build the maths and explaining ALL of the pieces that need to be working; and all of the situations you'd need to update it, then I pair it with the changes on things we alredy discussed and starts changing them. it usually don't take long for the person to give up; which was my point from the start. each phrase in that sequence is a step in making someone stop overcreating.

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

Using fancy new stuff to learn it is fine. If the rest of your team isnt able to understand it, either you did an absolute god awful job of choosing something, theyre poor programmers, or you should put a bit more effort into explaining the core concepts to them. If youre convinced you chose right, do a tech talk, be more active than usual in code review. If the problem persists, its your coworkers fault. Or youre delusional and made a bad choice, but youre delusional, so realization wont be reached. I swear every one of these "why X is bad" articles invariably ends up being "a guy did X, then wrote shitty code". Just write better code. Optimize for readability where you can.

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.

Can you do a video on your tool set and your best practices to handle Strings efficiently? Because that really piped my interest. Show casing stuff would be really great. Or even just a git with examples copy pasted together. If you brag, deliver 😜 Kidding aside, would be really helpful.

Nice, I haven't touched frontend or Angular much but I just looked at all our repos using Angular. They all use Nx and Rx, how delightful.

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.

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

Oh man he got me with that primeagen label at the end

I am terrorized by this article

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.

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

hmm, perhaps i should write my server backend in C for my next project

Imo sometimes it's good to atleast think about the future problem and considering it to a limit earlier, so you don't have to go through everything and fix each of them one by one later on.