29 ms·

Uncomfortable Truths in Software Engineering

• MisterTea 5y ago
  9 is a repeat of 5.
• SamoyedFurFluff 5y ago
  I think point 13 misses a nuance- technology has arguably already killed people (see: genocide and Facebook). But I would like to specify that it has to kill people that other folks deem important enough to prevent the further deaths of.
• rchaves 5y ago
  I really like this list, they all resonate with my own experience, I’ve been in both sides of many items (zealot became cynical)
• mojuba 5y ago
  No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibility, accessibility, security, and privacy" and making the lives of engineers (and users) miserable.
  • zerocount 5y ago
    It's not capitalism, but the bad apples exploiting it.
    • beaconstudios 5y ago
      if it's a near-universal problem, it's not "bad apples" it's bad incentives. IE, capitalism.
    • deleted 5y ago
      [deleted]
    • hotstickyballs 5y ago
      Bad environments make bad apples.
    • el_ravager 5y ago
      The exploitation is a feature of capitalism, not a bug.
    • mojuba 5y ago
      I'd like to see examples of well known good apples outside of OSS that care about performance, compatibility, accessibility, security, and privacy.
      • bluGill 5y ago
        Even in OSS caring about performance, compatibility, security and privacy is the exception. The biggest projects do tend to care, but the majority don't. The biggest examples in OSS are mostly funded by capitalism to care ab out those things.
      • db48x 5y ago
        Although they have many faults, Microsoft has cared about compatibility for 30 years (you can still run DOS programs on your Windows 10 computer). They have cared about the security of their users since about 1999, and they cared about their user’s privacy for about 10 years before dropping it in favor of advertising revenue a few years ago. People still install Windows on new their computers, so it evidentially isn’t a big concern for most people either. Their support for accessibility technologies is probably better than most operating systems, though it’s a bit hard to tell from the outside. Performance is an odd one. It is my understanding that the Windows kernel gets high marks for performance, but aside from that almost nothing does.
    • delecti 5y ago
      Capitalism is a handful of people who own the means of production and the rest of us trying to get by. The bad apples exploiting it are the people who own the means of production, and saying they're the bad part of capitalism might as well be saying "capitalism is only bad because of what makes capitalism what it is".
      • adwn 5y ago
        > Capitalism is a handful of people who own the means of production and the rest of us trying to get by. Well, good thing then that the "means of production" for software development consist of a 500€ laptop, which is well within reach of just about every programmer in the Western world.
        • simion314 5y ago
          >Well, good thing then that the "means of production" for software development consist of a 500€ laptop, which is well within reach of just about every programmer in the Western world. Sure, now tell me your opinion on this idea I have Today for music there are many parasites that suck the profits and creators barely get something. So my idea is to make a cooperatives (or non-parasitic company) to help the creators of content. First step is to have mobile apps and here we just HIT the parasites, Apple and Google , any transaction or subscription will be taxed by7 this parasites. It seems impossible to make money for the right people without fating up the parasites.
          • merpnderp 5y ago
            When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care.
            • simion314 5y ago
              >When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care. My issue is with "free markets" solve everything when most of the time you don't have free markets(like when you have too few competitors or when you have collusion not to compete ) , or when you forget to specify that free market would solve the problem but only after you make illegal all the bad or evil practices companies will abuse. If someone is an economist is there a theorem /law that proves that imperfect free market will covere to an evil state so you always need supervision to intervene when you notice the effects and apply a correction/bug fix ? In my example with mobile applications we don't have free markets , where free market would mean you have many agents competing to offer you something, we have basically 2 competitors and this 2 are happy to be in a balance and share this big pie then aggressively competing to make happy the custoemrs but reduce their profits.
    • CuriouslyC 5y ago
      It's not the fault of a system that rewards unethical behavior by having a massively skewed risk/reward profile for said behavior, it's the fault of people with low-normal levels of empathy who make rational decisions. Sure.
      • jjoonathan 5y ago
        "The system harnesses the power of incentives to make people do the right thing!" "But here the incentives point in the wrong direction." "It's not the system's fault! People shouldn't follow those incentives!"
      • merpnderp 5y ago
        That same line of argument could work for socialism/communism. What country that doesn't use the free trade paradigm for their economy isn't some authoritarian nightmare of poverty and despair? Are they just bad actors using the system wrong, or is it a system that always ends that way?
        • lupire 5y ago
          If every system ends up the same way, it's probably the people not the systems.
        • mojuba 5y ago
          Not always the case. There are non-democratic capitalist societies with varying degrees of performance, from great (Singapore) to awful (the entire post-Soviet space). On the other hand, over-regulated or fully socialist societies seem to be incompatible with democracy, I'd agree with that one.
        • CuriouslyC 5y ago
          Corruption isn't a problem of free trade, it's a problem resulting from centralization of authority. A single (or small cabal of) regulatory gatekeeper is comparatively cheap to pay off compared to satisfying all interested parties. Bribe one person? Check. Bribe 10,000 without having it break the bank or turn into a PR nightmare? Not so much. Clearly, our "free market" isn't really free, and our regulatory and enforcement strategies are the problem.
    • HeckFeck 5y ago
      It is a bit naïve to just blame the free market for everything wrong in the world. When I read complaints like that I wonder what "alternative" the author has in mind. Capitalism in this sense also gave us much of the software and hardware that is praised on HN. It is more accurate and useful to discuss which motivations, cultural shifts, or even psycological traits that have caused the decline in software quality and freedom. These are more practical than proposing mass economic realignment.
      • mojuba 5y ago
        It's not about the free market per se, but rather a system that allows to turn the information asymmetry into money without consequences most of the time.
    • CharlesW 5y ago
      From a capitalistic POV, it's irresponsible not to exploit ("make full use of and derive benefit from") underlying economic systems, no? This is why a purely capitalist, free market economy would be a societal disaster.
  • xwdv 5y ago
    Software is not charity. I will not work hard to deliver all those things out of the goodness of my heart. The ROI on those things isn’t great. If it’s easy to do I’ll do it, but none of those are trivial things.
    • XorNot 5y ago
      I'll go further: I would love nothing more then some well-defined common standards to work towards. Weighty documents I can drop on product manager's desk and tell them the ways in which our customers and the government will legally have their way with them if we don't meet those requirements.
      • bob1029 5y ago
        This is why I like working in highly-regulated industry. Technically correct is almost always what flies at the end of the day, because there certainly exists some audit item tracking the thing. I absolutely loathe the audit process on one hand, but its a useful tool for getting everyone to play the same game on the other. It also means your solution is compliant in a lot of places if you can get it signed off in one.
    • mojuba 5y ago
      Software is not charity but it's a responsibility. As probably the most innocent example, when you ship an app that drains a user's battery you betray your users. But then how about an app that sneakily collects data knowing that users won't even understand what you are doing or why? You can be a responsible business which unfortunately won't necessarily be appreciated. Or you can be a typical business that exploits information asymmetry to the last bit.
      • merpnderp 5y ago
        If you don't like our current system that lets users decide what they can put up with or not then are you proposing some sort of centralized authority to enforce this? Like the government? The same governments of the world that produce the crappiest, most insecure, user hating software with some of the most ridiculous rules and regulations or else 10 layers of subcontractors making the price per line of code outrageous?
  • StevePerkins 5y ago
    I'm honestly starting to feel like I transported back in time to my 1980's small town childhood, when the adults around me all blamed "Satan" for everything in the world they didn't like. "Capitalism" has about as much to do with software performance as actual devil worship had to do with my Dungeons & Dragons or heavy metal cassettes. And if your life as an engineer or user is "miserable" today, then I wish I could transport YOU to the 1980's. Yeah, existence is suffering... it sucks to be in the top 5% of household incomes, be inundated with open source platforms and tools that didn't exist too long ago, and a have a supercomputer in my jeans pocket.
    • AnIdiotOnTheNet 5y ago
      What sucks is having a supercomputer in your jeans' pocket that is significantly less responsive to your input than a Commodore 64 and is mostly used to deliver ads to you.
      • StevePerkins 5y ago
        I realize that this will get some reflexive upvotes from the meme crowd. But neither of those statements are remotely true.
        • AnIdiotOnTheNet 5y ago
          I frequently have to pause while typing and wait for my pocket-supercomputer to catch up and actually give me feedback like putting text on the damn screen. Multi-second non-interactable pauses are not uncommon at all. If that isn't "unresponsive" I'd really like to know what is. The ad thing I admit might be a touch hyperbolic.
          • StevePerkins 5y ago
            I have never experienced input lag on a iPhone, other than perhaps a context where the input is traversing across an Internet connection. And I assure you that a C64 with a 300 baud modem had that issue, too.
  • snth 5y ago
    Counterpoint: life in communist countries is not known for being "not miserable".
    • mojuba 5y ago
      That's the most irrelevant counterpoint that can be made here. "Communist" states were also totalitarian, i.e. undemocratic and that was the main reason for their ultimate failure. With democracy they'd be able to self-correct and likely switch to free[er] markets for example. Consumer software and Internet are probably the least regulated areas of engineering today, that's the problem. Compare that to aerospace, construction, etc. Regulation though is not part of the free market capitalism paradigm, it's the prerogative of democracy.
      • willcipriano 5y ago
        > Regulation though is not part of the free market capitalism paradigm Who told you that? People like to simplify views and say that people are "anti-regulation", but really people are anti-poorly-thought-out-regulation. What famous capitalist do you know that argued theft for example should be unregulated?
        • mojuba 5y ago
          Show me a corporation that would whole heartedly support regulation of the market they're in.
          • willcipriano 5y ago
            Facebook[0]. Regulation could make it more difficult for competitors to get off the ground so they are in support of regulation to that effect. [0]https://about.facebook.com/regulations/ https://about.facebook.com/regulations/
            • mojuba 5y ago
              You bring one of the most hypocritical pages on the Internet as an example?
  • Chris2048 5y ago
    The problem with blaming capitalism, is that these things are by no means unique to capitalism. People are as self-serving in communistic "utopias" as in capitalist ones. Plus many economies are a mix of both capitalist/socialist elements - people cherry-pick things they like/dislike according to what they want to prove; but the US is by no mean more/less "capitalistic" than any other nation. Some capitalistic value could just as well be described as conservative. Fostering co-operative communities has less to do with the political/control system, and more to do with how it is implemented - and the mindset of the population. I could just as well blame multi-culturalism, or globalism, or lack of religion, or metropolitan lifestyle on lack of social cohesion.
  • nonameiguess 5y ago
    Every response seems to have missed the joke by not reading the actual article. No. 12 makes fun of "blame capitalism" and this comment is riffing on that.
