luord

This was a fun game to play:

Seven I fully agree with.

Seven I agree with but I don't think they're controversial.

Two I agree with but they're interesting in that I'm pretty sure that the ideals of them are not controversial, even if they're not as common in practice.

One I agree with the title, but not the description.

One might have been controversial back then, but it might as well be an axiom nowadays.

Two I fully disagree with.

I'm still waiting for more news on the potential internally designed laptop they talked about last year. Thankfully, I'm pretty happy with the Gazelle I bought a couple of years ago from them, so I think I can keep holding out until they either confirm that new laptop or announce that it has been scrapped.

Location: Colombia

Remote: Yes (preferred)

Willing to relocate: Depends on the project and country.

Technologies:

- Python (Django, Flask, SQLAlchemy, Celery).

- JavaScript (Vue, React, Node, Typescript).

- Operations: Docker(-compose), Ansible, GCP, Gitlab-CI, Heroku.

- Other: PostgreSQL, Bash, Go.

Resume/CV: https://luord.com/pages/resume

Email: lo@luord.com

> I feel this article actually does not go far enough [...] I think in our quest to make things "easier" for people, we made it a lot more difficult for those who want to change a few things and use the computer.

IMO, if the article didn't "go far enough" because it didn't talk about something like this, then the article made the right choice. "Using Linux" doesn't mean "using linux mint".

For example: The three or four times I've bothered to reinstall my OS in the past eight years, I just install the minimal, CLI version of debian, and then proceed to install exclusively what I want on top of it. Seems like that's more or less what you would want to do.

Of course, your situation might be different and you might not have the opportunity to do that, but I hope this helps at least somewhat.

> By restricting your design documentation to a single file that is intended to be read as an introduction to your software, RDD keeps you safe from DDD-turned-waterfall syndrome by punishing you for lengthy or overprecise specification. At the same time, it rewards you for keeping libraries small and modularized.

Particularly liked this part.This nuance of not going too far in either direction is what makes the idea effective, I would think. Will keep it in mind for every future project.

And hey, writing the readme first will very likely make tdd easier, as the first few tests to write would be essentially transcripts of the readme into code.

I see your point, but in my opinion, part of a job is knowing how to use the tools for the job. New, easier to use or more efficient tools could be created? Absolutely, but knowing how the tools work is never a disadvantage, IMO. And at least we software engineers have an advantage there in that most, if not all, of our tools are themselves software.

For instance, an analogy with zoologists I would make is knowing how to set up their observation equipment in whatever remote area they're doing their research. They have to do it and they have to know how to do it, and maybe they even have to do troubleshooting in case something is not working quite like it should. None of that has to do with zoology per se, but it is part of a zoologist's job.

They can get better and/or more reliable tools over time? Absolutely, which is what I think most of TFA is understandable. I happen to think that git is already a pretty good tool, but I absolutely do see why many people disagree.

While I generally disagree with what he's saying, I do think that most of his points are understandable, even if not persuasive to me.

Except this one:

>> I will get you to think about a directed graph or as operations on a directed graph

> No human thinks about that!

Well, that's not wrong, people don't usually think like that, but people also don't usually think about possible specimens living in some forest during a hike, or the odds and the reasons why a given storm could become a hurricane when they read about it in the news, or all the most likely reasons why a given body part might be hurting. No, those are thought by zoologists, meteorologists and physicians, respectively.

With that in mind, I see thinking about graphs and other areas more complex of version control as being, similarly, part of the job and the cognitive load of software engineers.

In short: People don't usually think like that, but, in my opinion, thinking like that is part of a software engineer's job, so I don't see an inherent problem with that.

Pretty good write-up. Currently I commonly use nomad for deployment and management of (docker based) infrastructure, using docker-compose for local development. I'll have to take a closer look to terraform and packer to see how much I like them as alternatives.

The way I see it, he (and any other maintainer who chooses to do the same) is perfectly within his rights to do this. They're his projects after all, it's up to him how to run them.

That said, if a contribution of mine is ignored in a project (and a few have been), that usually becomes my last contribution to the project. Afterwards, I often choose to instead invest my efforts in other projects.

Ultimately, by Linus's law, those projects that accept the most contributions and/or foster the most active communication ought to raise to the top. I think that we simply can ignore back the projects that ignore contributions; they're the ones who end up losing out, as far as I've seen anyway.

This resonates with me far, far more than most, if not all, articles, essays, think pieces, etc, about getting things done and procrastination I've ever read. Indeed, I have a serious problem with wanting to have something be perfect when I do it, so often I don't feel like doing it. Ironically, that attitude has the result of sometimes making my work worse, since ultimately I end up having less time to do the work which can lead to sloppy results.

