Typing fast is not so important

In response to https://www.rugu.dev/en/blog/on-typing-fast.

HN comments.

What to say on this ? I like typing and feeling productive. But the two are unrelated.

TLDR; We need to slow down a bit, as programmers, and as technologists.

I believe there are virtues to typing fast, for the impatient programmer, for the prolific coder, for the over busy person, and because free time is never given to anyone. I tend to be quite impatient at times, because I see fast builds and fast code as solved problems, at least with boring tech.

I nurture other virtues like removing code, remove dependencies, pipeline steps, YAML soup, hundred lines setup instructions and docs, frameworks and libraries. You can shift to simple scripts, binaries and code, that is efficient and -- most important -- that your understand, can maintain and validate and which can fit in your screen without needing to scroll through long files nor switching between tabs and editors to understand it.

There are benefits to pushing releases faster, but it has nothing to do with typing more code faster. Do not push buggy code at first. Understand the code you write and make it boring, readable, concise, because you understand it an you know enough to improve it and vanish some complicated concepts.

Because you focus on the user experience, on quality, on the business, not on the code, you will be able to explain the business that it's more important to do the right thing than having to rewrite the things three times later and debug it four times. You know how to defend your case because and you know the impact of a badly designed solution built too fast. You already prefer quality code, and you know enough about the business to explain how risky it is to push bugs faster and have to spend all your valuable time debugging your code or peers code.

Do I enjoy more YAML and code on a daily basis ? Certainly not. Duplicated code and YAML makes me puke. I'm happy if a colleague thrashes some code I wrote, because in the end we do not need to keep it all. An a good CI pipeline should likely be 2 lines long, not thousands lines long (hello GitLab/GitHub and other YAML soup lobbies). More code is more fragile and harder to validate and rework. Good code takes lot of rework, or maybe more thoughtful upfront design.

Also, do you really want to type the whole day ? Is it your only way to solve problems ? Some things are not so urgent nor important.

  • A single line of code added or removed can make a whole day better. A simple "NO" can avoid tons of bugs.
  • Reading code, learning about boring and legacy tech, will teach you valuable lessons.
  • Discussing decisions and designs with peers, and even in the middle of other things, will lead you to connect more dots together, and lead to opportunities and more collaborative ways to solve the problems.
  • Reinventing the wheel, simplifying solutions, solving problems, thinking, writing, do not require typing faster.
  • Programming do not require typing faster.
  • Authoring good books and novels do not require typing fast.
  • The best work is not always the result of fast work. A good movie/tv show script, a good (comic) book, a good music release, requires thoughtful work.
  • Maybe feeling emotionally pressured to react/rant on internet or social media leads you to type faster.
  • Maybe a bad manager wants you to answer faster to what appears to be urgent/important. But maybe you have to reconsider the urgency.
  • Maybe we do not need to reach 120% productivity, nor 600%, nor 100%. We are not machines.

We do not need more code/bugs in the world, nor more pressure to deliver more in fewer time.

We need more quality and care. We need to take the time to think and discuss code. And sometimes consider doing nothing and maybe waiting for some technology to mature rather than succumbing the hype... hello LLMs and their carbon footprint that ruin long efforts, while a few good IFs could have done the work.

I tend to see myself as a slow programmer, I mean thoughtful one. For a decade at least. And I believe this is rarely valued. Yet an important virtue for me is to take the time.

And reconsider our ways for solving problems rather than trying to convince the world to speed up a little more. We already suffer with enough crap to fix, alerts, dark patterns, slow code, bugs, security incidents, broken tests, broken pipelines, fix(ci) commits everywhere, git conflicts, ignored specs, overlooked docs...

Do we want more code delivered by heroes (or glorified code addicts) through harder and faster work ? Do we want your value determined by your typing speed or the count of hours spent at work ?

Do I really want to pressure peers and myself even more by typing always faster and more, energized with caffeine (which I love too much)? No thanks.