• lexapro 5y ago
  >The open source maintainer problem isn’t going to get much better in the near future. >People are gonna keep blaming “Capitalism” for this. Capitalism is great, there really is no need to defend it at every opportunity, especially if no one is attacking it.
  • beaconstudios 5y ago
    great is a relative term. It's much better than feudalism, and certainly better than the most prominent socialisms that've been tried (USSR, China etc). However, it does not align incentives towards the things we think are "good", like maintaining open source software, securing software, etc - so it certainly isn't ideal.
    • ericmay 5y ago
      Yea I mean nothing is perfect. While capitalism doesn’t lend well to maintaining open source software (which I find to be a surprising comment given that GitHub exists) it does lend well to things like having a house, or being able to save money for retirement, or to creating markets where you get products you want. YC for example has enabled lots of founders to create brand new companies and services we all use. So I would definitely take the bad with the good here. The world’s most capitalist countries also have the highest standards of living (Norway, Sweden, etc.).
      • beaconstudios 5y ago
        > While capitalism doesn’t lend well to maintaining open source software (which I find to be a surprising comment given that GitHub exists) Github doesn't maintain the open source software they host. > it does lend well to things like having a house Capitalism isn't the originating point of houses though. However, it is the originating point of mortgages, and the massive profits banks draw off of them. I'd say it's a double-edged sword on that front. > The world’s most capitalist countries also have the highest standards of living (Norway, Sweden, etc.). Those countries are social democracies - they invest a lot into welfare and the state. The US is probably the world's most capitalist country, that or South Korea. Both have terrible standards of living for poorer people. Fundamentally, the incentives of capital drive towards maximising profits and minimising costs - everything else is surplus to requirements. I'm not on board with the people who think capitalism is the worst thing ever, but its incentives are pretty bad and it's usually better off mixed with taxes, regulation, nationalisation etc into a mixed economy.
