throwawaylala1's comments

This is a tough one.

I wouldn't worry that much about employability. If you're honest, hardworking, and love writing software then I don't see any issues there. I'm sure you've solved enough hard interesting problems that'll carry over to other industries. It's all about moving bits anyway. You'll even have a leg up if you have a better than average understanding of security.

You may be holding yourself back because it does take some time to ramp up in a new "vertical" (so to speak). Building new professional connections, etc. So like... maybe in an alternate universe you'd be working your way up the ladder at Apple or Google or whatever. That time invested does pay off and there's an opportunity cost there.

The tough one is the ethical question. Sometimes it's hard to tell if our disillusionment is internal or external. In other words, is it nagging you because you can see why the public is negative towards crypto or is it nagging you because you don't want to alienate yourself from the crowd?

If it helps, I've long held the strong belief that I should wake up in the morning guilt-free about my job. I need to feel excited about coming in to work and tackling the next big problem. I refuse to work for or with jerks. I refuse to work on products that aren't striving to make things better. I refuse to work on exploitative or manipulative products. I refuse to work for unfairly low pay. And all of that positive energy (great product, great people, great mission, good/great pay) make the dark/hard times easier to manage.

In the long run I feel like this philosophy has made me a happier and more successful engineer.

EDIT: Just to give you an idea of how I applied the above philosophy. I once quit a well paying job in the very first month because a senior engineer was an insanely venomous person and no one seemed interested in stopping them. I didn't make a big stink about it, just quietly moved on. The next job I found was amazing and I'm so glad that I did what I did. Yes it was scary.

I'd rather not say but it wasn't anything mind blowing. It was a B2B thing with a great UI in the early 2010s. You'd never have even heard of us. All of this predated the popularity of k8s. Docker wasn't really a thing. AWS was just growing and blowing everyone's minds.

Yea. We had a monorepo. The whole thing was one big webapp.

Even our background workers ran in the web app. Oh yea, that's right. I can feel the cringing just writing that! So like if we had an expensive background operation, our web app would start up a thread and do the work. Some might be wondering: "What if you needed to restart it? Like, I dunno... when deploying code?". Answer: we didn't, lol. Our deploy script would hold all new jobs and wait until existing ones finished before restarting. Some background process were extremely time consuming (eg: 10+ hours) and those we wrote in a way that they could just resume if killed.

It's actually amazing how productive you can be with a single monolithic web app on a beefy cloud instance.

I was also surprised how quickly we were able to scale out to a proper multi-service architecture after being bought. It only took us 6 months. The big company that bought us plans ahead years. It was no problem at all.

Now don't get me wrong. I'm not advocating for sloppy engineering here. Our team was some of the smartest people I've ever worked with. It wasn't uncommon for me (a medium-experienced engineer) to bring a proposal to our technical founder that would require like 1 month of work. That freakin' genius would reframe the problem and architecture such that we'd spend 2 days, still achieve the same goal, and take on minimal technical debt. I learned A LOT.

I know I'm rambling, but honestly I don't know if that kind of hustle is even a thing anymore. Are tech startups still scrappy? Are they focusing on the core problems/solutions they're trying to prove out instead of layers of architecture? Do such problems even exist anymore? Back in the mid-2000s it felt like that's how everyone did it.

If you're truly interested in being enlightened then do the work. It's not up to internet strangers to refute your painfully uninformed assertions in detail. That's what education and work experience are for. You simply can't cover it in a comment.

I wrote my comment to make it clear for anyone else who doesn't work in this area that what you said is utterly wrong. HN typically has well informed comments so people take it a little more seriously than other places. The thread is also old enough now that no one except you will probably read it.

I'll at least give you something so that you're not left holding nothing but a mean internet comment.

First: If you were to rank the hardest technical challenges in modern computing then UI architecture is easily in the top 5, if not #1. In that same list you have distributed (as in networks) computing. It's an incredibly difficult problem with an endless pit of depth. UI IS HARD. If your next question is "what makes UI hard?" then - good! - you're curious. Take some courses or something. Try building a great UI for non trivial use cases. Educate yourself by doing!

