Hacker News Reader

> I spend most of my time thinking about the problem, how to solve it...

A few years ago, I got a small but painful cut on my fingertip. I thought I would have a hard time on the job as a dev. To my surprise, I realized I spend 90-95% of my time thinking, and only 5-10% of the time typing. It turned out to be almost a non-issue.

As the owner of a fairly normal American address that is either corrupted by the UPS address validation service, this is a good time to remind everyone: accept the address that your customer enters. If you offer a service to try to improve your customer’s address, keep in mind that it’s a value added service, it may be wrong, and you MUST test the flow in which your customer tells your service to accept the address as entered. And maybe even collect examples in which the address change is accepted to make sure it does something useful.

Vendors have lost sales to me because they were too incompetent to allow me to ship things to my actual address. Oops.

P.S. for the US, you need to offer at least two lines for the address part. And you need to accept really weird things that don’t seem to parse at all. I know people with addresses that have a PO Box number and a PMB number in the same address. Lose one and your mail gets lost.

P.P.S. If you offer discounted shipping using something like SurePost, make sure you let your customers pay a bit extra to use a real carrier. There are addresses that are USPS-only and there are addresses that work for all carriers except USPS (and SurePost, etc). Let your customer tell you how to ship to them. Do not second-guess your customer.

> I don't really have a problem typing.

Im absolutely with you and want to upvote that part of the comment x100. Unfortunately it's often considered a fairly spicy opinions.

Entire frameworks (Rails) are built around the idea of typing as little as possible. Others can't even be mentioned without the topic of boilerplate/keystroke count causing a flame war (Redux).

A lot of engineers equate their value with the amount of lines they can pump out, so there's definitely a demand for tools like these.

There's also some legitimate stuff. There's a lot of very silly thing I have to google every time I do because I have a bad memory. It saves the step of googling. In a way, it was the same debate around autocomplete at the very beginning, but pushed to the next level. Autocomplete turned out to be a very good thing (even though new languages and tools keep coming out without it).

I never commit something that I can easily google (with a high quality solution) to memory

>Because from my experience, typing code is the fastest part of my job. I don't really have a problem typing. I spend most of my time thinking about the problem, how to solve it, and considering ramifications of my decisions before ever putting code in the ID

So very true.

[1] Understanding the problem > [2] thinking about all possible solutions > [3] working out which solution fits best > [4] working out which implementations are possible > [5] working out the most suitable implementation

... and finally, [6] implementing via code.

A lot of my job is thinking hard about how to do [X], incidentally needing to remember how to do [trivial thing Y] and looking it up.

Like, I did it before, remember that it was trivial, I just forget the snippet and I have to break focus to look it up - often by scrolling through my own commit history to try and find the time I did [trivial thing Y] four months ago.

I do kind of wish I could automate that. Skipping the actual typing of the snippet is sort of gravy on top of that.

It would be nice if there were a way to automate the "remembering what that one function is called and what order the parameters are in" portion of my job.

IME the best thing for this is looking at the method listing in the docs for the classes I'm using. E.g. for Ruby, it's usually looking at the methods in Enumerable, Enumerator, Array, or Hash. Or I'll drop a binding.pry into the function, run it, and then type ls to see what's in scope.

Even in the 90s that was a solved problem in Visual Basic with autocomplete. That a lot of dev environments "lost" the ability to do it is mind boggling. With that said, doesn't Rubymine let you do that with autocomplete with the prompt giving you all the info you need? (I haven't done Ruby in a long time).

Still, having to look up the doc or run the code to figure out how to type it is orders of magnitude slower than proper auto complete (be it old school Visual Studio style, or something like Copilot).

orders of magnitude slower than proper auto complete

Having worked extensively with verbose but autocomplete-able languages like Java, compact dynamic languages like Ruby, and a variety of others including C, Scala, and Kotlin, I've come to the conclusion that, for me, autocomplete is a crutch and I develop deeper understanding and greater capabilities when I go to the docs. IDE+Java encourages sprawl, which just further cements the need for an IDE. Vim+Ruby+FZF+ripgrep+REPL encourages me to design code that can be navigated without an IDE, which ultimately results in cleaner designs.

If there's any lag whatsoever in the autocomplete, it breaks my flow state as well. I can maintain flow better when typing out code than when it just pops into being after some hundreds of milliseconds delay. Plus, there's always the chance for serendipity when reading docs. The docs were written by the language creators for a reason. Every dev should be visiting them often.

That's totally cool but the grandparent was talking about remembering shit they already knew. Not everyone has a fantastic memory, and remember the arguments are A then B or B then A doesn't deepen your understanding of a language. Most of the time the autocomplete and the official doc use the exact same source anyway, formatted the same way, with the same info.

But if it works for you, more power to you!

remember the arguments are A then B or B then A doesn't deepen your understanding

What I meant is that you will coincidentally learn new things by going to the docs for old/simple things. In addition to remembering that method ordering, you might learn about a new method that simplifies your task.

this sounds super interesting, is there a video or upload somewhere that i can watch this being performed in real time?

I very briefly show some of the interactivity of Ruby+Pry here: https://youtu.be/Gy7l_u5G928?t=805 (the overall code segment starts at https://www.youtube.com/watch?v=Gy7l_u5G928&t=626s)

I'd be happy to hear about better demonstrations, and there's also Pry's website (https://pry.github.io/) where they link to some screencasts.

I spend most of my time thinking about the problem, how to solve it, and considering ramifications of my decisions before ever putting code in the IDE. So Copilot comes around and it autocompletes code for me. But I still have to read what it suggested, making edits to it, and consider if this is solving the problem appropriately.

So, rather than helping people program better, all its done is replace a bunch of the offshore cut-and-paste shops with "AI."

Isn't address storage and validation a solved problem? Why is it so complicated?

Ex:

412 1/2 E E NE

412 1/2 A E

1E MAIN

1 E MAIN

FOO & BAR

123 ADAM WEST RD

123 ADAM WEST

123 EAST WEST