• varjag 5y ago
  There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive. Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will always claim success.
  • StevePerkins 5y ago
    Number one, static type checking is hardly a "new tech" for which the industry is in a "newlywed period". If anything, it is the middle-aged wife that the industry's crawling back to, as the passion fades from its dynamic mistress dalliance. Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we've PROBABLY gone too far and are unfair now). When hype waves don't work out, this industry is pretty quick about discarding them.
    • varjag 5y ago
      You are right there is hardly a tech that hasn't existed in some form or shape since 1970s. Doesn't change my point (and nobody said newlyweds have to be on their first marriage).
    • the_gastropod 5y ago
      I think the trend is more of a pendulum swinging back and forth than a single cycle of "static" => "dynamic" => "oh, dynamic was bad, so static" explanation. Prolog, Smalltalk, Lisp, etc. are likely older than most of the engineers now very enthusiastic about static typing. Static typing is fashionable right now, I suspect, because it's the first time many engineers are stumbling upon it via Typescript, Sorbet, Haskell (or Haskell-derived projects like Elm). I predict eventually the costs (and let's be honest: static typing is not free) are realized, there will be a re-emergence of dynamic typing being fashionable again in the next 10 years.
      • 5y ago
• akavel 5y ago
  Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort, or just completely crap. Ideally I'd then (gradually) enable (or, "un-disable") statical typing, error handling enforcement, and formal proving. Question is, can anyone design & implement a language that would have all of that, and still be readable and understandable to a common programmer (like me). Re. 6: for API design, I have some (feeble) hopes behind https://aip.dev https://aip.dev; as to the rest, I have immense hopes behind https://enso.org https://enso.org
  • Chris2048 5y ago
    The problem isn't best case scenario, but possibility of abuse. gradual typing is an easy way to acquire more tech debt once tickets are closed and no-one comes back to add more types. Corps like a simple plan->code->test->done without any "return" to code considered "done".
  • Chris2048 5y ago
    Is that enso software related to the software launcher by Aza Raskin?
    • akavel 5y ago
      Noo, I don't think so, from googling what you describe it seems just a clash of names.
  • musingsole 5y ago
    > Question is, can anyone design & implement a language that would have all of that, and still be readable and understandable to a common programmer No, because exception handling and the answer to "what type are these data?" are product questions. Hard questions that no one really wants to work out because what if our customer base wants something completely different in 6 months? This is largely reflected in cloud providers being unwilling/unable to provide account spend caps: what is a sane response once the budget goes over? AWS can't tell you; only you can define it. (This isn't to say "there's nothing AWS can do for you here" -- they could but won't for other reasons). Python is the largest, common language that can support gradual checking systems being added in over time, and mypy has outlined a great framework for doing just that. But it's not a silver bullet and can't be because the problems are cultural, not mathematic. Either spend the time working out what you want your software to do, or don't. But don't argue "strictness" is "correctness".
• mrfusion 5y ago
  I’d never heard of mobbing. That’s an awesome idea.
  • throw1234651234 5y ago
    I am yet to see pairing work effectively for more than 20-30 minutes at a time, on a very specific problem, that really needs shared expertise. "Mobbing" sounds horrible 99% of the time.
  • benji-york 5y ago
    I've done it a bit in a professional environment and it worked well. I wouldn't want to do it 100% of the time, but it has its uses.
  • dagw 5y ago
    "Mobbing" means "bullying" in Swedish, which initially confused me greatly.
    • afarrell 5y ago
      “Ensemble programming” is a slightly better name for it.
    • lexicality 5y ago
      It's not really a positive term in English either, I think the name's supposed to be a joke
      • scollet 5y ago
        I didn't know it had a negative connotation.
  • edoceo 5y ago
    My team calls it Swarming. We Swarm up on a problem like a bunch of hornets, together we hammer that shit from many angles, heavyweight team and then boom, it's done. I think I got it from TPS