I'm not a luddite, nor for status quo, yet... less is a viable option.

  • Maybe the problem is not so urgent.
  • Maybe this feature will make everyone even more busy with the bugs and side effects and consultancy.
  • Maybe this extra feature or dependency will introduce too much risks and maintenance.
  • Maybe teaching you how to reach the same goal with this alternative way is as efficient.
  • Maybe this work can be avoided with a phone call, a chit-chat or a boring old idea or tool.
  • Maybe you do not need to be a code hero, especially as code is expensive.
  • Maybe you can solve the problem without a computer.
  • Maybe you need something simpler.
  • Maybe your problem was already solved many times before. Do not repeat the cycle or history.
  • Maybe we deserve a more disconnected world, long live local and offline first.
  • Maybe I want a world where I'm not urged to switch apps and copy paste the MFA within a 30 seconds time frame.
  • Maybe I can cultivate patience by watching someone type slowly, and it's fine.

Or if you insist, let's do it the right way, and think of a minimalist, solid and boring way to do it.

Related: Silicon Valley S01E05 - Typing speed

Reading RSS in peace with a few Miniflux Hacks

I'm avid of content curation using RSS feeds. Let me share some of my tips here and some code. This is a living document so please come back for new tips πŸ™‚ and explore my other articles on this topic.

Some of those tips rely on Userscripts which are snippets of code executed automatically on web pages, and usually it's very handy to customize your navigation. I'm using the Custom JavaScript block in Miniflux Settings. But some scripts won't work because of reliance on external resources, and in that case I'm using Tampermonkey for special cases that require loading external resources (think CSP & co).

Filter categories (remove empty ones) using Custom JavaScript block

There is by default no distinction between categories with or without content, and it can be annoying. I made a user script to remove categories with no content to read.

Source

https://gitea.zoemp.be/sansguidon/snippets/raw/branch/main/miniflux_scripts/filter_categories.js

Demo

Before applying the script, we have some categories, including one with (0) unread entries.

After

The category with (0) unread entries is hidden.


Feed organizer - using Tampermonkey

This one is for grouping together all feed entries by feed/author in the main on unread, read, and starred pages. I needed this one because by default, in unread tab, the feed entries are mixed all together and I often wanna consume content per feed/author and not in chronological order.

Source

https://gitea.zoemp.be/sansguidon/snippets/raw/branch/main/miniflux_scripts/feed_organizer.js

Demo


Distinct boring from interesting feeds thanks to objective ranking - with Custom JavaScript in global settings

When opening the "Show all entries" view of a feed, this trick will show you if you shall keep this feed or not. The classification is based on the ratio of starred entries vs total. In this case, clearly, my assistant tells me it's quite πŸ₯± boring. Other values are: Thinking πŸ’­ (in case we lack data), Interesting 😍 (we star a lot of items), Thinking πŸ€” (in case we stared at least some entries). Feel free to make it yours and customize the behavior!

Source

https://gitea.zoemp.be/sansguidon/snippets/raw/branch/main/miniflux_scripts/feed_classifier.js

Demo


Fetch original content - Per feed settings

This is a trick that works well with the majority of feeds so you can fetch the whole article content in your reader instead of just the excerpt.


Filter feed entries by title / content

I've customize the feed settings to exclude specific keywords, and on top of this I've also global rules which apply to all feeds, for excluding feed entries when keywords are found in their content or title. This makes it easy to exclude clickbait uninteresting or depressing content πŸ™‚

My current setting is here as an example https://gitea.zoemp.be/sansguidon/snippets/raw/branch/main/miniflux/block.rules (RSS)

In this case I follow news with heavy metal album releases and I'm excluding specific genre like Death Metal. I'm also abusing the feature to avoid being spammed with recurrent news like Olympic games (Paris 2024). Finally there are already many reasons for me to be anxious, and I do not need more. The last rule saves me from the useless negative news. I keep fine tuning the list and I could improve this by including terms from public blacklists, like this.


Startup options

You can override Miniflux behavior with some environment variables. See https://miniflux.app/docs/configuration.html for more configuration options.

Those are mine and make Miniflux more indulgent to unstable RSS feeds.

export HTTP_CLIENT_TIMEOUT=60
export POLLING_PARSING_ERROR_LIMIT=6

