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

Markdown: a text adventure

Seriously I wonder what is wrong with us, computer scientists and computer hobbyists. I thought I loved markdown, that I needed to keep telling the world about it, but what renders in Gitea is not rendering the same in GitHub, nor in Obsidian. I'm likely idiot, let's find out.

The guide at https://www.markdownguide.org/book/ already starts by confusing its readers, looking for simplicity, with prompting the user to pick between normal or extended syntax. The top menu also mentions hacks and tools and books. Woot ? Aren't we talking about a simple text format and about making things simpler ?

This can't be so complicated, at least I thought. Then I visited https://en.wikipedia.org/wiki/Markdown#Implementations and fallen of my chair -- note the >dramatic< tone here, but I'm only sitting in my sofa and avoiding sleep, I'm all fine.

I hope we are solving this problem. Likely, the smart people figured it out... < o> < o> https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=variant+markdown&sort=byDate&type=comment. Woot.

Damn, even on Markdown supposed to provide a simple and better source format and publishing tool than HTML, we experts can't agree. Myriad of tools and implementations each extended by a few more artisanal tools here and there, millions of hours wasted ?

They are plenty static site generators and people crafting them and enriching markdown with details to hopefully generate, well, mostly valid HTML ? Or not ? Last time I checked, only an handful of those would take care of this goal.

We could chose to go back to working with text or HTML without tools in our way. This blog post for instance is almost just text and links, nothing much I require from markdown. This likely makes this portable. No transpiling needed, no tools.

It's NOT SO HARD and still readable. This blog post also has links that do not require remembering keyboard shortcuts on Mac for [Title](...) nor combining any special key.

Markdown is like sharing a recipe, but everyone reinvents a different complicated meal.

Simple is however better.

Instagram

As a reminder of how shitty those social media can be, I'm feeling obligated to write this short rant.

This morning, using my secondary empty and idle Instagram account to do some research, I end up discovering a nice content through the home page feed, and I'm trying to share it with my partner.

For some reason, the share does not reach my partner, so I want to find the content again and I navigate backward and this triggers a home feed refresh. My home feed is now completely unrecognizable and this causes immense frustration.

Last week, I was about to revive my main Instagram account, and this kind of bad UX reminds me that the benefits are not worth the immense frustration and non-sense of navigating an endless loop of evaporating content. No, Meta, you won't fool me again.

Fear of missing out ? not worth it.

Magic is problematic

I deal with computers, hence I want things to work the most boring and reliable way possible, with automation, procedures, scripts, not through magic.

Hence, while I love tools such as Atuin, I've a problem with their slogan "Making your shell magical" and generally speaking with any product using such selling argument, especially AI LLM-based products.

For this reason, I'm usually against any kind of black box and one-for-everything tools and platforms that want to ease our lives by hiding the complexities. I think that the only result we get out of those abstractions is complexity, pain, and a culture of incompetence and dependability. I mean, if you want to deal with technology, at least you should understand it.

In the end, it's not all magic [1] [2], but it can feel magic for sure once we lack understanding. Magic feels shiny and appealing after all, its antonyms say it all.

Let encourage everyday users to look inside the box and understand what is happening, even if not everyone is going to switch to Linux, even if debugging is not easy.

At work, there exist an onboarding procedure targeted towards new developers in the team, and this procedure relies on scripts which were left untouched for way too long. The bad things : the procedure is broken but nobody dares to fix it, instead the old timers in the team share dirty hacks and workarounds with the newcomers.

Once you face such problem, the only solution is to address the root causes, not the symptoms. I choose to take a look at the procedure, run it again and again after each attempted improvement, cut it piece by piece, shred or rewrite what seems unreliable and suspicious.

Magic exists, but I’ve never seen any in software. Problems are logical. Nothing is impossible. You can solve this problem.1

As a software engineer, please don't fix symptoms. Don't get too used to deal with crap and unsolved problems. Don't be lazy, don't accept the status quo, make the hard work to understand and solve the problems. Set your focus on understanding things deeper. Enhance your and everyone's knowledge. Be a firefighter against ignorance, and help educate your peers to be better at understanding why things work or doesn't.

Thank you.

HN Comments.

  1. https://catskull.net/thoughts-on-debugging.html β†©οΈŽ

Prompt hacks aka make the best coding out of GPT

THIS WILL BE CONSTANT WORK IN PROGRESS

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 βœ…

  • Shorten your expectations. Timebox your interactions with ChatGPT. If it takes longer than you expect to reach a solution, stop and do your homework instead, debugging yourself or simplify the problem to solve or take a break...
  • 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 code diff and then the outcome, and only if it's validated, commit and move to the next step. 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
  • Ask to not change the existing comments, login logic, variables values in the code that is not impacted by the 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 or keep it minimal.
  • When debugging your code with ChatGPT, provide stack traces, inputs, outputs and even 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. Always 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, but for working on complex code it will mostly get 70% of the results then will suck your time and patience.

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

  • The 70% problem: Hard truths about AI-assisted coding (substack.com)
  • 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 recommend trying ollama so you can work offline and without feeding all your sensitive data into OpenAI.

Thank you πŸ™‚