• teddyh 5y ago
  #10 also applies to religion.
• Olreich 5y ago
  > 10. TDD/FP/Agile zealots are probably zealots because adopting TDD/FP/Agile/Whatever made them better programmers than they were before. Being a Zealot also stunts your growth beyond the level that zealotry got you to in the first place.
• teddyh 5y ago
  > 6. We don’t have the Alan Kay / Free Software / Hypercard dream of everybody having control over their own computer because integrating with disparate APIs is really fucking hard and takes a lot of work to do. This will never get better, because API design is decentralized and everybody is going to make different decisions with their APIs. No, it’s because it’s the incentive of most every developer involved to make it harder for the user to have control over their own computer. Even though it might make a net win, a proprietary software developer wants to not have competition. Also, they lobby for copyright and DMCA, etc. to further lock in their assumed place in the hierarchy.
  • ponow 5y ago
    So software copyright is not a net win?
    • sysOpOpPERAND 5y ago
      its fine until it stifles innovation one could argue https://www.investopedia.com/terms/p/patent-troll.asp https://www.investopedia.com/terms/p/patent-troll.asp
    • teddyh 5y ago
      Probably not, no. https://en.wikipedia.org/wiki/Criticism_of_copyright https://en.wikipedia.org/wiki/Criticism_of_copyright
• notacoward 5y ago
  Another uncomfortable truth: most software engineers beyond a few years' experience are highly resistant to suggestions for improvement in their craft. They're more likely to use their intellectual/verbal skills to push back than to move forward.
  • peruvian 5y ago
    Their craft isn't important. They can just move up the income ladder by getting a new job every ~3 years without really improving.
  • afarrell 5y ago
    Different people have different things they care about at different times. If I’m currently trying to improve my ability to do effective stakeholder interaction, I’m going to be reasonably resistant to switching to spending a bunch of time learning terraform.
  • DerArzt 5y ago
    The same could be said about all trades people (and yes I consider most software engineering a trade), there are those who care deeply about the quality of their work and improving that. Then there are those who get really comfortable and are fine with stagnating.
• teddyh 5y ago
  > 12. The open source maintainer problem The what problem? The only problem I see are entitled developers who think that putting stuff on GitHub and calling it “open source” is somehow an occupation for which they deserve a salary.
  • deleted 5y ago
    [deleted]
• deleted 5y ago
  [deleted]
• nickjj 5y ago
  This one from the article is a bit weird: > Sophisticated DSLs with special syntax are probably a dead-end. Ruby and Scala both leaned hard into this and neither got it to catch on. Rails is one of the most popular web frameworks around and a combo of Rails and Ruby power some really high traffic / high importance platforms like GitHub, Shopify and Stripe's API.
  • emteycz 5y ago
    Ruby had a huge hype, then its growth slowed down and now it's falling behind quickly. Yeah it's big, but other frameworks that chose a different path w.r.t. metaprogramming seem to be the more popular (and growing) choice today.
    • the_gastropod 5y ago
      While that may be true, I'm not sure that's evidence that DSL's are the reason. I would argue the explanation is: JavaScript. I think many people are compelled by the idea that you can learn one language, and handle both back and front-end development. As the language has improved over the past ~10 years, this angle has only become more compelling, and has eaten into the popularity of other "traditional" web frameworks like Django, Rails, Spring, etc.
      • emteycz 5y ago
        I myself am one of these people. But even if Ruby worked anywhere and I could share all my code, I would still prefer TypeScript because of its support for typed JSX and excellent typing system overall. The IDE can help me in most cases, while it stays silent a lot with Ruby. I just don't see what more Ruby offers - and I'm saying that as someone who really likes OOP and really wanted to like Ruby.
        • the_gastropod 5y ago
          I think JavaScript benefits from typing a lot more than Ruby does. Ruby is at least strongly typed, so doing something like `[] + {}` or `4 + {foo: "bar"}` will raise an exception instead of return you a seemingly-arbitrary value. As far as what Ruby offers over JavaScript? It's a bit personal preference, but I prefer Ruby for several reasons: - More stable ecosystem. There are more canonical "best" tools for the job. There's one dominant web framework, one dominant background job processor, one dominant task runner, debugger, testing framework, etc. - More robust standard library. Enumerable rocks. And rolls. - Better fits "OO" definitions—everything is an object in Ruby. It supports public/private/protected instance methods/variables.
• ReleaseCandidat 5y ago
  > ... will never broadly adopt Sphinx/rST or Sphinx/MyST, because everybody already knows how to use markdown. No. It's because the syntax is, well, §!$?§$. Headings, things like using an image as a link, that takes two lines of it's own (3 with an alt text). .. |LABEL_TO_USE| image:: image.jpg :target: http://example\.com
