19 ms·

Software development topics I've changed my mind on

• z33k 2y ago
  How come a fully typed ORM is the devil, if we agree we want a typesafe codebase for our mixed experience dev team? I have had positive experiences with Prisma. It just works.
  • zamalek 2y ago
    I personally draw a distinction between micro-ORMs and ORMs. A micro-orm will simply take a strongly typed flat struct and map it into the set of parameters for a query, and likewise map a single row out to another flat struct (or enumerate/iterate while doing so). They may even include insert, update, and delete helpers that deal with a single table. This is what 90% of Prisma does and is the Good Parts. Migration generation is also good (but can be dangerous, e.g. deleting columns). I'll call out query generation separately, as it is a lesser evil (in my opinion). This falls under a larger peeve of mine, which is using data (JSON, YAML, or this[1]) as programming languages. Using data as a programming language sucks. Tooling (compilers, LSP, etc.) are typically absent, meaning that mistakes very much become a runtime issue (not really a problem for Prisma). The deeper problem is that you'll run into limitations and will: either have to drop down to SQL (tricky given that you've rarely used it thanks to using ORMs to generate all your queries), or kludge/hack it up in order to remain in the ORM land. There's also lines of code and readability to contend with, the second Prisma example (the first is on my shit list for reasons further down): const result = await prisma.user.findMany({ where: { OR: [ { email: { endsWith: 'prisma.io', }, }, { email: { endsWith: 'gmail.com' } }, ], NOT: { email: { endsWith: 'hotmail.com', }, }, }, select: { email: true, }, }) vs. SELECT u.email FROM users u WHERE (u.email LIKE '%prisma.io' OR u.email LIKE '%gmail.com') AND u.email NOT LIKE '%hotmail.com' Just write the fucking SQL. The objectively bad parts are one or more of the following: * Change tracking: magically being able to update a value returned by the ORM and calling `save` to write it back to the DB. * Object graphs: magically accessing related objects in memory, e.g. `order.orderlines` or `order.address.city.state`. Relational databases (SQL) are not graph databases (in-memory object hierarchies). They are orthogonal concepts. Just throwing whatever you have as your classes into your database is neglecting to think about how your data is stored. This will come back to haunt you. You might claim that you can do the careful design using classes, and I would believe you, however, those juniors you mentioned aren't going to have the knowhow (because they've been shielded from SQL by ORMs their entire career and so don't understand how to make good databases). Case in-point, back to that Prisma example shown earlier. Any ideas what's actually wrong with that query, besides the pointless hotmail check? Both the original and my conversion have the same serious issue that stems from not designing the database. [1]: https://www.prisma.io/docs/orm/prisma-client/queries/filtering-and-sorting https://www.prisma.io/docs/orm/prisma-client/queries/filteri...
• Terr_ 2y ago
  > Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Exceptions are a subset of all Exceptions. To throw them, they must be part of the function's type signature. To call that function, the caller code must make some kind of decision about what to do when that Checked Exception arrives. [0] It's basically another return type for the method, married with the conventions and flow-control features of Exceptions. [0] Ex: Let it bubble up unimpeded, adding it to your own function signature; catch it and wrap it in your own exception with a type more appropriate to the layer of abstraction; catch it and log it; catch it and ignore it... Alas, many caught it and wrapped it in a generic RuntimeException.
  • dustingetz 2y ago
    remind me why they don’t work? because “throws Exception” propagates virally to every method in the codebase?
    • rad_gruchalski 2y ago
      Well, if you don’t handle them then… yes? What else can be done?
      • karatinversion 2y ago
        There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...
        • jkrejcha 2y ago
          With regards to I/O, there are generally any number of weird errors you can run into, file not found, directory exists, host unreachable, permission denied, file corrupt, etc etc. Like anything file related will be able to throw any of those exceptions at almost any point in time. I think IOException (or maybe FileSystemException) is probably the best you can do in a lot of I/O cases unless you can dedicate time to handling each of those specially (and there's often not a lot much more you can do except for saying "Access is denied" or "File not found" to the user or by logging it somewhere).
• cies 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL This week wrote an article on this, since I found there's a lot to explain wrt this topic: https://dev.to/cies/the-case-against-orms-5bh4 https://dev.to/cies/the-case-against-orms-5bh4 On HN: https://news.ycombinator.com/item?id=42922014 https://news.ycombinator.com/item?id=42922014
  • MisterKent 2y ago
    I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?
    • cies 2y ago
      I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL. While I have not used EdgeDB, I have used Hasura, which I really liked. Wrt the syntax of queries, I know of https://prql-lang.org https://prql-lang.org which is kind of similar of EdgeQL. Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in the linked article). Wrt my thoughts: the EdgeQL queries are usually still strings (no compile time type checking, not IDE tooling). With Hasura the GraphQL interface (that EdgeDB also supports) allows one to generate a client library based on the GraphQL schema: this allows one to have compile time checks on the queries, which is really neat.
      • cluckindan 2y ago
        If you like GraphQL and are looking at databases, try Dgraph community edition some day.
      • MisterKent 2y ago
        This is days old, but edgedb does allow generating a fully typesafe query builder package that is schema aware. At least for typescript, I haven't tried it with other languages yet. Edgedb ends up being an extremely performant ORM if used that way. And since your database is fully aware of your object graph, it's just as or more type safe than graphql.
• greener_grass 2y ago
  The author learns that Java is not a Functional Programming language; lambdas ain't enough!
• cies 2y ago
  > Gradual, dependently typed languages are the future I really interested why the author thinks this. I've seen the general sentiment wrt "the future" go from C to C++ to Java to Ruby to JS (also server-side) and Python. My own sentiment went from Ruby to Haskell to, well, Kotlin I guess... I looked into Idris (dependently typed), but did not think it would fit the Overton window[1], to be a reasonable expectation for the future. 1: https://en.wikipedia.org/wiki/Overton_window https://en.wikipedia.org/wiki/Overton_window
  • samsartor 2y ago
    Dependent typing is mainly just that feature of Typescript that `x: number | null` becomes just `x: number` inside an `if (x != null) { ... }` statement. If you dig deeper into the type theory, it gets really interesting and complicated because types themselves can start to include any arbitrary code. And that's where Idris comes in! But after doing a whole project on Idris in college, I agree it is way outside the overturn window. Python and typescript rightfully keep it simple.
    • wk_end 2y ago
      Narrowing, as TypeScript calls it, isn't dependant typing - it's basically just a form of pattern-matching over a sum type.
  • lucasoshiro 2y ago
    > to C++ to Java to Ruby to JS (also server-side) and Python I feel that languages are going back to static typing. Newer languages such as Go, Rust, Kotlin, Swift, Dart, Nim etc are all statically typed (I can't remember a language from the last decade that is dynamically typed). Even some dynamically typed languages are moving towards a more static typed system: for JS we have TS, and for Python we have type hints
• physicsguy 2y ago
  > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. I just want to set up a linter that’s standard for the language and let CI deal with it. Anything other than that is mental to me.
  • pgsandstrom 2y ago
    Agree. People who join a project and insist on changing the default styling configs are insane weirdos. But people who dont want to use any styling solution on a project with several developers are EVEN MORE insane weirdos.
• oniony 2y ago
  >People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Um, "minutiae", erm, uh.
• pjc50 2y ago
  > Good management is invaluable. (I went most of my career before seeing it done well) Yes, and: it's difficult to describe, must be led from the top, and extremely difficult to evaluate from above.
  • bayindirh 2y ago
    If the person at the top can come down for a coffee with people who endured some bad management, and ask honest, non-loaded three questions, it can be measured qualitatively but with very high accuracy. The three questions are: - What should we start doing? - What should we continue doing? - What should we stop doing? This is an immensely powerful tool. Thanks to the awesome person who introduced me this. Addenda: "Theory X" is something really bad. If you're working with a team which responds positively to Theory X, you have much bigger problems IMHO.
    • floydnoel 2y ago
      sounds just like the advice in the book "The Coaching Habit" which i thought was great
    • franktankbank 2y ago
      What insight does an IC have on what the person at the top even does? I can basically only comment on my interactions with direct management and I otherwise don't know how they spend their day.
      • pjc50 2y ago
        That's not important - you're not discussing how to do their job, but what your own view is of your part of the work and those around you. The leader can then synthesize all these views and see if there are any surprises. (another case similar to "you should listen to a customer when they say there's something wrong with the design of your product, but you should absolutely not pay attention to what they think the solution should be")
      • cosmosgenius 2y ago
• Kototama 2y ago
  > Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.
  • flir 2y ago
    UX really is everywhere, once your eyes are opened to it.
    • bbatha 2y ago
      Ill plug the "Design of Everyday Things" by Don Norman in case anyone in the thread hasn't read it. Its the classic text on design. You will never think about doors the same again.
  • Kenji 2y ago
    [dead]
  • cies 2y ago
    I think the size of the code base also matters: bigger size = having types is more important. There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.
    • pjc50 2y ago
      > More advanced typing features slow down compilation even more. C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.
      • cies 2y ago
• FrankWilhoit 2y ago
  The comment about project managers is interesting. At my last workplace, the PMs -- all consultants -- were the only reason anything ever got done.
  • qaq 2y ago
    Depends on team's experience level
    • FrankWilhoit 2y ago
      Actually in this case it depended upon the resource managers' technical illiteracy and unwillingness to do their jobs.
• pgsandstrom 2y ago
  > Most programming should be done long before a single line of code is written I'd rephrase this to something like: Most programming should be done before 5% of the code is written. Because "no plan survives contact with the enemy". I often develop a plan, work for just a tiny bit, and realize some new constraints. It's after that point that you should construct your grand battle plan.
  • latexr 2y ago
    From “The Cathedral and the Bazaar”: > # 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “The Mythical Man-Month”, Chapter 11) > Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once. https://en.m.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.m.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
  • v3ss0n 2y ago
    Its wrong in those day , exploratory coding is better for dynamic languges like python using jupyter notebook , and then do proper coding after exploratory step..
  • The_Colonel 2y ago
    I've made an opposite progression from the op. I was a strong believer of upfront design, but now value iterative approach as you do. For the first try, hack together something working, you'll learn things along the way, validate/disprove your assumptions. Iterating on this will often bring you to a good solution. Sometimes you find out that your current approach is untenable, go back to the whiteboard and figure out something different.
• bayindirh 2y ago
  It felt good to read someone who thinks like me, honestly. Also the observation of "The trouble with functional programming is functional programmers" is absolutely correct. This needs to be said more. Way more. P.S.: You can ask why, and I can answer honestly, without hostility.
  • lbj 2y ago
    Maybe say it less but it explain it more. I don't get it at all.
    • bayindirh 2y ago
      Let me try to explain it a bit more. From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others. Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet the rest at where they are". This is very true. The problem is, the people in the first camp can't cater to either group. First group has strong opinions and want a solid (not hostile, solid) discussion about how they can improve and how that tool works, and the second group doesn't care. Also, every programmer has an understanding of the machine, and they program on top of that abstraction. For me, "C virtual machine", or the modern hardware is very easy to grasp. For every line of code, I can have an educated guess about how my code will run (e.g. how will the branch predictor will behave or got inadvertently poisoned), hence imperative languages and the primitive memory management is easy for me. For others who think more meta, functional paradigm is a natural think to construct in their brains. Not meeting them at where they are is again off-putting. All in all, nobody wants to be constantly nagged to feel "stupid" about not understanding functional programming or how unelegant imperative is, and most of the functional programmers are doing this, even without knowing it. Some of my friends who do functional programming are more reasonable people. Who sit down and look at some code or problem say "oh, this looks an interesting problem and interesting solution, can I show you how it's done in functional way", and we can go from there, and go a very long way from there. I have never picked up Common LISP because of an academic who praised functional programming like it's the second coming of Christ. I still have the first chapter of the LISP book printed on my desk. I'll start it after 15 years, but now I don't have the time I want to spend on it. Lastly, from an architecture/elegance perspective, I believe a good imperative program in C/C++/Go is somewhere between Bauhaus and Brutalist architecture depending on what domain you're targeting (lower the level, more Brutalism), and I find that naked nature of imperative code directly tapping into the hardware or the kernel efficiently very elegant and well-designed. For the same majority of functional programmers this is ugly and shall be got ridden with a flamethrower. Also, an imperative programming language is no lighter on PLT and mathematics which the same majority finds mouth wateringly elegant. TL;DR: If the majority of functional programmers can be a bit less arrogant, meet in the middle and learn why we love what we love, we can build better languages, ecosystems, and a better world to live in, but no, functional elegant, imperative bad. Robert Martin's Talk: "What Killed Smalltalk can Kill Ruby, Too": https://youtu.be/YX3iRjKj7C0 https://youtu.be/YX3iRjKj7C0 which notes a similar mechanic about Smalltalk.
• deleted 2y ago
  [deleted]
• ertucetin 2y ago
  > REPLs are not useful design tools (though, they are useful exploratory tools) I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop. I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. This brings joy back to programming. I’m not saying other languages are bad, but working with Clojure is more enjoyable for me. I’m at least 2-3 times faster than I was with Java. Of course, there are techniques you need to know to write efficient and idiomatic functional code.
  • nickpeterson 2y ago
    I could definitely see how if you work in Java or C# all day, repls feel like a neat curiosity. Picture telling someone who writes scheme in emacs that repls aren't a good design tool. If you want to argue the point with non lisp people, I'd go to javascript or SQL as great examples where you really use repl's quite a bit.
  • cess11 2y ago
    I'm a heavy REPL/interactive shell user so when I do Java I abuse the testing framework, basically I put my sketches in unit tests and run those. The feedback loop is pretty tight, close to what I get in some other languages, whatever happens behind the scenes in IntelliJ it's much shorter than a full recompile and boot. Supposedly there are some Java shells around but I haven't tried them out.
    • skydhash 2y ago
      You either REPL or do TDD.
  • smallerfish 2y ago
    Apparently Graal lets you hotswap. I tried getting it working about a year ago, but couldn't figure out how to install it with Gradle toolchains, so gave up at that point. I should probably look at it again. Anybody using this? https://www.graalvm.org/latest/reference-manual/espresso/hotswap/ https://www.graalvm.org/latest/reference-manual/espresso/hot...
• latexr 2y ago
  > Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth. What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.
  • hkwerf 2y ago
    There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.
    • xnorswap 2y ago
      Edit: This comment was based on misreading the parent comment. I've left it up, but I should have been more careful. You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with. You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style. All of that is friction introduced because you haven't learned to live with the default style. Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time. By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
• lbj 2y ago
  I actually disagree with about half of this. > Typed languages are essential on teams with mixed experience levels Essential, meaning 'cannot exist without', it's not. I've seen this work a number of places. > Blind devotion to functional is dumb. Managing/limiting state is always a worthwhile pursuit. I'd think he would agree since he seems to value simplicity > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. That's like saying don't check if your cars tires still have any pattern left, the engine is more important. Until it isn't. Streamlining the smaller details allows the brain to focus on more important stuff, but the details matter and their value increases exponentially with the size of the project.
  • Tade0 2y ago
    Regarding code style etc. I get where he's coming from as plenty of people made entire careers on pursuing the perfect linter configuration. They're a net negative in every project.
    • steezeburger 2y ago
      I'd love some clarification if he meant people who bike shed or people who care to setup a linter and formatter as part of their workflow.
  • MisterKent 2y ago
    Your rebuttals are all agreeing with him... I don't think you're grasping the nuance he's putting out there. Instead you're choosing to be overly pedantic over the word essential.
• gunalx 2y ago
  > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. Could not agree more.
  • jamil7 2y ago
    I agree but have been on teams where this slows down PR review or arguments break out. Delegating to the linter and format on save can get the team past this.
    • ahoka 2y ago
      Those teams have these weirdos the article talks about.
• pjmlp 2y ago
  After almost 40 years, between hobby coding, education, and professional experience, kind of share a similar view in a couple of topics. Additionally such an extend experience gives us another point of view on trendy subjects that are experiences from the past newly repacked. And desilusion, seeing so many great ideas taking decades to become relevant, or never at all.
• mattacular 2y ago
  I strongly agree with almost all of this except the last part about project managers - a good one is invaluable, an ok one can still be helpful. The majority probably are neither (and their ability to be good at managing projects depends a lot on other org functions - not necessarily within their control) but way better than 90%+ that the author suggests.
• gorjusborg 2y ago
  No, objects aren't generally 'good', unless you think keeping multiple state machines in sync is 'good'. OO is not evil, but it also shouldn't be your default solution to everything. Also, who is this person? I immediately distrust someone who calls themselves 'a pretty cool guy'. That's for the rest of us to decide.
  • Insanity 2y ago
    I had a different read of that point. More along the lines of “don’t throw the baby out with the bath water” (might have butchered that saying?). I’m also more in the FP camp - even wrote a book on the topic of FP. But I also acknowledge OO is not inherently a bad choice for a project, and many languages nowadays do exist along a spectrum of OO and FP rather than being strictly one of the other. To me a benefit for OO might be the ubiquity - you can generally assume people will understand an OO codebase if they have done a few years of coding. With more strict FP that is just not a given - even if people took a Haskell course in Uni a decade ago :).
    • latexr 2y ago
      > More along the lines of “don’t throw the baby out with the bath water” (might have butchered that saying?). No, you got it right. https://en.wikipedia.org/wiki/Don't_throw_the_baby_out_with_the_bathwater https://en.wikipedia.org/wiki/Don't_throw_the_baby_out_with_... > even wrote a book on the topic of FP. Care to share? If not, that’s fine.
      • Insanity 2y ago
        Sure, “Functional Programming in Go”, this is the Amazon link: https://a.co/d/htv3BOu https://a.co/d/htv3BOu
  • karmakaze 2y ago
    The way I like to use OO (usually not real OO, but rather class-based languages) is to minimize its mutable state. Often mutability is merely a lack of using builder patterns. Some state can be useful as long as it's easy and makes sense to globally reset or control. It's like writing a process as a construction of monads before any data is passed into it. Similarly a tree of processing objects can be assembled before running it on the input.
• Tade0 2y ago
  > Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
  • alexchamberlain 2y ago
    I think Frontend (or maybe slightly expanded App Development) is a greatly underappreciated skill. It's easy to throw a UI together, but to do it in a way that is obvious to your user's, can be maintained and can move at the speed the business needs is a tough ask.
    • phist_mcgee 2y ago
      I agree, getting all the pieces together and having it be maintainable and enjoyable to work on is part of the craft. I enjoy the challenge, and have found a great niche for myself doing exactly that.
  • vaylian 2y ago
    The much bigger problem is that you not only have to deal with the technical challenges, but also the visual design challenges where non-technical people have all kinds of opinions that you have to deal with. Things get really nasty once you have to implement features that emulate non-web functionality like right-click menus and the UI becomes an inconsistent mess.
    • stackskipton 2y ago
      Visual Design Challenges is one I hear most frontend developer complain about. I explained a queen duck (https://bwiggs.com/notebook/queens-duck/ https://bwiggs.com/notebook/queens-duck/) to one of them and he started doing that several times in his project. If you look at this git repo, there would be commits called "queen duck" right before he would demo so he could get feedback about the "mistake" he made, revert the commit and move on with his life.
• CRConrad 2y ago
  He mentions this being a follow-up to a similar earlier post: https://chriskiehl.com/article/thoughts-after-6-years https://chriskiehl.com/article/thoughts-after-6-years . HN discussions on that post: https://news.ycombinator.com/item?id=25887373 https://news.ycombinator.com/item?id=25887373 (4 years ago|686 comments), https://news.ycombinator.com/item?id=32162716 https://news.ycombinator.com/item?id=32162716 (3 years ago|58 comments), and https://news.ycombinator.com/item?id=41633156 https://news.ycombinator.com/item?id=41633156 (4 months ago|56 comments).
• smitty1e 2y ago
  > DynamoDB is a good database (IFF your workload lines up with what it's offering) "The correct tool for the job." Seeing a document database used for tabular purposes gives me a sad.
• imjonse 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables and the sanity of other team members.
  • qaq 2y ago
    It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...
    • The_Colonel 2y ago
      Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM. Same thing for people claiming they don't need any frameworks.
      • wesselbindt 2y ago
        > you find out you need some caching here, then there Forgive my ignorance, but how do ORMs help with adding caching? Or are you implying they obviate or reduce the need for caching?
        • ivan_gammel 2y ago
          They do caching themselves so that some of your queries via ORM won’t hit the actual db.
          • capitainenemo 2y ago
            So, given the main issue with ORM is the object/relational part... (https://web.archive.org/web/20160301022121/http://www.revision-zero.org/orm-haters-do-get-it https://web.archive.org/web/20160301022121/http://www.revisi...) Why is caching not a feature in DB connection pools? I mean, most databases have it on their side, why not have it as an option for the same query sets prior to hitting the db, with configurable invalidations? Or is it, and I've just never thought to look for it.
• TheCapeGreek 2y ago
  > Most won't care about the craft. Cherish the ones that do, meet the rest where they are This becomes easier when you've transitioned from someone who cares to someone who doesn't. Some of us burn out from the industry and fall out of love with the job. I understand my curmudgeon-ly ex-colleagues a lot more nowadays.
• nrjames 2y ago
  Regarding scaling… one thing that drives me bonkers about Apache Superset is that the maintainers are absolutely adamant that it must be deployed with kubernetes because it’s meant to scale. The project works just fine with a simple and slim docker/compose deployment, which is easier for small teams to manage. The lead maintainers refuse to document this and have unnecessarily sprinkled the docs with warnings.
• vladde 2y ago
  > Good management is invaluable. (I went most of my career before seeing it done well) I don't think I've ever seen good management. Anyone care to explain what that would look like?
  • zvorygin 2y ago
    Your team gets a clear and simple high-level goal that everyone at the company understands is important and shields you to work on it for a year without interruptions. You don’t know it, but your manager playing up your teams contributions to the company, arranging happy coordination with other teams, occasionally intervening to resolve intra-team disputes, privately managing egos and careers, and jiu jitsu’ing any attempts to distract your team. They trust your competence and decisions, but they understand enough to keep you on-track and provide a valuable outside view perspective.
  • qaq 2y ago
    Key thing good manager shields team from corporate bs as much as possible
  • atulatul 2y ago
    A couple of indicators I have seen: 1. For a non-manager, an indication that there is good management (project, process, etc.) in place is that the management aspect sort of seems to disappear/ moves into the background. 2. Communication becomes efficient or smooth. How is it achieved? 1. High level goals and metric. And incremental upgrades to those. I think people/ teams need to get comfortable with one set of those before you want to improve better those metrics. Jira story points and velocity are not good metrics. 2. A manager acts as a buffer. A manager absorbs some shock and filters some data/ emotions which would otherwise flow between one (ideally more) pair of layers: one above them and one below them. 3. One kind of non-sense (from many kinds) is that people- junior or senior- are 'trying to prove their value'. This is why some people speak unnecessarily in meetings, emails go back and forth, senior management chimes in on low level issues, etc. A couple of good managers I saw were able to limit that- over a period of time.
  • koonsolo 2y ago
    Here's the problem with good management: you will not notice it, you only notice bad management. A good manager is at the service of their team. That means they will do anything to keep the team productive. In most cases this means shielding them from corporate bullshit. In practice this also means that you will barely notice them. So when you notice your management being intervening and bad, it's probably bad. When you barely notice your management and can't see what value they are adding, it's most likely excellent management.
• chrisjj 2y ago
  > There is no pride in managing or understanding complexity "is"? I see plenty.
• fergie 2y ago
  > Typed languages are essential on teams with mixed experience levels I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.
  • pjc50 2y ago
    Unless you can happily deal with '"four" + 1' your language is typed. The question is whether you want type errors reported upfront or you have to wait to find them at runtime (necessitating high test coverage). One of these days I'd like to see a "typed assembler". It still matters what the contents of registers mean, even if they all look the same to the instruction set.
  • Insanity 2y ago
    Interesting take, to me it is not so much about the type of coding (high vs low level) but more about the size of the project. Dynamic languages work great for scripting and rapid prototyping, but if you are working with a team maintaining a large monolith, I would rather have a statically typed language and avoid at least a class of runtime issues due to dynamic typing. Case in point, I love writing my Jupyter notebooks with Python but am amazed that entire platforms like Dropbox (and instagram?) chose Python as their default language.
  • drpossum 2y ago
    I think the sentiment was they help significantly when you have inexperienced programmers. (That has also been my experience)
  • arduinomancer 2y ago
    What do you mean low level? Do you think the Linux kernel could be written in a language without types enforced?
• chmod775 2y ago
  > Objects are extremely good at what they're good at. Blind devotion to functional is dumb. Maybe "mutable objects"? Maybe these were intended to be isolated statements? Personally I believe functional programming is great with objects too... It is however true that many OOP-embracing languages tend to favor an imperative style. Scala is an example of a language that embraces both.
  • ikety 2y ago
    C# is becoming one as well. I recommend Zoran Horvat on youtube And most of the well written react projects I've worked on tend to be overwhelmingly functional in style. Hooks just make sense when thinking about the lifecycle of a UI. Shared state and imperative code with react just feels wrong.
• ZaoLahma 2y ago
  > Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.
  • gaptoothclan 2y ago
    ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?
    • ZaoLahma 2y ago
      It's about defining and solving small problems all the way, and avoiding trying to solve big problems. If you manage to restrict yourself to only solving small problems (THIS is the true challenge with software engineering, in my humble opinion), then you won't ever have wasted too much time if (when) you need to reset.
  • gmm1990 2y ago
    I assume there are people who are able to have those eureka moments before writing any code. I definitely write a lot of code before figuring out the final design but always think I should be designing more.
    • bluGill 2y ago
      Always plan to throw one away. You will, so best to plan for it. (paraphrasing Fred Brooks)
  • VyseofArcadia 2y ago
    Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.
• andyish 2y ago
  > People who stress over code style, lining You can do it whatever way you want but match the style of the project. I've worked on too many projects where someone decides their way is best and you end up with a mix of everything. If you want to change the code style, okay, but change it everywhere and don't forget to test everything you've changed. > Frontend development is a nightmare But is it weird I kind of enjoy it every so often/ > Elegance is not a real metric You're dam right it's not! Next time someone proudly presents a super elegant, refined, and minimalistic solution I'm going to phone them at 3am on a Saturday and get them to debug it while screaming at them about lost revenue or something. > DynamoDB is the worst possible choice for general application development Oh man, the amount of times I've seen some form of noSql and it's used as a relational database. 9/10 some rendition of SQL is more than sufficient.
  • Twirrim 2y ago
    I've grown to be a big fan of opinionated linters like gofmt, rustfmt, black etc. They avoid so much time spent disagreeing about code formatting and personal preferences. Instead engineers can do mutual grumbling sessions about weird formatting choices they see it do, and move on.
    • guappa 2y ago
      black sucks. Everytime you bump version it will reformat all of your already formatted code. If your product maintains different versions you won't be able to cherry pick changes across versions.
    • spc476 2y ago
      If I didn't want to have opinions, I would join a cult.
      • krior 2y ago
        save your opinions for the things that really matter instead of another bikeshed to build! (not telling you to shut up, btw :) )
      • 2y ago
• v3ss0n 2y ago
  >People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harmony - without them it will be a disaster. - merge conflict hells because code style diferences - bad for code reviewers - bad to ready everyone's different code sytles.
  • pjc50 2y ago
    He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
    • v3ss0n 2y ago
      Everyone on the team need to agree to the linting rules before using linters. Else they will keep wirting their code according to their habits , and then they start to modify the rule that dosen't fit their bad habits when linters hints to fix the code. > run the language's standard formatter Even with very smart linters like `ruff` it cannot fix all of the linting errors. You have to hand fix many of them. What linter do you use that can just run and forget?
      • pjc50 2y ago
        Dotnet-format for formatting. Can auto fix. Sonarqube for linting. It's more annoying and not auto fixing, but it achieves the goal of avoiding arguments and does catch some bugs.
        • v3ss0n 2y ago
          In python and js sonarcube sucks. Ruff and Biome are perfect but still need manual fixes
    • 2y ago
• olavgg 2y ago
  One thing that I have never been more sure about after 20 years as a software developer, is that Hibernate is awesome! Seriously, it saves me ton of time and tinkering. It has support for native queries, and it is simple to transform your custom query into JPA entities. Using Hibernate has never been easier with the introduction of LLM, tell it what it needs to do, and see beautiful Hibernate examples code. In my Spring Boot applications I log every SQL that is generated, and quickly spot unoptimizations, like lazy loading of entities instead of using join. How ORM's behave in other languages and frameworks, like Python, Go, Rust is probably another story.
  • hu3 2y ago
    I'm curious, have you worked with Entity Framework with its legendary LINQ magic?
• SushiFreak 2y ago
  > DynamoDB is a good database I cannot agree with this. I've constantly ran into issues around where you can insert data into with an attribute name such as "status" and then when you query it, it says you cannot query with a reserved keyword. There is a myriad of other issues I've found and when asking around chat groups and forums, people universally dislike dynamo db.
• osigurdson 2y ago
  I think the ultimate boring language is golang. It is almost too boring though.
• FrustratedMonky 2y ago
  "Objects are extremely good at what they're good at. Blind devotion to functional is dumb. " Guess this hits home. But Blind anything is bad. I spent a decade blinded by objects being everything (original gang of four book). Then a decade where everything is functions. Why not pass a list of objects to that function.
  • ikety 2y ago
    Objects are also used in functional programming. This feels like a reaction to people being functional evangelists. There's a reason most modern languages are completely blurring the lines and allowing you to think with multiple paradigms. I'd be more upset with institutions lacking in functional programming coursework. OOP is dominant, I can't see why people get so irritated by a few annoying functional evangelists. And while annoying, I don't think the motivation there is always "Blind devotion to functional"
  • dionian 2y ago
    objects for data, functions for behavior
• dusted 2y ago
  Interesting, I've been in software development for a little more than 10 years, and just about every point I've read, I more or less agree one, will be interesting to see if it changes the next 10.
• kitd 2y ago
  One more that has opened my eyes recently: Good, empathetic UI design is invaluable. Get a professional UI designer. Engineers are (in the main) appalling at it and will cost you time and sales.
  • yakshaving_jgt 2y ago
    In my experience, finding an actually good UI designer is hard. Obviously they exist, but I don't know how to find them. It seems many — if not most — professional UI designers don't even understand that form inputs need labels. Got any tips?
    • kitd 2y ago
      I agree, it's hard. I'm lucky that I work for a large org with a separate design department. They are the ones that initiate how our products present themselves to the user, both in terms of styling and user flow, and they spend time and effort researching with guinea pigs what works best. It's very much "Design Thinking" in action. The outcome though is a monumental improvement in how easy the product feels to use. It's an artistic activity and is thus empathetic by nature. Being initially skeptical, I was won over very quickly.
• pmarreck 2y ago
  Here's mine, FWIW: 1) Nix. I finally came around after one too many bricked Linux installs, and learning Docker and being kind of unhappy with it. And while I still haven't completely mastered it, you can learn enough in a reasonable amount of time to maintain a Linux install. > Blind devotion to functional is dumb. Except when it's not "blind" and informed by hard experience (years of OOP). Which leads me to... 2) Functional programming/immutable data. For the vast majority of use-cases, these just lead to better code, fewer bugs, and less LOC needed for a given functionality. (I just wish Elixir had the option to compile to a single binary. Roc-lang looks interesting, in that space, if you aren't into Rust.) 3) Typing. I'm coming around to it, and to a general principle of "happy-path strictness" in general. All to achieve determinism. > Java is a great language because it's boring No. The people who disparage software devs who have tool preferences are a special bunch and not really "software devs" (with apologies to the No True Scotsman fallacy). If everyone was supposed to be "fine" with Java, then no new languages need be developed!
• laurent_du 2y ago
  DynamoDB is not good, it's OK. Capacity upscaling and downscaling is too slow to be useful. You need to over-provision.
• alexfromapex 2y ago
  > Code coverage has absolutely nothing to do with code quality Ehhh..lots of nuance to this one
  • jonhohle 2y ago
    And the inverse is almost always true: lack of code coverage is a strong indicator of lack of both code quality and developer experience.
  • commandlinefan 2y ago
    You can achieve 100% code coverage and always have passing tests as long as you don't add any assertions.
• olalonde 2y ago
  It feels like the author is in the middle of the bell curve meme[0], especially with regards to "most programming should be done long before a single line of code is written". [0] https://i.imgflip.com/8tw3vb.png https://i.imgflip.com/8tw3vb.png
  • marifjeren 2y ago
    This is an extremely lazy critique
    • olalonde 2y ago
      Hard to argue with that but it's a lazy article too - just a collection of opinions with no reasoning or supporting arguments.
• GuB-42 2y ago
  Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you Spring) is everything but boring, and it is not fun either. - Most programming should be done long before a single line of code is written I went the opposite extreme. That is, if you are not writing code, you are not programming. If you are not writing code on your first day your are wasting time. It is a personal opinion, but the idea is that without doing something concrete, i.e. writing code, it is too easy to lose track of the reality, the reality being that in the end, you will have a program that runs on a machine. It doesn't mean you will have to keep that code. - Formal modeling and analysis is an essential skill set Maybe that explains our difference with regard to the last point. Given the opportunity, I prefer try stuff rather than formalize. It is not that formal modeling is useless, it is just less essential to me than experimentation. To quote Don Knuth out of context: "Beware of bugs in the above code; I have only proved it correct, not tried it." ;) - You literally cannot add too many comments to test code (I challenge anyone to try) time++; // increment time
  • snapcaster 2y ago
    I agree with you, i'm much more on the "try stuff out" scale vs. formal methods. That being said, i've worked with people who are the other way and still very effective. I think this one is more of a trade-off or personality thing than something that's "true" or "false"
    • AnimalMuppet 2y ago
      I agree with you that personality plays a role. But regardless of which way your personality pushes you: You can never think enough up front to know all you need to know, or even 95%. You're not omniscient enough, and you never will be. Big Design Up Front fails because of this - you have to be able to iterate. You also have to know what you're trying to build, and at least roughly how you're going to build it. If you don't, no amount of iteration and experimentation will enable you to converge on a solution. You need to experiment and iterate and explore within at least a sketch of a larger picture, not on a blank canvas.
• tines 2y ago
  How does > There is no pride in managing or understanding complexity interact with > If I think something is easy, that's a sure sign I don't understand it. ? Is it implying that you must understand the irreducible complexity, but mustn't take pride in that understanding? Or is "difficult" the opposite of "easy" here, rather than "complex?"
  • mathw 2y ago
    Both easy and difficult problems can have simple or complex solutions. Two different axes of measurement. Most problems in software seem to end up being harder than they look, so if I think something is easy I have to suspect I've missed something. Most solutions in software end up being more complicated than they needed to be, because we don't have the hindsight to realise that until after we've done it and our managers are demanding the next thing.
    • tines 2y ago
      Sure, but that's not really what the quote says, it doesn't talk about making things more complicated than they really are, it just talks about "complexity."
  • ryathal 2y ago
    It's saying you don't need to be proud of your app that has multiple layers of abstractions to be immune to every possible change. There are hard problems, but the most complex solution is rarely good or best.
    • arduinomancer 2y ago
      I think when you first start out as a programmer you’re impressed by complexity and complex solutions But once you’re more experienced you realize complexity is arbitrary and anyone can make things more complex
    • tines 2y ago
      I'd argue that's a poor way to say that, because "managing" complexity tends to mean "taming" or dealing with complexity in a good way.
• jordanmorgan10 2y ago
  Huge disagree - 100% of project managers could disappear with no change in efficiency - not 95% ;)
