1. 6

    I would pay pretty money for an upscaled version of DS9. Not that I need an excuse to watch it again for an umpteenth time.

    1. 4

      Over the years I found that promotions and raises are disconnected from your worth as a professional and are the results of political scheming.

      Certifications and degrees are means to achieve personal growth but not a measure of career growth.

      I added the following dimensions to evaluate my career growth:

      • How much freedom I have to explore new/innovative technologies and use them in a production settings.
      • How much freedom I am given to manage my own time and to work from a place of my choosing.

      Time and intellectual freedom is the ultimate currency because it is absolutely finite and is based on professional trust.

      1. 10

        I overall agree with the post except for the following:

        Claiming there isn’t enough is a great way to look like you’re trying to help but not have to do anything.

        Unsubstantiated bug reports also encourage buck-passing behavior between departments. I wasted enough time in my career digging down root causes of bug reports passed along to me by other team members to finally discover that the issue was within components under their purview.

        Now I consider common courtesy to provide developers with a minimal scenario that reproduces the bug or, when not possible, sufficiently detailed information surrounding the failure so as not to waste the developer’s time.

        The fact that most large OSS projects request the same courtesy from their bug reporters (GCC comes to mind) comforts me in my decision.

        1. 4

          Sometimes the end-user is not-so technical, and mostly unable to grok the indications to reproduce the problem:

          Dev: can you provide me the .log files?

          User: what are logs? where are they? how to open .log files? what? no! I won’t ship you my device (was that what you were asking?).

          Issue: (after 3 weeks) “pending information from client” -> “cannot reproduce”

          1. 5

            In that case the dev should work with the user to repro the issue. Break down the communication wall!

            1. 3

              I like this way to do it. That leads to a bugfix. While it is good to avoid bothering the non-tech user with technobabble, sometimes there is simply insufficient data for meaningful answer…

              1. 3

                Yeah, part of the dev’s job is to extract info from the user but not spout babble at them. Explaining things simply is always a good skill to have.

                1. 3

                  Also a really damn hard one. It tends to pay dividends though.

        1. 11

          Thanks for posting! I wrote this with the help of some wonderful contributors. I’d be happy to work on any feature requests or answer any questions.

          1. 13

            Indeed, I’m excited and impressed at the the contributions to neovide. This is a case where Nvim’s decoupled architecture seems to bear fruit (which isn’t always totally obvious :)–people can fully embrace new ecosystems like rust without being blocked by Nvim’s tech stack.

            Recently https://github.com/equalsraf/neovim-qt/ (c++) has been picking up steam as well thanks to some talented contributors.

            For more on Nvim arch see also: https://lobste.rs/s/gchgjr/switch_sway#c_df7js3

            1. 8

              I can not say enough good about neovim’s design. By taking care of the text editing part, I can focus on the front end concerns such as font selection, glyph calculations, and text rendering. Zero to functioning text editor was really fast as well so it was easy to get started

              I highly recommend making a neovim gui as it gives you a better understanding of how things work in the text editor. @jmk and company have been doing amazing work

            2. 1

              I immediately gave it a shot as I am avidly looking for a nvim GUI interface with good performance and ligature support, but was greeted with a SIGSEGV on OS X 10.15.3. It looks like a know issue, so I’ll keep my eyes peeled.

              1. 1

                Wanna help debug? I don’t have access to a mac and so am kind of at a loss for how to fix this. I think it has something to do with font-kit, but I don’t have any way to know beyond that

            1. 5

              It’s rare that I find myself less in disagreement with an “… about software engineering” laundry list.

              Most measures of success are almost entirely uncorrelated with merit

              This one I think is a nugget which only become obvious after years of experience in the business. Understanding this is also, IMHO, the first step to reach a better appreciation of self-worth and work-related accomplishments.

              1. 9

                A BIG oof about this. I really loved actix for what it was doing for the rust community. But I also shaked my head about how ignorant some of the creators replies seemed to be, when people tried their hardest to point out why a specific usage of unsafe wasn’t right. Still I always kept using actix, because I think that in itself it was a nice project and improving it will eventually remove all its UB. This reminds me of systemd for some reason.

                Obviously there was also too much shitstorm about actix itself, so I can’t blame them for complaining about how people started to treat actix.

                I’ll have to transition some projects. Guess I won’t have to do the async/await switch for the actix code anymore.

                1. 3

                  Even if the code was unsafe and the author impermeable to the remarks, it’s his code and therefore his right. Users of his code are not entitled to anything. If the users don’t like it, they can fork it and do as they please. Expecting anything more is preposterous.

                  1. 2

                    Are there actual exploits for any the unsafe code? Or is it the usual Rust cargo cult over reaction?

                    1. 5

                      Both. Issues got proven to be exploitable from userland.

                      1. 9

                        I wouldn’t go as far. It was proven that there’s a usage pattern that would trigger UB if the user used it this way. The pattern in itself is unlikely and probably not present in any application out there.

                        So there’s no general path to exploiting actix-based applications in general.

                        It’s basically equivalent to the openssl side of heartbleed: if you use openssl wrong, it is exploitable, you are still using it wrong. Given that the actix-web API didn’t seem to be intended for library clients use, it’s even less likely.

                        Not arguing that it shouldn’t be fixed, but let’s be realistic about the impact.

                        1. 4

                          It was proven that there’s a usage pattern that would trigger UB if the user used it this way. The pattern in itself is unlikely and probably not present in any application out there

                          From a security engineer’s point of view, doesn’t that constitute “completely broken”?

                          1. 6

                            No. You are literally flying planes or driving cars based on systems with potentials for such bugs. There’s usually expensive tooling around the “don’t do this, then” (linters and such).

                            1. 4

                              User here refers to the developer using the library, not the user interfacing with the resulting web service. Under normal circumstances (that is, not a contrived example code snippet) it’s not broken, but it requires some amount of care that the problematic pattern wasn’t used somewhere in spite of it being unusual.

                              strcpy isn’t “completely broken” and for a given use of it it’s possible to reason that it is safe (if it is). Still, a security engineer would recommend (and at some point: demand) not to use it to reduce the amount of reasoning required (and remove the code smell). The issue at hand in actix is much less worrisome than strcpy in terms of being able to shoot yourself in the foot.

                              AIUI the author was interested in handling this, but on their own terms. Apparently that wasn’t enough for some and so they cranked up the internet rage engines.

                              1. 3

                                from a security engineer’s perspective we would talk about Likelihood or Difficulty (both of Discovery and of Exploitation) as well as Impact; you may see other metrics thrown in like Confidentiality, Integrity, and Availability.

                                If the user must use a specific library in a problematic way, that usually constitutes a Likelihood of Very Low/Low or a Difficulty of High; basically, yes, this could be bad (Impact of High), but the Likelihood of a user doing that may be very low. Security people who speak in absolutes are usually trying to sell you something or not very effective at their jobs.

                      1. 16

                        This piece is from 2013…. before Satya Nadella took over (2014). I would be extremely interested to get a fresh take on this after 6 years under his management.

                        1. 39

                          When this post was written, several people asked if it was me. It wasn’t, but I shared a lot of the same frustrations. To go over some of the specific things:

                          • In terms of Satya specifically, the culture has changed a lot. Today people are measured on how approachable, reasonable and cooperative they are. Dismissing outside contributions without good reason would no longer be a good career move. That said, culture change is a long and hard process, and some groups have made more progress than others.
                          • The compiler is now building more modern C support.
                          • The original comment talks about how hard it is to improve CMD; today the console (but not CMD) are on Github and outsiders (including me) have contributed to them.
                          • Moving away from dedicated test teams has plenty of problems, but it removes one source of pushback for outside contributions. A contribution is no longer a gift with a cost attached.
                          • Symbolic links are available to non-Administrators, although the documentation says this is restricted to Developer Mode, which seems like a step sideways.
                          • Windows really did move to a Git client with a TFS backend, and made substantial changes to both to make it happen.
                          • NTFS is still a giant SEH monster, but kudos to the developers who work on it. They have a hard job.
                          • In 2013 a lot of the benefits of ReFS weren’t apparent because it was still being developed. Today it really addresses a lot of NTFS limitations, including fine grained valid data, file level duplication where blocks are shared across files and diverge on write, and support for SMR drives. I was working on this in 2013, but deserve no credit for what happened since, and I think that team have delivered a lot in difficult circumstances.

                          On a personal note, a long time ago I wrote resizable dialog support outside of work to demonstrate that it wouldn’t be hard to retrofit things like the environment variable editor to be resizable. My day job was writing kernel drivers. My manager didn’t appreciate what I was doing there, and had the same reaction this post alluded to - that I should stick to my defined role. Post-Satya, I ended up contributing that code into what is now the environment variable editor. In fairness, when kernel developers write UI, some bad things happen too - I didn’t handle some high DPI cases, missed one way this could be invoked which broke a workflow I didn’t know about, which other developers ended up fixing. The team who took my change ended up paying a price for it, which kind of sucks. But it did go from essentially impossible to possible.

                          I would say though that one thing the post touched on is more true than ever. Windows is getting older. The number of people who were around when the system was designed is shrinking. There’s nothing anyone can do about that, but it’s challenging when smart, motivated, capable young people are stepping into a large scale codebase. Some level of fear is inevitable and even justified. It’s very hard to find somebody who is so smart to step into a million lines, distill all of the design considerations, then start changing them - we do find some people like that, but they’re rare. And it still seems true that this creates an incentive to add a new thing rather than to fix the old thing.

                          Just my 2c.

                          1. 2

                            Windows is getting older. The number of people who were around when the system was designed is shrinking. There’s nothing anyone can do about that, but it’s challenging when smart, motivated, capable young people are stepping into a large scale codebase. Some level of fear is inevitable and even justified. It’s very hard to find somebody who is so smart to step into a million lines, distill all of the design considerations, then start changing them - we do find some people like that, but they’re rare.

                            Would you say this is less of a problem with Linux? And in that case, why?

                            1. 5

                              Linux, in the broad ecosystem sense, comprises a lot of modular components. When one module stops being maintained, a new one can be developed, people migrate to it over time, and the old one goes away. We see this happen often enough with things like mail server components.

                              The expectation of Windows to maintain compatibility for longer means that there’s no mechanism for the old component to leave. Imagine a Linux distro that hadn’t dropped a package since 1993 - there’d be a lot of orphaned pieces in there.

                              But similar issues can still exist on Linux. I’d argue that X is a critical piece that’s become convoluted where a lot of knowledge about what it does and why has been lost, which is motivating a replacement, but being such a core piece that makes for a long transition.

                              1. 1

                                Insightful answer! Thanks.

                              2. 2

                                I think anyone can answer that question simply, as long as such person knows if there’s any sort of contiguous history in Windows source tree as well as comprehensive internal documentation.

                                I’m not even near Microsoft, so I don’t know.

                              3. 1

                                When this post was written, several people asked if it was me. It wasn’t, but I shared a lot of the same frustrations.

                                Perhaps by 2013 things got much worse but I don’t recall cross-team collaboration being this hard (unless shell team was involved, then yes). I’m also actually surprised people who know you would think that you wrote this. Author seems to not understand that contributing to a complex system is bound to cause problems. Your environment variable editor proves that but I’m also pretty sure it didn’t catch you off-guard (neither would it in 2013).

                                1. 1

                                  Did you try to contribute to CMD? I mean, it’s true that contributing to a complex system is bound to cause problems, but there are groups who accept that and are willing to work through them, and there are groups who use that as justification for inaction. It’s always amused me that Powershell is under constant development (which can break scripts) and CMD is so reluctant change because it might break scripts.

                                  When people asked whether I wrote it, I just told them that I wouldn’t hide behind anonymous Tor. People who know me know that’s true :^)

                                2. 1

                                  It’s very hard to find somebody who is so smart to step into a million lines, distill all of the design considerations, then start changing them

                                  It’s also pretty hard to find those jobs if you’re one of those persons who are good at it. Weird how misaligned that is.

                                  1. 2

                                    It’s as though you’re suggesting that an industry which is actively selling computerized data analytics to identify business opportunities in large amounts of data isn’t that good at analyzing lots of data to identify hidden business opportunities…

                              1. 1

                                That’s looks like interesting work ! I’ve been wanting to bootstrap an effort along that line myself for quite some time now, albeit using OCaml. I’ll be sure to keep an eye on your blog.

                                1. 1

                                  Thanks! I’m aiming to write about this stuff much more often now. The bones of that post were written a year ago, so the next few follow-ups should be fast, at least.

                                1. 7

                                  The author overlooks that, often times, the cognitive load of engaging with the owner of a project is greater than “scratching the itch”. My approach in that situation is to scratch whatever “itch” I have to unblock my task at hand. Then, when I have time and if I find my patch worth submitting, I follow the guidelines of the project and submit a PR. I attach no pride to that submission and expect it to be rejected for whatever reason. When that happens, I am usually happy to rework the patch.

                                  1. 5

                                    In addition to this, I feel the “Why are you making this change? What problem are you trying to solve?”-question should have been the first comment on the PR, instead of arguing that “it’s a bad change”. People usually don’t make these kind of changes for the fun of it.

                                    1. 3

                                      I would say that to me, this goes backwards. If someone offers a change, I expect them to explain why they’re going it.

                                      Communicating the intent before is always better than having to ask why after it’s done.

                                      The author even gives a the very particular case of a distributed team, where a team might have lost hours of implementation even before spending 10minutes in discussion.

                                      1. 1

                                        Well, ideally, yes. But people get caught up in their reasoning at times and assume it’s all just as obvious to other people as it is to themselves. Sometimes it is; often it’s not. It’s a simple human mistake that I think we’ve all made at least once or twice.

                                        Either way, don’t start argueing over the how if the why isn’t clear, which seems to have happened in the OP’s case.

                                        1. 1

                                          Agreed. I feel this often happens with strong ownership models.

                                    2. 1

                                      Good point. I’m the OP and perhaps I could have made it more clear that I’ve seen this issue happen more frequently with distributed teams in different timezones, especially when trying to make changes to less mature codebases owned by another, remote team.

                                      As I’ve observed these instances from a step back, I found it wild how narrow the person proposing the change was thinking, and how much time they poured into making a change that never made sense from the platform’s point of view. And these are smart engineers, who were under pressure to solve their pressing problem, on the spot.

                                      I’ll give you an example: a customer of a platform was frustrated how localization changes took around a day for the system to pick up. And this was blocking their team. They noticed that whenever the service was restarted, localization changes got picked up immediately. So they put together a pull request, implementing a way to restart service instances on-demand, when localization changes were done. They didn’t think further on what restarts would mean in a distributed world, how this could impact jobs, workflows and the many customers of this platform. And they added no commentary on the pull request.

                                      Had they talked with the platform team, outlining the problem, they would have learned that this was a known issue and the way it was being solved is… well, the platform emptying localization cache. It was just not a priority until then, and the platform engineers were unaware of the issue this caused.

                                    1. 7

                                      I’ve been using sr.ht since day one and I am very happy with the whole offering. I just recently started using the builds and was pretty impressed with how easy it was to set up. Great work @SirCmpwn 👍

                                      1. 2

                                        I had never heard about this before and I just tried it (using fish as my interactive shell). It appears super, super slow: When I run “ps faux” in an mtm window/panel the output is chunked. Without mtm it is rendred almost instantly. And with mtm a text editor like jed seems to take ages to initialize its display.

                                        Am I doing something wrong?

                                        1. 2

                                          Ditto. Scrolling in vi is painfully slow.

                                          1. 1

                                            What OS/terminal emulator/character encoding are you (and @eeks) using? On Linux with xterm, there’s no detectable difference with mtm running and without, at least for me…I tested with a VTE-based emulator too; again, no difference.

                                            Feel free to open an issue on GitHub.

                                            1. 1

                                              I am using the terminal emulator sakura (“A terminal emulator based on GTK and VTE”) with $TERM=xterm-256color on ArchLinux. The same thing happens with the lilyterm emulator, and actually also in xterm.

                                              Charset is UTF-8 ($LANG=en_DK.UTF-8).

                                              If I run “ps faux” right now the output is 26600 bytes and I see 6 “chunks” in mtm, so could it be something with a buffersize of 4096?

                                          1. 3

                                            Long time ago, I used to use zsh as my login shell on anything from Linux, macOS - Mac OS X back then ;^) - through to Solaris. Now, /bin/ksh on OpenBSD is all I need, and don’t spend enough time on macOS to warrant any deviations from certain defaults. It’s nice to see zsh becoming the default login shell on new macOS, though.

                                            1. 2

                                              I actually use OpenBSD’s ksh on Mac thanks to https://github.com/ibara/oksh

                                              1. 1

                                                I use zsh interactively but still target my scripting to ksh out of habit. While OpenBSD ksh is fantastic, everywhere else I use mksh.

                                              1. 1

                                                Base16 eighties. I am very sensitive to brightness and this dull coloring scheme works wonders on my eyes.

                                                1. 2

                                                  Even if all services are secure, the “mail route” is still wide open. Even if we encrypt every piece of data, the routing of that data is still up for grab. So if the content of your “package” is private, who sent it and to whom it was sent is still up for grab, even in coarse grain. There will never be privacy until not only the data is encrypted but the route is anonymized. And I don’t see the world using Tor or anything better anytime soon. That being said, I still prefer a vendor that allegedly does its best to protect whatever shreds of privacy we have left, rather than one that ostentatiously pillage every single one pf them.

                                                  1. 1

                                                    I agree with you, and with Google effectively controlling browsers and protocols (both HTTP 2.0 and 3.0 are “what Google does, as a standard”) that last loophole is going to be hard to close. I believe that the way to do it is to pull power back in the backend/transport domain. People can choose Apple or Purism for privacy-enabling devices, but while they still need to use Surveillance-as-a-Service applications there is not as much benefit to doing so as one might like.

                                                  1. 6

                                                    There is a comparison to Plan9 and Hurd, but not to GenodeOS (which superficially seems more similar).

                                                    I am not sure if Fuchsia brings anything actually good compared to Genode (and it would be interesting to see); of course, the adoption question is drivers, and Fuchsia will get adoption if Google forces manufacturers to support it, now without any problems around closed-source drivers.

                                                    1. 8

                                                      I heard more BeOS influence, due to the Be alumni working on it.

                                                      1. 6

                                                        And we don’t get a BeOS comparison, either.

                                                        A bit like explaining Git while being careful to never compare it to preexisting DVCSes, only to Monotone — on the other hand, that approach usually works…

                                                        (And I guess running Android apps on Fuchsia also means that security changes will matter more in terms of protecting manufacturer from consumers actually owning the device, than in providing consumers with securities, as most of the user-facing security problems are apps being happy to leak their entire state — although indeed it might also make it simpler for a custm build to provide fake sensitive data)

                                                        1. 1

                                                          Well, with no global file system, it should be easier for apps to have their own private storage to protect the customer from greedy data scouting.

                                                          1. 2

                                                            Hard to say how many vulnerabilities are exploited as single-app takeovers (these will probably stay in Fuchsia).

                                                            On the other hand, cross-application interoperation becomes harder and users lose the ability to have file managers…

                                                            (And some kind of cross-app message-passing will probably formally exist — inherited from intents — but will continue to require too much opt-in from apps to be widely useful — like OpenIntents that apparently didn’t even take off among apps explicitly wishing to ship in F-Droid)

                                                          2. 1

                                                            The speaker isn’t actually working on the OS so perhaps wasn’t aware of those comparisons to be made.

                                                          3. 2

                                                            If Fushia internals are remotely comparable to Be’s KernelKit then it’s a great architecture. I wrote an embedded kernel in grad school using Be’s documented Kernel API, and it’s extremely well designed. The VFS is a piece of art*; I still have fond memories implementing vfs_walk(). It’s a shame BeOS’ architecture is not better studied.

                                                            *not technically part of the kernel and well detailed in Practical Filesystem Design de D. Giampaolo.

                                                            1. 4

                                                              It’s not really like BeOS, no; BeOS was a monokernel, and Fuchsia is a microkernel. There are some vague similarities, but not anything too major.

                                                              On the other hand, Haiku is a complete re-implementation of BeOS including the kernel, and IMO our APIs are even more beautiful than Be’s … but I am biased, of course. :)

                                                            2. 1

                                                              And we don’t get a BeOS comparison, either.

                                                              A bit like explaining Git while being careful to never compare it to preexisting DVCSes, only to Monotone — on the other hand, that approach usually works…

                                                              (And I guess running Android apps on Fuchsia also means that security changes will matter more in terms of protecting manufacturer from consumers actually owning the device, than in providing consumers with securities, as most of the user-facing security problems are apps being happy to leak their entire state — although indeed it might also make it simpler for a custm build to provide fake sensitive data)

                                                          1. 31

                                                            Would you please post the raw data here once it’s collected?

                                                            1. 2

                                                              I’d like to see the results as well.

                                                              1. 2

                                                                I second this.

                                                                1. 3

                                                                  I third (for the sake of visibility)

                                                              1. 34

                                                                This is a pretty good post. I quit my job last month as I hadn’t been able to do any code for almost two months. I didn’t recognize it as a “burnout” until a few weeks later. I probably should have taken a sick leave in hindsight instead of quit, but ah well.

                                                                I wrote some about it on another Lobsters thread a few weeks ago, although I’m not sure if that still reflects my views today as they continue to evolve. I’ll write a detailed weblog post on it eventually, but right now I’m more focused on other stuff, like taking dogs to the park. I’ll probably write a post about dogs first.

                                                                I did have fun writing quite a bit of code this week (for the first time in a what feels like forever). Things are generally going well.


                                                                But here’s a general observation I’ve been thinking about for a while (that is, a few years); namely that office work is too abstract for our brains to thrive in. We can cope, but that’s not the same as thriving.

                                                                Consider mowing the grass. It’s not challenging, innovative, or really “fun” in the direct sense of the word; but it is rewarding. The effort-reward feedback loop is almost instant. A lot of traditional labour is similarly boring but has instant or very short effort-reward feedback loops. Take a look at this expert clog maker; he makes an entire product in what, a day? Probably less? It’s a very experience than office work.

                                                                This feedback is made even better by actually seeing your customers. As knowledge workers we hardly ever see any customer; we just write software and hope some number somewhere goes up. Seeing a real customer being happy with your labour is incredibly rewarding and motivating. I used to work as a repair tech in a computer shop, and the job had a lot of shitty sides, but one of the good sides was the ability to directly help people. Having a real person in front of you thanking you for your work is great. It’s been over 10 years, but I still miss that.

                                                                I also think the lack of a sense of “community” contributes here as well. No local “village community”, religious community, or other sense of belonging makes this even worse. You’re no longer working towards a common goal, you’re just a lonely speck (I have much more to say on individualism and its effects, but I’ll save that for another day).

                                                                The other day I had an idea for a product. I did some basic market research, jotted down some ideas, and made a basic prototype. I showed it to a test audience (N=1, my girlfriend) and she thought it was great (okay, she may be biased, but it’s a start).

                                                                I enthusiastic worked on this for most of Sunday, and continued Monday morning by fleshing out the quick mocked up prototype a bit, and I realized I had to make a user management system (login, registration, forgot passwords, etc.) Dear God, not again! and almost instantly lost motivation. I’ve lost count on how many user management systems I’ve written over the years. It’s neither hard nor mundane. It sits in the dangerous place where you need to do something tedious, carefully. I think of software development sits in that category. What makes it even worse is that I’m not even sure if it will be of any use, since this is a product idea that may never gain traction.

                                                                Perhaps this is the real reason for Rails and the like; not because of laziness, but because doing the same kind of stuff over and over again is too demotivating. I primarily use Go these days which has a very “anti-framework” mentality. I can see the logic in it, and in a way I find myself agreeing with stories such as The resource leak bug of our civilization , but on the other hand doing the same stuff over-and-over again is not how I want to spend my life.

                                                                Many people see me as a “real programmer geek”, or whatnot. I have more Stack Overflow points and GitHub projects/contributions than most and am generally full of ideas. But I don’t really like programming. I just like building stuff. I can cope with the price of building stuff with software, but when too much negative stuff happens my brain seems to fizzle out and give up. The distance between “normal functioning” and “breakdown” seems relatively small; at least, it is for me.

                                                                How can we do better? I’m not sure. I think a major rethinking of both software development practices as well as Western societal norms are needed to really fix it, and that ain’t happenin’ any time soon.

                                                                1. 10

                                                                  I think the part about the feedback is an astute observation. Two philosophical things before I say something practical

                                                                  • There is a verse in the gita that says: “You have a right to perform your prescribed duties, but you are not entitled to the fruits of your actions. Never consider yourself to be the cause of the results of your activities, nor be attached to inaction.”
                                                                  • Manual work is somehow fundamentally different from mental/organizational work and seems to touch something very basic in our minds. Do you pace when you think? I do. I think our evolution dictates that the only reason for thinking is action, so there is a tight connection between thinking and acting. And if we don’t act on what we think, we become depressed. Note that in your example you were satisfied by the act of mowing and not worried about if anyone admired your lawn. The work was it’s own reward.

                                                                  Now on to practicality - I find that getting feedback from users directly about a product is rewarding. It can be painful because the feedback is often negative. Fewer people comment positively about a product they are happily using and more people comment about things they find wrong. But in general the sense that there is some action - some one using the product and gaining some use out of it - is pretty motivating for me personally.

                                                                  There is also the aesthetic pleasure - derived like that from mowing the lawn - of creating code that is pleasant to read and does its job and does it well. I think some of the burnout might come from overdoing it - so not getting enough other things to do, and rest and so on, and some from having to do it badly because of time pressure and negative feedback without any positive feedback.

                                                                  1. 9

                                                                    Great post. Especially “But I don’t really like programming. I just like building stuff.” resonates with me. This is exactly how I feel, and I don’t feel I can express this without receiving negative attention. In Europe, developers aren’t as well paid as in the US, and many employers list having ‘pizza nights’ as a benefit. To me, it signals that I’m expected to work overtime, and the company doesn’t want to invest in me (as in, if they have a pizza nights, employers usually 1. don’t allow you to have paid trainings, 2. expect you to lead pizza nights yourself 3. won’t buy you any food that’s better than greasy junkfood).

                                                                    1. 6

                                                                      I generally agree with your statement, but I think this lack of reward feeling has more to do about our trade that about office work. One can design a building, a train or a plane in an office and feel tremendously rewarded once the product is finished.

                                                                      Because we delve into the virtual world of computer programs, we have nothing to show for our efforts. The product of our work is not tangible and, worse, only shows value among people within our trade. Although I tremendously enjoy what I do, I cannot help but feeling worthless from times to times, wondering what exactly my legacy is going to be.

                                                                      This is why the past several years I have been trying to diversify myself with some other, more tangible skills. I opted for motorcycle mechanics and, interestingly, often take more pride in my small mechanical achievements than my larger, more impactful professional achievements. And the reason is absurdly simple: I can sit on them; I can show them off; I can parade on them; and I know where they physically are.

                                                                      1. 2

                                                                        Maybe people looking for such appreciation should do a mix of what impresses peers in the know and user-visible work that outsiders would appreciate? I think better marketing of what you build showing its benefits can have that effect, too. They say, “I don’t know how it works but I like the results.” They have to see your name attached to it, though, front-and-center to avoid it being made by some abstract or legal entity.

                                                                      2. 5

                                                                        Nobody seems to have responded to the part where you thought you needed to write your own user management system so I figured I’d do it: don’t; just use OpenID or OAuth or something along those lines; even just giving users the ability to authenticate via Google, Facebook, etc. would address the problem sufficiently to focus on the other stuff you actually enjoy.

                                                                        1. 2

                                                                          Yeah, that’s a good suggestion. I might do that for the first version/MVP.

                                                                          I think there’s a bit of a friction between “good elegant implementation” and “easy to create” in this area; in general, I don’t particularly like Facebook logins and such, so I want to offer people the ability to login via regular ol’ email login.

                                                                          Perhaps a good third-party authentication solution exists?

                                                                          1. 4

                                                                            If you do end up implementing it yourself, don’t even bother with passwords; just use cookies and magic links sent via email.

                                                                            1. 1

                                                                              That’s nice, for several reasons, but there are a lot of users who understandably hate it. It’s kind of slow, it doesn’t integrate with 1Password and its clones, and it fundamentally requires you to collect user email addresses.

                                                                              1. 1

                                                                                I don’t understand why you think it’s slow; it takes at most a few seconds the first time and should be a no-op on subsequent uses. It doesn’t need to integrate with 1Password because it’s not a password! Yes, it requires you to collect email addresses, which seems better than collecting passwords.

                                                                                1. 1

                                                                                  One of the benefits of 1Password (or anything like it) is that it shows me all of the sites I have accounts with. Even if a site didn’t use passwords per se I would still make a 1Password entry for it just so I would remember later that I’d made an account there.

                                                                                  1. 1

                                                                                    To what end?

                                                                                    1. 1

                                                                                      *shrug* I mostly just like having a list of the accounts I’ve registered for. But it’s also helpful to keep track of which username and email address I used for a particular service, since I use one-off email addresses and I’d probably forget exactly which address I used if I didn’t write it down somewhere.

                                                                              2. 1

                                                                                So I ended up implementing this suggestion, but to be honest I found it doesn’t really work all that well, and eventually deprecated it in favour of more standard password auth.

                                                                                I wrote up my experiences here, in case you’re interested: https://www.arp242.net/email-auth.html

                                                                                1. 1

                                                                                  “One issue I had is people misspelling their email during signup, so they were immediately locked out of their account.”

                                                                                  When I did this a decade ago, I required them to click a link in an email they provided during signup to actually validate it.

                                                                              3. 3

                                                                                I recently learned about userkit.io. If you use it write a review for the rest of us.

                                                                                1. 3

                                                                                  Thanks. I looked at it, but it’s too JavaScript-heavy for my liking. The dashboard doen’t load in Firefox for some reason (blank page); perhaps a problem in my Firefox, but it doesn’t inspire a lot of confidence. I personally consider accessibility pretty important so I’m not confident this is a good fit. Right now the app is usable in Lynx if you really want to (well, as “usable” as anything gets in Lynx).

                                                                                  I eventually went with @adsouza’s suggestion, which I implemented in about 140 lines of Go code and one simple HTML template. I might make a weblog post or library out of it. Thanks!

                                                                            2. 8

                                                                              How can we do better? I’m not sure. I think a major rethinking of both software development practices as well as Western societal norms are needed to really fix it, and that ain’t happenin’ any time soon.

                                                                              I don’t think major changes are necessary. Software engineers and knowledge workers in general need to get organized and stop drinking whatever kool-aid the silicon valley visionaries, thought leaders, and the likes of Facebook, Amazon, Google, etc. have been selling. Just establishing basic standards of professionalism and ethics can go a long way towards fixing many of the issues that lead to burnout.

                                                                              1. 10

                                                                                I’m very much in favor of professionalizing our occupation, myself. I’d like “software engineering” to be a real engineering discipline, like civil or mechanical or even electrical engineers have, with all that entails. But I do think that it would constitute a major change from where we’re at now. I hope and expect to see this kind of change, but gradually.

                                                                                1. 1

                                                                                  We absolutely imperatively need to fix our tools and fix the general state of programming itself before we “professionalise” which usually means codifying and legislating existing best practices. Because our “best” practices are awful.

                                                                                  1. 3

                                                                                    I think that professionalizing is going to be such a long process that we need to be talking about it now—and besides, there’s so much churn in tooling and practices in our industry that waiting for anything to be “fixed” is going to be waiting for Godot. (A nascent professionalization movement might even put some weight behind an effort to figure out what “fixing” our tools and practices might look like.)

                                                                                2. 3

                                                                                  While I don’t disagree with that, I also think the problems are more fundamental and deeper than that. Or maybe not; I’m not really sure to be honest.

                                                                                  I can only talk from my experience as a software developer, as that’s the only experience I have. But I think I would suffer from the same kinds of problems if I’d work in, say, marketing, or other sectors.

                                                                                  1. 1

                                                                                    That’s true. Programming as a profession attracts certain kinds of people and maybe those people are just more prone to this kind of stuff. But even with that I still think some kind of collectivized professionalism would go a long way to fixing many of the problems that the solo genius mythos has created.

                                                                              1. 3

                                                                                All my OSS work uses OpenBSD’s license: https://www.openbsd.org/policy.html. It cannot be more clear, to the point and contemporary, and certainly does not require deprecation.

                                                                                1. 10

                                                                                  The OpenBSD “ISC” licence says:

                                                                                  Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

                                                                                  Here’s one case where this text turned out to be ambiguous. The University of Washington used this licence to distribute the Pine email client. They claimed that the licence did not permit the distribution of modified versions. You can modify it, you can distribute it, the licence doesn’t say you can do both at once, or so they claimed.

                                                                                  1. 8

                                                                                    It looks to me that they are playing fast and loose with the English grammar in this case. The “,,, and” form is clearly a conjunction and not an exclusive disjunction. If an exclusive disjunction was meant, something of the “either,,, or” form would have been used.

                                                                                    1. 2

                                                                                      I guess the pedantic answer to that is that they are claiming that you can both modify the software and distribute the software at the same time, as long as you modify one copy and distribute another (unmodified) copy.

                                                                                    2. 5

                                                                                      If memory serves, this was a Trademark issue rather than a license issue. If you take the program “pine”, make a bunch of changes, and ship it as “pine”, it’s no longer “pine”, but “pine and your modifications”.

                                                                                      I don’t think this is unreasonable. Firefox has a similar policy, which is why you install “iceweasel” on Debian instead of “firefox”.

                                                                                      At least on the face of it, I think UW was not as incorrect here as it may seem at first sight, and that they are correct that the license didn’t explicitly allow modifying a program and shipping it with the same name.

                                                                                      1. 4

                                                                                        The Debian/Firefox thing was resolved in 2016, but you’re correct - Debian and derivatives are allowed to use the Firefox trademarks as long as they don’t make substantial changes to the Firefox code, and that’s a permission specifically granted by Mozilla, not a general effect of an open-source licence.

                                                                                        A more current example would be the Free Software app store F-Droid, which distributes Firefox as Fennec F-Droid because they compile-time disable some content-visible features, and Mozilla doesn’t want a less-capable browser bearing the name “Firefox”.

                                                                                      2. 4

                                                                                        You can modify it, you can distribute it, the license doesn’t say you can do both at once, or so they claimed.

                                                                                        Companies and people claim things all the time. Did they ever file suit based on their novel interpretation?

                                                                                        1. 7

                                                                                          From the article that I linked to,

                                                                                          Richard Stallman claims that the University of Washington threatened[9] to sue the Free Software Foundation for distributing the modified Pine program, resulting in the development of MANA ceasing and no versions being released.[10]

                                                                                          1. 3

                                                                                            I saw that. Note that it says threatened, which is why I asked if they ever /actually/ sued anyone.

                                                                                            Also seems like FSF didn’t change the name of their version? I guess it was a different time back then…

                                                                                      3. 3

                                                                                        You are citing an example of the exact license that the author is claiming to be ambiguous. Perhaps it depends on whether you read it as a layman or a lawyer.

                                                                                        1. 4

                                                                                          You’re technically incorrect: the article is about the BSD license, but OpenBSD prefers the ISC license which is similar but distinct.

                                                                                          I admit it’s a moot point because ISC suffers the same problem as the BSD license.

                                                                                          1. 3

                                                                                            I don’t quite see how it suffers from the same issues. Most of the points made look dubious at best. Except for patent. But, citing from the page I linked to, the spirit of Berkeley’s UNIX was to provide a

                                                                                            source distribution un-encumbered by proprietary code and commercial licensing

                                                                                            It looks to me that that precludes the inclusion of patented work. Hair can always be split.

                                                                                            1. 2

                                                                                              I was thinking of patents, and agree that the license seems to preclude including patented work.

                                                                                              I would have assumed that about the BSD licenses also, though.

                                                                                            2. 4

                                                                                              “Technically incorrect” is the best kind of incorrect! ;P

                                                                                        1. 6

                                                                                          Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated – E. Dijkstra

                                                                                          1. 3

                                                                                            Another great quote from Ben Franklin:

                                                                                            Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.