kixxauth

Yeah, pinning dependencies is very similar to vendoring or cloning them. By cloning, you get to know the code better and how it is structured, plus you cherry pick only the features you want.

But, like you said, you are at risk of introducing new vulnerabilities.

I'd just prefer making that bet on myself than someone I don't know

It makes me wonder if large engineering organizations are going to splinter. The coordination costs are getting, proportionally, much larger than they used to.

When I left my corporate engineering job wayyyyy back in March, there were engineers and engineering leaders going off and getting a lot done, individually or in small teams. But project management and QA couldn't keep up with it. Managers resorted to turning their tokens loose on Jira just to try to make sense of it all (which, ironically made them the first to hit their token goals on the dashboard every week, and brought Jira to it's knees).

And, even worse, the junior engineers had no idea what was going on or how to get involved in anything.

The result was an increasingly chaotic mess.

I really don't like how the payment plans work with the providers right now. I feel this pressure to use all my tokens for the week, often just "wasting" them. But also, I want to take advantaged of the subsidized tokens in Claude Code and Codex for as long as I can.

There is this real danger that our thinking, and the things we make, become bloated without constraints.

IMO software has gone to shit since both mobile phones and laptops mostly have massive amounts of compute. We always seem to use it to the limit, just because it's there.

Vendor your dependencies, clone or port them where needed, and freeze them. Most good packages these days do not have a deep dependency tree, and we should stop using the ones that do.

I spent a week with claude and codex re-implementing several packages which had dependency trees deeper than I would like.

Most of these packages are trivial to clone.

"But now you're not getting the upstream fixes" they will say.

"So what?" I reply

I heard from someone, somewhere, that coffee and free wifi may be the biggest economic value driver of all.

What aspects or use cases of crypto do you find important?

Yeah, it's appropriately ironic that these things were supposed to give power to the people (excluding the private jets), but power has become consolidated to those who have the means to consolidate it ... and the climate pays.

It's no longer a boom (and yes, AI is probably far worse at this point)

And proof of stake consumes less energy, but still significant.

Additionally, a question for you: I don't have experience in finance. Do you think this idea of having a settlement period for crypto transactions could work?

Ha. That's cynically hilarious.

The carbon emission problem with crypto currency and AI is analogous to the oil and gas industry. When you boil it down to first principles, we are extracting resources from the Earth, and destroying our climate, in the hope of some sort of economic gain.

And the economic gain is tenuous at best.

I wrote an opinion on HN about the carbon problem in crypto as well.

Ha, yeah. So, maybe a stretch here.

I'm thinking of use cases like distributed domain name lookup systems, identification systems, social networks.

I'd be really curious to know if this could be use case for AI code generation tools using speech recognition. I don't know of any, but this could be very interesting.

I was part of this discussion in 2009-2012, and was curious if it was still out there. It is!

It's fascinating to take dig stuff up like this and replay it, knowing what we know now.

Of course, everyone is using the new ES modules spec now, but it's hard to imagine how we would have got there without working through the ideas which led to CommonJS.

This started before Node.js, when we were playing around with the Narwhal runtime.

One really interesting concept which never got traction was creating a standard library for JavaScript.

Learn to love JavaScript. Then you'll always have fun building side projects.

Sounds snarky, but I'm serious. You can build anything with it, and it can be fun to use too.

To really become valuable in your role you need to leverage your experience and skills to become a force multiplier (as mentioned several other places in this thread).

There is some good advice in here to help junior devs level up. But I would start by boiling it down to one that is easier to remember as you become a manager / coach:

Try to remember what worked well for you when you were learning, and then do that for your team.

I have gone back to that well over and over as I've moved between senior, principal, and management roles.

Copilot may be one of the most valuable early use cases for chat AI.

I've been brushing off AI as overhyped, but this is very compelling. I believe the real crux of software engineering is thinking about the problem and organizing solutions today which can be changed/improved/iterated in the future. Programmers too often overweight the time it takes to type things (using short variable & function names or creating terse 1 liners). But if our objective is to make code easy to change/improve/iterate in the future, then it needs to be readable now.

The nice autocomplete features in most IDEs have been a huge win to productivity along with Google search. I think chat AI could be an order of magnitude improvement.

I’ve been recreating in the mountains for a few decades now, some of it pretty serious. Honestly, nothing has taught me more respect for life than being challenged in the mountains. The lessons I’ve learned I’ve applied to software, management, and life in general. It allows you to keep a cool head when the world is on fire.

+1 would recommend

Looking through the comments on this post, it's no surprise that many HN readers are doing the same. A self selected audience, I guess ;-)

Still, it has been fun, and rewarding. I don't feel like building these things is a waste of time, seriously.

> There is a ton of practical stuff written in this general area if you search for "mind mapping" or "zettelkasten" (links below).

I think sometimes we can overweight the impact of tools and systems for retaining knowledge. These tools can be useful (I'm working on my own home grown versions of them) and I am getting better with the systems as I get more practice. But, still, this is a race you can never win. As you digest more information, you consume more.

Eventually you've got to get out there and be a maker.

I've been collecting nerdy tech information on and off for 30 years. I say "on and off" because it seems to come in waves. It happens between spans of time when I'm building something important or profitable (not necessarily related).

Examples:

In 2004 I built my own web crawler and RSS feed reader in PHP in an attempt to build my way out of the information problem. I learned that tools do not help with this problem, but it did lead to a good software development job where I was able to put what I learned to use.

In 2006 - 2007 I went down a deep rabbit hole with the possibility of server side JavaScript. That led to participating in the development of the Node.js runtime, CommonJS and Promise specifications, and a career doing some pretty cool stuff with JavaScript.

In 2014 - 2016 I went down a rabbit hole on video streaming which led me through a startup (which failed) and then a job at a major consumer streaming platform (which has been wildly successful). I got to build some state of the art technology because I had remembered and acted on some of that information I was hoarding.

Now I feel like I've missed out on information hoarding while I've been building cool stuff in my dream job. I don't regret my time away from the information hurricane, but I am having fun getting back into it to see what comes up next (it is NOT AI or Web3 ;-) )

For everything, there is a season.

> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).

Totally. It takes some experience and maturity to be confident enough to resist the big business “best” practices. That, or a very intuitive entrepreneur

In most large businesses the most significant work is done by 20% or less of the workforce (I work for a fortune 100 company).

Too often the team size is a proxy for how successful an entrepreneur is. Although I’m not a fan of the solo entrepreneur/ build in public fad, there is a lot of merit to starting with one or two and only adding great people to the team when needed.

And I think entrepreneurs overweight their indicators for when more people are needed to continue scaling. A business can usually continue scaling by refining processes and building or buying better support and tooling software.

In my experience, while group discussion establishes the context for a problem, breakthrough solutions usually come when thinking alone.