janee

Personally I find it helps with immersion for content of that era.

E.g. the non-digital aesthetics of Tarintino films contribute a lot to their style in my opinion.

Plastering fake film grain ontop of something is not really my ideal, but going full film is also probably not something people can really afford in terms of time and budget...unless you're someone like Tarintino who's already at the top

If anything it's rather the start of programming in my opinion, or rather the start of a new era.

We build endless higher level abstractions ontop of each other in programming, this is just another one.

I'm not bullish on AI actually understanding something in the near future and it'll rather continue to be something more akin to mimickery, albeit amazingly expressive and accurate.

I think this is rather going to become an amazing tool to help reduce repeating already solved problems. But humans would still be needed to plumb it together and adjust it to meet some final need.

If the AI can do the whole thing then whatever you're trying to create probably already exists and there's unlikely to be a need for it in my opinion.

In a hypothetical total universe timeline of something like 100 trillion years, say till the degenerate era...we're not really very far in right.

If we were near the end and had the same paradox I'd say you're probably right in that the answer is there is no life.

But we're really really early, so either we're a total fluke and the first or there's another reason.

Basically what I'm saying is if you're right and the probabilities are so low then I'd think we should either not exist or the timelines I've sketched are very very off

Article aside, the interface shown top left in the control room pic looks quite polished.

Couldn't make out what the program is called...was expecting a more win xp looking UI haha

Maximizing earnings (regardless ethical or not) just for the sake of redistribution based on an individuals choice seems dangerous to me.

It feels like someone optimizing for "power"

This is anecdotal, so take it with a shovel of salt. I was in a very similar position. I decided to quit my job before having another.

My main reason was I wanted to find something that will keep me happy for a long time. I felt it was less likely for me to find that while doing my current job. I had savings to keep me afloat, but planned to find a new job asap.

Long story short, it paid off. I think having full days to find it helped me a lot. I ended up joining a startup as the first dev and that would've only happened if I had the time to fly up to the founder and spend a few days with him understanding the business and more importantly the person I would have to work with.

It sounds to me you've already written off your current place. I would say commit to finding a new place and think hard about what you want then articulate it well to others.

Best of luck and stay positive.

Would you use the same argument for groups that justify racism, violence or even murder?

No because they are obviously not justifyable.

Yes, I agree at some point each person basically draws their own line in the sand when it comes to wrong or right.

But I think most people (not just in the west) have agreed in the last few decades to draw their line to exclude making homosexuality illegal.

Are you saying it's justified because of religion and circumstance?

>farming is brutal hard work but it also does not require a high degree of thinking

I disagree strongly. Most people I encounter in the agricultural industry are quite creative lateral thinkers.

But yeah I guess they wouldn't think of higher lvl thought such as using JSON because it "helps" with corruption...good luck with your data

As a lazy non-ML simpleton, is there a simple explanation for it's usage?

Would tabular classification usually refer to say, extraction of tabular data in a picture to text?

I tried googling and looking through the site but it wasn't obvious to me what this actually does.

Yes! I'd say avoid:.

- industries that have serious consequences for errors, e.g. finance, health.

- high volume client facing systems, e.g. high tps b2c (think large e-commerce).

- companies not yet in a mature phase, e.g. 10 years or older.

Start there in terms of simple rules of thumb to filter out potential jobs. Then when doing interviews dig further. Lastly don't take leadership positions.

In the end of the day it's definitely possible to find something fulfilling but not all consuming, just take your time to find a place...I'm sure it's out there

I found having big doc store tables in Postgres became harder to manage as time went by from a people perspective.

E.g. around the 300GB mark I had to constantly remind myself and others to be careful of it because it might have normal relational columns you think are fine to query, but it also has a fat json payload on each row and if you're careless the query planner would basically do a table scan for things you wouldn't expect.

This isn't so much a problem with json in an rdbms but more the false sense of query performance on non-json columns in the same table...after moving it to mongo never had the same problems because people knew not to query it in an unsupported manner.

Haha snap! Will def check out end of eternity. Happy reading :)

Haha sounds like me. I used to read as a teenager but stopped, thinking it a waste of time.

Only recently rediscovered my love for sci-fi after randomly picking up Isaac Asimov's foundation series on a whim while waiting for a flight at a book store.

Not saying it's the best thing ever or necessarily what I'd recommend. But maybe try and think what genere would be interesting to them and then pick one from someone's top x list.

I plan on doing that now using this list https://youtu.be/pP0XnfC1jVM and am very keen to build a bookshelf now haha

Wish there was a nice HN coffee table book documenting historic trends on here... from first post to current print date. Maybe just a bunch of illustrations of key words and a small foot note accompanying each

Bare metal I'd think is the first choice for a large rdbms where you have skilled dedicated personnel that can manage it.

If not rather use a specialist service like RDS for anything with serious uptime/throughput requirements.

k8s doesn't really make sense to me unless it's for spinning up lots of instances, like for test or dev envs or like in the article where they host DBs for people.

I think it's this one https://news.ycombinator.com/item?id=21202600

The nuclear command badges are also pretty good https://news.ycombinator.com/item?id=21214730

I suppose where my assumption could be wrong is that consumer vs gov spending sort of cancel each other out, i.e. fluxuations in the two are quickly negated because they take place in the same overall "market" and eventually anyway end ups in non-gov hands because there's a lot more of us in the market

