31 ms·

Theory-building and why employee churn is lethal to software companies

• eternalban 4y ago
  The Tacit Dimension, Michael Polanyi, 1966 https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html https://press.uchicago.edu/ucp/books/book/chicago/T/bo603536... Programming and Tacit Knowledge https://mbuffett.com/posts/all-tacit-knowledge/ https://mbuffett.com/posts/all-tacit-knowledge/ Tacit Knowledge blogpost series, Commoncog https://commoncog.com/the-tacit-knowledge-series/ https://commoncog.com/the-tacit-knowledge-series/ Acquiring and Sharing Tacit Knowledge in Software Development, 2013 https://www.researchgate.net/publication/264125152_Acquiring_and_Sharing_Tacit_Knowledge_in_Software_Development_Teams_An_Empirical_Study https://www.researchgate.net/publication/264125152_Acquiring...
  • bwestergard 4y ago
    I'm curious what you see as the connection between this article (which I think captures something very important) and the "tacit knowledge" concept (of which I'm very skeptical, having read Michael Polanyi's book and a bunch of the secondary literature).
    • thenobsta 4y ago
      I'm curious about the skepticism. Could you elaborate? The explanation of tacit knowledge hit me quite viscerally. I see a part of my engineering work as turning tacit knowledge into explicit knowledge.
    • eternalban 4y ago
      “ What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory.” wiki says: “ Tacit knowledge can be defined as skills, ideas and experiences that are possessed by people but are not codified and may not necessarily be easily expressed.[5] With tacit knowledge, people are not often aware of the knowledge they possess or how it can be valuable to others. Effective transfer of tacit knowledge generally requires extensive personal contact, regular interaction,[6] and trust. This kind of knowledge can only be revealed through practice in a particular context and transmitted through social networks.[7] To some extent it is "captured" when the knowledge holder joins a network or a community of practice.[6]” The distinction appears to be the implication of OP that the ‘theory’ is not communicable, thus “first generation” workers need to be around. But you can clarify (am interested in your views) (a) what’s your crit of TD and TK, and (b) the matter that I missed, the “something very important” (which is not TK transfer). p.s. “we know more than we can tell” is pretty much the tldr of T.D.
      • bwestergard 4y ago
        We can paraphrase "we know more than we can tell" in at least two ways: 1. "We know [the manner in which we carry out a task] more than we can tell [...but are unable to articulate the procedure by which we do it]." 2. "We [can do] more than we [can explain in writing or verbally]." The second statement is uncontroversial. No one would say that the ability to ride a bicycle logically entails the ability to explain how we do those things in writing such that, by reading alone, someone could learn to ride a bicycle. But this is only mysterious if you consider the second statement to be a paraphrase of the first. I don't think that it is. The first statement suggests a mystery; it's as if we are always following rules when we act skillfully, but are sometimes unable to articulate those rules. But this is a mistaken view. Not all skillful performance is rule-governed. In fact, most isn't (statement two). And that is easy to forget, but does not require a theory of "tacit knowledge". See also: https://plato.stanford.edu/entries/knowledge-how/ https://plato.stanford.edu/entries/knowledge-how/
        • eternalban 4y ago
          Possibly the issue is your conflating knowing with doing. The straightforward parsing of that sentence for me is: We are not capable of completely expressing our (personal) knowledge with language.
          • bwestergard 4y ago
            We are in agreement. Doing should not be conflated with knowing, as the "tacit knowledge" approach tends to.
            • eternalban 4y ago
              Good, we (the 3 of us) are in agreement. So what's your beef with brother Polayni?
• rpod 4y ago
  Seems related to the concept of conceptual integrity as stated by Fred Brooks: https://wiki.c2.com/?ConceptualIntegrity https://wiki.c2.com/?ConceptualIntegrity
• dang 4y ago
  Related to Naur's classic: Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=31500174 https://news.ycombinator.com/item?id=31500174 - May 2022 (4 comments) Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=30861573 https://news.ycombinator.com/item?id=30861573 - March 2022 (3 comments) Programming as Theory Building (1985) - https://news.ycombinator.com/item?id=23375193 https://news.ycombinator.com/item?id=23375193 - June 2020 (35 comments) Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=20736145 https://news.ycombinator.com/item?id=20736145 - Aug 2019 (11 comments) Peter Naur – Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=10833278 https://news.ycombinator.com/item?id=10833278 - Jan 2016 (15 comments) Naur’s “Programming as Theory Building” (2011) - https://news.ycombinator.com/item?id=7491661 https://news.ycombinator.com/item?id=7491661 - March 2014 (14 comments) Programming as Theory Building (by Naur of BNF) - https://news.ycombinator.com/item?id=121291 https://news.ycombinator.com/item?id=121291 - Feb 2008 (2 comments)
  • FeistySkink 4y ago
    Here's a more readable version I came across: https://gist.github.com/nwh/60eb3115754e68f2d1c46aa31961b660 https://gist.github.com/nwh/60eb3115754e68f2d1c46aa31961b660
  • Terretta 4y ago
    > Accepting program modifications demanded by changing external circumstances to be an essential part of programming, it is argued that the primary aim of programming is to have the programmers build a theory of the way the matters at hand may be supported by the execution of a program. Such a view leads to a notion of program life that depends on the continued support of the program by programmers having its theory. Agree with the theory of programming as theory*, but here's the problem with that essay in an era of software-as-a-services and platforms: A SaaS offering or an Enterprise runs on a stack or assembly of software, each of which has its own Theory. The problem with no churn is that most of the Theory is not in-house, it's elsewhere, and evolving. If you can't tap into that, you're falling behind. If you don't know it, you can't remix it into your own. It's just math to convert an org's "refresh rate" of outside-in knowledge (aka churn) into the average lag of that organization behind current best theory and patterns. A 10% churn means an average of 5 years out of date. A 20% churn means at least a fifth of your org is 5+ years out of date. A couple key antidotes, though (and there are of course more): Realize that knowledge transfer from (a) outside in, then (b) among, is vital to theory maintenance and evolution. That means (a) have a great "always be hiring" pipeline of fresh Theory and build processes to make knowledge sharing of outside and inside theory frictionless and routine, and (b) have a great "always be learning" approach to exposing developers not just to the internal theory but to the best and most up to date outside theory. The better an org is at (b), the less it needs (a). The worse it is at (b), the more it needs (a), but -- crucially -- it must refresh with candidates who know more recent theory than the ones doing the hiring! Churn is not bad, that word is spin. Internships are a thing, so are externships (firms should do more of this). People, and theories, grow by exposure to novel challenges. Circulation is good for the whole ecosystem of software development because we are building a collective Theory bigger than any one org. This remixing of ideas is how our collective Theory evolves. * Most recent decade of my career involved a lot of evangelizing to enterprise management that developers are not project teams to form and disband as fungible resources. Think in terms of capabilities to garden, not projects to remediate.
