undefined | Better HN

0 points3pt141597y ago0 comments

I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it.

For me, that time started about two years ago. At 31, a full 25 years since first learning how to program[0] I finally felt like I could be trusted to make the right calls on when to invest the time to abstract or create generation or code parsing tools; and when to do things the old fashion way.

After two years of spending about 20 to 40% of my time on tooling I'd wager I'm about 10x faster than I was at 30 and about 20x faster than I was at 25.

The problem now isn't writing the code. The problem now is that the code is so fast that I don't have the same amount of passive time to think about features / strategy. I have to intentionally set aside time for it and I find it unnatural. Also, I know too much about cybersecurity which is good for my end users, but bad for my feature productivity.

[0] Poorly. My mum taught me how to code QBASIC. I altered video games.

0 comments

7 comments · 3 top-level

ryanmarsh7y ago· 2 in thread

> I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it.

Indeed yak shaving should only be done when one has the breathing room to do so. It's just good common sense, except there are exceptions. Slack was a yak shaving effort. The most valuable things I've shipped have all been yak shaving efforts. I guess I'm just better at building tools than anything else. Perhaps I enjoy it more. shrug

To each their own, but if you're trying to ship a product instead of a bald yak you're going to have to do it the ugly way, with tools you could fix, etc...

T-hawk7y ago

Shipping is a feature. Your product must have it.

That recursively applies to each tool used to make the product as well.

ryanmarsh7y ago

Shipping is a feature. Your product must have it.

I think I’m going to frame that and put it on the wall. Did you come up with that or did you hear it somewhere?

1 more reply

da027y ago· 2 in thread

What do you mean by, "I know too much about cybersecurity which is good for my end users, but bad for my feature productivity"?

brazzledazzle7y ago

One thing that pervasively infects every decision is the principle of least privilege. Basically it’s the idea that someone/something should only have the minimum access necessary to do what they/it is supposed to do. It applies to infrastructure access control, network communication, application access control, everything. Once it becomes a default part your thinking you sometimes have to make conscious tradeoffs so you don’t spend forever perfecting things and not delivering any value. Ideally a lot of that thought and effort is common or reusable though.

3pt14159OP7y ago

This is most easily explained by examples.

Before:

I'll get my clients to give me access to an S3 bucket that I can push their data to.

Now:

I'll make sure I get my clients to give me a password or public key to encrypt their data before I push it to the S3 bucket because many people fuck up security on those things.

To my end user, it's obviously more secure, but it isn't lining my pocketbook and most end users don't care about security, even if they should. Same thing with security headers or anything, really. Security slows you down at some point.

dustingetz7y ago

This worldview does not take into account network effects, which consolidate the aggregate investment of many people onto a few bad projects. For example Common Lisp is a more effective language than Javascript and always the wrong choice. Corollary: ClojureScript is ecosystem-compatible with Javascript, and TBD if it is a long run better choice!

j / k navigate · click thread line to collapse