1. 1

    This is amazing! It’s a great summary of what’s happening in photography. However I think what’s killing high-end cameras is that it takes longer to find a cable and copy the images to my ipad than it does to type the 27 hashtags before I post to instagram.

    Computation photography is doing amazing things, but at the end of the day photography is about creating an image that you’ll do something with. Anything that shortens the time between pressing the shutter and getting an acceptable image for your photographic vision is a big win. Plus a phone is much lighter than a full frame body with a 24-70 f2.8 so I’m excited for the future!

    1. 15

      To have a way for others to find you

      If you google either my real name or my nickname you’ll find my github or twitter profile ranking a lot higher than all the personal websites I ever had. I was too busy playing around and coding over doing SEO.

      Also I don’t want to be found in meatspace.

      To build your personal brand

      Nobody wants to engage with a brand except shouting at company’s twitter accounts if they fail to do proper customer service. I am not a brand, I am not popular or famous. I’m just a normal person on the internet. Also employers don’t care about your personal website except for one of 50 datapoints. Shout out to the guy whose CV I had to check for hiring a position. I didn’t want to see you and your girlfriend in underwear before we even met. Not that it changed my mind or made me prejudiced, but it’s still a weird story.

      For the email

      Come on, that’s a domain name, not a website.

      To make some money

      Does this really work out unless your traffic is exploding? Anything below 100EUR isn’t worth the hassle in filing taxes for that. You are filing taxes for your ad income, right?

      Also looking at my output apparently I got pretty tired of blogging after 18ish years and feel I have nothing original to say and prefer to write snarky comments.

      But in general I absolutely approve of people having a website, so don’t mind me criticizing this post :)

      1. 12

        Also looking at my output apparently I got pretty tired of blogging after 18ish years and feel I have nothing original to say and prefer to write snarky comments.

        I like Matt Might’s take on this:

        • Writing a detailed email reply? “Reply to public” with a blog post.
        • Answering the same question a second time? Put it in a blog post.
        • Writing interesting code? Comment a snippet into a post.
        • Doing something geeky at home? Blog about what you learned.
        1. 3

          Yep, good points and I know them. :)

          Look at my profile, I don’t think I write a lot of detailed replies, and less so emails.

          But for the last few things I made I just think I (we as a team) either didn’t do things that were cool and that could be made public at the same time. Yeah. maybe the scale has to be readjusted and the barrier for “blogworthy” should be lower and the output flows again.

        2. 5

          Criticizing a blog post that’s encouraging people to get off the main platforms, be creative and build their own space on the internet doesn’t seem very productive.

          1. 4

            @wink’s comment isn’t criticizing the idea of

            getting off the main platforms, being creative and building one’s own space on the internet

            it’s merely criticizing the reasons given in this article, which is productive enough for me.

            1. 2

              See my last point. Also I think these are partly just false promises, but they shouldn’t discourage people from doing it.

            2. 2

              While I agree with not wanting to be a brand, a web developer without a personal website feels a lot like a Ford dealership with an employee parking lot full of Toyotas and Hondas. While other engineers completely understand this situation, if you have to appeal to less web focused people(e.g. for a high level position in a smaller company) it’s a small step that can help a lot.

              update: I’ve recently gotten back into photography and most photographers looking for freelance work have a curated portfolio under their own domain name. But this might count more as a small business than an individual looking for recognition. I find it interesting that with all of the photo-centric social media out there the way to stand out as professional is to have a site under your own domain name. This amount of personal image is similar to carrying a big black DSLR “because I know what I’m doing” when you could easily do the shoot on a cell phone.

              But this is a very focused point, I otherwise agree with your comments.

              1. 4

                If you reference the quote “I’m not a web developer, so I don’t need a website” I think it’s not about web developers having websites, but exactly other people.

                Hell, I’ve been a web developer for a good part of my working life and I never had a (one, or more) personal website because of that - always for other reasons, most of all to sum it up because I thought it was cool and at times - very handy.

                Maybe I’m too much of a big proponent of “give me back the old weird web on geocities and subdomains hosted on friends’ servers” because I never saw this to push my portfolio or brand or whatever. I think I never posted a CV on my website because why would I?

                Also the author is conflating “having a website” and “having your own domain”. Both are awesome and useful, but I see other reasons.

                NB: If anyone wants to push their own website to be a freelancer or be hired or whatever, go ahead! I’m not arguing there. I just don’t like this “do this or you’re not being smart” angle.

                Maybe I do sound so negative because the author wildly mixes points I agree and disagree so much :)

              2. 2

                I think you might be confusing the “personal brand” point somewhat. The idea is not to try to become a Faceless Professional Entity, or really anything other than who you already are. The idea is to become more easily recognised for who you are – which is, likely, an authority in your specialisation. By using consistent visual language and other tricks available only to people with their own web sites, the audience will more quickly associate content with your persona.

                1. 1

                  I haven’t done any SEO and my website ranks higher in searches for my real name and nickname. This data is just as anecdotal as yours of course.

                  There are a few pages that are in the top 10 for their search terms, just because they happened to be what people needed.

                1. 4

                  I’m already wondering if WSL is admitted defeat or an EEE scheme, and if the latter, what the “extend” step is going to be.

                  1. 14

                    It’s long-game EEE. Corporations have discovered that by throwing a lot of developers to an open-source project they can control the ecosystem. Then gently but slowly push it towards their walled garden. Add features that make it more convenient to their cloud solution, then collect all of the data.

                    An example is Google Chrome. 1) throw a lot of engineers and make a better browser. 2) keep pushing the spec forward as fast as you can so that it takes a huge engineering effort to be able to compete. 3) add features like the google login that make it more convenient but also shares all your data. Chromium might be open source but also long as you use their google login they win, and there is no alternative available for shared user sessions.

                    For WSL the key is to get developers back onto the Windows platform. macOS was able to capture some of the Linux market because they added bash and other unixy tools that made Linux developers comfortable. As soon as those developers only start testing on WSL they start winning. Then add easy integrations to deploy to Azure. The same will happen to GitHub and VSCode.

                    1. 2

                      “EEE scheme” is a new term to me, and my googling is only returning taxing schemes. What does it stand for?

                        1. 1

                          Thank you

                        2. 3

                          EEE = Embrace, Extend, and Extinguish. What they did to LDAP and many other once open things.

                      1. 25

                        I do this with Emacs and org-mode. I have one dedicated file - journal.org, and I create an entry per day. Despite ‘setup’ and configuration costs (which isn’t really that bad if you look at getting started with Spacemacs or Doom-Emacs), I’ve yet to come across anything that’s as frictionless whilst at the same time retaining the ultimate in flexibility.

                        It might be worth a look at org-journal, but personally I’ve found the above to be pretty much all I need.

                        1. 7

                          Another +1 for org-mode. I keep an inbox.org that has a top level heading for each day. So it might look something like this.

                          * March 19 - Tuesday
                          ** 1:1 w/ boss
                           - some 1:1 notes
                           - more notes
                          *** TODO a task from the 1:1
                          ** A coding task [ 0 / 3 ]
                          - [ ] write the code
                          - [ ] write the tests
                          - [ ] make a PR
                          

                          org-mode has built in tools to manage the TODO items and the checkboxes for you. You can pull a list of all todos, or see what things were checked off what days. The check boxes give a nice overview when the subtasks are folded. All of this gets folded up by org-mode so I can see a nice summary of the day without needing to dig into each sub item.

                          1. 3

                            org-mode has built in tools to manage the TODO items and the checkboxes for you.

                            The dates, too: ‘C-c .’ AKA ‘org-time-stamp’ inserts <2019-03-19 Tue> and S-leftarrow goes back one day, etc.

                            1. 2

                              I do this exact same thing. One top-level item for each day.

                            2. 4

                              Same here with org-mode, but I also have a capture template that allows me to create a journal entry from anywhere with very little effort.

                              The following in my emacs config file allows me to type C-c c j to open a buffer where I can record my entry, which then gets saved to ~/org/journal.org under the Journal heading.

                              (global-set-key (kbd "C-c c") 'org-capture)
                               (setq org-capture-templates
                                     '(("j" "Journal" entry (file+olp+datetree "~/org/journal.org" "Journal")
                                        "* %?\n  %i\n  %a\n")))
                              

                              Emacs capture templates

                              1. 2

                                I do this as well. I have a file: labbook.org with one entry per day. For me I was getting lost trying to come up with good methods of organizing my content (todo.org, $project.org, $person.org) and finally decided to simplify with chronological ordering.

                                1. 1

                                  If you’re an emacs person org-mode is hard to beat. It’s outlining features are without peer near as I can tell. It’s one of the things I miss about emacs.

                                  1. 2

                                    Even if you don’t use Emacs for anything else, what stops you from using it for Org? Your comment reads a bit to me like “If you’re a Java person, Minecraft is a pretty fun game”.

                                    1. 1

                                      Because I came to realize that much of Org’s power, much like the rest of emacs’s power, is more than I need and ends up being a bright shiny distraction that I end up futzing with endlessly rather than actually getting work done :)

                                      Plain old Markdown files have served me very well for work stuff, and Evernote for personal stuff.

                                1. 37

                                  I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.

                                  I find work that matches my ethics; at the moment I’m lucky enough to support radiopaedia.org. We get regular letters from around the world detailing cases where the site has helped save a patient or markedly improve their health, which is always a morale boost.

                                  What is there that’s genuinely interesting and exciting in the world of software, and what was your way of engaging your interest and excitement?

                                  Software systems get used to plan large-scale infrastructure projects, keep track of clean drinking water, food production & distribution, and healthcare. Being aware of the positive outcomes my work generates has become key to enjoying it.

                                  1. 24

                                    Some (mostly unfiltered) thoughts on this:

                                    This all sounds very familiar. In fact, I resigned a few weeks ago with no new job lined up as I felt my entire job was just useless. Everything gets rewritten every year or so anyway, so why bother?

                                    I was rewriting some of the same code I rewrote when I started. When I joined a lot of stuff was objectively bad; for example a lot of the email handling code was so bad a lot of emails simply didn’t get delivered, or incoming emails wouldn’t get accepted (it was written by someone who didn’t understand email). So my refactors served a clear purpose: “don’t drop emails”, “make sure emails are RFC-compliant”, etc. I then refactored things to add some features (“more details logs”, “ability to re-send delivery failures”, etc.) Again, refactors to enable a concrete goal.

                                    Later on, we did some refactoring to make stuff compile faster; it was taking upwards of 30 seconds for even simple changes, and it was pretty annoying. This involved rewriting quite a bit of our API, and that took maybe 2 months in total. I’m not sure if it was worth it in hindsight, but at least it had a clear concrete goal (“make it compile faster”), which was measurably achieved. It did make working with the code more pleasant, as waiting 30 seconds for a simple type is no fun at all (fast compile speeds are supposed to be a feature of Go!)

                                    But now, I see people rewrite stuff because “it’s more elegant, “it had better layers”, or “this is the best way to do it according to {person,methodology,religion,…}”, which are all really just rephrasing of “I prefer it this way”. This doesn’t mean the new way is bad per se, sometimes I think it’s probably a better approach too, but … the “old” way is working, and often has been working for quite a while. Why rewrite it? “I prefer it this way” is not a concrete goal. What is gained with the rewrite? Often this isn’t clear, and at the same time there’s still the increased workload. Even if you’re not involved in the rewrite directly, you’ll still have to learn the new API and/or way of doing things.

                                    This is a product to solve concrete problems for our customers. The code to achieve that isn’t some sort of art project.

                                    Yet, many people seem to treat code as an art project. Now, I treat some of my personal projects as “art projects” – and I learned a lot from doing that – but when building software in a team of people that’s just not workable, every time someone new joins the “art project” needs a re-evaluation because it doesn’t fit their sense of aesthetics.

                                    Software is easy to change. This is great in some ways, but it’s also easy to fall in to the trap of constant change. If you build, say, a bridge of building you can’t just change it at a whim, even if it has serious problems such as lack of daylight or airflow (far too many office buildings suffer from this), so people accept that the world is imperfect, suck it up, an deal with it the best they can. But in software it’s tempting to say “no, I can make the world a better place! I just need to rewrite [..]!” Sometimes that is the correct approach, but often times it’s not. Especially not if you’re in a team. It’s very hard to actually prove something is “better” in the world of software, so the endless battles/bikesheds start.

                                    This isn’t just a software dev problem, it’s also a management problem in the company. But I don’t see that changing, so I just quit.

                                    If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.

                                    I don’t know what I’ll do next; maybe I’ll just go jwz and open a bar or something. I really like building software products, but am thoroughly fed up with the industry. Everything feels like a battle, and I’m too tired of it. It might be worth it if I felt the end-result is worth it, but it’s just regular B2B software. Not the worst in the world, but nothing special either. There are a whole bunch of competing products that do an equally good job (if not better).

                                    1. 12

                                      If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.

                                      Every time I’ve seen this happen, it’s at a organisation that has money far in excess of its costs (unfortunately, this happens pretty often in b2b software).

                                      This enables middle management to start empire-building / hiring for projects of dubious value. You can fight it in the early stages by having a suitably aware CEO (eg 37signals / basecamp) but as you get to larger organisations, most roles fit this description.

                                      Once you have more developers than you need to solve the problem, you start stepping on each others toes and spending all your time communicating; before you know it, there are four teams building microservices (to reduce the communication overhead) to solve a problem that only needed one team of 3-5.

                                      You can avoid this by finding a place that either lacks excess money, or has somewhere to sink it. Basecamp sink it into high engineering salaries and dividends to owners; radiopaedia can only afford me part-time, but can hire me for more hours if they get more money.

                                      1. 5

                                        There is a saying that if everybody are morons, you are the moron. (For clarity, I don’t believe you are a moron, you seem bright).

                                        Could something similar be said of battles? If everything feels like a battle, does it come from within?

                                        1. 4

                                          Okay, some more mostly unfiltered thoughts (I guess Lobsters is my weblog now?)

                                          That’s not unreasonable, and I’ve been thinking about that for quite a while during the last few months (even before I resigned). There is an easy solution to it: shrug, don’t care about anything that happens outside of the narrow scope of the job I was hired for, do my boring job for a few hours, and collect the paycheck.

                                          But that’s not really how I work. In many companies there’s a lot of stuff “between the cracks”, stuff where there’s no person/team who has a clear responsibility, but really should get done. I tend to do a fair amount of work “in between the cracks” as that’s often pretty valuable for the business. Example: I wrote standard scripts for our Travis integration, because that’ll save everyone a lot of time so they won’t have to ad-hoc the .travis.yaml files with random copy/pasting. I spent a day on it two years ago and while hardly perfect, it’s been working pretty well since then. Yet I’ve had to deal with a ton of bikeshedding and headaches about it. Some of the feedback has been reasonable and constructive (great), but there’s also a lot of “change for the sake of it”, and some downright toxic stuff (like the guy that just overwrite it all several times with his own version without prior discussion, often getting a few key things wrong).

                                          Perhaps the worst part if that all the bikeshedding and toxic idiocy made me shoot down a more reasonable proposal that someone made a few months ago. The PR did have a bunch of issues and needed quite a lot of work, but fundamentally it was a good effort as it attempted to address various real concerns (and was’t a “I don’t like the way it’s done” type of rewrite). The entire thing was eventually amicably resolved, but being in the state where I growl at things because I’m tired of bikesheds and toxicity being flung at me is not a place I want to be at.

                                          To be clear, the problem isn’t “everybody”, it’s just that there are a few people who have very strong visions on the One True Way™ how to do things and will push that vision with little sense to pragmatism. A lot of people think that’s somehow normal, so these people can do what they want (some of these people are also very toxic).

                                          As I briefly mentioned, this is just as much of a management fail as anything. Ideally, management should have nipped a lot of this nonsense in the bud and fired a lot bunch of these people (some of the more toxic ones have).

                                          Some examples: I wrote our internal Go framework; this wasn’t a “invent a framework from scratch” effort, but more “codify common practices our existing projects already use, while making sensible ROI improvements”. The end results is pretty decent, if I say so myself. Yet, no one uses it, as it doesn’t fit the One True Way™ for any of the teams. The result is that we now have 6+ “frameworks”, all based in varying degrees on the original. There is loads of duplicated effort here. I tried very hard to accommodate people’s concerns, but there was a lot of “I don’t like it”-ism and people just went of in their own direction anyway 🤷

                                          I don’t even have strong opinions. I just care about 6 teams not duplicating all effort to produce a Go API. Not unreasonable, right? But now we’ve got all that duplicated effort. Worse, some of these efforts are just … not very good. We’ve had two unreleased apps that already had to undergo a massive rewrite before release because the re-invented stuff sucked too much, but is being ignored “because I don’t like it”. I get that new apps sometimes need to take risks and experiment, and that some of these risks don’t work out, but this isn’t rocket science, this is basic CRUD APIs. We already invented all of that 2 years ago.

                                          I’ve been working on a weblog post about all of this for a while, but I find it hard to articulate my feelings accurately, because when described like above it doesn’t necessarily sound like a huge deal. “So no one uses your framework, deal with it!” In part, it’s a “death by a thousand cuts” affair, this is just one example. There have been a lot of pushes to rewrite/redo existing systems without a clearly stated goal. Seeing a lot of your work being rewritten all the time has a certain psychological effect. Why bother if everything will be rewritten next year, anyway? There was also a good HN comment on that last week.

                                          I’m also one of the few that actually takes the effort to push back on all of this. A lot of people seem to shrug in apathy, or they just don’t do anything because they don’t want to spend the effort to get involved. Turns out that actually caring about making a good business, and not just doing the job you were hired for, can burn you down. I’m “just” a developer, I don’t really have more authority than anyone else. In hindsight, I should have either pushed for more authority, or tried harder to get those in authority aboard. Being remote while ~75% of the company is in an office probably doesn’t help either, especially not after I moved to New Zealand which put me in a massively different timezone (main office is in Ireland).

                                          Part of this is just growing pains from small startup to company with >250 people. When I joined stuff worked pretty well without any direction, as a lot of people were very pragmatic and dedicated. Now that’s we’ve increased the amount of staff by a lot, things are more tricky. I guess I could work to change the culture, but after 3 years I feel burned out and to be honest, our products aren’t all that great and not really sure if it’s worth is trouble.

                                          1. 2

                                            What you’re describing here sounds like a bad mismatch between the level at which you care and the level of authority you hold. Plus probably. the proportion of payoff you stand to receive if you do succeed.

                                            Put another way: if you’re high up enough in the organisation that you could fix it, it might be your responsibility. If you’re not senior enough to e.g. be able to order people to knock bad behavior off, then by definition it is not your responsibility.

                                            Please don’t get emotionally invested in a company of which you are not a large-stake shareholder. It is IME a recipe for getting burned out hard.

                                            1. 3

                                              I suppose you’re not wrong, but on the other hand apathy and not caring is also quite toxic, IMHO.

                                              1. 2

                                                Sure, don’t start casually keying peoples’ cars on the way in or whatever. Care about your work. Don’t try to fix things that are your boss’s (boss’s) job, though.

                                      2. 26

                                        I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.

                                        Here’s why this is so correct: being excited by technology is a surefire way to be disappointed in life.

                                        1. 19

                                          This kind of sentiment confuses me, especially given the context of this community. If working at a job that matches your ethics is what does it for you, then that’s amazing! We need more people like that around to make the world a better place.

                                          But disparaging people for being excited about technology is odd, to say the least. There’s something intrinsically satisfying, at least to some people, about learning new things, understanding the context in which that thing is (or is not) useful, and why it is (or is not) more useful than the old way of doing things. Do you think a mathematician being excited about mathematics for its own sake is a surefire way to be disappointed in life?

                                          Treating your software like a craft and always striving to be better is a great way to enjoy what you do. A carpenter isn’t diminished by making tables for whoever happens to want to buy them, they can enjoy their work intrinsically as they masters their craft and take satisfaction in a job well done. Obviously this can be complicated by the reality of working with other people who may not treat it the same way, but… that’s how people work, and that problem exists in any field or career.

                                          1. 20

                                            But disparaging people for being excited about technology is odd, to say the least.

                                            If you get excited about technology, it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own, which most of the time is going to be deployed to sell more ads or perform more effective surveillance.

                                            1. 7

                                              it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own

                                              There is a certain irony to this comment coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)

                                              One way to help people is to not criticize their internal motivations simply because they don’t align with yours. If someone gets home at the end of the day and feels great for no other reason than that they got to write a bunch of code and they love how writing code makes them feel, more power to them.

                                              It might be more meaningful to also help other people with your tech, but that has its downsides. When you hang your satisfaction on someone else’s joy, you give others control over your own happiness. You sacrifice the freedom to feel good about something you did just because they happened to not like it.

                                              Each of us is free to find our joy however we like.

                                              1. 8

                                                coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)

                                                On the contrary, the reason I have continued to make custom keyboards after all these years is precisely that; it helps people. The keyboards allow my customers to avoid RSI and learn some useful DIY skills. I wouldn’t still be doing it otherwise.

                                                If you look at my comment in context, I’m replying to a post that is explaining why the original poster no longer feels motivation to work in software. If you don’t feel like they do right now, that’s great, but the odds are very good that at some point in your life you will if you’re working in the technology industry.

                                              2. 4

                                                Genuinely wondering how you feel about this:

                                                If you get excited about mathematics, it’s much more meaningful to get excited about how mathematics could help people, not about mathematics on its own, which most of the time is going to be used to sell more ads or perform more effective surveillance.

                                                1. 5

                                                  which most of the time is going to be used to sell more ads or perform more effective surveillance.

                                                  This isn’t actually true for mathematicians as far as I know? I mean, if you’re a statistician working for an ad company, then sure; it seems to hold up fine, but as far as I know most mathematicians aren’t.

                                                  1. 1

                                                    The “most of the time” probably isn’t (I personally think definitely isn’t, but no data no certainty), but if you’re a mathematician working on something just because it interests you, there is a chance still that someone might find a use for it in ways that you didn’t think about, including ads and surveillance. What I was wondering about phrased directly is basically, whether these two questions have different answers for you:

                                                    Q1: Is it meaningful for a mathematician to work on some mathematical structure that interests them, without any foresight of a meaningful use of their work?

                                                    Q2: Is it meaningful for a programmer to work a on a technology that interests them, without any foresight of a meaningful use of their work?

                                                    where meaningful is relative to you personally.

                                                  2. 2

                                                    Mathematics is discovered. Technology is built.

                                                    When you discover new mathematics, nobody owns the math.

                                                    When you build technology for an employer, somebody else owns the technology.

                                                    That means:

                                                    • Your work can be destroyed by someone else without you getting a say (eg the project discontinued by management)
                                                    • Your work can be redirected to only be used in ways you disapprove of.
                                                    1. 1

                                                      Mathematics is discovered. Technology is built.

                                                      This statement is in my opinion too general to have any useful meaning or validity.

                                                      I however find your distinction between discovery and invention (building) interesting, so I’d like to ask you a question. Consider a new real world programming language L. It would probably be very easy to argue that L was invented. Assume now that a user of L stumbles upon a quirk in the way L handles closures for example. Is this quirk an invention or a discovery?

                                                      1. 1

                                                        The quirk is in an implementation; it was invented by the language creator and discovered by the user.

                                                        1. 1

                                                          What about the behavior of numbers? why isn’t that an implementation detail? if numbers are too natural for you then what about the behavior of sequences of numbers? doesn’t that seem a bit closer to an implementation detail?

                                                          1. 1

                                                            Whether numbers are an implementation detail is a question for theology 😀. Human understanding of them is a discovery.

                                                            1. 1

                                                              Whether numbers are an implementation detail is a question for theology

                                                              Hehe, I was actually heading in the direction that numbers are defined by humans and not by any divine entity and thus the way they behave is maybe just an implementation detail of how we defined them;)

                                                2. 8

                                                  But disparaging people for being excited about technology is odd, to say the least.

                                                  My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment. This does not mean you are a lesser person for liking it.

                                                  Treating your software like a craft and always striving to be better is a great way to enjoy what you do.

                                                  I take great pleasure in writing software, making keyboards and other such things. I truly enjoy it and I always want to improve. But that is not technology. Technology is just a vehicle for that kind of growth. The technology itself may be interesting and I may like it, but I certainly don’t like it just because it’s technology.

                                                  According to the life expectancy measures, I have one foot in the grave (that is, I’m past the halfway point). I grew up in the personal computer revolution and was an adult when the Internet took off. I’ve heard a lot of promises of what technology will do and how it will change things. Only one thing has ever been consistent: it does change things (corollary: we’re terrible at predicting the future). It does this for both good and bad, and rarely in the ways you hope. I used to look for the new thing all the time. I don’t anymore and I’m happier for it.

                                                  The joy I get from technology is understanding it and using it so that I can do things or better yet, how it gets used to help people. I don’t get excited about AI/deep learning, for example, I get excited about the thought of learning how it works and maybe using it to help me with my extensive collection of papers. At the same time, I think the adtech world is nothing short of a blight on humanity and have zero respect for it. As such, I would never work in it, regardless of what AI techniques they use. Being excited about AI for the sake of technology, in this case, would cause me great inner conflict and thus, disappointment. To avoid these situations, I no longer seek happiness in technology.

                                                  This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”

                                                  1. 2

                                                    My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment.

                                                    Not if they die tomorrow. Sorry for the strong statement, but I just wanted to provide at least one counter example.

                                                    People are different, maybe as programmers we need to resist the urge to generalize more than other humans.

                                                    1. 2

                                                      I wasn’t generalizing so much as playing the odds. (And yes, there are plenty of counter examples. But it’s also not a cut and dried kind of argument, which is kind of the point.)

                                                      1. 2

                                                        Fair enough, I personally share your sentiment. Thanks for your explanations, you’ve certainly put it in a way better than I could’ve.

                                                    2. 1

                                                      This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”

                                                      I’d like to point out that this is the same tendency, expressing itself in opposite ways. If we had an Earth-Level EMP Pulse, people would die. A lot of people. Technologists have a hubris that says “We can do it better, just watch us” that leads to magpie development, technological innovation, and a wish to burn it all down.

                                                      1. 2

                                                        It’s a hyperbolic statement.

                                                    3. 10

                                                      There is almost nothing new and shiny that’s genuinely interesting, in my opinion. I derive excitement from learning about new concepts and such that I haven’t previously known about–there’s plenty of that. I do not derive excitement from whatever the current hype is. Elixir? Serverless? Those just feel dull to me. They seem like a cycle: “This is the next great thing! It’s SIMPLE! And FANTASTIC!” and then those folks write software systems that, like most other software systems, suck. Everything is simple in the beginning, and everything is legacy after five years. I think that’s what Geoff was getting at.

                                                      1. 4

                                                        I think you are describing the toxicity of the hype cycle and the shallow excitement it inspires. The target of the hype, being it yet another software framework, a music genre, or a food, is not relevant.

                                                        Trends are almost parasitic: they chase after new idea, feed on the novelty aspect and then leave it behind.

                                                        1. 1

                                                          I share that, mostly. There’s one problem with this approach I’ve experienced, which is that it focuses on getting fundamentals right (good!) but disregards the importance of getting the superficial details right too.

                                                          The reason for e.g. Go being popular is that they got so many little details right, not because it contains new concepts.

                                                    4. 6

                                                      I find work that matches my ethics

                                                      That’s a good suggestion. I think this is why I have been trying to skirt the Free Software world, because I believe strongly in the four freedoms. When I’ve gone for “open source” jobs that aren’t really open source, I’ve always been disappointed (in one, the open source was kept very much at arms’ reach to avoid “accidentally” opening the core IP; in another, I took on the role of defining our open source strategy, getting the internal lawyers and other stakeholders on board, getting buy-in from the engineers…who then didn’t open source anything).

                                                      1. 6

                                                        Being aware of the positive outcomes my work generates has become key to enjoying it.

                                                        This is helpful for me, thanks.

                                                        1. 8

                                                          Honestly, it’s hard for me to imagine any other reliable way to enjoy work, other than enjoying the company of your co-workers.

                                                          You might get some fleeting enjoyment out of solving a particularly tricky logic puzzle at work, but in a healthy workplace there tend to be few opportunities to apply cleverness; people applying a lot of cleverness to their code on a regular basis is a sign of an unhealthy workplace.

                                                          1. 5

                                                            I get quite a bit of enjoyment from just solving the problems at hand in the most appropriate way. This is way more reliable for me than enjoying the company of coworkers! People come and go, have a bunch of opinions and habits, but GNU Emacs never lets me down.

                                                            1. 12

                                                              speaking of Emacs, I think there’s definitely something to be said for dotfiles hacking as a kind of “release valve” that allows you to express your cleverness in a way that doesn’t result in unmaintainable code for your teammates!

                                                              1. 1

                                                                I like that idea a lot actually.

                                                            2. 4

                                                              I live in the central US and I’ve met a lot of developers around here who are happy to grind away at an insurance company because it lets them provide their family with a level of comfort other jobs wouldn’t allow. The work itself doesn’t seem to give them a wholesome feeling, but being able to provide for their families does.

                                                              This feels related, but somewhat different from your point about the work itself being directly beneficial to society.

                                                        1. 1

                                                          u/SirCmpwn, do you see Moore’s law catching up with this at any point? If I have my math right that machine in a few years that machine will have two orders of magnitude fewer transistors than a new machine.

                                                          (I looked into it because I currently have an X201 serving as a ham radio logging machine with no problems)

                                                          1. 1

                                                            Moore’s law has been mostly dead in the consumer space for near a decade now. I’m not too concerned. It’s the extra features on new silicon that makes newer hardware attractive

                                                          1. 7

                                                            I’ll only speculate on the next half-decade (0-5 years).

                                                            Industry trends:

                                                            The tech bubble collapses. Interest rates change, some high-profile company collapses (my money is on one of Uber, Twitter, Tumblr, Facebook, Magic Leap, Coinbase), and investors suddenly realize that basic business economics actually matter again. In turn, portfolio companies are encourage to tigthen belts, and a surplus of nominally skilled workers drives wages down across the industry–and removes the tolerance for vanity projects on company time.

                                                            Mozilla and Firefox die. The mission creep of Mozilla as well as its dependence on ad revenue and search partnerships is going to kill it once the bubble collapses. Some useful things, like the MDN docs and possibly the Firefox codebase itself, are gonna survive through various forks. Rustlang probably survives through its community.

                                                            There is gonna be a massive drop in wages for programmers. Either while dealing with unions (explained below) or with visa stuff or a change in the type of work, we’re gonna see market forces make all of us poorer.

                                                            Language trends:

                                                            Rust fails to provide a compelling alternative to C, Go, or Haskell, but remains an existential threat to C++. Between the bubble collapse taking out the main source of funding for the Rust Evangelion Strike Force, the decrease in wages for programmers, and the fact that honestly most of the useful systems stuff is already implemented there just isn’t going to be a vibrant niche. Rustlang is going to be a source of continued exasperation for the true believers for decades to come, as were lisp and smalltalk before it.

                                                            JS is going to continue to be the dominant language in production around the world, despite a cancerous language spec and anemic standard library. The community continues to be full of perpetual novices, but the language strength for banging things together under budget and on a tight deadline cause it to continue to flourish.

                                                            Go continues to be a boring, mediocre, and utterly successful language used by people that need to get things done–it’ll probably make up most of the daily ops and ‘real work’ tooling we rely on. Not much to explain here, and its main sponsor (GOOG) isn’t likely to stop making payroll soon.

                                                            Elixir/Phoenix will supplant Ruby/Rails, and to a good extent frontend JS, and possibly show up as a major player in embedded systems. Not too much to say here…I don’t expect it’ll be vastly more popular than it is, I don’t think the web braindamage is completely set in yet, and I think people will just be quietly productive in it. You’ll see it a lot in contract work, but it’s not going to be a crazy huge deal. Those that know know, and those that don’t won’t.

                                                            Assembly will still be useful. The magical myth of a competent autovectorizing compiler will continue to evade language ecosystems that aren’t Fortran, C, or C++.

                                                            Formal methods will be a secret weapon, but not a useful one in most cases. With the collapse of the market, there will be even more emphasis on lean and sloppy engineering, and in the vast majority of domains the resulting lack of quality and correctness will be the market’s expressed preference.

                                                            Ops trends:

                                                            Containers/k8s will turn out to be a huge boondoggle outside of very specific usecases. The bubble forces developers to focus on their jobs instead of buzzword chasing, and all of the sudden the mundane solution of “run this locally and document your shit” becomes preferable to teams when compared with “pay for dedicated devops people, pay a hosting platform megabucks to babysit containers, add lots of overhead to solve problems that don’t exist in simple systems”.

                                                            BSD derivatives become the standard ops platform, because of Linux douchebaggery. This is a little more optimistic, but the renewed emphasis on careful systems administration mentioned previously suddenly mean that spinning up and shutting down machines and containers instead of actually maintaining them becomes a cost-ineffective choice. That, and the bazaar having become too bizarre in its offerings (systemd, etc.).

                                                            Monitoring remains mostly the same. Dashboards and automated alerting look basically the same they do now, especially as market contractions kill off really novel/weird business ideas that would create demand for something else.

                                                            Cultural trends:

                                                            We’re gonna see our first big ideological purge. My money is split on which project, but I think we’ll see the first big push to deplatform/remove/purge/destroy some integral group or BFDL. Further, I’m pretty sure that this is gonna come from the left. I wager it’ll take another few years to see if it cripples the project in question.

                                                            We’re gonna see increased work to make programmer guilds or unions. This will be fought tooth-and-nail by righties in tech, but it’ll happen. It will bring some definite benefits, but is going to hurt wages for a time while companies adjust. There’s gonna come a time where things come to a head and during a general strike we find out that, honestly, we’ve been living off of a really inefficient system and companies haven’t looked too hard.

                                                            We’re gonna see increased backlash from users as they realize just how much of their data we’ve been giving away. There will be show trials, some engineers are gonna be served up by the companies, and entire chunks of the industry are going to have a Very Bad Day when legislation finally catches up with them.

                                                            The pendulum is gonna swing back away from liberal/progressive policies. With the collapse of the bubble, keeping your job is going to be more important than tweeting your beliefs. Blacklists formed for unionbusting will be just as useful for getting rid of people who are outspoken about progressive things (and especially at first these lists will overlap a lot). Within the ranks of programmers, the follow-on from the purges will make people realize the existential threat of allowing certain folks in their projects, in turn having a chilling effect on otherwise healthy perspectives.


                                                            In my opinion, we all need to buckle up and get ready for a really rough ride.

                                                            1. 3

                                                              The tech bubble collapses. Interest rates change, some high-profile company collapses (my money is on one of Uber, Twitter, Tumblr, Facebook, Magic Leap, Coinbase), and investors suddenly realize that basic business economics actually matter again. In turn, portfolio companies are encourage to tighten belts, and a surplus of nominally skilled workers drives wages down across the industry–and removes the tolerance for vanity projects on company time.

                                                              I tentatively agree with this, and I wonder if some of it could possibly be driven by fines/legislation against big corps due to pressure from constituents for both privacy and voter manipulation reasons. As to which company… my current bet is on either Facebook or Amazon being forcibly split up. I could see also see Uber running out of gas (pun intended).

                                                              Aside: I don’t think Tumblr is even worth discussing though, as it was bought by Verizon as part of yahoo, and it appears they (verizon) are already trying their hardest to kill it.

                                                              1. 2

                                                                There is gonna be a massive drop in wages for programmers. Either while dealing with unions (explained below) or with visa stuff or a change in the type of work, we’re gonna see market forces make all of us poorer.

                                                                What kind of market forces could these be? I’m trying to think from the point of view of pure supply/demand. If there are enough people who need software to do their work better, the supply should remain fairly consistent, no? Of course, if the jobs that others are doing are in trouble (for whatever reason), that would directly mean programmers are in trouble. But curious what your chain of thought here is.

                                                                1. 4

                                                                  If companies that are paying outsize salaries to programmers cease to be viable due to market forces (a collapse in value of ad sales or something), then they’ll be forced to fire employees, leading to more programmers vying for the same job. So supply will outpace demands for jobs.

                                                                  Really tho, wages for programmers in the American tech sector are aberrantly high. It seems likely there will be a correction. Wages will stay high, but not astronomical. And that’s fine.

                                                                  1. 1

                                                                    If a massive employer like Accenture, IBM, or DXC goes belly up it’ll flood the market with 100’s of thousands of unemployed programmers, and the supply/demand ratio will change.

                                                                    1. 1

                                                                      But are there any market forces acting in the next 5-10 years that could make those big companies go out of business?

                                                                      1. 1

                                                                        Maybe? Enron, WorldCom, and Bear Stearns didn’t look like they were going out of business 5-10 years before they declared bankruptcy.

                                                                        1. 3

                                                                          “When the tide goes out, we’ll see who’s been swimming naked”.

                                                                  2. 1

                                                                    Christ, those cultural predictions are pessimistic friendlysock, and some of them are things I worry about myself. Do you have any idea about what practical steps “getting ready for a rough ride” might look like for the average programmer?

                                                                  1. 18

                                                                    What a curious article. Let’s start with the style, such as calling some of the (perceived) advantages of a monorepo a “lie”. Welp, guess I’m a liar 🤷‍ Good way to have a conversation, buddy. Based on this article I’d say that working at Lyft will be as much fun as working at Uber.

                                                                    Anyway, we take a deep breath and continue, and it seems that everything is just handwaved away.

                                                                    Our organisation has about 25 Go applications, supported by about 20 common dependency packages. For example, we have packages log, database, cache, etc. Rolling out updates to a dependency organisation-wide is hard, even for compatible changes. I need to update 25 apps, make PRs for 25 apps. It’s doable, but a lot of work. I expect that we’ll have 50 Go applications before the year is out.

                                                                    Monorepos exist exactly to solve problems like this. These problems are real, and can’t just be handwaved away. Yes, I can (and have) written tools to deal with this to some extent, but it’s hard to get this right, and in the end I’ve still got 25 PRs to juggle with. The author is correct that tooling for monorepos also needs to be written, but it seems to me that that tooling will be a lot simpler and easier to maintain (Go already does good caching of builds and tests out of the box, so we just have to deal with deploys). in particular, I find it’s very difficult to maintain any sense of “overview” of stuff because everything is scattered over 25 PRs.

                                                                    Note that the total size of our codebase isn’t even that large. It’s just distributed over dozens of repos.

                                                                    It’s still a difficult problem, and there is no “one size fits all” solution. If our organisation would still have just one product in Go (as we started out three years ago) then the current polyrepo approach would continue to suffice. It still worked mostly okay when we expanded to two and three products. But now that we’ve got five products (and probably more on the way in the future) it’s getting harder and harder to manage things. I can write increasingly more advanced tooling, but that’s not really something I’m looking forwards to.

                                                                    I’m not sure how to solve it yet; for us, I think the best solution will be to consolidate our 20 dependency packages in to a single one and consolidate all services of different applications in their own repo, so we’ll end up having 6 repos.

                                                                    Either way, the problems are real, and people who look towards monorepos aren’t all stupid or liars.

                                                                    1. 4

                                                                      I would imagine that if all you use is Go, and nothing much else, then I would image that you are in the monorepo “sweet spot” (especially if your repo size isn’t enormous). From what I understand, Go was more or less designed around the google internal monorepo workflow. At least until Go 1.10/1.11 or so (6 years? after Go 1.0).

                                                                      It makes me wonder…

                                                                      • Are there other languages that seem to make monorepo style repos easier?
                                                                      • Are monorepos harder/worse if you have many apps written in multiple disparate languages?
                                                                      1. 7

                                                                        Main issue with monorepos (imo) is that lots of existing tools assume you are not using them (eg: github webhooks, CI providers, VCS (support for partial worktrees), etc). Not an issue at google scale where such tools are managed (or built) in-house.

                                                                        1. 3

                                                                          This point isn’t made enough in the monorepo debate. The cost of a monorepo isn’t just the size of the checkout, it’s also all of the tooling you loose by using something non-standard. TFA mentioned some of it, but even things like git log become problematic.

                                                                          1. 2

                                                                            Is there a middleground that scopes the tooling better? What I mean is, keep your web app and related backend services in their monorepo assuming they aren’t built on drastically different platforms and you desire standardisation and alignment. Then keep your mobile apps in separate repos, unless you are using some cross-platform framework which permits a mobile monorepo. You get the benefits of the monorepo for what is possibly a growing set of services that need to refactored together while not cluttering git log et al with completely unrelated changes.

                                                                            1. 2

                                                                              Sort of. What really matters is whether you end up with a set of tools that work effectively. For small organizations, that means polyrepos, since you don’t often have to deal with cross-cutting concerns and you don’t want to build / self-host tools.

                                                                              Once you grow to be a large organization, you start frequently making changes which require release coordination, and you have budget to setup tools to meet your needs.

                                                                        2. 4

                                                                          Interesting, Go in my experience is one of the places I have seen the most extreme polyrepo/microservice setups. I helped a small shop of 2 devs with 50+ repos. One of the devs was a new hire…

                                                                        3. 0

                                                                          Rolling out updates to a dependency organisation-wide is hard, even for compatible changes. I need to update 25 apps, make PRs for 25 apps.

                                                                          What exactly is the concern here? Project ownership within an org? I fail to see how monorepo is different from having commit access to all the repos for everyone. PRs to upstream externally? Doesn’t make a difference either.

                                                                          1. 3

                                                                            The concern is that it’s time-consuming and clumsy to push updates. If I update e.g. the database package I will need to update that for 25 individual apps, and them create and merge 25 individual PRs.

                                                                            1. 3

                                                                              The monorepo helps with this issue, but it can also be a bit insidious. The dependency is a real one and it’s one that any updates to need to be tested. It’s easier to push the update to all 25 apps in a monorepo, but it also can tend to allow developers to make updates without making sure the changes are safe everywhere.

                                                                              Explicit dependencies with a single line update to each module file can be a forcing function for testing.

                                                                              1. 2

                                                                                but it also can tend to allow developers to make updates without making sure the changes are safe everywhere

                                                                                The Google solution is by pushing the checking of the safety of a change onto the team consuming it, not the one creating it.

                                                                                Changes are created using Rosie, and small commits created with a review from a best guess as to who owns the code. Some Rosie changes wait for all people to accept. Some don’t, and in general I’ve been seeing more of that. Rosie changes generally assume that if your tests pass, the change is safe. If a change is made and something got broke in your product, your unit tests needed to be better. If that break made it to staging, your integration tests needed to be better. If something got to production, you really have bigger problems.

                                                                                I generally like this solution. I have a very strong belief that during a refactor, it is not the responsibility of the refactor author to prove to you that it works for you. It’s up to you to prove that it doesn’t via your own testing. I think this applies equally to tiny changes in your own team up to gigantic monorepo changes.

                                                                              2. 1

                                                                                Assuming the update doesn’t contain breaking changes, shouldn’t this just happen in your CI/CD pipeline? And if it does introduce breaking changes, aren’t you going to need to update 25 individual apps anyway?

                                                                                1. 4

                                                                                  aren’t you going to need to update 25 individual apps anyway?

                                                                                  The breaking change could be a rename, or the addition of a parameter, or something small that doesn’t require careful modifications to 25 different applications. It might even be scriptable. Compare the effort of making said changes in one repo vs 25 repos and making a PR for each such change.

                                                                                  Now, maybe this just changes the threshold at which you make breaking changes, since the cost of fixing downstream is high. But there are trade offs there too.

                                                                                  I truthfully don’t understand why we’re trying to wave away the difference in the effort required to make 25 PRs vs 1 PR. Frankly, in the way I conceptualize it, you’d be lucky if you even knew that 25 PRs were all you needed. Unless you have good tooling to tell you who all your downstream consumers are, that might not be the case at all!

                                                                                  1. 1

                                                                                    Here’s the thing: I shouldn’t need to know that there are 25PRs that have to be sent, or even 25 apps that need to be updated. That’s a dependency management problem, and that lives in my CI/CD pipeline. Each dependent should know which version(s) it can accept. If I make any breaking changes, I should make sure I alter the versioning in such a way that older dependents don’t try and use the new version. If I need them to use my new version, then I have to explicitly deprecate it.

                                                                                    I’ve worked in monorepos with multiple dependents all linking back to a single dependency, and marshalling the requirements of each of those dependents with the lifecycle of the dependency was just hell on Earth. If I’m working on the dependency, I don’t want to be responsible for the dependents at the same time. I should be able to mutate each on totally independent cycles. Changes in one shouldn’t ever require changes in the other, unless I’m explicitly deprecating the version of the dependency one dependent needs.

                                                                                    I don’t think VCS is the right place to do dependency management.

                                                                                    1. 3

                                                                                      Round and round we go. You’ve just traded one problem for another. Instead of 25 repos needing to be updated, you now might have 25 repos using completely different versions of your internal libraries.

                                                                                      I don’t want to be responsible for the dependents at the same time.

                                                                                      I mean, this is exactly the benefit of monorepos. If that doesn’t help your workflow, then monorepos ain’t gunna fly. One example where I know this doesn’t work is in a very decentralized ecosystem, like FOSS.

                                                                                      If you aren’t responsible for your dependents, then someone else will be. Five breaking changes and six months later, I feel bad for the poor sap that needs to go through the code migration to address each of the five breaking changes that you’ve now completely forgotten about just to add a new feature to that dependency. I mean sure, if that’s what your organization requires (like FOSS does), then you have to suck it up and do it. Otherwise, no, I don’t actually want to apply dependency management to every little thing.

                                                                                      Your complaints about conflating VCS and dependency management ring hollow to me.

                                                                                      1. 1

                                                                                        I mean, again, this arises from personal experience: I’ve worked on a codebase where a dependency was linked via source control. It was an absolute nightmare, and based on that experience, I reached this conclusion: dependencies are their own product.

                                                                                        I don’t think this is adding “dependency management to every little thing”, because dependency management is like CI: it’s a thing you should be doing all the time! It’s not part of the individual products, it’s part of the process. Running a self-hosted dependency resolver is like running a self-hosted build server.

                                                                                        And yes, different products might be using different versions of your libraries. Ideally, nobody pinned to a specific minor release. That’s an anti-pattern. Ideally, you carefully version known breaking changes. Ideally, your CI suite is robust enough that regressions never make it into production. I just don’t see how different versions of your library being in use is a problem. Why on Earth would I want to go to every product that uses the library and update it, excepting show-stopping, production-critical bugs? If it’s just features and performance, there’s no point. Let them use the old version.

                                                                                        1. 2

                                                                                          You didn’t really respond to this point:

                                                                                          Five breaking changes and six months later, I feel bad for the poor sap that needs to go through the code migration to address each of the five breaking changes that you’ve now completely forgotten about just to add a new feature to that dependency.

                                                                                          You ask why it’s a problem to have a bunch of different copies of your internal libraries everywhere? Because it’s legacy code. At some point, someone will have to migrate its dependents when you add a new feature. But the point at which that happens can be delayed indefinitely until the very moment at which it is required to happen. But at that point, the library may have already gone through 3 refactorings and several breaking changes. Instead of front-loading the migration of dependents as that happens by the person making the changes, you now effectively have dependents using legacy code. Subsequent updates to those dependents now potentially fall on the shoulders of someone else, and it introduces surprise yak shaves. That someone else then needs to go through and apply a migration to their code if they want to use an updated version of the library that has seen several breaking changes. That person then needs to understand the breaking changes and apply them to their dependent. If all goes well, maybe this is a painless process. But what if the migration in the library resulted in reduced functionality? Or if the API made something impossible that you were relying on? It’s a classic example of someone not understanding all of the use cases of their library and accidentally removing functionality from users of their library. Happens all the time. Now that person who is trying to use your new code needs to go and talk to you to figure out whether the library can be modified to support original functionality. You stare at them blankly for several seconds as you try to recall what it is you did 6 months ago and what motivated it. But all of that would have been avoided if you were forced to go fix the dependent in the first place.

                                                                                          Like I said, your situation might require one to do this. As I said above, which you seem to have completely ignored, FOSS is one such example of this. It’s decentralized, so you can’t realistically fix all dependents. It’s not feasible. But in a closed ecosystem inside a monorepo, your build doesn’t pass unless all dependents are fixed. Everything moves forward, code migrations are front loaded and nobody needs to spend any time being surprised by a necessary code migration.

                                                                                          I experience both of these approaches to development. With a monorepo at work and lots of participation in FOSS. In the FOSS world, the above happens all the time exactly because we have a decentralized system of libraries that are each individually versioned, all supported by semver. It’s a great thing, but it’s super costly, yet necessary.

                                                                                          Dependency management with explicit versioning is a wonderful tool, but it is costly to assign versions to things. Sometimes it’s required. If so, then great, do it. But it is most certainly not something that you “just do” like you do CI. Versioning requires some judgment about the proper granularity at which you apply it. Do you apply it to every single module? Every package? Just third party dependencies? You must have varying answers to these and there must be some process you follow that says when something should be independently versioned. All I’m saying is that if you can get away with it, it’s cheaper to make that granularity as coarse as possible.

                                                                          1. 6

                                                                            Writing fast code will be actually be pointless.

                                                                            What got me thinking about this is this: My webserver is probably the fastest HTTP/1.1 implementation that is possible - there’s nothing to remove, it’s 100 or so lines of code, and seriously: I’d love to see anything someone thinks is faster.

                                                                            The next fastest, is within a few percent though. The next fastest is thousands of lines of code; they’re doing much more than 10x more work than me - they have more branch mis-predictions, they can spill L1. None of it seems to matter anymore.

                                                                            That means our modern CPUs are so quick they can do at least 10x more work, throw it away, and still get the packet out to a 1Gb network interface in time for the network buffer to flush (or a disk buffer, or any other kind of IO). When the new 7nm process popularises I expect the gap will be gone entirely, and that’s just a few years away.

                                                                            We’ve got 10Gb adapters though, that’ll push things back maybe as long as a decade. Hopefully we’ll get those 100Gb adapters before then…

                                                                            1. 3

                                                                              “I’d love to see anything someone thinks is faster.”

                                                                              One idea I saw in an embedded server was pre-converting the web pages into TCP packets that just get fired off directly. I cant remember if I tried or timed that. Might want to experiment with caching TCP packets generated on startup for all content or first request for Might be hardware versions of this concept with RDMA or something.

                                                                              1. 3

                                                                                Xok exokernel from MIT. File system block size was aligned and offset so you could basically mmap a file and splat it into packets.

                                                                                1. 1

                                                                                  That’s clever. Thanks for the tip.

                                                                              2. 2

                                                                                I think this is only one facet of a bigger change. I think “programming” will no longer be seen as one monolithic pursuit. Fast code will continue to be extremely important for some activities, e.g. gaming, trading, simulations.

                                                                                1. 2

                                                                                  With CPU performance increasing at a snail’s pace, writing fast and efficient software might become an important feature again.

                                                                                2. 1

                                                                                  My webserver is probably the fastest HTTP/1.1 implementation that is possible - there’s nothing to remove, it’s 100 or so lines of code, and seriously: I’d love to see anything someone thinks is faster.

                                                                                  I would love to see a webserver in K ;)

                                                                                  1. 2

                                                                                    We’d need sockets for K first :)

                                                                                1. 17

                                                                                  I expect the AI hype bubble to burst, and self-driving car projects to be mothballed as being impractical and too expensive.

                                                                                  1. 4

                                                                                    The self-driving car thing has a long tail. Getting a self-driving car to 98% capability is “easy”, but I think the last 2% (without which the project is useless) is still decades away.

                                                                                    1. 6

                                                                                      I guess it depends on what the last 2% is, but I don’t think they’re useless without every single thing working perfectly? Perhaps they wouldn’t be suitable for sale to the general public as go-anywhere vehicles (which is certainly what I want!) but I can imagine that you might be able to use them in limited cases as fleets of taxis, geo-gated into only the areas they’re capable of working reliably in. Or perhaps for long-haul trucking - autonomous on the interstate, driver required for city roads and for parking.

                                                                                      1. 7

                                                                                        I do see self-driving long-haul trucking coming in the next decade, perhaps with a human-operated lead truck and definitely with a remote operator somewhere that can give instructions to a truck that gets itself into a situation it doesn’t know how to handle (e.g. it pulls over because its GPS map doesn’t match up with what it’s seeing on the ground).

                                                                                        The final 2% are things like handling an ambulance behind you with its lights on, roads without painted lanes or with soft shoulders, roads that are closed, lanes that are diverted, etc.

                                                                                        The final-final 0.5% is handling special instructions. What does a self-driving car do if there’s a police officer in the middle of the road directing traffic? A light-up sign that says “all traffic left-lane?” A “bridge out ahead!” sign, etc?

                                                                                        1. 3

                                                                                          It’s already seeing production adoption in mining and agriculture, especially in dangerous areas that have OSHA limits on how long someone can drive. John Deere and Caterpillar have been working on this for a long time.

                                                                                        2. 1

                                                                                          A 98% solution would be far from useless, if it leads to a better safety record.

                                                                                          The places where automated driving could improve safety (fast response to emergencies, warnings of dangerous traffic conditions) are separate from places where automation is likely to break down (communication between drivers in complex traffic interactions.)

                                                                                          1. 1

                                                                                            Id use it like Google Maps uses it. It drives in a situation computer can handle. If not, I drive. Hell, just letting it do highways and Interstates for long hauls while I chill would be great.

                                                                                          2. 3

                                                                                            If you have a 98% solution, you could deploy it to a limited region where it is a 100% solution. For example, Voyage deploying to The Villages, FL.

                                                                                            1. 2

                                                                                              Exactly! How much time and money are people willing to dunk in this bottomless pit? At some point it should dawn on people in the industry that this simply isn’t cost-effective.

                                                                                          1. 6

                                                                                            What do they mean by “microVM”? The marketing docs are pretty short of details about this and googling returns links about programming language VMs.

                                                                                            1. 27

                                                                                              A microVM is similar to a VM but does not boot firmware (UEFI or BIOS) and uses a much smaller device model (the virtualized devices available to the VM). Otherwise a microVM provides all the same containment features of a VM. In the case of Firecracker there are only 4 emulated devices: virtio-net, virtio-block, serial console, and a 1-button keyboard controller used only to stop the microVM. Also the kernel is started by executing Linux as an elf64 executable, not bootstrapped by firmware.

                                                                                              1. 2

                                                                                                Thank you! That helps clear things up.

                                                                                            1. 8

                                                                                              I think the article is good but it over looks a big factor that sets go apart from rust. To phrase it as a joke:

                                                                                              I’ve loved every programming language I’ve tried before I’ve used it in production.

                                                                                              A more thorough explanation starts with Google offering full time production usage to a large number of developers who subsequently churned into other startups. Go has some rough edges, but it’s core is easy to pick up. This means a single expert on a team can get several other developers productive within a few weeks. You just need one person to catch the gotchas, explain the idioms, and guide the general structure of the project.

                                                                                              So while I think the article describes a small flame of interest, there was a giant company pouring millions of dollars in gasoline onto the the fire. Mozilla is great for supporting the development of Rust, but they don’t have the money to subsidize it’s commercial adoption. While I’d love for a language’s intrinsic properties to drive it’s success, the environment they are released into plays an out sized role.

                                                                                              edit : For the past few months I’ve played with rust and love the language, I really hope it’s usage becomes more widespread. Until Rust has a wealthy benefactor churning out experienced developers who get hired for their ops/python/ML/etc. experience and then those developers start introducing the language to production environments, it’s adoption will be slower than any of us want.

                                                                                              1. 2

                                                                                                Near universities when the students are gone, e.g. summer or major holidays, I’ve found coffee shops and restaurants happy to have a patron. Because it’s a short time frame it forces me to change pace more frequently than I naturally would.

                                                                                                1. 10

                                                                                                  I love working from libraries. A handful of the San Francisco public libraries are perfect quiet spots – the one up on Potrero Hill even has an incredible view! Something about being in a quiet place where everyone is working helps me focus.

                                                                                                  1. 3

                                                                                                    You work remotely and still choose to pay San Francisco rents? You’re an absolute mad-person.

                                                                                                    The day I get a remote job I’m fucking gone.

                                                                                                    1. 2

                                                                                                      Kind of – I consulted for a couple years, so being in SF was great in terms of meeting clients and such. Now I’m back on the full-time grind. One day I’ll escape.

                                                                                                      1. 2

                                                                                                        That tracks a lot better with what I’d expect haha. Cheers to that :)

                                                                                                    2. 2

                                                                                                      I second libraries! Our local public libraries have a cafe in an isolated place that’s set up for conversations but also works great if you have to take a quick meeting without disturbing the rest of the library.