facundo_olano

Most orgs never get to that scale

Absolutely annoying to have it assuming that I want to use this when I type workflow in the prompt. Like thats not already a thing in half of the software projects

Author here. I'm surprised to see this surfacing now. I just wanted to clarify, since apparently the post doesn't do a good job at it, that what I discussed there is not a methodology I advocate for. The point of the post was: ok, since there are organizations mandating to maximize speed by reducing time spent on typing code (or even mandating to maximize agents usage), is there a way we can meet that requirement while still preserving the rigor somewhere else?

This was a follow up to a previous article[1] and the pair tried to express what I still think today (using AI daily at work): every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. This is not necessarily always a bad tradeoff, but I think it's important to constantly remind ourselves we are making it.

[1] https://olano.dev/blog/tactical-tornado/

A Makefile is good for this, and why not checking it into git?

Is there a recommended modern day, non mac specific, equivalent to those "Macintosh Human Interface Guidelines" linked at the beginning of the article?

Willing to accept AI agents can replace programmers

Not willing to accept ex-US devs can do a comparable job at half the price

I started with prelude[1], I wanted something batteries included to use as my main editor right away, but not as structurally different from vanilla as Doom or Spacemacs. Then after a couple of years I rewrote my config line by line looking at what prelude did and keeping only what I needed.

I’m happy with result, but this was 7 years ago so there may be better options than prelude to do something similar today.

[1] https://github.com/bbatsov/prelude

I built that feature (auto mark as read by scrolling) into my feed reader if you’re up to self host and curate your sources

https://github.com/facundoolano/feedi

I did try to build a public facing news aggregator with a similar ux but I couldn’t pull it off purely based on client side state (and I didn’t want to do user management)

I’ve been using Magit at work because it’s what everyone uses.

Where do you work?

I have the same issue, the chronological nature of feeds kind of breaks this flow. It feels like there’s a missing piece, like a standard to browse older content from a blog. I Wrote a bit about this here: https://olano.dev/blog/web-anthologists/

I wrote my own org-mode static generator: https://github.com/facundoolano/jorge

More robust than my previous emacs setup and much lighter than hugo. No fancy babel generation but I don’t really need that.

As a non native English speaker/writer there are a bunch of errors I miss, no matter how much attention I pay and how much I proofread, and these tools are useful to catch those.

you should try the reader then https://github.com/facundoolano/feedi

Most of the "structural" events of the story are true, most of the scenes are made up or pastiche. If you're interested in the facts, I suggest taking a look at the sources at the bottom, especially the Mark Ferrari interviews: https://youtu.be/ri4_3P2Oh14?feature=shared

https://www.reddit.com/r/indianajones/comments/1hwce4a/india...

This story broke my rss reader.

I considered adding them (also considered adding links to the book page) but I ended up preferring the uncluttered titles only version. (I know it makes it inconvenient to lookup the book).

Make sure to also include a link tag in all the website headers, so the feed is discoverable by readers:

     <link type="application/atom+xml" rel="alternate" href="/feed.xml" title="olano.dev"/>

Depends on how your blog is generated. Static generators like jekyll have plugins for this[1], but it’s also easy enough to generate it by hand with an xml template [2]. Wordpress, substack and other platforms generate it by default afaik.

[1] https://github.com/jekyll/jekyll-feed

[2] This is mine: https://github.com/facundoolano/olano.dev/blob/main/src/feed...

TIL thanks for commenting, I'll make a note to fix this.

+1 I'd say it's a great read even if you don't plan to do much Erlang or Elixir programming.

I second this. I wrote a post around this idea of non chronological blog archiving https://olano.dev/blog/web-anthologists

I really like this metaphor of provisioning architecture and staying clear of dead ends. I'd say dead ends come not just from bad quick design decisions but also from wrong predictions (in the scenario you describe where it's hard to tell what the long term looks like ---which is most of the times).

awesome designers are great at predicting where the architecture will be and at forward-provisioning it.

And this matches the No Silver Bullet conclusion.

I was curious about this position (the fact that you are upfront that you need to do a big refactor), but then the application form was very off-putting.

Tell us about yourself in 3 KPIs, with a brief explanation and examples. (A KPI is a number that evaluate performance in a specific aspect.)

Record and upload an unedited face-cam video (3 to 10 minutes) where you explain a problem you had this week and how you solved it on your own.

SEEKING WORK | ARGENTINA (GMT-3) | REMOTE

Résumé/CV: https://olano.dev/resume/ GitHub: https://github.com/facundoolano Email: facundo.olano@gmail.com Technologies: Erlang, Elixir/Phoenix, Python (Flask, FastAPI, Django, Celery), Golang, Rust, Clojure, Postgres, Redis, AWS, DataDog, Terraform.

Hi, I'm Facundo. I'm a Software Engineer with over 15 years of experience, most recently developing and operating large-scale backend systems. I've done technical leadership, project management, and legacy modernizations. I'm good at understanding business and customer needs, and writing reliable software.

I kind of want my Emacs scratchpad to work like this now.

If I were going to suggest anything, it would be "don't use Readability" since it isn't a good fit for this use case.

It is a perfect fit for the user experience I was going for, even if it adds development and operational complexity --both of which were a lower priority for this project, as I stressed in the blog post.

In other ways, I’m upset and jealous the author got there first.

Don't be! the whole point of this was to build something for myself, and use the process to reflect. There's no reason why trying something similar shouldn't work for you, I certainly wasn't the first to implement a personal reader.

Fun fact: I just skimmed through one of the indie web posts I linked (which I had read months ago) and it struck me how much of their ideas I just replicated almost verbatim in my post:

Firstly, don't try and make your software work for everyone, or just for a specific set of people you think may be interested. Make it for you.

By making it generic and possible for others to work with it, you'll make tradeoffs that may make things worse for your own usage, or may even design for an imaginary user that may not even exist, or build a system that with 17 different configuration items you could have a completely different system. Be selfish and make it more useful for yourself.

fwiw my reasoning wasn't javascript -> node, it was more that I was biased towards doing all significant work on the backend. So it didn't even occur to me that I could add some ad hoc logic to fetch the article HTML from js, pass it to readability and insert the in the UI, which I guess is what you suggest.

Having this logic available in the backend was convenient for me, anyway. I'm using it also for the "send to kindle" feature, which I couldn't have if content cleaning was done browser side. Having it in the backend also opens the option to save the content in the db to skip loading/parsing latency and preserving it long term.

(I'm the post author). I agree with this. Perhaps I'd emphasize larger in terms of people working on it rather than codebase size. Once you have competing "mental models" about how the code works, the problem of silent bugs can escalate quickly.

So I do think the "always test" mentality is a reasonable default for the non-prototype type of work. There's a tipping point where going on without testing can get the project out of control and it's hard to tell when that is, so in contexts where you care to avoid that risk it makes sense to be strict about it. I didn't care for that risk in this case, so it made sense not to bother and focus on building momentum. I'd probably add some integration tests now if I wanted to try a significant new feature or refactor, or if I had to consider contributions from other developers.