11 ms·
Go ahead, write the “stupid” code
- throwy98888 1y agoI appreciate the sentiment, but "There is no stupid code" is the dumbest sentence I've ever read.
- rabbitlord 1y agoYeah, I think he’s trying to equate it to something like “there are no stupid questions.” That’s a pretty silly analogy, but you get the idea.
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- xboxnolifes 1y agoI think the people who think there is no stupid code don't actually ever witness truly bad code. The worst code that they come across is, at worst, below average. And since that's the worst they see, it gets mentally defined as bad.
- deadbabe 1y agoThat’s a charitable interpretation. The other more pessimistic one is that they only see stupid code, which cannot be made any stupider.
- xboxnolifes 1y agoI think that's basically an impossibility, unless the only code they look at is from people who have 5 minutes of coding experience and attempt to get working code from vibes (without the LLM). Even suggesting this makes me think you haven't even seen truly stupid code. I'm talking code from people with no programming experience, trying to contribute to open-source mod projects by pattern matching words they see in the file. They see the keyword static a lot, so they just put static on random things.
- deleted 1y ago[deleted]
- PinkMilkshake 1y agoMaybe you don't read much, but it's obvious they weren't making some universal statement about code. They are referring to the code you write when you are just experimenting by yourself, for yourself. The point is to not let irrelevant things like usefulness, quality, conventions, etc. limit just tinkering and learning.
- Swizec 1y agoStupid code is fine. Make it work/exist first, you can make it good later.
- Jensson 1y agoHe will counter with "There are no stupid sentences"!
- pluto_modadic 1y agowhen you're paralyzed into not putting anything on the page, it's important to just get the dumb idea onto the IDE and refactor from there.
- VladVladikoff 1y agoThis is a particularly bad mobile layout. Fix your margins.
- grugagag 1y agoAt least on IOS, if you double tap the text it’ll fill the viewport just nicely.
- FearNotDaniel 1y agoPartially true, in that on Safari on iOS, you can use that to enlarge the text. But that doesn't change what's really broken about the layout, which is that it forces the column width to allow only a small number of words-per-line, which is what makes for uncomfortable reading. Another Safari-on-iOS option would be to use the built-in "Reader" function, which re-flows the text into a cleaner layout.
- ForOldHack 1y agoI get more done by writing the stupid code, and fixing it, than junking the old code... but every now and then I can see clearly a structure for a rewrite, and then I rewrite, but its rare.
- anon-3988 1y agoI feel like people should be writing stupid code, and in the case where its a compiled language, we should ask compiler or the language for better optimization. The other day, I was writing a check of a struct that have certain structures (protobuf probably have something like this) struct S { int a; int b; int c; int d; int e; /* about 15 more members */ } so I wrote const auto match_a = s.a == 10; const auto match_b = s.c == 20; const auto match_c = s.e == 30; /* about 15 more of these */ if (match_a && match_b && match_c) { return -1; } Turns out compilers (I think because of the language) totally shit the bed at this. It generates a chain of 20 if-else instead of a mask using SIMD or whatever. I KNOW this is possible, so I asked an LLM, it was able to produce said code that uses SIMD.
- stillworks 1y agoWhy is this a struct and not an array of ints ?
- bitwize 1y agoI'm working on in-kernel ext3/4fs journalling support for NetBSD. The code is hot garbage but I love it because of the learning journey it's taken me on: about working in a kernel, about filesystems, etc. I'm gonna clean it up massively once I've figured out how to make the support complete, and even then I expect to be raked over the coals by the NetBSD devs for my code quality. On top of that there's the fact that real ones use ZFS or btrfs these days, and ext4 is a toy; like FAT, by comparison, so this may not even be that useful. But it's fun and lets me say hey Ma, I'm a kernel hacker now!
- mig_ 1y agoExt4 is most certainly still in use and not a toy. Its trusted. It takes a lot for folks to adopt a new file system. I worked on a research topic in grad school and learned about holes in files, and how data isn’t removed until the last fd is closed. I use that systems knowledge in my job weekly. A tip. Kernel development can be lonely, share what you are working on and find others.
- bluGill 1y agohe said netbsd - there I would expect ext4 to be considered a toy even though it is used a lot in linux land. Different worlds.
- mitchbob 1y agoI'm reminded of the quantity vs. quality groups in a photography class: https://sebastianhetman.com/why-quantity-matters/ https://sebastianhetman.com/why-quantity-matters/ Do stuff, and you learn stuff. Go play.
- x3n0ph3n3 1y agoQuantity has a quality all its own.
- pvdebbe 1y agoIt worked for Garry Winogrand, for one.
- godelski 1y agoWhile I generally agree with the conclusion of that, I think it might be a bit too naive. The quantity group has a trivial way to "hack" the metric. I can just sit there snapping photos of everything. I could just set up a camera to automatically snap photos all day and night. To be honest, if I'm not doing this at a stationary wall there's probably a good chance I get a good photo since even a tiny probability can be an expected result given enough samples. But I think the real magic ingredient comes from the explanation > The group never worried about the quality of their work, so they spent time experimenting with lighting, composition, and such. The way I read this is "The quantity group felt assured in their grade, so used the time to be creative and without pressure." But I think if you modified the experiment so that you'd grade students on a curve and in proportion to the number of photos they took then the results might differ. Their grade might not feel secure as it could take just one person to communicate that they're just snapping photos all day as fast as they can. In this setting I think you'd have even less ability to explore and experiment than the quality group. I do think the message is right though and I think this is the right strategy in any creative or primarily mental endeavor (including coding). The more the process depends on creativity the more time needs to be allocated to this type of exploration and freedom. I think in jobs like research that this should be the basis for how they are structured and effectively you should mostly remove evaluation metrics and embrace the fundamentally ad hoc nature. In things like coding I think you need more of a mix and the right mix depends highly on the actual objectives. But I wanted to make the above distinction because I think it is important if we're trying to figure out what those objectives are.
- ipaddr 1y agoToday its vibe stupid code.
- Existenceblinks 1y ago> Fast forward to today. I’ve been doing a dive on JavaScript/TypeScript and different runtimes like NodeJS and Deno, That's why. If all codes in a project are stupid, there's no stupid code indeed relatively. Go read Linux kernel mailing list.
- Tenemo 1y agoAnd reading the Linux kernel mailing list would allow him to... do what exactly? And by when? Compared to writing simple, working, usable apps in TypeScript, immediately after reading about how Deno/TypeScript/etc. work?
- mashpoe 1y agoIt would allow him to brutally roast anyone who submits a sub-optimal merge request.
- bitwize 1y agoLinux still works by email-submitted patches, the workflow for which git was originally designed. And if an unacceptable patch made it to Linus's desk, someone downstream hasn't been doing their damn job. The submaintainers are supposed to filter the stupid out, perhaps by more gentle guidance toward noob coders. The reason why Linus gets so angry is because the people who let it through should know better.
- Existenceblinks 1y agoTo avoid writing stupid code since they will see qualified people put reason on why some codes are "garbage" (I'm not saying this).
- 29athrowaway 1y agoThe Kernighan law says debugging code is twice as hard as creating it. Therefore, if you push yourself to the limit of your abilities to create the most clever code you can, you won't be able to debug it.
- AdieuToLogic 1y ago> The Kernighan law says debugging code is twice as hard as creating it. > Therefore, if you push yourself to the limit of your abilities to create the most clever code you can, you won't be able to debug it. If only advocates of LLM-based code generation understood this lemma.
- bubblyworld 1y agoIs LLM output the kind of clever we're talking about here? I always thought the quote was about abstraction astronautics, not large amounts of dumb just-do-it code.
- marcosdumay 1y agoIt applies to LLM code, but if you take the law at face value, it's a very damaging one. Cleverness should be used to make your code easier to verify, not harder. He said it with a very specific idea in mind, and like most of software engineering "laws", if you know enough to know when to apply it, you don't need the law.
- threatofrain 1y agoNo, it just means you'll be spending extra time debugging it. The most clever code is often cleverness which isn't from you, but derived from the field over time.
- protocolture 1y agoWhere did you study games? Seems like we have similar trajectories.
- analog31 1y ago>>> When I finished school in 2010 (yep, along time ago now), I wanted to go try and make it as a musician. I figured if punk bands could just learn on the job, I could too. But my mum insisted that I needed to do something, just in case. Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. My mom also talked me out of it. Her argument was: If there's no way to learn it in school, then go to school anyway and learn something fun, like math. Then you can still be a rock star. Or a programmer, since I had already learned programming. So I went to college as a math major, and eventually ended up with a physics degree. I still play music, but not full time, and with the comfort of supporting myself with a day job.
- grugagag 1y agoLuckily you can still pursue being a musician without all the pressure of having to be successful. On this road, one day you are free to declare your own success to yourself
- analog31 1y agoIndeed. On the other hand, I also know my limitations, since roughly half the people I play with are pro's with music degrees. And I'm still trying to improve. I'm inspired by the quote from Pablo Casals when he was in his 90s. They asked him why he still needed to practice, and he said: "Because I'm finally beginning to see some improvement."
- bitwize 1y agoMaybe if the internet and piracy hadn't fucked artists over, they could have made decent money as a musician selling their work without having to be a major-label superstar. Alas, we do not live in that timeline.
- analog31 1y agoAh, one of the luxuries of not having to support myself from music... I have no interest in making recordings. That audience means nothing to me.
- sanj 1y agoThis reminds me of the (excellent!) book by Jamie Buck: https://pragprog.com/titles/jbmaze/mazes-for-programmers/ https://pragprog.com/titles/jbmaze/mazes-for-programmers/ They write a maze algo in any new language they learn just to learn bits of the language.
- lycopodiopsida 1y agoA modern variant would be to do a year id Advent of Code in the new language.
- noduerme 1y agoI like this philosophy. It's interesting to me that the author writes about trying deno, specifically out of curiosity for compiling binaries with it, because that is something that's been specifically tickling the back of my mind for awhile now, but I've had no real reason to try it. I think this gave me the motivation to write some "stupid" code just to play with it.
- braebo 1y agoBuns faster and the binaries are a bit smaller last I checked.
- codazoda 1y agoI would say that much of my code starts out stupid and, hopefully, becomes better with refinement.
- mock-possum 1y agoFirst do it, then do it right, then do it better.
- amatecha 1y agoYeah! That's great, thank you! I will share this quote with a couple people with whom I've discussed this topic recently :)
- ctxc 1y agoThe more popular quote ime is "make it work, make it right, make it fast" (1983!) https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
- jama211 1y agoOr just ship it, always an option
- deltarholamda 1y agoThe graphic design version of this is "Get it done, make it beautiful," but it works for code too. I used to get hung up on things like doing a loop when a ternary operator would work. "Somebody is going to see this and be rude about it." But sometimes you write code how you're thinking about the problem at the time. And if you think of it as a loop, or a series of if statements, or whatever, do it that way. If it makes you feel better, note it in a comment to revisit later. And if somebody is rude about it, so what. It's not theirs, it's yours.
- amatecha 1y agoFor sure. I'd argue to write the "stupid" code to get started, get that momentum going. The sooner you are writing code, the sooner you are making your concept real, and finding the flaws in your mental model for what you're solving. I used to try to think ahead, plan ahead and "architect", then I realized simply "getting something on paper" corrects many of the assumptions I had in my head. A colleague pushed me to "get something working" and iterate from there, and it completely changed how I build software. Even if that initial version is "stupid" and hack-ish!
- tacitusarc 1y agoI think this is mostly true, but also I’d highlight the necessity of having a mental model, and iterating. I think it is common for a programmer to just start programming without coming up with any model, and just try to solve the problem by adding code on top of code. There are also many programmers who go with their first “working” implementation, and never iterate. These days, I think the pendulum has swung too far from thinking about the program, maybe mapping it out a bit on paper before writing code.
- withinboredom 1y agoMy philosophy: 1. Get it working. 2. Get it working well. 3. Get it working fast. This puts the "just get it working" as the first priority. Don't care about quality, just make it. Then, and only once you have something working, do you care about quality first. This is about getting the code into something reasonable that would pass a review (e.g., architectually sound). Finally, do an optimization pass. This is the process I follow for PRs and projects alike. Sometimes you can mix all the steps into a single commit, if you understand the problem&solution domain well. But if you don't, you'll likely have to split it up.
- katrotz 1y agoSlight variation: - Make it work - Make it right - Make it fast
- mananaysiempre 1y ago
- boriselec 1y agoAlso read "stupid" code :) I didn't know about Deno and streams, but this looks fine const file = await Deno.open("huge-quotes.txt"); const quotes: string[] = []; await file.readable .pipeThrough(new TextDecoderStream()) .pipeThrough(new TextLineStream()) .pipeTo(new WritableStream({ write(line) { quotes.push(line); } }));
- brabel 1y agoLooks like straight out of Dart.
- brunooliv 1y agoI both agree and disagree with this post, but I might be misunderstanding it. Near the end, it states: “Enjoy writing it, it doesn’t have to be nice or pretty if it’s for you. Have fun, try out that new runtime or language.” It doesn’t have to be nice or pretty EVEN if it’s NOT for you. The value in prototyping has always been there and it’s been very concrete: to refine mental models, validate assumptions, uncover gaps in your own thinking (or your team’s), you name it. Unfortunately it feels that the pendulum has swung in the completely opposite direction. There’s a lot of “theatre” in planning, writing endless tickets and refining them for WEEKS before actually starting to write code, in a way that’s actively harmful for building software. When you get stuck in planning mode you let wrong assumptions grow and get baked in into the design so the sunken cost keeps rising. Simply have a BASIC and SHARED mental model of the end goal with your team and start prototyping. LLMs have made this RIDICULOUSLY CHEAP. But, the industry is still stuck in all the wrong ways.
- awesome_dude 1y agoFor my money, certain types of software shouldn't have tests, too much planning, or any maintenance whatsoever Prototypes (start ups) rarely have the luxury of "getting it right", their actual goal is "getting it out there FAST to capture the market (and have it working enough to keep the market)" (Some - apologies but I'm not a game dev enough to be able to say what types this applies to) Game devs - they're more or less build it, ship it, and be done with it, players tend to be forgiving of most bugs, and they move on to the next shiny thing long before it's time to fix all the things. Once the product has traction in the market, and you have paying customers, then it's time to deal with the load (scale up) and bugs, I recall reading somewhere that it's probably best to drop the start up team, they did their job (and are now free to move on to the next brilliant idea), and replace them with a scale up team, who will do the planning, architecting, and preparation for the long term life of the software. I think that that approach would have worked for Facebook (for example) they had their PHP prototype that captured the market very quickly, and (IMO) they should have moved through to a scale up team (who could have used the original code as a facade, strangling it to replace it with something funky (Java/C++ would have been what was available at the time, but Go would be what I would suggest now)
- 1y ago
- brabel 1y agoShame that the writer didn’t tie up the initial story about waiting to be a musician without knowing anything about that with the end of the story. Also, 2010 was just yesterday my young friend :)
- p_zuckerman 1y agoEven if the code is for yourself or for a collaborative team for a project or for a company the quality matters. Also the software replicability, reproducibility and reliability are significant indicators for viable code and guaranteed results
- Tade0 1y ago> It’s small, it’s dumb, and there were probably plenty of options out there. Oh, this sort of "dumb" code. That is just exercise. It bothers me that in this field we don't think we should rehearse and exercise and instead use production projects for that. Actual dumb code is one that disregards edge cases or bets on things being guaranteed when they're not.
- epolanski 1y ago@author the blog scales poorly on smaller devices. The header doesn't fit the screen, margin's too big and lines are too crammed (line height needs a bit mor love). https://i.imgur.com/Ev6Ea1b.png https://i.imgur.com/Ev6Ea1b.png
- atoav 1y agoOne thing I have found to be a very valuable habbit is to first think about what your software has to do on paper and draw some shitty flow charts, lists and other things, without too much care about whether you will do it (especially if it isn't software that you strictly need to do for some reason). Whether an idea is good or not can often only be judged when it becomes more concrete. The actual finished project is as concrete as it gets, but it takes time and work to get there. So the next best thing is to flesh it out as much as possible ahead and decide based on that whether it is worth doing it that way. Most people have the bad habit of being too attached to their own ideas. Kill your darlings. Ideas are meant to be either done, shelved or thrown into the bin. It doesn't do any good to roll them around in your head forever.
- simultsop 1y agoI do not believe that the real struggle is "starting", nowadays, since AI impresses 90% that is able to complete a task. We struggle in architecting the whole thing we want to start.
- dgb23 1y agoI agree but there are certain types of unnecessary stupidity, which feel more easy at at first, but hurt more than they help very quickly (measured in amount of code): The first one that comes to mind relates closely to naming. If we think about a program in terms of its user facing domain, then we might start to name and structure our data, functions, types too specifically for that domain. But it's almost always better to separate computational, generic data manipulation from domain language. You only need a _little bit_ more time to move much of the domain specific stuff into your data model. Think of domain language as values rather than field names or types. This makes code easier to work with _very quickly_. Another stupidity is to default to local state. Moving state up requires a little bit of planning and sometimes refactoring and one has to consider the overall data model in order to understand each part. But it goes a long way, because you don't end up with entangled, implicit coordination. This is very much true for anything UI related. I almost never regret doing this, but I have regretted not doing this very often. A third thing that is unnecessarily stupid is to spread around logic. Harder to explain, but everyone knows the easy feeling of putting an if statement (or any kind of branching, filtering etc.) that adds a bunch of variables somewhere, where it doesn't belong. If you feel pressed to do this, re-consider whether your data is rich enough (can it express the thing that I need here) and consistent enough.
- jstanley 1y ago> we might start to name and structure our data, functions, types too specifically for that domain. I once worked on a Perl script that had to send an email to "Harry". (Name changed to protect the innocent). I stored Harry's email address in a variable called "$HARRY". Later on a second person (with a different name) wanted to get the emails as well. No problem, just turn the scalar into an array, "@HARRIES". I thought it was very funny but nobody else did.
- globular-toast 1y agoYou should write stupid code, but you should write good code too. Writing stupid code is like walking to the shop. You're not going to improve your marathon time, but that's not the point. It's just using an existing skill to do something you need to do. But you should also study and get better at things. If you learnt to cycle you could get to the shop in a third of the time. Similarly, if you learn new languages, paradigms, features etc. you will become a more powerful programmer.
- kvnlst 1y ago"In the beginning you always want the results. In the end all you want is control."
- LogicArsenal 1y agoIt's like riding a bike. You need to start in a low gear and get some momentum - even if you are going in circles. Starting from zero in the highest gear is difficult and hard to ballance. Once you have some speed, everything gets easier.
- rafaelbeirigo 1y agoYesterday I spent the entire day working on a lib to create repos in Github from inside Emacs. It was the first time in 3y that I had touched it. When googling, I saw potential candidates that were much better than my simple one. But I kept going, for the pleasure of making my own thing. I learned a lot, and felt very accomplished, even if, at the end, it was messy, and I'll have to go back and reorganize it. It feels like making _my_ thing, even if it is drawing my copy of Monalisa.
- ourmandave 1y agoIs this one of those shortened titles? Like the original was: Go ahead, write the "stupid" code, I dare ya!
- dvcoolarun 1y agoI believe "stupid code" is useful for sticking concepts or quick prototypes together. But for strategic decisions, having a well-researched document (a PRD or similar) helps as a starting point for iteration, and the approach you take will be influenced by your team's culture.