1. 2

    Hi, congrats on your first article! I didn’t knew Cloudflare supported an equivalent to Amazon lambda function.

    Having read a lot about Oauth in the last few weeks, I learned something that you may find useful: In the case of Google, there is actually a way to get the user email without the worker: you can use Oauth implicit flow. If you specify id_token in response_type, it will use an implicit flow, which does not require a clientSecret (only your client id, but that is not something that need to be kept secret). Google seems to secure this by making you register what is the valid domain from which the call can be made. When the flow is completed and the final redirect occur, the token will be included directly in a URL hash fragment that you can read with JS (rather than a code to obtain said token). That token is a JWT that will contain the user email.

    If you use google sign-in or their provided google api javascript library, I think you can even get the information without ever leaving your app (you simply provide a javascript callback for when the authentication has completed)

    You can check it out at https://developers.google.com/identity/protocols/oauth2/openid-connect and https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow

    Sadly, GitHub does not support any of this, so you do require the worker function in their case. This ultimately mean that your solution is the most generic possible, so, nice one :)

    1. 2

      Good to know. I ended up implementing OAuth on Netlify using their Lambda adapter last week because I wanted to be able to connect to Google Docs. I guess I still would have needed Lambda for the docs processing I wanted to do, but in theory it could be moved to WASM and done as purely static pages.

      1. 1

        Wow, thanks! I didn’t know this. The Google docs in general for getting email information via OAuth seem slightly outdated. I had to rely on a Stackoverflow answer from 2019 because the API they said I should query in their docs wasn’t working. Yeah I’ll keep it as is for now so that it’s consistent, but thank you for suggestion. I’ll definitely remember that for the future :)

      1. 3

        Dear Drew

        I want to raise a small point, not with your argument, but with the text you wrote. You say it’s okay to sacrifice a bit of what you call “usability” for what you call “utility”. And by usability I understand you mean the ease of understanding the tool, and by utility the ability to get something done with it. But usability can also be understood, in the eye of many, the ability to use the tool effectively. For such persons who read a bit too fast, what it seem you say is “It’s okay to make the tool less effective to use in order to make it more effective to use.”. And of course they’ll disagree with such a blatant contradiction of logic.

        I would suggest that maybe your text will be better would you be restate your argument with simple, easy to understand word as follow : “It’s okay to write tool that take time to learn if, by sacrificing the time to get effective, we get a design that allow expert to work very fast.”

        I know it is longer and it is more annoying to write it like that, but the reason I encourage you to restate your argument, is that us developer are a bunch of big nerds, and when us big nerds see big word with precise definition, we become full of big self-righteousness and start yelling: “Well, ACTUALLY, that is NOT what the words “usability” and “utility” MEAN”. And then the debate evolve to be about what the correct definition of the words are, completely drowning the point originally made. This is not very efficent.

        In other words, big “precise” word have poor usability, because nobody understand them in exactly the same way, but every nerd think it has the One True Definition™. As such their utility to get a point across is rather limited. It’s easy to think they allow you to communicate faster, but, unless everybody took the time to standardize such word in the same, precise way, they just confuse everybody. You really have to think about the correct time to use them, and they should be avoided when possible. They most certainly should not be used as an excuse to communicate poorly.

        I hope you understand what I mean?

        1. 3

          Well, “90% of anything is crap”, according to Theodore Sturgeon. I think is a useful rule of thumbs. But I would argue though that too much idiosyncrasy and “I listen to my own experience” is not perfect either. The lessons you learned through your own questioning and experience may not be as broadly applicable as you imagine, and the experience of others may well contradict your own. The anecdote given by another commenter on Google engineer talking about scaling to a crowd of beginner is a good example of this.

          Karl Popper theorized that we gain confidence in an hypothesis as it get tested across dimensions, and as we generalize its context. Does the advice apply to the small startup as well as the bank as well as Google? Is it true in greenfield as well as brownfield codebase? 100 users and 1 billion? The reason the advice is bad can be because it is false, but it may be that it is not applicable to your context. Your own experience and hard learned lesson may be a poor advice to somebody else, even to future you!

          A lot of advice should be rejected outright because it is just some guy thinking without checking the facts. This is very common, and why it is wise to check what one do, rather than what one say. Then, a whole bunch of advice are, sadly, wrong conclusion from real fact, and those should at least be looked at, to see if you can find the real lesson hidden behind the error. Then some advice are real hard earned wisdom that don’t apply to you… yet. They are not crap, just a poor fit right now. And it may well be that some day you’ll find yourself discovering that in your new situation, they are right!

          1. 23

            The short answer would be : Conway law combined with familarity. The system reproduce the communication structure of the organization. The front-end have a need to do some supporting stuff on the backend, but the backend belong to another team, and it’s easier for them to just wrap that backend in a “backend for frontend” that to deal with the politic. So they build a new system. And that system is likely to be in JS because that’s what they know.

            For the long answer: let me just note that your question is actually two questions:

            1. Why are they adding a proxy?
            2. Why do they want to write backend code in NodeJS?

            Let answer the second question first. Why build backend component in NodeJS? Well, Node is already used in the frontend team build, along with mocha, chai, eslint, and other node standard tools. They already manage their dependencies via NPM. Building a backend part in Node mean using the exact same set of tool that they know, and the same language that they know, and the same IDE that they know. This is why my personal projects use Node: I use JS anyway for the UI, and it is less friction to just use it on the backend too, as I don’t have to write my string-util module twice.

            First question now: Why a proxy? Having introduced such a proxy in a project, our stated reasons was control and risks: the existing mission system was hard to work with, had no tests, and took 15 minutes to boot. Changing it involved political discussions with people that viewed changes as dangerous to their job. Any outage was 30 000$ per hour in cost. It took 6 week for new code to be in production. With a non-mission critical proxy in our control, no such restraint: release was on every pull-request, and we could use TDD, static check our code, do automated deploy in the cloud, without asking the permission to anybody. If the project was ever cancelled, there was little to rip out of the existing mission system. Also, our proxy was doing tasks like validating form values, which was strongly coupled to a UI that was changing with every whim of marketing and UX. Had we not introduced the proxy, our capacity to iterate and accommodate their request would have been seriously hampered. I still stand by our decision to introduce it.

            An interesting point : We built said proxy in Java. Since we were Java dev, this is what we knew. The JS part was the new part we didn’t knew much about, and we wanted to limit the part were we would do dumb stuff. If the team had been familiar in JS already, I may well have recommended to use Node.

            1. 6

              Conquering isolationism is a task for everyone, not just functional programmers. The computing industry is now beginning to deploy standards, such as CORBA and COM, that support the construction of software from reusable components. Recent work allows any Haskell program to be packaged as a COM component, and any COM component to be called from Haskell. Among other applications, this allows Haskell to be used as a scripting language for Microsoft’s Internet Explorer web browser [4].

              Well, it’s definitely written in 1998!

              1. 3

                Ah, I remember that dark time ,where we would be rescued from the despair of CORBA by the hope of SOAP…

                1. 2

                  And then, we were to be rescued of the complexity of SOAP by embracing REST.

                  And now, are we to be rescued of REST by embracing yet a new miracle solution? Or did we at last reached a local minima that’s gonna last for a while? Only time -or viral blog posts written by kids too cool for HTTP- will tell, I guess.

                  1. 4

                    Fear not! GraphQL will save you!

              1. 37

                At my former employer, for a time I was in charge of upgrading our self-managed Kubernetes cluster in-place to new versions and found this to eventually be an insurmountable task for a single person to handle without causing significant downtime.

                We can argue about whether upgrading in-place was a good idea or not (spoiler: it’s not), but it’s what we did at the time for financial reasons (read: we were cheap) and because the nodes we ran on (r4.2xl if I remember correctly) would often not exist in a quantity significant enough to be able to stand up a whole new cluster and migrate over to it.

                My memory of steps to maybe successfully upgrade your cluster in-place, all sussed out by repeated dramatic failure:

                1. Never upgrade more than a single point release at a time; otherwise there are too many moving pieces to handle
                2. Read change log comprehensively, and have someone else read it as well to make sure you didn’t miss anything important. Also read the issue tracker, and do some searching to see if anyone has had significant problems.
                3. Determine how much, if any, of the change log applies to your cluster
                4. If there are breaking changes, have a plan for how to handle the transition
                5. Replace a single master node and let it “bake” as part of the cluster for a sufficient amount of time not less than a single day. This gave time to watch the logs and determine if there was an undocumented bug in the release that would break the cluster.
                6. Upgrade the rest of the master nodes and monitor, similar to above
                7. Make sure the above process(es) didn’t cause etcd to break
                8. Add a single new node to the cluster, monitoring to make sure it takes load correctly and doesn’t encounter an undocumented breaking change or bug. Bake for some day(s).
                9. Drain and replace remaining nodes, one a time, over a period of days, allowing the cluster to handle the changes in load over this time. Hope that all the services you have running (DNS, deployments, etc.) can gracefully handle these node changes. Also hope that you don’t end up in a situation where 9/10 of the nodes’ services are broken, but the remaining 1 original service is silently picking up the slack and hence nothing will fail until the last node gets replaced, at which point everything will fail at once catastrophically.
                10. Watch all your monitoring like a hawk and hope that you don’t encounter any more undocumented breaking changes, deprecations, removals, and/or service disruptions, and/or intermittent failures caused by the interaction of the enormous number of moving parts in any cluster.

                There were times that a single point release upgrade would take weeks, if not months, interspersed by us finding Kubernetes bugs that maybe one other person on the internet had encountered and that had no documented solution.

                After being chastised for “breaking production” so many times despite meticulous effort, I decided that being the “Kubernetes upgrader” wasn’t worth the trouble. After I left, is seems that nobody else was successfully able to upgrade either, and they gave up doing so entirely.

                This was in the 1.2-1.9 days, for reference, so though I’d be very surprised things may be much better now.

                1. 33

                  tldr; If you can’t afford 6+ full-time people to babysit k8s, you shouldn’t be using it.

                  1. 13

                    Or, at least, not running it on-prem.

                    1. 6

                      True, if you out source the management of k8s, you can avoid the full-time team of babysitters, but that’s true of anything. But then you have the outsourcing headache(s) not including the cost(like you still need someone responsible for the contract, and for interacting with the outsourced team).

                      Outsourcing just gives you different, and if you selected wisely, less, problems.

                      1. 5

                        True dat. But every solution to a given problem has trade-offs. Not using Kubernetes in favour of a different orchestration system will also have different problems. Not using orchestration for your containers at all will give you different problems (unless you’re still too small to need orchestration, in which case yes you should not be using k8s). Not using containers at all will give you different problems. ad infinitum :)

                        1. 6

                          Most companies are too small to really need orchestration.

                          1. 2

                            Totally!

                    2. 2

                      I keep having flashbacks to when virtualization was new and everyone was freaking out over xen vs. kvm vs. VMWare and how to run their own hypervisors. Now we just push the Amazon or Google button and let them deal with it. I’ll bet it 5 years we’ll laugh about trying to run our own k8s clusters in the same way.

                      1. 8

                        Yeah, this is the kind of non value added activity that just beg to be outsourced to specialists.

                        I have a friend who work in a bakery. I learned the other day that they outsourced a crucial activity to a contractor: handling their cleaning cloths. Everyday, a guy come to pick up a couple garbage bag full of dirty cleaning cloth, then dump the same number of bag full of cleans one. This is crucial: one day the guy was late, and the bakery staff had trouble keeping the bakery clean: the owner lived upstairs and used his own washing machine as a backup, but it could not handle the load.

                        But the thing is: while the bakery need this service, it does not need it to differentiate itself. As long as the cloth are there, it can keep on running. If the guy stop cleaning cloth, he can be trivially replaced with another provider, with minimal impact on the bakery. After all, people don’t buy bread because of how the dirty cloth are handled. They buy bread because the bread is good. The bakery should never outsource his bread making. But the cleaning of dirty cloth? Yes, absolutely.

                        To get back to Kubernetes, and virtualization : what does anyone hope to gain by doing it themselves? Maybe regulation need it. Maybe their is some special need. I am not saying it is never useful. But for many people, the answer is often: not much. Most customers will not care. They are here for their tasty bread, a.k.a. getting their problem solved.

                        I would be tempted to go as far as saying that maybe you should outsource one level higher, and not even worry about Kubernetes at all: services like Heroku or Amazon Beanstalk handle the scaling and a lot of other concerns for you with a much simpler model. But at this point, you are tying yourself to a provider, and that come with its own set of problems… I guess it depends.

                        1. 2

                          This is a really great analogy, thank you!

                          1. 2

                            It really depends on what the business is about: tangible objects or information. The baker clothes, given away to a 3rd party, do not include all personal information of those buying bread. Also, business critical information such as who bought bread, what type and when is not included in the clothes. This would be bad in general, and potentially a disaster if the laundry company were also in the bread business.

                            1. -7

                              gosh. so much words to say “outsource, but not your core competency”

                              1. 1

                                Nope. :) Despite my verbosity we haven’t managed to communicate. The article says: do not use things you don’t need (k8s). If you don’t need it, there’s no outsourcing to do. Outsourcing has strategical disadvantages when it comes to your users data, entirely unrelated to whether running an infra is your core business or not. I would now add: avoid metaphors comparing tech and the tangible world because you end up trivializing the discussion and missing the point.

                        2. 3

                          As a counterpoint to the DIY k8s pain: We’ve been using GKE with auto-upgrading nodes for a while now without seeing issues. Admittedly, we aren’t k8s “power users”, mainly just running a bunch of compute-with-ingress services. The main disruption is when API versions get deprecated and we have to upgrade our app configs.

                          1. 2

                            I ahd the same problems with OpenStack :P If it works, it’s kinda nice. If your actual job is not “keeping the infra for your infra running”, don’t do it.

                          1. 7

                            I’ll be honest: when I read the usage printout of a command and find the flag that does exactly what my strange and obscur use case require, I feel really, really happy. Maybe this is bloat, but this is bloat that make me productive, and I have trouble getting worked up over that notion.

                            1. 3

                              I’m in the middle of listening to the Socratic dialog on Audible. I’ll be honest, from where I stand, Socrate documenting an API would be him claiming that he does not know what a good API is, then asking me to try to explain to him what make a good API, then after I said something, he would hijack the conversation for 20 minutes where he would rave about the good and why since a physician is good by the virtue of curing the disease, the API is good by virtue of curing the database of its inconsistencies (or whatever), then use that long harangue to display to me that I don’t know what a good API is, then I would ask him a bit frustrated “well, what make an API good”, to which he would answer that he does not know because he does not know what the “good” is and that he need me to teach him. Go back to beginning and start over, until I get frustrated and start thinking that this guys would sure deserve to be put to death for being so damn annoying.

                              Of course he would barely mention the API itself, but then, since we don’t know what the good is, we can’t know what a good API is, and because of this, we cannot know if that particular API is of any good. “And yet, you seems to know what a great API is, but you refuse to tell me!” would probably have been uttered at some point in the dialog.

                              Yeah, the Socratic dialog are great to listen to. 😆

                              1. 2

                                Yes, the term “Socratic dialog” has come a long way from what Socrates himself actually engaged in. But then, it has been a couple thousand years, so maybe that’s not surprising.

                              1. 21

                                The author doesn’t mention a more important problem with the new, ‘clean’ code: it replaces repetition with lots of new local idioms, making it much harder to read.

                                I think the intuition of trying to prevent repetition was correct, but it seems to me that he could simply have extracted some duplicate math into a separate function instead.

                                1. 17

                                  This is my immediate reaction to this entry too. They ‘cleaned’ their code by introducing ad hoc abstractions which a future reader could not escape from. They didn’t quite remove repetition, they traded it for a more complicated structure. Which now puzzles them that it is cognitively more expensive than their previous code.

                                  This is the problem with blindly following mantras. People follow mantras blindly after some guy in some fancy blog post or book says it is a good idea, rather than understanding why it is [potentially] a good idea. The tittle hints it as it refers to a book that replaced common sense with a cult. Notice the sentimental attachment in ‘goodbye’.

                                  They should have resourced to a construct that any possible reader already is familiar with: a function, providing a free abstraction. Of course, the problem they had at hands is essentially side effecting the system, which challenges this strategy.

                                  1. 6

                                    Yeah. Simple and dumb code using universally known abstractions (function, list, map) is often better that a clever custom made one.

                                    There was a consultant coming once to teach us to be a better coder. The style was much “I read a lot of book, but haven’t had a lot of experience working in enterprise”. At some point he made us do a Kata exercises where we modeled a system triaging patient in a hospital. The point he was trying to made was that we should extract an abstraction for a priority queue.

                                    — Was it better once you extracted you queue?
                                    — I didn’t extract a queue.
                                    — Then your code doesn’t reflect an important abstraction in the domain.
                                    — Honestly, I think my code is fine and I would be perfectly happy to find it in the wild. It use Java Lists and Maps, has well named variable and is well chopped into reasonably sized function.
                                    — But you are missing a concept.
                                    — Honestly, for that kind of code, I always found that the way it is coded now is the way I would regret the least later.
                                    — it’s not domain driven
                                    — Maybe not. But it’s easy to read, work correctly and easy to changes, and that is what I ever cared about.
                                    — you may have trouble later because the missing abstraction will make people add code haphazardly.
                                    — They would do it no matter what in my experience, and we have code review for that. What about you? Do you ever found that it ever help?
                                    — Abstractions help a lot actually. They allow you to…
                                    — Yes, yes, but can you give a me real and concrete experience where YOU created such an abstraction in a production code base and list me some REAL problem you found it avoided?

                                    At this point, the conversation stopped being productive because one of us could not really speak from a real tangible experience.

                                    1. 3

                                      “Bro have u even shipped” is a valid rhetorical device to end a conversation, it might have been more educational if the consultant showed their abstraction. I would like to be that guy and point out that you are both right, I just don’t want to work at the place that embraces the consultant’s techniques.

                                      I had a similar experience with a Design Pattern consultant, he even had a book. When I asked about a systemic pattern of flaws in code bases he drew a complete blank. No concept of antipatterns. I don’t mean in the sense of X bad, Y good, but more of when one goes down path Gamma, you are implicitly signing up for G, H and K.

                                      Humans are crazy full of cognitive blind spots, experts even more so. Lots of folks are in do loops when they would be better served with a why loop.

                                  1. 11

                                    I’d recommend “Data and Reality” by William Kent. More of a philosophy book geared toward programmers, but it is asking good questions. The book has been updated a few times since the 70s, so the stale content has been removed.

                                    In the non-technical variety, “Zen and the Art of Motorcycle maintenance”, which was published in the 70s also. It’s an introspection into what quality and expertise is made of.

                                    Also published in the 70s, “The timeless way of building”, which args for looking at patterns in the way people build. This and it’s successor, “A pattern languages” are the inspiration for design patterns. The difference between the original thought and what has been made of it make for an interesting read.

                                    1. 3

                                      The only part of Zen and the art… that stuck with me was the beer can shim.

                                      However most of Zen Flesh and Zen bones is permanently wired into my head.

                                      1. 3

                                        I’d recommend “Data and Reality” by William Kent.

                                        Seconded. Great book. I found it went nicely with The Systems Bible, by John Gall.

                                        1. 1

                                          OOH Data and Reality is even availabe on Audible! Woot I am there! :) Thanks for the recommendation.

                                          1. 1

                                            I’d recommend “Data and Reality” by William Kent. More of a philosophy book geared toward programmers, but it is asking good questions. The book has been updated a few times since the 70s, so the stale content has been removed.

                                            While I came here to second Data and Reality, be warned about the third edition. It was updated after Kent died, removed something like half of the original text, and replaced it with the editor’s (Steve Hoberman) own half-baked ideas. And while the book says it put the new stuff in italics, but at least on Safari it often presents The content as the original.

                                            Try to read both the earlier editions: the content is the same but it’s a book worth reading twice.

                                            1. 1

                                              I’m about 3/4 of the way through the most recent edition now on Audible.

                                              I haven’t read the earlier editions (and may not get to any time soon) but I just wanted to say the sidebars by Steve Hoberman are getting on my nerves. They’re mostly breathless generalizations about the author’s original ideas and I’m finding them to be a distraction I wish I could skip.

                                              GREAT book though, so glad I’m reading it. Thanks @laurentbroy for the recommendation!

                                            2. 1

                                              In the non-technical variety, “Zen and the Art of Motorcycle maintenance”, which was published in the 70s also. It’s an introspection into what quality and expertise is made of.

                                              When reading this one I had a feeling that the entire concept could be more succinctly put instead of constant repetition of the same theme.

                                            1. 3

                                              One junior dev on my team once suggested to use a whitelisting gitignore, which only specified the file to keep (for example, everything in src/, config/, a few dotfile file at the root..). I was skeptic at first, but I gotta admit that it solved rather elegantly this issue, as any combination of editor was automatically ignored.

                                              The downside was that whitelisting in a gitignore has a bit of a wonky syntax, and it made it easier to forget to add a file that was not already whitelisted. But all in all, I think this is something that should be tried more.

                                              1. 4

                                                For work: The Toyota Production System by Taiichi Ohno

                                                Personal: Thus spake Zarathustra, by Nieztches

                                                1. 1

                                                  I feel like the article focus overly on the Gang of Four book. Yes, this book has aged poorly, and is more than overly due for a 2nd edition. The endless cheerleading for 90s style OOP, the focus on C++ are not that much relevant for the programmer today.

                                                  There are many patterns books that were published in between that are much better. Recently, I purchased Microservices patterns, which was quite interesting. I don’t think that “Client Side Load Balancing” (a la Eureka/Ribbon in Spring Cloud) could really be interpreted as a way to fix poor syntax in language: it’s a netwoking pattern, and could apply in Elixir or Clojure as well as in C. Another favorite book of mine is “Release it”: are the patterns “Circuit Breaker” and “Correlation Id” really something that only poor programmer use to avoid thinking? I don’t know. For me, having those little nuggets of solution felt very instructive. And I used those two terms very directly when talking with my colleagues about our latest app.

                                                  Heck, I have book called “the rule of photography and the art of breaking them”. While not using the word “patterns”, it certainly has the structure of a pattern book. For each rule (i.e. the patterns), it describe what the rule help for, how to apply it, and when to decide to not apply it.

                                                  Patterns, as a way to describe a “dictionary of tips and strategy” have been around for a long time. If all you think about when you hear patterns are the old Facade, Proxy, etc, then I agree with you that this specific list is not that useful. The general concept of patterns, however, I find very relevant

                                                  1. 8

                                                    Or maybe do pay the early adopter tax? Sometime, if you have few downside and only upside, it make sense to take the risk. If you buy the latest VR kit, the most you can lose is the money you paid, and you get to enjoy stuff few people enjoy. Better yet, early adopter community are often fun, full of buzzing idea and potentials. I’d say it would be pretty worth it to invest a little in such an immature technology.

                                                    On the other hand, if you only have downside, stay far, far away. Updating your work computer to the latest and greatest version of the MacBook will not make your accounting any easier. All it can do is preventing you to work. Plus, laptop and phone are pretty much a solved problem these days. So what if you don’t have the new useless gizmo in Apple MBP? It is just not worth it.

                                                    I can’t help but notice that most of the element alluded to are all Apple products that are way less innovative today than they were a decade ago. Yes, I concur, there is little point in being an early adopter for the latest iteration of those old product, because there is little to gain. But I wouldn’t generalize the approach to everything. Early adopter of the Raspberry Pie had a ton of useful ideas of how to use them, and I certainly wouldn’t consider their time wasted or their purchase worthless. It always depend!

                                                    1. 6

                                                      I really gotta ask: what is the big difference between this and Concurrent Sequential Process or the Actor model? Is there a special benefit to this model that the two previously mentionned does not have? Because, from my uninformed point of view, all three seems to be various way of implementing the same general idea, with only small variation between the three.

                                                      Kind of like how Model View Controller, Model View Presenter and Model View ViewModel are all basically the same idea, with only the direction of the arrow differing.

                                                      1. 2

                                                        Feels to me like one of those game theory problem: “if everybody collaborate then it is better for everyone”. And then it take just one “selfish” (I use the term loosely here) person using 120 char lines and your space optimization trick is kaput. If you have a large team, vendor in some external code, or do anything that increase the entropy of your code base style, then it may be easier to just accept that lines are gonna be longer and you won’t be able to file open side by side on one screen.

                                                        And, as was hinted by others, some language tend to create large lines. If you code in JavaScript, add an IIFE, some function expression for your test framework, then you are a few callback deep and then need to add a if… you don’t have much remaining space to code anything. Likewise, in Java, if you use Spring and have to use some sort of “ProviderControllerProxyGeneratorFactory”, it eat up line width pretty fast.

                                                        That said, I also found that going with a vertical layout for my code, rather than cramming everything in a one liner, does lead to more readable code. So there is merit in optimizing for short width. I just don’t think a hard limit is necessary, or always beneficial. Better decide case by case if you ask me!

                                                        1. 2

                                                          Is this meant to be a transcript of the audio version of the book? Or is this someone’s paraphrasing of the book?

                                                          I’m reading it trying to figure out why it’s in the third person and to whom it refers when saying “His main point ….” and “He concludes”. Is this a note-taker ascribing these comments to Graeber? Or is this Graeber referring to someone else?

                                                          1. 3

                                                            He is quoting someone working in IT who was disgruntled with his work. A lot of the book actually consists of such testimony, rather than hard data. So yeah, this is some random bloke opinion, which found its way into a published book.

                                                            That being said, I do believe this a point worth discussing. It kind of sound like Alex Papadimoulis idea that programming will always be boring in a job context http://thedailywtf.com/articles/Programming-Sucks!-Or-At-Least%2c-It-Ought-To-

                                                            1. 3

                                                              I think the book and the article you shared is helping me realize some realities about the industry and the point that I wanted to discuss is exactly this: how to enjoy work. For me to enjoy my job is definitely not about the money and this can make things harder.

                                                              By what Graeber says is not common to classify software development as a bullshit job, but there’s in fact a lot of software development bullshit going on. If it’s not because you’re duct taping software together, maybe is because you are producing today the bugs that you will fix tomorrow, maybe because the marketing is promising unnecessary features, maybe because clients are demanding unnecessary features or maybe because the business is not providing any value to society at all.

                                                              Ignorance is a bliss: probably I would be very happy staying in my meaningless job for 10 years fixing the same bugs and earning my money, but as I believe what I’m doing is bullshit I don’t actually have another option, I need to keep looking for a meaningful job.

                                                              1. 2

                                                                I haven’t read the book, but the author has stated that in order for a job to be a Bullshit Job:

                                                                if the job, or even the whole industry, were to vanish, either it would make no difference to anyone, or the world might even be a slightly better place. [0]

                                                                That doesn’t mean that a glue-code programming job isn’t crushingly boring or soul destroying, but it might mean that it doesn’t count as Bullshit.

                                                                IME the worst kind of glue-code programming jobs tend to be gluing together non-free applications such as CRMs and email marketing or sales systems. At least if you’re working with free / open source software and it doesn’t meet your need in some way, your employer may pay you to fix it upstream.

                                                                [0] https://www.economist.com/open-future/2018/06/29/bullshit-jobs-and-the-yoke-of-managerial-feudalism