• dtquad 2y ago
  >Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very little time to migrate to Vite and update dependencies. By 2019/2020 React Hooks had already been out for some time but there were still some class components in the app. They were easily migrated to functional components + Hooks using ChatGPT.
  • kovacs 2y ago
    it's the best comment in the entire post IMHO and made me LOL
  • pinoy420 2y ago
    With ChatGPT I am enjoying Typescript development and learning a lot. Unfortunately with ChatGPT being - in JavaScript terms - decades behind the state of the art. It becomes a little challenging to get it to do what you want. But it gets me 80-90% of the way there 70% of the time. Which is a huge win.
    • knodi123 2y ago
      I know what you meant, but that phrasing reminds me of the gag from Anchorman, "60% of the time, it works every time."
  • phailhaus 2y ago
    Yeah I wonder if his experience is mostly using JavaScript, which is absolutely impossible to maintain at scale. Most of my team comes from primarily backend-dev roles and they've all grown to love TypeScript over Python.
    • jghn 2y ago
      Both of his blogs mention Java at least once. It's a good bet this factors heavily in his day to day.
• lmm 2y ago
  Hard to have any kind of productive discussion when it's just a set of claims without rationales. I agree with some and disagree with some (RDBMSes are overrated and solve the wrong problem; ORMs are a useful tool and bypassing the ORM because you want to use your l33t SQL skillz is the devil; programming should be done by writing lots of code from the earliest stage on (and throwing most of it away)).
