1. 3

    (I wonder how many good companies that Accelerate book is going to kill before engineering managers move on to the next shiny object.)

    More on-topic … this article seems to set up a false dichotomy between E2E tests and unit (or component) tests. Integration tests which exercise the whole system can be fast and not flaky if you replace external service dependencies like queues, HTTP transport, etc. with synchronous, in-process components.

    1. 11

      Did you know that it’s possible today to create something for your browser that works like a native app on your device?

      This is categorically false. It is a marketing fiction spread by those who want to develop their apps on the cheap, and, ok, fine. But PWAs do not work anything like native apps from the perspective of the end user, and acting otherwise is just gaslighting those users.

      1. 7

        This is insane…

        I assume most people here that use Ubiquiti have disabled remote access to devices if they haven’t already.

        Legal overrode the repeated requests to force rotation of all customer credentials, and to revert any device access permission changes within the relevant period

        I’m struggling to see how this is good advice. Was it really to protect the stock value (rotating would reveal something bad happened and open it up to questions)? Even that is short sighted.

        1. 24

          A comment from a former employee lifted from the HN thread:

          While I was there, the CEO loved to just fly between offices (randomly) on his private jet. You never knew where he’d pop up, and that put everybody on edge, because when he was unhappy he tended to fire people in large chunks (and shut down entire offices).

          This seems consistent with some Glassdoor reviews; for example:

          No one is safe here. you expendable just like the trashbag in your garbage can. owner gives unreasonable goals and when not met, he fires. upper management/cfo like money and rjp [Robert J. Pera, the CEO] clout over the product. over the consumer experience. the company morale is everyone tries to fly under RJP’s radar due to random firings. Upper Management is number people, worried about the stock more than employees and the product. Very muddy project mangement and very foggy leadership. No one really knows where the ship is sailing. Everyone is on the same ride trying to avoid a wreck at the same time avoiding RJP.


          The company is a one-man show who completely ignores people value.

          You are being questioned, demoralized and you even don’t believe your skills in the end.

          No feedback, no HR, no planning.


          • Incredibly toxic culture where most people would rather not have to deal with the CEO at all (“be invisible”) due to his behaviour and complete lack of respect towards his employees. I have witnessed or experimented a lot of what you can see in the other negative reviews on this site.

          • This may vary from office to office, but there doesn’t seem to be a general HR department. If the CEO is being disrespectful or abusive, who can you complain to, really?

          And a bunch more.

          Seems like the owner/CEO is just a twat that everyone is afraid of, and for good reasons too. This kind of company culture incentives the wrong kind of decision-making; from a business, ethical, and legal perspective. It’s no surprise that whistleblower “Adam” wants to remain anonymous.

          It’s all a classic story repeated untold times over history innit? People will go to great lengths to avoid strong negative consequences to themselves, whether that’s a child lying about things to avoid a spanking, a prisoner giving a false confession under torture, or an employee making bad decisions to avoid being fired. We only have several thousand years of experience with this so it’s all very new… Some people never learn.

          1. 5

            holy shit.

            This kind of company culture incentives the wrong kind of decision-making; from a business, ethical, and legal perspective.

            Indeed, and it makes its way right into the product too; you can tell when release feature quantity is prized over quality. This honestly explains more than I thought it could about my experience with their products so far — they feel so clearly half-baked, in a persistent, ongoing sense.

            1. 3

              I never even heard of Ubiquiti until a few days ago when there was a story on HN that their management interface started displaying huge banner ads for their products – I just use standard/cheap/whatever’s available kind of hardware most of the time so I’m not really up to speed with these kind of things. Anyway, the response from that customer support agent is something else. The best possible interpretation is that it’s a non-native speaker on a particularly bad day: the wife left him yesterday, the dog died this morning, and this afternoon he stepped on a Lego brick. But much more likely is that it’s just another symptom of the horrible work environment and/or bad decision making, just like your meh experience with their products.

              1. 2

                Yeah, I had similar experiences with Ubiquiti stuff–I bought it because I liked the idea of separating routing and access point functionality, but it never stopped being flaky. After the last time throughput slowed to a crawl for no reason I got a cheap TP-Link consumer router instead and I haven’t had to think about it once.

            2. 1

              I assume most people here that use Ubiquiti have disabled remote access to devices if they haven’t already.

              Ironically, I can’t. The UniFi Protect phone apps require it, so I have to choose between security of my network and physical security of my house.

            1. 5

              Great write-up, I had no idea the REPL of lisp/smalltalk was so powerful. I need to get around to learning clojure.

              I think the elixir* REPL fits the bill for the most part - if I start up one iex instance and connect to it from another node I can define modules/functions and they show up everywhere. And for hot-fixing in production one can connect to a running erlang/elixir node and fix modules/functions on the REPL live, and as long as the node doesn’t get restarted the fix will be there.

              * erlang doesn’t quite fit the bill since one can’t define modules/functions on the REPL, you have to compile them from the REPL.

              1. 3

                Does Clojure actually have these breakloops though? I think I’ve seen some libraries that allow doing parts of it (restarts), but isn’t the default a stacktrace and “back to the prompt”?

                1. 1

                  Well, prompt being the Clojure repl, but you’re correct that the breakloop isn’t implemented, as far as I got in the language. You can must implement the new function and re-execute, so you lose all of the context previous to the break. I think with all of the customizability of what happens when a stack trace happens, it’s possibly possible.

                  I THINK the expected use with Clojure is to try to keep functions so small and side effect free that they are easy to iterate on in a vacuum. Smalltalk and CL have not doubled down on functional and software transactional memory like Clojure has. That makes this a little more nuanced than “has/doesn’t have a feature”.

                  1. 1

                    You’re correct. Interactivity and REPL affordances are areas where Clojure–otherwise an advancement over earlier Lisps–really suffers compared to, for instance, Common Lisp. You don’t have restarts, there is a lot you can’t do from the REPL, and it’s easy to get a REPL into a broken state that can’t be fixed without either a full process restart or using something like Stuart Sierra’s Component to force a full reload of your project (unless you know a ton about both the JVM and the internals of the Clojure compiler). You also can’t take a snapshot of a running image and start it back up later, as you can with other Lisps (and I believe Smalltalk). (This can be useful for creating significant applications that start up very quickly; not coincidentally, Clojure apps start up notoriously slowly.)

                1. 3

                  If you notice one difference, it would probably be that commands that act on the symbol at point (e.g. cider-doc) will no longer prompt you to confirm the symbol. The old default was a mistake and I wanted to adjust this for this grand release.

                  Best news I’ve heard all day! It’ll be nice to remove the override of this setting from my Emacs config.

                  1. 4

                    At least we have a single connector now…

                    1. 18

                      Arguably having one connector that is not actually interoperable is worse than having multiple connectors whose lack of interoperability is apparent at a glance.

                      1. 5

                        Yep, not knowing if the cable you want will work is like having USB-C Heisenberg edition. Its arguably worse because of the lack of knowing.

                        1. 4

                          It works for me with everything. A variety of phones, laptops, Nindendos Switch, chargers, batteries and cables. Maybe sometimes I’m not getting optimal charging speed, but it’s always better than the situation was before.

                          I don’t have a MacBook though. I hear they have more issues than anything else.

                          1. 3

                            Good for you. But the article shows your experience isn’t shared by everyone. Not knowing if a USB-C cable and charger will charge your device unless you try it is mildly infuriating.

                      1. 4

                        I use fish and have been happy with it. I don’t use any of the plugins for it, mostly because it’s good enough out of the box for the simple shell stuff I do.

                        On occasion I have used bass to work with bash scripts that were required by projects I had to work on. It runs bash scripts and exports environment changes back to your fish session.

                        1. 3

                          Damn, I’ve been wanting something like bass for years, thank you!

                        1. 6

                          I switched away from Fish (after using it for several years) because I couldn’t get used to it’s non-POSIX syntax…

                          1. 13

                            That’s the reason I picked it; for day to day usage, it’s a lot less warty, and if I need a bunch of POSIXy stuff, I can just exec bash.

                            1. 1

                              You are correct in that exec bash is a useful way to run POSIXy stuff. Unfortunately (to my knowledge), shell functions, aliases, etc. must be translated into fish. I depend on being able to source POSIX shell scripts in order to bring my functions and aliases to remote servers and containers.

                              1. 2

                                From my experience, 90% of shell functions and aliases can (and should) be rewritten as standalone scripts. Unless you indeed modify the current shell’s environment or even the argument handling (like noglob in zsh), there is no reason to hoard functions.

                                1. 1

                                  Funny; I did just that mere hours before you posted your comment. Took three commits to my dotfile repo (1, 2, 3).

                                  There is one other benefit to using shell functions and aliases: it’s easy to view them all at once by running functions && alias; the result can be written to a file, giving you a single file with all your custom commands.

                                2. 1

                                  That’s a different use case, yeah. For me, I have two computers I ever interact with, so.

                                  1. 1

                                    Yeah, that’s unfortunately why I have to use bash at work even though I use fish everywhere else. Sad; fish is way nicer for shell scripting.

                                3. 5

                                  I switched away from Fish, despite much preferring its obviously better syntax and other UI improvements, because I still had to work with old bash and posix shell scripts day-to-day anyway.

                                  1. 4

                                    For the folks in this thread who found Fish was not compatible with their POSIX scripts: do you have a lot of functions that modify your shell’s state/environment, then? For me that’s limited to a few scripts related to virtualenv, changing directories, and setting the prompt. The other 95% does just fine as standalone scripts with #!/bin/sh as the hashbang.

                                    To avoid misunderstanding, I’m not really asking “why do/don’t you use X”. It is me wanting to see all the things folks do with their shell that could not be done as a script, so please Share All The Things That Come Under That Heading And That You Feel LIke Sharing :D

                                    1. 3

                                      The biggest offenders are the version-switchers for various languages–virtualenv, chruby/rvm/rbenv, nvm, etc. For some of these things, there are fish equivalents, but it remains a point of friction.

                                      The other annoyance with fish is that any time I have any problem with a shared script at work that works for everybody else, everyone assumes fish is the problem (which is rarely-to-never the case).

                                      But it’s still a great shell and I continue to use it.

                                    2. 4

                                      I’m just writing scripts for zsh or a non-shell language when I want to do more than one thing.

                                      fish has made 99% of my interactions at a shell prompt ‘just work’ with practically zero config, learning curve, or slowness.

                                    1. 4

                                      The decision to not try to entirely abstract the host away as some other languages do (Java for example, with respect to operating systems) has not in any way hindered the ability of different Clojure implementations to share code between them.

                                      This seems … patently false? For several years there was no way to conditionally execute code based on which runtime it was running under.

                                      1. 10

                                        Yeah, there is a lot of hand-waving in this piece. All implementations of Clojure other than the first-party JVM implementation are distinctly second-class citizens. The latest version of Clojure does not work with Graal–you have to use an older version and many of the most common Clojure libraries are not compatible. Clojurescript works OK in the browser, but most Clojurescript tooling was not designed with Node.js in mind. Code reuse between Clojure and Clojurescript kind of works unless your code needs to do any IO, at which point your Clojurescript becomes a nest of callbacks (and you don’t have access to the async/await stuff that makes async IO tolerable in Javascript).

                                        I like Clojure and have been using it professionally since 2014, but its strength is definitely in the core language concepts, not the implementation–and certainly not in having multiple compatible implementations, where it lags behind many, many other languages.

                                        1. 1

                                          FWIW the Graal issue is being worked on at the moment, slated for release in 1.11.

                                        2. 4

                                          I’m sure in those earlier years it was more of a struggle, but I’m speaking from the perspective of someone who started using Clojure in 2017. To me it’s been smooth sailing with .cljc files from the very beginning.

                                        1. 10

                                          The maker of the Iowa Caucus app was given $60,000 and 2 months. They had four engineers. $60k doesn’t cover salary and benefits for four engineers for two months, especially on top of any business expenses. Money cannot be traded for time. There is little or no outside help.

                                          This is the important bit. “Cheap, fast, good: pick two.” If the caucus wanted a better app, they’d have needed to invest a lot more time and money.

                                          1. 4

                                            I don’t think so: Even if you assume 10% bench time, that’s still a mean $81k salary which is above market rates (avg. software engineer salary in Des Moines is $75k). That still leaves revenue for a $80k salesperson with a $80k OTE and the company makes money.

                                            It is more than possible two months time isn’t enough to build a $360k mobile app for some people, but I certainly could’ve done it, and I probably would have for $360k.

                                            My guess: Either the persons who made the RFP didn’t anticipate their real requirements (uptime/availability, accuracy, etc), or The Maker really doesn’t know how to make software. Without looking at the RFP I wouldn’t venture to say, and my own experience doing government projects could have me believe either equally.

                                            1. 1

                                              Did you read that number right? It’s 60k not 600k.

                                              1. 4

                                                $60k for 2 months work is $30k/pcm. If I do 6 projects of that size a year that’s $360k/pa revenue. If I discount that by 10% (for running my business; my salesperson, overage, etc), that’s still $324k/pa I could budget for four people, or an average salary of $81k.

                                                I could certainly do this project in two months, and then do six more just like it in a year. That means if I went and did the RFP myself I could make $360k/pa doing projects like this.

                                                I’ve also done events though, so I know that even if the RFP says there’s going to be wifi available, it’s going to be shit. Someone who hasn’t might trust the RFP and the project will fail: Whose fault is that? It seems a bit unfair to blame the developer who writes to a spec where the spec is just ambitious/wrong, but it also seems a bit unfair to blame the RFP writer since they might have never done event software before either. I suppose I could blame the DNC for hiring idiots in the first place, but that’s a bit higher up the food chain than what we’re talking about: We have no idea what they’re paying their PM…

                                              2. 1

                                                None of the engineers at Shadow was based in Des Moines. They seem to have been based in Seattle, Denver, and NYC. $81k is not above market rates in those cities.

                                                1. 1

                                                  Do you have a link for that?

                                                  I searched their jobs page and saw offers for “remote” which is usually a sign they pay midwest rates.

                                                  I haven’t seen any news articles saying where the developers actually were.

                                                  1. 1

                                                    I was going by the developers associated with them on Linkedin.

                                            1. 2

                                              I used Google Reader and when it shut down, I exported my subscription list (in a standard format), imported that list into several other competitors until I found one I liked (Feedbin), and continued reading essentially without interruption. Isn’t that how interoperable standards are supposed to work? I would be thrilled if any newer social media stuff were as interoperable as RSS.

                                              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.

                                                                                  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