• sublinear 4y ago
  This is of course just my opinion, but I'm pretty sure what kills off a legacy project is whether the organization is committed to maintaining it rather than it being some kind of property of software itself. Minimizing churn is just one aspect of that commitment. If the project was always a mess it probably wasn't as important to the business as the developers believed.
• compiler-guy 4y ago
  I have seen half a dozen otherwise useful projects retired or criticized because "the original developers are all gone and no one understands it any more." The code worked, and continued to work, and didn't need really active development, so the org decided the project's programmers should move on to something new, or that the knowledge they have isn't especially valuable, and the programmers aren't worth keeping happy. And a couple of years later, no one knows how to update the code for a changing outside environment, updated input styles or whatever. And all that investment is gone.
  • ramesh31 4y ago
    It's not "gone", it served its purpose. Software is born, lives, and dies. By the time a project is 3-4 years old, unless it is a core central service, the business (if it is competing successfully) has most likely moved far beyond the initial assumptions laid out at its' creation.
    • compiler-guy 4y ago
      Don't know what kind of projects you are working on, but in the world where I work, source-code that is literally decades old is common, and companies pay extremely good money for people who understand it. This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.
    • tyre 4y ago
      If a business is competing successfully I don’t think you’re going to see software obviated every three years. Software isn’t like living beings that up and die. They evolve over time. Companies doing rewrites every three years have a hard ceiling.
    • marcosdumay 4y ago
      > it served its purpose That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live. All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.
• jonnycat 4y ago
  Of course, this often works the other way as well: a project is failing or stalled by the "wrong" theory being saturated through the team, and it can only be fixed by replacing individuals and developing new mental models of the problem.
• jimmyhmiller 4y ago
  This blog does pretty good job summarizing Naur's points. (My only quibble is equating mental models with theory in Naur's sense, but its an okay approximation). I definitely recommend people read the original paper. It's a flawed but beautiful paper. Shameless self plug: We just did an episode on Naur's Programming as Theory Building in the most recent episode of the Future of Coding Podcast. https://futureofcoding.org/episodes/061 https://futureofcoding.org/episodes/061
  • kasbah 4y ago
    I was going to post this! I really enjoyed this episode (and also, all the other episodes of your podcast).
  • fghfghfghfghfgh 4y ago
    Can you elaborate on why you think the paper is flawed please?
    • jimmyhmiller 4y ago
      I think all papers are flawed in their own way. So it is not meant as a slight. It is actually my favorite programming related paper. That said: I think Naur was just a bit to vague and assumed background knowledge of Gilbert Ryle where most people don't have any. I think a lot of people finish reading the paper and don't realize what Naur's notion of theory is or how his radical conclusions follow.
      • fghfghfghfghfgh 4y ago
        I don’t know Gilbert Ryle but I believe I understand the paper as intended. What do they realize then instead?