• nisa 5y ago
  > The open source maintainer problem isn’t going to get much better in the near future. People are gonna keep blaming “Capitalism” for this. People are gonna keep blaming “Capitalism” for a lot of irrelevant things. People are gonna argue with me about blaming “Capitalism”. Goddamn I am so tired of “the problem is CAPITALISM” takes and they will never stop The entitlement and arrogance is pretty mind-blowing - those damn' developern don't fix our bugs, don't always respond fast for security updates - such a big problem, but wait - maybe not such a big problem to actually task a dev from my company to work on the dependency - either by maintaining a local fork or helping upstream. Because oh well - this costs actually money. Sure blaming capitalism is oversimplifying the problem but it's pretty clear that most companies try to avoid using their resources for improving important open-source components. I don't mean paying the developers - that doesn't always work but instead doing things like upstreaming bugfixes and features, maintaining a local fork if upstream is not responsive or even publishing an improved fork. It happens but not very often.
  • afarrell 5y ago
    The problem is that there’s no agreed-upon point when we give FOSS maintainers the negotiating power to get the compensation they actually need —- whether that is patches or pesos.
    • nisa 5y ago
      I argue that a healthier approach would be to own the foss-components you use and to try to build an internal understanding of them - no need to audit every line of code but at least some high-level understanding what every component does would already be helpful - try asking for resources to do so, I guess most of the time you will be laughed at. Also giving your devs the knowledge and time to upstream fixes until the maintainer is happy would be great - so many interesting forks and pull requests in all kinds of projects that are just dumped out there but the work to integrate it into upstream is something nobody is doing. This requires resources and resources are money and there is no direct benefit for the corporation. So it's quite a big problem.
      • 5y ago
• WhompingWindows 5y ago
  My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are making great money by utilizing the greatest tool of all time: the computer. It's uncomfortable because many of us didn't understand this going in. We liked computers for a long time, we had a penchant for working with them, and it turned out that made us great money. Meanwhile, our friends who are teachers, firefighters, child-care workers, etc. are doing tough work daily for less pay, perhaps simply because they didn't use computers much or didn't like them. And yet, their jobs are ESSENTIAL and we need people to do them even though they're grueling and underpaid.
  • dpeck 5y ago
    You’re not wrong, but I’ll say the part about not going into it for the money is becoming less and less true all the time. For developers who are ~35 and up, almost 100% true, once you get younger than that you’ll find that there are a large and growing minority of people who are very much in it for the money alone without any particular interest or affinity for computing. Their parents, advisors, etc saw how much money was being made and pushed them towards computing as something more like a high ROI trade. You see the same done for specialized welding for smart, but not academically smart, kids. It’s hard work to get into, but if you get there it can pay very well, regardless of if you care much about the underlying metallurgic properties that you’re dealing with or not. This is completely fine either way, but it’s important to realize that we’re not really the professional of child prodigies that it once was.
    • kk6mrp 5y ago
      It feels to me like most people no longer find fulfillment in their work, regardless what it is. It really seems like almost everyone is in it for the money and could care less about the lack of craftsmanship.
• ixtli 5y ago
  This is a great essay. Also, the problem is capitalism and the fact that the argumentation won’t stop should probably tell us something.
• madsbuch 5y ago
  > ...statically-typed languages are better for large projects than dynamically-typed languages... > Formal methods will never be mainstream... Say what? these two statements are written just 2 lines apart?
  • yakshaving_jgt 5y ago
    What’s confusing about it? In this context, “statically-typed languages” refers to things like Haskell, and “formal methods” refers to things like TLA+. The two are not at all the same, nor are they intended to be.
    • madsbuch 5y ago
      One would say that static types has grown out of research in formal methods, and hence, is a consequence of formal methods.
