1. 14

    I request a follow up post where an existing blog post is rewritten to show how it could be improved!

    Even better, I’d like to see the author of this post show a finished blog post, and the process of getting there from an imperfect original? How do you debug a blog post?!

    1. 6

      I was thinking about doing something like this back in January.

      If anyone has a blog post they would like me to edit, feel free to send it my way (e-mail, PM, etc.). If I think it can be improved and it overlaps with my areas of interest / knowledge, I could either offer suggestions, or rewrite it myself (although I do have a lot of my own posts to write, so no promises).

      Warning: I’ll likely delete 50% of the words in the post while retaining the meaning. My last editing pass almost always consists of deleting words.

      And I suppose you should be comfortable showing the before-and-after, because that’s the request here. (And of course I’ll be interested if anyone thinks the “after” version is worse :) )


      For context, I’ve received a lot of good feedback on the technical writing in my blog:

      • This is a great write up! I wish I saw more of these types of posts

      https://old.reddit.com/r/programming/comments/7xlca1/commonmark_is_a_useful_highquality_project/

      Another warning is that good writing requires more effort / more rewrites than most people are willing to put in. Unfortunately I’ve backed off on that for the last couple years, but I want to get back to it. It’s good to know that you can do it if you put enough time in, even if you’re not always willing or able to.

      So it would be ideal if you have a lot of time to spend on one blog post (and that might be true for more people now due to the state of the world.)


      I should also point out that I borrowed a CSS rule or two from http://bettermotherfuckingwebsite.com/ :)

      http://www.oilshell.org/css/all-2020.css

      1. 1

        You could try linting your blog post: https://www.gnu.org/software/diction/

        Works ok for me.

        1. 1

          This is an awesome idea! Something like https://motherfuckingwebsite.com/!

          Not just technical people are bad at this, neither. Communicating effectively is difficult in every context. We don’t always say what we mean; abstract concepts are even harder to talk about than something you can touch.

          How do you debug a blog post?!

          I used to be very harsh with editing whenever somebody asked me about writing in college…

          1. 5

            I have an obligation to mention http://bettermotherfuckingwebsite.com/ as well.

        1. 35

          Use a library or framework.

          So the best code is actually somebody else’s code.

          Use a third party SaaS tool.

          Somebody else’s code on somebody else’s machines.

          if you can solve a problem without doing anything, it is better to not do anything

          you don’t say…

          1. 24

            If I had to rank problems with modern software development, “devs don’t use enough third-party libraries and frameworks” would be way, way, way down the list. Much higher on the list would be “few devs bother to learn how to write code that can be reused without causing more problems than it solves”.

            Relevant: Designing and Evaluating Reusable Components (2004) by Casey Muratori

            1. 10

              I think this is a fair reply to the literal interpretation of the post, but wholly irrelevant to its spirit.

              Yes, using someone else’s code is still using code, but the important things are:

              • It’s code you don’t have to maintain and support (at least not nearly as much as code you’d write yourself)
              • It’s already done, so you save time by integrating with it rather than having to write and test it
              • If you pick a decent module/framework/tool, it’s likely the author has spent significantly more time refining it than you would if you wrote it yourself, as it’s the purpose of the whole module versus your need of the hour

              It’s also worth mentioning that picking which third-party code or tool to use and (more importantly) which not to use is a skill which gets better with experience. Those less experienced in making those critical distinctions are sometimes bit by bad choices, and revolve to reinvent the wheel.

              you don’t say…

              Regarding this, it may be obvious to you that solving a problem with little or no code is better than the alternative, but this is far from obvious to every developer.

              An outsized portion of developers, even experienced ones, are more oriented toward writing code than solving problems. I’ve seen more than one occasion where a developer starts down the path of designing a complex system to avoid asking a user to make a tiny, effortless tweak to their workflow. Asking them to do so is a win by every measure, and yet many developers fail to consider it.

              1. 9
                • It’s code you don’t have to maintain and support (at least not nearly as much as code you’d write yourself)
                • It’s already done, so you save time by integrating with it rather than having to write and test it

                These are both terrible assumptions. They can be true, but they’re by no means guaranteed. And if you do end up having to make changes to that third party code, it’s going to be a massive pain. Vendoring the code into your repo can alleviate some, but not all, of that pain.

                • If you pick a decent module/framework/tool, it’s likely the author has spent significantly more time refining it than you would if you wrote it yourself, as it’s the purpose of the whole module versus your need of the hour

                Time =/= Quality. Specific solutions to specific problems almost always outperform general solutions in every metric.

                1. 5

                  Like I said, evaluating whether to use a library or to write it yourself is a skill. I hoped I’d made that clear in my original post, but those points are assuming you’ve done your due diligence in choosing a library. I’m not arguing that picking any old module will automatically save you time and it’ll just work effortlessly, but if you do that due diligence you can have pretty good luck.

                  The project I work on at my job had a sizable number of dependencies and we spend relatively little time dealing with those downsides because we do a decent job mitigating those risks.

                  Like everything else, it’s a tradeoff. Sometimes the odds favor writing it yourself, and sometimes they favor using someone else’s code.

                  1. 4

                    Totally agree. I just think the far bigger problem is devs piling on layers and external dependencies due to the belief that it will save them time or make their code more “clean”.

                    There are very few truly general abstractions. Compilers/Interpreters and Relational databases are probably the two most obvious (in software). And they took decades to reach sufficient maturity to be the obvious choice over rolling your own special-purpose solution. And still, they come with a considerable complexity cost.

                    1. 2

                      Like I said, evaluating whether to use a library or to write it yourself is a skill.

                      I think it’s worth highlight this, given the blog domain is called letterstoanewdeveloper.

                  2. 1

                    It’s already done, so you save time by integrating with it rather than having to write and test it

                    I’ll add this is only true if integration effort is less than effort of writing and testing a solution. At first glance, it seems like it obviously would be. Many 3rd-party libraries will be more complex than one needs, have poor documentation, maybe miss corner cases, etc.

                    I can’t give any guidance outside “learn from experience” on how to evaluate when you’re running into this problem. Lean, focused, and well-documented libraries seem to be a good pattern. Personal example for development server in Python was choosing Flask over Django since I figured I’d get working code out faster. It’s been working fine outside one problem that might not even be Flask.

                2. 6

                  Fair points. I did mention manual processes as an alternative.

                  I think some developers are enamored of writing code for code’s sake. I was when I was younger.

                  Maybe a better title would be “The best code is no custom code”?

                  1. 18

                    Surprisingly often, there’s more work in gluing together frameworks than there is in just writing the code. And you lose visibility into what’s going on, so when it goes wrong, it’s much harder to debug.

                    There’s a balance to be made. I try to restrict dependencies to ones solving hard problems.

                    1. 4

                      Surprisingly often, there’s more work in gluing together frameworks than there is in just writing the code.

                      In my experience that is true for the golden path, sometimes. But once you, or your users, stray off the happy path, I find that libraries and frameworks help a lot. Yes, it’s less fun for me to read a doc and learn how to use a third party lib than to write my own, but long term the former is the better solution.

                      1. 4

                        Glue code is rarely bug free, and commonly misses edge cases between what one library outputs and another accepts.

                        The libraries also get special cases wrong more than you’d expect. If I’m lucky, I can get upstream to ship a fix quickly. But often, I just need to work around it.

                        Popular libraries too: I’ve spent days dealing with issues in grpc, core Android APIs, and similar.

                    2. 4

                      It’s certainly valuable to re-use mature, maintained solutions whenever possible. I think we need a new metric to capture evaluate this. Maybe something like “Maximize annual maintenance dollars per Line of Code”?

                      This encourages you to think through who’s actually maintaining the stuff you’re using. You can write it yourself and pay 100% of the maintenance cost. You can use an open source library and benefit from community maintenance investments. You can pay a vendor with a dedicated staff for maintenance investment. Somebody has to do the work or your code rots.

                      You have to think carefully about your unit of analysis though. There are some LOC that matter more to your business than anyone elses’. Are those features actually benefiting from investment received by their parent libraries?

                      1. 1

                        Great idea. I think you meant minimize, though?

                        1. 2

                          I was thinking in terms of maximizing the total investment in your code base, not necessarily your own investment. For example, it’s probably not a good idea to write your own Operating System. You can choose one that already has millions and millions of developer dollars invested in it. Sometimes you can get it for free! This lets you start way further ahead. The same logic applies to almost anything. Use stuff where lots of other people also care about making it work well, so you combine forces. Then focus you internal efforts on the stuff that really matters to your organization.

                          This is somewhat related to the Choose Boring Technology argument. You have to choose where to spend your resources, so you have to put them where they can do the most good.

                    3. 6

                      Ahem. Economics, Mr. Llama!

                      So the best code is actually somebody else’s code

                      They’ve already paid for it. You get to use it for free, maybe pay a little maintenance cost. Is that a good deal? Depends, but probably worth consideration.

                      Somebody else’s code on somebody else’s machines.

                      Infrastructure costs money too. Do you really want to be in that business?

                      If you’re writing code for fun, great, have fun. But if you’re writing code to make money, I think it’s your responsibility to actually make some money. Or at least, not just throw it away merely because it’s more fun to reinvent stuff.

                      1. 2

                        Use a library or framework.

                        Perhaps a library is a good idea in many circumstances if it is sufficiently well designed but frameworks can be a lot of trouble.

                        1. 1

                          I’m upvoting both you and the post on this one. The deep irony here is that you can say things like “the best code is no code” and seem trivial, trite, pointless. You’re just restating the obvious!

                          Everybody can agree, get a nice chuckle. Then they go out and write a bunch of code they didn’t need.

                          Profound statements tend to be facile as well. For me, folks kept saying things like this over and over again until one day the light went off. I’m not sure if I just had to wait until somebody said it the right way, I had to hear it X times, or personal experience demonstrated to me how much I said the words but didn’t actually live the life. Took a long while, though.

                        1. 5

                          Welp, there goes my motivation to finish the draft I have making the exact same point. Good post.

                          1. 2

                            My email actually went to spam in Gmail, surprisingly. Luckily for me, a coworker mentioned it.

                            Has anyone else had LetsEncrypt emails go to spam? Usually they don’t, but this (probably the most important one I’ve received) did.

                            1. 2

                              Maybe Gmail changed something, because since only a few days ago, Sentry mail has also ended up in spam for me.

                              1. 6

                                Consider this a reminder that Gmail cannot be considered a reliable email service that will actually deliver legitimate mail to your inbox, as anyone who’s tried to run a small-scale independent mail server following all the common best practices in the past decade would know.

                                1. 2

                                  People say this frequently, but it hasn’t really been my experience. Of all the third-party or company-managed email services I’ve used, Gmail has been the best by far in terms of spam going to spam and everything else going to the inbox. That’s why this mis-categorization as spam was such a surprise to me. It’s pretty rare. I suppose different people have different patterns in the sorts of emails they receive, though.

                                  1. 1

                                    Your experience has been generally as positive as you describe merely because the vast majority of origins of legitimate email are run by massive megacorporations. It would be vastly different if you were on the other side, trying to run your own email service, and getting falsely flagged on almost every single message that you try to send to someone. By definition, since this affects small-scale servers, from your point of view as a gmail user, the percentage of these false positives in your incoming mail will be tiny.

                                    And in my personal experience, gmail is the worst in this regard – other services tend to at least have the decency to reject messages in a false positive scenario; gmail just swallows everything up and buries it in the spam box that almost nobody ever looks at.

                            1. 11

                              Celebrating a 60th birthday, continuing Dark Souls 2 (I beat 1!), hack on my Somus some more, and reading some papers on garbage collection to fix my fragmented knowledge on it.

                              1. 1

                                Happy birthday!!

                                1. 1

                                  Haha, not mine :) It’s my mother-in-law’s, a wonderful person. (I was trying to be discrete but oh well.)

                              1. 1

                                This is a great list with some wisdom only earned through experience.

                                That being said, I’m puzzled about 77. “Mandatory code reviews do not automatically improve code quality nor reduce the frequency of incidents.”

                                Of course code reviews don’t catch all issues, but the fact that they catch some seems like trivial proof that they reduce the frequency of incidents.

                                1. 1

                                  Of course code reviews don’t catch all issues, but the fact that they catch some seems like trivial proof that they reduce the frequency of incidents.

                                  I totally agree, but try doing a s/code reviews/types/ here and watch people lose their minds :)

                                1. 6

                                  Keep in mind it’s OK to do nothing at all, too.

                                  I’m legitimately thankful for this reminder. It’s been a long week and I think I’m going to spend the weekend doing whatever I feel like doing.

                                  1. 13

                                    This reminds me of a sentiment I’ve often repeated:

                                    The first step of Service-Oriented Architecture is building a monolith.

                                    1. 10

                                      There’s more to it. Services should be used by multiple consumers, otherwise, when a monolith is split into services that only use each other you end up with a distributed monolith.

                                      1. 2

                                        you end up with a distributed monolith.

                                        Which is the wooorse kind of monolith…..

                                        1. 0

                                          I think this depends on how your teams are set up as well. If you have a monolith with 20 teams working on it, it becomes increasingly difficult to release with all of the potential side effects. Microservices can be a good solution for breaking up maintenance of a codebase as well.

                                          1. 3

                                            If you have a monolith with 20 teams working on it, it becomes increasingly difficult to release with all of the potential side effects.

                                            Why? What side effects? If a team is writing it as a library you call versus a service you call – how do the side-effects differ?

                                            1. 1

                                              This depends on the maturity of your development team and processes. It’s easy to say it would have no problems with a bunch of experienced folks, but the reality is that you don’t have that luxury at many places (particularly at a financial institution like I’m at).

                                              People don’t just write them as libraries, they touch common, core functionality, introduce bugs and poor tests, and create inefficiencies in the application that the best teams won’t create.

                                              In some areas, we have up to 45 teams actively contributing to one monolith (although it’s being separated out as we speak). Each of those teams has 5 developers, and many of those teams don’t have any senior level devs to really make sure things are being done correctly.

                                              1. 5

                                                It’s easy to say it would have no problems with a bunch of experienced folks, but the reality is that you don’t have that luxury at many places.

                                                Services aren’t a fix for management/team/experience problems. Hell, you need A LOT more experience, expertise and skill to deal with microservices. Their complexity radically outstrips monoliths when in use to create an application. The bugs are harder to debug, the environment is more challenging to setup, the security between layers is complex and often radically different between dev and prod.

                                                People don’t just write them as libraries, they touch common, core functionality, introduce bugs and poor tests, and create inefficiencies in the application that the best teams won’t create.

                                                This isn’t fixed by services. You are talking about poor abstraction/design of your application. If you are using services as an excuse to rewrite, just call it what it is – a rewrite. One that could be just as well done by rewriting to libraries. I see this pattern a lot, developers masking a rewrite by calling it a “conversion to microservices” to hide it.

                                                if they are touching common, core functionality – they would be touching other peoples services, or a core-uber-service. This is a design failure, it has absolutely nothing to do with services or anything else, hell – it is a management failure.

                                                In some areas, we have up to 45 teams actively contributing to one monolith (although it’s being separated out as we speak). Each of those teams has 5 developers, and many of those teams don’t have any senior level devs to really make sure things are being done correctly.

                                                My guess – you will end up worse off than before. Separating out a system where everyone needs to touch “common, core functionality” ends up with everyone touching the “core uber service”, or it is a stealth rewrite. Either way I don’t see how you are magically fixing anything? Soon you will have 45 teams of developers constantly doing integration work, touching each others services, or working on an uber service. They will be trapped in whatever the first interface they design is because 44 other teams will be using it. They will be afraid to touch it because the users are invisible to them. Welcome to microservice hell, enjoy your stay. :)

                                                EDIT: I said more about microservices on another thread, so I won’t repost it all here: https://lobste.rs/s/g04myz/neomonolith#c_tjlrcb

                                                1. 1

                                                  Spot on. Microservices cannot solve poor abstraction - you get poorly modularized services - or poor testing. If anything, testing and debugging a distributed monolith is much more difficult.

                                                  Big monoliths are usually a very bad but SOA cannot help lack of good design.

                                                  1. 1

                                                    Big monoliths are usually a very bad

                                                    Software is usually very bad - FTFY

                                                    1. 1

                                                      In this particular case, our monolith grew from a team of 4 to 40+ teams over the years and is a hodge podge of hacks, quick fixes, and technical debt that “we’ll get to later.” Rewriting it in microservices allows folks to use things like Java 11 or Node for their microservice instead of being locked into a Java 7 environment that’s nearly impossible to upgrade due to the vast number of lines of code.

                                                      Microservices are not the only solution out there, but they definitely make sense in some places. Especially on federated teams.

                                                    2. 0

                                                      Services aren’t a fix for management/team/experience problems. Hell, you need A LOT more experience, expertise and skill to deal with microservices. Their complexity radically outstrips monoliths when in use to create an application. The bugs are harder to debug, the environment is more challenging to setup, the security between layers is complex and often radically different between dev and prod.

                                                      I would disagree with this, especially in the setup. We do have a team that helps teams set up their pipelines and AWS resources, but as far as setting up a gigantic monolithic application (and getting it running locally) vs starting up a microservice, it’s worlds different. You get to mock out the dependencies that would otherwise be part of your running application, or, if necessary, use something like docker-compose to spin them up without actually knowing anything about how they work.

                                                      if they are touching common, core functionality – they would be touching other peoples services, or a core-uber-service. This is a design failure, it has absolutely nothing to do with services or anything else, hell – it is a management failure.

                                                      They touch the core functionality because they can right now. It has already been abstracted for the microservices (and hence backported into the monolith), but the real problem was a matter of “hey I can just change this real quick” without understanding the consequences. Our management is definitely not ideal, but it’s still a difficult thing to manage.

                                                      My guess – you will end up worse off than before. Separating out a system where everyone needs to touch “common, core functionality” ends up with everyone touching the “core uber service”, or it is a stealth rewrite. Either way I don’t see how you are magically fixing anything? Soon you will have 45 teams of developers constantly doing integration work, touching each others services, or working on an uber service. They will be trapped in whatever the first interface they design is because 44 other teams will be using it. They will be afraid to touch it because the users are invisible to them. Welcome to microservice hell, enjoy your stay. :)

                                                      We already have teams using the new setup with tons of positive comments. It’s also part of a broader ‘you build it, you own it’ strategy that, while not ideal in all cases, does put the power back into the owning team’s to do what they need to do in a way that makes sense for them.

                                                      Will some of them inevitably develop a tangled web of nonsense that’s little more than a house of cards? Sure will. But it’s no longer part of a monolithic codebase that everyone else needs to deal with.

                                                      We already have a versioning scheme for our services, as well, so there’s no “getting stuck” in a certain version. There is a current-stable version, deprecated version, and a beta version for folks wanting to try the latest. These are all communicated out to ensure teams have plenty of time to adjust.

                                                      I’m not saying microservices are the only way or some sort of silver bullet, but they have their place. Whether you like them or not doesn’t change that.

                                                      1. 3

                                                        setting up a gigantic monolithic application (and getting it running locally) vs starting up a microservice, it’s worlds different.

                                                        Only if your microservice has no dependencies (in which case it could be a library or module and tested alone as well). Once it requires calling into other services, it better have error handling for when they are down and THOSE microservices better have developer versions running and of course, correlated configuration options for everything.

                                                        They touch the core functionality because they can right now.

                                                        Literally 30 seconds of work and a git hook fixes this issue.

                                                        But it’s no longer part of a monolithic codebase that everyone else needs to deal with.

                                                        That is only true of those services “at the bottom”, everyone on top of them has to deal with the bugs on all the layers below. Sure – you can now pass the blame – but now you can’t even freaking fix it – which is a far more horrible fate. Now you are at the mercy of others. The actual top level – the real app – the problem you are actually trying to solve still is a “monolith” of features to the client. They don’t care about your microservices.

                                                        We already have teams using the new setup with tons of positive comments.

                                                        I have setup a one year reminder to hit you up to see how you feel about them in 12 months. They always feel great at first, it is the long term pain that is the problem, like an STD/STI you don’t know the pain you have signed up for at the start.

                                                        We already have a versioning scheme for our services, as well, so there’s no “getting stuck” in a certain version.

                                                        This is always the plan, it just hardly ever is the reality. Unless you are willing to outright break other teams ( and that includes teams more important than you and possibly far more busy ) management will stop this. The reality is in a microservice setup with multiple teams, it becomes a service hierarchy… there will always be stuff you can’t break no matter “how much notice you gave” and again – you can’t break the app – but now you also can’t fix it – glorious future!

                                                        I’m not saying microservices are the only way or some sort of silver bullet, but they have their place.

                                                        Your comments did have a wiff of silver bullet (or if you are non-decision maker in all this, stockholm syndrome might be a better description) to me – but I will take you at your word.

                                                        Whether you like them or not doesn’t change tfhat.

                                                        I was a proponent of SOA/microservices and implemented them multiple times at large scale production before I became a doubter, to now someone who assumes they are the wrong answer unless convinced otherwise.

                                                        EDIT: I sincerely hope you are the exception, that your organization is the one that does this right – and if that is the case I hope you write white papers and books about it. I don’t wish the pain of a micro-service architecture on any group of developers, the majority of whom had no choice in adopting it and are just stuck in whatever the fashion of the day is.

                                                        1. 1

                                                          We (as a company) have been using microservice architecture for multiple applications now for at least 3 years. The monolith that is being split apart is taking its jolly time, but it’s been well over a year for this as well. These comments aren’t really that new. The versioned APIs are already a reality as well, not a potential discussion point or target. It is the real world for us, not a dream (or nightmare in your case).

                                                          I don’t use microservices in everything I do, but when it comes down to a federated platform where you want teams to own their product front-to-back and support it in production, it’s a good solution. I’ve been on the other end where I was on production support for stuff I’ve literally never even seen just because I worked on a (very) small segment of the monolithic application.

                                                          Not everything on our backend is even a service as such, as we have a lot of lambdas/functions where it makes sense to help on costs of infrastructure and maintenance.

                                                          I’ve seen them work successfully in a large-scale businesses, and I’ve seen them fail in smaller organizations. It’s not about making bad decisions or having some form of stockholm syndrome. That’s a very dismissive opinion that you’re asserting as fact. “It didn’t work for me, so it can’t work for anyone.” Like some sort of anti-silver bullet. There is no one solution for any given problem, and that’s the fun of being in the dev world IMO.

                                          1. 2

                                            Thanks, this is a great idea!

                                            Since it seems the list is going to grow fairly long, it might be helpful to have some organization and/or short descriptions for each podcast so it’s easy to pluck out items of interest. Some topics are obvious based on the podcast names, but others are much less so.

                                            1. 21

                                              Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather.

                                              We have no elected government, nor are we likely to have one, so I address you with no greater authority than that with which liberty itself always speaks. I declare the global social space we are building to be naturally independent of the tyrannies you seek to impose on us. You have no moral right to rule us nor do you possess any methods of enforcement we have true reason to fear.

                                              Governments derive their just powers from the consent of the governed. You have neither solicited nor received ours. We did not invite you. You do not know us, nor do you know our world. Cyberspace does not lie within your borders. Do not think that you can build it, as though it were a public construction project. You cannot. It is an act of nature and it grows itself through our collective actions.

                                              You have not engaged in our great and gathering conversation, nor did you create the wealth of our marketplaces. You do not know our culture, our ethics, or the unwritten codes that already provide our society more order than could be obtained by any of your impositions.

                                              You claim there are problems among us that you need to solve. You use this claim as an excuse to invade our precincts. Many of these problems don’t exist. Where there are real conflicts, where there are wrongs, we will identify them and address them by our means. We are forming our own Social Contract. This governance will arise according to the conditions of our world, not yours. Our world is different.

                                              Cyberspace consists of transactions, relationships, and thought itself, arrayed like a standing wave in the web of our communications. Ours is a world that is both everywhere and nowhere, but it is not where bodies live.

                                              We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth.

                                              We are creating a world where anyone, anywhere may express his or her beliefs, no matter how singular, without fear of being coerced into silence or conformity.

                                              Your legal concepts of property, expression, identity, movement, and context do not apply to us. They are all based on matter, and there is no matter here.

                                              Our identities have no bodies, so, unlike you, we cannot obtain order by physical coercion. We believe that from ethics, enlightened self-interest, and the commonweal, our governance will emerge. Our identities may be distributed across many of your jurisdictions. The only law that all our constituent cultures would generally recognize is the Golden Rule. We hope we will be able to build our particular solutions on that basis. But we cannot accept the solutions you are attempting to impose.

                                              In the United States, you have today created a law, the Telecommunications Reform Act, which repudiates your own Constitution and insults the dreams of Jefferson, Washington, Mill, Madison, DeToqueville, and Brandeis. These dreams must now be born anew in us.

                                              You are terrified of your own children, since they are natives in a world where you will always be immigrants. Because you fear them, you entrust your bureaucracies with the parental responsibilities you are too cowardly to confront yourselves. In our world, all the sentiments and expressions of humanity, from the debasing to the angelic, are parts of a seamless whole, the global conversation of bits. We cannot separate the air that chokes from the air upon which wings beat.

                                              In China, Germany, France, Russia, Singapore, Italy and the United States, you are trying to ward off the virus of liberty by erecting guard posts at the frontiers of Cyberspace. These may keep out the contagion for a small time, but they will not work in a world that will soon be blanketed in bit-bearing media.

                                              Your increasingly obsolete information industries would perpetuate themselves by proposing laws, in America and elsewhere, that claim to own speech itself throughout the world. These laws would declare ideas to be another industrial product, no more noble than pig iron. In our world, whatever the human mind may create can be reproduced and distributed infinitely at no cost. The global conveyance of thought no longer requires your factories to accomplish.

                                              These increasingly hostile and colonial measures place us in the same position as those previous lovers of freedom and self-determination who had to reject the authorities of distant, uninformed powers. We must declare our virtual selves immune to your sovereignty, even as we continue to consent to your rule over our bodies. We will spread ourselves across the Planet so that no one can arrest our thoughts.

                                              We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before.

                                              Requiescat in pace, sir.

                                              o7

                                              V.v.V

                                              1. 3

                                                I remember reading this in my teenage years. It really had an impact on me. It changed how I thought about computers, the internet, security, privacy, government, identity, and everything else the Declaration addresses. The Hacker Manifesto had previously spoken to me and this was, in some ways, a more mature and natural extension of some of those ideas. This was those early teenage years when you start to realize your new mental capabilities, ones you didn’t really have a few years earlier, when you start to gain the ability to really think deeply about things—a time when you’re really impressionable.

                                                This piece really shaped who I’ve become. Rest in peace, Mr. Barlow. Thanks for everything.

                                              1. 5

                                                Today is the first day of my new job!

                                                As much as I want this week’s agenda to be to share all the ideas I’ve had for the product over the last couple months, I know that’s not what someone should be doing in their first week. Or month. Or three.

                                                This week I’m going to find my bearings. I’m going to feel out the culture, acquaint myself with people, and fit in. I’m going to try to understand more of the fundamentals of their product, development process, culture, and industry. A lot of new information is about to come at me and I expect to be a bit overwhelmed and exhausted, but that’s the game.

                                                I’m excited and nervous and all of the usual emotions. Wish me luck!

                                                1. 2

                                                  Good luck, and congratulations.

                                                1. 3

                                                  This was a really fun read! Thanks for sharing.

                                                  I’d recommend this article to any Lobster with even a passing interest in cryptocurrency.

                                                  1. 5

                                                    This is a really stellar article. I mean really fabulous. The article perfectly distills years of rumination into simple points and subpoints. If you expect to have to design an API at some point in your career (spoiler alert: you will), you absolutely need to give this article a read.

                                                    When using a poorly-designed API, I always find myself wondering why it was designed so poorly. Was the API just an afterthought which grew more popular than expected? Was it made by a first-time API designer? Is it a reflection of a poorly-designed existing system?

                                                    My pet theory is that in the back of our minds we don’t think about other developers as users. Of course, they’re not users in the traditional sense, but they are still users. We think they’ll just be able to handle whatever we throw at them, and to some extent we’re right—they will hem and haw and grumble and use the API. They’ve used kludgey APIs before, right?

                                                    1. 5

                                                      For work: I’m re-implementing some abandoned cart handling in the CMS we’re migrating to.

                                                      For me: I’m continuing work on siftrss, fleshing out my unit test suite to better cover edge cases concerning feeds with off characters, encodings, namespaces, etc. Ahhh, they joys of working with XML for no money. :)

                                                      1. 2

                                                        I used your project as inspo for some Rust code I hacked on while streaming.

                                                        1. 2

                                                          Hey, it’s you! I saw that a while back when I happened to search for mentions of siftrss on Twitter. I’m glad I could lend some inspiration for your project!

                                                          I love how clean your code is. I don’t know much about Rust, but your code makes me want to give it a go. I’ve been meaning to get around to writing a serious project in a functional language.

                                                          1. 3

                                                            Thank you very much!

                                                            My main thing (day job and personal projects) is Haskell, which may have something to do with the style of my Rust code. There’s a lot of idioms I ignore/wrap in Rust.

                                                            Case in point, I got irritated with the useless (IMO) information hiding in the rss crate so I forked and patched it: https://github.com/bitemyapp/shiftrss/blob/master/Cargo.toml#L15

                                                            Didn’t get upstreamed, they special-cased a setter or whatever for the thing I was doing.

                                                            I use Rust because it’s a reasonably type-safe language with sweet-spots (super perf sensitive, no GC) that are complementary to Haskell (everything else)

                                                            1. 1

                                                              Right on! I’ve poked at Haskell a couple times, but never used it to write anything of substance. Of course, my list of languages to try out grows faster than my list of projects… which is often longer than I have time for in the first place, haha. I’ve been meaning to try out Elm, as I wanted something new to play around with on the front end.

                                                              Rust sounds very interesting. Consider my interest piqued!

                                                      1. 9

                                                        Wow, this couldn’t have landed in front of me at a better time. An email hit my inbox this morning from a local technical college where I serve on an IT advisory committee, asking me if I’d like to come in and talk to the students about my job. I was leaning toward politely declining, but now I’ll have to reconsider.

                                                        1. 3

                                                          Seems plausible Google didn’t go over Buganizer as carefully as they do many public-facing products because it seemed like an internal product, and the external audience that gets access (folks who successfully reported a security bug) seemed semi-trusted. I bet there are a lot of security issues in code that’s meant for semi-trusted audiences like this: a company’s vendors, say, or a small number of special high-value clients, or employees (when employees have access to a tool but shouldn’t all have ‘root’ on it). Place to look for issues in our own stuff potentially.

                                                          1. 1

                                                            Agreed—this is a prime example of security through obscurity. Tons of small shops do this sort of thing every day, employing only what security is necessary to keep out the passerby who isn’t too tech-savvy.

                                                            One would hope a place like Google wouldn’t lean on obscurity, but here they are doing it.

                                                            1. 2

                                                              Agreed—this is a prime example of security through obscurity. Tons of small shops do this sort of thing every day, employing only what security is necessary to keep out the passerby who isn’t too tech-savvy.

                                                              Oh, huh, you’re right and it’s different from what I originally thought. I had thought they had proper access control so that only bug reporters could access the tool, but weren’t securing products for that audience as well as they would secure apps that just anyone can trivially browse to. But, in fact, it looks like it’s public (at least, I can just browse to issuetracker.google.com), so it really was just a more obscure product being less thoroughly scrubbed for issues.

                                                          1. 4

                                                            Hey, Lobsters! I’ve been sitting on this project for a while and a buddy recently recommended sharing it here. I built it to scratch my own itch, so it’s still very MVP. Its biggest shortcoming is definitely the lack of the ability to apply AND and OR boolean logic to filters. In the long term I’d like to add the ability to combine multiple feeds into one as well, assuming there’s demand.

                                                            My girlfriend was looking for a new job in a rather niche field so I had subscribed to some RSS feeds, only to find they were country-wide and there was no good way to narrow it down geographically. I didn’t want to wade through hundreds of job postings just to nab a couple, so I built siftRSS. Laziness really is a virtue.

                                                            I’d really appreciate any feedback. Thanks!

                                                            1. 2

                                                              Support for regexp would be great too. ;)

                                                              1. 1

                                                                Ahh, good call! It was in my original plans (like many things), but I was focused on cutting the scope to the point of embarrassment. ’Tis the nature of MVP, after all. :)

                                                                If you like, I can shoot you a message when I implement regex matching.

                                                            1. 4

                                                              I desperately want someone to make a font from his handwriting. It’s gorgeous.

                                                              1. 3

                                                                It really is! One post you might enjoy is Josh Davis’s attempt at acquiring Edsger Dijkstra’s handwriting. If you’re unfamiliar with Dijkstra’s handwriting it’s well worth checking out—a nice little homage to one of the greats in both CS and penmanship.

                                                                1. 1

                                                                  There are a number of sites and softwares for doing this, sounds like a fun Saturday afternoon project. Let us know how it goes. :)

                                                                  1. 1

                                                                    I’m sure some handwriting nerd will be able to trace it to a specific public school in the UK.

                                                                    Possibly Sherborne.

                                                                    1. 1

                                                                      Oh wow, is this actually a phenomenon? If so, that’s pretty incredible! I know my grandfather (born 1917) had penmanship classes growing up in Canada before coming to the United States.