• raincom 4y ago
  The biggest problem is that software companies don't see "software development" as theory-building. Instead, they see "software development" as solutions to plumbing problems; that way, they can call a plumbing company at 1-800-CLEAN-ME whenever new problems emerge. Even not many people subscribe to Peter Naur's "Programming as theory building"[0] [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • commandlinefan 4y ago
    > they can call a plumbing company at 1-800-CLEAN-ME And, in fairness, that is a reasonable thing to want. The problem is it's not clear whether or not that's possible, and it is clear (but completely ignored by the people who ought to be aware of it) that our current software development methodologies don't even come close to allowing it.
    • deathanatos 4y ago
      > The problem is it's not clear whether or not that's possible It's not. Attempting to say it is is very akin to wanting a single, pre-created bridge to be able to span any valley. But valleys come in all shapes and sizes, and so too do the bridges required to span them. Certainly, there are some parts that are the same. I think most of us complain about cookie cutter CRUDs or byte shuffling, but even in all that, there's generally some higher purpose business reason as to why the software is doing the byte shuffling that I am, or more deeply, why the software is doing the byte shuffling the way it is[2]. And honestly, I think that oversimplifies it, when it comes to the problem and the software that attempts to solve it. The problem can and often does change in software … so it's akin to a valley that shapeshifts, adds new local laws of physics, and requires the bridge to change and adapt. How changes to the software mesh with the existing software, and why that might be — is unique to the project. (And, as Naur argues, contained only in the heads of the developers, and what is in their heads is not even necessarily the same.) [2] And to extend this with the shifting valley analogy, when new byte shufflings come along, would they benefit from this program's current design? If I need to extend the design, would a given extension work well? Are the requirements different enough that I need to consider something separate for this new requirement? etc.
• roomey 4y ago
  This happens even if I step away from my own code for a few months. The last program I built was coded around characters from Sherlock Holmes, by making the code like characters that had to interact in a certain way, it helped me maintain a mental model over a longer time. It genuinely made the code more enjoyable to work on, as it is a story now
• majormajor 4y ago
  > What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. Replace enough of the programmers, and their mental models become disconnected from the reality of the code, and the code dies. That dead code can only be replaced by new code that has been ‘grown’ by the current programmers. and > Team stability is vital for software development. Each team needs to be composed of a majority of first-generation developers. How does this interact with individual or career growth? I don't want to work for the manager who insists I stay on the first few projects I worked on at the company forever... To take this seriously, internal churn (even if just someone being promoted into management, or specializing on expertise in a small part of the original project, or switching projects when they get bored) is almost as costly as external churn. Five, ten years later how much is their domain knowledge still that relevant to the people working on the code day to day today? It could be harmful if they've been out of the loop and make outdated suggestions, even! Assuming and desiring your employees will stay in the exact same role indefinitely seems like a huge cause of churn.
  • ElevenLathe 4y ago
    I've worked in incident/crisis management for several big, complicated, grown-via-acquisition companies with a tangle of internal systems that were never quite fully integrated. When TSHTF and we need some expertise from the original builders or operators of a system, it's a lot nicer to have them on another team than at another company. If they still work for us, somebody can make the case to them (or their boss) that borrowing them for a few hours to fix it is in everyone's interest. A lot of times they are in some kind of management position now and they kind of smile and say "Wow, I haven't thought about that system in a long time. Sure, I can take a look." and it's even kind of a fun diversion from whatever budget meeting they were in. If they work for somebody else, the answer is often "sorry, I'm busy" or just a hangup when you explain who you are and why you are calling.
  • codazoda 4y ago
    I don’t wholesale agree with the writing but it does mention working with someone who worked on the project and can share the theory. In that case, a new dev is hired, and you instill all the knowledge of the system in the new dev. Once you’ve trained them enough, you can move on. New devs will adapt and create new theory and solutions. Rinse and repeat.
• scrubs 4y ago
  Totally agree - perhaps put more succinctly many rewrites are an attempt to independently rediscover the business requirements by reversing it out of code: "Team stability is vital for software development. Each team needs to be composed of a majority of first-generation developers. Too many second-generation developers and the first generation gets overwhelmed, and work stalls. The work slows down either because too many core tasks are waiting on the first generation or because the second generation keeps having to rewrite components from scratch because they didn’t understand the theory behind the original component. Too few second-generation developers and there is no renewal—each developer that leaves the team is a potential catastrophe. Many teams in the industry constantly rewrite parts of their code. Not because they keep figuring out better ways of approaching the problem but because nobody on the team has an accurate mental model for how it works and how the code fits in with the rest. If you can’t hold onto the original team, if you grow the team too quickly, you end up running to stay in place. Code keeps getting written without any improvements of substance to the software itself."
• codemac 4y ago
  This is the similar to the classic "design concept" from "the design of design." It is the idea that must be shared between the software developer's minds to increase velocity, not software itself. The pressure you face in communicating this theory is time to market. I am obsessed with cleanroom, zero defect software, and literate programming. However, I have only worked on one project that these tools would have been relevant for. All others, the code/system moved on faster than the time it would take to get it communicated. The real measure of programming languages to me then becomes raw productivity. If we could make programming literally a 10% or less task, and documenting and communicating the 90%+ task, I think software companies would do very well. This bodes well for things like ChatGPT/copilot.
• SilverBirch 4y ago
  I've got a little pet theory related to this. Which is that no one really solves difficult problems. They turn difficult problems into easy problems and then solve that. Often that literally means "We have this class of problems, I'm only going to solve the easy subset". And I've observed repeatedly people say "No we have to solve the real, hard, problem" - and a decade later, with a team of a hundred engineers, they've not really got anywhere. Applied to this, that theory is very simple. It's enormously difficult and expensive to keep old code running, especially when the engineers who originally wrote it have left. Not only is it difficult, but the engineers who have to do maintain it will hate it, churn themselves and you'll be back to square one. So, solve the easy problem. Get your new guys to write something new, and give up on the old software once all the people who knew how it worked quit. And it's easy! No one left at the company is going to argue to keep the code. The new people will enjoy writing something new. Oh and people will be amazed at how happy and productive your team is - because you literally just choose not to do things that are difficult and no one appreciates. But you may ask, what if the product is essential, you can't just abandon it. Well, call me flippant but if it were essential you shouldn't have let the engineers quit. And if you're really going to saddle me with it, I'll quit too. Then you still don't have your software, and it's not my problem - it's yours.
  • eddsh1994 4y ago
    If it’s essential it could last decades, greater than the career length of a developer. What happens then?
    • clhodapp 4y ago
      I guess you budget to rewrite it even though it's "working fine"
    • SilverBirch 4y ago
      Successful products are like the ship of theseus, they can go through the hands of thousands of engineers, the important part is having people actively working on it overlapping with more experience people. You don't literally expect the original author to be there forever, butyou do expect people to come onto the project and learn about it whilst the more experienced people are still there. If literally everyone working on a project is gone, the project is probably unmanageable at that point anyway, there's no point starting CPR, the project is dead.
• NordSteve 4y ago
  > What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. Replace enough of the programmers, and their mental models become disconnected from the reality of the code, and the code dies. That dead code can only be replaced by new code that has been ‘grown’ by the current programmers. While it's possible that there are systems out there that can't be understood, it's plainly false that - to paraphrase - code dies and must be replaced when the original developers are gone. A couple examples from my direct personal experience: 1. I work every day on code that's 20-30 years old, in use in production by hundreds of millions of people every day. There's no one around who worked on it originally. And yet it works, 100s of pull requests a day, and customers continue to pay us to use it. 2. I took on a volunteer project this fall, working on a ~million line distributed system that runs on clients at about 30 sites and integrates with 3 cloud services. No original developer is working on it. For the client code, it took me about a day to understand how it works and make meaningful changes.
  • compiler-guy 4y ago
    For both of these cases, the article author would say that the original developers have been replaced by newer developers who have acquired the theory. The solution to the problem, at least according to the article, isn't "no churn ever", but "low enough churn that the newer developers acquire an accurate mental model of the system."
  • marmetio 4y ago
    The author starts with the implicit assumption that the companies in the target audience will not be able to restart the metaphorical engine, which is why they recommend letting it idle. They tactfully don't call attention to the fact that not everyone has that problem.
• darth_avocado 4y ago
  Tell that to Elon or Bezos or the other geniuses of our lifetime
• passwordoops 4y ago
  We're having an issue of employee churn, and I think a lot of that is 20+ years of tech debt is catching up and new developments are becoming extremely difficult. I was just wondering if it would be good general practice to refractor piecemeal every couple of years. This would (in theory) reduce tech debt, and if the refactoring is done by relative newbies, you ensure the base is understood and stays fresh. I haven't hashed out or thought this through yet, so happy to have holes poked in this idea
• unity1001 4y ago
  Losing institutional knowledge kicks the org. in the proverbial balls. Even if stellar seniors come in to replace the ones who left, they still take 3-4 months to get up to speed on institutional knowledge, and they rarely can get all the knowledge that the ones who left had.
• yowlingcat 4y ago
  This is a poorly written article by someone clearly projecting their own individual experience (or more clearly, the lack thereof) onto a giant world of professional phenomena. It is trivially easy to think of a structural counterexample to their primary point, which is how experienced senior engineers can inherit production codebases without documentation or the original team that wrote it and are able to successfully operate, understand and improve the entire codebase. Is there a gradient of pain? Yes. Is it possible to inherit a codebase that is falling apart, without the resources to get the ship back on track due to organizational issues? Absolutely. However, it doesn't change the fact that every year, significant quantities of senior engineers do something that the author does not believe to be possible. This isn't to say employee churn is particularly health for software companies; it's often not. But that really varies on a case by case basis.
  • fud101 4y ago
    maybe but can an org afford to pay for those super seniors or is that not a valid option except for companies with deep pockets?
• deleted 4y ago
  [deleted]
• bentobean 4y ago
  > Documentation only works up to a point because it can both get out of sync with what the code is doing and because documenting the internals of a complex piece of software is a rare skill. A skill that most developers don’t possess. Most internal documentation only begins to make sense to a developer after they’ve developed an internal mental model of how it all hangs together. Most code documentation becomes useful after you have built the theory in your mind, not before. It operates as a mnemonic for what you already know, not as a tool for learning. This is ringing particularly true to me right now. The organization I work for has allowed bit rot to occur for a number of years, to the point that it's becoming increasingly common for things to break whenever even seemingly small changes are implemented. The "solution" that we've implemented is to require a detailed RFC document whenever you want to create or modify anything. You're required to outline every anticipated step along the way, all the tiny minutiae that you foresee yourself encountering and how you'll deal with it. And in a Google doc, no less. It's utterly exhausting.
  • tikiman163 4y ago
    I'm not a huge fan of writing a ton of documentation about the code. I am a huge fan of requiring developers to write in-line comments explaining what they're doing so the next person can build that internal model more easily. There should be some documentation about the system, but this is much more helpful if it only explains how to get the project running locally, including configuration settings and how to interact with it (if data has to be uploaded for a process, what should the data look like and how do you upload it). From there, a mid level developer should be able to locate the code entry points and follow the online comments to find what they need. Just because it seemed obvious what you were doing and how things worked while you were writing the code doesn't mean it is, or that it will stay that way. Especially if that code ends up getting abstracted out. In line comments demystify code for the next guy way better than any amount of well written documentation. As for what they're making you do with the RFC documents for changes, try writing your stuff as an ordered multi-tier list. The first tier should be the "manager" description of the change. The next level should be the more technical description of changes. The third tier is the location in the code where that change needs to be made (like a file path sort of thing, but you could use name spaces and even method names if you want). The forth and final tier if you need it would be cross references to other related items in the list and implementation notes/challenges specific to the file path. I've used this approach in the past myself. It's much faster, and it allows you to write a spec doc that isn't a huge waste of your time because it allows you to half write your code at the same time. It also provides a sort of semantic map from how the manager thinks about things to how you think about them, making it much easier for a manager to discuss it with you without having to write nearly as much. Another benefit to this is you can often use stuff from the second and forth tiers to add in line code comments.
• kens 4y ago
  > That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. Maybe it's because I've done so much reverse-engineering, but I reject that claim. It's quite possible to start with a binary ROM dump and build up the theory of the code. If you have source code that's even better. And the whole point of design documents is to explain the theory. Curiously, the book quoted at the top of the article gets this correct: "Revival of a program is the rebuilding of its theory by a new programmer team." But the article says that the only way to rebuild the theory is by writing new code.
  • unsui 4y ago
    Reverse-engineering is inherently an inductive process, whereby you have to make educated guesses as to what the model is, iteratively. Samba is a great example of how this is necessarily an imperfect model, and definitely not an optimal process: - https://news.ycombinator.com/item?id=488089 https://news.ycombinator.com/item?id=488089 Development as theory-building is intended as a metaphor to understand the impact of the collaborative mental model that is created as part of any complex system, and the losses incurred when this mechanism is not appreciated.
    • lll-o-lll 4y ago
      Having worked on reverse engineering complicated proprietary network protocols (but not for a long time), this is true to an extent. The “mental model” developed may not match the original authors in the exact way intended, but a working model can be constructed none the less. We were often able to make better models than the assumed original authors (at least the software that used said protocols was much more performant due to better packing algorithms), so I’m unconvinced that reverse engineering puts you in a worse state. Fully agree that the cost of reverse engineering is large, requires exceptionally skilled people, and no company should ever willingly put itself in the position where it becomes necessary for their own software.
  • lll-o-lll 4y ago
    Yes exactly. It’s reverse engineering. That doesn’t mean it will be easy, but once the reverse engineering is done you are back to where you were. Anecdote: Worked for a company that had a large software component (graphical design tool) that had been written in C with a very complicated object model/macro layer, file system format etc. Zero documentation, hadn’t been updated in a decade and not a single person remained who understood it or had done more than simple bug fixes. Couldn’t rewrite as customers had huge investments in assets built from the tool. One principal dev and maybe 1-2 months? And we had the theory of mind back, explained to everyone else and a new team of 5-6 devs working productively. Component was brought into the 21st century, and this time some documentation was written.
• deathanatos 4y ago
  If you haven't yet read it, go straight the source on this one and read Peter Naur's "Programming as Theory Building". The paper is excellent, and an easy read. It's linked to by TFA. The consequences of the logic contained within Naur's essay are far stronger than I think the article understands them to be.
  • DalekBaldwin 4y ago
    It's not exactly an easy read -- whenever I recommend it to someone I also warn them that it contains the most passive sentence in the history of the English language: "Information obtained by a member of group A about the compiler resulting from the further modification of it after about 10 years made it clear that at that later stage the original powerful structure was still visible, but made entirely ineffective by amorphous additions of many different kinds." But the content more than makes up for the style!
• cloogshicer 4y ago
  This is an excellent paper, it changed my view on programming. I've written a similar essay [1], summarizing the paper and providing some case studies as examples from real-life projects. [1] https://hiringengineersbook.com/post/autonomy/ https://hiringengineersbook.com/post/autonomy/
• PathOfEclipse 4y ago
  I've long felt that this is an issue unaddressed by the industry, though I've framed it as "knowledge acquisition and dissemination." As part of building a software product, the developers acquire deep knowledge of both the problem being solved and the system that solves it. The question then becomes: how do we efficiently capture and disseminate that knowledge? Capturing the knowledge is expensive both initially and over time as the software itself evolves. Disseminating it is expensive because it costs O(NM) time, where N is the number of people receiving the information and M is the average amount of time taken to absorb it. Dissemination is so costly, so we tend to do it in a "lazy" manner, meaning non-strict or as-needed. I think the best software systems I have worked on do a number of things: 1. They define enough ad-hoc proofs or invariants via unit tests. It's possible to work around these by simply disabling the tests, but, assuming your team hasn't devolved to that point, the tests are an excellent source of machine-readable and machine-executable knowledge. 2. The software is designed modularly so that one can operate on a part of the system without having to understand the entire system or worry that an unrelated part of the system is going to break. 3. The system is kept as simple as possible. The less knowledge one needs to accomplish the same task, the better! This is why KISS is so important. It's not for the person writing the code so much as the person debugging it a year later! As a corollary, a simple system tends to have less dependencies. Dependencies are actually costlier than people realize. Every dependency suffers its own bitrot problems and requires knowledge to handle them as part of maintenance.
  • mike_hearn 4y ago
    The lowest hanging fruit on any project is always documentation. Dissemination isn't O(NM) if your docs are well organized. At least, that's been my consistent experience over the years. I feel like our industry approaches documentation today the way it approached testing in the 1980s, before unit testing became widespread and culturally accepted/enforced. The problem is, just like how at the start you find lots of devs who don't want to write unit tests, you usually have a lot of devs who resist writing (and reading) docs. They'd rather interrupt someone to ask, or thrash around, or move onto the next task the moment some code is written. What helps: 1. Keep your docs alongside the source, in version control. This lets you gate code reviews/merges on docs being updated. Someone changed the way the code works but didn't update the docs? Then the PR is rejected until it's fixed. 2. Leading by example. If the TL for the project updates docs with their code changes, and visibly spends time gardening the docs, then they can't be accused of hypocrisy when they demand the same standards of others. Praise quality docs work when done by others. 3. Make the docs beautiful. Let people have pride in their work. It's so easy these days with great static site generators. 4. Answer questions by linking to the docs when possible, not ad hoc Slack/email/ticket discussions. If the docs don't tell someone the answer ask them to hold on for a moment, update the docs quickly and then link to them. Obviously this requires a fast / lightweight turnaround process on review and merge of docs changes, but it can be done. 5. Avoid wikis. Quality requires ownership, someone who is directly responsible and can enforce their will. Wikis don't let you do that so they become a commons, and you end up with a tragedy. Use Markdown or equivalent in a VCS repo so you can refactor docs as they expand, make sure there's someone (e.g. yourself or a trusted lieutenant) who is expected to spend time paying down docs debt every so often. 6. Docs bugs should be a thing. File them. Expect people to fix them. 7. Make it clear that people are expected to read the docs, not just write them. If someone is regularly asking colleagues questions that they could have answered by reading, ensure that's treated like other performance issues i.e. their managers know and the need for improvement is clear to them. There's more that can be done but these things do work. The biggest problem is always passive resistance. Just like with unit testing or code review, if a culture of avoiding it grows then you'll find it hard to introduce, people will passively resist because it's not as much fun as just banging out more code. With these approaches the robustness of a program to churn can be improved a lot, you can scale teams up quicker and productivity improves.
• cratermoon 4y ago
  Meir Lehman wrote [1] extensively about software lifecycles and evolution, and came up with what he called "laws". Most of them should be familiar to HN readers. To sum up as succinctly as I can: programs in use undergo continual change; as a program is changed, it becomes more complex; the quality of the system will degrade over time unless rigorously maintained. He also wrote that over time a software system, through dynamics of the programming process, the rate of change tends towards being statistically invariant. This is because, he said, the team involved in the system, including not just the developers, but also the users and others, have a finite ability to maintain understanding of the system, and excessive and too-rapid change outpace the ability of the people to maintain understanding. A Sixty North blog post[2] provides some interesting graphs showing the measured effects of Lehman's laws, including one showing that after 5 years, almost 2/3rds of the code is written by people who joined the team after the original team members left. 1 Metrics and Laws of Software Evolution - The Nineties View https://ieeexplore.ieee.org/document/637156 https://ieeexplore.ieee.org/document/637156 2 https://sixty-north.com/blog/predictive-models-of-development-teams-and-the-systems-they-build.html#id4 https://sixty-north.com/blog/predictive-models-of-developmen...
• holtkam2 4y ago
  Can someone help me understand why Twitter had not crumbled from the overwhelming weight of software decay after 50% of the staff was laid off? I’m not being sarcastic, it’s just honestly hard for me to understand…
  • AnimalMuppet 4y ago
    People leaving doesn't cause decay. Decay happens over time - usually not just in a month. People leaving means that there's nobody there who can fix the decay when it happens, though.
  • DethNinja 4y ago
    Did they ever disclose exact amount of engineers that were laid off? Twitter laid off lots of people but I doubt majority of them were engineers.
    • sgerenser 4y ago
      According to this: https://gizmodo.com/elon-musk-twitter-layoffs-engineering-spreadsheet-1849767712 https://gizmodo.com/elon-musk-twitter-layoffs-engineering-sp... the first round of layoffs was around 40% engineers.
  • JonChesterfield 4y ago
    Patience. It hasn't been long, and they probably left a test suite running under CI. Ideally it doesn't push to production without the tests passing and noone is left who knows how to disable it.
    • ranting-moth 4y ago
      I mean, this test is really annoying and it's testing a case that I'll guarantee 100% won't happen often in production.
  • bakuninsbart 4y ago
    There's a number of plausible scenarios: 1. It takes more time for the rot to show. 2. Twitter devs were amazing at building really solid software 3. The culture of twitter was really that 1 person did the work and 9 others watched, enough of the productive devs stayed. 4. The effects of rot are overestimated. I have no insight into how twitter worked as a company before Musk's takeover though, and I still think it is quite likely major problems will occur in the next couple of months.
• Guthur 4y ago
  After 200+ years of capitalism It's now deep rooted in our society that all work is a commodity, with human labour wholly fungible. This in and of itself pretty dreadful but I have been wondering recentl whether or not abstract thought is quite so. I'm not quite sure.
  • robocat 4y ago
    Capitalism doesn’t treat people as fungible, but instead according to a power law according to their capitalist value. Rare valuable skills tend to get paid highly, with professionals in the middle somewhere. The most common skills get paid near a minimum set by regulations, and also minimum wage is set by competition - see https://en.m.wikipedia.org/wiki/Baumol%27s_cost_disease https://en.m.wikipedia.org/wiki/Baumol%27s_cost_disease High level capitalists (such as VCs) treat rare people unfungibly e.g. Paul Graham “the success of a startup is almost always a function of its founders” or http://paulgraham.com/founders.html http://paulgraham.com/founders.html Edit: also fungibility is by no means a capitalist idea, and it is a central concept to some non-capitalist doctrines. What is equality?
    • Guthur 4y ago
      Paul Graham the capitalist is not Paul Graham the coder. One uses his time to produce something another uses his capital to buy others time. But also reducing to single entities misses the forest for the trees. Commodities and there exchange value is a social construct that naturally appears as we exchange goods and ultimately human labour time. The high skilled worker's cost is not just the time now but all the time spent to get to that level of expertise.
• dathinab 4y ago
  I have only limited experience but I think the worst thing you can do when taking over an startup (with the intention to continue it) is to start with firing people. I know it's expensive and not always viable but you should try to "let it operate like normally" while auditing it before starting firing people. Like some especially stupid examples: - firing the main tech lead which had worked month of unpaid overtime (not for month, but the accumulated equivalent of month of work) because he supposedly didn't work enough during the insolvency proceeding/first week after it. - cutting the cost of renting the storage system with essential data without making backups - firing most people which where important for the main product - firing people in such a bad way that most of the rest quit, too - deciding it's more important to keep marketing people then people from the development team in a situation where the insolvent company had multiple bigish contracts they just where missing a few month of work to be able to deliver to and interests from other customers and the buyer being the main potential customer buying the company to get the product
• smeagull 4y ago
  Honestly, I think all these layoffs hurt companies. Hiring is difficult and a slow process. Being unable to think of something profitable for devs to do inside your company is a sign that your management is being ineffective, or that ideas are being squashed inside your company. I'm skeptical that these companies were so bloated that they needed to lose large percentages of their headcount.
• avereveard 4y ago
  People joke about militaries writing docs about the exact number of turns each screw can take, but a-10 are still airworthy and the last one was built in the 80s Quips aside, software life expectancy matters, so total documentation approach is not something that works for everything. But if your software has generations of developers, maybe it's worth thinking about it. That or a total rewrite every skip generation. I can see both working, and maybe total rewrites are a better approach in a world of ever changing requirents. Thing is, documentation is great to capture static knowledge, and a evolving software is not static by any means If I had to pick and choose, I'd say written requirements with change management for every domain object APIs within the software object model, and anarchy underneath. The code conforms to the requirements, and not the documentation conforms to the code, so to say. Contract driven, in a way, but only where it's relevant.
  • mr_toad 4y ago
    > Thing is, documentation is great to capture static knowledge, and a evolving software is not static by any means There are many open source projects with great documentation and they manage to keep abreast of changes. This attitude among programmers that documentation is hard, so don’t bother is just that - attitude.
    • ikrenji 4y ago
      the documentation for something like angular or rxjs is about how to use the framework, the documentation doesn't explain the underlying code...
    • moffkalast 4y ago
      > and they manage to keep abreast of changes With varying degrees of success.
• gigatexal 4y ago
  Isn't it obvious? Senior or long-term employees that leave take with them tombs of process/folk-knowledge with them. They take the answers of "who do you talk to in what team to get x done?" and "how best do you navigate this team and their hot-headed manager to get what you need?" etc. etc. Documentation is helpful but the intangibles that come and accrue to just someone or someones who have been in the trenches for years and years can't be documented and when they leave it can be fatal at least for a team/unit. Add to that the onboarding cost and the cost of hiring: take in-house or (worse) external recruiters and their salaries/commissions, add to that senior engineers taking time to interview candidates and both prep for the interview (hopefully) and then write up detailed notes afterwards -- count not only their time doing this but their time NOT mentoring a junior engineer or working on something else during that day (yes this might sound like double counting but senior engineers really do make 1+1=3 so pulling them off something is extra costly imo), and then add the expense of the employee being hired, all their gear that they'll need, and then the 3-6 months until their productive and all the help/training they'll need to get to productivity AND THEN imagine all that and then person leaves after 6 months to a year: how much does that cost? now multiply that by your attrition rate... it gets hella costly.
• twawaaay 4y ago
  I specialise in joining teams with problems (inability to ship, reliability issues, performance issues, etc.) At least thrice I joined teams where all original developers and the manager was long gone. The situation for some reason looked very similar in all cases. The team is complaining about supposedly bad design that is preventing them from getting work done. But the system is also large and complex and they are unable to fix/rewrite it. Lo and behold, in two out of three cases I found that the original developers actually did pretty good job designing the system but in all cases any one of new developers understands only small part of the design and is unable to contribute changes across the entire system, there is a core of the system that nobody understands even though everybody uses and the team has made changes that are against original ideas of the system quickly creating more problems and exploding complexity. In all cases developers are only able to comfortably do some kinds of changes to the system that are routinely done (like adding new fields to forms, messages, etc.) that do not change how the system functions. Changing the basic structure of the system is a taboo. In essence, developers treat "legacy" code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals understood. (I will never understand this approach to development) Making "non-standard" changes (yes, one team used this exact term!) pretty much always ends up with something resembling long archeological expedition with ancient traps, diseases and wild animals.
  • pistolpete333 4y ago
    As an anecdote to how developers treat "legacy" code: As a fresh developer out of college I had the mindset that frameworks were something you use and they always work and all you need is the documentation. My first job had a lot of "core" code written by another team in another office we would use with exactly 0 documentation. I was trying to get our UI to do something specific but couldn't figure out how to do it by just looking at the functions available, so I ask my manager and he immediately knows what to do, makes 2 small changes (in my defense it was pretty hacky how it was set up imo) and I get what I want. I remember being moderately pissed because I was already feeling the heat of asking my manager too many simple questions and I just apparently asked another one, so I say something along the lines of "How the hell would I ever have known how to do that, there are no docs available to say that is possible and that is not obvious at all." He just looks at me and says "You read the core code" and I remember having my mind blown at missing something so obvious for so long. After that I voraciously read almost all "framework" code I could get my hands on, I asked more intelligent questions and my relationship improved my manager and eventually came to be considered a generally good developer. Once I had this breakthrough I was seeing it in younger developers all the time, and now any time someone asks for general advice on becoming a better developer one of the things I say is "read a lot of code", and more specifically "read the code in your frameworks"
• tdumitrescu 4y ago
  "Many teams in the industry constantly rewrite parts of their code. Not because they keep figuring out better ways of approaching the problem but because nobody on the team has an accurate mental model for how it works and how the code fits in with the rest." This part rings very true, as someone who's been through plenty of rewrites / "make module X not suck" projects. A side observation here is that usually the original author (sometimes long-departed or departing) understands very well the limitations/flaws of the original system/implementation, but can be excluded from the design of the replacement for any number of misguided reasons. Trying not to bruise the ego of an early employee, thinking that they wouldn't agree with any changes, whereas those are often the people in the best position to guide a rewrite, and often would love the chance to fix some of the decisions they had to make originally.
  • robertlagrant 4y ago
    I agree. I would add that sometimes the existing team only want to make incremental changes to their existing software, rather than make something new, and that can make team dynamics... complicated!
  • layer8 4y ago
    This is very true. On multiple occasions, after taking over ownership of code for which the original author wasn’t available anymore, I ended up rewriting it bit by bit, according to my progress in understanding it. In some ways, rewriting a piece of software is the best way to understand it deeply, and/or to uncover the gaps in one’s understanding.
    • cudgy 4y ago
      > In some ways, rewriting a piece of software is the best way to understand it deeply, and/or to uncover the gaps in one’s understanding. Fine, so long as your rewrite is not checked in. Otherwise, this approach will surely lead to chaos when prior developers who figured it out now have to re-learn your version, resulting in the exact problem this article is addressing.
      • 4y ago
• jononomo 4y ago
  When I first decided to get into web development after taking a couple of years off from software (after doing Java development in the finance world) I started with Ruby on Rails because it was hot at the time. I spent several weeks going through about three books on Ruby on Rails and working endlessly on tutorials, etc. But I got nowhere and I couldn't stand it. Then one day I read the Django documentation and it took a completely different approach. The approach that the Django documentation took just made sense. It began by explaining what the problem was from a high level and then explaining different solutions that had been tried over the years and what their drawbacks were and how this led to further approaches, and so on. By walking me through the system that way it made Django clear and sensible to me. All the Rails stuff I had been reading seemed to assume that I already knew everything but just needed to understand some magic incantation. Django treated me like a child, which meant that it actually treated me like an intelligent adult. I'll never forget the experience of reading that Django documentation. It was crystal clear and it changed my life. This all happened around 2012.
• coffeemug 4y ago
  What is the bear case for this essay? It's notable that almost all large organizations operate in a diametrically opposed way, yet we have thousands of successful incredibly complex software systems. To me the essay feels intuitively true, but I'm not sure how to reconcile it with this empirical fact.
• giantg2 4y ago
  My company actively promotes rotating to different areas of the company every 18 months. I think it's terrible for continuity as well as skills development.
  • ranting-moth 4y ago
    It's good to know how different areas of the company, but that's taking it to the extreme!
• bvirb 4y ago
  We're working on a project that was inherited from previous engineers with no crossover. The first thing we did was write an end-to-end integration test suite for all the features we could find, which has grown more comprehensive over time. We still have old code we know is working alongside newer code written in a completely different style. We've been able to make major changes in tools and conventions over time while keeping progress steady. While we'd love to clean up all the code and have a single set of the latest conventions the decision is always refactor it now or maybe punt and we'll get to just delete it later, we usually go for the latter. I think the biggest benefit has been that the tests are isolated from the implementation details so we can always be sure everything is still working without having to refactor the tests themselves. There is still a learning curve for new people because they don't know which of the multiple conventions in the code are the presently-agreed-upon ones, and that is where we could probably use some better documentation, but I think the end-to-end tests really saved us from the idea that some knowledge is lost and we might need to start over.
  • yashap 4y ago
    Yeah, zero doubt investing in robust, automated E2E tests in that situation is key. I’d also add: - Get the “change engine” running smoothly (productive and reliable local dev environment, reasonably fast/reliable build/deploy jobs) - Get people understanding, documenting, and teaching others the high level functionality and architecture If you skip those steps, and hop straight to new features, you’re just asking for regressions, outages, poor architecture/design decisions, and just a very slow pace of work. But invest in those 3 up front and you can get to a point where you’re evolving the product well, with few regressions, at a good pace, even without vets to teach the newbies.
• ShredKazoo 4y ago
  This all makes sense to me, but how do you reconcile it with the fact that job tenure in Silicon Valley tends to be so short? (Like, people hopping jobs every few years?) * If churn is lethal, shouldn't we expect the center of the software industry to be in a city where people take a more conservative approach to their careers, sticking with a single employer for 10+ years? * If churn is lethal, wouldn't we expect a stronger focus on retention of software engineers? Instead, it's common to offer new hires generous packages, and common wisdom is that constant job hopping is the path to high compensation.
  • xwolfi 4y ago
    There's the theory and there's reality: resources being limited and a finite employee can run things at any time, companies have to compete for their survival by hiring high while killing their competitors.
  • sublinear 4y ago
    The most valuable software tends to be written by people who commit to their work. The frequency of job hopping is inversely proportional to the time spent working on a career. Gaming the system for a large salary early on without much experience only hurts the employee with burnout and getting replaced with better developed talent more deserving of the role.
• ostenning 4y ago
  This is why I would recommend for low barrier of entry software, like web development, to only ever use the most opinionated frameworks available, but this isn’t desired from a hiring perspective because of web tech hype. Hell, I would recommend Java over nodejs for this reason. All jokes aside, time and time again have I seen web projects erode away with 1000s of employees taking a quick hack or asking for large refactors and then leaving soon after.
• osigurdson 4y ago
  I don't disagree, but which companies have died largely/entirely due to churn? Running out of money, getting outcompeted, etc. will all lead to churn but it seems that churn itself is more of a lagging indicator.
• etempleton 4y ago
  Employee churn has a very real cost and many executives are still struggling to understand this. I think many have just never seen it before or are in denial, but it guts an organization. I have seen teams and divisions that operated like clock work suddenly descend into chaos after 25 percent of the team left for higher pay. Once that happens it is over. Everyone leaves because work becomes terrible for everyone left.
• m3047 4y ago
  A myth, a plan, a canal. I worked for a period in a consumer product OT shop. I was a consultant; not a 2nd gen. It's not often you discover you have access to a quarter $mil of OT equipment just lyin' around as hot spares sitting in a lab down the hall; and it all talked to the hot spare L2 which we used for development. Technically, I was working on the L2 system. But I needed to write test plans. When I showed up, they showed me "the wall" which was three ring binders (1/2 to 1 inch thick?) of "test plans". Each binder was a test plan. Yes. Over the better part of a month I assembled enough stuff in the lab to run product "end to end" in the best environment we could simulate. So, after meetings, I was able to write a test plan which referred to an SOP for some portion of its setup and then deviated (a "variance") for the actual test. Tests took longer to execute, but a hell of a lot less time to write. To set this up, I interviewed the actual line personnel. By the time my tour was done I had to schedule time in the lab because they were using it for training and general "what if" screwing around.
  • liquidgecka 4y ago
    When Twitter was still in managed hosting and basically out of space to put new equipment we started an emergency "build a datacenter" project of which I was initially one of the only FTE's allocated too it. My plan was simple: I don't have bodies to throw at problems (we didn't even have data center techs and our facility was still under construction) so my plan was to make something that could effectively "self deploy" a functioning data center for us. I locked myself in a really hot closet behind the cafeteria with several pieces of our soon to be purchased hardware and started coding. The whole thing ended up amazing and I am still proud of it to this day. =) Some of my primary goals where simple: No manually edited configs, ever. If you swap a mother board there should be no mac address tracking, no serial number editing, etc. If we can detect it automatically we did and updated the machine database automatically. Hardware techs could simply walk out, swap a drive, and walk away and we would track that. So we wrote a tool called vex that would export all the machines various bits and bobs. Anything we could access, serial numbers, mac addresses, etc. So once the machine was running we knew where it was, what it was doing, etc. The biggest challenge was getting it running in the first place. The plan was to use DHCP option 82 which includes port information when forwarding DHCP requests to an upstream server. Thus our dhcp server (written by an awesome coworker in like two days) was 100% stateless. It knew the IP range for the datacenter, the ip range for the rack, and the port that the request came from and could respond with a static IP every time. Swap the mother board and it wouldn't matter because the machine would still be plugged into the same port on the switch. Each machine would then request a tftp boot image from the server listed in the dhcp reply. This server was smart, it would look in the machine database to see what state the machine was in and where it needed to go "next" so to speak. Step 1) Machine has never booted before. It would go into an identify utility that would allow the installer to verify that each machine was plugged into the right ports. The tech could watch the ipmi identify lights on the machine as it activated each in the rack in order and if any where out of order network cables needed fixed. From this point forward we knew that port 3 was the 3rd machine in the rack on the prod and ipmi networks. Once identified the machine would automatically reboot. Step 2) The machine would run memtest86 to ensure that memory was valid. Sadly I didn't have time to make it automatically update with results and reboot so this step required manual verification when I left. A engineer would check IPMI and mark the test successful. Step 3) The machine would run stressapptest to push the CPU and memory to the extreme. This allowed us to ensure that they would not overheat and that the rack could pull the load needed to get all the machines to 100%. Once done it would mark itself successful and reboot. Step 4) The machine would run fio to ensure that every attached disk was in good state and fully functional. Again, it would then reboot automatically. Step 5) The machine would install our default operating system assigning hostnames and such via parameters from the database. Lastly once the machine booted into its "real os" for the first time it would setup puppet, install all the back packages, look into the machine database for its assignment and then install all the various bits ad bobs required for it to do its selected function (hadoop, web server, dhcp server, puppet server, etc) Everything was driven by the machine database, and you could mark a machine as needing burn in and it would repeat the testing steps. Super useful if you suspect a machine is bad in some way but don't have time to debug. Once running vex would export all the details of the machine as well so we could track failure rates, hardware events, etc. Best part is that the lab ran the same software as the datacenter so we could always test the various bits of this process to see what worked and what didn't. In fact I added several optional steps to do things like get performance profiles and build all kinds of cool graphs from tests on demo hardware. I ended up bootstrapping three datacenters and all it required was an "Ark" which was just a single server with puppet, dhcp, tftp and audubon on it ready to setup all the other servers in the facility. During our initial power up we had a DHCP server doing something like 100-500 requests per second sustained over the course of like a half an hour (until the memory tests started) Sorry, not sure why that memory jumped out at me but it seems you did something alike and it reminded me of how much fun it was to be involved in mine. =)