• overthemoon 5y ago
  Is mobbing really better than pairing? I've never done it. Sounds awful. I got into this game to have long stretches of solitary work, that's when I'm at my best. Not entirely obviously, I still work on a team. Anyway, pairing can work well under the right circumstances, curious to hear anyone's take on whether mobbing works or not.
  • waylandsmithers 5y ago
    I've done it with 4 people on a team where occasionally there would be one blocking story before anything else could move forward, so we'd all just jump on zoom. I was never the one in control. It was really hard to keep focused, but the task at hand got done, and it was easy for people to take a break for a few minutes while things continued to move forward.
  • michael1999 5y ago
    Mobbing can be easier for people that pairing, and can be a way to observe the skills required for good pairing before being on the hook for practicing them.
  • DerArzt 5y ago
    It depends....if the mobbing is what my former agile consultants were pushing (having everyone from dev's to business analysts do it) then no, it doesn't work. The few places that I have seen it work sort of well is when there is some big issue going on such as a production outage that can be benefited from having a group of devs together looking at the issue. Aside from that the level of engagement goes down the more people you add to the session and it felt to have diminishing returns on the quality to developer count ratio.
    • TrickyRick 5y ago
      This is my experience as well, for a large issue or for learning new tech (Let's say you have a new lib which everyone will be interacting with) it makes sense. For day-to-day it's at best a waste of resources and at worst an excuse for people to do less while getting the same pay.
  • 5y ago
• 3pt14159 5y ago
  This piece is great overall, but: > TDD[...] zealots are probably zealots [...] Because they're sick to death of things breaking in production and having to program against interfaces that were designed as an implementer was thinking about them over how a caller would view them. There are times and places to not do TDD, I'd say on the backend around 15% of the time where exploration first is more important (e.g., some data science thing where you don't even know the shape of the data yet) but for run of the mill programming TDD works, but most people still don't do it even if they say they do. I had my zealot phase on TDD, and what got me out of it was just resigning to the reality that the world isn't going to change. But that said, when friends / coworkers going on zealot style TDD rants I pour gasoline on that fire because I still enthusiastically agree with them.
  • amw-zero 5y ago
    What got me out of TDD zealotry is the enormous cost of really testing software well, I mean all branches, all sides of all conditions, large amounts of input space coverage. Then that coupled with the fact that specifications change constantly and relentlessly, invalidating some percentage of all of your cases. I agree with the sentiment that got me into testing in the first place: software is complicated and hard to modify without breaking something. But, TDD for sure isn’t the answer to that problem.
• ChrisMarshallNY 5y ago
  > But especially so with me, given I care about weird exotic technology at the boundary of programming. Smells a bit like a humblebrag. Here's mine: But especially so with me, given I care about extremely high-Quality software. > Also also also, most muggles don’t want to program their own computers, much in the same way that most muggles don’t want to do their own taxes or wire their own houses. This is true, but I'm uncomfortable referring to non-techs as "muggles." Some of the least-computer-tech-savvy people I know, are doctors, lawyers, and scientists (and I actually know quite a few). > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. Unfortunately, I have to agree with this.
  • musingsole 5y ago
    > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. Which is why software as a skill in and of itself will go the way of mathematics. And then SE's might actually start doing real engineering.
  • Mezzie 5y ago
    > This is true, but I'm uncomfortable referring to non-techs as "muggles." Some of the least-computer-tech-savvy people I know, are doctors, lawyers, and scientists (and I actually know quite a few). Agreed. As a tech educator, STOP. I've been teaching people to use technology for decades, and, like with math, a huge stumbling block is "I'm not smart enough for this; only 'tech people' can understand this." And no, not everybody wants to develop algorithms or web pages (or fully wire their house), but most people can learn basics of how things work and look for ways to improve their experience. Also that analogy doesn't work: most people don't want to wire their own house, but being able to do basic problem-solving on your electricity saves the homeowner time and money AND lets electricians spend their time on bigger problems. Same with taxes, as somebody who isn't an accountant but does do my own taxes: Not everybody will do that, but most people could definitely learn how things like tax brackets work. This guy is a computer nerd. That's fine, but it doesn't make you INHERENTLY BETTER than people who are color theory nerds or whatever.
• palijer 5y ago
  >>The open source maintainer problem isn’t going to get much better in the near future. People are gonna keep blaming “Capitalism” for this. People are gonna keep blaming “Capitalism” for a lot of irrelevant things. People are gonna argue with me about blaming “Capitalism”. Goddamn I am so tired of “the problem is CAPITALISM” takes and they will never stop This is a horribly constructed argument for a great point that I would have loved to see expanded on and communicated better. Feels like the author was just trying to dismiss an argument with some "repetition legitimizes" comedic statement.
• musingsole 5y ago
  > While dynamic languages can be the right choice for a large project, you have to make the case for why it’s the right choice, like a killer library, something particular to the domain, etc. ...While dynamic languages can be the right choice for a large project, you have to make the case for why it’s the right choice, like a killer library, something particular to the domain, etc. 99% of software projects are by no definition "large". Why in the world would it follow that what is right for critical state infrastructure is at all the right way to do something not nearly as complex? An attempt at rephrasing the argument: "When you go to the moon, you need to concern yourself with the vacuum. If you're not going to the moon, you should put on your space suit because other people are going to the moon."
• Layke1123 5y ago
  [dead]
• isthis129283 5y ago
  "Empirical research on software engineering is a trainwreck" ...and here are some truths from my empirical research.
• Workaccount2 5y ago
  Well if we're just gonna bash software guys here.... The arrogance stands out for me. I have worked in many different fields and with a range of engineers (EE,ME,CE), none come close to the general aura of big ego and arrogance around software guys. It's similar to the levels seen in finance guys. Its like there has to be some relationship between compensation and true value, where ego makes up the difference. Of course there are the humble bunch in there, but god I have no idea how they get along with their colleagues.
  • agumonkey 5y ago
    I wonder if it was the case in the previous decades. I assume that a lot of this comes from the fact that computing is now more than trendy, and being knowledgeable on it makes you feel like king of the hill. Also lots of people going into computing, knowing the recent history. Strong opinions about things based on the last 10-20 years, choosing their little church. While having next to zero knowledge about previous history (tech or even business in general), nor fundamentals about computing, but they have enough data to flood you with their certainty :)
    • notacoward 5y ago
      > I wonder if it was the case in the previous decades. Less so, in my memory. Sure there was hubris. Sure there was conflict. But there was also a recognition that we were all small fish in a big pond. And there were still people around from when computing was an even smaller sliver of the economy, who tended me more "grounded" than anyone you'll see today. Now that computing companies are among the richest in the world, the mix of personality types within them has changed a lot and not for the better IMO.
      • agumonkey 5y ago
        I'd add: - innate difficulty: it's a bit harder to make an application on a 286 machine, you need to think more, you can't clone a template and tweak a few things to get a fully featured platform - also, more utility driven, can't make shiny visual and presentation. the app has steps toward goals and you get done quicker.
• ryandvm 5y ago
  > Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling social interaction is just devastating to that process.
  • seanhunter 5y ago
    You're not the only one. I absolutely detest it (to the extent I would absolutely leave a job if they made it a requirement) and a significant portion of devs I have worked with are lukewarm at best.
  • notreallyserio 5y ago
    I just want to be able to fart at my desk in peace. I haven't tried pair programming. It sounds miserable. I figure I'd end up paired with one of those people that can't stand to see you looking for something. You know the type: you're looking through cabinets for something and they demand you tell them what and they demand you go directly to the right place. Sure, I'm looking for something, but I'm also learning where other things are.
    • t0mbstone 5y ago
      The trick to pair programming is for each dev to have their own workstation with two screens. Then, you simply use a screen sharing tool to share and collaborate on a code editor on each of your primary screens. We used to use Screenhero for this before they got bought out by Slack, but another tool that works well is something like Tuple.app or Drovio. The beauty of this approach is that each person can "check out" temporarily and do research and look up stuff or check messages on their secondary monitor (without the other person seeing it), but they can easily move their mouse back over to their primary monitor and re-join in on the pair programming. It makes pair programming a lot more tolerable, and gives you the ability to collaborate, while still having some flexibility and autonomy. This also works well in both local and remote pairing sessions.
• NoGravitas 5y ago
  [flagged]
• stronglikedan 5y ago
  #99: Everyone is replaceable, even you.
• austincheney 5y ago
  1. Not everything can be declarative. Navigating tree models (file systems, DOM, decentralize relationships) is an inherently imperative task. This doesn't stop developers from forcing declarative abstractions over imperative concerns. It just means a foot gun at maintenance time or passing the buck to somebody else. 2. Legacy paradigms will continue to live, no matter how obsolete or harmful, so long as developers reliant upon those paradigms continue to find employment. Such developers will continue to find employment so long as such paradigms remain in formal education criteria. 3. Software hiring is extremely biased. Such bias will continue until software is perceived as generally harmful by people outside of software hiring. Until such time any attempts to limit bias will be met with maximum hostility, as such only benefits experienced and generally confident incumbents. 4. It is common in software to hate on credentials of any kind except a computer science bachelor's degree, which then becomes a credential. This line of thinking is prolific and extreme enough to view credentials as a form of incompetence regardless of what such credentials are or what they mean, thereby increasing bias. 5. Software will continue to swell and slow so long as the goals of the developers are out of alignment with the end product. Claiming product first goals by developers is not a solution if not reflected by the tool chain and processes. 6. The older the web gets the more costly it becomes to add text content to a commercial webpage.
• jancsika 5y ago
  > Also also also, most muggles don’t want to program their own computers, much in the same way that most muggles don’t want to do their own taxes or wire their own houses. I smell a red-herring that reeks of domain incompetence here. Find me even a FSF/Gnu zealot who argues that paradise includes end users fishing around in ALSA or display settings to "program their own computers." As Keenan's character on SNL's Black Jeopardy said-- "Everybody's got a guy." Anyone who has ever installed something as simple as Ublock Origin for a muggle gets this. Anyone who has ever tried to turn off telemetry for good on a muggle's proprietary OS gets this.
• mgaunard 5y ago
  Pair programming or mobbing are a huge waste of resources. I know that myself I can't actually get anything done unless I'm in control. The only use this sort of this could have is to train juniors or hand over projects.
  • lolsal 5y ago
    > Pair programming or mobbing are a huge waste of resources. Likely for some, but not all cases. Pair programming at my shop had a weird positive multiplier effect on velocity/delivery. It was optional and about half the team did it. Different folks work differently, we aren't all productive in the same ways.
  • stnmtn 5y ago
    Do you think that this is true of every programmer, or that there are people who do experience increase in productivity from pairing?
    • mgaunard 5y ago
      We all have our own set of values. Myself I value independence and self-learning, so I would be inclined towards having a negative opinion of people that require the constant assistance that pair programming provides.
• commandlinefan 5y ago
  > TDD/FP/Agile zealots So his phrasing is a little hard to follow here, but I take this as being part of the ongoing TDD backlash, which is unfortunate because in my 30 years of experience, the opposite of TDD is "not testing anything at all". Or rather, when somebody pushes back against TDD, they usually push back against any form of unit testing. The net result is that the code itself is difficult to impossible to actually test... so nobody ever does outside of QA who does end-to-end black box testing and just kind of hopes they've covered all of their bases (hint: they didn't). I guess I'd have to understand better what his definition of a TDD "zealot" is because I've been accused of being one for insisting that non-trivial code that doesn't have unit tests (and doesn't even allow for them) is unacceptable.
  • evouga 5y ago
    > so nobody ever does outside of QA who does end-to-end black box testing and just kind of hopes they've covered all of their bases (hint: they didn't). You don't need to cover all bases, in 99% of software. (And in the 1% where you do, you should probably be using formal verification.) Testing is an investment and should be analyzed in terms of ROI. There is a cost to writing tests in advance, a cost to fixing bugs after writing the code, and a cost to shipping software with bugs left unfixed on rare codepaths. Sometimes TDD yields high returns indeed (usually for "library code" that (a) does something very complicated on a complex data structure; (b) is easily isolated from the rest of the system without writing tons of mocking infrastructure; (c) has a stable API that is not frequently refactored.) Often it does not. I've found that a combination of static assertions, black-box systems testing, and incrementally adding regression tests during debugging allows me to develop good code more efficiently than TDD the vast majority of the time. Your mileage may vary, of course.