Not sure if I'm explaining myself well

Not really. My intuition would be less tax just means different kinds of things purchased, not really a change in the total amount available in the pool... I'm not well learned about this stuff, but I don't see it being intuitive at all

I.e. tax money I would think eventually circulates back into the same pool, same pool non-gov entities trade in.

My intuition tells me the total pool size available at any given moment shouldn't be drastically different and wouldn't be correlated to tax amounts in an obvious way.

My guess would be something like:

- startups, small teams, no devops.

- horizontally scalable monoliths.

- no complex infra needs.

Haven't used fly.io but strongly considering migrating over from Heroku and above is roughly what I would say is a good fit for Heroku so hopefully it's the same on fly.io

Over the years I've actually found duck typed code bases to end up, for lack of a better word, less of a mess than those based on typed languages.

I feel like readable dynamically typed code is more easily "trained" onto younglings than typed equivalent.

I understand no typings allow for much much worse code bases, but my experience has been the opposite.

Good strategy. I would suggest not hooking it up to prod DB at the start. Rather script out something to restore prod DB backups nightly to a staging env. That way you can hookup non prod instances to it and keep testing as the other engineers continue with what they do until you can do a flip over as suggested. Key here is always having a somewhat up to date DB that matches prod but isn't prod so you don't step on toes and have time to figure this out.

Note that going from no source control to first CD instance in prod is going to take time...so assume you need a roll out strat that won't block the other enigneers.

Considering what sounds like reluctance for change the switch to source control is also going to be hard. You might want to consider scripting something that takes the prod code and dumps it into SC automatically, until you have prod CD going...after that the engineers switch over to your garden variety commit based reviews and manual trigger prod deploy.

Good luck! It sounds like a interesting problem

There's a lot you can learn by yourself in this field as you've probably realized.

But I find the best learnings for me have come from others. Mostly through observing their work and them observing mine. I think finding and surrounding yourself with people you admire is best.

Remember code is just a tool to achieve some end goal and it shouldn't be the goal itself imo.

I'd say start with industry sector or company size. Go directly to the company rather than a recruiter, a good ol email showing genuine interest goes a long way.

E.g. be the first dev hire, or look for IT related work in Antarctica...heck go all in and become a co-founder with someone.

I think there's lots of interesting work out there, it's just often reverse correlated to your long term wellbeing haha

My guess has always been somewhere near the last apartheid generation passing away you'll see a change in ruling party...so somewhere around 2070.

Can happen earlier, I just hope when it happens it goes smoothly

As with most things depends on the code base, but if documentation in whatever form is available, I'd start there rather than just jumping into code.

I'd start from the highest level abstraction of the code and work downwards until I reach a domain I'm either interested in or asked to work on and specialize on that vertical for a while (this can be anything from a few weeks to say 6 months). I then repeat the process on other verticals if needed/wanted.

So going from highest level of abstraction down to actual code:

1. read docs or converse with others around what the value proposition/s are of the product/service/app.

2. Understand the main use-cases or if not obvious, read product brochures or w/e you have in terms of "sales" material for end-users.

3. Try to map the main use-cases back to high-level architecture diagrams (if available).

4. After doing above steps if there are multiple domains I would pick one based on either personal interest or assigned work.

5. When starting with a business domain (meaning some high level grouping of code based on their business function), I tend to focus first on the design of the persistence layers as its usually less dense and less sprawling than other parts of a code base and can give you some idea of state management.

6. From here I generally start up the service/s or apps related to he domain I'm studying and try to play around with it, trying to tie previous steps together in my mind with what I'm observing with my interactions.

7. At this point I would generally have documented my findings (whatever means / form it is done) and ask for a session with someone that's familiar with this domain and ask their opinion of my documentation, making corrections where needed.

7. After this it's generally best in my opinion to just jump into work.

8. Personally I find doing support work fixing bugs for about 6 months gives you a very good lay of the land and people.

Jumping straight into feature work is not optimal in my experience as it's less likely to provide as wide an array of exposure as support.

This obviously only fits certain scenarios, but for your garden variety product/s this is how I'd go about understanding the code base.

Oh, commit history is also a very very rich source of info if there's an established culture of good commit messages.

> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).

My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc.

When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it.

I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket.

I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.

I have a similar game interest. Something based on internet sourced data, e.g. gpt-3 based npc dialogs, trained off current news or something else that's never ending... something like kenshi with the complex mechanics of dwarf fortress, combined with NPCs that can very realistically mimic conversations

It would be an open world, but not pvp...maybe you support co-op but I think the novelty would lie in single player combo'd with a very dynamic cause and affect world

that's pretty rad...both the song and vid :) Didn't think I'd find some new music to listen on the drive back home from HN, thanks haha

I agree with "war rooms" not being as effective...but whiteboards, standups and deep dives personally can be helpful.

I think the key thing for me is that I never force people to sit in on these.

When an employee starts a large piece of work they don't understand that I feel have some knowledge on. I ask if they would like to whiteboard a solution with me...or deep dive something in the code, or do daily standups just to talk about w/e is on their mind

Doing these remotely is totally fine, but I do feel these activities...or atleast whiteboarding and deep diving is nicer in person for me

Haha given the sea aspect of this, your post makes me think of BioShock