• donatj 2y ago
  > Most programming should be done long before a single line of code is written This is the only point I strongly disagree with. I have been doing this for twenty years now and every time we've gone into something with a STRONG plan for how it's going to be built, it's ended up an inflexible nightmare when we inevitably end up having to work around things that were not considered in the design phase. The plan always ends up bumping into unforeseen realities, and you end up with sunk cost around the planning so instead of pivoting you keep on suboptimal course. You can spend months planning the smallest feature and there will always be something you did not consider. Rapid prototyping in my experience is the way. Throw something together that works, see how it can be improved, don't be afraid to throw the entire thing out.
  • cardanome 2y ago
    I feel like exploratory and iterative development is more necessary when requirements are unclear or when there is a lack of domain knowledge. Also obviously things like game dev require an iterative style. For backend web dev though, I can plan it all in advance. I have done it enough times that there are rarely any surprises and I know the pitfalls. I am really just limited by customers not knowing their own requirements. I really love the iterative style but the problem is that I never worked in a company that allowed for enough time for large scale refactors. They might promise you that but it will never happen. You have to get it right the first time around or you will have to suffer until the system gets rewritten in a decade or two. Of course plans can absolutely be too rigid but I generally found that more planning results in better products.
  • nicce 2y ago
    I would say it depends on your domain expertise and the expertise of the chosen programming language. Of course, for very large projects with multiple unknown integrations this is not the case. But if you are an expert in both of domain and the technology itself, you can well design it before starting the coding, because you already know the technical issues you are likely facing. At least I have personally managed to design some projects and implement them without any design changes. But I also read countless blog posts about the limitations of these programming languages every day.
  • 2y ago
