1. 10
  1. 7

    I sometimes think about this in terms of “full stack” vs frontend / backend web dev. Obviously, truly “full stack” development is impossible unless you build your own hardware, OS, network stack, programming language, etc. etc. So “full stack” always at its best means “fuller stack” as compared to some alternative. I think the alternative it should be compared to is the alternative of saying “that’s not my problem.” “Oh, the button is too small to tap on mobile? That’s not my problem, I’m backend.” “Oh, the page has too slow of a time to first byte? That’s not my problem, I’m front end.” Etc. Full stack is just an attitude that if you care about the product, everything is your problem. :-)

    1. 13

      “Oh, the button is too small to tap on mobile? That’s not my problem, I’m backend.”

      “I would love to fix the button, but I fixed similar things in the past, and it didn’t look right, and I know I don’t have an eye for design, so I rather not. Also there are considerations about the screen size/software versions/things I don’t even know I should care about, which I don’t know enough about. So I’ll leave it to the people who actually know about this stuff, and they can do a quick solid fix. But while looking at the button noticed the page loaded a bit slower than I would like, and I saw some things I can improve there on the backend”

      1. 5

        I see this attitude sometimes called ownership. If you own it, everything is your problem. This attitude is absolutely valuable.

        However, I think there’s a question of means even within the shared goal of ownership or full-stack. If you see a problem, you could:

        • File a bug report, and navigate the process to get it prioritized, fixed, deployed to every one, pick up the change, deploy it to your context.
        • Change the code and deploy it to your context.

        Both are valid paths for an owner to follow. I think the second is often ignored or forgotten.

        1. 3

          Obviously, truly “full stack” development is impossible unless you build your own hardware, OS, network stack, programming language,

          Eh, choosing to take something off-the-shelf is a perfectly acceptable decision to make. For things like hardware and OS, that’s most likely the best decision. But the higher you get to the top, the more likely that you need to go custom. But even then, you might, for example #include<stdlib.h> for small parts of your backend.

          I was hired for a job once quite some time ago, when I figured the best solution was to make a very basic website that embeds some licensed video player that ran off a licensed media server that streamed stuff from an off-the-shelf camera that I screwed to the wall with off-the-shelf hardware. The job was “stream video from this location to the website”, so that’s full-stack - they didn’t hire me to just make a website, but rather to figure out the whole problem - but it actually made most sense for me to just buy 99% of the requirements. I perhaps could have done more custom and kept more of the money (the license fees came out of the same budget as my pay), but this way the project was done in two days instead of….. well i don’t even know. I probably still would have bought an off-the-shelf camera at least!

          Same thing with the website - good chance the full stack developer at least has some influence down to the hardware, but you’ll almost certainly just buy something even if you did have enough budget and know-how to design something so you save the time.

          1. 3

            Web developers calling themselves ‘full stack’ is one of my pet peeves. My team works on microarchitecture, architecture, language design and implementation, and OS and distributed system design and implementation. We’re aware that there are layers below us in the stack (we don’t do any gate-level design or anything that involves caring about the physics of IC fabrication processes) and layers above us (we don’t do graphics things or any user-facing HCI things [though that was how I started down this rabbit hole]). Full-stack web developers sit at the top one or two layers in two different stacks and deny the existence of the 20 layers below them in each stack.

            1. 4

              Your “ire” is misplaced, because it’s an industry term, sad as it is. Even most web developers I know who actually have some experience outside web dev hate the term, because you can be a web developer and still do SRE work, work on languages, or on the kernel. Sadly it’s too late, the ship has sailed. This is the term for web developers now. Maybe we should coin a new one for people actually going down from JS to a backend, to the OS and hardware :)

              1. 2

                The term changed many years ago though. I remember job postings for full stack engineers which meant taking care of the infrastructure as will as the web service code. I was very annoyed when it changed, but you can’t argue with descriptivists…

                I think the term you want exists already: generalist engineer. Although everyone will have a slightly different view on that one too.

          2. 3

            @akkartik that sounds cool, though it also makes me wonder if such an approach doesn’t lead to the Lisp Curse - or, are there ways to still escape it? In particular, I currently tend to think of the Lisp Curse as that when something is too easy to hack on and tweak, the comparably high effort to document & refactor this for others/for reuse becomes hard to justify; whereas if it’s somewhat harder to write some code, spending some extra effort to make it nicely reusable becomes comparably small and easier to justify. But that’s just a hypothesis, and a somewhat pessimistic one at that, so I’d love to be argued out of it, or shown a third way/counterexample. Still, if it’s true, I wonder if there could be ways to bring the refactoring or documenting or making attractive to others cost also down, so that it could still encourage sharing one’s own - and using others’ - code. In fact, as much as I dislike npm and the leftpad situation, I think npm might have made sharing relatively easy and that it might be good in a way. I seem to recall Joe Armstrong also had some ideas about easy sharing of code at function level granularity. In a way maybe github is also a kind of an attempt at implementing this ideal to some extent (and obviously sourceforge before that). Though personally I like to dream of some more decentralized space for this kind of sharing, like via IPFS or something.

            1. 2

              I think you’re right that the Lisp Curse is at the end of this continuum. But what I’d like to focus on is that it is a continuum. When something is packaged up just right, use it! But when you encounter problems with it, don’t be afraid to change the code. Currently we’re all too often treating reuse/modify as an eternal, immutable, binary choice.

              But that’s a simplistic answer. What makes the problem complex is that our tools for packaging up software fail to acknowledge the value of changing the code. They prioritize packaged use to such an extent that they make changing the code too difficult. Things like gem installing packages to some shared place that make it difficult to even locate where the code is. At this point we’re dealing with decades of tools over-prioritizing packaged use over naked use/change.

              OP was triggered by the asdf fiasco in the Common Lisp community. My reaction to it was, “you all were given God’s way of writing code. And you somehow managed to shackle yourselves with the ways lesser languages manage code. The most malleable language known to man, and now you can’t modify a character!”

              1. 2

                Very good point about the pervasive “fear” of modifying code. I used to be afflicted by it too - I had the impression that reading the source code of a package would be akin to disassembling a binary. Eventually I ended up using a bunch of packages that were so sparsely documented I had no other choice but to read the source - and it turned out it was just like any other code.

                Sure, it’s always hard to navigate an unfamiliar code base, but far from intractable. If anything, a popular open source package is probably easier to get to grips with than whatever in-house codebase you’re currently working on since the shared stewardship incentivizes easy onboarding of new contributors.

                1. 3

                  Learning that I could read the source to Django or Go or whatever and understand it was definitely a level up moment. Many times reading the source is easier than finding the docs that explain what something is supposed to do.

                2. 2

                  Him, maybe another take on trying to put in words my vague thoughts: first of all, to reiterate, I honestly very much like the idea. It’s more that I’m trying to think how to make sure it doesn’t accidentally fall into some traps that history shows us can happen - thus, how to learn on the failures of others. As to modifying thirdparty code, your reply made me think about it a bit how I approach this - and, personally, I seem to be doing this sometimes and contributing code upstream. So I certainly see this is quite easy in Rust, where I can just tweak Cargo.toml, such that a particular dependency becomes loaded from a local clone of a git repo. I can then push it to my fork on github, and open PR upstream, with some hope of it maybe being merged, changing Cargo.toml again to use my fork in meantime. Interestingly, it was much more painful in Go for a long time, until recently got somewhat easier with go.mod file (though still somewhat less friendly than with cargo). I think that might be worthwhile to keep in mind, to make it easy to keep using the modified dependency, and also switch again to upstream if it manages to get merged - or keep using it if not (together with any other thirdparty libs that transitively depend on this tweaked dependency).

                  1. 1

                    That is really interesting. You’re right that newer tooling does seem better in this respect. npm loads modules within a project’s directory hierarchy, and now I learned something about Go as well. I think I have a tendency to dismiss what’s already out there with too broad a brush. I’ve been trying to work on that. For example, I’d like to spend some time with gokrazy. I think modern software’s dependency supply chains are insane, but cutting down from 5 languages to just one seems like a huge improvement.

                    I wish I could collaborate with someone else on stuff like this. I think I have a hard time learning new things, and that causes me to rationalize not learning about them.

                    (Apologies if my previous comment sounded like push-back. I did appreciate your kind words. I didn’t intend to sound disagreeable with anything you wrote.)

                    1. 2

                      No worries - I also basically just tried to reflexively double-down on making sure that my initial comment didn’t sound like push-back 😅 But still thanks a lot for caring - I always love and find it refreshing to encounter yet another fellow person dedicated to kindness <3

                      As to collaboration and cross-polination of ideas, I’d love to try helping with that, however I’m personally kinda already spread way too thin among various hobby projects; but for sure I always watch with great interest any posts you make here. Anyway, I think the way that you seem to already be sharing a lot of your progress and thoughts in the open, and especially in forums like this one, sound to me like decent ways to try and achieve some feedback and discussion. FWIW, this thread we had above helped me too with exploring a bit more some of my rather vague thoughts, an opportunity I find quite interesting and cherished.

                      So, please do keep up great work, and I keep wishing you good luck with it!