6 ms·
The worst kind of programmer
- davedx 3y agoIt's a good discussion to have! I've been in both sides of these roles over the years. I think the problems in the article really seem to be lack of technical design or leadership though, rather than problems with individual programmers or personality types. You can't have one guy leave, another guy come in, have the same issues then blame the people. The process is broken! At any kind of head count beyond 5+ people, you need to have some kind of framework in place for choosing and deploying technology. You need someone (it could be many someones, or even the whole team) who thinks about architecture at each step of a project, especially the first part. Conversely, your org should try to intercept "architecture astronauting" early and balance simplicity with decomposition and integration goals. Managing people can be like herding cats. Managing programmers can be like herding autistic cats. But you still have to do it. The org in the article sounds like it's missing CTO/engineering management.
- gHeadphone 3y agoI love the cats analogy. It reminds me of the book even tougher than herding cats (about tech management) https://www.amusingmulcahy.com/my-first-book-even-tougher-than-herding-cats/ https://www.amusingmulcahy.com/my-first-book-even-tougher-th... No mention of autistic cats there as far as i remember!
- mojo74 3y agoAdded to my reading list. Thanks
- bluetomcat 3y agoIt happens when companies are managed by people with non-technical backgrounds. They think they can employ “autistic wizards” to solve the lowly technical problems. One such wizard initially receives all the praise and then gets so out of touch with reality that they either implement a custom TCP/IP stack or they get frenzy with the modern buzzword tools.
- pjerem 3y ago> implement a custom TCP/IP stack This but over HTTP of course, I heard it prevents issues with firewalls. Have I seen a company-made HTTP over an internal RabbitMQ instance that had to de queue messages and call registered web hooks on our multiple apps ? Yes. And when I asked the CTO why we had to do like this, because we were losing all the rabbitmq purpose, the answer was that HTTP didn’t need firewall configuration so that we could spread our architecture everywhere over the internet.
- bambax 3y agoWell yes; the problem described in the post is often found in real life: how many Angular projects are simple CRUD apps that would work just as well in PHP or ASP? But I don't think the cause is clever programmers. I think the main cause (as you say) is this: > After all, the management in business environments is usually non-technical Management in business environments is not only non-technical, it's also non-business. It specializes in managing people and timelines, without a profound understanding of either the business requirements or the technical solutions available to address them. I don't know how one promotes a culture where management is technical but that should be an important topic to focus on in many (most?) organizations.
- icedchai 3y agoI love when a “timeline” is determined without even discussing the work with the people who actually do it. It’s beyond laughable.
- pjerem 3y ago> The org in the article sounds like it's missing CTO/engineering management. Not necessarily. I’ve worked in a company where the CTO itself was encouraging those employees. He established a clear list of goals to achieve to climb to the next seniority level. To be promoted you _had_ to do stupid shit like hacking the framework (which was Angular so I let you imagine the potential), be the architect of the project, or make company-wide presentations of your original solutions. Of course, a team full of people hacking things, trying to be the architectural leader and solving old problems with "invented here" solutions can’t really exist. So you were either in the promoted hackers camp or in the camp of people trying to do their job of delivering value and quality at the lowest cost, which in a CRUD SaaS business means that most of the time you just have to do the old boring things "by the book" that have proven to just work. But if you were in this camp you were seen as underperforming because you didn’t do what was expected but also you were underperforming for real because adding a single API in the back or a component in the front was just a hell of stupid work. The "high performers" were just the people who created this hellscape because since they invented it they’d be the only ones to have a full mental model of the team’s codebase. Now I just avoid any company who promotes their team as "the most talented engineers" because it’s either false or worse. I’d rather work with average coworkers who have a life outside computers and who just want the work done by 6pm.
- bathtub365 3y agoThat sounds like a bad CTO.
- cjfd 3y agoThe problem is that an architecture is created that does not fit the problems that need to be solved. This is inevitable if lots of architecture is created before working on real requirements. TDD gets this right: start with actual requirements and extract an architecture from the resulting code so the architecture will actually apply to what is desired. Software is so flexible that that everything can be written in millions of ways. But there are also billions of ways that cause more problems then they solve. You have no chance of selecting one of the millions of working ways out of the billions of wrong ways by starting out with architecture. The numbers are just too much stacked against it.
- wredue 3y agoYeah. Functional programming happened to be trending again and our lead service bus developers decided to write Java like it’s Haskell. Now their garbage keeps crashing with stack overflows, and they complain when files are bigger than a few hundred lines. We accidentally pushed a 10,000 line file once and it brought the entire bus to a crawl for an hour. TEN THOUSAND LINES. One day, these twerps pushing this stupidity of “copy everything always cause ‘it’s easier to reason about dawg’” are gonna get theirs.
- taberiand 3y agoYeah that's not the fault of a functional approach, that's just bad code.
- solraph 3y ago> decided to write Java like it’s Haskell. I have no love for Haskell or functional programming, but the problem here isn't FP per se, it's that they tried to jam it into Java. Don't fight the language or framework. If you are using Java, write idiomatic OOP code. If you want to write FP on the JVM, then start writing Clojure or Scala. If the business won't let you write Clojure or Scala, then do it on your own time and/or change jobs.
- throwawayqqq11 3y agoPassing arguments as read-only references does impact the purity of functions from a fundamentalistic view point but, as you experienced first hand, is sometimes more or less required for performance. Looks like your FP zealots didnt learn how to compromise on that point or how to work with constness in general.
- smallstepforman 3y agoI feel confused. Even though I’ve been doing C++ embedded systems and drivers, C++ network protocols, C++ graphics engines (OpenGL and Vulkan), C++ video codecs etc, on many OS’s, all this for over 25 years professionally, I must admit I have no clue about the articles technology stack, programming techniques, languages, or architecture. Am I completely out of touch with this industry?
- sam_lowry_ 3y agoThis is contemporary Enterprise Java: Spring Boot with Angular running in Openshift.
- upon_drumhead 3y agoThe industry is made up of hundreds of different microcosms of technology stacks. Knowing a fundamental language like C++ as well as you do, you’ll be just fine.
- GoToRO 3y agoThe industry has expanded due to high demand, but the procentage of smart people in the population did not. So you have all kinds of people that should really not write any code, write code. Also managers decided to give all decision making power to people that don't even understand code: scrum masters, project managers, product owners, team leads ans so on.
- groestl 3y agoDon't worry, it's just the same the other way around :)
- colonwqbang 3y agoYou may be out of touch with web development in the "enterprise" (Java) style. Personally I much prefer working in the embedded/video/graphics area so if I never have to work with Angular/Spring that's ok with me.
- qudat 3y agoYour question is grammatically correct but doesn’t make any sense. Software isn’t an industry, it is used in every industry.
- GoToRO 3y agoThey are the best in management eyes: look, they are doing so many things. All those things are unnecessary and will need to be supported/removed in the future. The truly best are the ones that do very little indeed. We produce software, not objects. You get to save money when you use a good piece of software not when you write it. But they are seen as lazy.
- revskill 3y agoSeriously, what's the "only nessessary" for most software project ? Not CI/CD, not deployment pipelines, not complicated YAML bullshits. Testing is all you need to produce bug-free software.
- icedchai 3y agoWithout that other stuff, (CI/CD, deployment pipelines, etc.), you’ll waste so much time manually deploying. It is very error prone, especially for those who lack knowledge of the whole system. Why not automate it?
- GoToRO 3y agoThat's not what I was referring to. F.e. management brought on the project some senior dev. He did a minor framework update, reeplace one library with another even if nobody was complaining about anything and he was gone. None of the problems or technical debt the client was actually complaining was addressed. Oh, and he did some implementation that blocked the other devs, and we needed to work arround it.
- mrd3v0 3y agoThis is a brilliant way to put how I view "10X developer" mindset.
- pkolaczk 3y agoYou’re not a 10x if you can’t share your knowledge by mentoring others, writing good docs and writing code that’s easy to read and change by others. By this standard, they were not 10x. 10x is not about number of lines of code produced.
- mrd3v0 3y agoI agree, but by the looks of many social media posts it's basically a nerdy extension of the "sigma grindset" movement, rather than what you mentioned about good software engineering practices.
- 4pkjai 3y agoI worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing. I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never has any bugs, but they took longer to write it. Enjoyed working with person two, despised person one. According to management, person two was not known and person one was a rockstar.
- davedx 3y agoFor me that's very much been an experience thing. It's often not just motivation, but also that handling errors properly can be genuinely difficult compared to writing the happy paths of code. It's probably a good thing to do a training/knowledge sharing on in an org (seniors show juniors different ways to handle errors).
- heisenbit 3y agoIt is a questions of taking responsibility, willingness to pay attention and learn. We all start out with the happy path which automatically leads to plenty of learning opportunities. The question is how does one deal with them. While training and mentoring can help I believe most learning occurs while reading/reflecting on other peoples code and fixing own and others mistakes.
- burrish 3y agoPerson two sounds great to work with, would love to be like them
- DougBTX 3y ago> closer tons of tickets but his code was full of bugs Yeah, total closed ticket count is a terrible metric. If closing one ticket in a rush opens two bug tickets, that’s one ticket opened overall. Much harder to track though!
- prakhar897 3y ago
- gardenhedge 3y agoI agree they were bad devs but I don't see how scrum fixes this at all. Even if every team member got a say, they would defer to the most experienced.
- from-nibly 3y agoAs someone in this situation a lot. They always do. People generally don't want to fight the smartest guy in the room. And everyone is happy to leave responsibility with someone else.
- pkolaczk 3y agoThe examples given in the article do not match the final conclusion. This is all non sequitur argument. They chose a commonly known, boring tech stack (Spring boot and Angular) and then used them incorrectly and the project failed. And the authors conclude that choosing the tech stack was the problem. I argue the real problem was in management - two guys working alone and the rest of the team not participating and not learning until late in the game. Adding people to the project at the end of its lifecycle rarely works well. No knowledge sharing and one guy leaves, what can go wrong? Another problem is not having anything working for a very long time in the beginning. After a week of work the management should have asked for a demo and if nothing was working, they should start questioning the skills of those two „rockstars”.
- deleted 3y ago[deleted]
- sk11001 3y agoThe point of the article is buried under the bait that is the list of qualities to watch out for. The main problem was that these people overengineer things and work without any collaboration or business context. Out of the four listed qualities: Ability to find satisfaction in solving abstract problems Ability to put up many hours of work Passion in software engineering Narcissism and self-confidence Only the last one is actually a problem (and it's the narcissism really, not the confidence). The way the author has laid it out can make it look like "passionate hard-working people who like solving abstract problems" = bad. Which isn't true but it can seem like an appealing proposition if you're not that passionate/hard-working/etc.
- padjo 3y agoI find that the first three are correlated with both the best and the worst engineers I know. The last one is usually the decider. Sadly lots of hiring processes select heavily for the first three and are poor at identifying the last one.
- mobiuscog 3y agoA great article, but promotion of golang and lua as part of the answer seems somewhat disingenuous.
- gdsdfe 3y agoFunny, you can't actually get any job without leetcode these days ... But if you overcome that the problem in my opinion is that people think their problems are unique and hey maybe it is the case, for like 10-20% of us, the rest are just dealing with the same issues with a slightly different flavor
- LoganDark 3y ago> Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. Why call out Rust specifically here? CloudFlare achieved the world's first widespread deployment of HTTP/3 thanks to Rust, and they called out plenty of Rust-specific benefits that sped up the development process and provided peace of mind. Sure, if you're using Rust just because it's Rust, you'll lose sight of the big picture. This can happen in any language.
- sam_lowry_ 3y agoRust, like Scala, is a complex ever evolving language that attracts curious minds. Look at the human side of the story. Yes, teams can build great software in Rust. But Rust also attracts many people interested in playing with fancy language features. If I had a choice, I would have taken Go over Rust just because I need a different kind of people in my team.
- mobiuscog 3y agoGo often attracts similarly problematic people, who prefer to yolo 'script-like' code because it's 'simple' but becomes unmaintainable more quickly at scale. Both languages are becoming far more mainstream, but they are still in the realms of people wanting to play with 'new' languages. The correct answer is to choose a language that is maintainable by most engineers you have, and if you need something else for technical reasons, hire the new engineers first - never impose a new language on engineers without very good reason, and definitely not because "It's simple". It's often not the language that's the problem, but all of the 'clever' ways the 'clever' devs use it.
- drogus 3y agoWhat big language features did Rust get in the last few years? What big changes have you seen that changed codebases directly? Cause I code in Rust and my Rust code these days looks very similar to what I was writing a few years ago. The biggest change to the language was async/await, which was introduced almost 5 years ago. What if you compare it to Go that fairly recently got a massive new feature that can change how you write code drastically, ie. generics?
- sebastianconcpt 3y agoAll this for me has nothing to do with programming or programmers and much less to skill level. All that is superficial. What's lacking there is deep alignment before jumping into coding and too much concentrated dependencies in specific individuals instead of team. Call it process problem if you want. It's a people and culture of that team problem that downstream to a process that didn't care enough about teammates know-how transfer and mission sharing as part of the job. The outcome is a company with a project with an unsolved bus factor [1] and all the details about which tech stack enabled what are as irrelevant as their inevitable outcomes to that culture. [1] https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor
- gwnywg 3y agoYep, this sentence from the article is good summary of the problem they had: > The rest of the team observed them in admiration. They should have been included in building base, they also should spend time learning what state of the art is (since, as article says, they had time before requirements started flowing)
- Arisaka1 3y agoAs far as I know, appearances win every time, so the appearance of you being (to put it in video game terms) "the carry" is much better than you being the one who teaches others. Then we have the replaceability factor. It's not rare for someone to try to secure their spot by making themselves irreplaceable, and one way of doing this is by being the only person working on a project or the vast majority of the codebase. I'm currently onboarded in a (previously) 1-man project and I find myself learning why they designed things like that instead of learning the framework and best practices.
- sebastianconcpt 3y agoI despise seeing appearances win over substance. I feel like every time illusion trumps over reality, whoever is involved in that is making humanity be pushed one little bit closer to asking to be fooled in a massive illusory lie ala Plato's Cave (or The Matrix 1999 if you prefer).
- hasoleju 3y agoDeveloping software as a team is a completely different sport than developing software alone. Developing software alone even happens when people think they work as a team. They just split up the tasks so that each individual contributor owns their part of the codebase. Developing software as a team really means much more time is spent on discussion, writing documentation, reviewing code and explaining concepts than actually writing code. The benefit of this is: Everyone in the team has a good understanding of the code base and can contribute. The disadvantage: Not everyone likes this style of work and is comfortable with so many non conding tasks.
- antupis 3y agoAlso, it is much slower than just shipping the code. I prefer working with a pair or a team but sometimes you need to ship often and fast.
- mnsc 3y agoI'm sure there are circumstances where there's good reason to firehose thousands of lines of complex unmaintainable code. But how common is such "throwaway" projects?
- antupis 3y agoUsually when you are starting an actual new project that kinda throwaway is a very good way to understand business needs and problem domain.
- pharmakom 3y agoThis is a deeply nihilistic article. The pinnacle of software development is definitely not simple languages and boring technologies. Have we given up?
- MrBuddyCasino 3y agoCan you elaborate what exactly we‘re giving up when choosing „simple languages and boring technologies“?
- cobertos 3y agoThe ability to be more expressive, niche, and precise. As an analogy, it would be like removing the "big words" from the English language because they are not well understood, but then losing the specificity and expressiveness of having them in the first place.
- mobiuscog 3y ago"big words" are fine, so long as you are using the words that your audience understands. You need to speak to your audience. You could always use those words, and explain the definition/meaning as a side-note, which would be more inclusive without losing the expressiveness. It's often through explaining the need for a big word, that people realise there are smaller, better known words, that work just as well - they just don't look as 'clever'.
- grncdr 3y agoRemoving the big words from English is encouraged in most business communication. I think both losses are a shame, but they are conscious decisions made by people optimizing for certain outcomes. Another choice quote from the fine article: > One largely unappreciated aspect of Scrum is the interchangeable nature of team members.
- MrBuddyCasino 3y agoIn software there is no fixed common language (like english) that, with varying competence, is spoken among all participants, but the opposite: many languages, frameworks and technologies, some of which will not see the next decade. In such an environment, it seems prudent to avoid sunk costs of short-lived technologies, and instead try to reduce complexity as much as possible. I understand that this is not always satisfying, and that one wishes it was different. There is joy in elaborate expressions of language.
- oldpersonintx 3y ago"Intermediate dev" strikes again! Junior dev works in fear and tends not to make a mess Senior dev knows less code is better than more Intermediate dev knows about every tool in the toolbox but doesn't know when is the right time and place to put them to use It's an extra insult to have to follow through on their bad decisions once they leave
- axegon_ 3y ago> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. I'm sorry, what??!?!?!?
- sk11001 3y agoI don't know if I would the generalize as much as the author about how different teams operate but there is a valid point in there - with some languages you can focus on getting things done while with Rust you spend a disproportionately large percentage of your time thinking about programming language concepts.
- drogus 3y agoOut of curiosity, how many professional projects written in Rust have you worked on?
- _v7gu 3y agoI think Go creates a false sense of “getting things done” by allowing too little abstraction and increasing LOC. The writing/thinking ratio is great, but most of it is having to write 4 lines of repetitive code for every reduce that should have been one line instead
- drogus 3y agoI implore anyone that says "Go is simple therefore Go codebases are simple" to look at big Go projects like Kubernetes
- pkolaczk 3y agoHaving written a few Rust projects, I cannot disagree more. As for writing code, I am just as productive in Rust as in Java, despite having way more experience in Java (15+ years). I spend less time hunting for bugs in Rust and less time thinking „can I change that line so I don’t introduce a bug?”
- andrewstuart 3y agoWhat a pile of garbage. So you’re no meant to use generators/discriminators/whatever because they’re too fancy or something? IMO any language feature, any technology feature that is there and documented in the API is fair game to be used. The author seems to be suggesting there is some “standard” way of programming ….. not too advanced mind you …. and that anyone who uses more than some baseline set of features is setting up some crazy complex house of cards. Codswallop. What exactly is this line below which you’re a good normal sane programmer and above which you’re a narcissistic primadonna who makes write only software. Don’t write your software for a baseline of barely competent programmer …. write the best software you can according to the project priorities defined by management. And use every advanced technique you think is right for the job. As long as you strive for simplicity then whatever you need to get there is the right technique. The alternative is done stupid set of rules that go through the programming APIs and cross a whole bunch of stuff out, forbidden for being “too advanced”. Silly. You’re a professional software developer, do your job.
- mobiuscog 3y ago> What exactly is this line below which you’re a good normal sane programmer and above which you’re a narcissistic primadonna who makes write only software. Look at the rest of your team, all the other developers that have to work on the product. Write for the average capability of those, bearing in mind that employee churn will mean new people have to be on-boarded. Realise that code that is 'simple' to you, often may not be to others - you will see it thought your own. The code has to be readable and maintainable by others. > You’re a professional software developer, do your job. Exactly. That's not just about churning out clever code and moving on. It's about creating a product that can be maintained by everyone on the team. Anyone who's had to maintain a 'legacy' codebase knows exactly what this means, as they curse the names of those who came before and the stupid decisions they made... and spend far too long trying to figure out the obscure code ideas they used.
- jclardy 3y agoFrom my experience in 15 years of mobile development - there are developers out there who are more interested in building great software rather than building great products. The framework that they work in is the highest order of priority, and everything else is secondary to that. If a new requirement comes in, they will pass it off as "impossible" or give it an incredibly high estimate, when in reality, it just needs a little creativity and doesn't work in their self-imposed limitations of the application. Not to say these developers aren't useful - they are great at cleaning up and organizing messy codebases, but it can easily be taken to an extreme, at the detriment of the actual goal of the project. But again - I don't think this even applies only to developers - it is all industries. There are people who optimize things for a better end-user experience, and people who optimize things for their own personal/team work experience. Ultimately you want both once your team grows beyond a handful of people.
- Arisaka1 3y agoI know exactly the person OP is talking about, and I really want to expand on it (won't mention names): He's someone who has almost 2 years of work experience before he got his degree, meaning he worked and studied simultaneously. Because he works remotely he doesn't stop at 8 hours, I caught him working on an issue at 11 p.m. on a Wednesday night, with a Friday deadline (I know because he told me). When I told him to stop doing that cause he will drive himself to burnout he promptly ignored me, claiming that ThePrimeagen and all talented influencers endorse such behavior because it's fine to invest in your career early on. He's only chasing big firms, and wants to hit senior status before 25. He writes internal company tools in Rust, again because the internet influencers say Rust is cool, and not because there are people in the company who know Rust and can maintain it once he leaves the company (which will happen soon because again, he told me so). He thinks that people should get on his level, and that he shouldn't adapt his work to others, and jokingly threw a "people think I'm hard to work with" remark. He had a job interview where he explicitly asked if they reward high performers who work outside of working hours. His social media profile is pristine. He keeps a blog that writes for his small side-projects or because he discovered how StringBuilder works and has to analyze it. It doesn't matter if a developer would read it, what matters is the recruiters seeing him grinding. Before you think "this doesn't affect you in any way" let me clarify: Next time someone asks if you have plans to get married or have a kid, this is the person they actually look for. This is why ageism is a thing. It's not because you're old it's because being young you can afford to not work-life balance. I know that because I'm 40 years old and while I'm not in a life situation where I care about work-life balance I'm implicitly placed in the "this guy gets married soon and has a life" bucket by everyone, even if I explicitly tell them I'm a career-focused guy. It's the stereotyping based on assumptions which are in turn based on societal expectations that really gets me mad. I'm not experienced enough to make claims like OP does "people like him are detrimental to the team", however since this is capitalism and it rewards what managers think should be rewarded then it's clear which behaviors one must adapt in order to bring food to their plate. Worst or best? It is what it is.
- bilinguliar 3y agoI suspect that these types of programmers are not challenged enough at work. And this is when some devs try to entertain themselves at customers' expense. My advice to such people would be to work with the team where they are no longer the most experienced. Another option is to start a side project that can be safely used as a proving ground for all the exciting ideas.
- throwaway63467 3y agoI’ve fallen into this trap as well and try to be more mindful and pick boring, easy technologies and frameworks. Each and every time I built some (in my opinion) clever abstraction or library some other devs would struggle to use it. And they were right I guess, as I don’t want to grok other peoples homegrown libraries either. In the end software is a team game and you need a common language, and you need to realize that most programmers (maybe not the ones here) just want to solve the issue at hand in a straightforward way. That said even frameworks can be problematic, e.g. in the JS world the technology churn rate is so high that I had developers rewrite perfectly fine though a bit outdated React code bases in the latest fad framework. Those developers are dangerous too, they don’t invent their own stuff but they want to always stay on the bleeding edge, which is a recipe for disaster in most organizations.
- engeljohnb 3y ago> Appealing to management does not work. After all, the management in business environments is usually non-technical, and the worst kind are the best performers. Who should the management listen to if not to the best performers? > One largely unappreciated aspect of Scrum is the interchangeable nature of team members. I'm not trying to argue that encouraging this kind of programmer will result in better software, but if a programmer goes from "difficult to replace" to "easy to replace" by following these best practices, then maybe the problem runs much deeper than these kinds of individual programmers. Apparently following best practices is bad for job security.
- TruthWillHurt 3y agoSounds like these devs did more work than the rest of ya'll combined. When they left you couldn't match their skills and progress (perhaps if you tried to contribute instead of slacking off?) In my opinion and experience, development is done by individuals, who are slowed down by the rest. Honestly they could do without you. Perhaps if they gave those two your salary theid stay.
- albertzeyer 3y agoI somewhat identify myself as being such worst kind of programmer. I like to tackle hard problems. I like playing around with new technology. I like to try out new ideas how to solve problems. I started coding since I was a child, around 10 years old. I tend to code many hours non-stop on interesting problems. (Now with family and kids, I'm somewhat limited in doing that, though.) Many people say that they admire how productive I am and how much I accomplish. Sometimes some of the design decisions of some projects seem to be bad and lead to lots of overhead later. Basically the wrong kind of abstractions were chosen. Other parts of the software are much better and the abstractions seem to be quite nice, but this is not true for everything. (Related recent discussion here: Goodbye, clean code (2020): https://news.ycombinator.com/item?id=38566235 https://news.ycombinator.com/item?id=38566235) I often tried to discuss some of the designs with more people, but noone was really interested in this work, so to push things forward, it was still often just me doing the decisions. I think the management just does not want to invest more resources into the software development. After all, the software works and does its jobs, but it's messy and I think it holds us back in some ways. But my manager keeps saying, we are not a software company, the software is just there to solve some problem. So, how to improve myself? I was trying to improve on basic design decisions of the software. The feedback loop here is very long though, and then difficult to really pinpoint it in the end. I also tried to improve my communication skills, but here it's even harder to tell whether I improved. At least every decision I do is discussed and communicated in many ways. I definitely learned already that the simpler the solution, the better, as also this article is pointing out. But that comes back to the problem of making exactly the right kind of abstractions, i.e. the right design decisions. Often I think I overthink some of the problems now to come up with the right abstraction. I want to get back to my older habit to just do things and iterate. But I'm afraid that this again leads to more messy solutions.
- jrs235 3y agoI feel you could be me (or I could be you). I just picked up and started reading Clean Architecture by Robert C. Martin. Read that.
- cobertos 3y agoAfter the anecdote, the vibe I got of the article was anti-intellectualism applied to the programming field. I'm all for simpler, communicable code and APIs. But at the same time not everything can be solved with a junior-level technique. That doesn't mean throw a new framework at it, but it does mean explore the problem spaces, communicate possible solutions with the team, choose one, document it, move forward. Yeah, it is fun to skip some of the steps above, but usually at a big-picture detriment. You need a balance!
- dsign 3y agoI happen to disagree with this guy. The way I see it, we are paid to deal with sh*t. And I'm not saying this just of developers, but also of management and scrum masters. That's it. In my current job, I was the most versatile DevOps they hired. The guy that got assigned to bringing me up to speed wanted to use shell script to automate infrastructure creation in AWS. The lead engineer wanted to use Java , because the org ships Java code. Both of them had been working at the org. for twenty years. Then a second lead architect wanted to use Cloudformation for AWS, not CDK (which, for a project this complex, would have made sense). We had to negotiate, and ended up writing Python scripts to generate Cloudformation because let's face it, nobody wanted to edit a single .yml file with a hundred thousand lines of infrastructure code and shell-script nested in it. Six months later, the lead architect who forbade us from using CDK (a consultant) came back and said, "we should use CDK, it's so much better than cloudformation and your home-made scripts." I still want to punch him on the face. But! I don't think that any of us is on the wrong when we say "X". We just do it from our best experience. We are paid to listen to the "Y" the others have to contribute, to do "Z" at the end, and to deal with the consequences, all of it as best we can.
- mrkeen 3y agoIf you're ever criticising other devs for being narcissistic and thinking they know best, while simultaneously looking down on them, you need to take a long look in the mirror. Doubly-so if you start invoking terms like 'Dunning-Kruger'. As if they're so wrong and you're so right - there must be a psychological explanation for why they don't see things your way.
- sesm 3y agoI won't call this kind of programmer good or bad, IMO this is just the result of 2 factors: 1. This specific person leaning towards being a contractor rather than employee. They are more focused on solving technical problems and improving technical skills, but not learning the problem domain, their company's business model and organisational structure. 2. Never being personally accountable for the result of their work, because the company takes teams/departments accountable, instead of individual people. Number 1 by itself is not a bad thing. Number 2 will be fixed as soon as this developer works for some time as a real contractor or if the organisation gives him a 1-man project and holds him accountable for it. After that they will learn to make sane technology and architecture decisions.
- CipherThrowaway 3y agoThe author was on a mismanaged project and his takeaway is to blame his fellow devs rather than hold management accountable. In fact, he does not even seem to recognize the existence of a managerial issue. This whole article reeks of imposter syndrome. Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad, and that the author's inability to understand technologies like Rx, validation and testing frameworks is actually a hidden strength because it makes him some perfectly interchangeable lowest common denominator developer. I hate/hated working with Rx, but it is fundamentally not challenging or complex. This story is common because the types of people who are capable of single-handedly building large parts of a software product in a short time are naturally the ones who are "hyper-productive" and leveraging a tonne of different technologies and paradigms. The unexceptional "slow and steady" devs are usually not capable of having that kind of impact. When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce. Ultimately, the onus is on businesses to avoid crutching themselves entirely on a single developer's output. But there are a heap of shitty businesses that have no method for delivering software other than to let singular, highly motivated and passionate developers "go HAM" on the codebase with no oversight. These businesses deserve to fail, and the unmaintainability of the code base after the departure of their key players represents the correction of a market anomaly. >Then suddenly, the frontend lead quit for greener pastures What does this even mean? Key personnel do not "suddenly" quit.
- moffkalast 3y agoThe main management issue with this project sounds like the lack of prototyping while requirements are unknown. Until they are rock solid every piece of code written should be considered expendable. I bet the guy suddenly quit once it became obvious that they'd have to maintain a poorly fit monstrosity and management wouldn't support a full rewrite that was badly required now that they knew what they actually needed. And because they probably got a better paid offer from some other place where they could build something from scratch again. Or maybe I'm just projecting, lmao.
- pjerem 3y ago
- shermantanktop 3y agoThere’s a little “tall poppy” syndrome in this article. The two hotshot engineers who are the villains are clearly out of step with their teams, but their teams sound like they might be conservative clock-punchers who resent the existence of any new technology which might require them to grow a bit. The two attitudes represent extremes, and most people will be in the middle. I’m the agitator on some projects, and I’m the voice of caution on others.
- MattPalmer1086 3y agoThe main problem seems to be really poor process. They told or were willing for their leads to start building stuff out on their own. The rest of the team were "slacking off because business requirements were in the works". They had no review of what the leads were doing. They did not involve the rest of the team in the design and build of the frameworks. The leads, also in the absence of firm business requirements produced highly abstract systems that could cater to many different requirements. The rest of the team couldn't understand it and it was bug prone (and presumably hard to debug). I assume that these frameworks had to be ready by the time the fabled business requirements were finally produced, so there would be some time pressure to deliver them. I have no idea whether the leads bear much responsibility here from what was written. I do know that the way they write software is very likely to produce this kind of result.
- globular-toast 3y agoIf one of these "worst kind" developers is messing up the team then it's not a good team. You wouldn't want a team composed entirely of this type of programmer but, equally, you wouldn't want one composed entirely of the 9-5 bish-bosh-bash type programmer either. This kind of analysis makes it seem like not only a binary system but a one-dimensional one too. People are multi-faceted and each individual fits somewhere on a multi-dimensional space. Some people like to talk to users, others prefer to talk to technical peers. Some like to break down problems into their essence, others like to do literally what they are told to do. Some like to work on honing their tools and techniques, others prefer to learn something once and keep using it forever. Ultimately you bring out the best in someone if you can get them doing what they like doing. The "best" people in any field are those that are there because they like doing what they are doing. The ones that struggle are those that are doing it simply as a job that pays. A good team will bring out the best in everyone.
- a_random_user 3y agoWhile I have seen this pattern occur in many software projects I have worked on, I find your implied solution cannot possibly work; bringing everyone to the lowest common denominator can not possibly yield extraordinary results. The example you put forth, namely rust vs golang is great; rust is an extraordinary tool.. in the right hands. So no, it is not for the average programmer. You need years of experience to see why rust is a great language and framework. To understand the why. Instead of ditching the Jedi and the light saber with it would be a better approach to understand how to leverage the extraordinary individual without alienating the entire base team. Define boxes where they can contribute as individuals who own key components.. alone. Team work is not for everyone ;-)
- ChrisMarshallNY 3y agoHmm... If you remove that last line (well, truth be told, a few folks probably earned that, too), it pretty much describes the membership of every team I've worked with, for over 35 years, and I've worked with some big, interdisciplinary, high-functioning, geographically-distributed teams. Different strokes, for different folks, I guess.
- Tainnor 3y agoThe kind of anti-intellectualism that is espoused by this blog post is what sometimes makes me want to leave this profession. Certainly, there are many people who overcomplicate solutions - for a myriad of reasons. The idea that therefore it is suspicious to be passionate about software engineering or that one should work as an interchangeable DevOps cog is deeply saddening however.
- sam_lowry_ 3y agoI always suspected that the famous 20% side project time in early Google was a trick to divert intellectuals from shitting into production code.
- anon-sre-srm 3y agoLet's refine the archetype: the pseudo-talented jerk, cowboy coder, workaholic snob. Demographics doesn't have anything to do with it; it's an attitude problem leading to all manner of manageability and team morale problems. These types of people are unwilling to listen to others and don't consider the needs or abilities of others on the team. They just do their own thing, overengineer things, and knowledge hoard with little or no documentation. It's sad to say but many Ruby developers circa 2011 fit this stereotype because they drank their own KoolAid.
- jvlake 3y agoThe worst kind of programmer is the non-technical manager that once learned a little sql or JavaScript.