Last updated: Sept 5, 2024 around 9:51 AM CEST in πŸ—ΊοΈ Brussels, Belgium.

Prompt hacks aka make the best coding out of GPT

I've been using a paid subscription to ChatGPT Plus since May 2023 and I'm still happy with the usage. It's one of those tools you have to master to get most of the time spent with it. There are a lot of benefits to use it, of course there are also negative aspects and bugs. Some of them can be mitigated, and that's the purpose of the current post.

Disclaimer / Context of use 🧾

  • I'm ChatGPT mostly for scripts and each conversation is focused on singular topics, i.e single-file codebases if possible.
  • I don't use Open API Keys and I'm not interested to use OpenAI directly. I've been on a paid plan for OpenAI and was charged way too much for my needs. I advise anyone to use ChatGPT Plus which remain to this day worth it and good enough both for personal and professional.
  • This article was not written nor reviewed by AI/ChatGPT.

Lessons learned - Do βœ…

  • Timebox your interactions with ChatGPT. If it takes longer than you expect to reach a solution, stop and do your homework instead.
  • Test test test after each change. ChatGPT will make you lose faith by repeating the same mistakes, by removing sensitive code, by providing incomplete solutions, always verify.
  • Before running or committing anything generated by ChatGPT, always compare with the previous situation you had. Git diff the result of changes. If you have any doubt about a specific change, submit the git diff to ChatGPT for review and ask for explanations while also explaining why you have doubt (failing tests, errors at runtime, weird code removal, ...).
  • Tell ChatGPT to always decouple code in functions.
  • Instruct to use minimalist code, and avoid comments in code, respect your specific style (if you provide examples), instruct to write the code that takes the least amount of lines and space and to avoid long functions.
  • Keep one conversation per context / type of problem / flow. Once done with the problem, validate the solution (test!), commit locally, and delete the conversation to keep your Chat history clean.
  • Try to limit ChatGPT's attention to one single file or one single function at a time, to improve its speed and accuracy. I've experienced inconsistencies and code regressions when expecting ChatGPT to work with too many files and too many changes at once on too many files, as then ChatGPT.
  • If you have lot of work you expect ChatGPT to perform for you, be patient and request one change at a time, then review the outcome, and only if it's validated, move to the next. ChatGPT sucks at multitasking. Keep the rest of your TODO list somewhere else to keep track of what remains to be requested from ChatGPT.
  • You will be given better results if your tech stack relies on popular libraries and programming languages so keep that in mind and be prepared to deal with more mistakes if you pick niche programming languages.
  • Ask to only output the code that require change, e.g add this at the end of your prompt :
    just output the function(s) needing change
  • If you really want to multitask, open multiple ChatGPT sessions (browser tabs) in parallel, each focused on distinct changes, so you can multitask while ChatGPT stays focused on single tasks πŸ™‚
  • One change at a time. If ChatGPT keeps making error, step back, restart from to the latest stable version of your code, and ask to make minimal changes, step by step, while you validate each increment.
  • When happy with your changes, ask ChatGPT to improve its performance or clean the code.
  • When debugging your code with ChatGPT, provide stack traces, inputs, outputs and even complete your input with the copy of the code that seems buggy (based on the stack trace).
  • Be suspicious if ChatGPT changes your code way too much or introduce weird changes to dependencies. Review, check, investigate.
  • ChatGPT will likely be interesting to use only for writing very small and boring scripts to batch automate some tasks. But you are responsible for the whole, do not forget that. And test. And understand the code. Make it easy to understand and debug. If you can't explain it, rewrite.
  • ChatGPT could be good at documenting tasks or at writing tests.