Second: A computer drawing "hundreds of of complex 3d objects 120 times a second" has absolutely nothing to do with complexity of UI. The challenges in UI are not strictly a matter of drawing dots on the screen! The two things are orthogonal! Game engine renderers are solving a very constrained problem whereas UI architecture is totally unconstrained.

Third: Game GUIs have a TINY fraction of the UI components you'd need to support a sophisticated modern day business application (think Salesforce). Someone else mentioned accessibility but that's just the tip of the iceberg. The sheer number of UI components in business applications dwarfs what you see in games. Not only that but the UI components I'm talking about need to be assembled in an uncountable number of ways. And they're constantly being updated/tweaked.

-

There are many people who have devoted their entire life to finding a general purpose way to build great UI. No one has cracked it yet and it's not because people are stupid or don't want to. It's HARD. But also a lot of fun if it's something you enjoy doing.

I've worked at 3 organizations that adopted k8s. This all happened over quite a long period so I saw what k8s adoption looked like at varying stages of k8s development.

k8s gets shit for one very simple reason: it forces teams to deal with issues that they're not necessarily ready to deal with just yet. I've seen it happen over and over and over.

Small startups are able to get away with not using auto-scaling, having bad secret management, not running minimally sized containers, etc, etc. Are they going to solve these problems eventually? Yes, if they grow and don't die. But until they grow they simply can't afford dedicating a lot of effort setting up Hashicorp Vault with proper secret rotation (just as an example).

One of the companies I worked at was a 10 person startup that was trying to find product market fit at a break-neck pace. We had customers, big ones. It was a non-trivial piece of software too. We ran the whole thing on a very beefy EC2 instance. The DB and the application were on the same server. Provisioning an application server was all done with a single bash script. One time we had to re-provision this server and we had take everything down for like 3 hours. We did at 3am so none of our customers got disrupted.

Every single ounce of engineering time was devoted to product development. We ended up getting bought and everyone (all 10 of us; founders were generous and awesome) made a crap ton of money. I can tell you with absolute certainty that every major feature we shipped contributed to that acquisition. Had we dedicated any effort at all to proper infra it just wouldn't have happened. The cost of our crappy duck taped infra was that one night we needed to reprovision everything and maybe another 20 total hours of wasted time across all engineers in the company.

That's why the first line in the blog post specifically cites early stage startups.

The miscommunication is in your mind.

Every software out there has defects. Bugs, performance issues, UX issues, etc. To assume that anyone in this thread actually means that submodules have no defects whatsoever... well... that's just creating a straw man to tear down because you're grumpy or something.

The issue appears to be with your understanding of what "bad" means in this context. When the OP (and commenter I was responding to) says "bad", they're referring to the overall experience of using git submodules. That specifically does not include the minor fixes/improvements you'd find in a changelog.

By your definition, all software is "bad" because all software has defects in varying degrees. That of course makes the entire conversation pointless and pedantic.

Git submodules work just fine when they're used properly. I've been using them for years without issue and so have many other commenters here. Are there things we (the users of git submodules) would like to see improved? Of course! But that doesn't violate the statement that there is "nothing bad" about submodules in the context of this discussion.

I really hope this helps you navigate conversations with a little more nuance. If not, that's okay too. Have a nice weekend.

> You were elaborating on the comment, weren't you? And that comment was quite vague too.

What was vague about that comment?

> The difference between "what are uses and misuses" and "what is good and bad" is not enormous.

This is incorrect. The definition of "bad" is something of low quality. Misusing a tool and then calling it low quality is dumb.

> Plus, there are things that are flat-out bad. It's a human-made program under constant development, after all.

What about git submodules is "flat-out bad"?

It's ironic that you're criticizing others' comments on being vague and providing non-answers while you've contributed nothing to the discussion. Maybe educate yourself on technical things and you won't need to waste your time having meta discussions on internet forums. Looks to me like you want to contribute but have nothing of value to say.

It was a response to a comment, not the OP.

There is nothing "bad" about submodules. They do what they were intended to do very well. They are often misused because people don't take the time to understand how things work (event at a conceptual level) before diving into it.

I've found submodules most useful when I'm tracking an external dependency that doesn't change often -and- I don't have a dependency management system to lean on.

For example, I have a repository of 100+ various bash utility scripts. One of the scripts depends on another repository with 500MB of data. I don't use it often so I don't need that large repo cloned alongside my bash scripts every time. In this case:

1) The dependency doesn't change often and I like being deliberate when using a new version of that dependency.

2) The dependency is optional and can simply be ignored when using Git's default clone behavior for my repo.

3) Since it's just a bunch of bash scripts, I don't have a package management system to lean on. I use these scripts on multiple *nix distributions.

Could I make it work without Git submodules? Yes. I would have added the dependency to .gitignore and wrote a script to `git clone` the dependency and set it to a specific revision. Submodules just makes that process a lot easier.

Exactly! Submodules are a tool within a toolkit. Learn the toolkit, learn the tool, and then decide whether or not it'll solve your problem.

> Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right.

You have no idea what you're talking about.

You're not wrong, but there is a large spectrum of success out there. It's not like you get only "one shot, one opportunity" (Eminem) or nothing. Yes there's also a spectrum of the work/reward ratio and sometimes it's skewed in a crappy way. For some people it's too easy and for some people it's too hard

Point is that reaching upper middle class and higher is totally feasible no matter your walk of life as long as you keep the hustle going. Success could only happen in one's late 30s though.

(There are of course overriding factors like having an abusive childhood or something like that. Systematic discrimination plays a big part too. But that's outside the scope of this particular thread)

The realization that...

Okay seriously this blew my mind.

The realization that the majority of the rules/regulations/laws/policies that we have in place are directly connected to the suffering of a human being.

Our society is reactionary. We enact new rules in response to negative outcomes. Any time we try to pre-empt a bad outcome, people claim conspiracy and/or believe that the problem is being over dramatized. It takes a negative real world event (often several) before we collectively agree that it's a problem and do something about it.

So then... all of humanity's progress is built upon the pain of other humans. That really sucks.

Do your thing I guess. The results will speak for themselves. Just know that even in the mid-2000s (when the market was red hot) there were all sorts of hurdles you'd have to go through to get a good gig. A lot of that involved doing work "for free".

A little hustle pays dividends long term. It's much worse in other industries.

lol yes

What did you write CRUD APIs in before Go?

What are you using it for?

> The real world is messy, as much as programmers want to think it's not.

You hit the nail on the head with the whole comment and that line in particular.

I'll add that one of the most effective ways to deal with some of the messiness/complexity is simply to avoid it. Doing that is easier said than done these days because complexity is often introduced through a dependency. Or perhaps the benefits of adopting some popular architecture (eg: containerization) is hiding the complexity within.

> It's because system design is a lot less theoretically clean

Yea this is a major problem. It's sort of a dark art.

Computer systems are imperfect. No one is claiming otherwise. What matters more is the probability of failure, rates of failure in the real world, P95 latencies, how complex it is to mitigate common real world failures, etc, etc, etc.

"Turtles all the way down" is an appeal to purity. It's exactly the kind of fallacious thinking that leads to bad system design.

If you're needing to fight the GC to prevent crashes or whatever then you have a system design issue not a tooling/language/ecosystem issue. There are exceptions to this but they're rare and not worth mentioning in a broad discussion like this.

Sadly very few people take interest in learning how to design systems properly.

Instead they find comfort in tools that allow them to over-engineer the problems away. Like falling into zealotry on things like FP, zero-overhead abstractions, "design patterns", containerization, manual memory management, etc, etc. These are all nice things when properly applied in context but they're not a substitute for making good system design decisions.

Good system design starts with understanding what computers are good at and what they suck at. That's a lot more difficult than it sounds because today's abstractions try to hide what computers suck at.

Example: Computers suck at networking. We have _a lot_ of complex layers to help make it feel somewhat reliable. But as a fundamental concept, it sucks. The day you network two computers together is the day you've opened yourself up to a world of hurt (think race conditions) - so, like, don't do it if you don't absolutely have to.

That first example is deceptive. In this line:

    for i := 0; i <= n; i++ {

The "<=" character just looks like a "<" character due to the typeface that the author chose. I'm going to assume that wasn't an accident because it perfectly masks the obvious bug in the for loop.

When I did a quick scan of that code it looked good to me. Then he claimed it should panic and I felt crazy. So I copy/pasted the code into an editor to see wtf was going on and sure enough it was "<=".