HN user

streblo

1,366 karma

a lurker

Posts30
Comments276
View on HN
en.wikipedia.org 9mo ago

Frozen Conflict

streblo
4pts0
en.wikipedia.org 2y ago

17-Animal Inheritance Puzzle

streblo
2pts0
github.com 3y ago

Dumbpw: Generate passwords for sites with dumb password policies

streblo
1pts0
tasvideos.org 3y ago

Beating Super Mario Bros 3 in 19 frames (2021)

streblo
27pts12
geekingfrog.com 4y ago

Advent of code 2021 under 1 second

streblo
3pts0
jaredhecht.com 5y ago

Every company is a shit show

streblo
2pts0
blog.getdbt.com 5y ago

Dbt Labs (formerly Fishtown Analytics) raises $150m Series C

streblo
18pts0
alexdanco.com 6y ago

Ten Predictions for the 2020s

streblo
1pts0
www.cnet.com 6y ago

Uber sues Los Angeles to keep scooter location data private

streblo
3pts0
www.wsj.com 7y ago

Lawsuits Surge Over Websites’ Access for the Blind

streblo
11pts3
www.nytimes.com 11y ago

The Myth of High-Protein Diets

streblo
6pts0
matthew.mceachen.us 12y ago

How to make breaking changes and not break all the things

streblo
1pts1
github.com 12y ago

Toolkit for managing jQuery Deferred/Promise objects inspired by Twitter Futures

streblo
1pts0
www.usatoday.com 13y ago

IPO candidates are lining up

streblo
2pts0
stevenbenner.com 15y ago

Will the really real programmers please stand up?

streblo
9pts1
online.wsj.com 16y ago

The Dow Jones has crossed the 10000 mark

streblo
2pts0
www.youtube.com 16y ago

Ptolemy and Homer Simpson

streblo
3pts0
www.ideapaint.com 17y ago

Idea Paint

streblo
13pts7
www.animatedengines.com 17y ago

Animated Engines

streblo
44pts11
ece.olin.edu 17y ago

(Y Y) Works

streblo
13pts5
beej.us 17y ago

Beej's Guide to Network Programming

streblo
72pts22
www.ckwop.me.uk 17y ago

Meditation Driven Development

streblo
4pts1
www.cla.wayne.edu 17y ago

On writing well

streblo
40pts26
slowchop.com 17y ago

Create a WiFi heat map

streblo
16pts0
www.garykessler.net 17y ago

An Overview of Cryptography

streblo
2pts3
vortrack.net 18y ago

Productivity Magic Eye

streblo
2pts3
download.srv.cs.cmu.edu 18y ago

CMU team builds robotic snake

streblo
19pts5
news.ycombinator.com 18y ago

Ask YC: Best languages/tools to use for graphics development?

streblo
1pts1
tomayko.com 18y ago

Learning as you go

streblo
1pts0
www.codinghorror.com 18y ago

Gifts for Geeks

streblo
8pts1

Everyone in this thread suggesting a “data leak” or “compromise” is totally missing the fact that this is how Apollo works. This is often times overlooked by Apollo customers themselves. You have to opt out of customer data sharing (and in doing so lose out on the value of the product): https://knowledge.apollo.io/hc/en-us/articles/20727684184589...

Not commenting on whether this is good or ethical (or even totally legal), but this is what is happening behind the scenes.

Intel missed GPUs, missed ARM, missed ASICs, missed everything right under their nose for the last 15 years. This from Andy Grove's "Only the Paranoid Survive" company, a company that in it's own past pivoted from commoditized RAM production to become the one that won the CPU race, a company perfectly positioned to win the next big cycle as the dominant leader in the industry.

This is what happens when the MBAs and the bean counters take over. They cut the fat, then they slice right through the muscle and bone.

You're not wrong, this is the nth iteration of python tools that try to solve all the problems of what came before, including whatever the n-1th iteration introduced.

That said, in my personal experience with uv, it solves nearly all of the problems I've come across that were created by other python package management tools. It seems to have been very thoughtfully designed and I think there's a strong chance it'll become the standard, and that there won't need to be more standards after this. We'll see!

- Execs truly believe that culture and productivity are better in office (i.e., what they actually say in their announcements)

I think this is the reason, but its more nuanced than this. Management finds in-office employees easier to manage. They are more likely to attend meetings, participate in team communication, give status updates, etc. There's much less of a question around "is this person doing the work" if you can see them doing something that looks like work in the office. If you are blocked or are blocking someone, it's a tap on the shoulder instead of sending a message into the ether.

Management of remote employees is a huge information gathering exercise - very little of the above information is proactively surfaced to you, and instead you have to go looking for it. Frankly, it's just a lot more work for managers.

I realize the above may not be fair to employees, or that the perceptions of managers accurately resemble the truth - just stating what I think is going on.

Am I correct in understanding how firms like Jane Street work? They are a market maker - they run an exchange where buyers and sellers can transact. They can arbitrage these trades by connecting buyers and sellers where there is a price discrepancy. Something like that?

Citation needed. The paper specifically says:

Dietary risk factors (diet high in red meat, low in fruits, high in sodium and low in milk, etc), alcohol consumption and tobacco use are the main risk factors underlying early-onset cancers.