Lessons learned - Avoid ❌

  • Don't trust ChatGPT outputs. OpenAI is known for dreaming and also tends to complexify solutions to simple problems.
  • Don't run nor commit anything generated by ChatGPT that you don't understand and always compare ChatGPT's solution with what you had before.
  • Don't ask too many improvements or bug fixes at once or be prepared to deal with many new errors and regressions.
  • Don't keep conversations for too long, as all the initial context will likely be forgotten about by ChatGPT and you will suffer, also it will cause a lot of scrolling and augment the size of the web page which will be slower to load and will likely crash your browser tab at some point.
  • Don't switch context / files / problems in the same conversation. It's a waste of time and you will suffer later when trying to source specific content or make sense of anything.
  • Don't share secrets/passwords with ChatGPT.
  • Don't waste your time when the LLM seems confused or unable to solve your problem. Either reshape your problem statement or restart from the latest known stable state, ideally in a new conversation. Be confident in your own abilities. Don't be too dependent on any LLM. I once wasted a whole evening and night trying to get ChatGPT to write the solution for me then trying to use it to fix the problems it caused, I was too lazy to code something by myself from the start.
  • Don't expect ChatGPT to be as efficient on big codebases and complex problems as it is on small scripts and simple problems. So use it more often for the latter and keep the fun of solving the big problems yourself.
  • Don't expect ChatGPT to understand a single thing you do nor why he generates his code. it's a dumb machine without creativity built in. It has to be treated as such and with caution.
  • When trying to help you fixing problems caused by its previous solutions, ChatGPT may enter and endless loop of replacing one solution with another, without understanding the context. Before copy pasting anything from ChatGPT, make your own investigation and check the logs of the apps that do not behave as expected, before touching the code. If you find interesting logs, then provide those to ChatGPT or make your own investigation. Do not depend on ChatGPT for too much grunt and research work. You are better than that.
  • Don't expect ChatGPT to run well and fast on huge bloated scripts. That should encourage you to decouple your code into functions and modules and specialized files/modules/components/...

Relevant references

  • ChatGPT could be used to address the fact that solving some problems is costly in term of engineering. This XKCD meme below should be likely made obsolete if LLMs are used to provide the programs to automate the tasks. For instance when faced with some painful work, I rather use LLM to write me a script to tackle the task. It will be faster than me on some occasions, which itself help removing the need for manual work for tedious tasks, also help removing the need to prompt LLM in the future for that same task, since the script is already provided.
Automation (by XKCD)

Legend: "I spend a lot of time on this task. I should write a program automating it!"

via https://xkcd.com/1319/

is It Worth the Time? (by XKCD)

Legend: "How long can you work on making a routine task more efficient before you're spending more time than you save? (across five years)"

via https://xkcd.com/1205/

Extras

  • If you lose focus on the ChatGPT session in your browser, it's likely the calculation process will interrupt.
  • ChatGPT seems stuck at generating the output ? Refreshing the page might be enough, in other cases ChatGPT might automatically continue the generation or will show a button you can hit to force this action.
  • I've commented on this topic and this post at https://lobste.rs/s/7a3qhh/how_s_your_experience_so_far_using_llms_for#c_igssaj
  • I recommend trying ollama so you can work offline and without feeding all your sensitive data into OpenAI.

Thank you πŸ™‚


Quick Bugs, Slow Fixes

The 🐒 engineer has good guts but often seems slow compared to the 🐰 engineer.

The 🐰 engineer is quick at decision and gives impression of progress to the product owner often disappointed with the slow pace of change of the 🐒.

The 🐒 is busy battle testing the draft he's about to integrate in the product, suddenly he finds out the new bugs were introduced recently by the 🐰, and decides to postpone his work while focusing on debugging the shit.

In the meantime, the customer complains because of the new bugs introduced in latest release by the 🐰 engineer.

The product owner is worried and decides fixing this bug is a priority.

  • The 🐒 engineer was already investigating the bug and proposes a fix.
  • The 🐰 engineer cannot wait for the 🐒 to fix the bug and already merges new changes in the stable branch so the new release will not only be bug free but also deliver new quality shit.
  • The 🐒 is busy integrating and retesting all the new changes made by the 🐰 as it seems those changes includes critical changes of the core authentication layer and library updates that had nothing to do with the features the 🐰 was working on.
  • 🐰 lacks time for testing for side effects, so his changes bring bugs πŸ’©, whatever, at least code is delivered, whether it works, that is someone else's problem (🐒 of course).
  • The 🐰 becomes impatient at the slow 🐒 and decides to create a hotfix πŸ’₯ and deliver his changes to production.

