Seven signs of a bad programmer. How many do you think I'm gonna get? Real talk, type it up here. How many of those do you think I'm going to have? One, two, seven? Okay, well, I'm happy that all of you guys think I'm an...

Then I'm stupid, really? What this shows is that I'm emotionally bruised all the time. Streaming the seven signs of a bad programmer... uh, the Secret Developer. Okay, four-minute read. Let's go! Let's go. There are many ways to be effective or ineffective at a job.

Here are a few that seem to be the running theme with some programmers I've worked with over the years. Number one: You watch a lot of Twitch, specifically the Primogen... Let's see, I'm a software engineer, not a programmer. Okay, okay, okay.

You know what they're like? Mechanical keyboard in the office. Can't make stand-up because they're thinking about a problem. It's a five-minute mention of what you're thinking about. How long did this... Oh my goodness! Oh my goodness! This... Yes, yes. Conflating the person with the

mechanical keyboard; the person that thinks... you know, that gets lost in a problem. This is so good! Oh no! Oh no! First off, stand-ups are never five minutes. It's because... it's because Bill won't shut up about his dog. Well, actually, this weekend, me and the missus

were on a hike, and you'll never guess what little Teddy did. So Teddy ran off at the sight of a cow, and then we were off in the pasture. It's just like, dude, I don't care about your dog, your hike, or anything. I just want to get the hell out.

of this meeting. If we're having lunch, tell me about it, okay? Because lunch is where we talk about this stuff, not at stand-up. What are you doing? What did you do? Tell me your effing roadblocks and get the hell out of the way. Why are

stand-ups so bad, by the way? I haven't done a stand-up in about 10 years since joining Netflix. It's been fantastic without stand-ups. I'm not entirely certain how people uh, can become so arrogant with three years of experience, but there you go.

Whoa, this article is a flame war! This article is barbecuing somebody! Yo, if you have a mechanical keyboard at the office, I don't think it necessarily means you're arrogant, but man, that barbecue is set to 500. I like to impress with my job title, who

what do you mean, nobody cares? Whiteboard in the background... Some people in the industry do have degrees. I've worked with doctors, not medical kind, okay? Usually we call those PhDs. Uh, those with qualifications in the industry often choose not to mention them because

within many organizations, there is a reverse snobbery around education. Okay, that's fair. There's kind of... I've seen some of this reverse snobbery, um, but it's it's exceptionally rare and it mostly exists on Twitter. I don't think I've seen it anywhere else, uh, yet.

Others wear glasses without medical reasons, which really happens. Instead of in front of a whiteboard on those video calls... Is he describing LinkedIn or programmers? This seems like a LinkedIn call-out, you know, that one post that inevitably gets around on Twitter from time to time.

That's just like, I watch porn. I don't care who knows; it's on LinkedIn. You're like, "Dude, this guy's unhinged." I'd be more impressed if your whiteboard had, uh, more than a bullet point list. That is, I know you don't understand the

wider architecture of the application. Your whiteboard is like putting makeup on a pig. Damn, zing, zing! All right, here we go. Uh, some have interesting information written on the whiteboard, though. What the hell are you doing, reading a whiteboard? Shut up! Why are you caring?

Stop caring! All right, here we go. Delete the current project. You've entered a new project, and I've seen someone on Twitter recommend that you delete the whole thing and start again. Won't the current team members be somewhat put out, uh,  by the suggestion? What do you mean,

teamwork might be damaged? Just delete it. Okay, whatever. Uh, I mean, a full-on rewrite; there are sometimes benefits to it, but the problem is... so, I mean, the problem with this article right away is that it lacks depth in general. It's very funny ad hominem.

We're all laughing, hahaha, but the reality is that there's a lot of ad hominem in here with not a lot of depth. Um, the thing is that some technologies you choose make it virtually impossible to just do a runtime refactor if you

will. Right, uh, it's really, really hard, right? So like, I mean, real talk: if you choose to write your front end in any framework—Svelte, JavaScript, wait, not JavaScript—Svelte, React, Solid.js—you can't just swap them, right? You can't just do that. It takes a

Lots of you know what I mean, like you can't—you literally have to delete the whole effing thing and start again, right? Uh, but okay. Uh, the Michael Jackson "Black or White"—the programmer can only think in terms of right and wrong, rather than shades of gray, in almost every

circumstance. There's only shades of gray and no right or wrong decisions, apart from a few things. Let's not get, uh, confused, though. When programmers declare that something should just be done in a certain way, they frequently think about their way of doing things.