I'll now have that nitpicky attitude in check and remind myself that not completely perfect merge/pull requests are still work that my clients can see, and the feedback loop within them when they're not perfect from the get go doesn't necessarily have a downside, and can in fact improve communication and the flow of work. After all, a request is by definition not necessarily the work completed, but literally a request for feedback, and possibly iterating on the work already done.

I can even use a trick to mentally tell myself it doesn't have to be perfect: I can start work everyday with the expectation that, at the end, I only need to create or update a draft merge/pull request. That will get me even more easily into the mindset that I'm working to ask for feedback, not to deliver the final piece. Who knows, maybe by the end of the day the work will be good enough for a finished request, so it's a win-win situation.

And that's just one idea, that I need to put in action. I'll see how it goes.

Between this and Jeffrey Paul's article shared yesterday about Big Sur and Apple Silicon[1], it's becoming increasingly tempting to throw my phone away and keep using only Linux with no applications primarily developed by these giants (i.e. no Chromium, etc).

Supporting initiatives like the Librem phone is also moving up in my list of priorities, once I get enough money to spare at least.

[1]: https://news.ycombinator.com/item?id=25078034

> "We recognize the work that’s gone into the past 7 years and it sounds like this is a great landing spot for the team. We’re grateful for the opportunity to have supported you along the way."

That is incredible and, as the author says, classy. If I ever find myself actually doing the investment rounds for anything I create or help create, I hope that people like General Catalyst take an interest.

I use the pomodoro technique not just because it actually helps me get started—the best way I've found, for me, to combat procrastination—and get things done, but also to combat the sitting problem he mentions. Standing up and walking around the house for five minutes periodically helps me at least stretch my legs.

That aside, I find pretty much all of his advice pretty useful and a lot of it I already at least try to follow. Good to know it doesn't work just for me.

> Try not to jump straight into the code, sometimes it's OK, but it can also be distracting. I strive to first form a reasonable conceptual model of my approach before implementing it in code.

This was probably the key takeaway for me. Too often, specially when I'm solving hackerrank/leetcode challenges, I jump straight into the code without bothering to think about the problem first, at least for a moment.

Now I keep a physical notepad to write and/or draw at least basic models of whatever non-obvious problem or issue I'm given. I've noted that it's helped me quite a bit, at least to give me a general idea of what I should do.

Faced similar issues in both of the Go projects I've worked on, particularly the one that used Mongo as the database.

My conclusion from both experiences is that Go is a tool like any other, with its strengths and weaknesses, and with particular idiosyncrasies that make it particularly important to properly architect the application. It can punish you pretty hard[1] if you don't follow proper patterns, or the architecture you decided.

For instance, I think the issues were more pronounced with the project using Mongo precisely because of the flexibility Mongo offers, which allows to delay deciding on schemas, and thus means that the architecture itself can change constantly.

[1]: Such as making coupling and code repetition to balloon pretty fast.

Something I like about RESTful APIs over GraphQL[1] is the predictability. With GraphQL each request can depend on how the client constructed the query; with REST, every time you hit an endpoint, and assuming good practices such as idempotency are followed, you know exactly what data is being returned.

Sure, these same restrictions are what can lead to the necessity of versioned APIs, but on their own, they make the API in general a little easier to reason about, and test, at least in some ways.

[1]: Which is not to say that I prefer them nor I think them better overall. Much like TFA says, I think both approaches, and others, have their uses.

This reminds me that I've got to remove recaptcha from the contact form in my website.

I rarely get contacted so I wouldn't have to pay any time soon, but I want to remove all third party services from my site anyway and I have to find a way to prevent spam that would nevertheless be less annoying for someone who would actually want to contact me.

My current approach to technical debt is not mentioning it, and instead attempting to make small refactors and/or writing tests for uncovered sections of the code as I go along. Also adopting an attitude of letting it go if my attempts or suggestions are stopped.

That latter thing is more difficult as it means efforts to help go to waste sometimes so my first instinct is to insist, but ultimately I tell myself that it's the clients' code and their decision, not mine. Besides, cleaning up code, sometimes by trying different ways to clean it, is always a teachable moment.

Fortunately, my current clients have been far more receptive and open to improvements than some other people/companies I've worked with before.

It might be because I'm more familiar with the syntax, but I find gitlab-ci easier to reason about than github actions. At least, it's a single file instead of a workflow and any number of actions.

This is to say, if I were in Jeff's situation, I would seriously consider moving to GitLab (with mirrors in github for visibility), or at least setting up their ci to trigger from github.

Though maybe I'm just speaking from lack of experience, as I've only set up actions in one project so far.

Yet something else that I definitely need to try out as soon as possible. I generally don't like leaving the CLI, so this seems like it could work great for me.

