HN user

lojack

1,743 karma

Full stack developer. Ruby/Python/Elixir/random other things I'm interested in.

https://github.com/rclark72

[ my public key: https://keybase.io/iojack; my proof: https://keybase.io/iojack/sigs/TM6mY45JTnTwI5zGX2LT9nUibIwvZU8gAd5KitS6oHA ]

Posts6
Comments663
View on HN

This post is a <insert-startup-here> advertisement

same thing you said but in a different context... sir, this is a hackernews

Claude Opus 4.1 12 months ago

Lets see: We have GitHub, and GitHub Enterprise Server, and a GitHub API. Then there's the command line and a desktop version, and one that is just browser based I guess. Then you have different pricing plans, Free, Team, and Enterprise? How is Enterprise different than GitHub Enterprise Server? It's very easy to find evidence to confirm our bias.

Claude code is actually one of the most straightforward products I've used as far as onboarding goes. You download the tool, and follow the instructions. You can use one of the 3 plans, and everything else is automatic. You can figure out token usage and what models and versions to use and how to use MCP servers and all of that -- there's a lot of power -- but you don't need to do ANY of that to get started trying it out.

You're not being:

That critic who doesn't try the stuff he criticizes

You're being:

That critic who is trying to confirm their biases

Definitely not a prompt and pray type thing, though you can do that if you choose. It shows its work, in the newest version there's three modes (planning, executing, auto accepting edits). You can also hit Esc at any time to redirect as you see it going in the wrong direction.

In every place I’ve worked, outside of independent contracting, the sales person didn’t do the trench work.

Have you ever worked at a place where the sales people promised features that didn't exist? A bad sales person can ensure you're in the trenches doing work that is urgent but not important. A good sales person anticipates requirements, identifies when they're not currently available, and proactively works with the right people to get the important features prioritized strategically.

The sales people talk to the customers, so from a certain perspective they're the ones in the trenches and talking to customers while you're in the back office plugging away at a keyboard.

The first time I had the plug pulled on a public API a product I worked on used sucked pretty bad. At this point its happened to me so many times that its just another line item of business risks thats an inevitability. I've never worked at a company that failed to recover as a result. Then again, I've never worked at a company whose entire business hinged on one single API.

The likelihood of things breaking or behaving in unexpected ways are data points I think about when assessing risk irrespective of whether an API is public or not. In some industries even the public APIs are more risky than using the unofficial Venmo API likely is.

Anyone who's ever had to work on a system that had copious unit tests deep within will know the pain of not just changing code to fix a bug, but having to change a half-dozen tests because your function interfaces have now changed and a healthy selection of your tests refuse to run anymore.

In my experience this problem tends to be caused by heavily mocking things out more so than the unit tests themselves. Mocking things out can be a useful tool with its own set of downsides, but should not be treated as a requirement for unit tests. Tight coupling in your codebase can also cause this, but in that case I would say the unit tests are highlighting a problem and not themselves a problem.

Perhaps you're talking about some other aspect of unit tests? If that's the case then I'd love to hear more.

Interviewers tend to have one of two different mentalities...

Some are trying to see you fail. They're looking for a reason to say "no". They tend to not be of any help on a problem, will often try to find ways to trick you. They also tend to have an ego problem -- you need to prove to them that you're worthy of joining the team.

The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work. People that shut down when they get nervous tend to open up to these interviewers. They also tend to be the people that are more pleasant to work with.

Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.

For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.

is probably one request in a long queue of requests that team is dealing with

You've explained away the crux of the problem without even identifying it as a problem. Queues are an inappropriate construct for managing work. If something urgent & important takes weeks to even get looked at then there is a prioritization problem. If something that isn't urgent or important even gets worked on at all then there is a commitment problem. Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order. Similarly, the work OP is doing may be much less important than they think it is.

Now, I agree that it's important to understand how the system works, but IMO it's equally as important to understand how it can be improved. Long lead times is definitely not a good thing, and also not a foregone conclusion at big companies.

correlation != causation

OP was commenting on why there may not necessarily be a causation, and you commented on how the doctors tend to think there's a correlation. It just as well could be that schizophrenia tends to lead to increased marijuana consumption as people are self medicating. I'm no expert, so I don't have any strong beliefs around causation, but I do think both lines of thought (marijuana causing schizophrenia, or vice versa) seem pretty logical to me.

It's pretty widely believed that there is a correlation between the two, but the reason behind the link is where there's a lot of debate.

I don't even necessarily think its just leaving your baby alone with other people. Pre-covid with a <1 year old and a toddler we would have play dates all the time for a break. You stop being the source of entertainment and become a mediator, which is much less work. The baby then gets passed around to whoever has a free hand.

I suspect there has always been pressure to not leave your baby with someone else and go off and do your own thing. The difference is now people are physically more distant from everyone else (I blame the ease of transportation) so being around close friends and family is the exception and not the standard.

I've done the math on my local lotteries and I only buy tickets when the EV of the return is greater than the cost of a single ticket.

If you want to get really technical, you also need to consider the number of people playing. When the jackpot gets extra high more people tend to play, so the likelihood of having to split a jackpot (which happens all the time) becomes higher. Without doing the math I would guess EV of the return is rarely ever greater than the cost of a single ticket.

Good developers are the ones that create code that resists the slide from a 10x code-base to a 0.1x code-base.

10x is 100 times bigger than 0.1x FWIW.

but I argue that it is at least partly due to the prevailing code-base.

Its almost exclusively because of the prevailing code-base. We can't forget that the prevailing code base was built by developers of varying skills. You can have "100x" developers build it or you can have "0.1x" developers build it.

One of my least favorite people to work with is also a "high throughput" developer who is a prolific creator of software, but everything created by this person is an un-maintainable, un-documented, un-tested, brittle block of procedural copy-pasta that ends up in the critical business path. And yes, this developer "snapped" about a year ago and it has been a 3 person project ever since to scramble to fix this stuff.

Was this person the aforementioned "Rick" from this article?

for time-beating purposes, it is optimal to instantly guess as soon as you identify that a guess is necessary

Often that is the case, but sometimes you reach a point where you ultimately need to guess, but you can make an informed guess based on the number of mines remaining. Then the question becomes, is it worth guessing and potentially losing faster, or are you having a really good game and want to risk losing late in the game?

I think you misunderstand... Obsidian is precisely a personal wiki for me because thats exactly what I want. I don't even attempt to argue that I'm doing Zettelkasten in any way shape or form -- I even have the Zettelkasten features disabled.

and no one seems to be able to explain to me why it's not basically just a wiki

That's actually precisely what it is for me. It's just an easy to use, lightweight, wiki that uses markdown and has backlinks. Your pages are stored in regular old markdown files, so you can do whatever you want for syncing if that matters.

If I weren't using Obsidian I'd probably be using a lightweight note taking app like Bear, or maybe a personal Wiki. It just feels like a good mix of the two that works for me though.

I use Obsidian (which is inspired by Roam). I know some people may use the graphs, but I personally have that functionality disabled. The real important bit for me is the fact that I can have bi-directional linking. For me, graphs are a cool toy, something I can go "ohhh, neat" and then never use again.

We're using Heroku where I'm at and looking to move off of it for a number of reasons. Review apps are one of the great things about Heroku, but once your team is above a certain size its most definitely not free, or even cheap.

The biggest pain point I'd like to see solved (beyond just review apps) is the provisioning of good staging data. Ultimately we want data that looks like a subset of production data with PII scrubbed. Heroku doesn't give you an easy mechanism for getting this, and we had to sink a ton of time building this out for our specific use case.

I think this is super helpful, I definitely don't think all scores on the Joel test are equal. I would steer very clear of a company that had an 11 on the Joel test because they didn't use source control, but would happily work at a company with a score of 8 because they allowed some bugs, didn't have dedicated testers, no hallway usability testing, and had to take a few steps to build.

I've played as Turkey a number of times. There's a natural stalemate that occurs with the Black Sea. If either Turkey or Russia take it they can steamroll the other. If they both try to take it then they just waste their time. If they're able to trust each other and not try to get it, then there's a lot of potential for them to win, along with plenty of temptation for the other party to stab their counterpart.

Its actually a game that lends itself well to playing very slowly asynchronously (i.e. on the internet or mail). I've only ever played games where you have a full year every day. Those games take weeks to complete.

Yeah, there's a huge meta that goes along with diplomacy. I've heard numerous times that those that play competitively rarely ever backstab. They understand that there needs to be a certain level of trust in order to succeed.

More broadly, there are finders, minders, and grinders. Different companies need different compositions of those characteristics, but startups tend to lean towards finders (people that can sell) and grinders (the aforementioned "doers").

I don't think it's good for any individual to be an extreme with any trait. Thats how you end up with a sales team that sells the world with no regard for how it'll get done, or a developer who can crank out features with no ability to support those features, or product folk that spend hours every day with meetings full of people toiling over all the accessories that may one day need to fit inside your bike shed.