I moved to NYC from SF about 4 years ago. I’ve faced a lot of culture shock and I’m not sure I’d recommend it. I don’t think NYC has what it takes to become an innovation hub, the way SF/San Jose/Seattle are. There’s a pervasive small-c conservatism here, an attachment to tradition in so many ways, that makes it tough for interesting, out of the box, uncomfortable ideas to take root. There are tons of lifestyle pros to living here (entertainment, food, people, transportation), but if you’re deeply interested in technology, innovation, pushing boundaries, etc, then you might not find what you’re looking for here.

1. Set an aggressive (but achievable) revenue goal for your first year. If you're having trouble figuring out what that might be, I suggest 500k ARR, because that will put you on a path to raising a series A. You should be able to hit this goal with fewer than 5 people in your first year. You should take a very hard look at your business and what's going wrong if you don't hit that goal.

2. Don't raise too much money for your seed. Plain and simple, you just do not need much money to build and validate your business plan. Whatever your number is, consider whether you'd really be much worse off if you raised half as much.

3. Start by providing professional services before you have a product. This will help you generate some early revenue, it will validate that someone is willing to pay for your services, it'll help you understand the requirements for your product before it's built, and most importantly, it'll help you build early relationships with crucial clients. Streamline these professional services by automating them with your early product. Over time, replace the professional services entirely with your product.

The role of a CTO at a startup (at any size company, but at a startup especially) can be very amorphous and depends on the needs of the business. Sure, a lot of the time the CTO is involved in the technical day-to-day ongoings of the business, but that doesn't need to be the case. If your business is struggling to find product-market fit, or close customers, or figure out product strategy, then your CTO might be preoccupied with those things instead of with technical tasks/management.

I'm hugely disappointed with OpenTelemetry. In my experience, its an over-engineered mess and the out-of-the-box experience is super user hostile. What it purports to be is so far away from what it actually is. Otel markets itself as a universal tracing/metrics/logs format and set of plug and play libraries that has adapters for everything you need. It's actually a bunch of half/poorly implemented libraries with a ton of leaky internals, bad adapters, and actually not a lot of functionality.

In a past life I spent a lot of time developing for iOS, and the one incredibly sore spots in terms of documentation was the build process. Particularly, what are all the things I need to know to effectively build my app, and debug the process.

The Apple-provided documentation assumes you already know many of the ins and outs of C/C++ build arcana, and on top of that does a terrible job of explaining what parts XCode adds or subtracts to the process. I never came across a resource for this information that was even passable, and wound up getting most of my answers from IRC.

You should sign what your trusted legal representation recommends you sign. Many of these situations are more nuanced than an internet blogger looking for clicks is going to make them out to be.

And yes, if you're making a 6-7 figure decision (which you often are when you sign an employment agreement as a software engineer), you should at least have an employment attorney give it a look through.

One of my favorite examples recently is Frank Slootman (sales/operations/general management background) taking over as CEO for Snowflake, over Bob Muglia (developer/technical product background). The company's market cap is up >10x since Slootman took over.

When I run 1:1's with members of my team, it's generally:

* 10 minutes shooting the shit

* 5 minutes (or less) getting status updates

* 15 minutes (or remaining time) on 'how can I help you' type stuff

I like this agenda because:

* I work remotely and don't get as much time as I'd like relationship building. The purpose of the 1:1 can be, all else removed, a chance to have a friendly conversation where I get to know someone better. It's great for everyone's mental health (my own included), and it can also be great for understanding people's areas of strength, work-related interests, and career goals.

* I try to get as much as I can in terms of status updates from automated means. Project tracking, internal docs, git repo, build tool, etc, are all sources of information for me to know where things are. Occasionally I miss things and ask about them during 1:1, but generally I don't like to treat 1:1's as a chance to get status updates. This is a problem best solved using tools, and our time is precious, so if I'm spending >5m on this during a 1:1 it might be a sign of an issue.

* Understanding where I can help the person is where I like to spend the bulk of my time during a 1:1. This can be unstructured, and help can be in various forms. Unblocking something, helping make a decision, providing information, helping mediate or resolve a dispute, provide feedback on something being considered, etc. Sometimes there's nothing, but in a majority of my 1:1's there's something to talk about here.

I'm happy to end a 1:1 early if we run out of things in the above agenda to talk about. I'd say 50% of the time I end 1:1's around 5 minutes early.

Lastly, I'd say if you're not sure if you're using your 1:1 time productively, it's not a bad use of your 1:1 time to talk about it.

I think this is just a story we (fellow tech-oriented types) like to tell ourselves and repeat, not because it's true, but because it sounds good.

If you look, there are actually plenty of examples of professional management or 'bean counter' types taking over companies and running them more successfully than their former tech-oriented management. And also, plenty of examples of tech-oriented management ruining a good thing. But those kinds of stories don't get very good play on Hacker News.

I'm sorry but this is a really poorly informed opinion. You actually can have a shortage of labor - see e.g. countries like Japan and Russia, where the demographics are very skewed towards the geriatric, and you literally have more jobs than people to do them. Birth rates in these countries have been too low to keep populations stable, and as people retire you wind up with a labor shortage.

This is starting to happen all over the world as the global baby boomer generation is aging into retirement. It's started to happen in most of western Europe, China, Japan, Russia, even the US. It's absolutely not a wage issue, it's a demographic issue.

Most people don't really appreciate how close Twitter was to shutting down.

Twitter was on its death bed and was desperate for money.

I worked at Twitter at the same time, and while the company definitely was going through a rough patch at that time, it was absolutely not anywhere close to 'shutting down' or 'on its death bed' financially.