• naasking 2y ago
  > You literally cannot add too many comments to test code (I challenge anyone to try) I think it is possible, depending how you write them. If you write long comments interspersed with the code, you have a lot of scrolling to do follow the control-flow. Long block comments should go at the top to "set the stage", and then lightly interspersed comments throughout to remind of the specific steps, where necessary. > Very few abstractions exist in general application development. Just write the code you need I think they exist, but they're either not well known or are hard to engineer because of missing context; good abstractions are just hard. Solve the immediate problem and you'll maybe, eventually converge on the abstraction and you'll have your "aha!" moment.
  • naasking 2y ago
    > ORMs are the devil in all languages and all implementations. Just write the damn SQL I'm re-evaluating this again. I used to be all-in on ORMs, eventually became annoyed with the shortcomings and the performance problems, but am realizing the disadvantages of foregoing them as well. * ORMs Bad: ORMs often lead to deep object graphs and tight coupling if you don't know what you're doing / don't factor the model properly. This has serious performance implications. * ORMs Good: you get a unified, consistent view of all of your data on which you can enforce invariants in a holistic way. * Only SQL Good: you can easily return and operate on only "slices" of the data, which is great for performance and rapidly iterating on features. * Only SQL Bad: because you're only operating on "slices", you don't get a unified view of the data on which you can declare invariants. You can declare invariants on the slices and then stitch all of the properties together in your head to make sure you covered everything important (and write what tests you can to validate this), but this is error-prone and less necessary with ORMs. So yeah, there's no single, clear winner here yet.
    • Shorel 2y ago
      > enforce invariants in a holistic way This sentence is golden, it advances the bullshit bingo score better than the rest. But honestly, in SQL the invariants should be constraints and triggers, enforced by the DB, not just by the application layer.
• vincnetas 2y ago
  agree on 10/11 because i have not used DynamoDB ;) by the way, whats wrong with serverless functions? Given a long enough time horizon, you'll deeply regret building on Serverless Functions
  • leptons 2y ago
    Been using AWS Lambda for 10 years, since AWS Lambda was first released, so there really is no longer of a "time horizon" - I have not had any problems that would cause any regret, quite the opposite in fact. I also don't use the "Serverless framework", I rolled my own AWS Lambda toolchain long before the "Serverless framework" was ever a thing. So I'm not sure if the author is referring to "functions as a service" generally or specifically the "Serverless framework". My team did recently try to set up the "Serverless framework" for a new project, and it was quickly apparent that it wasn't going to work for us. It was kind of messy, honestly. I really wanted it to work, but requiring an account on the Serverless framework website just to get Lambdas deployed was the wrong way forward for us. We just ended up using my own toolchain, which is simple and easy and does everything we need it to do, which is build the Lambda function inside AWS Lambda, and deploy the function with some basic configs.
  • esafak 2y ago
    Your load might grow as your application scales, costing you.
• xhrpost 2y ago
  > REPLs are not useful design tools Anyone have more context on this? I've never thought of a repl as a design tool. Does he mean loading your app in a repl, calling functions manually and then manually swapping them out in real time?
• lucasoshiro 2y ago
  Strong opinions, but only telling them doesn't say too much for me. Constructive criticism: tell the reasoning behind those opinions. I really believe that they are based on facts and experiences, so tell them! Only telling "after 10 years in the industry" may look like the argumentum ab auctoritate fallacy (https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority)