The customer is still unhappy 😠.

Ignoring the new bugs, the product owner finds it's time for 🐒 to deliver things too, but is happy the 🐰 is done.

The 🐒 will be busy with kids at home while also thinking about all new bugs caused by 🐰.
The 🐰 thinks and claims 🐒 is not delivering and working enough hours.
The 🐒 is tortured with this lack of teamwork and with all the shit πŸ’© that is being merged in the codebase by the 🐰.
The 🐰 says it's time to hire more people and he knows other 🐰 who can help and it would be nice if the 🐒 worked more like 🐰 is doing.

The 🐒 suggests to focus on quality and teamwork and slow down but the 🐰 and the product owner look at him suspiciously.

The product owner suggests the 🐒 to consider leaving the team if he's not happy with the way things are. Because in the end, speed and working long hours are important even if results are not perfect.

🀦 "fuck this shit". A few weeks later, 🐒 has left.

The 🐒 is working in a good team nowadays 🀲, where testing is a thing βœ…, quality is under control πŸ‘Œ, documentation matters ✍️, and collaboration is a foundation 🀲πŸ’ͺ.

Related

How the situation should be managed instead by the PO / Lead.

https://workchronicles.substack.com/p/comic-be-like-bob-he-works-long-hours

Don't be like the 🐰-> See broken window theory.


Nerds Against Clutter: My Digital Downsizing Diary

Declutter and letting go.

  • Dropping Discord, Diaspora, Daily.dev, maybe Pixelfed and Mastodon next (done, by March 2024). Too buggy, too noisy.
  • Kissed Google Keep goodbye and embraced Obsidian even more, thanks to the Importer plugin.
  • Trying to escape the WhatsApp surveillance state. I'm axing useless groups left and right.
  • Scrubbing my old web presence. It's like digital housekeeping.
  • Using Syncthing now. Real-time sync across devices without cloud middlemen. Dropbox, you're on notice.
  • Deploying FDUPES for disk decluttering – it's a duplicate file slaughterhouse. Throwing inotifywait into the mix for smart folder monitoring, because who likes manual mess management?
  • Cut down on RSS. I've dropped Wallabag (done by November 2024). I'm still using Miniflux. and Shaarli with their weaknesses. Thinking about it. Bookmarking tools still suck somehow and I can't see a better alternative (yet) for my needs... yuck, so I'm working on my own thing, Tapas. Looking at the market for knowledge and bookmarks management tools, there is room for improvement in how we manage and consume information. Most of the hard work is on you for years with tools that connect to information.
  • Harnessing RSS-Bridge and Miniflux for streamlined info feeds. Using Changedetection for the unRSS-able stuff, i.e to monitor some indexes, lists, legal terms, release pages.
  • My tab hoarding was legendary, now capped at 18 with Tab Limiter. Browser zen achieved.
  • I have been known by my colleagues and partner to keep too many tabs open. My nerves cracked at reading other folks suffering same issue. So I decided to close a number of them, and limit each Window to 18 tabs with Tab Limiter.

Exploring and creating.

  • Blogging's up, but it's a discipline game. Need to turn Obsidian hoarding into public wisdom. Notebooks over phones, knowledge over scrolling.
  • Taming my Brave extension zoo with Context. It's like a digital bouncer for my browser. Funny, now I've more UX/Privacy oriented extensions than tabs.
  • Eyeing Geeqie to outsmart duplicate photos. Even my pixels need to be minimal.
  • n8n (Zapier/IFTTT alternative) is my new digital butler, still a bit rough around the edges. Coding my own automation magic because their recipes are just appetizers for my needs. For the record I'm now using it to automate RSS feeds triage and automate the web archiving of some bookmarks as I feel archiving beats bookmarking.
  • Diving back into Rust. Cooking up something for productivity and knowledge management. Stay tuned.
  • And of course, some snowballs and video gaming to keep things balanced and fun.

To be continued.