So what you're trying to say is that there is a way that things should be done, but it's not the way that someone else is suggesting? Do you feel the loopback on this own piece of advice? Yo, bro, you can't make general statements; you're doomed if you do, doomed if you

don't. Like, what, uh, what—it's a loop. Sometimes it doesn't need to be your way or the highway. Uh, perhaps introduce the—perhaps introduce that it depends—a way of thinking—to your software development practices. This is good, but also real

talk. Who here—press one in the chat—who here has been on a team of a bunch of "it depends" CISOs? Deal in absolutes, ideal in absolutes. Press one if you've been on a bunch of "it depends." How fun is that team, right? How fun is

the team that everybody wants to pedant? Like everybody builds their own bike shed constantly, like it's—there's—it's almost equally as bad. I preferred the informed captain approach, which is just have one person—we all go, "Hey, hey Peter, what do we do?" And Peter goes, "Okay, I"

I think we should do this, this, and this, and we go, okay, we'll do that. Peter, we call it at Netflix, we call it the 'informed captain.' Someone just needs to make a decision; we need to just... we just need to move on, right? Just stop... stop with all

this pedantic masturbation. Uh, the Peter Principle. Oh man, this sounds like [name]'s favorite thing. Uh, faster path downwards. Some programmers are well worth a promotion after 12 or even six months, yet it seems many programmers feel that they are entitled to a raise

and a new job title after a few months on the job. The standard of team leads in tech companies does seem pitifully low. New developers quickly move up the chain without technical knowledge for a new advanced role and certainly lack the

people knowledge in order to be an effective team lead. Programming is all about people; they take time to develop. Why is it called the Peter Principle? Is this a reference to Peter, the pillar of the church? What... what's... I don't... is this a Peter I'm

supposed to know? Is it a biblical reference? Peter Griffin? Did he mean the word 'penis'? What is it? I think it's Spider-Man because Spider-Man... wasn't he promoted too quickly and he wasn't ready for his responsibility and his uncle got killed? I think that's what it

means. Okay. If I can relate everything to Spider-Man, I'm going to... Not biblical, clearly. That I just copy the code from Stack Overflow; it seems to work. Let's go. Later that week: 'Can you fix the crash?' You guessed it. Okay, I mean, this is such

An old meme. I don't know anybody that actually does this right. Chad, you don't do this right, chat. Okay, so this one actually sounds great. Lack of curiosity. It's fine to be in it for the money; absolutely. To some extent, every job is about the income you derive from it.

Absolutely. If Netflix cut my income by a tenth, like if they cut it to one-tenth, I'm not like, 'Well, geez, I really love my job,' you know? Like, I get it; there is definitely an income barrier here. However, to really have a

passion and love for your work means that you get so much more out of it and become a much more valued colleague. Absolutely. Your aim is to retire at 40? Not so much, perhaps. That is why you are not so interested in finding out

the origin of that bug, after all. What if you are curious and you just don't want to work at a corporation by the time you're 40? I'm not—hey, I'm not saying I'm going to quit Netflix within the next four years, but I'm just saying that it would be really sweet if I didn't have to work for you at 40. I got them—damn, I'm about to be a farmer

full-time. But why? If you don't enjoy your job and want to improve both yourself and your current project, perhaps it's time to find a new career. Oh my goodness, this little bit is a little intense. I can—you know what? Not everybody has to love it.

I finally came around on it. Not everybody has to love it; you just have to realize what that means. That is, if you don't love it and you're just cashing in, cashing out, you're going to be a kind of stagnant

basic generalist with not a lot of depth. And there's plenty of jobs that need that, right? There's plenty of jobs that like that, plenty of jobs that need it. That's okay; not everybody has to be around, not everyone has to be an Olympian, right? Uh, this article is a

light-hearted look at the following destructive developer behaviors. Okay, I'm a software engineer, not a programmer. Whiteboard in the background to delete the current project; Michael Jackson, Black or White; Peter Principle—still don't know who this Peter is; copy-pasta; lack of curiosity. Conclusion: If you're

displaying one of these signs, it doesn't mean that you're a bad programmer; just playing all seven, you might not be a fantastic developer. Uh, you might not be the fantastic developer you think you are. I let's see, I don't know, though, because I don't know you. See, you want to

know an effective programmer looks like. Look at the article below: Seven signs of a great programmer. Office Space Peter—ooh, none of us even thought about that. Okay, hold on. Uh oh, thank you, thank you. Uh, uh, Twitch, Twitch Jeopardy. Uh, the Peter Principle was laid

out by Canadian educational scholar and sociologist Dr. Lawrence J. Peter in his 1968 book titled *The Peter Principle*. Kind of looks like a dick. Uh, dang it, this is a YouTube video. Uh, the Peter Principle is the concept in management developed by Lawrence J. Peter.

