Ask HN: Tinkering Too Much?

1 pointsOezMaster3y ago2 comments

Hello Friends, hope this is relatable to you.

I think i spend too much time in the REPL and in documentations. I like learning new things, and testing them out in an interactive environment, without bothering to deploy at some point.

I might write 20 different versions of a Method, just to discard it in the end. In my mind, this is not wasted time, but my Employer might think differently. I want to impress him with my skills, but can't bring myself to produce anything usable.

At its core, it is Escapism. How do I get my Head out of my Ass and start producing?

2 comments

eternityforest3y ago

I thoroughly appreciate the honesty and bluntness. I tinker 1/10th as much as I used to, and... honestly even that amount makes me feel that my head is deeply wedged in my ass, on account of how little utility, education, or enjoyment it brings compared to... pretty much anything else. Only a small fraction winds up being anything other than throwaway, so before I start coding, I try to do a lot of research to figure out if it's worth it or not.

I wonder if trying non-REPL oriented coding would be a useful change of pace. I've never used one in any significant way, beyond a bit of debugging, but it seems like REPL programming is like a whole different way of thinking.

My "Extremist Anti-tinkering" workflow is pretty much:

1. Survey all existing solutions. Find out if I can avoid the whole project and use something off the shelf

2. Look for libraries and frameworks that do most of it. Look for the super high level integrated and enterprisy stuff.

3. If something takes more than 5 minutes, start getting suspicious that it will be a continual challenge not just a one time learning curve, start looking at other things.

4. If I think I might have to explain something to someone, assume they won't be interested, and look for something they already know.

5. For design decisions, look at similar things and copy their architecture, UI concepts, etc. Maybe I'm not actually making a traditional TV remote... but can I model my protocol on Roku's ECP?

6. Instead of Agile continual refactoring, continually and aggressively look at what interesting new things to get rid of and replace with something standard. Users and passwords? Can you just use pass through the auth request to Linux system accounts?

7. Look at the documentation. If there's any documentation you can eliminate by adding more code to automate something, do that.

8. Use the linter. Use type hints. Don't use deprecated APIs. Use the debugger. Use the recommended project template. Use the configuration everyone else uses. Code in such a way the average StackOverflow poster would approve.

Basically, I try to code things that a suckless fan would spit on, and a captain in Star Trek would love.

A lot of great things have come from tinkering... but the tech community acts like it's the be all and end all of development, and takes it way too far.

gjvc3y ago

start by writing tests which follow the shape of the system required to solve the problem. tinker away all you like in the pursuit of fixing those.

j / k navigate · click thread line to collapse