• black_13 5y ago
  Age is something you should talk about.
• angarg12 5y ago
  > Any technical interview is going to be gameable and exclusionary to some underrepresented group/background. Bold claim! I agree, and think this isn't talked about enough. People love to hate leetcode-style tech interviews, but the truth is that it made it more accessible for some people (like myself) to enter the rungs of top tech companies.
• travisgriggs 5y ago
  > We don’t have the Alan Kay / Free Software / Hypercard dream of everybody having control over their own computer because integrating with disparate APIs is really fucking hard and takes a lot of work to do. APIs and distributed integration are hard. But the modern API landscape is a long long long way away from what Alan and folks were shooting for. Sure, you get the messaging part, but that research team wrote a number of papers, one of my favorite being Design Principles behind Smalltalk (https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....). When I read through the headlines there, I don’t feel like the modern API space lives up to those principles very well. To be clear, Alan Kay’s entire hypothesis may be flawed. I’m not asserting either way on that issue. I’m just pointing out that alluding that Alans dream didn’t work out because APIs are what he said and we’re miserable, doesn’t really follow, because there’s so much lacking in the rest of the picture.
  • hunterx 5y ago
    didn't work out because ... little inventors, lots of implementors.
• aaroninsf 5y ago
  Are these uncomfortable? I don't think they're cynical (as stated); I think most of them are common sense and I had assumed consensus understanding. But I don't spend much time with young whippersnappers. It's true that experience, and what appears to the irrationally exuberant to be cynicism, are regularly coextensive...