• jagraff 2y ago
  > Contrarily, library development is about abstractions. Spend time hunting for an algebra This line piqued my interest - what does an algebra mean in this context? Does anyone know of any good resources for further exploration?
  • wink 2y ago
    Only guessing but my first thought was about how you have addition and multiplication and they both work for different types of numbers. But not in the generics/C++ template sense, more like working on Sets and Rings and other algebraic structures in the mathematical sense.
  • jghn 2y ago
    It comes from the FP world. It's one of those things like monads that seem obvious when explained but sound opaque if you're not in on it. Basically it's saying to create a formal set of types and formal rules about how they interact. If you search for permutations of phrases like "functional programming" "algebra" "data types" you'll turn up some hits. For instance [1] [1] https://www.turingtaco.com/algebraic-data-types-structuring-data-in-functional-programming/ https://www.turingtaco.com/algebraic-data-types-structuring-...
  • itishappy 2y ago
    Algebraic structure. It's a fancy way of saying that a system follows certain patterns or rules. As an easy example, you're probably quite familiar with the algebra of addition over integers. It describes rules like associativity and commutativity that describe some general transformations that are guaranteed to always behave predictably. Contrast this with subtraction over integers, which is associative but not commutative. Programs in general are neither associative nor commutative, so sadly no swapping terms or adding parenthesis willy-nilly. A slightly more advanced example that you're probably still familiar with is mapping over Functors. A functor is just a thing that contains other things, and it includes collections you're familiar with like lists and trees. Well, the action of taking stuff out of a container, modifying it, and returning the results in their original position turns out to be an incredibly common and useful pattern! https://en.wikipedia.org/wiki/Algebraic_structure https://en.wikipedia.org/wiki/Algebraic_structure
• nailer 2y ago
  > Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy Yep. At some point in React (maybe 5 years in) ‘how do I handle state?’ started to be ‘read this essay about the true nature of FRP from Dan Abramov’ and it just seemed to get worse from there. I worry Svelte will do the same in future.
• pinoy420 2y ago
  > If I think something is easy, that's a sure sign I don't understand it. A lot of people (definitely here) need to understand this.
  • patrickmay 2y ago
    This was the one that resonated the most with me. As soon as I start to think "Why don't they just . . . ." I know I'm in for an epiphany.
    • pinoy420 2y ago
      “Just”(TM) The bane of my life. Glad I grew out of that eventually. I completely agree.
      • MattGrommes 2y ago
        At a previous employer I tried to implement a Just Jar where people had to put a dollar in every time they said "Just do...". It didn't last because the boss was the biggest offender.
• braggerxyz 2y ago
  > Monoliths remain pretty good > It's very hard to beat decades of RDBMS research and improvements > Micro-services require justification (they've increasingly just become assumed) That is so true. I am still deploying good old .war files to full blown Java app servers backed by simple SQL databases (all clustered and stuff) with some handwritten cli tools and a Jenkins server. Shit is fast, shit scales, shit just works. It is a pleasure to work with
  • jeremycarter 2y ago
    98% of teams I've worked on did not need microservices.
  • jamaicahest 2y ago
    20+ years as a professional developer and I still have to argue with coworkers on why MongoDb is a terrible fit for their data, which is clearly relational, just because said coworkers can't be bothered to learn SQL.
• nerdralph 2y ago
  > Very few abstractions exist in general application development. Just write the code you need. I don't try to foresee abstractions (premature optimization), but I often encounter them when adding to a codebase. A recent example would be a tool that uses property info from a public database. The first version was hard coded to the database from one jurisdiction. When I added support for a second jurisdictions, abstractions helped avoid code duplication.
• deleted 2y ago
  [deleted]
• Cyclone_ 2y ago
  "Elegance is not a real metric". Code maintainability certainly is something to consider that will bite you if you're not thinking about it.
  • jghn 2y ago
    Define "code maintainability" in a measurable way.
• markatkinson 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL. I think I might get this tattooed on my chest.
• ikety 2y ago
  Functional programming does not prevent you from using objects Stop listening to functional programming bros. Watch someone like Zoran Horvat. While I can't cosign all of his opinions, he tries to bridge the functional/OOP gap for OOP programmers. OOP programmers urgently need to distance themselves from this binary narrative. Everyone should understand functional programming and how they can utilize functional approaches in every language or paradigm. For me it is a requirement of understanding software development. Absolutely every institution teaches OOP practices, they also need to teach functional practices. These aren't sports teams.
  • mrkeen 2y ago
    > Functional programming does not prevent you from using objects It's a bit like how doing single-entry bookkeeping doesn't stop you from doing double-entry bookkeeping.
    • beders 2y ago
      That's probably the most incorrect analogy. If I have objects, I can change their state in the middle of any bookkeeping. There should be a different name for functional programming with mutable objects.
      • mrkeen 2y ago
        I think the analogy works. It's all about the tradeoffs. Double-entry is harder to grasp, but it has certain properties, like being able to sum along rows or columns. With that property, you can then make assertions like "if anything is off by a cent, then there has been a mistake and it needs to be looked at again." On the other hand, single-entry is much simpler, you can just record a figure for a date with a reason, and be done with it. It widens the pool of employable candidates, it's easier to onboard new employees, and you don't have any elites screaming at you for doing accounting the wrong way. If you take a hybrid approach and mix the two, then on average you only have to fill in 1.5 entries per transaction, so it's easier and faster than double-entry, but you can still express some transactions with two entries if it's more elegant, on a case-by-base basis.
• mikelinsi 2y ago
  > Never go full monad in Java. what? why?
  • dionian 2y ago
    because no matter how much java wants to be like scala, it's very painful to work with (verbose). There is no good Option type either. But I believe there are third party libraries out there that do a better job, if you really can't use scala for some reason
  • mrkeen 2y ago
    From a use-case perspective, Haskell monads let you restrict where various effects happen. Some code can be allowed to do local mutation, other code can do shared-mutation suitable for (ACID-like) transactions. In Java you can do anything, everywhere (except throw checked exceptions from lambdas for some reason) so the monadic wrappers would give you about as much guarantee as a comment, and be less clear. From a representational perspective, you need a generic of a generic to represent<M><A> and that doesn't really work. Or if you go for interfaces not type variables, you could have a Monad<A> but you don't know which one you have (List? Future? Parser? Either?). It's like representing the above as literal 'Object's, you'd be constantly casting.
• qwertox 2y ago
  > Java is a great language because it's boring My issue with Java is not that it's boring, which it is not, but there is so much that needs to be done to get a simple "Hello World" program to run which also depends on an external library. It feels like you first have to build a castle just to put a bed in a room.
  • geophile 2y ago
    Do you mean "public class HelloWorld { public static void main(String[] args) { ... } }"? Or the ridiculous Spring abstractions that many people insist on? The former is a minor nuisance, easily filled in by an IDE. The latter is far worse, unnecessary bloat and complexity. Architecture Astronaut stuff.
  • MichaelNolan 2y ago
    These days hello world in Java is just: ```void main() {print("hello world"}``` And you can skip the compile step as well and run it with just `java yourFile.Java` Since JEP 495 they have made "simple programs" very simple.
    • qwertox 2y ago
      yes. main() is the room and print("hello world") the bed. with the castle I'm referring to the whole myriad of things that must be done to be able to compile this. But, as I said, at least drop in a library, possibly via Gradle.
