The problem is: Sometimes it's a good idea to reason about the future problems as well. You don't need to solve them right now, but check if they could possibly be solved with the chosen approach. So what's actually needed is to reason about the cost you take for being a bit more future proof. If the cost is small but a future change would be a lot of effort, take it now. As always: "Choose with reason not by accident".
@@josefpharma4714 I'd agree with that. There's always some balance to strike and gray areas to navigate. It's real easy and sometimes encouraged to go off on grand design adventures and work up a Deathstar when you only needed a Speeder because you just knew that the day would come when you'd need to support interstellar travel and planetary destruction. And in the end you get neither. Kubernetes....
Yea, the entire thing was. “Why are these two people, who are doing 90% of the work, also creating 90% of the code quality issues” It’s a big duh moment. It just got worse as it went on too. At some point he was complaining about young people making mistakes. Another big duh moment…. They lack experience… Here’s the truth, the company didn’t want to shell out the big bucks for senior developers so they hired a bunch junior devs and put their least competent older devs on the same team with them. Their gamble succeeded and there were two gems in the younger devs they could overwork and underpay. Those devs did exactly what young talented devs always do and try out a bunch of new untested things because everything is new and untested to them anyways. The old crotchety non senior dev riding out his paycheck in the corner decided he needed a way to blame someone else for the reason why the team sucked and why he did nothing while waiting for requirements instead of ya know participating and maybe advising his juniors not to use weird functional JavaScript libraries.
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.
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?
The problem for me, currently. Is that this person is the lead and they ignore the rest of the team since they are in the lead. If the lead becomes a manager and a closed circuit, they can start bypassing everyone else.
This. Management gets told the lead is undermining the project, that he's resistant to change, resistant to others' input and that outstanding abstract maths skills don't actually translate into being a good programmer (shocking I know). 2 years later and the project finally gets aborted and work begins on rewriting it from scratch. Few lessons are learned, all the invested time & money is lost and the cycle begins again.
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.
Honestly, this perfectly encapsulates what I thought the best people for all the different jobs I have been part of would be. I've done routine jobs where the dumb lazy people were the best to have around but would have driven a smart person insane out of boredom. And, dumb, hard workers are the absolute worse.
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.
The least dependencies is not the grail. But, a low healthy number is - e.g. 1 web framework, 1 database, etc, for a decent HTTP microservice, as an example. It obviously scales up and down with what you do.
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.
100% salty scrub with his first job or something along those lines - lead devs and management fault in my humble opinion. bad choices were made, but the reasons why it sucked he didn't quite get right imho
How did you land at that conclusion? The article said not to overcomplicate your solutions and think of the people you're working with. You just can't introduce stuff like "rxjs" and "nx monorepos" when your team doesn't even know what those things are and just dip and switch jobs later on, can you imagine what a bad taste that would leave in someone's mouth and how it would make them hesitant to hire someone such as yourself in favour of someone normal who might not have made those decisions You must be empathetic to the people you work with, teach them new things if required and make sure they can handle stuff in your absence. Don't be hard on them because their hiring was not in your control
@@dough-pizza That's not the main point the article actually pushed though. It explicitly stated that passionate and talented programmers are red flags. They didn't even make the case that being passionate and talented can mask poor decision making when it comes to systems design for teams.
@@thekwoka4707 not entirely true, the article did state that, but it was more in the lines of that line from Jurassic Park- "They were more worried if they COULD do it, instead of if they SHOULD". Meaning that writing a lot of code just because you like it, without taking into consideration the business requirements and your teams involvement IS A RED FLAG. That screams "I'm smart so I can KNOW what I have to do, I don't care about anyone else", which in certain circumstances could be true, but it can also ruin team morale and skill development and absolutely derail the products future.
The selection bias issue could make this make sense. If this guys dev experience was at like big lots or Pizza Hut, it would make sense that these dudes cause the most problems. Because if you have all of those characteristics and are actually good why are you working there instead of a software company. So he’s only dealing with low quality versions of the dude he’s describing.
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.
>he described passionate engineers who took risks in doing More like he described a bunch of pricks that would gladly put several gigabytes worth of trendy frameworks, libraries, with tons of bloat and dependencies to solve some basic CRUD task, and then pat themselves on the back for being so "forward thinking" and "passionate". I've worked on legacy project left by such people. Fuck. Them.
Well, i see where that article wanted to go, but poor examples and descriptions make it too hard to relate. I think the aim was to show that, overcomplicating and selling most 'trendy' things to top management without considering our resources is a bad thing. I mean it's bad in the case of management not a bad thing in the case of engineering. That programmer he described wasn't the issue, the issue was a non-technical CEO who sponsored it and let it go without knowing his team's strengths and weaknesses
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.
I think the biggest take should just be that being very knowledgable, talented, and hard working does not mean the decisions you make all the time are the best for that specific situation and the limitations of the teams involved. It's not what the article actually said though.
You’re right, some of the worst developers are talented and motivated people who lack experience and go make stupid articles like the one we’re reading.
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.
I always thought about that shit, why the f**** the jobs ask for such an amount of bullshit when the actual work is usually simple. Bro, your small e-commerce isn't Amazon
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.
"make it work" is the important part. When I need to add something,, the first thing I do is get the most basic function working. Even if it's the worst possible version that works. Building on that foundation makes everything else easier when you aren't making lasagna out of spaghetti problems.
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.
I do think that using the latest hype technology is a risk and should be considered very heavily since the new language or codebase didn't have enough time to settle in and prove its worth yet. I mean, half of what you can do with new languages, C++ probably does better if coded correctly. That's as far as I agree with the article, but I do think that having enthusiasm and passion for the job and trying to find new ways to solve problems is a good thing. I think that sure maybe some of the programmers the article writes about have gone off the deep end of the new tech hype that their own coworkers have lost themselves among the confusion but I think it's less the problem of those who try to incorporate those and instead it's the fault of the managers and higher-ups allowing things to get to this state of hell development. I'm not saying that you shouldn't do anything new or innovative, but what I'm saying is that you should at least communicate fairly with your team and managers so they know that there's a new technology being used and understand that it will probably take time for EVERYONE to adapt to it no matter how good of a developer you are and be open to criticism and help those who don't understand the framework as good as you do.
Ever heard the saying "The overly active fool is worse than a saboteur"? (or some variant of it) The article (at least, the first part) is describing just that. Your passion and productivity don't mean crap if the end result is a mess. You are not here to get participation trophy for a "hard work", you are here to actually make product that does what is intended to do, in the acceptable timeframe, with acceptable degree of scalability/maintainability. If it doesn't, you can take, idk, a new world record in speed running Wolfenstein, it will be as much "hard work" with as much result.
@@casusbelli9225 Yes, people who are doing a bunch of stupid shit are worse than people doing a little bit of stupid shit, but pointing your fingers at the "doing stuff" part as the problem instead of the "stupid shit" is ridiculous.
Sometimes a road to simplicity is through complexity. Sometimes you need solve it in a complicated way to learn what needs to be done so that you can learn from it.
Sometimes you need to fall down with your face into the pavement trying to do something complex to learn that doing it the simpler way is often times more desirable@@RealRatchet
@@RealRatchet You could dedicate 402% of your brain into inventing the most energy efficient form of walking, or you could walk. One of these gets you to work on time.
"Knowing some trendy/obscure things and shoving them everywhere to show off, damn the performance and readability, is being a better programmer" No wonder the industry is such a shitfest.
@@casusbelli9225 I call it job security. Those tire fires are very entertaining to watch. As much as this stuff seems scary. It scares proper managers just as much. So the management issues do not just randomly correlate here, I dare say.
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
Nobody refactors the lousy code that sort of works. Bad code gets half as expensive CPU, Memory and Storage wise every 18 months. If it fits the spec that allows 90% of the invoice to be paid... all is good. By the time a bad codebase is clear to the guys paying the bills, work needs to happening on the next code base per current trends.... it will be so much better in Rust than JS. For whom will it be better? If it works, what manager in their right mind will allow someone to jump into that mess and open up the need for extended QA to wring out 50% more performance in a 4 months when moore's law does it without risk in 9 months. The customer accepted the application months ago....paid their bill...f them.
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.
Yeah I thought that the very core of the engineering mindset is to break a complex problem into simpler smaller problems. An experienced Lead should be able to do this in a way that everyone in the team can contribute as long as the requirements are clear.
This video embodies every reason I subscribed. Crying tears of laughter in the first 3 minutes... And functional programming. We've all been there. "My GOD! Look what I did with just two lines of code!" (followed by three pages of comments to try to explain it)
I've always said to people and newer programmers that it doesn't matter if you take 10 lines of code or 1 line of code. If I can intuitively read the 10 lines and you need to explain the 1 line, the 10 lines is superior.
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.
highly skilled, but lack of wisdom. I think that's this article is really about. "Beautiful" codebase is useless if no one in your team understand the codebase.
@@adicandra9940 Business owners like programmers to be replaceable. Programmers don't want themselves to be replaceable. This can be seen as a class conflict.
>I mean people that the guy in the article has described literally carry the company, especially on critical times. If a programmer can't adhere to KISS principle, he is not a programmer, he is a code monkey. A code monkey with a time grenade, specifically. Elegance and simplicity are part of the programming as an art. Overcomplicating due to techbro having a need to show-off is the opposite of good programming, "carrying the company" and generally software engineering. Moreso, most of the time it CREATES those critical times, when the overcomplicated mess of the code starts collapsing on itself.
“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
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.
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.
99.999% of the data transformations are because of lack of normalization that is forced within classic databases and the inability to write joins/views by 99.999% of programmers...I see bulk selects flow by every day as a network side role. If one does not understand the power, or should I say lack of CPU cycles to present indexed and normalized data in bulk move fashion is why programmers go insane in their libraries. If oracle or mssql is your only data source, your programing tasks are considered trivial for a reason, your not attemtping to mesure a distance with knotted string in a ball. If you as a programer cannot make a GUI stream by like wireshark for a bussiness applaication without stacks and stacks of compute, your the problem. Performance has always been from ruinously knowing the data is not thawing an exception logic event every 5th entry. The 30 year old systems performed on 4MB, your dogshit slow on 16GB.
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."
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.
Literally all you need to do to make kids like you is to talk to them like a normal person and encourage them when they talk about stuff they like. It's so rare for them that it pretty much makes any kid latch onto you.
@@fearedjames Yeah, kids usually quickly like me. Just showing serious interest in them is often enough. My mom is even worse. Sometimes children from other visit us, like the childern of a friend of my mom, and usually they just don't want to leave anymore. My mom always wonders what she's doing, because when her children (like me) were somewhere else, we were usually happy to see our mom come back. But maybe it's also just because we don't put so much restrictions on them, like they would be allowed to play video games for hours. (I'm actually happy if children are able to focus on something for more for an hour. The children I mentioned earlier ususally can't focus for that long on a single game)
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.
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 have never found an article I disagree with this much. It’s almost political. Jaded low-bar underachiever who just wants bare minimum garbage older than the rest of the team. Sometimes we have to get away from the easy to use stuff. That being said, a good team lead spends time teaching as well
if it's the right tool for the job, I don't see the issue. Node was clearly an issue for the kind of traffic the app was under. Should he have used C and hate his life about the threads management, the error management without a clear happy path between threads / malloc / race conditions, etc? Or C++ which is technically even more convoluted nowadays? He could probably have made things simpler in Golang, but why should he cares? He was the one building the app and doesn't have skill issues with Rust.
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.
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.
Thank you for saying it. I have been in teams with horrible Scrum implementations (like everyone else), but the single good Scrum implementation which worked so well showed me that this general allergy to Scrum is just a... let's say, "experience issue", since this audience here so easily accepts the locution "skill issue" as a proper response to an argument (which it certainly isn't).
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.
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.
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.
I think the opinion you highlight does make sense when you follow through with the belief that wash language sucks but that isn’t the source of suffering. The source of bugs and other suffering is almost always skill issues, especially in C and Rust and the latter is designed to not work until you stop having skill issues.
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.
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.
Yeah exactly. Those incompetent managers just throw a big problem at bright but inexperienced people in order to avoid paying for expertise and those young eager people take it because they see it as a way to prove themselves. What can possibly go wrong?
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.
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.
> 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 I am pretty sure that, with time, it only becomes worse. Especially since people tend to drop the fundamentals of programming in favour of readily available overcomplicated (but trendy) solutions. Webdev already is filled to the brim with such approach (hence, the whole web bloat problem), but it now slips into other areas.
DevOps is not a role, it's a team pattern. Including operations experts in the team lets them build the infrastructure the devs need. Devs don't have to mess with infrastructure. I totally agree, "DevOps should be done by people who like doing it." I think its the 'dev' in DevOps that throws people off. Yes, we use developer methods, and we write 'Infrastructure as Code' and use git and vs code, but in the end, we support the devs. Expecting devs to build CI/CD pipelines leads to hiring folks who are "jack of many trades, master of none". Much better to hire one or more infrastructure engineers, site reliability engineers, or whatever name you want to give it, to support the devs. This frees the Developers to develop.
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 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.
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😄
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 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.
This article is a great example of correctly identifying a problem, but getting the cause and solution analysis COMPLETELY wrong. Prime has the right take, this is a teamwork problem. That means management should step in and fix it, because facilitating teamwork is the only reason to have management. If you want to be a good engineer, just repeat this mantra over and over in your head all day every day: "simple solution best solution". Good engineering is the process of removing complexity until only the solution remains.
Agree. In a project that lacks clear leadership, de facto leaders will arise and implement their own vision. Seemed like the article was kinda using the people who were actually attempting to provide solutions as scapegoats by painting them as the "worst type of programmer". Sure, their approaches may have been flawed and their attitudes may have needed adjustment, but management should've stepped in to correct the situation when the cracks began to show.
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.
Damn, I'm in my third year of learning informatic and agile SCRUM it the only management method they make us learn to work with... I've never seen perspective opposed to it before, would you mind saying what you dislike about scrum?
@@lcarsos Yes, we removed groomng sessions for tickets. Instead we just have high level topics which are prioritized by product and we just start with the POC immediately by one or two people. We try to do a vertical slice of the feature (some happy path scenario). Usually that's enough to determine which things need to be done and we are gradually able to include more people in the work if needed. Or we discover it's too much effort and deprioritize it (if it's not critical). We're also not afraid to just throw away the PoC work if the initial ideas were bad and we need a completely different approach. IMO this is the faster way in the end than trying to come up with the best architecture beforehand. Then one person on the team (technical lead) also takes technical debt tickets and adds them to backlog. We use a kanban board and whenever someone has nothing to do they can just take something from there. And most importantly, we do not go strictly by the process. For example if somebody thinks there's something completely different we ought to be doing they can just bring it up on Slack and we can decide ad-hoc. Of course, I have only 4 years of experience after college so there's a lot of things I have not experienced, but so far I like this approach a lot better.
@@bruoche It's a huge waste of time. People attending meetings where they bring no value, and gain nothing from hearing what's said. And focusing on arbitrary tasks that aren't about solving the real problems. It's a specialized organization tool that is uncritically turned into something general. Much like many software frameworks. It's not all bad but there's many better ways of communicating and enforcing standards.
Or developer who is sick of 99% of the new shit that, behind all the BS about being "hip", "new", "challenging the world of whatever" and other buzzwords, is the reinventing of the wheel by the more convoluted, messy, overcomplicated bloated methods. Keep. It. Simple. Stupid.
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 agree with you and I believe that the secret to financial stability is having the right investment ideas to enable you earn more money, investing with the right expert would free you from modern financial slavery.
Wow. I'm a bit perplexed seeing him been mentioned here also Didn't know he has been good to so many people too this is wonderful, i'm in my fifth trade with him and it has been super.
Fergus waylen is a retirement manager and investment/savings expert, in ranks with Cathie woods and Warren, has demonstrated expertise in investment strategies and has been involved in managing and providing financial guidance globally, it's all facebook .
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.
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.
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.
I am wondering why the guy who wrote the article is not someone in charge of programmers? I mean it sounds like he has all the answers and knows all the problems and can do it all exactly the right way. So why is he not putting his immense knowledge, experience, and skill to a productive use and instead sitting in the corner watching all these fail managers fail and cost the company so much money without being able to deliver anything?
Did i just hear that you would tie a customer to a certain node due to caching? Noooooooo. Do NOT do that. Write the session into a replicated cache. Every node is then stateless so they can die without taking customers with them.
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.
You're close but you're not quite right. Everyone has a tendency to conceive of themselves as regressing towards the mean. Your model explanation lacks any accounting whatsoever for the fact that (just as important in the dunning-kruger graph) the people who are much better than average tend to under-evaluate themselves as well. In my opinion, the Dunning-kruger effect is simply that it's very difficult to evaluate yourself relative to everyone else, period. It's a statistical way of thinking that runs counter-intuitive to actual human thinking. You can't really keep inside your head an accurate perception of what's in everyone else's head. Without having already seen the data, asking me to guess where I fall in regards to the general population at any individual task would be very difficult. And in my opinion, people read WAY too much into this phenomenon. Because why does my ability to place myself on a percentile chart matter? It really doesn't matter in any practical sense. It's just an excuse to act like a douchebag towards people who aren't very good at something. Why do you think that's the only half of the theory anyone seems to know?
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.
Agreed. I encountered a bug in a famous extension for a well established "text editor" (Yes, its starts with a v). The code that was crashing was written in rust and you know what caused the bug? It was a None.unwrap(). Probably another one of those "Well. It will never happen. It's safe here". Worst thing is, the code was littered with unwrap() and other blatant lack of error checks.
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.
08:10 The way you work 60 hours a week is by neglecting other aspects of your life. That's ok when you are young, or if you let your spouse take care of the house, kids, and family (let's face it, it's usually men leaving this to their wives), and if you don't have any health condition that limits that. That is called overachieving, and doing it consistently should not be the norm.
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 don't think that is what he's saying. Dunning-Kruger Effect is where people with little knowledge and experience in a particular skill don't fully understand how much knowledge is required to achieve competency in it and therefore overestimate their current ability - which he alludes to with his comment on younger developers. The common misunderstanding with Dunning-Kruger is that people think it is related to intlelligence - but it isn't at all.
@@curtmantle7486No the common misunderstanding with Dunning-Kruger has to do with misapplying it to actual experts with the notion that actual experts will never think of themselves in those terms when in actuality as people get better at things the effect is that they become more accurate in their appraisals and so experts do indeed know that they are experts. Recent studies actually indicate that the effect isn't actually real and in fact comes from people who are misinformed vice uninformed. A flat earther thinks they know more than me about the shape of the earth while an elementary school student who has never thought about it before likely realizes they don't know. The author doesn't come out and say what I say but it is clearly implied. Why don't the other developers suffer from it (of course the face the other developers don't think they know enough to challenge the "performant" ones indicates that they at least have some level of self awareness and also shows the likely flaw in the science behind the effect itself)? The author also says later that the performance of these people ruining their projects is measurable which shows they've never read an article on software engineering and also contradicts the idea of the Duning-Kruger effect.
So management let these two push their vision of the project without any pushback or proper assessment of whether their solution fits the problem. Also I do think code should be written and documented in a way a novice programmer could follow or at least work with.
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.
Let me break this down. Here's the problem. We have an oversupply of smart people and an undersupply of interesting jobs for those smart people to do. Therefore, you see this pattern where smart people show up on the job and want to be engaged, but can't because the work isn't interesting. So they try to make it interesting by concocting ever more elaborate and complicated software systems. Here's the solution: No mandatory work hours. If you complete your work, you go home. Now there's an incentive to finish the job, go home, and make video games, which is what every programmer actually wants to do.
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 don’t get the problem statements like “backend and frontend were already too complex for team members to work on business requirements”. Like… fking learn it dude, that’s your job. What else are you doing that you just decide you’re not going to work on the product that the leads have made. Idk this architecture doesn’t sound TOO wild ‘n out. I feel for the leads here, the juniors devs were probably just lazy. The statement that the code quality struggled and “the angular TS was randomly mixed with JS” is like absolute entry-level failure, that had nothing to do with the seniors making the product “too complex”, thats just a matter of… NOT SUCKING
Blaming complexity is very dangerous. What's the delimitation between wanting simplicity vs caving to the dimwits. Overengineering is bad, idiocracy is worst.
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
There are specific areas where Rx is good, but it's not a panacea The problem is when all you have is an Rx library and every problem looks like an observable
@@georgehelyar Having been a hard-core observable zealot in the past, I think the problem is that observables are kind of the only abstraction Angular provides for dealing with asynchronous behavior, including things like user input. So the alternatives are clean observables, or dirty stateful imperative programming, and when faced with either learning monads or untangling a bunch of cascading assignments in an event callback, you'll choose the monad. It really seemed cool at the time, but I had to watch a few talks that perfectly described some problems I was running into before I finally understood why it was a problem. My current take is that if you're in an Angular environment, you should still use observables to reduce complex interaction patterns into simpler ones, but you should never be doing that kind of work in your actual page or its business logic. Hide that off where you only need to touch it when there are changes to those complex interaction patterns. Ideally there shouldn't be very many of those complex observable chains anyway. If you're using React, put it in a hook. It's still easier said than done, because with certain team makeups you might find that you can't extract the "bad" code before a junior dev on a deadline starts adding complexity to the page in a way that makes it very difficult to get rid of the observables.
Wtf. were those leads even doing if there were no requirements until the last moment? I know they tried to prepare to be able to digest any requirements that could eventually come, but.. what else could they even try?
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.
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.
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.
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.
"Don't solve tomorrows problems because you don't know what they are". Beautiful.
I need that on a T-shirt to wear for every single meeting.
you forgot
"your not good at it anyway" after that qutation
“Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own.” Matthew 6:34
The problem is: Sometimes it's a good idea to reason about the future problems as well.
You don't need to solve them right now, but check if they could possibly be solved with the chosen approach.
So what's actually needed is to reason about the cost you take for being a bit more future proof.
If the cost is small but a future change would be a lot of effort, take it now.
As always: "Choose with reason not by accident".
@@josefpharma4714 I'd agree with that. There's always some balance to strike and gray areas to navigate. It's real easy and sometimes encouraged to go off on grand design adventures and work up a Deathstar when you only needed a Speeder because you just knew that the day would come when you'd need to support interstellar travel and planetary destruction. And in the end you get neither.
Kubernetes....
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.
I legitimately lol'd at this one
@@yeahdudex I'm glad you enjoyed my corny joke
Haha I laughed out loud
It wasn't corny, it was fowl.@@ISKLEMMI
@@ISKLEMMI man i used to eat tons of grocery store rotisserie chickens and grocery store fried chicken. kinda got sick of it.
This article is written by a business major who accidentally fell into IT.
Why do you hold that opinion?
Because business majors are teh stupid, obviously.
@@dejangegicthey might have looked up that person on LinkedIn or smth, why are you assuming it is an opinion?
Yea, the entire thing was. “Why are these two people, who are doing 90% of the work, also creating 90% of the code quality issues”
It’s a big duh moment.
It just got worse as it went on too. At some point he was complaining about young people making mistakes. Another big duh moment…. They lack experience…
Here’s the truth, the company didn’t want to shell out the big bucks for senior developers so they hired a bunch junior devs and put their least competent older devs on the same team with them. Their gamble succeeded and there were two gems in the younger devs they could overwork and underpay. Those devs did exactly what young talented devs always do and try out a bunch of new untested things because everything is new and untested to them anyways.
The old crotchety non senior dev riding out his paycheck in the corner decided he needed a way to blame someone else for the reason why the team sucked and why he did nothing while waiting for requirements instead of ya know participating and maybe advising his juniors not to use weird functional JavaScript libraries.
Thank you, 7 Grand Dad.
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.
That's a really good caution.
love this take
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?
The problem for me, currently. Is that this person is the lead and they ignore the rest of the team since they are in the lead. If the lead becomes a manager and a closed circuit, they can start bypassing everyone else.
This.
Management gets told the lead is undermining the project, that he's resistant to change, resistant to others' input and that outstanding abstract maths skills don't actually translate into being a good programmer (shocking I know).
2 years later and the project finally gets aborted and work begins on rewriting it from scratch. Few lessons are learned, all the invested time & money is lost and the cycle begins again.
Thats the project lead, and they are the problem
It's like some kind of system of checks and balances. Or a courtroom where the manager prosecutes all the silly decisions the lead makes.
this is JS bro. The difference between this and functional code without any problems is very slim
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.
Honestly, this perfectly encapsulates what I thought the best people for all the different jobs I have been part of would be. I've done routine jobs where the dumb lazy people were the best to have around but would have driven a smart person insane out of boredom. And, dumb, hard workers are the absolute worse.
Dumb and lazy here 🤚
@@The-Dirty-Straw same!
I'm curious, where did you read this? I like it
@@MrJimmyjammalbump
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.
100% correct.
" as few dependencies as humanly possible" but without NIH syndrome.
The least dependencies is not the grail. But, a low healthy number is - e.g. 1 web framework, 1 database, etc, for a decent HTTP microservice, as an example. It obviously scales up and down with what you do.
I'm stealing that and putting it on my CV - amazing take
True.
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.
100% salty scrub with his first job or something along those lines - lead devs and management fault in my humble opinion. bad choices were made, but the reasons why it sucked he didn't quite get right imho
How did you land at that conclusion? The article said not to overcomplicate your solutions and think of the people you're working with. You just can't introduce stuff like "rxjs" and "nx monorepos" when your team doesn't even know what those things are and just dip and switch jobs later on, can you imagine what a bad taste that would leave in someone's mouth and how it would make them hesitant to hire someone such as yourself in favour of someone normal who might not have made those decisions
You must be empathetic to the people you work with, teach them new things if required and make sure they can handle stuff in your absence. Don't be hard on them because their hiring was not in your control
@@dough-pizza That's not the main point the article actually pushed though. It explicitly stated that passionate and talented programmers are red flags. They didn't even make the case that being passionate and talented can mask poor decision making when it comes to systems design for teams.
@@thekwoka4707 not entirely true, the article did state that, but it was more in the lines of that line from Jurassic Park- "They were more worried if they COULD do it, instead of if they SHOULD". Meaning that writing a lot of code just because you like it, without taking into consideration the business requirements and your teams involvement IS A RED FLAG. That screams "I'm smart so I can KNOW what I have to do, I don't care about anyone else", which in certain circumstances could be true, but it can also ruin team morale and skill development and absolutely derail the products future.
The selection bias issue could make this make sense. If this guys dev experience was at like big lots or Pizza Hut, it would make sense that these dudes cause the most problems. Because if you have all of those characteristics and are actually good why are you working there instead of a software company. So he’s only dealing with low quality versions of the dude he’s describing.
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.
This is it! Skill issue + Envy lol.
>he described passionate engineers who took risks in doing
More like he described a bunch of pricks that would gladly put several gigabytes worth of trendy frameworks, libraries, with tons of bloat and dependencies to solve some basic CRUD task, and then pat themselves on the back for being so "forward thinking" and "passionate".
I've worked on legacy project left by such people. Fuck. Them.
Well, i see where that article wanted to go, but poor examples and descriptions make it too hard to relate. I think the aim was to show that, overcomplicating and selling most 'trendy' things to top management without considering our resources is a bad thing. I mean it's bad in the case of management not a bad thing in the case of engineering. That programmer he described wasn't the issue, the issue was a non-technical CEO who sponsored it and let it go without knowing his team's strengths and weaknesses
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.
I think the biggest take should just be that being very knowledgable, talented, and hard working does not mean the decisions you make all the time are the best for that specific situation and the limitations of the teams involved.
It's not what the article actually said though.
Yo you just described me 😢
"we are solving for x, so while we're in here and working, let's solve for every hypothetical case we dream up"
You’re right, some of the worst developers are talented and motivated people who lack experience and go make stupid articles like the one we’re reading.
if they need guidance they are not talented as they dont apply the right solutions to the right problems. Redefines them as being motivated only.
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.
Based take right here. Why do they interview front-end devs on such skills instead of the type they should be using,
Well put truth machine
hit the nail on the head
I always thought about that shit, why the f**** the jobs ask for such an amount of bullshit when the actual work is usually simple.
Bro, your small e-commerce isn't Amazon
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.
...and then wake up from your dream, right?
"make it work" is the important part. When I need to add something,, the first thing I do is get the most basic function working. Even if it's the worst possible version that works. Building on that foundation makes everything else easier when you aren't making lasagna out of spaghetti problems.
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.
I do think that using the latest hype technology is a risk and should be considered very heavily since the new language or codebase didn't have enough time to settle in and prove its worth yet.
I mean, half of what you can do with new languages, C++ probably does better if coded correctly. That's as far as I agree with the article, but I do think that having enthusiasm and passion for the job and trying to find new ways to solve problems is a good thing. I think that sure maybe some of the programmers the article writes about have gone off the deep end of the new tech hype that their own coworkers have lost themselves among the confusion but I think it's less the problem of those who try to incorporate those and instead it's the fault of the managers and higher-ups allowing things to get to this state of hell development.
I'm not saying that you shouldn't do anything new or innovative, but what I'm saying is that you should at least communicate fairly with your team and managers so they know that there's a new technology being used and understand that it will probably take time for EVERYONE to adapt to it no matter how good of a developer you are and be open to criticism and help those who don't understand the framework as good as you do.
Ever heard the saying "The overly active fool is worse than a saboteur"? (or some variant of it)
The article (at least, the first part) is describing just that. Your passion and productivity don't mean crap if the end result is a mess. You are not here to get participation trophy for a "hard work", you are here to actually make product that does what is intended to do, in the acceptable timeframe, with acceptable degree of scalability/maintainability. If it doesn't, you can take, idk, a new world record in speed running Wolfenstein, it will be as much "hard work" with as much result.
@@casusbelli9225 Yes, people who are doing a bunch of stupid shit are worse than people doing a little bit of stupid shit, but pointing your fingers at the "doing stuff" part as the problem instead of the "stupid shit" is ridiculous.
5:00, really agree with this one.
"An idiot admires complexity, a genius admires simplicity" -Terry Davis
Sometimes a road to simplicity is through complexity. Sometimes you need solve it in a complicated way to learn what needs to be done so that you can learn from it.
Sometimes you need to fall down with your face into the pavement trying to do something complex to learn that doing it the simpler way is often times more desirable@@RealRatchet
I correct you: simplicity is admired but extremely complex to present. A genius turns complex things into simple tools.
@@RealRatchet You could dedicate 402% of your brain into inventing the most energy efficient form of walking, or you could walk. One of these gets you to work on time.
Yea, so "let develop new AI just keep it simple". - Me. Just for sake of brevity it seems to be other way around.
Summary of the article:
"The worst programmers are those who are better than me, because they make me feel like a noob".
Nailed it.
Thank you for saving my time.
Yup.
"Knowing some trendy/obscure things and shoving them everywhere to show off, damn the performance and readability, is being a better programmer"
No wonder the industry is such a shitfest.
@@casusbelli9225 I call it job security. Those tire fires are very entertaining to watch. As much as this stuff seems scary. It scares proper managers just as much.
So the management issues do not just randomly correlate here, I dare say.
this was written by a malding scrum master
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
Nobody refactors the lousy code that sort of works.
Bad code gets half as expensive CPU, Memory and Storage wise every 18 months. If it fits the spec that allows 90% of the invoice to be paid... all is good. By the time a bad codebase is clear to the guys paying the bills, work needs to happening on the next code base per current trends.... it will be so much better in Rust than JS. For whom will it be better?
If it works, what manager in their right mind will allow someone to jump into that mess and open up the need for extended QA to wring out 50% more performance in a 4 months when moore's law does it without risk in 9 months. The customer accepted the application months ago....paid their bill...f them.
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.
Yeah I thought that the very core of the engineering mindset is to break a complex problem into simpler smaller problems. An experienced Lead should be able to do this in a way that everyone in the team can contribute as long as the requirements are clear.
This video embodies every reason I subscribed. Crying tears of laughter in the first 3 minutes...
And functional programming. We've all been there.
"My GOD! Look what I did with just two lines of code!"
(followed by three pages of comments to try to explain it)
I've always said to people and newer programmers that it doesn't matter if you take 10 lines of code or 1 line of code. If I can intuitively read the 10 lines and you need to explain the 1 line, the 10 lines is superior.
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.
highly skilled, but lack of wisdom.
I think that's this article is really about.
"Beautiful" codebase is useless if no one in your team understand the codebase.
@@adicandra9940 Business owners like programmers to be replaceable. Programmers don't want themselves to be replaceable. This can be seen as a class conflict.
@@adicandra9940How is it beautiful. I would call it "mystical" codebase that the team abhors touching
>I mean people that the guy in the article has described literally carry the company, especially on critical times.
If a programmer can't adhere to KISS principle, he is not a programmer, he is a code monkey. A code monkey with a time grenade, specifically.
Elegance and simplicity are part of the programming as an art. Overcomplicating due to techbro having a need to show-off is the opposite of good programming, "carrying the company" and generally software engineering.
Moreso, most of the time it CREATES those critical times, when the overcomplicated mess of the code starts collapsing on itself.
“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
Someone once said that people's understanding of the Dunning-Kruger effect is a perfect example of the Dunning-Kruger effect
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.
its not easy to refactor refactor code when is a big project believe me
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.
If the only tool you have is a hammer, everything will look like a nail.
@@BoominGame
If you have all the tools in the world, finding the right one will have exponential time complexity.
Nothing like making a simple idea very very complicated with bloated dependencies
@@dickheadrecs #everything.js
Stuff like React always makes small projects look simple. The bad news is that in most actual applications, it isn't.
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.
Stored procedures...wow...I get flashbacks.
99.999% of the data transformations are because of lack of normalization that is forced within classic databases and the inability to write joins/views by 99.999% of programmers...I see bulk selects flow by every day as a network side role. If one does not understand the power, or should I say lack of CPU cycles to present indexed and normalized data in bulk move fashion is why programmers go insane in their libraries. If oracle or mssql is your only data source, your programing tasks are considered trivial for a reason, your not attemtping to mesure a distance with knotted string in a ball.
If you as a programer cannot make a GUI stream by like wireshark for a bussiness applaication without stacks and stacks of compute, your the problem. Performance has always been from ruinously knowing the data is not thawing an exception logic event every 5th entry. The 30 year old systems performed on 4MB, your dogshit slow on 16GB.
Lot of wannabe architects make a mess where they are, then they quit to avoid facing responsibility.
@@MarcKruziknot even an architect
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 kind of programmer only exists because JS is disorganization-oriented
This is one of your best commentary videos IMHO. Loved 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.
Literally all you need to do to make kids like you is to talk to them like a normal person and encourage them when they talk about stuff they like. It's so rare for them that it pretty much makes any kid latch onto you.
@@fearedjames Yeah, kids usually quickly like me. Just showing serious interest in them is often enough.
My mom is even worse. Sometimes children from other visit us, like the childern of a friend of my mom, and usually they just don't want to leave anymore.
My mom always wonders what she's doing, because when her children (like me) were somewhere else, we were usually happy to see our mom come back.
But maybe it's also just because we don't put so much restrictions on them, like they would be allowed to play video games for hours.
(I'm actually happy if children are able to focus on something for more for an hour. The children I mentioned earlier ususally can't focus for that long on a single game)
@@porky1118 Eh, restricting kid behaviour is important. They lack the ability to be good at self moderation at that age.
0:06 - I need a TL;DR on these Rick, Brad, and Tom characters.
60 hours is insane. Take care of yourself.
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.
I am stupid
"If you can program any application in C++, you're already more sophisticated than 80% of web developers." Woohoo!
Make it 90% :P
KISS:
"Keep it stupid, stupid"
c-tier dev way over his head, trying to schmooze his way out of it. Just skill up, dude.
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 have never found an article I disagree with this much. It’s almost political. Jaded low-bar underachiever who just wants bare minimum garbage older than the rest of the team.
Sometimes we have to get away from the easy to use stuff. That being said, a good team lead spends time teaching as well
> if you try to cram the hot overcomplicated tech into a project, you are a fool
Proceeds to do a project in Rust
if it's the right tool for the job, I don't see the issue. Node was clearly an issue for the kind of traffic the app was under. Should he have used C and hate his life about the threads management, the error management without a clear happy path between threads / malloc / race conditions, etc? Or C++ which is technically even more convoluted nowadays? He could probably have made things simpler in Golang, but why should he cares? He was the one building the app and doesn't have skill issues with Rust.
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.
That _unappreciated aspect of Scrum_ praise went under the the radar and it is straight sociopathic and sick
10000% written by a project manager.
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.
Thank you for saying it. I have been in teams with horrible Scrum implementations (like everyone else), but the single good Scrum implementation which worked so well showed me that this general allergy to Scrum is just a... let's say, "experience issue", since this audience here so easily accepts the locution "skill issue" as a proper response to an argument (which it certainly isn't).
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.
That Gremlins ref at the end 😂
Mentions of Commodore bring up nice memories.
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.
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.
I think the opinion you highlight does make sense when you follow through with the belief that wash language sucks but that isn’t the source of suffering. The source of bugs and other suffering is almost always skill issues, especially in C and Rust and the latter is designed to not work until you stop having skill issues.
This is the gun > bow argument for programming and i fully agree.
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.
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.
Yeah exactly. Those incompetent managers just throw a big problem at bright but inexperienced people in order to avoid paying for expertise and those young eager people take it because they see it as a way to prove themselves. What can possibly go wrong?
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.
Sincerely,
Satan
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.
> 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
I am pretty sure that, with time, it only becomes worse. Especially since people tend to drop the fundamentals of programming in favour of readily available overcomplicated (but trendy) solutions. Webdev already is filled to the brim with such approach (hence, the whole web bloat problem), but it now slips into other areas.
DevOps is not a role, it's a team pattern. Including operations experts in the team lets them build the infrastructure the devs need. Devs don't have to mess with infrastructure. I totally agree, "DevOps should be done by people who like doing it." I think its the 'dev' in DevOps that throws people off. Yes, we use developer methods, and we write 'Infrastructure as Code' and use git and vs code, but in the end, we support the devs. Expecting devs to build CI/CD pipelines leads to hiring folks who are "jack of many trades, master of none". Much better to hire one or more infrastructure engineers, site reliability engineers, or whatever name you want to give it, to support the devs. This frees the Developers to develop.
This whole article can be summarized as: be mediocre, hate your life never dare to enjoy your job
done and doner
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 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.
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😄
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.
The problem is overcomplication
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.
hmm, perhaps i should write my server backend in C for my next project
By all means!
This article is a great example of correctly identifying a problem, but getting the cause and solution analysis COMPLETELY wrong. Prime has the right take, this is a teamwork problem. That means management should step in and fix it, because facilitating teamwork is the only reason to have management. If you want to be a good engineer, just repeat this mantra over and over in your head all day every day: "simple solution best solution". Good engineering is the process of removing complexity until only the solution remains.
Agree. In a project that lacks clear leadership, de facto leaders will arise and implement their own vision. Seemed like the article was kinda using the people who were actually attempting to provide solutions as scapegoats by painting them as the "worst type of programmer". Sure, their approaches may have been flawed and their attitudes may have needed adjustment, but management should've stepped in to correct the situation when the cracks began to show.
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.
Damn, I'm in my third year of learning informatic and agile SCRUM it the only management method they make us learn to work with...
I've never seen perspective opposed to it before, would you mind saying what you dislike about scrum?
@@bruoche work with it, and you quickly learn why majority of engineers dislike it
Your team removed the grooming session? Or am I reading that wrong?
@@lcarsos Yes, we removed groomng sessions for tickets. Instead we just have high level topics which are prioritized by product and we just start with the POC immediately by one or two people. We try to do a vertical slice of the feature (some happy path scenario). Usually that's enough to determine which things need to be done and we are gradually able to include more people in the work if needed. Or we discover it's too much effort and deprioritize it (if it's not critical).
We're also not afraid to just throw away the PoC work if the initial ideas were bad and we need a completely different approach. IMO this is the faster way in the end than trying to come up with the best architecture beforehand.
Then one person on the team (technical lead) also takes technical debt tickets and adds them to backlog. We use a kanban board and whenever someone has nothing to do they can just take something from there.
And most importantly, we do not go strictly by the process. For example if somebody thinks there's something completely different we ought to be doing they can just bring it up on Slack and we can decide ad-hoc.
Of course, I have only 4 years of experience after college so there's a lot of things I have not experienced, but so far I like this approach a lot better.
@@bruoche It's a huge waste of time. People attending meetings where they bring no value, and gain nothing from hearing what's said. And focusing on arbitrary tasks that aren't about solving the real problems. It's a specialized organization tool that is uncritically turned into something general. Much like many software frameworks. It's not all bad but there's many better ways of communicating and enforcing standards.
some dude: don't be this guy!
me: Oh man, now I'm going to be that guy so hard
Written by:
The manager who actually failed this project
Or developer who is sick of 99% of the new shit that, behind all the BS about being "hip", "new", "challenging the world of whatever" and other buzzwords, is the reinventing of the wheel by the more convoluted, messy, overcomplicated bloated methods.
Keep. It. Simple. Stupid.
"Angular Typescript was randomly intermixed with plain JS"
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 agree with you and I believe that the secret to financial stability is having the right investment ideas to enable you earn more money, investing with the right expert would free you from modern financial slavery.
YES!!! That's exactly his name (Fergus Waylen) so many people have recommended highly about him and am just starting with him from Brisbane Australia
Wow. I'm a bit perplexed seeing him been mentioned here also Didn't know he has been good to so many people too this is wonderful, i'm in my fifth trade with him and it has been super.
Though I started with as low as $15,000 actually because it was my first time and it was successful, he's is a great personality in the state
Fergus waylen is a retirement manager and investment/savings expert, in ranks with Cathie woods and Warren, has demonstrated expertise in investment strategies and has been involved in managing and providing financial guidance globally, it's all facebook .
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.
"I don't want your monoids, you can go endo-fuck off" might be my new catch phrase as a Haskell dev
bro that cyberpunk meme jump-scared me awake lol, thanks prime I needed the wake up call.
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.
I'm happy this article got published. Opens up an amazing discussion. Great criticism from ThePrimeTime!
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.
I am wondering why the guy who wrote the article is not someone in charge of programmers?
I mean it sounds like he has all the answers and knows all the problems and can do it all exactly the right way.
So why is he not putting his immense knowledge, experience, and skill to a productive use and instead sitting in the corner watching all these fail managers fail and cost the company so much money without being able to deliver anything?
Did i just hear that you would tie a customer to a certain node due to caching? Noooooooo. Do NOT do that. Write the session into a replicated cache. Every node is then stateless so they can die without taking customers with them.
Why are these programming articles often written so trashy?
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.
You're close but you're not quite right. Everyone has a tendency to conceive of themselves as regressing towards the mean. Your model explanation lacks any accounting whatsoever for the fact that (just as important in the dunning-kruger graph) the people who are much better than average tend to under-evaluate themselves as well.
In my opinion, the Dunning-kruger effect is simply that it's very difficult to evaluate yourself relative to everyone else, period. It's a statistical way of thinking that runs counter-intuitive to actual human thinking. You can't really keep inside your head an accurate perception of what's in everyone else's head.
Without having already seen the data, asking me to guess where I fall in regards to the general population at any individual task would be very difficult. And in my opinion, people read WAY too much into this phenomenon. Because why does my ability to place myself on a percentile chart matter? It really doesn't matter in any practical sense. It's just an excuse to act like a douchebag towards people who aren't very good at something. Why do you think that's the only half of the theory anyone seems to know?
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.
yes!
Agreed. I encountered a bug in a famous extension for a well established "text editor" (Yes, its starts with a v).
The code that was crashing was written in rust and you know what caused the bug? It was a None.unwrap().
Probably another one of those "Well. It will never happen. It's safe here".
Worst thing is, the code was littered with unwrap() and other blatant lack of error checks.
I didn't get much out of this. Must be the Danning-Pflueger effect at work.
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.
08:10 The way you work 60 hours a week is by neglecting other aspects of your life. That's ok when you are young, or if you let your spouse take care of the house, kids, and family (let's face it, it's usually men leaving this to their wives), and if you don't have any health condition that limits that. That is called overachieving, and doing it consistently should not be the norm.
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 don't think that is what he's saying. Dunning-Kruger Effect is where people with little knowledge and experience in a particular skill don't fully understand how much knowledge is required to achieve competency in it and therefore overestimate their current ability - which he alludes to with his comment on younger developers. The common misunderstanding with Dunning-Kruger is that people think it is related to intlelligence - but it isn't at all.
@@curtmantle7486No the common misunderstanding with Dunning-Kruger has to do with misapplying it to actual experts with the notion that actual experts will never think of themselves in those terms when in actuality as people get better at things the effect is that they become more accurate in their appraisals and so experts do indeed know that they are experts. Recent studies actually indicate that the effect isn't actually real and in fact comes from people who are misinformed vice uninformed. A flat earther thinks they know more than me about the shape of the earth while an elementary school student who has never thought about it before likely realizes they don't know. The author doesn't come out and say what I say but it is clearly implied. Why don't the other developers suffer from it (of course the face the other developers don't think they know enough to challenge the "performant" ones indicates that they at least have some level of self awareness and also shows the likely flaw in the science behind the effect itself)? The author also says later that the performance of these people ruining their projects is measurable which shows they've never read an article on software engineering and also contradicts the idea of the Duning-Kruger effect.
@@wdavid3116 it's kinda funny that people talking about Dunning-Kruger is an example of it
Scrum: preferring shitty solutions because the sprint needs to have a good result
I use semi-colons in Python
basically
based
Try bython
So management let these two push their vision of the project without any pushback or proper assessment of whether their solution fits the problem. Also I do think code should be written and documented in a way a novice programmer could follow or at least work with.
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.
Let me break this down. Here's the problem. We have an oversupply of smart people and an undersupply of interesting jobs for those smart people to do. Therefore, you see this pattern where smart people show up on the job and want to be engaged, but can't because the work isn't interesting. So they try to make it interesting by concocting ever more elaborate and complicated software systems.
Here's the solution: No mandatory work hours. If you complete your work, you go home.
Now there's an incentive to finish the job, go home, and make video games, which is what every programmer actually wants to do.
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 don’t get the problem statements like “backend and frontend were already too complex for team members to work on business requirements”.
Like… fking learn it dude, that’s your job. What else are you doing that you just decide you’re not going to work on the product that the leads have made.
Idk this architecture doesn’t sound TOO wild ‘n out. I feel for the leads here, the juniors devs were probably just lazy.
The statement that the code quality struggled and “the angular TS was randomly mixed with JS” is like absolute entry-level failure, that had nothing to do with the seniors making the product “too complex”, thats just a matter of… NOT SUCKING
Most sane JDSL enjoyer.
wdym JDSL is a perfect alternative for todays overtly bloated frameworks, once JDSL supports comments its over for React
@@ninocraft1I have started using JDSL for all of my projects and have been loving how much more time I have to play solitaire!
2:05 My God. This took me SO MUCH by surprise that I started belly laughing ahhahahahhahha
why does prime think he is one of us, we actually suck he pretends to suck for memes.
12:00 - that is comeddy gold
Blaming complexity is very dangerous. What's the delimitation between wanting simplicity vs caving to the dimwits. Overengineering is bad, idiocracy is worst.
don't be a middle-aged person with black hair sitting at the PC wearing glasses while drinking a green drink!
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
There are specific areas where Rx is good, but it's not a panacea
The problem is when all you have is an Rx library and every problem looks like an observable
@@georgehelyar Having been a hard-core observable zealot in the past, I think the problem is that observables are kind of the only abstraction Angular provides for dealing with asynchronous behavior, including things like user input. So the alternatives are clean observables, or dirty stateful imperative programming, and when faced with either learning monads or untangling a bunch of cascading assignments in an event callback, you'll choose the monad.
It really seemed cool at the time, but I had to watch a few talks that perfectly described some problems I was running into before I finally understood why it was a problem. My current take is that if you're in an Angular environment, you should still use observables to reduce complex interaction patterns into simpler ones, but you should never be doing that kind of work in your actual page or its business logic. Hide that off where you only need to touch it when there are changes to those complex interaction patterns. Ideally there shouldn't be very many of those complex observable chains anyway. If you're using React, put it in a hook.
It's still easier said than done, because with certain team makeups you might find that you can't extract the "bad" code before a junior dev on a deadline starts adding complexity to the page in a way that makes it very difficult to get rid of the observables.
Wtf. were those leads even doing if there were no requirements until the last moment? I know they tried to prepare to be able to digest any requirements that could eventually come, but.. what else could they even try?
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.
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.
Classic example of an entitled Zoomer misidentifying the issues while working under dev's that should have never been team leads.
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.
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.
The article: Mom,, can you please stop these people being smart that me an pushing me to get better? I don't want to get out of my confort zone 😭