Good question - this was an excellent write up and AnythingLLM looks great. But I’m really curious about that too.
Regardless of the answer, OP you’ve done a hell of a lot of work and I hope you’re as proud as you should be. Congratulations on getting all the way to a Show HN.
I used to have the same issue then started running and changed my approach. Now:
1.) When you run, you’re only finished training when your body gives out, you die or give up the sport. In software, a product is never really finished; a version is. Therefore if I forget something or mess something up, I already know what tasks to work on for the next version. Forgetting something is bad but it makes planning easier. If finality is scary, turn it into a yield sign.
2.) If you want to run well at a distance, you have to specialize in that distance. If you train for Leadville and the 100m dash simultaneously, you won’t perform as well at either. In software, I work on one version of one product at a time. If I have to choose which one to work on when I sit down, I have already failed.
3.) I’m a human so for me, running is all about pace. Anyone can complete any race if they find and keep their pace. Software is the same. So find your pace and learn how to keep it. When I’m trying to find my pace for a race, I run that pace six days a week regardless of my distance - on shorter days, I’ll add in gliders at the end so I get the workout. With software, I have to keep the same kind of consistency or it takes me too long to get back where I was to ever finish anything.
4.) If you want to run fast so you can see the stars backs for a few moments, you have to treat every single training session just like the race. If you want to run fast enough to be one of the stars, it has to be your whole life. With software, everything even silly side projects gets the same name - product - and I follow the same methods. Practice is always good but deliberate, competitive practice is better.
Keep in mind that they’re studying unemployment whereas your anecdote is about retirement. The article argues that unemployment leads to a loss of control which leads to certain significant attitude changes.
It would be quite irregular for someone who received a career ending windfall in their mid-30s to feel a lack of control. There is a whole other can of angry cobras for them.
First off, this is creative and you did a great job of writing it up and explaining the benefits to your approach. And I think it is a good idea in extremely early stages of a software product because as you mention, it’s a quick way to get something up and running.
Unfortunately, the longer into the project you are, the more brittle that connection becomes. You’re tightly coupling a process to the state of the database at time of build. When you do that, you create a situation where your customers can kill your code.
So fundamentally, when you integrate directly, you create a situation where your customers’ engineers control how reliable your software can be. They likely won’t fess up when they break your tool so the problems will come back to you.
I know that sounds a lot like typing ‘npm install’ or ‘building an API’ but in this case, you’re handing the keys over to your customers. At best, it will cause reliability problems. At worst, it will add friction to a sales process. As companies scale and sales gains power, that can become a career issue for you. As a rule, it’s better to have difficult technical decisions when you’re employed than difficult financial decisions when you’re not.
So good writing and excellent analysis. But if you choose to go down that path, at some point in the future, I feel like that integration will become someone’s headache.
If you have to do it, it would be worth documenting that the customer in this case won’t provide proper access through an API. That’s a good reason to do something like this because that’s quite unreasonable of the customer. If they’re unwilling to provide API access, I feel like they’re just as unlikely to provide a read replica so aside from the integration’s brittleness, your queries have to be rock solid or you could slow down prod.
It’s all risky and you have a big decision to make. Good luck and have fun.
The intelligence agencies public vs private statements validate the claims of few isolated directed energy incidents then exacerbated through asocial psychosomatic social incentives until it matured into a mass psychogenic illness.
“And those who were seen dancing were thought to be insane by those who could not hear the music.”
― Friedrich Nietzsche
Take those low teen megabits and scale it through $x users in $y locations streaming $z content items. Consider that 15% of those $x users will take to the internet to complain about problems. Also consider that once you’re a big enough name, mainstream media will cover those complaints on slow news days. Finally consider that a large portion of budget goes into constantly maximizing x, y and z.
Thats where the engineering problem goes from trivial to extremely complicated. Lots and lots of people demanding a similar quality of service across a wide pool of content on a wide pool of devices.
And that doesn’t even fully cover last mile issues.
I like this comment because I think it does a good job of demonstrating four kinds of important people.
You have people who are most important to a:
- a project.
- a problem.
- the organization.
And I think we can divide organization into internal and external. When you divide like that, you’ll usually end up with four very different lists with some overlap at an upper management level.
None of the four areas are more important than others. If your software problem has a month long outage, that’s a huge problem. But that’s different from if you only have two months of runway left or if nobody has cleaned your office in a month. And since the problems are different, the people involved should be different too. Then you’ll end up with a lot of different hierarchies of most important people depending on what lens you’re looking through.
> Nine books. 3939 pages of writings (1,283,267 words). 499 hours of podcasts and 1369 hours of livestreams. 14 software product releases (with our great team). Oh, and a bunch of big—and beautiful—ideas and results.
That’s from the first paragraph - key nouns like “books”, “podcasts” and the like link to backup for the numbers.
This is amazing productivity - a book is a serious amount of work. Nine in five years though? Thats something else entirely.
I suspect he’s optimizing everything he does to be immediately suitable for publication. He’s not so much publishing the results of his research as he is publishing the process of it. I also suspect that he is driven by a deep-seated need to prove his worth to the world, a need that he has to continuously satisfy (but is never really satisfied), that motivates this level and method of activity.
I enjoyed the article and it reminded me of many experiences in my career. However, this sentence bothers me:
“I felt like by 40 I needed to move on from engineering because if I didn’t, I’d be like the few older workers I’d dealt with in my career. I felt like they moved too slow, were stuck in their ways, and unable to change - even when faced with evidence to the contrary.”
I’m in my forties and none of those things are true about me. Nor are they true about any of the other older developers I know. There isn’t this magic switch that goes off when we turn forty.
When I extrapolate from there, it makes me genuinely wonder how many of the writer’s problems stem from the position versus how many stem from a serious lack of empathy and the communication difficulties that creates.
The best management advice that I ever received was to always consider if a management problem is actually the sign of a personal problem. If it is, it’s my job to manage to fix that before I make my workplace more toxic.
For what it’s worth, I am a relatively young engineer who has recently been working very closely with other engineers over the age of 55 on a daily basis. It has been one of the more enriching periods in my career so far. I often wonder if the ageism that I see so often referred to on Hackernews is more projection than reality because I consistently find it pleasant to work with individuals who have a very large body of experience to draw from. Ageism in general baffles me as one could very well ask the question: “would you rather have a carpenter with 2 years of experience working on your house, or one with 30 years of experience?” The answer seems obvious to me, and the question could easily be applied to software engineering.
I don't feel that way either. But the 40+ year old devs when I was a fresh faced kid where from a whole different world. One guy wouldn't let go of Novell running on DOS. There are hard paradigm switches sometimes in tech, but many fewer today than back then. Every big switch loses some people that decide, "nope don't like it" and don't keep up.
I really, really think that most ageism in tech is driven by similar memories of the old crowd when we were coming up. I mean, I fought for years (years!) to get Linux accepted by the older devs and had to sneak Postgres past the Oracle greybeards. Yet I am not that person blocking progress now, nor do I see the same with my peers. If a new tech has merit, we learn it. We grew up with tech and are plenty used to making those switches.
If anything, I'm way better at handling change than when I was younger and headstrong. And 25 years in industry has given me lots of practice.
Having decades of experience gives me a certain degree of skepticism about promises that some shiny new widget will solve all my problems. From the outside, this might look like I'm stuck in my ways.
Regardless of the answer, OP you’ve done a hell of a lot of work and I hope you’re as proud as you should be. Congratulations on getting all the way to a Show HN.
reply