Great write-up, and I've got to say that the biggest takeaway from it, for me, is that the cloud pie has more sections than I thought it did. Well, I guess in the back of my mind I knew there were quite a few providers, but I never paid serious attention.

From now on, I'll make a conscious effort of at least taking a look beyond the most popular providers (and Heroku), and not just for the sake of cutting costs.

I see that it's time to start using my domain email more consistently, and change existing accounts into using it too. I don't have a lot, but still, better safe than sorry.

It's interesting that he is so vehemently in favor of "cancel culture" given two things:

The reason many people oppose it is because it often leads to completely innocent people being harassed and/or ostracized (or worse). So, in that way, his situation makes a very fitting example of many of the things wrong with cancel culture and highlights a few of the reasons why detractors oppose this kind of attack.

Secondly, it's unfortunate that, despite buying into cancel culture and believing it is merely "facing consequences", he doesn't mention any names. If I were in favor of this kind of social retribution, I definitely would think that the members of this committee should "face consequences". At the very least, they should be removed from the committee, as clearly these people shouldn't have the authority to enforce any CoC, let alone a particularly nebulous one.

All in all, though, I feel very bad for him and, if nothing else, hopefully this doesn't bring him any more trouble.

> It's designed to scare away open source hobby programmers? And users?

Just giving my two cents: I don't have any trouble contributing to AGPL projects. Mind you, I haven't contributed much in general, but still.

As for using AGPL projects: Well, I wouldn't want to offer someone else's project as a service and poach potential users for the maintainers in the first place. But if I did, I wouldn't mind contributing back any modification I made.

Now, using them as dependencies—for just one part of an application that you want to keep otherwise private—is a little trickier because I'm neither a lawyer nor has the AGPL been tested in court as far as I know. The crux of the issue lies on whether dynamic linking makes a piece of software derivative; the FSF thinks it does (at least from what I read in their FAQ), but that also hasn't been tested in court (again, AFAIK) and one's interpretation could be entirely different. If it isn't derivative, then there's no problem with using AGPL software strictly as dependency. And, if it is, well, in the world of microservices you could just create a thin wrapper over the AGPL library, run it as a service, and release only that.

Then again, if one assumed that linking doesn't make a work derivative, then there's not much difference between the GPL and the LGPL (once again, AFAIK). It's a nuanced issue, to say the least.

I don't think this is necessary a product of malfeasance or anything, but rather lack of complete knowledge on certain areas.

Put it another way: Sucks for this guy that google seems not to know about dictionaries and the importance of citations; and that whoever placed the manual penalty (assuming there's one) isn't completely well versed on intellectual property law.

Suppose that, again, the solution would be on more competition; it would encourage google to improve on nuances like those.

This is what nightmares are made of.

> We’ve learned that having a function that deletes your database is too dangerous to have lying around.

Indeed, anything that might compromise the data, anything that might involve deletion anyway, should require manual confirmation whether you manage the database or it's a service provided.

Sadly, I learned this the hard way too, but at least it was a single column with a non-critical date and not the entire database.

Reading these comments, I've noticed an interesting inversion of the usual pattern:

1. Some guy says something about Linux.

2. He gets several replies that are multiple variations of "well, Linux doesn't work for me!"

In this case, it's Windows users mentioning how the issues in TFA don't happen to them.

Maybe this will help some understand that replying with "for me, it's broken!" (Whether it's about Linux or Windows or anything else) is very likely not helpful at all, or completely pointless at worst, because it might be perfectly possible that it isn't broken for the people who made the original comments so there's not much discussion to be had.

Maybe.

Ever since I started using vim exclusively for development a couple of years ago, I deliberately decided not to use plugins nor to edit the defaults unless strictly necessary. Nowadays, my .vimrc is just a few lines, all regarding indentation.

It had worked for me so far and I never really felt any less productive than when I used IDEs or VS Code.

As if I needed more reason to believe that C should absolutely not be the first language taught in CS programs (sadly my alma mater still disagrees). I think I'm gonna have nightmares.

Of course, C isn't taught like this over there, but the point is that C gives you way too much rope to hang yourself with, and that's if you're an experienced developer, let alone a college freshman. Sure, the argument can be made that screwing up as a freshman helps you learn in a way that doesn't compromise your career, but I believe that quite a few of my classmates wouldn't have given up on programming altogether had they not been thrown at C right away. I myself didn't learn to love programming until I tried less spartan languages.

> Similarly, when Facebook wanted to inform its users that 30% of the fees users were paying for online events went to Apple, Apple didn’t let Facebook do it saying this information was (once more) “irrelevant”.

That's the passage I meant. I wouldn't have imagined that Apple would be in the capacity of letting or not letting Facebook do something.

On a separate note, you seem to have replied to pretty much everyone in this thread, may I ask why?