1. 14

    Actually a lot of people I know in skilled labor tend to employ it in off hours for fun. The carpenters & electricians will remodel their houses, the chefs cook, etc. Really that’s neither here nor there though…

    There’s multiple dimensions here really. There’s a difference between not coding outside work because you’re not passionate about it and because you choose to prioritize time differently. There’s a difference between not coding outside of work as a universal rule, and only doing it sometimes or rarely.

    There’s a difference between passion for side projects and passion for work.

    There’s also many different ways to be “passionate” and not all of them are healthy.

    When it gets down to it I’m inclined to believe they both have benefits. The benefits of passion are intuitive I think, but a certain sense of detachment and practicality can be good too.

    That of course doesn’t get into other aspects of it like building up a portfolio or socializing, but I don’t think that’s really what people are wondering about with this. There are other ways to achieve those ends.

    1. 1

      I agree with your analysis.

      A side project, for an experienced developer, means a nightly journey.

      The balance between what he learn and how tired he is at work might not be easy to measure.

      Still, in the right environment an hacker do not need a side project.
      If he cannot see a problem, he will not feel the need to fix it.

    1. 18

      I completely agree. The more I end up doing at work the less I end up doing on my own time. I am confident in my abilities to build, to learn, to grow, and the company that employs me believes in growing its employees. I spent a bulk of my free time on other stuff like audio production, photography, cooking, etc. You become one dimensional as a human if you only do one thing, and that goes for anything - not just software development.

      1. 17

        The more I end up doing at work the less I end up doing on my own time.

        I have definitely found this to be true, in a way. When my work project is interesting and clearly defined, meaning I am able to make good progress and feel like I’ve actually “done” something, I tend to write a lot less code on my own time. So programming on my own time is kind of a creative release “valve” that gives me an outlet when work doesn’t.

        1. 5

          Sometimes I satisfy my compulsion to create when it isn’t being satisfied at work by cooking.

          1. 4

            So programming on my own time is kind of a creative release “valve” that gives me an outlet when work doesn’t.

            This is exactly how it works for me.

            And if you see that I’m writing an operating system that aim to replace the whole stack from dynamic linking to JavaScript-enabled browsers with simpler and more effective solutions, you might get an idea about my deep frustration with hyped mainstream technologies.

            Without Jehanne I could simply explode.

          2. 5

            I also agree. I’m not experienced as some people since I’m just a junior developer but I’ve tried forcing myself to code in my free time and it just didn’t work out for me personally, either I would get burnt out and lose interest, or just not do it right at all. Now I’ve found other hobbies that I enjoy and do them when I can, and I’ve found that coding in my free time came from sudden ideas, like recently I’ve been coding a Discord bot and it has been slow going, but it’s been far more enjoyable than forcing myself to code at any given time.

          1. 5

            Preparing a talk about AI misconceptions and misuse for the University of Milan.
            Guys, it’s hard to fit in just 20 minutes!

            Also, looking for a CI solution to avoid this sort of mess to hit other Open Source contributors.
            I’m thinking of a script based on git blame and awk, but I’m not sure… it wouldn’t work if you add git rebase to the equation.

            1. 1

              Well, it’s very interesting to contrast this article with what happened to my copyright in Harvey.

              What a perfect timing!

              1. 4

                Sorry, but I think you’re overreacting a bit there.

                I think the question boils down to whether your remaining contributions constitute a derivative work.

                What this means in practice is that copyright claims are usually added only for substancial rewrites or entirely new files. When modifying an existing work in a way that does not make the result a derivative work in the legal sense, it is better to retain the original copyright and licence claim, i.e. fold the contributions into it. This is because ownership of copyright implies the power to change the licence of the work. So adding copyright statements is not something that should be done willy-nilly because otherwise anyone getting a one-line fix into a project could arbitrarily change the licence of the affected file (EDIT: Of course, copyright could nowadays be tracked to individual lines thanks to version control, but the legal rules involved are older than version control, and always up to interpretation by lawyers).

                You deserve recognition for your contributions, no doubt. But adding a copyright claim is not the only way to recognize a contribution.

                1. 1

                  Sorry, but I think you’re overreacting a bit there.

                  Well, if you feel that as an “overreaction”, do not visit Italy. Ever. It would be scary, to you. ;-)

                  Of course, copyright could nowadays be tracked to individual lines thanks to version control, but the legal rules involved are older than version control, and always up to interpretation by lawyers.

                  And this is exactly what I’m afraid of!
                  I don’t want a lawyer to sue me because he saw my code in my project and he trusts the (git rebased) Harvey’s repository more then mine.

                  There was a reason why I asked to git revert the commits when they said that they prefer to remove the contributions instead of fixing the attribution.

                  Many reasons, actually.

                  You deserve recognition for your contributions, no doubt. But adding a copyright claim is not the only way to recognize a contribution.

                  Sorry, but I think you have completely misunderstood the matter.
                  Not your fault, though.

                  I do not care about any recognition from Harvey’s team. Really.
                  My contributions were gifts. Hadn’t I suggested my friend to try Harvey, I would have never noticed the issue.

                  But they removed the few copyright statements I added back in 2015 and also removed the CONTRIBUTORS file that contained my name (because it was “too much trouble” to maintain it).

                  Had they moved, say, to GitLab after an unfortunate git rebase, I would have had an hard time to prove I’ve ever actually contributed a single line of those I reused in my project.

                  1. 2

                    I think you are now mixing up two different parts of the conversation.

                    Yes, they removed a lot of code with your copyright on it, and that was done correctly and you already said you had no problem with that. But this is not the part of the conversation I am talking about.

                    What I am talking about is your concern about some changes which were left in their source tree after your copyrighted code was removed: https://github.com/Harvey-OS/harvey/issues/698#issuecomment-365286356

                    You claim that they must add your copyright back to those changes, and what I am saying (and I think it is what dancrossnyc from Harvey is saying as well) is that your copyright claim on those changes is valid only if those changes consititute a “derivative work”. If they don’t, then no copyright claim can be made which extends on that of the original copyright on the codebase. Which means both you and Harvey are entitled to make these same “non-derivative-work” mechanical changes in your projects without risking copyright infringement. So I don’t follow your argument that your copyright claim must be on those changes in order to legally protect your derived project. Essentially, there was no reason to ever have your copyright on those specific changes in the first place.

                    Now, for contributions which are consiered a “derived work”, the situation is different, and this is why Harvy removed all of those changes we (you and me) both agree they should remove.

                    But you are still pursuing an argument with Harvey which boils down to the question of what constitutes a “derivative work”. I think it’s not worth having that argument for either side. Just chill. It seems they’ve already removed all they had to remove.

                    1. 2

                      No, sorry, I know there’s a lot of confusion and some contradictory statements in that issue, so it needs a careful read.

                      The statement

                      If you feel you can’t remove those changes because they are important for Harvey, you can still add my copyright statement to each of modified files.

                      was ironic.

                      I just wanted to point out that they had to use alternative solutions. That exist.

                      Btw, as I said otherwhere, I wont bore them anymore.

                      According to my lawyer, my github fork (frozen before the rebase) and the archive on the WaybackMachine should be enough to defeat in court any pretension on my code.

                      The medium post is, as it has been defined elsewhere, just “a cautionary tale”, for younger devs pondering to contribute to Open Source Software.

                      1. 1

                        why would you waste money on a lawyer for something you don’t even make money with. Your whole story is baffling.

                        1. 2

                          Well, I cannot measure everything I do with money. I have three daughters I love most.
                          I do my mistakes, but I know they learn from what I do, not from what I say.

                          But your is a good question, since I’m often called “greedy” just because I’m Ads Adverse.

                          My decision was pretty simple. And rational.

                          I pay the bills as a programmer.
                          Compared to the value of the time I’ve spent hacking for Harvey, the lawyer’s fee is tiny.
                          But compared to the value I put in my own fork, the time I spent for Harvey means nothing.

                          1. 1

                            Where I’m from trying to get value for your money isn’t considered greedy.

                            I respect you value your time invested, but I do think spending on it is a sunken cost fallacy, trying to recover an unrecoverable loss. In the future sign your commits and keep your version of the repository on github. Don’t be so concerned about what people do with your work unless it costs you real money in some way. That’s how I would do it anyway.

                            1. 1

                              I do not think that my contribution to Harvey was “an unrecoverable loss”.

                              I will keep to send bugfixes to Open Source Softwares that I use in the future.
                              Opportunistically, since I do not want to maintain them locally.

                              But I will not donate my time and skills to them again.

                              Obviously I won’t just look at the license they use!
                              I’ve worked very well with communities using all sort of license.
                              I’ve never checked before, but you can still see my name in php-mode, for example, 14 years after my introduction of PHP 5 support.

                              In the future I will look at the leaders, who they are, where they work…
                              I will consider to donate only if I’ll see they both trust and respect their developers and users.

                              And this will automatically exclude many big firms that treat their users as laboratory mice.

                              1. 1

                                Oh, as for GPG signing the commits, it’s a good idea.

                                But back then, in 2015, Harvey had a convoluted “standardized” workflow based on GerritHub.

                                It was so cumbersome that, after I managed to integrate travis-ci and coverity scan to Harvey, I fought against it very strongly. You might find something on the mailing list.

                                But given it used to break almost weekly, adding GPG signatures project wide was unrealistic.
                                They just required devs to sign-off commits.

                1. 5

                  My comment in another thread (sorry @Shamar, didn’t realize you had also submitted your blog post as a separate story): https://lobste.rs/s/yz7npb/gpl_enforcement_update#c_fdcggi

                  1. 1

                    Following up on the above: So @Shamar, my take would be that the test code you added in this commit is copyrightable, but s/uint32_t/uint64_t/ is not.

                    And I would also hope that adding ‘const’ to function parameters does not make the result a derivative work. You could probably find a lawyer who would support this claim though, as long as that laywer doesn’t know C.

                    1. 2

                      You could probably find a lawyer who would support this claim though, as long as that laywer doesn’t know C.

                      Well, the lawyer I consulted knows enough about these stuffs to suggest me to record the issue evolution in the WaybackMachine when I told him that they where using git rebase to remove me from the repository.

                      He is pretty smart, actually. ;-)

                      As for the const matter: are you sure you know the modifier’s semantic deeply enough? ;-)

                      The modifier enables several optimizations (they can vary depending on the compiler).
                      It was not supported by Ken-C.

                      My patch enabled these optimizations not only for the functions you can find in the ISO C standard (that btw was not supported, in any way, by the Harvey’s libc), but also for others that were specific for Harvey, such as all the rune related ones.

                      Now, I agree that my patch is the simplest possible way to enable such optimizations.
                      But not the only one!

                      If you barely know C, you know that there are several other ways to do the same. In a word: macros.
                      But if they really wanted to support ISO C, they had several other alternatives to address the optimization problem without using a patch that conflicted with mine. They have an ISO C library in APEX after all!

                      1. 2

                        Whatever the semantics of const are in various implementations of C, this question boils down to whether your change is a copyrightable “derivative work” or not. I suspect you can only determine the legal answer in a long court case. Do you really wanna go there, after they’ve already removed all code that everyone already agrees consitutes a derivative work? I think you’re blowing this out of proportion.

                        1. 1

                          No no no! As I said otherwhere, I wont bore them anymore.

                          According to my lawyer, my github fork (frozen before the rebase) and the archive on the WaybackMachine should be enough to defeat in court any pretension on my code.

                          The medium post is, as it has been defined by @mempko, just “a cautionary tale”.
                          For younger devs pondering to contribute to Open Source Software.

                          1. 3

                            I don’t think what you’re doing is encouraging younger devs to contribute to open source :(

                            1. 5

                              Indeed! I strongly suggest them to contribute to Free Software, instead!

                              1. 9

                                You had one problem with one project. Generalizing this experience to an entire class of communities doesn’t seem appropriate.

                                1. 2

                                  Please, read more carefully.
                                  I wrote:

                                  Free Software feels proud of each person that contributes.
                                  Whatever the license, a Free Software community will be very happy to add your name to their code base. Because you studied and changed the code.
                                  You made it useful. You are a sign of honor.
                                  They trust you. And respect you.

                                  On the other hand, Open Source managers are eager to take your code.
                                  But while your code becomes their asset, your copyright is a liability.

                                  I’m not generalizing to “an entire class of communities”.

                                  I’m saying that, whatever the license, you should not assume that you are working for a Free Software community that will trust and respect you.

                                  And, that you should really know what you are doing before contributing to Open Source Software leaded by big firms, because there you will probably be just another minion to use.

                      2. 1

                        Ah.. yes… since you cited the scheduling issue, please try to get their change with s/uint32_t/uint64_t/! ;-)

                        I don’t want to be a jerk, but as I wrote, I do not play poker. I try to back my statements with facts.

                        1. 1

                          please try to get their change with s/uint32_t/uint64_t/! ;-)

                          Well, what other change in that diff do you mean? This one?

                          -uint32_t tk2ms(uint32_t);

                          +#define tk2ms(x) ((x)*(1000/HZ))

                          Are you convinced that change must carry your copyright?

                          I don’t mean to be confrontational, I’m just trying to help you find a perspective on the matter that doesn’t leave you in a bad mood.

                          1. 1

                            No, problem.

                            What I mean is: open one the file modified files in that commit, eg sys/src/9/amd64pv/devarch.c or sys/src/9/k10/dat.h, at the state before the change and try to use s/uint32_t/uint64_t/ all over it.

                            You will notice that you had just broken the system.

                            Finding the right type to change was not trivial.
                            And I had to do some iterations, testing manually that everything was working in kernel and user space.
                            That’s why I wrote the test you cited.

                            Do you really think that work does not constitute a derivative work? Are you sure it was a trivial change not deserving any authorship?

                            1. 0

                              Yes, so copyright your test. Doesn’t that solve the problem?

                    1. 6

                      It may be the late hour, but I’m having trouble synthesizing the information presented here. It seems that Giacomo contributed some code to Harvey, a Plan9 fork, but then forked Harvey at some point to create Jehanne. He stopped paying attention to Harvey at some point after focusing efforts on Jehanne. A friend pointed out that Harvey’s attributions no longer included his name. He verified this and then posted an issue about it. The Harvey folks said something along the lines of “no big deal” and after some discussion, the Harvey folks decided that it would be better to remove all of his contributions than to attribute them to him. He pointed out that their rework didn’t really remove his contributions but rather reimplemented them minorly. Then he posted a blog post about it.

                      Does the Harvey team still have work to do if they want to actually mitigate a need to attribute to Giacomo?

                      1. 12

                        He laid it out cleanly in the end. Instead of respecting him and his contributions, they bitterly removed them. He feels the Free Software people respect contributors, while big corporate open source folks dont. I agree with his conclusion. It’s a cautionary tale.

                        1. 8

                          It’s a cautionary tale.

                          Exactly. But note that it’s not just a matter of Free Software’s ethics.

                          As I tried to explain them, if you use somebody else code without proper copyright statements, you pose a threat to their own right to use their code elsewhere.

                          1. 1

                            It sucks a lot but I think it’s something that we as contributors have to accept. Code changes. When our contributions are no longer present, there’s no longer a need to actively recognize those contributions. At least, that seems to be the terms of the license.

                            1. 10

                              except thats not what seems to have happened. They actively removed and reimplemented so the name isnt on the project. Thats some nasty stuff.

                              1. 4

                                They actively removed and reimplemented so the name isnt on the project. Thats some nasty stuff

                                Umm, no, that’s not nasty. It happens, sometimes for good reasons: https://marc.info/?l=openbsd-cvs&m=99118918928072&w=2

                                1. 3

                                  The point @stsp is not that they reimplemented my stuff. Surely they can!
                                  But their new implementation can be obtained by trivial, non recursive, modifications of my patches (that is: you can do that with notepad, you don’t even need for a regular expression).
                                  And, accidentally, their reimplementation work went mixed in few huge commits that were a squash of several commits from several authors.

                                  Now, I wont bore them anymore. But I really learned a lesson there.

                                  1. 1

                                    And if the parts of your patches they kept could be obtained by trivial, non recursive, modifications of their original code, what then?

                                    Your statement shows that you are applying the derivative work concept, but only where it favours your own cause.

                                    1. 4

                                      And if the parts of your patches they kept could be obtained by trivial, non recursive, modifications of their original code, what then?

                                      If you think that my patches can be obtained by trivial, non recursive, modifications of their original code, you didn’t look at the code at all…

                                      1. 1

                                        This is about parts of patches, not the patches as a whole.

                              2. 3

                                I cannot agree @colindean: I didn’t complain for the code they removed or replaced.
                                For example I ported zlib to Harvey and wrote a console filesystem in user space, and they properly removed them together with the copyright statements, here and here.
                                I’m fine with this: it’s their project, they are many different people, they can always choose better approaches.

                                What I cannot accept, is people using my code and patches (that I’m using elsewhere) without any attribution.
                                SCO teaches that things can get hairy in the long term.
                                And they are backed by Software Freedom Conservancy.

                          1. 1

                            Interesting prototype.

                            It’s also nice that the biggest AI-first company in the planet is starting to use proper technical language, talking about “calibration” instead of “training”.
                            It’s important to reduce the hype, addressing the anthropomorphization of these statistical tools.

                            However it’s rather weird that the solution proposed to restore trust of people in AI is a camera that can autonomously identify and record happy moments.

                            It is trying to get trust establishing an affective relationship of gratefulness toward the technology.

                            Not a rational understanding of the tools, but an irrational feeling of trust.

                            I won’t surprise if Google Clips will be heavily subsidized: Google won’t try to get a margin on it, as it’s more important to put one in every house soon, like a sort of cultural Trojan horse.

                            As for me, timeo danaos et dona ferentes.

                            1. 1

                              @paroneayea this is a great achievement! Congrats!

                              I’m not much a “socials” guy (I tried mastodon recently, and identi.ca a few years ago… but somehow the message/rumor ratio is always too low), but I’m curious about the federation technologies.

                              Where I can find something about the kind of problems these tools are trying to solve?
                              I mean, compared with email, mailing lists, web of trust and so on…

                              I can’t find anything from this perspective, but not being a “socials” user, this could help me to understand the architecture.

                              1. 18

                                I really love legacy, and have been working on a DOS application that is in use since 1986. I helped to patch the blob to solve clock frequency issues around 2005, and virtualized it completely in 2015 (now allowing the app to reach files and print over the network!)

                                I really hate legacy, and have found enormous amounts of garbage and myself struggeling not only with the incomprehensible and untangible structure of bloated software architectures, but also with consequent motivational problems. I even had to disappoint the customer, who invested a lot in me: despite the promising progress, fixing it for real would cost way too much.

                                Sometimes I like to tell junior programmers some war stories, especially when they complain when working with the code of others. I romanticize what I call “software archeology,” and declare my love of unraveling the mysteries hidden behind the unknown. This I do for two reasons: I hope to motivate them beyond the point of misery (the trap, in which you believe you can not deal with the problem, and give up) and I hope to give them another perspective, as follows.

                                Legacy is something to be proud of. It is the work of a precious generation (be it 30 years or 6 months ago), which dealt with perhaps completely different circumstances. Respect their work, just as you wish others will respect your own. Instilling this picture, that legacy is something great and is what you ultimately hope to produce, might result in work that one can be proud of: work that builds upon the great work of others, and tries to improve upon it!

                                1. 4

                                  “Your code could be legacy some day!” is a legitimate motivational phrase, in my opinion. There’s often a lot wrong with legacy code, but that’s because you’re often looking at it from a very different perspective. Understanding the original authors’ viewpoint is important. You might call it “code empathy”.

                                  1. 1

                                    I have made similar experiences with dealing with legacy. It’s easy to complain about certain design decisions, but really, sometimes it just seemed like a good idea at the time. Much can be learned from legacy code, too. Tricks that nobody uses today, space and memory optimization and such.

                                    Grab a copy of some 70s or 80s source code and go to town with it sometime. Bring it into the 21st century. Enjoy the journey.

                                    1. 1

                                      Realizing that legacy code is code that did served well it’s purpose, is part of our path to professionalism.

                                      But IMHO, this should not stop us to rethink things.

                                      Most of complexities of modern software (and most of it’s flaws) come from legacy decisions that we didn’t challenge.

                                      And I’m not only talking about JavaScript in the browsers, but even about things like dynamic linking, root users, using HTTP to deliver computations and so on…

                                      All useful things, when they were thought. But today we can do it better.

                                      1. 1

                                        You know, I did get a pretty uplifted feeling reading that. The respect point is both incredibly spot on, and incredibly not the norm.

                                        1. 1

                                          Yes! I often really enjoy working in fifteen year old legacy code for exactly that reason. Sure the abstractions may not be great, but it is useful code that has served the company well all that time. My main job when working in legacy code is to not break what it gets right.

                                          1. 1

                                            This is all fine, but what turned me off a bit wrt consulting is a high frequency of modernizing legacy.

                                            The code did not appear in a vacuum and there are always some of the original forces in place; budgets and schedules and such. Tradeoffs have to be made, and often these include not taking the upgrade path all the way to the latest version.

                                            This leads to boredom, although the customers are always super and their domains where they work different from each other. It also raises the barrier to invest time in the latest and greatest, since the bulk of it would have to be done out of passion on free-time hobby projects.

                                          1. 1

                                            Exploring the design space of the new file protocol for Jehanne.
                                            The only decision so far is it’s name: File Protocol. It has an important property: FP reminds 9P in hex. :-D

                                            Also, I’m coping with the unexpected reception of an (unrelated) article about AI.

                                            1. 3

                                              Wow, I’ve rarely seen such an angry email from Linus. Last time it got close was with Nvidia. In a way it’s oddly reassuring to know that the Linux kernel is guarded by such a tough Cerberus.

                                              1. 18

                                                Cerberus seems to be biting all directions a little mindlessly, though. Reading the followups is interesting:

                                                http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04630.html

                                                You’re looking at IBRS usage, not IBPB. They are different things.

                                                Seems to be the victim of a mixup during reading. The response is appropriately meek:

                                                http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04637.html

                                                Ehh. Odd intel naming detail.

                                                1. 9

                                                  To my untrained eye, these considerations seem pretty polite and technically rooted.

                                                1. 3

                                                  This is relevant to a side project of mine. I wanted to train a neural net Q-learner (with no pre-training or stuff-I-know-about-the-game feature engineering) to play Ambition. To add slightly (actually, only slightly) to the difficulty, I’ve been rolling my own libraries for statistics and linear algebra, because I want it to run in “just plain C”, out of the box, so people can ideally download a small set of files and not only play against the AI, but improve it. Stats and linear algebra aren’t hard to write; but it’s a bitch to debug, e.g. a backprop algorithm written in C that seg-faults because you wrote malloc(n_weights * sizeof(double)) as opposed to malloc((n_weights + 1) * sizeof(double)), forgetting the bias. It’s also disgustingly easy to write algorithms that compile, run, and fully look like they work but, e.g. fail to update biases in hidden layers.

                                                  So far, no luck. That’s after checking the obvious– was the backprop correctly getting the gradient? yes. was the learning rate reasonable? yes. I had about 600 dimensions and tried to get it to learn a heuristic, and it came out with some overfitting, whilst spitting zeros (i.e., not learning anything, and minimizing error by guessing the mean) on validation data. It’s not surprising to me that I ran into this difficulty. The universal do-my-homework machine doesn’t exist, and the more one learns about neural nets, the more one realizes just how much data they need to train (and how much work it takes).

                                                  A more hybrid approach– mixing automated function-learning in small spaces (< 20 dimensions) with prior knowledge about the game, in order to build a painstaking but reliable MCTS player– would have worked much faster for my particular problem; but I wanted it to teach me about the game. So far, no luck. But I’m far from out of ideas.

                                                  Neural nets are good for images because, especially if we use convolutional topologies, we can specify translation and rotation invariance. Those are also high-dimensional spaces where a few features are meaningful, but hard to specify in “this implies that” terms. Pixel (383, 110) means absolutely nothing, except in relation to Pixel(383, 109). Hence, convolution. Neural nets can also be good with games because the program can generate new data by playing against itself. It can still do a bad job of exploring the strategy space (reinforcement learning is far from a solved problem) but the classical danger of overfitting to a small training set isn’t there; your training set is effectively infinite (although, if it explores the strategy space poorly, biased).

                                                  Are NNs the best function approximators in general? Sadly, I think they’re often not. That’s something I’m exploring: sparse neural nets and evolutionary algorithms. With fully-connected layered networks, not only is there a risk of overfitting (which is a fancy word for “finding a too-complex function that fits the training data beautifully, but performs badly on new data”), but it’s computationally expensive to update tens of thousands of weights each step and evaluate a function where you know that much of the work cancels out other work.

                                                  Real talk: If you have “only” 1,000,000 training points in a noisy space, and 10,000 input dimensions– that’s 75 GB of data– even ordinary linear regression is likely to overfit. (You can regularize, but now you have to tune the hyperparameters.) You can’t reasonably fit more than a few hundred features– which may be quadratic interaction terms or non-linear transfer functions, but won’t all be transforms of linear combinations of transforms of linear combinations of transforms of …– and neural nets get you nowhere in picking the right ones. Neural nets try to regularize with early stopping (quitting “optimizing” when performance falters on a validation set) but that often means that you’re at risk of quitting when it has barely learned anything (more than a linear model would) if only because it’s starting to learn “wrong” things.

                                                  For an example where neural nets do a great job of fitting training data, but don’t make sense outside of it, use the XOR set, {(0, 0) -> 0, (0, 1) -> 1, (1, 0) -> 1, (1, 1) -> 0}. What’s the “best” interpolation of the never-seen value of (0.5, 0.5)? I would say that it’s 0.5; the simplest interpolation function is a quadratic with a saddle-point there, in the middle. You want the simplest, “tightest”, function for interpolation. But train a neural net, and you’ll quickly get one that gets those four points perfectly; but as for (0.5, 0.5)? All bets are off. Traditional neural network applications end up needing to use multiple tiers of segregated data– training, topology validation, method validation, a true test set; then, finally, independent tests or a production environment which are the truest of true test sets– but this has its own issues. If nothing else, it takes forever unless you’re at a Facebook-level quantity of resources (computation and data).

                                                  To show that your neural network is not “trained to discriminate” you simply have to declare the function you tried to approximate and

                                                  • provide (and thus safely store, for years) the whole data sets used to calibrate the network, including the one used for cross-validation;
                                                  • provide (and thus safely store, for years) the initial values you choose for each topology you tried, and obviously the topologies;
                                                  • disclose the full source code, with documentation;
                                                  • hire an independent team of experts to verify the whole application.

                                                  The issue here is that, if a neural network’s parameters and topology are known, it’s relatively easy to concoct an adversarial example that it gets wrong. Imagine explaining the brilliance of your self-driving car in court, and then watching as the opposing counsel presents a “Speed Limit 70” sign that it mistakes for a deer about to run across the road.

                                                  I think that there’s a metacognitive issue here with the hype around “machine learning”. A few people in the world (I’m not one of them) deeply understand multilayer, fully-connected networks– what they can do, what they can’t do– in a way that requires years of experience, and all the tricks necessary to make them work on noisy data in the real world. Many more people– especially in the anti-intellectual environment of the corporate world, where taking time to understand things is the sin of “learning at work”– see NNs as an all-purpose do-your-homework algorithm (as opposed to all that “boring” stuff in the Hastie book that every data scientist calls “The Bible” and, like the Bible, few who claim to adore it have actually read) that’s more mystical than boring logistic regression coupled with domain-specific feature engineering. Neural nets are great at some things but, for many problems, they require either a massive amount of handholding or an extreme supply of computing resources to train effectively.

                                                  1. 1

                                                    The issue here is that, if a neural network’s parameters and topology are known, it’s relatively easy to concoct an adversarial example that it gets wrong. Imagine explaining the brilliance of your self-driving car in court, and then watching as the opposing counsel presents a “Speed Limit 70” sign that it mistakes for a deer about to run across the road.

                                                    Good point: an adversarial example easily falsify a declaration about the target function of the neural network.
                                                    This has obvious application in digital forensics, but even worse, it could be used as a weapon!

                                                    Suppose a self-driving car fooled by a constructed toy that can be easily removed after the car crash.

                                                    However, I don’t foresee a future where the insurance requires that an artificial intelligence drives your car.
                                                    Not because of technological issues with this, but because the automobile manufacturers would be directly liable of deaths occurred in their cars by default.

                                                    And I guess they don’t want this to happen.

                                                  1. 10

                                                    Good article, here were the key points that stood out to me:

                                                    The words we use to describe the reality forge our understanding of it.

                                                    Absolutely agree, though I would say “the words we use forge the story we convince ourselves is reality”.

                                                    Pulling back the poetic imagery and talking about ML approaches as simply statistical approaches is highly clarifying. And spelling it out as “neural networks approximate a function between two sets”, it’s a lot easier to see how limited certain projects are, like the discrimination example you provided. The technique doesn’t approximate how “risky” an individual is, it approximates how we perceive the riskyness of individuals. Which, surprise! is highly biased, especially relating to race.

                                                    Your points about responsibility are especially pertinent. Without substantial evidence (as you outline) the tools are just moving bias from one place to the other, and the people choosing to make choices based on that evidence are responsible for that choice.

                                                    1. 5

                                                      the tools are just moving bias from one place to the other

                                                      The funny part is that, by moving the prejudice in the machine, we make it observable.

                                                      When somebody talks about the risks of AI, he diverts attention from the true danger: the people using it.

                                                      1. 3

                                                        Yes an AI should never be responsible, only the people who trained it and the people who use it. After all if it could reason and think on its own it really shouldn’t be owned.

                                                    1. 7

                                                      I wrote the user-space emulation of non blocking IO for Jehanne, and now I’m looking for more tests.

                                                      Please share links to POSIX C code that uses non blocking IO.
                                                      Any small program that exit(0) iff non-blocking IO works will help.

                                                      1. 2

                                                        The screenshot link on your front page is down.

                                                        If I have time some time this week, I’ll swap out 9front for Jehanne for my occasional “Plan 9” hacking explorations. I’ve been curious how things are going over there.

                                                        1. 2

                                                          It’s not down, it’s sadly “work in progress”… that is: I had no time to write the page down.
                                                          Sorry… I can either code or edit the web site, and I usually prefer to code. :-(
                                                          I’ll try to give it a shot asap.

                                                          Thanks for trying Jehanne!
                                                          Just beware that it is really unstable, by design.
                                                          And I’m going to change it deeply in 2018. So do not use in production. :-)

                                                          OTOH, 9front is the most stable evolution of Plan 9.
                                                          I imported a lot of their improvements, but if you are looking for a Plan 9 system, you might be disappointed.

                                                          I mean: if Plan 9 from Bell Labs were Homo Sapiens, 9front would be Homo Sapiens Sapiens.
                                                          Jehanne would be a race of Elves.

                                                          1. 2

                                                            Just beware that it is really unstable, by design.

                                                            I’m very aware, but 9front is already in my “for fun” bucket, with things like Haiku and DragonflyBSD, so that’s fine. (Honestly, to a point, it’s almost better, because it means the community is probably actively having some fun and not entrenched in process yet, and the last thing I’m looking to do in my spare time is to learn or contribute to Yet Another Unix that’s almost but not exactly like what I do for work each day.)

                                                          2. 1

                                                            Just added a screen shot at http://jehanne.io/pages/screenshot.html

                                                            Also, the link in the front page should work now.
                                                            This is marketing, dude! :-D

                                                            (it has been work in progress for more than two years!)

                                                        1. 1

                                                          Some years ago I wrote about this topic too.

                                                          I still think that you should not even measure coverage if you don’t know what TDD is for.

                                                          1. 25

                                                            I used to do the things listed in this article, but very recently I’ve changed my mind.

                                                            The answer to reviewing code you don’t understand is you say “I don’t understand this” and you send it back until the author makes you understand in the code.

                                                            I’ve experienced too much pain from essentially rubber-stamping with a “I don’t understand this. I guess you know what you’re doing.” And then again. And again. And then I have to go and maintain that code and, guess what, I don’t understand it. I can’t fix it. I either have to have the original author help me, or I have to throw it out. This is not how a software engineering team can work in the long-term.

                                                            More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member. If you can’t understand the code now, you can bet dollars to donuts that any new team member or new hire isn’t going to either (the whole team must be able to read the code because you don’t know what the team churn is going to be). And that’s poison to your development velocity. The big mistake people make in code review is to think the team is bound by the strongest team member code-wise too and defer to their experience, rather than digging in their heels and say “I don’t understand this.”

                                                            The solution to “I don’t understand this” is plain old code health. More functions with better names. More tests. Smaller diffs to review. Comments about the edge cases and gotchas that are being worked around but you wouldn’t know about. Not thinking that the code review is the place to convince the reviewer to accept the commit because no-one will ever go back to the review if they don’t understand the code as an artifact that stands by itself. If you don’t understand it as a reviewer in less than 5 minutes, you punt it back and say “You gotta do this better.” And that’s hard. It’s a hard thing to say. I’m beginning to come into conflict about it with other team members who are used to getting their ungrokkable code rubber stamped.

                                                            But code that isn’t understandable is a failure of the author, not the reviewer.

                                                            1. 7

                                                              More succinctly: any software engineering team is upper-bound architecturally by the single strongest team member (you only need one person to get the design right) and upper-bound code-wise by the single weakest/least experience team member.

                                                              Well put – hearing you type that out loud makes it incredibly apparent.

                                                              Anywhoo, I think your conclusion isn’t unreasonable (sometimes you gotta be the jerk) but the real problem is upstream. It’s a huge waste when bad code makes it all the way to review and then and then needs to be written again; much better would be to head it off at the pass. Pairing up the weaker / more junior software engineers with the more experienced works well, but is easier said than done.

                                                              1. 4

                                                                hmm, you make a good point and I don’t disagree. Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself? (Although I do acknowledge that expressive, well-structured and well-commented code should strive to bring complicated aspects of the problem domain into the picture, and not leave it up to assumed understanding.)

                                                                1. 3

                                                                  I think your point is very much applicable. Sometimes it takes a very long time to fully understand the domain, and until you do, the code will suffer. But you have competing interests. For example, at some point, you need to ship something.

                                                                  1. 2

                                                                    Do you think the mandate on the author to write understandable code becomes weaker when the confusing part is the domain, and not the code itself?

                                                                    That’s a good question.

                                                                    In the very day-to-day, I don’t personally find that code reviews have a problem from the domain level. Usually I would expect/hope that there’s a design doc, or package doc, or something, that explains things. I don’t think we should expect software engineers to know how a carburetor works in order to create models for a car company, the onus is on the car company to provide the means to find out how the carburetor works.

                                                                    I think it gets much tricker when the domain is actually computer science based, as we kind of just all resolved that there are people that know how networks work and they write networking code, and there’s people who know how kernels work and they write kernel code etc etc. We don’t take the time to do the training and assume if someone wants to know about it, they’ll learn themselves. But in that instance, I would hope the reviewer is also a domain expert, but on small teams that probably isn’t viable.

                                                                    And like @burntsushi said, you gotta ship sometimes and trust people. But I think the pressure eases as the company grows.

                                                                    1. 1

                                                                      That makes sense. I think you’ve surfaced an assumption baked into the article which I wasn’t aware of, having only worked at small companies with lots of surface area. But I see how it comes across as particularly troublesome advice outside of that context

                                                                  2. 4

                                                                    I’m beginning to come into conflict about it with other team members

                                                                    How do you resolve those conflicts? In my experience, everyone who opens a PR review finds their code to be obvious and self-documenting. It’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles. The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                    1. 2

                                                                      Not well. I don’t have a good answer for you. If someone knows, tell me how. If I knew how to simply resolve the conflicts I would. My hope is that after a while the entire team begins to internalize writing for the lowest common denominator, and it just happens and/or the team backs up the reviewer when there is further conflict.

                                                                      But that’s a hope.

                                                                      1. 2

                                                                        t’s not uncommon to meet developers lacking the self-awareness required to improve their code along the lines of your objections. For those developers, I usually focus on quantifiable metrics like “it doesn’t break anything”, “it’s performant”, and “it does what it’s meant to do”. Submitting feedback about code quality often seems to regress to a debate over first principles.

                                                                        Require sign-off from at least one other developer before they can merge, and don’t budge on it – readability and understandability are the most important issues. In 5 years people will give precisely no shits that it ran fast 5 years ago, and 100% care that the code can be read and modified by usually completely different authors to meet changing business needs. It requires a culture shift. You may well need to remove intransigent developers to establish a healthier culture.

                                                                        The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                        This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                                                                        1. 1

                                                                          The result is that you burn social capital with the entire team, especially when working on teams without a junior-senior hierarchy, where no one is a clear authority.

                                                                          This is a bit beyond the topic at hand, but I’ve never had a good experience in that kind of environment. If the buck doesn’t stop somewhere, you end up burning a lot of time arguing and the end result is often very muddled code. Even if it’s completely arbitrary, for a given project somebody should have a final say.

                                                                          I’m not sure.

                                                                          At very least, when no agreement is found, the authorities should document very carefully and clearly why they did take a certain decision. When this happens everything goes smooth.

                                                                          In a few cases, I saw a really seasoned authority to change his mind while writing down this kind of document, and finally to choose the most junior dev proposal. And I’ve also seen a younger authority faking a LARGE project just because he took any objection as a personal attack. When the doom came (with literally hundreds of thousands euros wasted) he kindly left the company.

                                                                          Also I’ve seen a team of 5 people working very well for a few years together despite daily debates. All the debates were respectful and technically rooted. I was junior back then, but my opinions were treated on pars with more senior colleagues. And we were always looking for syntheses, not compromises.

                                                                      2. 2

                                                                        I agree with the sentiment to an extent, but there’s something to be said for learning a language or domain’s idioms, and honestly some things just aren’t obvious at first sight.

                                                                        There’s “ungrokkable” code as you put it (god knows i’ve written my share of that) but there’s also code you don’t understand because you have had less exposure to certain idioms, so at first glance it is ungrokkable, until it no longer is.

                                                                        If the reviewer doesn’t know how to map over an array, no amount of them telling me they doesn’t understand will make me push to a new array inside a for-loop. I would rather spend the time sitting down with people and trying to level everyone up.

                                                                        To give a concrete personal example, there are still plenty of usages of spreading and de-structuring in JavaScript that trip me up when i read them quickly. But i’ll build up a tolerance to it, and soon they won’t.

                                                                      1. 6

                                                                        Adding non blocking IO to Jehanne, a Plan 9 derivative voted to simplicity.

                                                                        Thanks to the great developer behind MirBSD, I recently managed to port mksh.

                                                                        1. 1

                                                                          Do the changes made in Jehanne (vs. the other Plan 9 descendants) make it any easier to compile and run a modern web browser? It seems like this is the stumbling block all alternative OSes are tripped up by these days.

                                                                          1. 2

                                                                            It obviously depends on which browser, but I think so.

                                                                            RedHat’s newlib is battle tested on Cygwin, so Jehanne has a true “standard” C library to build upon.
                                                                            The rest is “just a matter of workforce”.

                                                                            But do not hold your breath: porting Firefox (my favorite) is very low in my priorities.

                                                                            I do not care much about web browsing in Jehanne, as I want to replace the web! ;-)

                                                                            1. 1

                                                                              Thinking more about this I’ve realized that all Plan 9 descendants seems to share a sort of dislike for the web.

                                                                              It should be noted that my daily job is as a C#, JavaScript, and $whatEverYouPayFor developer and I pay the bills building finance applications for large companies, mainly banks. I fight with everything between IE8 and Chromium on a daily basis. And I often have to remote desktop over remote desktop over remote desktop in vpn, for security reasons.
                                                                              I know JavaScript very well. We are good enemies. Like Harry Potter and Tom Riddle.

                                                                              So maybe I’m a bit biased too.

                                                                              But in my defense, you should consider that Jehanne (like Plan 9, 9front, and friends) is a distributed OS.

                                                                              We do not care about world domination, just about progress.

                                                                              The web will always be there (we still have Gopher after all!), and nostalgics will keep using rdesktop and xhost.

                                                                              In a distributed computation experience, the OS you use for any particular task should be a detail.

                                                                            1. 2

                                                                              To save people the click for (a reminder) what Jehanne is:

                                                                              Jehanne is a simple operating system.

                                                                              Jehanne has noble ancestors:

                                                                              • most of userland tools, a lot of wisdom and some kernel modules, come from 9front

                                                                              • the kernel is a fork of Charles Forsyth’s Plan9-9k

                                                                              • most of the build system and some valuable piece of code come from Harvey OS

                                                                              1. 2

                                                                                Well actually I’ve updated the overview page too: http://jehanne.io/pages/overview.html

                                                                                To save clicks, TL;DR

                                                                                Jehanne is a simple operating system.

                                                                                It shows that few orthogonal abstractions can be composed to provide everything you want from modern operating systems. And more.

                                                                                The emphasis is really on simplicity.

                                                                              1. 42

                                                                                Reminds me of a quote:

                                                                                Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

                                                                                • Brian W. Kernighan
                                                                                1. 13

                                                                                  :) Came here to post that.

                                                                                  The blog is good but I’m not convinced by his argument. It seems too worried about what other people think. I agree that we have to be considerate in how we code but forgoing, say, closures because people aren’t familiar with them or because we’re concerned about how we look will just hold back the industry. Higher level constructs that allow us to simplify and clarify our expression are a win in most cases. People can get used to them. It’s learning.

                                                                                  1. 8

                                                                                    I think he may not disagree with you as much as it sounds like. I don’t think that sentence says “don’t use closures,” just that they’re not for impressing colleagues. (It was: “You might impress your peers with your fancy use of closures… but this no longer works so well on people who have known for a decades what closure are.”)

                                                                                    Like, at work we need closures routinely for callbacks–event handlers, functions passed to map/filter/sort, etc. But they’re just the concise/idiomatic/etc. way to get the job done; no one would look at the code and say “wow, clever use of a closure.” If someone does, it might even signal we should refactor it!

                                                                                    1. 5

                                                                                      It seems too worried about what other people think.

                                                                                      I agree with your considerations on learning.
                                                                                      Still, just like we all agree that good code must be readable, we should agree that it should be simple too. If nothing else, for security reasons.

                                                                                    2. 2

                                                                                      On the other hand, sometimes concepts at the limit of my understanding (like advanced formal verification techniques) allow me to write better code than if I had stayed well within my mental comfort zone.