which observes that people in a hierarchy tend to rise to a level of incompetence. Employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent

as skills in one job do not necessarily translate to another. And that's actually a pretty good principle. I like that. [Music] So you're telling me I can't make a dick joke? That's what you're trying to say?

Karen, then how do I measure my dick in bites if that's such a big deal to you? Huh? Do you know about the pickling algorithm? Oh, you don't? Well, guess what? It's confusing. The name Karen is the dictogen. [Music]

7 Signs Of A Bad Programmer | Prime Reacts

This is a place for all the things that are awesome on stream. 

ThePrimeTime

'나쁜 프로그래머의 7가지 징후' 글에 대한 소개 및 초기 생각.

발표자가 주제를 소개하고 시청자에게 자신에게 해당한다고 생각하는 징후가 몇 개나 있는지 맞혀보라고 요청합니다.

화자는 자신의 감정 상태와 글의 전제에 대해 반성합니다.

첫 번째 징후는 과도한 Twitch 시청입니다.

연사가 두 번째 징후인 스탠드업 회의 중 집중할 수 없는 상황에 대해 설명합니다.

비생산적인 스탠드업 회의의 예를 들어보겠습니다.

기사의 내용과 어조에 대한 비평 및 토론.

화자는 기사의 공격적이고 독단적인 스타일에 대해 댓글을 달았습니다.

기계식 키보드, 직책 및 학위와 관련된 기사의 요점에 대한 토론입니다.

연사는 업계의 역 속물근성에 대한 기사의 지적에 대해 언급합니다.

발표자가 프로그래머와 LinkedIn 게시물을 비교한 기사를 분석합니다.

화이트보드와 애플리케이션 아키텍처 이해에 대한 기사의 요점을 비판합니다.

기사에서 제기된 구체적인 문제점을 분석합니다.

발표자가 프로젝트를 삭제하고 다시 시작하라는 제안에 대해 설명합니다.

기사의 깊이가 부족하고 애드호미넴 공격에 의존한다는 비판.

특정 기술 리팩토링의 어려움에 대해 논의합니다.

프론트엔드 프레임워크 변경과 관련된 문제에 대한 자세한 설명입니다.

연사는 '마이클 잭슨 흑인 또는 백인'에 비유하여 설명합니다.

다양한 팀 접근 방식과 의사 결정 스타일에 대해 토론합니다.

연사는 '상황에 따라 달라진다'는 접근 방식과 보다 단호한 리더십 스타일에 대해 설명합니다.

연사는 모든 사람이 지나치게 많은 생각을 하는 팀의 단점에 대해 설명합니다.

연사는 의사 결정에 대한 '정보에 입각한 선장' 접근 방식을 소개합니다.

연사는 불필요한 지연을 피하기 위해 효율적인 의사 결정을 옹호합니다.

피터 원칙과 기술 분야의 경력 발전에 대해 논의합니다.

연사는 사람들이 자신의 능력을 뛰어넘어 승진하는 현상에 대해 이야기합니다.

연사는 기술 기업의 팀 리더의 낮은 수준에 대해 언급합니다.

연사는 피터 원칙의 기원과 의미에 대해 추측합니다.

발표자가 스택 오버플로에서 코드를 복사하는 방법에 대해 설명합니다.

프로그래밍에서 호기심과 열정의 중요성에 대해 토론합니다.

연사는 금전적 동기가 유효하다는 것을 인정하지만 열정의 가치를 강조합니다.

연사는 소득이 직업 만족도에 미치는 영향에 대해 설명합니다.

발표자는 자신의 개인적인 커리어 목표와 포부에 대해 이야기합니다.

발표자는 조기 은퇴를 하고 다른 관심사를 추구하겠다는 포부를 밝혔습니다.

연사는 모든 사람이 자신의 일을 사랑할 필요는 없지만 열정이 부족할 때 어떤 결과가 초래되는지 인식하는 것이 중요하다고 결론을 내립니다.

이 글에서는 나쁜 프로그래머의 7가지 징후를 요약하여 설명합니다.

연사는 한두 가지 징후를 보인다고 해서 반드시 나쁜 프로그래머가 되는 것은 아니라고 강조합니다.

연사는 훌륭한 프로그래머의 7가지 징후에 대한 기사의 존재를 언급합니다.

연사가 피터 원칙의 기원과 의미를 언급하며 피터 원칙에 대해 설명합니다.

연사가 경영에서 피터 원칙의 핵심 개념을 설명합니다.