1. 3

    In retrospect it’s kind of amazing how quickly we moved from an Internet with no “like” counts (the golden age of blogging) to an Internet where it’s very difficult to find any community where “like” counts or upvotes are not a core part of the system. Even indie sites like Lobste.rs or Metafilter that eschew a lot of the apparatus of the modern Internet incorporate this very quantitative approach to community and social interaction.

    1. 2

      Yes. The quieter, less-evaluative Internet was hijacked by one of addictive narcissism.

      1. 2

        After writing my earlier comment I realized that there is one type of online community I participate in that is completely free of likes/voting/ranking/quantitative anything: mailing lists.

        It’s probably not a coincidence that I love mailing lists, while people whose Internet experience started even a few years later than mine did seem to really, really hate them. I wonder if there is a real generational (or internet-generational) divide here, or if I’m just an outlier.

        1. 2

          It’s probably not a coincidence that I love mailing lists, while people whose Internet experience started even a few years later than mine did seem to really, really hate them. I wonder if there is a real generational (or internet- generational) divide here, or if I’m just an outlier.

          As a guy who first acquired an ISP in 1993, I can honestly say that I generally dislike mailing lists (like most people, I guess). I always think of them as a poor-man’s usenet, I would much rather just hop on tin(1) and read the latest posts in my subscribed groups.

          Having said that, I am a member of some mailing lists that I genuinely enjoy. Though they are the exception, not the rule…

        2. 1

          It would be interesting to see an implementation of an upvote button that didn’t display the count to the users. You still get the “community” aspect of it, without the narcissistic side.

          1. 1

            HN does this.

            1. 2

              Right! For the comments. They still show the points for each story, which I think makes sense (or does it…?)

          2. 1

            Back then we had guestbooks and hit counters to provide the tingle of popularity that is oh so addictive.

            I remember when I first added commenting to my blog and getting ten or so meaningfull comments within the first week of publishing a new post was a thrill to see; those were different to likes though, because they were actual meaningful interactions that often spawned discussion.

          1. 5

            I feel lucky to work in the Clojure ecosystem where edn is ubiquitous. It behaves predictably and supports the features I need.

            In a previous job I found myself sometimes hand-editing YAML CloudFormation templates. What a nightmare that was.

            1. 25

              With respect to email, don’t forget that pull requests were once intimidating too - as anyone who frequently works with onboarding new developers to its workflow can attest. To help make onboarding users with email easier, I wrote this tutorial:

              https://git-send-email.io

              I also wrote a rebase guide which applies to both workflows for making your changes more consistent and easier to review:

              https://git-rebase.io

              1. 26

                https://git-send-email.io

                That nicely outlines how to send patches, but I think people have far more difficulty receiving patches via email. Not everyone uses mutt, aerc, or runs a patchwork instance. Many mail clients, that people are otherwise generally fairly happy using, are just super not great at handling emailed patches. Emailed patches also generally don’t show a CI status that you can view ahead of time (I have heard of some, but I don’t ever remember seeing it firsthand in the wild).

                It’s great that it (an email patch workflow) works well with your workflows and tooling, but for some people it just… doesn’t work as well.

                1. 4

                  I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion. And testing your patches against SourceHut CI is pretty easy, before or after it’s sent.

                  1. 26

                    I think one issue is that for most of us, sending and receiving patches is a very small part of what we do with email, so choosing a mail client on that basis doesn’t make sense.

                    1. 1

                      But we aren’t forced to use only one mail client. I use several depending on context / the task at hand.

                      1. 1

                        I am curious about your multiclient workflow. Do you use multiple addresses, or use filters and one shared address? Or just all the mail in all of them?

                        1. 4

                          Whether you use local maildir or imap, mail stores are designed for concurrent access. How many people check email on their phone and not their phone?

                          1. 1

                            Sure, but my question was specifically about their workflow with it.

                          2. 2

                            As it happens I do use multiple accounts for multiple “hats”, but that’s slightly orthogonal to multiple clients, which I use even for a single account. My daily driver is mutt; I use thunderbird for rare occasions when I need to see rendered html properly or perform a search (still haven’t got mairix or not much etc set up) and I often use ios mail app but mostly read only.

                            At work we use Gmail. I do check that from ios mail app too. I recently started configuring mutt to read my work mail too but it’s a work in progress so I still regularly open the Gmail website.

                      2. 23

                        I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion.

                        To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.
                        Well…maybe.. I do find it unlikely that is going to convince very many people who weren’t already riding them, or weren’t already inclined to do so. Even if it is amazing.

                        Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find that oddly humorous.

                        Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                        1. 7

                          To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.

                          I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                          Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find the humorous.

                          Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                          Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                          That’s why Sourcehut can do it for you.

                          1. 9

                            I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                            A bit of an “Ipse dixit”, but I’ll take it at face value anyway. To be clear, my comment was in response to your statement:

                            I mean, those people who don’t have such a mail client are missing out.

                            Which is what I made the comparison against. You have now pulled in other concerns in your response, and attributed them to the comment I made. I find that a bit uncharitable. I guess at this point we can just agree to disagree.

                            Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                            That’s odd. I looked through the last 2 months of their mutt-dev mailing list, and saw no mailed patches, but several gitlab PRs. Maybe I saw the wrong mailing list? Maybe I didn’t go back far enough? Overlooked it?
                            It doesn’t really matter, and I’ll take your word for it that they predominantly use emailed patches.

                            1. 2

                              The last 2 months have only seen one patch on Gitlab:

                              https://gitlab.com/muttmua/mutt/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

                              After reviewing it myself I have to correct myself, I reckon that Gitlab and the mailing lists are at about an even pace these days.

                              1. 2

                                Do note: that was merged PRs. There were a couple of more (not many though!) in All which is what I looked at.

                        2. 5

                          Not everyone is productive using such mail client. Personally, I just plainly cannot remember more than a few shortcuts, which is already a massive roadblock for effectively using CLI tools as for most of them rely on shortcuts to increase productivity, they also do not provide me with options of what I can do, and I cannot for my life remember what can I do for all the possible contexts, cause of course options on what you can do are dependent on the context which you are currently in. Some people just aren’t productive using CLI tools, and saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                          1. 3

                            saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                            This is absurd. If a mechanic decides that he “is not a ratchet person” and will only ever use open-end wrenches, then I will question his professionalism just as I would question a software developer that “is not a CLI person” and will not learn to use a CLI mail client.

                            He doesn’t need to use the CLI mail client for his day-to-day email, but he should be capable of learning how to use it to handle the occasional emailed patches.

                            1. 5

                              Or this person will work with whatever, when paid for (professionals are paid for their work by definition!), but will only work with tools he/she finds enjoyable when doing charity. Thus FLOSS projects forcing inconvenient, last century methods with arrogant communication are missing contribution.

                              I thing the FLOSS community should focus on this kind of openness more, instead of CoCs.

                              1. 3

                                Good point. For work I’ll use whatever tools get the job done, no matter how gruesome. But for FOSS contributions, I agree that if the tool is difficult or simply frustrating to use, then it may as well not exist.

                              2. 1

                                Wrong assumption. Difference between using GUI and CLI clients is not like between open-end and ratcheted wrenches. Using those wrenches is basically the same. Meanwhile the experience between using CLI and GUI mail client is a lot bigger. I’d compare it to using automatic and manual wood planes. You can work with higher precision and similar speed with manual hand plane, but most carpenters would choose automatic hand plane, as it “just works” and doesn’t require that much skill and learning to do.

                                And why should you care what kind of wrench does your car mechanic uses, if he does the job well? This isn’t a problem not using better tools, but a problem of tool abilities. The tools that an average developer uses does not represent the tools that are created for that workflow. And that is a problem.

                                1. 2

                                  I’ll entertain the analogy to a wood plane, though I’m unfamiliar with the devices. You say it yourself: the manual wood plane is useful in certain circumstances but requires skill. So does the CLI mail client. Use the automatic wood plane where it fits, but at least learn the skill to use the manual wood plane where the higher precision is necessary.

                                  A developer that refuses to acquire a skill is simply not professional.

                                  1. 1

                                    It’s not like it requires much skill. It is the basically the same skill. The difference is, you need to move the manual wood plane along the plank 10 times, while with automatic you only need to move it once and the motor does its job. Some people just don’t have the patience and/or physical stamina to use manual wood plane. Manual hand plane is in fact more configurable, and can be used in more specialized scenarios. So enthusiasts use hand planes. Your average carpenter does not.

                                    1. 2

                                      The analogy was not mine.

                              3. 0

                                Consider acme?

                                1. 2

                                  I am unable to find such email client. And the point is, for a workflow to be usable by a wide range of people, it should require as little new tools that do the same as the ones they use. And in case of email clients, most people probably like their current email client, and they do not want to change it. So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                  1. 4

                                    acme is a text editor which can be easily coaxed into being a mail client.

                                    Consider as well that you needn’t discard your daily mail client in order to adopt another. What difference does it make if some technology is backed by email or by some other protocol? Just because you already have an HTTP client (e.g. your web browser) doesn’t mean another isn’t useful (e.g. curl).

                                    1. 7

                                      Acme does not seem like general user friendly. My colleagues all use JetBrains IDE’s and use Thunderbird as their mail client. And acme would be a downgrade for their experience. I might use it, but they wouldn’t. If I cannot offer them a good GUI email interface, there is no way they would switch to email-based workflow.

                                      1. 0

                                        I was recommending acme particularly for you, given the following:

                                        I just plainly cannot remember more than a few shortcuts

                                        If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software. A bicycle is easier to use than a car but it’s not going to get you to the other end of town in time for the movie.

                                        1. 14

                                          If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software.

                                          Don’t you think peace within a team is more important than any particular software or workflow? Or, to put it another way, the feelings of people are more important than any workflow, so if a large group of people reject a workflow, it’s better to conclude that the workflow is wrong for those people than to say that those people are wrong.

                                          1. 7

                                            My colleagues wouldn’t join me because the workflow is bad, but because there is no tooling suitable for them and the workflow. If tooling for a specific workflow just isn’t comfortable for me, I’m just not going to use it.

                                            1. -8

                                              Then you ought to be coding in basic. Good things often require effort.

                                              Edit: this comment seems to be being misinterpreted, so a clarification: I’m not earnestly suggesting that he should use basic. I’m extending his logic to an incorrect conclusion to demonstrate the flaw in his argument. Most languages are harder than Basic, therefore Basic is more comfortable, therefore why ever learn anything else? Obviously it doesn’t make sense.

                                              1. 18

                                                You are literally making the exact same argument that @ignaloidas’ colleagues are. The only difference is that the tooling you find suitable and the tooling they find suitable is a null set. They want to be in JetBrains’ IDEs, you want to be in email. You built tooling that demands email-based workflow because it’s what you want and then tell them they have to change; they’ve got tooling that demands GitHub (or a workalike) and then tell their colleagues that they have to change.

                                                As an aside, I pay for and generally enjoy using Sourcehut, and I respect your diehard allegiance to email, but you’ve got to quit acting like this in the threads. I get that you love an email-based workflow, and find it superior for your use cases. Having used Git and Mercurial since, what, early 2006 I guess—certainly before GitHub and Bitbucket existed—I disagree (especially when your workflow starts to involve binary assets, so most websites, games, mobile apps, and so on), but I’m also comfy in that workflow, and happy to support an SCM that fully supports that flow. But if you insist that people who do not use your workflow are wrong, and do so in this offensive manner, you’re going to start losing customers.

                                                And as an aside to that aside, you need to do what you want with Sourcehut, but the fighting against this on principles to me, as a former SCM lead, looks a bit forced: looking at this whole thread, and thinking back to a very early comment, all you’d have to do to satisfy him is to make temporary branch names that can be pulled in some mechanism based on the patch series. That’s it. It’s not trivial, but it’s also not that difficult, since you’re already doing 90% of that with the patch view. If you don’t want to do it, that’s fine, but it seems like that’d still mandate patch-accessible workflows, while also meeting the PR crowd a bit.

                                                1. 2

                                                  Note about the JetBrains’ IDEs. It’s not like they are incompatible with with email driven workflow, they just have tools that are better suited for pull-request workflow. I gave JetBrains IDEs as an example of what an “average” developer as I know it uses from day to day, as it seems that many bloggers have a distorted view of “average” developer. Average developer actually doesn’t want to fiddle with settings and try 10 different variants before deciding to use one. They want tools that “just work” without massive setup. Average carpenter wants a table saw that simply does the job they want to, they do not fiddle around it to make it the best saw for them.

                                                2. 14

                                                  Hi this is not a very nice tone, please try to argue in good faith.

                                                  1. 13

                                                    Is insulting prospective customers really the best way to grow your business?

                                                    1. 0

                                                      That was no insult, it was a logical extension of his logic. I didn’t mean it sincerely, I was using it to explain his error.

                                                    2. 2

                                                      Ok, in simpler terms. I would probably still use an SUV instead of Smart even if Smart can go through some shorter paths, because I feel cramped when driving it. Same with software. Some software is in fact more useful than other, but is harder/inconvenient to use for some than software which doesn’t have those fancy features.

                                                      1. -5

                                                        This isn’t such a case. This is a case where you (or your colleagues, I’m not sure at this point) are refusing to try unfamiliar things and, being ignorant of the experience, asserting it’s worse.

                                                        1. 3

                                                          It is. The thing is, I have tried mutt and aerc, and the problem is that I just plainly am not comfortable using bigger CLI programs, that is, those, whose scope goes out of pipes and command line rguments. About the only programs that of such style that I can use is nano and htop, only because they have a handy shortcut guide in the bottom at all times. Acme is also not the kind of editor I would like to use casually. It is easy to blame the people that don’t use it, without understanding the reasons why they don’t use it.

                                                          1. 0

                                                            You didn’t know anything of acme not even 2 hours ago. You’ve evaluated it in that time?

                                                            Herein lies my point. I have a vision and I must at some point exercise my creative authority over the project to secure that vision. Yes, it’s different from what you’re used to. You can construct reasons to excuse this away, but I fundamentally believe that being unwilling to learn something new is the underlying problem. As evidence, I submit that there’s no way you could have given acme a fair evaluation since my suggestion of it. I don’t consider this sort of behavior acceptable cause for changing my system’s design to accomodate.

                                                            1. 12

                                                              As someone who used Acme for two years, @ignaloidas does not sound like someone for whom Acme would even be worth trying. It’s great, but incredibly dependent on how you want to use your editor. You can’t disable word wrap, or use any shortcut to move the cursor down a column, for Christ’s sake. It’s really not for everybody (perhaps not even most people).

                                            2. 2

                                              So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                              What happened to using the right tool for the job?

                                              1. 1

                                                The question here is not about “the right tool for the job” but about the usability of those tools for the wider audience. Currently I do not see the majority of the developers switching to email-based workflow purely because of the usability of tools. “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                1. 3

                                                  “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                  Good to know that we were all rockstars for decades without realizing it!

                                                  This is probably just an age thing but I don’t know any professional programmers who aren’t comfortable with CLIs.

                                                  1. 3

                                                    There is CLI, and there is CLI application. Git is used through CLI. Vim is a CLI application. Surely you know at least one professional programmer that isn’t comfortable with Vim and alike.

                                        2. 3

                                          I am not particularly experienced at using git with email. One problem I have had in the past is when I want to pull in a patchset from a mailinglist archive, where either I am not subscribed to the mailinglist, or wasn’t subscribed at the time when the patches were sent. Can these mail clients help me with this problem? (By contrast, I find it very easy to add a branch / PR as a remote and pull or cherry-pick commits that way)

                                          1. 3

                                            lists.sr.ht, the sourcehut web archive for mailing lists, has a little copy+paste command line thing you can use to import any patch (or patchset) into your local git repo. Here’s an example:

                                            https://lists.sr.ht/~sircmpwn/aerc/patches/7471

                                            On the right, expand the “how do I use this” box and a short command is given there.

                                            Integration directly with your mail client would require more development but isn’t necessarily out of the question.

                                            1. 3

                                              That’s good to see, but presumably doesn’t help for non-sourcehut mailinglists?

                                              1. 3

                                                No, I’m afraid that there are fewer good solutions for non-sourcehut mailing lists. Patchworks has a similar feature, if the list in question has that set up. You could also ask someone else for a copy of the mail. I don’t think this damns the idea, it just shows that we need better software to support the idea - which is what sourcehut tries to be.

                                      2. 2

                                        I am still trying to find some time to check out Sourcehut. My only concern is how to configure it to run CI builds on mailing list patches as I couldn’t find it anywhere in the docs.

                                        1. 1

                                          This hasn’t been implemented yet, but it will be soon.

                                          1. 1

                                            Great. If that happens I will think about migrating some of my personal projects to the Sourcehut as it seems pretty as a pretty nice solution.

                                      1. 1

                                        As another programmer without a degree I really like seeing this documented. Thank you!

                                        1. 4

                                          I’m sorry this happened (and is happening) to you. It’s clear that you did the right thing here.

                                          1. 1

                                            If you’re interested in this kind of thing you should check out Clara, a Rete-algorithm-based forward-chaining rules engine written in Clojure (so you get that nice S-expression syntax). Anecdotally, it seems like rules engines are having a bit of a resurgence as the healthcare software industry heats up. In my experience Clara is a pretty good fit for capturing the kinds of really baroque business (or clinical) logic that is often required in the healthcare space.

                                            1. 2

                                              The author of this post is famous but doesn’t get how things work. This is his argument…

                                              Tl/DR:

                                              • companies go public later, doing more later stage funding rounds.
                                              • founders have more control nowadays since VCs started to realize that founders outperform external CEOs
                                              • being a founder is less risky (not clear why this would be the case, yes, funding rounds went up, but so did the early expenses of starting a company)
                                              • founders have more upside than employees (he pulls a number from thin air, 30-50 times)

                                              There is so much in this post that I don’t agree with that it’s hard to know where to start. First of all, founders having more control is a good thing for employees. Founder stock is very close to the deal employees are getting. At the very least it’s better aligned with employees than investor stock. (down round protection is almost always built-in to investor stock). Also the founders work with the employees on a day to day basis. Making them on average less likely to screw over the employees. (seriously does anyone believe that the VCs care more about you than the founders? have a look at what happened to Travis)

                                              The opportunity cost of being a founder has only gone up. The reason is that nowadays you can get crazy high engineering or management salaries at big tech companies.

                                              I can only speak from my own experience. Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                              The main thing I don’t agree with is the general sentiment of the post. Supply and demand for engineering talent have been more and more in favor of engineers over the last 10 years. Salaries are going up, perks are going up, work life balance is becoming more chill. I have a friend who joined 4 startups and sold his stock 4 times. He can pay his house in cash these days. No other industry has these amazing jobs.

                                              The one thing that does really need to change is taxation on stock options. That system is obviously a bit broken at the moment.

                                              What I think is really going on here is that Steve Blank is low on traffic for his blog and decided to write some hipster sounding controversial blogpost.

                                              1. 10

                                                I have to disagree with you on a number of your points.

                                                First of all, founders having more control is a good thing for employees.

                                                This is highly situation dependent–if the founder has experience and values their employees, it’s a great thing. If a founder is young and doesn’t understand the career trajectory of engineers (or other people trying to raise a family), this can be bad. If the founder, as a purely random example, comes from a privileged background and tries to treat their employees like pieces of factory machinery, it’s terrible.

                                                Founder stock is very close to the deal employees are getting. At the very least it’s better aligned with employees than investor stock.

                                                Founder stock grants are quite often orders of magnitude larger than that for their employees, they have inside information about how the financing and fundraising is going, they have direct control over those aspects in ways their employees do not, and that’s before you even get into the options, voting stock, and other differences Blank touches on.

                                                I’ve seen a CTO (who is legally liable for the company’s behavior as an executive!) be grudgingly given less than a point share in the business, because of stingy founders! Us poor grunts who build the products have no hope in such cases.

                                                Also the founders work with the employees on a day to day basis.

                                                The company I was just let go from had a founder that talked to me a total of like 5 times in the last year and a half, the final time gaslighting me about who had me fired. The previous health IT company I was at, the tech cofounder kept their day job and seagull managed the rest of us, and the biz cofounder/CEO usually was holed up in their office and popped out to ask for asinine product tweaks and failed to make sales and raise investment.

                                                This is a highly-variable thing.

                                                Making them on average less likely to screw over the employees.

                                                VCs are there to make money, if it means sharing with employees they’ll do that. Founders are there, in my observation, to boost their own egos–and even if you write most of their product, their own arrogance will prevent them from ever giving you similar compensation, because you once took a paycheck from them and somehow that makes you not as worthy…even if the paycheck was backed by other people’s money. If it’s backed by their money, God help you.

                                                The opportunity cost of being a founder has only gone up. The reason is that nowadays you can get crazy high engineering or management salaries at big tech companies.

                                                That applies double for early employees, right? At least founders get to network with the investing class and can put “I founded ” on their resume and go on podcasts and shit–early employees are usually hired because they’re more qualified than the founders (by definition…if they weren’t, they probably wouldn’t be hired) and they are paid very much below market rates.

                                                Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                                Are you one of the founders? Can you throw out some numbers?

                                                I have a friend who joined 4 startups and sold his stock 4 times.

                                                I’ve worked at least four startups (two as senior FTE, one as cofounder, others as contracted engineering talent), and only now might have stock from one of them. Last one the founder got really weird when I talked about exercising my options to see our finances. Good for your friend, but equity is basically a joke on par with exposure now.

                                                No other industry has these amazing jobs.

                                                You might be surprised at the perks and job security offered by other white-collar fields. Engineering, once you have a PE, is relaxed as hell by all accounts. If these jobs are so great, why do we mostly only see dumb young men signing up for them?

                                                ~

                                                Like, I get it–in magical little pockets of reality that still mirror the 90s, being a startup early engineer is great. For most of us, though, we’re getting shafted compared to the value we add.

                                                1. 1

                                                  Sorry to hear that, doesn’t sound like a great environment. As an engineer you can be quite picky where you work. I’ve made this mistake in the past as well, staying too long somewhere were the culture/environment isn’t right. Did you find a good opportunity eventually?

                                                2. 1

                                                  I have a friend who joined 4 startups and sold his stock 4 times.

                                                  When did this happen? His whole argument is that options used to be a good deal, but no longer are. Examples from ten years ago don’t disprove that thesis, which is in accord with my experience. Yes, it’s a good time to be an engineer, but only because salaries are high. None of the equity I’ve notionally had at several startups has ever been worth even enough to buy a coffee in actual exchange value.

                                                  Maybe we’re particularly generous, but the difference between top employees and founders is not that big over here.

                                                  OK, I’ll bite. What’s the ratio of a founder’s equity to the equity of an April 2019 new hire at your shop?

                                                  1. 1

                                                    I don’t think the post said or could credibly say it’s a bad time for engineers, but it did raise some things that seem both true and relevant to one’s analysis of options. Just that you might be waiting a long time before you can sell is a pretty big deal. A naïve analysis of options value probably doesn’t factor in dilution – you might think “it’s 0.x% equity” based on what it is at the time, forgetting that if there are more rounds, that will change. This post only touches on it, but the whole short exercise window if you quit thing is relevant too.

                                                    The world is, in general, quite unfairly kind to engineers in 2019. But you should still understand upsides and downsides of options when you’re evaluating them.

                                                  1. 1

                                                    The #NoEstimates response to these business needs is typically of the form, “Estimates are inaccurate and therefore not useful for these purposes” rather than, “The business doesn’t need estimates for these purposes.”

                                                    That argument really just says that businesses are currently operating on much worse quality information than they should be, and probably making poorer decisions as a result, because the software staff are not providing very good estimates. If software staff provided more accurate estimates, the business would make better decisions in each of these areas, which would make the business stronger.

                                                    If magical fairies dropped bundles of gold doubloons from the sky onto the conference room table, that would also make the business stronger. It does not follow that this means relying on fairy gold is a sound practice.

                                                    Like every #yesestimates argument, this one boils down to: we really need to be able to estimate reliably, therefore it must be possible. That’s not how causation works.

                                                    1. 39

                                                      I’m really burning out on “simplicity” posts. I get it, simplicity is good. But that doesn’t actually inform me as a developer. Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                      It’s like if I stood on stage and said “Be good! Don’t be evil! Being evil is bad!” Sure, everybody agrees with that, but does it actually help people make moral choices?

                                                      (Also the analogy is dumb. Yes, we should totally base our engineering practice on a movie! A movie where the engineers are wrong because of magic.)

                                                      1. 11

                                                        Why do things become complex? What kinds of simplicity are there? How do we detect simplicity? How do we know when we shouldn’t simplify? None of these posts ever answer that.

                                                        Because your questions are difficult and answers are dependent on a lot of factors.

                                                        I’ll tell you what I do to detect simplicity, maybe you’ll find it useful. Let’s start with a real-life example.

                                                        I needed tokens for authorization, I reviewed existing formats, JWTs look conservative and Macaroons look powerful.

                                                        What do I do? I dissect the formats. For JWTs I read the RFCs and implemented software to create them and verify them (each in 2 languages) for various options (key algorithms).

                                                        For Macaroons I read the whitepaper, then implemented verifier based on the whitepaper, reviewed existing implementations, found out differences between the whitepaper and de-facto code with explanations. While comparing my implementation I found out some security issues with existing code. Additionally I implemented the rest of the stack (de/serialization, UI for manipulation of Macaroons). After two months I knew precisely where does complexity lie in Macaroons and of course there are the only spots all blogposts don’t mention (spoilers: cycles in third party caveats, no standards for encoded caveats…)!

                                                        Then I looked at my JWT proof-of-concept code - it uses base64(url) and JSON, primitives that basically all programming environments have built-in. After limiting the algorithms used the entire verifier takes just a couple of lines of code! It’s vastly simpler than the Macaroon one.

                                                        What’s the moral here? That you need a lot of time to see for yourself what is simple and what is complex. Now every time I see a post recommending Macaroons I can already see the author didn’t use them in practice (compare that with the Tess Rinearson post linked at the end of that article).

                                                        That’s only the example, I routinely implement various protocols and re-implement software (ActivityPub, Mailing Lists, roughtime client) and each time I discover what’s simple or what’s complex in each one of them.

                                                        (By the way your book is excellent!)

                                                        1. 9

                                                          I get it, simplicity is good.

                                                          Alas, not everybody gets it. The best that these kinds of exhortations can do (all that they aim to do, as far as I can tell) is to persuade people to modify their own set of values. This doesn’t immediately result in better code… but I think it’s a necessary precondition. The only developers who will even ask the good questions you suggest (let alone look for good answers) are the developers who hold simplicity as a value.

                                                          (The analogy is pretty dumb though, and not especially motivating.)

                                                          1. 10

                                                            I’ve never met a developer who does not claim to hold simplicity as a value. But as a concept it is so subjective that this is meaningless. It’s extremely common for two developers arguing for opposing approaches each to claim that their approach is the simpler one.

                                                            1. 7

                                                              I get the value of exhortations. I think more examples would be better. Pairs of solutions where the simple one meets requirements with a number of better attributes. Developers often prefer to see the difference and benefits instead of being told.

                                                            2. 6

                                                              Exactly. This is one of those things you can’t explain in a book. When to compose, when to decompose. When to extract methods, when to inline methods. When to add a layer of abstraction, when to remove one. When is it too flexible, when is it too simplistic?

                                                              No amount of rules of thumb is going to answer those question. I only know of one way to learn it: practice. Which takes effort and most importantly, time. Rendering this kind of posts mostly useless.

                                                              1. 3

                                                                P.S. They do feel good to write though, so people will keep writing them, and there’s nothing wrong with it either.

                                                              2. 5

                                                                I agree that anecdotes like this can get old, but I’ve been meaning to actually write a similar post to this… on something I’ve been calling the “too many buttons” syndrome. This issue pops up a ton in large pieces of software (Though I’m specifically thinking of projects like JRA and Confluence) where there’s an option for everything.

                                                                Not everyone gets that simplicity is good because it can be harder to sell. “If a user wants it, we should do it” is something I’ve heard just a few too many times without bothering to look at the use case or if it could be done better. Sometimes it’s worth stepping back and looking at the complexity something will add to the project (in both code and testing… especially when it comes to options and how they interact with each other) rather than just adding all the little features.

                                                                1. 5

                                                                  In my experience a lot of commercial companies that develop under tight deadlines produce a lot of suboptimal and dreadful code. Often it takes more time, to produce less code simply because the more time you spend on a difficult problem, the better you understand it. I think the reason that most a lot of software is bloated and complex is because it’s “good enough” which is optimal from an economic point of view.

                                                                  The other day there was a discussion here on Lobsters about all the required pieces needed to run a Mastodon instance and the popular solution of abstracting all that away in a Docker container. There are alternative implementations that depend on a smaller number of components alleviating the need for dumping everything in a container (of course the question is, do these alternatives offer the same functionality).

                                                                  How do we detect simplicity?

                                                                  For me personally simplicity has to do with readability, maintainability and elegance of code or infrastructure. If someones solution involves three steps, and someone else can do it in two steps (with comparable cognitive load per step), I would say it’s more simple.

                                                                  How do we know when we shouldn’t simplify?

                                                                  If that would cut some features you cannot miss.

                                                                  1. 5

                                                                    You are so right. After years of experience, I only start to clarify my idea of “simplicity”. There are different kind of simplicity most of them are not totally compatible. And in my opinion some need to be preferred to other, but there is no clear rule. To make a choice between different complexity I still use a lot of intuition and I debate a lot, and I am still unsure my choice are the best.

                                                                    • only using basic feature of a language (do not use advanced programming language feature) is certainly the most important aspect in simplicity. It will make your code easy to read by more people.
                                                                    • don’t use too much intermediate functions, and if possible don’t disperse those function in many different files before really feel you are copy/pasting too much. My rule of thumb is, 2 or 3 times duplications is totally fine and superior to centralisation of code. It start to be really clear that code factorisation is good when you start repeating yourself more than 6 to 10 times
                                                                    • only really use advanced feature of the language after having tried not to use it for some time and really lack the ability of that advanced feature. Some examples of what I call advanced feature of a language are; class heritage, protocols in Clojure, writing your own typeclasses in Haskell, meta programming (macros in LISP), etc…
                                                                    • prefer stateless functions to objects/service with internal states
                                                                    • prefer pure functions (side effect free) other procedures (functions with side effects)
                                                                    • give a lot of preference to composable solutions ; composable in the algebraic meaning. For example, I do my best not to use LISP macros, because most of the time macros break composability. The same could be said when you start to deal with type-level programming in Haskell, or when you are doing meta-programming in ruby/python.

                                                                    For now, all those rules are still quite artisanal. I don’t have any really hard metrics or strong rules. Everything I just said is “preferable” but I’m pretty sure we can find exception to most of those rules.

                                                                    1. 5

                                                                      Amen, +1, etc. “Simplicity” often just means that a concept fits cleanly in the maker’s head at a particular point in time. How many times have I returned to a project I thought was simple only to find I had burdened it with spooky magic because I didn’t benefit from critical distance at the time? When was the last time I deemed another person’s work “too complex” because I couldn’t understand it in one sitting and wasn’t aware of the constraints they were operating under? Answers: too often and too recently.

                                                                      1. 3

                                                                        What kinds of simplicity are there?

                                                                        This is a good question (as are the others). Borrowing from Holmes, I’d say there’s a continuum from naive simplicity, to complexity, to simplicity on the other side of complexity (which is what is truly interesting)

                                                                        For example, “naively simple” code would only cover a small subset (say, the happy path) of a business problem. Complex code would handle all, or most, of the business complexity but in a messy, complicated way. “Other side” simplicity refines that complex code into something that can handle the business complexity without itself becoming overly complicated.

                                                                        1. 2

                                                                          What happens to simplicity? We trade it for a other things of course. For example, you can have simple regular expressions, but most people prefer less simple and more powerful implementation like Perls.

                                                                          Simplicity is often a tradeoff versus easyness, performance, flexibility, reusability, useability, etc. So simplicity is good, but those other things are also good.

                                                                          1. 1

                                                                            Most people seem to agree that simplicity is best. However, when it comes down to simplicity for the user versus the developer, I have seen disagreement. Each trade off is going to be situation and implementation dependent, but at my job I’ve been pushing for a simpler developer environment.

                                                                            In my office, there is a tendency to create exceptions to rules because it makes things simpler for the user. Since the environment has more exceptional circumstances, it tends to have more errors when people forget the undocumented exception case. In my opinion, this causes an uneven experience for the user despite being “simpler.”

                                                                            My experience is coming from a medium sized, non-tech company. I work in the IT department so we are a cost center. There is an emphasis on white glove treatment of the revenue producing portions of the company. YMMV

                                                                          1. 4

                                                                            Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers.

                                                                            Haha, what a load of crap, just admit you don’t like java. We should be honest about these things.

                                                                            1. 34

                                                                              Please don’t dismiss people by telling them you know their own opinions better than they do or that they’re lying. There’s much better ways to disagree with their decision here.

                                                                              1. 8

                                                                                It’s a case study for promoting Rust…I wouldn’t judge it the same as dismissing somebody’s own blog post or whatever, say.

                                                                                1. 3

                                                                                  It’s dismissing people’s experience. The medium is irrelevant.

                                                                                  1. 21

                                                                                    Sometimes people’s experiences are not representative of reality, and sometimes people lie about their experiences, and sometimes people rewrite their experiences without realizing it, and sometimes people have experiences so limited that their ability to usefully generalize and advise others is called into question.

                                                                                    Just because it’s somebody’s claimed experience doesn’t magically make it somehow unable to be questioned.

                                                                                    And so we’re on the same page…we’re not talking about somebody relating a background of trauma or something: we’re talking about a company (npm) engineering team deciding to redo the same task three times using 1 hour (Node), 2 days (Go), and a week (Rust) and then the RESF using that to shill Rust (glossing over a doubling in the complexity of the npm’s language ecosystem and stack.

                                                                                    If they’d provided real performance numbers, maybe shown how the Rust version vastly outperformed the Node version, then this might be a better article. As it is, anybody with experience reading press releases (rightly) will wonder if the “experiences” are worth learning from.

                                                                                    1. 3

                                                                                      What exact claim do you find insufficiently backed up? They literally just documented the (their!) process of rewriting a chunk of JS in a different language, and how it went (for them). To get back to the original “page”: The “claim” ac was attacking was an opinion, a non-falsifiable statement at worst (as I think the conclusion is).

                                                                                      1. 17

                                                                                        There are no numerical metrics or benchmarks in the article. The service in question was “projected to become a CPU-bound task”, but it’s unclear if that’s a real issue without seeing their math. Other quotes like “the legacy JavaScript implementation of this service in Node.js was in need of a rewrite in any case” hint that this might be a strictly unnecessary rewrite.

                                                                                        Have you not experienced engineers selling a rewrite or new technology because they’re bored and not because it’s necessary?

                                                                                        1. -5

                                                                                          Ugh. Nobody is selling you anything here.

                                                                                          1. 13

                                                                                            “Rust Case Study:” “Copyright © 2019 The Rust Project Developers” “https://www.rust-lang.org

                                                                                            It’s on there specifically to convince people to adopt Rust. Which is fine: they’re promoting their work and how others benefit from it on their project page. (shrugs) It doesn’t bother me as much as friendlysock since I got at least two things out of it:

                                                                                            (a) Javascript developers were able to adopt it. That’s good to know in long term since I’m for minimizing Javascript use in general. Rust apps will also be more secure and maybe predictable. The typical predictions so far were that it would win over only C and C++ types, not Javascript and Go. This is a data point against that expectation for Javascript in an unlikely place.

                                                                                            (b) The Rust apps caused less problems, possibly due to what I just said. Then again, it could be anything since we have no data. Might not even be Rust. Heck, the Go rewrite might have taught them some lesson they reused when making the Rust version. We don’t know.

                                                                                            Now, far as a scientific evaluation, there’s nothing more to go on as friendlysock says. They didn’t even give us numbers. We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing. What they told us was what everyone writes, including Rust project’s marketing pages. It objectively introduces no new information on a technical level that we can evaluate or build on.

                                                                                            1. 2

                                                                                              We’d also be interested in what was easy, difficult, and so on at a language level for the work they were doing.

                                                                                              The did mention that the Rust implementation was more difficult, though.

                                                                                              “Therewriteof the authorization service using Node.js tookabout an hour. … The Go rewritetook two days. … The rewrite of the service in Rust did take longer than both the JavaScript version and the Go version: about a week to get up to speed in the language and implement the program. Rust felt like a more difficult programming language to grapple with.”

                                                                                              1. 2

                                                                                                Almost all things on Rust mention a learning curve with borrow-checker (or language), cargo being great, and a great community. Mentioning that downside is echoing common claims more than anything extra critical at this point. It’s part of the refrain.

                                                                                                You mentioning this did bring another data point I overlooked: they felt up to speed in Rust in about a week. So, Javascript developers both found the language useful and picked it up in a week. Or at least did for that one type of service well enough to falsely think they understood it in general. See how we’re still lacking objective data? We have a nice anecdote, though, which justifies trying to train a crowd of JS developers on Rust on similar or different projects to see what happens.

                                                                                                1. 1

                                                                                                  See how we’re still lacking objective data?

                                                                                                  That’s not a surprise to me, since I believe that the programming language field is at least a century away from having the capability of gaining objective data on anything non-trivial. We’re like surgeons ridiculing the guy who washes his hands before operating.

                                                                                                  I guess that guy is Rust.

                                                                                                  1. 3

                                                                                                    It’s a frequent complaint we have. We’d love to have more data to compare us to.

                                                                                            2. 6

                                                                                              Nobody is selling you anything

                                                                                              Companies don’t just publish information randomly. A white paper is a standard marketing device (https://en.wikipedia.org/wiki/White_paper#In_business-to-business_marketing).

                                                                                              In this case they’re selling:

                                                                                              1. NPM as a rigorous engineering culture (recruiting), and
                                                                                              2. JavaScript-Rust ecosystem cohesion (technology)
                                                                                              1. 3

                                                                                                Exactly, we use whitepapers in precisely this fashion. They are basically executive tl;drs and as such gloss over details.

                                                                                  2. 2

                                                                                    Did you really need use Sysop hat to say that?

                                                                                    1. 3

                                                                                      hatters gonna hat.

                                                                                    2. 0

                                                                                      Perhaps the ‘haha’ didn’t convey my tone right. I meant it as a jab/joke, the type of thing you would say to make fun of your friend…

                                                                                      ‘cmmmoooon, my friend… just admit it, you don’t like java … nenornenornenor … lets go play tag’

                                                                                      1. 0

                                                                                        Also, I didn’t say lying… I think I was more implying a level of self delusion.

                                                                                      2. 19

                                                                                        Those are valid complaints. Deploying a Java service requires deploying at minimum 2 things that must be kept in sync. A JVM and a Java jar.

                                                                                        Because they are separate they bring a number of deployment and operations issues for the life of the service. Rust being a single binary removes those issues entirely.

                                                                                        There are resolutions for all those in Java too but they all require more effort than Rust does.

                                                                                        1. 12

                                                                                          Of all the other things you have to do to run or build service - that seems like a drop in the bucket of things to care about to me.

                                                                                          How many backwards incompatible changes are the JVM’s making these days anyway?

                                                                                          1. 14

                                                                                            Quite a few, actually.

                                                                                            I am no JVM expert but in my experience as a Clojure application developer it’s quite common for new Java releases to break Clojure and/or widely-used Clojure libraries. It’s happened several times in the last year. At work, we are currently on an older Java release for this reason. Right now, the latest Java has a serious performance regression for some fairly-common Clojure use cases and folks are being advised not to upgrade.

                                                                                            1. 2

                                                                                              that does sound pretty lame.

                                                                                            2. 3

                                                                                              It’s not so much the JVM’s backward incompatibilities as the JAR’s that are dependent on the latest and greatest JVM, except that one old JAR that only works on some old ancient version.

                                                                                              So you end up running multiple JVM’s across various machines, to make various JAR’s happy. Suddenly you start day dreaming of rust or go built binaries…

                                                                                              But generally I agree, JVM nightmares aren’t that miserable compared to 5,000 external service dependencies you may have to operate just to make X work.

                                                                                            3. 3

                                                                                              Shouldn’t that be easily automated, either provision the server with a pre-installed JVM (using ansible? etc.) or use Docker and put the JVM in there as is common?

                                                                                              1. 1

                                                                                                The most future proof method is to use a Docker container.

                                                                                              2. 4

                                                                                                They’re already doing the exact same thing with Node and the JS code that it runs.

                                                                                                1. 5

                                                                                                  Sure, but that’s no reason to go through the same pain a second time. I put up with many things in the Python packaging world because I already know and use Python, but I am not willing to invest time in learning an ecosystem that exhibits issues anywhere close to that.

                                                                                                2. 2

                                                                                                  But deploying any service is already tracking versions of databases, the state of your app, the code + compatibility with the OS. I don’t think avoiding java solves dependency or state management.

                                                                                                3. 8

                                                                                                  While I think you phrased this strongly, I’m also puzzled by the quote. The legacy application being replaced is a node app. Running a node app requires a VM and standard library just as running a JVM app does. What is the overhead that makes a JVM app unacceptable while a node app is ok? Perhaps it’s language/tooling familiarity? In my experience, all those three-letter J** acronyms can get fairly confusing.

                                                                                                  As an aside, I found the following quote refreshingly honest -

                                                                                                  “I wouldn’t trust myself to write a C++ HTTP application and expose it to the web”

                                                                                                  1. 7

                                                                                                    Maybe you haven’t read the full article? it literally says

                                                                                                    Given the criteria that the programming language chosen should be:

                                                                                                    ● Memory safe

                                                                                                    ● Compile to a standalone and easily deployable binary

                                                                                                    ● Consistently outperform JavaScript

                                                                                                    of which Java doesn’t fulfill at least one.

                                                                                                    1. 1

                                                                                                      @ac’s comment doesn’t indicate that he missed that part of the article. He is challenging the premise of the second bullet point. The statement about Java that he quoted was the implicit justification for that bullet point.

                                                                                                      1. 1

                                                                                                        I don’t agree, I think the bullet point was the justification for the statement about Java and not the other way around. At least logically this makes more sense. You do have a point though about the order in the document:)

                                                                                                      2. 1

                                                                                                        Pretty sure graal vm java does all of those.

                                                                                                        1. 3

                                                                                                          It’s also commercially licensed by Oracle.

                                                                                                          1. 1

                                                                                                            from http://www.graalvm.org/downloads/

                                                                                                            License

                                                                                                            All open-source

                                                                                                            Free for production use

                                                                                                            1. 2

                                                                                                              The community edition. Enterprise edition:

                                                                                                              • Free for evaluation and other non-production uses
                                                                                                              • Improved performance and smaller footprint
                                                                                                              • Sandboxing capabilities for native code
                                                                                                              1. 1

                                                                                                                Twitter runs on the community edition for all production services and have impressive numbers. Search for talks by Chris Thalinger on YouTube to learn more.

                                                                                                                1. 1

                                                                                                                  Yep, it’s still not “it’s free”, but “it has free variant”. Oracle is no stranger to changing the licensing, as they have recently shown with the mainline oracle JVM.

                                                                                                                  Not wanting to deal with oracle stuff at all is a reasonable stance.

                                                                                                          2. 1

                                                                                                            Fair enough, though in this same vein you could argue that C++ is a safe programming language, if you avoid the “thorns”;)

                                                                                                        2. 4

                                                                                                          It’s a real issue. I stumbled across this “warp” project that makes standalone app bundles for the Buck build system and Buckaroo package manager, which are written in Java.

                                                                                                          https://github.com/dgiagio/warp

                                                                                                          If it weren’t an issue, then they wouldn’t have done this weird dance. I also took care to make a Python app bundle for Oil for related reasons.

                                                                                                          1. 2

                                                                                                            I found warp the same way you did :)

                                                                                                            but buckaroo is now written in F#

                                                                                                            1. 3

                                                                                                              We still use Warp, even though Buckaroo is now AOT-compiled F#. The reason is that we have dynamic libraries but still want users to be able to wget the tool for quick installs.

                                                                                                          2. 4

                                                                                                            It’s a legitimate concern. Having the ability to deploy a single binary easily from CI or the like can greatly reduce ops headaches (Python is a bit of a mess to deploy because it’s hard to do this).

                                                                                                          1. 5

                                                                                                            There are so many assumptions here I wouldn’t trust this any more than just asking during the interview. And from what I’ve seen, work/life balance depends as much on the employee as it does the employer.

                                                                                                            And fwiw, working on personal projects or doing any non-work open source development using your work GitHub account sounds like a terrible idea.

                                                                                                            1. 3

                                                                                                              I have never worked with anyone who had separate work and personal Github accounts. How would such separation benefit me as an employee?

                                                                                                              1. 4

                                                                                                                Odd. I’ve never met anybody who didn’t keep their work accounts separate.

                                                                                                                The way I see it, it’s just like any other work account. I wouldn’t use my work email for personal correspondence, or a work chat for personal chatting so why use my work GitHub account for personal projects?

                                                                                                                Not to mention all the questions it could raise about who actually owns the work the account creates. And what happens when you leave the job? And who knows what kind of snooping employers can do to the accounts they control.

                                                                                                                In general I like to keep a very strict separation between work and the rest of my life.

                                                                                                            1. 10

                                                                                                              In a burndown chart, I want to be able to run simulations as well. “What happens to this project if X work falls behind. What happens if Bob gets sick?”

                                                                                                              Is anything in software development predictable enough to make this kind of analysis useful?

                                                                                                              1. 8

                                                                                                                No, this is basically a management wish-fulfillment fantasy.

                                                                                                                Seeing that we thought something would take 8 hours of work but we spent 24 is incredibly valuable. We can revisit our assumptions we made when estimating see where we got it wrong. Then, we can try and account for it next time. Yes, estimating is hard but its also a skill you can get better at if you work at it and have support for proper tools.

                                                                                                                Likewise, I have heard this asserted by every manager I’ve ever worked with and for. No evidence has ever been presented, nor have estimates actually improved over time. (The usual anti-pattern is: estimates get worse over time because every time an estimate turns out to be low, a fix is proposed–“what if we do all-team estimates? what if we update estimates more frequently?”–which inevitably means spending more time on estimates, which means spending less time on development, which means we get slower and slower.)

                                                                                                                1. 7

                                                                                                                  I personally used to be quite bad at estimating. I’ve worked at it, I’ve gotten much better about estimating. There are things you can do to get much better at it. None of the things you’ve mentioned are ones I think would help. I plan on writing a post about the things I’ve learned and taught others that have helped make estimates more accurate.

                                                                                                                  1. 3

                                                                                                                    That would make great reading.

                                                                                                                    Are there any existing accounts of effective software schedule estimation you’d recommend?

                                                                                                                    1. 1

                                                                                                                      Two things I would recommend (and will be primary topics of said blog post).

                                                                                                                      Estimates slipping is usually about not accurately accounting for risk. Waltzing with Bears is a great book on dealing with risk management. The ideas in it might be overkill for many folks but the process of thinking about how you should account for risk and establishing your own practices is invaluable. The book is great even if you only use it as “that seems overblown, what if I…”.

                                                                                                                      The second is to record your estimates and why you made them. What did you know at the time that you made your estimate. Then, when your estimate is wrong, examine why. What didn’t you account for? When I first started doing this, I realized that most of my estimates were wrong because I didn’t bother to explore the problem enough and that I was being tripped up by not accounting for known knowns. Eventually I got better at that and started getting tripped up by known unknowns (that’s risk). I’ve since adopted some techniques for fleshing our risks when I am estimating and then front loading working on risks. If you think something might take a week or it might take a month, work on that first. Dig in to understand the problem so you can better estimate it. Maybe the problem is way harder than you imagine and you shouldn’t be doing the project at all. This isn’t a new concept but its one that is rarely used. In agile methodologies, its usually called a “spike”.

                                                                                                                      I’ve worked on projects that spanned over the course of months and we spent a couple weeks on estimation and planning. A big part of that time digging in, understanding the problem better, discussing it and coming up with what we needed to explore more to really understand the project so we could course correct as we went along.

                                                                                                                      1. 1

                                                                                                                        Ooh, a DeMarco book! Will definitely check it out. Thanks!

                                                                                                                    2. 1

                                                                                                                      Please do write this, I need to improve in this area.

                                                                                                                    3. 1

                                                                                                                      The wish-fulfilment does not exist in a vacuum.

                                                                                                                      Your customers might not be happy with your team constantly running late. Your pre-revenue startup might have a hard time raising investment. Whatever. There are external reasons for why a professional developer must be reliable in his or her estimates to actually get things out the door.

                                                                                                                      I’ve been changing my opinion on this back and forth. Especially in a pïss-poor startup, where the the biz guys wanted us to skip unit testing to achieve results faster, refusing to estimate was a fuck you. The code base got convoluted, but also dealing with how they represented things was frustrating.

                                                                                                                      I feel that in those cases the problem runs deeper in how geeks are supposed to be managed. Hell, it could be that estimation starts eating up time because the managers drove the geeks into protesting, which is - of course - as unprofessional as delivering late. Still you need to sort out your org for smooth ops before taking care of estimates.

                                                                                                                      Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

                                                                                                                      1. 0

                                                                                                                        The fact that customers want something, or that it is necessary to the business’s success, do not cause it to become possible. I’m not disputing the desirability of accurate estimates. I’m disputing the idea that they are possible. I have not seen any team or technique generate such estimates reliably, over time, in various circumstances. (Of course, like any gambler with a “system,” sometimes people making estimates get lucky and they turn out to be right by coincidence.) I have heard many managers claim to have a system for reliable estimates which worked in some previous job; none was able to replicate that success on the teams I observed directly.

                                                                                                                        (It’s not just software, either. Many people point to the building trades as an example of successful estimation and scheduling. In my experience maintaining and restoring an old house and the experiences of friends and acquaintances who’ve undertaken more ambitious restorations, this is more wishful thinking. It’s common for estimates by restoration contractors on larger jobs to be off by months or years, and vast amounts of money. If so mature an industry can’t manage reliable scheduling, what hope is there for us?)

                                                                                                                        Yet this isn’t car repair for old vehicles, where you find more and more problems as you go along, making estimates tough without thorough diagnostics, but the customer is happy with the substitute car you gave out in the meantime.

                                                                                                                        I’d argue that is exactly what much software development is like (except there is no substitute for the customer).

                                                                                                                        1. 1

                                                                                                                          Maybe I’d like to be more optimistic about learning to estimate better ;) But for sure @SeanTAllen touched on a lot of pertinent points. Is it Alice or Bob who gets the task? How well is the problem space, the code, known? And so on.

                                                                                                                          It’s hard as balls, and you’re not wrong with your gambler analogy, but not all systems for getting things right occasionally are equally unlikely to succeed. Renovators also learn what to look out for and how long those issues tend to take, as well as the interactions. Probabilities are usually ok by customers if that’s all you got.

                                                                                                                          In my car analogy, the point kinda was that we’re screwed because we can’t give out substitutes. We can deliver temporary hacks, although nothing is as permanent as a temporary hack.

                                                                                                                    4. 1

                                                                                                                      A lot of activities in software development try to improve predictability. For example: following style guidelines, continuous integration, unit testing, etc. All of these have a cost and slow developers down. The upside of course is to reduce bugs which will slow you down much more later. Or maybe not. The risk is generally too high, so we generally prefer the predictability of a slow incremental process.

                                                                                                                      I have a feeling that Demings thought about that when he talked about “variation”, but I need to read more from the father of Lean and grandfather of Agile to understand that. Currently, I believe that I don’t assign quite the correct meaning to the words I read from him.

                                                                                                                    1. 2

                                                                                                                      Judging by how much success teams like the Google Chrome team have with this approach, it’s obviously got big upsides.

                                                                                                                      I have a slight worry. What do you do about this scenario: flagged out feature deployed, its lightly tested code has a serious bug (data destruction or leaking, i.e. one where the consequences persist even if you turn the flag off after), it gets switched on by accident or malice in production, havoc ensues?

                                                                                                                      1. 9

                                                                                                                        This is similar to the incident that destroyed Knight Capital Group. A feature flag was re-purposed (!) to toggle a feature unrelated to the original feature for which the flag had been added. A deploy went wrong such that some servers were running the old code with the old flag semantics and some the new code with the new flag semantics. They lost $440 million in 45 minutes.

                                                                                                                        1. 1

                                                                                                                          Ooh thanks. I was sure there was a recent-ish example in the news but I couldn’t remember.

                                                                                                                          1. 1

                                                                                                                            And this is why some FAANG companies use Immutable Infrastructure internally.

                                                                                                                            Code and configuration are built and packed together and go through all integration and pre-production CI steps without changes.

                                                                                                                        1. 6

                                                                                                                          I try to avoid feature flags unless deployment and release absolutely must be separated. Each feature flag doubles the number of available code paths. Ten feature flags yield 1,024 possible combinations. How sure are you that each feature flag is truly independent and that there is no undesirable behavior that can emerge from unanticipated combinations of feature flags? I am rarely sure.

                                                                                                                          Sometimes there are good reasons to deploy code with features disabled. More often, in my experience, the reasons are poor and the decision is made by non-technical business functions (marketing, sales) because they do not understand the cost in complexity of littering code with these kinds of branches.

                                                                                                                          1. 3

                                                                                                                            Not having the flag means that you are coupling “put out this new feature” with “roll out these fixes”, so if there’s any issues with the new feature it also means rolling back fixes.

                                                                                                                            If you’re on a decent sized team, with several people working on independent features, making sure that “merge into master” doesn’t immediately couple the fate of all these features is very valuable.

                                                                                                                            Granted, in our case we use feature flags almost exclusively for “features in QA/testing before release”, and at most there are two feature flags that can affect code execution in a specified block of code. If you are writing feature flags that interop with each other 1024 different ways I think you don’t have a feature flag problem, you have a coupling problem.

                                                                                                                          1. 6

                                                                                                                            An interesting observation for me is that — at least from what I’ve gleaned online — it seems the sentiment is that Clojure is good because it is developed slowly and thoughtfully, while Elm is bad because it is developed slowly and thoughtfully.

                                                                                                                            One is perceived as “stable”, the other perceived as “dead”.

                                                                                                                            Although this could just be an illustration of the overlap between JavaScript users and the “move fast and break things” crowd.

                                                                                                                            1. 4

                                                                                                                              Clojure is good because it is developed slowly and thoughtfully, while Elm is bad because it is developed slowly and thoughtfully

                                                                                                                              One of these regularly breaks existing code.

                                                                                                                              (I have no idea which one is perceived “dead” because as a Clojure programmer I haven’t seen meaningful changes in Clojure in the entire time I was using it professionally, which mostly means that what I think would make Clojure better is not what Rich Hickey thinks makes Clojure better)

                                                                                                                              1. 2

                                                                                                                                I won’t dispute that, but from my perspective:

                                                                                                                                1. Elm is at less than a 1.x release
                                                                                                                                2. The changes I’ve seen in the past couple of years have all been caught by the compiler. This is more desirable to me than the uncertainty of not knowing if something will break at runtime after a version bump.
                                                                                                                              2. 3

                                                                                                                                Clojure programmers tend to have a lot of respect for Elm (both the language and the way it is developed). I don’t know who thinks Elm is dead, but it sounds like that perception is coming from people with different priorities than Clojurists.

                                                                                                                                1. 2

                                                                                                                                  Sorry, I didn’t mean to imply that I observe Clojure enthusiasts doing this. It’s more the people who are excited about all the latest JavaScript frameworks. They would be the target audience for Elm, since Elm is essentially a UI DSL.

                                                                                                                              1. 6

                                                                                                                                I might think the process is just overwrought and not rife with useless steps / conflating things in a non-malevolent way until I got the the 8 written questions “essay exam” part. Then I would probably drop out of the process and just work somewhere else.

                                                                                                                                1. 3

                                                                                                                                  Being able to write and communicate well is such a crucial part of software engineering, especially on a long-lived product maintained by a group of engineers with the inevitable membership churn that happens over many years. Strong writing skills also help with the kind of asynchronous communication that often works best with remote teams who might have members in far flung time zones, and when collaborating with members of open source communities.

                                                                                                                                  At least, those are things I believe are important. The written questions are not meant to take a long time to answer, though because we don’t ask you to answer them in front of us you can really take as long as you want. For folks that get nervous under exam or interview conditions, hopefully the chance to polish their thoughts in writing at their own pace also affords a chance to demonstrate clarity of thought and breadth of experience in a lower stress setting.

                                                                                                                                  At the end of the day, it’s true that no process (or job!) will fit everybody. Though the RFD is certainly detailed, it represents a level of transparency with applicants that I’m not sure is that common in our industry. It also helps us in our attempt to give each candidate a consistent treatment.

                                                                                                                                  1. 2

                                                                                                                                    Of course writing skill is important. It’s important in nearly every industry, yet no other industry that I have ever heard of assigns essay question homework. Only in the software industry does this “dancing bear” mentality predominate, where most employers are wholly unwilling to look at any existing work product the candidate may have, instead demanding that the candidate produce new work (for free) especially for evaluation. It’s abusive and should be illegal.

                                                                                                                                    1. 1

                                                                                                                                      If you take a closer look at the RFD, you’ll see that the written answers we’d like are not dissimilar to regular interview questions, except that we’re asking you to write instead of asking you in person. They’re not some exercise which is suspiciously close to asking for free labour relevant to our shipping product.

                                                                                                                                      In addition, for the other artefacts we ask for such as a code sample, we’re perfectly happy to accept any code you’ve written already which meets the criteria.

                                                                                                                                      These interviews are for professional positions with an agreeable salary, where much of the work you do will be extremely collaborative – with other engineers and with customers. I don’t think it’s exploitative to ask for you to write a little about yourself when you’re applying for a job like that.

                                                                                                                                      1. 3

                                                                                                                                        Again, no other industry requires this hoop-jumping, even for much more senior positions than that of an individual-contributor engineer. I’ve observed my partner go through the interview process a couple times, for positions with dozens of people in the reporting chain and millions of dollars in budget. She is often asked to provide writing samples from work product she’s created at previous jobs, but I don’t recall a single instance where she was asked to do the kind of homework that is routine for even the most junior software job. I have not seen any evidence that the software hiring process yields better results than the process used in every other field.

                                                                                                                                        Homework excludes people with childcare and other responsibilities, and it also makes it very difficult to interview with more than one or two companies at a time, which puts the candidate at a disadvantage as far as finding the best available offer.

                                                                                                                                        1. 1

                                                                                                                                          Again, no other industry requires this hoop-jumping, even for much more senior positions than that of an individual-contributor engineer.

                                                                                                                                          I think that’s a very broad generalisation and though I appreciate you’re relaying your personal experience, I’m not convinced it’s universally true.

                                                                                                                                          She is often asked to provide writing samples from work product she’s created at previous jobs

                                                                                                                                          Which, if you’ll look at the RFD, describes most of the artefacts we request. A writing, code, and analysis sample, each of which can absolutely be from previous jobs or from open source work or from a portfolio you already have. We’re willing to look at anything you’re allowed to show us, even if it’s not something you can or wish to post in public.

                                                                                                                                          Of course, if you have none of these things at all, we do ask you to produce something specifically for your application. We try to make it clear that you shouldn’t spend an undue amount of time on it.

                                                                                                                                          Homework excludes people with childcare and other responsibilities

                                                                                                                                          I have a son, and certainly raising him takes a lot of time and energy. One of the reasons I love working for Joyent is that everybody is very understanding of this, and I have no trouble making flexible arrangements to attend important events or to stay home when he’s sick.

                                                                                                                                          Assuming you have existing samples, the only pre-interview thing we’re asking you to do is answer a few questions about yourself in an e-mail. We’ve tried to keep the list of questions long enough to give us some insight into you and your ability to write, while short enough not to be burdensome – even for those with family and other responsibilities.

                                                                                                                                          Hiring is complicated, as is finding the right job for you personally. We aim to be a workplace where people feel like they can (and want to!) build a career, hopefully on the time scale of at least years. I’ve been with Joyent for six years, myself. With that in mind, an hour or less spent answering some questions is hopefully not too much to ask, especially if you would like to work with us on the products we build!

                                                                                                                                          1. 2

                                                                                                                                            I do appreciate that Joyent allows you to provide existing work. My complaint is really about the majority of software hiring managers who are not willing to do that and want you to do their specific coding exercise.

                                                                                                                                            I think that’s a very broad generalisation and though I appreciate you’re relaying your personal experience, I’m not convinced it’s universally true.

                                                                                                                                            I’d certainly be interested to hear about examples of other fields which require similar things of job candidates. Offhand, the performing arts are the only examples that come to mind.

                                                                                                                                1. 1

                                                                                                                                  This is cool. It’s nice to have a pure-Lisp option.

                                                                                                                                  1. 8

                                                                                                                                    I agree with this, and I believe the door should’ve been slammed shut before I was invited. The past three or four months have definitely had more “HN-flavored” stories, or so it feels at least. There’s no way to keep a community of over 10000 users on track and focussed on the original concept.

                                                                                                                                    1. 7

                                                                                                                                      Could you post some examples of ‘HN flavoured stories’ ?

                                                                                                                                      It is hard to pinpoint what it is about Lobsters that makes me prefer it to other similar communities, but I would summarise this place as:

                                                                                                                                      Stories for those who enjoy the details
                                                                                                                                      

                                                                                                                                      I had to omit the word ‘technical’, I don’t think it is critical to describe what goes on around here. I would much rather read some well informed and passionate write up on a non-technical subject than some clickety-markety new CSS grid framework piece.

                                                                                                                                      1. 7

                                                                                                                                        Omitting the “technical” part is a big problem.

                                                                                                                                        1. 5

                                                                                                                                          You’ve made this claim many times, but it’s clear that there is a large contingent of members–including similarly long-tenured members–who feel otherwise, and it isn’t clear why your vision for the site should be dispositive.

                                                                                                                                          1. 3

                                                                                                                                            This is pretty much the only description of Lobsters on the About page:

                                                                                                                                            Lobsters is a computing-focused community centered around link aggregation and discussion, launched on July 1st, 2012.

                                                                                                                                            Content is added and somewhat curated by the active community. Whatever is posted today will be the hallmark for what is posted tomorrow. This would evolve over time.

                                                                                                                                            I retracted calling it a ‘technical’ community as I think the word is ambiguous to the point where it can mean pretty much anything. Stories should just match up with the tags defined, and if they are beneficial to enquiring minds then they should have a place here.

                                                                                                                                            1. 1

                                                                                                                                              These posts don’t seem to be overwhelming the conversation on the site. Is the problem that these haven’t been downvoted below zero?

                                                                                                                                        1. 22

                                                                                                                                          I gotta say, as annoying as recruiter emails can be, too many of them is the very definition of “a great problem to have.”

                                                                                                                                          1. 7

                                                                                                                                            If they represent real job options but you happen to have better ones, sure.

                                                                                                                                            But if they’re truly irrelevant - requiring skills you don’t have and never claimed to have - they truly have no value to you and waste your time.

                                                                                                                                            1. 1

                                                                                                                                              Recruiter emails are to real job opportunities as “You may already have won the Publisher’s Clearinghouse Sweepstakes” letters are to actual lottery winnings.

                                                                                                                                              1. 2

                                                                                                                                                Some are good, but random recruiter emails do seem much more likely to be ridiculously bad - like lowly-paid and probably high-stress contractor “opportunities” for stacks I’ve never touched in a random city halfway across the country that I have no interest in moving to or commuting to.

                                                                                                                                            1. 4

                                                                                                                                              Here’s mine. For remote jobs locations given are company HQ locations, not my own. I haven’t included equity or bonuses since they’ve never been a significant portion of my compensation. I will second femiagbabiaka’s comment that this is nerve-wracking.

                                                                                                                                              Date      Company     Title                     Location        Remote? Salary
                                                                                                                                              2005-2006 WebCheckout Support Technician        Chicago         N       ~30k
                                                                                                                                              2006-2014 WebCheckout Software Developer        Chicago         N→Y     50k→~75k
                                                                                                                                              2014      Outpace     Senior Software Engineer  SF              Y       100k
                                                                                                                                              2015-2018 Healthfinch Senior Software Engineer  Madison         Y       120k→145k
                                                                                                                                              2018      Healthfinch Principal Engineer        Madison         Y       155k