• poulsbohemian 5y ago
  No. 13 in this list is absolutely true, but I’m not even sure that a mass casualty event would be enough. Year after year there are credit card / social security / customer data breaches, but companies have done the math on whether to put in place more upfront measures versus a cleanup afterwards. Same with performance - I used to go into companies to fix performance issues. Companies do not care if their staff has to wait minutes for that request to process. They don’t care if customers have to do stupid workarounds. Only when there is indisputable proof that (big) money is being lost will they bother to fix performance problems.
• irq-1 5y ago
  13. We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. [3] And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. [3] ...I think the killing has to be directly and obviously attributable to the software. Something that would cause a media sensation. Since we're talking uncomfortable truths: BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL. That was blamed on a bad UI/UX at the time, and nobody died, but there was never even talk of regulation. Credit Cards on the web got PCI DSS regulation because money, not because of people dying. Money has to be tied to "things like performance, compatibility, accessibility, security, or privacy" not lives. https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec... Also, the recent Boeing 737 Max scandal resulted in a payment but no regulation. https://www.justice.gov/opa/pr/boeing-charged-737-max-fraud-conspiracy-and-agrees-pay-over-25-billion https://www.justice.gov/opa/pr/boeing-charged-737-max-fraud-...
  • onecommentman 5y ago
    Money and focus to improve SE culture can come from just changing civil liability doctrines, instead of gov’t regulation. For example, guilty-until-proven-innocent (res ipsa loquitur) would make poor IT design and operations a lot more expensive, at the expense of a lot more court cases and a chilling effect on new software. For mature core operations, the price paid by society might be worth it. The IT industry would then be forced to come together and address issues at an industry level, if for no other reason than every player avoiding painful amounts of time and money spent in the civil justice system…which is a lot less fun than even the most torturous code reviews. My sense is (IANAL) that the liability doctrines for software are stuck in the 1960s with all software viewed as a “best effort” sort of experimental exercise that must be protected from the rigors of normal liability. I think we are past that point for a lot of software components. But who in the software industry dare acknowledge it?
• poulsbohemian 5y ago
  >We don’t have the Alan Kay / Free Software / Hypercard dream of everybody having control over their own computer because integrating with disparate APIs is really fucking hard and takes a lot of work to do. A couple weeks ago there was a conversation here about software in the 90s where the argument was proposed that as an industry, software veered off in the wrong direction somewhere along the way. When I read the above from the article, there's a part of me that starts feeling this...we have all this horsepower in both hardware and software such that it should be as "easy" for people to make software in the same way they can now make pictures, music, and videos without needing hundreds of thousands of dollars invested in a movie or recording studio. Like, these are mutually exclusive points - you can have APIs that maybe are a step beyond, but does that mean that all software must be hard to write? I was telling my son just last night about how people did all these cool, unexpected things with Hypercard back in the day. It didn't need to be perfect, it didn't need to be "enterprise grade" because it was easy to make and was good enough for what people wanted to do.
• jiaminglimjm 5y ago
  Not capitalism, but imperialism & its neo variants.
• mcguire 5y ago
  "The Unix philosophy of “do one thing well” doesn’t actually work that well. Dan Luu explains this better than I could." The question is, what works better? Nothing in software development works particularly well. But some things don't work at all. "TDD/FP/Agile zealots are probably zealots because adopting TDD/FP/Agile/Whatever made them better programmers than they were before. I mean it would be better if they learned TDD/FP/Agile/Whatever without becoming zealots, and incorporated their ideas into an overall synthesis of a nuanced programming philosophy, but I don’t think most people are interested in doing that anyway. Possibly because “synthesizing a nuanced programming philosophy” only matters / is useful to a very small slice of programmers, because it’s honestly a kinda weird thing to expect tens of millions of people to be that weirdly obsessive about their job." But it's not kinda weird to expect tens of millions of people to behave like zealots of a thing that doesn't work particularly well? (A non-zealot cannot work with a zealot without at least acting like a zealot. The true zealot won't allow it.)
• divbzero 5y ago
  14. Most software “engineering” jobs are dominated by activities other than writing software, and the limited time spent actually writing software is dominated by routine coding tasks that can only be loosely termed “engineering”.
• sorokod 5y ago
  > 10. TDD/FP/Agile zealots are probably zealots because adopting TDD/FP/Agile/Whatever made them better programmers than they were before. Possibly, but that doesn't mean it made them good programmers.