• pkphilip 2y ago
  I must say that I resonate with almost all of the points stated. These particularly stood out to me: Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy ORMs are the devil in all languages and all implementations. Just write the damn SQL Monoliths remain pretty good It's very hard to beat decades of RDBMS research and improvements Micro-services require justification (they've increasingly just become assumed) Most projects (even inside of AWS!) don't need to "scale" and are damaged by pretending so I did agree with the following as well: Typed languages are essential on teams with mixed experience levels Java is a great language because it's boring REPLs are not useful design tools (though, they are useful exploratory tools) Most programming should be done long before a single line of code is written Given a long enough time horizon, you'll deeply regret building on Serverless Functions Types are assertions we make about the world Most won't care about the craft. Cherish the ones that do, meet the rest where they are Code coverage has absolutely nothing to do with code quality (in many cases, it's inversely proportional)
  • leptons 2y ago
    >Given a long enough time horizon, you'll deeply regret building on Serverless Functions What is the regret about? I've been almost exclusively using AWS Lambda (not using the "Serverless" framework), since 1 month after AWS released Lambda in Nov 2014. I've built quite a lot on top of AWS Lambda, and I love it. It just works. It's not difficult to work with, and I don't really have to worry about scaling it. Is 10 years not enough of a "time horizon" to regret it?
• zafka 2y ago
  "93%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (this estimate is up from 4 years ago)" This made me laugh it is so true. My last big project at "Big Co" ( Knee surgery robot ) My small group went through 4 project managers - just for our small team. The entire project had probably 20. While a few where enjoyable to work with, there was very little value added and a lot of time spent filling them in.
  • mystickphoenix 2y ago
    Agree - in my 10+ year career, I've run into exactly 2 PM's that have provided enough value to a team or project to justify their inclusion in the team or project. Both were technical enough to understand what the engineers were working on and talking about and were able to offer genuinely good suggestions. The rest? At best they were glorified QA/QC with a large stick to hit the engineers with when the spec wasn't met exactly. And when it was, and things still failed, they still hit the engineers with the large stick and were usually promoted for it.
  • danjl 2y ago
    You can extend this to all varieties of PM. Product/Project/Program. All should be replaced by people who actually create things. E.g. I prefer to have a UX Designer handle the Product Manager tasks, since they already think about the app from the user's perspective, and can actually create solutions to problems.
  • rgblambda 2y ago
    When org charts are from 2 reorgs ago, team members are going straight to members of other teams where collaboration is needed, the backlog is 100% maintained by the developers with no input from managers, I wonder what exactly they do outside of meetings where they usually just relay orders from higher up.
  • spc476 2y ago
    At $PREVIOUS_JOB, the team I was on worked the best when we had no manager. Or rather, we had a director (who should not have been managing us directly) meet with us once a week to tell us "here's what we're headed ... good?" and let us go work in quiet until the next meeting (or meet with us sooner if something really important cropped up).
• nmeofthestate 2y ago
  "Most programming should be done long before a single line of code is written" I wish this were the case, but have found that "No plan survives first contact with the enemy".
• geophile 2y ago
  After more than 25 years in the industry, and 10 years of retirement, I agree with pretty much everything on this list. A few things that struck me: - Don't get too fundamentalist about OO or functional programming. Each has its place. - "Spend time hunting for an algebra" is somewhat obscure, but truly excellent advice, and I have spend a lot of my career doing exactly that. That has never been time wasted. This connects to a couple of other points. 1) Once you have an algebra, you have the basis of a good API for functional programming. (This point is not explicit in the list.) 2) The things manipulated by your algebra are also the basis of a good OO design. - "Elegance is not a real metric." It is absolutely dangerous as a metric, because it is a subjective goal we all aim for, and can therefore be used to justify anything, no matter how dumb. That said, elegance is something to strive for in your day-to-day programming life. You know it when you see it in someone else's work, and you appreciate it. You see a small set of principles, implemented in one place, that can then combine in many ways to do many useful things. Hmm, sounds a lot like an algebra!
  • physicles 2y ago
    As I understood it, the “algebra” is the domain-specific language/abstraction that you build — and if you’re lucky, discover — that encodes something fundamental about the domain you’re working in. Once you’ve found that, further coding is easier than you’d expect. I’ve had the pleasure of finding a few of these over my career.
    • geophile 2y ago
      I think it goes beyond that. An algebra has operators that take objects of some type as input and yield objects of the same type as output. E.g. arithmetic (numbers in, numbers out), and relational algebra (tables in, tables out).
• NoMoreNicksLeft 2y ago
  >ORMs are the devil in all languages and all implementations. Just write the damn SQL This was in the "picked up along the way" category. Better a slow learner than a no-learner.
• weberer 2y ago
  >DynamoDB is a good database (IFF your workload lines up with what it's offering) >The query planner is a cruel mistress >ORMs are the devil in all languages and all implementations. Just write the damn SQL >DynamoDB is the worst possible choice for general application development >It's very hard to beat decades of RDBMS research and improvements All these points tell a beautiful story
• ChrisMarshallNY 2y ago
  > Most programming should be done long before a single line of code is written > Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy These two may be interrelated. I do app (frontend) development, and it greatly benefits from an iterative, evolutionary approach.
• ge96 2y ago
  It's funny I used to think tests are a PITA now I'm arguing for them as I'm seeing the problem they solve, even basic ones like full E2E headless browser testing vs. 100% unit test coverage. I am holding back on stressing out regarding syntax like PEP 8. My role right now is great where we get to prototype random things.
• marviel 2y ago
  "Typed languages are essential on teams with mixed experience levels" This is true of working with LLMs, too
• Havoc 2y ago
  > REPLs are not useful design tools Add Jupyter notebooks to the list. Currently in a corporate environment where that seems to be the go to way of coding and it’s just fuckin awful compared to an IDE
• BenoitEssiambre 2y ago
  These mostly align with the idea of reducing code entropy: https://benoitessiambre.com/entropy.html https://benoitessiambre.com/entropy.html
• DarkCrusader2 2y ago
  > You have to actively invest in improving your soft skills (and investments pay back immediately) Can anyone elaborate how does one do that? I have seen this advice many many times but never anything actionable attached to it. I believe my soft skills are my biggest weak point right now and is holding me from growing further in my career and I would like to do something about it. But I have no idea how.
  • esafak 2y ago
    Socialize more. Even out of work. Participate in and organize meetings. Try to pay attention to people's feelings.
• tasuki 2y ago
  > Gradual, dependently typed languages are the future What's that? Idris is dependently typed. > Gradual typing is a type system that lies inbetween static typing and in dynamic typing. Some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime. That sounds miserable. I can't see how one would guarantee anything when types of other things aren't known. And I can't see how to connect that to dependent types either.
  • aranchelk 2y ago
    Maybe the author meant gradual static typing?
  • beders 2y ago
    I can only assume this comes from an observation that once your product matures, the static types become more apparent and you have a better idea how flexible your data modeling should be. i.e. we are gradually adding more runtime type-checks to our Clojure codebase. (Runtime check are even more powerful than dependent types)
  • crvdgc 2y ago
    Imagine adding types to a legacy JavaScript codebase. You can turn everything to valid TypeScript by annotating `any` everywhere, then you can gradually add types here and there. Or imagine writing Rust with `Rc` everywhere and then using the borrowing style on the hot path. I can see where the author is coming from, but sadly a difficulty is that dependently typed languages often require the programmer to prove type equality during type checking. It's hard to do if the information is not complete.
  • roguecoder 2y ago
    I recommend https://open.library.ubc.ca/soa/cIRcle/collections/ubctheses/24/items/1.0428823 https://open.library.ubc.ca/soa/cIRcle/collections/ubctheses... as a place to start. It isn't about "guaranteeing" _everything_, any more than assertions or guard clauses guarantee everything. It is about giving programmers a semantic tool they can use to communicate expected interfaces in an automatically-detected way, without adding unnecessary toil and boilerplate in tight, local contexts where functions are just working on obvious primitives. The most graceful implementation I've seen is RDoc comments + Jetbrains tooling in Ruby. When it looks like a type system people assume it's going to work like Java, but having build-time checks based on where people bothered to describe the expected interface catches errors without any of the downsides of type systems that keep type systems from measurably boosting productivity.
• taeric 2y ago
  > The trouble with functional programming is functional programmers This hilariously works for a lot of things. Biggest trouble with legalization of drugs is the drug use of the ones that love to talk about why it should be legal. Biggest trouble of prohibition policies are the people that love going on about why they are better for not drinking. I assert that this is, essentially, "The trouble with THING is the group of people that think THING is a panacea at what it does."
• devmor 2y ago
  For the most part, I agree with a lot of this, but there were a couple points I raised an eyebrow on. > There is no pride in managing or understanding complexity To the point that intentionally creating complexity or allowing it to continue to exist where it can be simplified, I agree - but some systems are necessarily complex and having pride in understanding and managing them is a good thing. If no one had pride in this, why would anyone care about the things that aren't simple - or bother to train the ability to simplify the complex in the first place! > Micro-services require justification I used to believe this, but have changed my mind on it. Micro-services are great in the current CS ecosystem (at least in the US) because they allow smaller parts of the whole to be more easily refactored when you find your development team with none of the people that were present when design decisions were made and a major feature needs to change. It's an unpleasant situation to be in, and one that you ideally want to avoid happening, but is common enough that preparing for it in your application landscape is reasonable.
  • zem 2y ago
    you don't need microservices to accomplish that - a library with a well designed public api and a language that lets you enforce private functions/methods are good enough,
• mr_tristan 2y ago
  This list does resonate, but I’d make some tweaks to express things slightly better. For example: > Most programming should be done long before a single line of code is written I would say “most engineering should be done before a single line of production code is written”. Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of the new hires. Needless to say, there’s a whole world of complexity in just navigating the system. My take: don’t try to predict when the production code will be done, focus on the next draft, and iterate until we can define and measure what the right impact will be. The problem is that there’s a ton of neanderthal software engineering management thinking that we’re just ticket machines. They think the process is “senior make ticket, anyone implement ticket, unga bunga”. What usually happens here is that we write a bunch of crappy code learning the system, then we’re supposed to just throw that in a PR. Then management is like “it’s done, right” and now there’s a ton of implicit pressure to ship crap. And the technical debt grows. I haven’t quite codified a draft process, but I think it’s kind of in line with what Chris here is talking about: you shouldn’t worry about starting with writing production code until you’re very confident you know exactly what to do. Ah well, it’s a fun list of opinions to read. Chris’ WIP book is an interesting read as well
  • drbawb 2y ago
    >They think the process is “senior make ticket, anyone implement ticket, unga bunga”. The fact that you just summarized about an hour worth of argumentation from my last annual planning meeting with that one sentence has just destroyed me. I kneel. At this precise moment in time, if anybody seriously thought the above was the way the process works or should work, they should be advocating for firing all the juniors and replacing them with LLMs.
    • mr_tristan 2y ago
      > At this precise moment in time, if anybody seriously thought the above was the way the process works or should work, they should be advocating for firing all the juniors and replacing them with LLMs. Sadly, I think this is happening at some places. Like Salesforce. Sigh https://www.ktvu.com/news/salesforce-cutting-1000-jobs-hiring-ai-roles https://www.ktvu.com/news/salesforce-cutting-1000-jobs-hirin...
• aranchelk 2y ago
  > Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy > Objects are extremely good at what they're good at. Blind devotion to functional is dumb. Blind devotion to anything in engineering is dumb, but if you go full functional on the frontend it’s definitely not “Kafkaesque”
  • tasuki 2y ago
    > if you go full functional on the frontend it’s definitely not “Kafkaesque” This has been my experience too. Elm on the frontend is easy and delightful.
    • aranchelk 2y ago
      Right on! I’m using PureScript with an Elm-like framework.
• x3n0ph3n3 2y ago
  > Most programming should be done long before a single line of code is written This definitely contradicts a previous article on Discovery Coding [1]. I can't say I agree with it _at all_, despite 20 years in the business. 1. https://news.ycombinator.com/item?id=42860128 https://news.ycombinator.com/item?id=42860128
• petesergeant 2y ago
  I have a grey beard and have earned my right to have opinions on things, so: > Most programming should be done long before a single line of code is written I think via programming, and I think we should be building more prototypes. Upfront design almost always falls apart, and if you've invested too much into the design, you end up with some nasty frankenstein code. Get a good prototyping process in place instead, and write code and interfaces as early as possible, just make sure you're very willing to throw them away, review what worked, etc. The sooner you prototype, the sooner the "natural" design appears, and the less you've invested in it. > Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy I like React much more than the shit I've enjoyed any of the run-up to it, and I've been building websites since the late 90s, working my way through server-side includes, hidden refreshing iframes, XMLHttpRequest, Prototype.js, jQuery ... and today's React just Makes Sense, man.
• daxfohl 2y ago
  Abstractions are a failure in most libraries too. Invariably something will come up that breaks the abstraction. Either new instances come up that don't quite match, or clients want new functionality that doesn't apply to all instances, or whatever. I've come to the conclusion that in almost all cases, you should avoid providing any abstraction from your own library / service, and let consumers figure out what abstraction makes sense in their domain. By stipulating the abstraction, you're robbing your consumers of the ability to make things work the way they want, and painting your own thing into a corner. When you build the abstraction, it seems like you're doing your consumers a favor. But that favor is short lived as the abstraction changes and breaks your consumers.
  • daxfohl 2y ago
    Half of my team's work right now is changing our abstractions because a couple clients want something slightly different, without breaking existing clients. The other half of my team's work is KLO forced on us by our dependencies needing to change their own abstractions. > When you build the abstraction, it seems like you're doing your consumers a favor. "The road to hell is paved with good intentions."
  • Bjartr 2y ago
    The best libraries provide both the abstractions and the building blocks those abstractions were built from so consumers can benefit from the abstraction when they can, but aren't blocked just because the library devs didn't consider a specific use case.
• anacrolix 2y ago
  This list will look different at 20 years. About half will be the same.
• bob1029 2y ago
  > It's very hard to beat decades of RDBMS research and improvements This is further complicated by the fact that not all RDBMS engines are created equally. It took me 2 decades to develop appreciation regarding why one would actually want to pay for something like SQL Server when options like SQLite and Postgres are free and easy to use.
• er4hn 2y ago
  > Code coverage has absolutely nothing to do with code quality (in many cases, it's inversely proportional) I think this one keeps on being viewed as a % metric. You have 50% code coverage, 75%, 99.9%, 100%, etc. In that sense it is useless. Where I think code coverage has an enormous value is in showing what parts of your logic are/are not covered by test code. Being able to eyeball that and see where key parts of logic are not tested is extremely helpful and tends to get lost in these discussions.
  • Izkata 2y ago
    > Being able to eyeball that and see where key parts of logic are not tested is extremely helpful and tends to get lost in these discussions. I've been saying for years code coverage broadly is fine, we're just presenting the metric in a screwed up way that makes people focus on the wrong thing. It should be absolute value and flipped, presented similar to linting: instead of percent of covered lines, it should be raw count of uncovered lines. Not only does this help you focus on "this code has no tests" instead of "number go up", it removes the painful edge case where refactoring covered code to be shorter makes the percent-based metric worse.
• MajimasEyepatch 2y ago
  > The trouble with functional programming is functional programmers As a former Scala dev, I feel this in my bones.
• dkarl 2y ago
  > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. I wish he'd say which people are the weirdos: the ones who say let's just pick a standard and rigorously enforce compliance, or the ones who complain about the burdens of compliance and try to undermine enforcement. I'd say the latter. I'm surprised he didn't feel the need to be specific.
  • thuanao 2y ago
    Agree. No code standards is a red flag. It betrays a lack of leadership and efficiency. It means the person in charge either doesn't enforce standards, or doesn't see the value in them.
• brodouevencode 2y ago
  > Monoliths remain pretty good > Micro-services require justification (they've increasingly just become assumed) I say the opposite is true. Monoliths have a negative value return with the expansion of an application.
• vrnvu 2y ago
  - Elegance: Articulating the value of absence. https://100r.co/site/computing_and_sustainability.html https://100r.co/site/computing_and_sustainability.html
• zem 2y ago
  mostly good advice, but he's yet another person who seems to think orms are primarily about sql generation. they're not; they're about serialising/deserialising between objects and db columns!
• KronisLV 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL My take on this would be: ORMs are the devil in all languages and all implementations. Static SQL queries with parameters will have a lot of duplication (lots of similar queries), whereas dynamically generating complex SQL will be hard to debug and maintain (e.g. myBatis). Write some good DB views in SQL. Generate some dumb ORM entities against those views for passable querying/filtering/pagination and do whatever works for altering it. Don’t go fully into the opposite direction either and don’t put 99% of your business logic into the DB, that will be hard to work with because the tooling isn’t very good (e.g. stored procedures).
• debarshri 2y ago
  Software development should also be seen from what stage the org is in. Software development looks super different when the org is a startup vs when the market fit is established. When you are a pre-PMF, you have to establish trust. You deliver fast, cut corners, make sure customer needs are met, value is generated. Nothing else matters. When PMF is established. You have to de-risk everything. All your work is at stake. Then best practices has to be in place to makes things scalable, code quality matters because it is a proxy for enforcing standards. I don't think Software can be seen in isolation. It has to be seen from thr orgs perspective.
  • baq 2y ago
    This. Engineers are hired to solve problems. Sometimes beautiful code and clean architecture are part of the requirements to solve the problem at hand. Sometimes… they aren’t.
    • debarshri 2y ago
      Beauty is in the eye of the beholder. I would argue you didn't use design patterns enough. Beautiful code and clean architecture is a rabbit hole. Code should be clean enough to communicate. As long as team understand and accepts the risk, it is good enough.
      • baq 2y ago
        I equate design patterns with language deficiencies, so not sure what to answer. I know 'beautiful' won't be part of the response, though. Code is a liability, unless you're selling it. The less you have of it, the better off you are in the long run. That doesn't mean I don't agree that it should be clean, as an engineer. As a customer making a decision whether to buy a product or not, I couldn't care less. If you're hunting for product-market fit, you can do it with clean code, nothing is stopping you, except perhaps if there's enough runway to make paycheck.
• ljm 2y ago
  > Good management is invaluable Good management is life and death, particularly for a startup. If you think you can do without it and you're not a good manager yourself then it's going to be a struggle to execute. > ...you'll deeply regret building on Serverless Functions Whatever serverless functions promise in scalability, they'll cost you in terms of complexity. Trying to build a cohesive backend entirely in a serverless environment just isn't worth it when it's trivial to boot up a simple, long-running server. Even running locally is a pain in the ass compared to `rails s` or `fastapi dev`. God forbid your serverless environment is actually on the edge, at which point most of the stuff you're used to using won't work.
  • lovetocode 2y ago
    Not all backends are web applications. I have built many step functions applications for various ETL type workloads with massive success with little to no complexity. Just because someone doesn't understand the technology doesn't make it "complex"
• mprast 2y ago
  "Objects are extremely good at what they're good at. Blind devotion to functional is dumb." sure, but I think the status quo is to way overuse objects. my preferred style is to bias heavily towards value objects, and to never ever use things like inheritance for control flow "ORMs are the devil in all languages and all implementations." hard agree lol
• juhanakristian 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL What are the main issues people run into with ORMs? I've used Django ORM for years and written some relatively large applications using it without much problems. Complex queries and aggregations can result in quite hairy code though.
  • ramon156 2y ago
    I can give an example for Prisma. It joins in code, not in SQL. We realized this way too late because we assumed an ORM is optimally structuring code. It wasn't. This, along with the fact that SQL is already a definitive language, made us realize that ORM's are stupid and utterly useless. I'm talking about the ones that try to pretend they're code, and not a query. There are multiple ways you can design an ORM though, and one way is to let the user fully manage how they want the query to run, so you're pretty much structuring a query already. Why not go the extra mile and make an SQL query? I get that ORM's are fine when you don't want to deal with writing queries (e.g. school projects) but for real world apps just take the extra minute...
    • gniting 2y ago
      Perhaps this information will be helpful context for you and for anyone else who happens to land on this post: - https://www.prisma.io/blog/prisma-orm-now-lets-you-choose-the-best-join-strategy-preview https://www.prisma.io/blog/prisma-orm-now-lets-you-choose-th... - https://www.prisma.io/blog/database-vs-application-demystifying-join-strategies https://www.prisma.io/blog/database-vs-application-demystify...
  • Izkata 2y ago
    I've seen and poked at a lot of the ORM-hating on here, and whenever I can get people to give specific examples instead of generic theory-level stuff, it's either not a problem in Django or Django has a fix you just need to learn about and use. The fixes have sometimes even been there for over a decade. It seems be leaps and bounds ahead of every other ORM out there.
    • 2y ago
• lainproliant 2y ago
  In response to "There is no pride in managing or understanding complexity.", I posit the following based on my experience: Understanding and managing complexity is one of the first steps required in order to eliminate complexity. Some of the greatest achievements in my software development career have been instances where I carefully pulled apart inscruitable solutions, often short-term and built in desperation, and re-constituted them into well tested and much less complex solutions which were more understandable by devs and users. I agree with most of Chris' observations and enjoyed reading his insights. Makes me want to do the same!
• the_gipsy 2y ago
  > Typed languages are essential on teams with mixed experience levels > Java is a great language because it's boring Stopped reading there. Ironic that one is right below the other.
• gspencley 2y ago
  > Elegance is not a real metric While I agree with this in spirit, I once made the observation that: "Code quality can be measured by the number of occurrences of 'WTF' uttered by other developers per minute when reading a PR." Elegance might be subjective, but how easy code is to read and understand probably can be quantified even if we don't have the best tooling for that yet. Meaning that if 10 engineers less experienced than me all tell me that they think expressing something one way is easier to understand than another, I take that as objective feedback and change course.
• sesm 2y ago
  Articles like this always remind me of 'The 57 Precepts of Zote'.
• charlieflowers 2y ago
  Good stuff!
• throwaway2037 2y ago
  > 3%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (this estimate is up from 4 years ago) This is 100% of immediate line manager that I have had in my career. Anyone else?
• asalahli 2y ago
  > You literally cannot add too many comments to test code In my opinion, almost every developer I've worked with who advocated for generous amounts of comments has overestimated their (and or others') ability to write good quality comments. Obvious ones like `a = b; // set a to b` while useless are also mostly harmless, but I've been lead astray by outright factually wrong comments, many more times than I can count. I certainly don't feel confident in my own ability to not write factually incorrect comments. So yeah, I'd rather the code do the talking.
  • adamtaylor_13 2y ago
    That’s why your comments should be on things you know to be factual like WHY you made a certain decision. Things like that cannot always be communicated by good variables and functions.
  • Izkata 2y ago
    I suspect they mean in tests, not in general code as hints about testing. A comment block that explains a bit why that test is doing what it's doing can be amazing.
• austin-cheney 2y ago
  [dead]
• joshdavham 2y ago
  > Most programming should be done long before a single line of code is written What does this mean?
  • alkonaut 2y ago
    That you must design the system before you type it down as code. Once you make the wrong assumptions or wrong abstractions no amount or skillful coding can save you. You risk solving the wrong problem perfectly.
    • joshdavham 2y ago
      That makes sense, but if this is the correct interpretation, then I find the wording a little weird. I've always considering "programming" and "writing code" to be the same thing.
      • alkonaut 2y ago
        Yeah I think programming is both ”thinking about what code to write” as well as actually typing it in. One can’t meaningfully separate any steps like ”design” or ”architecture” from programming.
• x3haloed 2y ago
  Good thoughts. I agree with much. I quite disagree with the following: “Most projects don't need to ‘scale’” I get that you’re probably referring to theoretically infinite scaling provided by stuff like microservices, containers, and serverless functions, but I do think it’s part of our job to consider the external factors that affect the functionality of our software. Similar to types being assertions about the external world, so too the design of the code and how it handles scale is an assertion about external factors. It’s important to define the bounds of what our software can handle in terms of throughput and what should happen in case those assumptions break or approach their outer bounds. I think most projects need careful attention to handling unexpectedly large throughput gracefully.
• moose44 2y ago
  > Given a long enough time horizon, you'll deeply regret building on Serverless Functions Could someone expand on this point?
• mindwok 2y ago
  Can someone explain the ORM thing to me? I’ve been a developer for 8 years but never really worked on an app that was really database dependent. ORMs for me have always been convenient, and the performance has been fine. I understand there’s obvious tradeoffs I’m making, and in some cases full control is necessary, but I’ve never seen it happen. What level of complexity does an app need to get to before an ORM becomes a nightmare?
  • mrkeen 2y ago
    Personal pet peeves: * They hide the queries. When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to. And then is there even a way to fix it, or are you stuck with the ORM? * LINQ-specific: Love the tech, but it's unclear whether my .wheres() are being sent upstream properly, or if I'm downloading the whole database and filtering it in memory. * Another LINQ one: we wanted to do "INSERT IF NOT EXISTS" but could not. * Back in Java land, magic like that tends to be incompatible with basic hygiene like consting all your class fields. Frameworks like being able to construct a Foo in an invalid state, and then perform a bunch of mutations until it's in a good state. * They make it near impossible to reason about transaction states. If I call two methods under the same open db context, what side-effects can leak out? If I try to do an UPDATE ... SET x = x + 1, that will always increment correctly in SQL. But if read x from an ORM object and write back x + 1, that looks like I'm just writing a constant, right? * Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never? But just in general, I want to look at the data, play with queries in a repl environment until they look right, and then use directly in the code without needing to translate from high-level&declarative down into imperative loops, sets and gets.
    • wimdetroyer 2y ago
      >When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to Not if you have proper telemetry set up... Tooling like instana was extremely useful for me to diagnose exactly where SQL statements caused issues >Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never? For hibernate if you understand the concepts of: - application level repeatable reads - it's dirty checking mechanism - when the session is flushed / entity lifecycle That 'magic' isn't magic anymore. But every abstraction is leaky (even SQL)
• nitwit005 2y ago
  > Code coverage has absolutely nothing to do with code quality (in many cases, it's inversely proportional) My theory from working at a company that demanded high unit test coverage is that it encourages coding patterns that are easier to create coverage for. Not necessarily easier to genuinely test, but easier to get a high coverage metric. For example, try/catch blocks are bad if you want coverage. Now you have to do things like inject exceptions. People will try to design things so that's not required, with odd side effects.
• Sparkyte 2y ago
  Most to all I agree. I disagree with monoliths and microservices. I am not a fan of microservice per se but I'm not a fan of monoliths either. I certainly prefer a mix depending on their use cases. However both designs deserve equal scrutiny. My monolith horror started when I was working with Ruby developers. The problem with a monolith is when it becomes too big for itself. Realistically something between microservices and monoliths are where quality of life resides. If you need a small service that needs to be fast and focused microservice it. If you need a service where it relies heavily on the same logic and shared across many things. As long as it is performant, modular and easy to fix, monolith it. Either way conforming to one design certainly cripples the potential of services.
  • notTooFarGone 2y ago
    You can build everything the wrong way. In my experience making a monolith modular is organizationally easier than gluing together microservices and step on various toes and getting rid of needless abstractions.
    • Sparkyte 2y ago
      Right, that part I agree with. Microservices if used sparingly in the right way are fantastic as they can offer flexibility in APIs that do not necessarily need a monolith obfuscating certain behaviors away from the monolith making the architecture more secure. Everything needs to be purposefully built and used with the intention of serving the customer's needs without compromise.
• Mikhail_Edoshin 2y ago
  Elegance is not a metric, right. But the primary drive beyond the discovery of non-Euclidean geometries was that the set of axioms did not look elegant.
• wakawaka28 2y ago
  Consistent style makes it possible to search for stuff with less pain. It's not just some kind of OCD.
• serverlessmania 2y ago
  "Given a long enough time horizon, you'll deeply regret building on Serverless Functions" Let's just apply "Hitchens's razor" to this kind of none sense: What can be asserted without evidence can also be dismissed without evidence
  • Defletter 2y ago
    username checks out
• thiscatis 2y ago
  On Serverless since 2018 and we still love it. One thing it had helped us with is deploying and managing customisation for some clients without affecting the wider product.
• jongjong 2y ago
  I don't have a strong opinion about dynamically typed vs statically typed but I have a very strong opinion about interpreted vs compiled. I regret how neglected interpreted languages have become. I'm much more productive with interpreted languages than compiled (or worse; transpiled) languages. The iteration time is crucial for me. I don't want to wait even 30 seconds to test a change. After 20 seconds waiting for a compilation, my brain is already going into sleep mode. I can't have that. For most application-building use cases, I will choose an interpreted dynamically typed language over a compiled statically typed one. When it comes to low-level embedded use cases, or high-performance systems programming I will tolerate a compilation step but I won't pretend like it's not a negative.
• awpteamoose 2y ago
  > It's very hard to beat decades of RDBMS research and improvements 13 yoe here, I don't find this true, in fact I find the opposite - storing data in binary (to minimise de/serialization overhead) and precomputing indices and relations in a simple K/V store easily and immediately annihilates best case performance you could get out of a typical relational DB. I don't work in FAANG so we don't get millions of reads/writes per second, but there's probably more use-cases like us than like FAANG.
• smashedtoatoms 2y ago
  My man!
• 0xbadcafebee 2y ago
  > Elegance is not a real metric Actually I recently discovered it is, it's just not what people think. Elegance is a function of the probability measure of how much someone likes your idea/solution/thing. There is a curve upon which people will think it is more or less elegant. The problem is you can't actually see elegance from your own perspective. You might think it's elegant and it later turns out it's not to anyone else. And vice versa. It's like quantum physics: you have to observe it externally and your guess won't always be right. That doesn't mean it's not a metric. It just depends on multiple probabilistic measures. It's important to gauge the elegance of things because in general, engineers will fight you harder the less elegant your idea is. It might be a better idea, despite its inelegance, but if you're working on a team, the team's acceptance of the idea is more important. (Unless you have total authority, in which case you can do whatever you want) > Most projects (even inside of AWS!) don't need to "scale" and are damaged by pretending so Actually it's the opposite: literally all projects need to scale. The problem, again, is perspective: the scale of the scaling varies. If you have a physical business where you move goods around, you have to choose how to do that. You could buy a bike, or a car, or a truck, container ship, etc to move the goods. You might need just one or you might need many. Your business might increase or stay the same. If you buy a container ship, probably you will never need to add another container ship again, as very few do that much business. But if you buy a bicycle, probably you will need to at least add more bicycles, if not change completely to a car or truck, or multiple. If you use the smallest measure of compute on AWS, it's pretty much a guarantee it won't be sufficient for your entire workload. If you buy the biggest measure of compute, it's almost guaranteed it will be more than big enough. The scale of the scale matters. Scale is therefore, again, a probability measure of whether your workload will match its container. If you could perfectly predict your workload and the capability of the container then this wouldn't be probabilistic. But not only is your workload usually variable, so is the container. Bicycles/cars/trucks/container ships all can fail, so the scale of your workload may reach 0 at some point. The ability to scale dynamically is important in order to eventually deal with failure. Otherwise if your car died you could never get or rent another one, you'd have to sit there becoming an auto mechanic to get your business working again. This is more obvious when you self-host. People take it for granted on AWS, where they don't realize that literally everything in AWS is scalable, and so tell themselves scalability doesn't matter... until it does. If we didn't have a way to scale bicycles/cars/trucks etc (by temporarily or permanently getting another one), the world would be much harder to do anything in.
• ZiiS 2y ago
  "If I think something is easy, that's a sure sign I don't understand it." Feeds fairly strongly into "project managers, could disappear tomorrow to either no effect or a net gain in efficiency."
• etothet 2y ago
  > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. In my experience when working on and/or leading a team, having good and clear code style/guidelines helps the members of the team understand other people’s code much more easily. It often also serves as much easier to understand historical record when looking at previous contributions. I find it’s best to leverage tooling that enforces team conventions so that programmers don’t have to “stress” about it.
• red_admiral 2y ago
  > You have to actively invest in improving your soft skills (and investments pay back immediately) I wonder how much of this can be qualified with "after you've been hired". Between two university graduates with equal skills in technical interviews and splicing linked lists and recursive-descent parsing and whatever, if one has better soft skills, you hire that one. The question is what you do between one who is better at soft skills and another who is better at doubly linked lists or group-by queries or docker orchestration or whatever tech you're asking about in the interview. Empirical evidence suggests you hire the second person and support and expect them to skill up once they're in. If you have spare time at uni, working on both soft and techy skills is great, if you have to trade off opportunity costs, the advice I hear a lot is invest on the technical side first.
• palmotea 2y ago
  > Typed languages are essential on teams with mixed experience levels > Java is a great language because it's boring This. Especially the thing about mixed experience levels.
• danans 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL Agreed, or just use a key/val JSON document database and it's get/set APIs for basic operations. All the main ones also provide indexing and SQL APIs if that's needed.
• _virtu 2y ago
  > ORMs are the devil in all languages and all implementations. Just write the damn SQL I was agreeing with most opinions and then I saw this one. Having used Ecto from the elixir ecosystem completely changed my mind on this. It's an amazing piece of software.
• forgotpwd16 2y ago
  Presentation bit confusing since it's written comparatively (opinions changed/added/retained) but there isn't a reference list. (Maybe they keep such a list in their personal notes.) Compared to the older post (at 6y), none has been flipped (and actually some were strengthened, e.g. typing in mixed experience teams going from better to essential).
• sethammons 2y ago
  I've been at this a couple decades, focusing on SaaS, rising up with and through a unicorn, and having worked at over half a dozen real engineering orgs, I agree with just about everything in the article. My two differing thoughts: 1) Gradual, dependently typed languages are the future: no, just go with something typed. We are trying to type our python code base right now. It sucks. 2) People who stress over code style...: I love go fmt. Use tooling and linters. Be consistent in the code base. Inconsistent styles can lead to misreading code.
• psunavy03 2y ago
  So "management is invaluable" but "most project managers are worthless." Not necessarily a contradiction, but it makes you go "hmm." At some point, you have to have someone looking "up and out" to make sure the folks looking "down and in" are all still moving in the same direction.
• bilbo-b-baggins 2y ago
  > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. Considering anyone who is any good is gonna automate these things… and they are very important for long term maintenance and readability and predictability… … probably the author is terrible. Sad to waste a decade.
• rglynn 2y ago
  As always on here, a lot of people appear to act as if there are universal truths about our craft. I would posit that the exact enviroment you are in changes massively what is correct, what is a good rule of thumb and what is a bad practice. What applies to a game developer does not apply to a web developer. What applies to a product developer does not apply to a library developer. What applies in a startup does not apply in a legacy org. I'm sure there are some universal truths, but usually they are principles and not prescriptions. E.g. Code should probably lean toward readability, but you quickly come up against time constraints, language constraints, performance constraints, interpersonal conflict, etc. Edit: To that end, I would ask that when discussing what we find to be useful or not useful, that we caveat with the enviroments that we have found this to be true.
• RandomMarius 2y ago
  People who stress about people who stress about linting… focus on something else. Everyone has their idiosyncrasies. A lot of great coders have psychological oddities. Some things help them focus. Whether it’s neat environment, listening to music, consistent code formatting. I listen to them and try and accommodate even if I disagree. I’ve changed my mind about several topics multiple times now. I felt strongly about some at one point over the past few decades as well.
• damnever 2y ago
  > Distributed locking is still really hard for some reason I think distributed locking is hard because it only offers certain properties and requires that the application work together to achieve consistency, just like what you said about DynamoDB: > DynamoDB is a good database (IFF your workload lines up with what it's offering) I have written a blog post about distributed locks: https://blog.damnever.com/en/2020/the-consistency-problem-of-distributed-lock https://blog.damnever.com/en/2020/the-consistency-problem-of...
• antfarm 2y ago
  > Simple is not given. It takes constant work. That was actually one of the first things I understood about programming 30 years ago. Accidental complexity is the root af all evil.
• mikesteven 2y ago
  [dead]