• beebmam 4y ago
  In my opinion, every piece of software should be entirely rewritten every 5 or so years, taking into account the previous iterations mistakes and successes.
• cwalv 4y ago
  > What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. That's the easiest way to learn it, but it's not the only way. After a while, it even becomes fun to read through other projects (some of your dependencies, e.g.) to see how easy it is to develop this 'theory' (even if it is fleeting; in the case of dependencies, you'll at least keep a rough idea of the cost of that dependency, relative to it's value)
• whatever1 4y ago
  The incentives are broken for software engineering companies. Most of them are operated with a startup mentality, aka we will be around for 18 more months so let’s optimize for that. All of the employee benefits are incentivizing them to stick for the short term and then move to other pastures. Or you know they could instead offer high 401k, pensions, career options for people over 55y.o. etc. But it is always easier to burn though fresh grad meat, and let the dumpster fire for someone else to deal with.
• black_13 4y ago
  [dead]
• faangiq 4y ago
  It really doesn’t matter and it’s definitely not lethal.
• janandonly 4y ago
  This is why the UNIX way, where every program does only one thing and does it well, is so powerful. You don't need to know how it works to use it. And if it really needs changing you can make a new executable with a new version number in its name. That way legacy code can continue to call on the old still functioning version while other peaces of code call on the new version.