yashap · HackerTrans

3 वर्ष पहलेdiscuss

I don’t think middle management are the ONLY cause, but I do agree that once you start getting layers of management, managers “shielding their teams” from the rest of the company, cross-team dependencies that require lots of planning, and execs/upper-management that are very disconnected from the details of the business and product, you’re basically doomed to mediocrity-at-best.

yashap

3 वर्ष पहलेdiscuss

I haven't worked personally at these places, so just going on what I've heard:

- Netflix is a poster child for this, I've heard their "culture deck" isn't hot air, but is really how they operate. Combo of high autonomy and high responsibility, letting ppl go who don't pass the "keeper test" ("would you fight to keep this person if they told you they were leaving the company" - if not let them go), very open and candid communication, and generally a smart and driven group doing great work

- I don't know that Apple is still like this, but for a long time, as a massive company, it seems they did keep going a really high performing group, that were passionate about their work and hustling hard to build great things. Although could be pretty brutal in terms of long hours and lack of work/life balance

- Have heard SpaceX is similar to how Apple used to be

yashap

3 वर्ष पहलेdiscuss

I honestly think it’s possible to have large/mature companies that are still innovative, fast moving, transparent/candid internally, user focused, and low on internal bureaucracy. It’s just really, really, really hard.

You need to constantly be eliminating red tape and causes of slowdowns, because they’ll keep appearing. For tech companies this means spending a lot of time eliminating tech debt, slow/unreliable workflows, toil work, etc. It also means reducing cross-team dependencies, keeping decision making units small and independent.

You need a very performance oriented culture, where you only keep strong performers and fire miss-hires (or ppl who start strong but later start coasting). This is maybe the hardest part, as firing people is very tough and can have real negative consequences on the person being let go, but an accumulation of ppl who are just sort of coasting is one of the biggest reasons companies slide into mediocrity over time.

I think very, very few companies pull this off in practice, but I don’t think it’s impossible to pull off, just EXTREMELY hard.

yashap

3 वर्ष पहलेdiscuss

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like:

- Slow DB queries

- Lack of concurrency/parallelism

- Lack of caching/memoization for some expensive thing that could be cached

- Excessive serialization/deserialization (things like ORMs that create massive in memory objects)

- GC tuning/not enough memory

- Programmer doing something dumb, like using an array when they should be using a set (and then doing a huge number of membership checks)

With that being said, I have worked on the odd performance optimization where we had to get quite low level. For example, when working on vehicle routing problems, they’re super computationally heavy, need to be optimized like crazy and the hot spots can indeed involve pretty low level optimizations. But it’s been rare in the work I’ve done.

This article is probably meaningful for people who work on databases, games, OSes, etc., but for most devs/apps these tips will yield zero noticeable performance improvements. Just write code in a way you find clean/maintainable/readable, and when you have perf issues, profile them and ship the appropriate fix.

yashap

4 वर्ष पहलेdiscuss

The blog post in general was good/informative, but I gotta say, this quote does reduce my confidence in Fly quite a lot:

> To get the merit badge, we also had to document an approval process that ensured changes that hit production were reviewed by another developer.

> This isn’t something we were doing prior to SOC2. We have components that are effectively teams-of-one; getting reviews prior to merging changes for those components would be a drag. But our auditors cared a lot about unsupervised PRs hitting production.

> We asked peers who had done their own SOC2 and stole their answer: post-facto reviews. We do regular reviews on large components, like the Rust fly-proxy that powers our Anycast network and the Go flyd that drives Fly machines. But smaller projects like our private DNS server, and out-of-process changes like urgent bug fixes, can get merged unreviewed (by a subset of authorized developers). We run a Github bot that flags these PRs automatically and hold a weekly meeting where we review the PRs.

Letting code go straight to prod without a review is just IMO a really bad practice. It sounds like they've improved significantly here, but still have plenty of gaps where people can ship to prod with no code review until it's been running in prod for up to a week. This isn't just about stopping bad actors, it's 99% about preventing all sorts of bugs/mistakes/bad ideas from hitting prod. Obviously automated tests are the main line of defence there, but code reviews are very important too. I'm kind of shocked that they want to skip out on this. I personally wouldn't want to rely on a core piece of infrastructure from a team practicing this level of cowboy coding.

yashap

5 वर्ष पहलेdiscuss

Looking at the “Who’s Al” page of the blog:

> Each string of the violin possesses the power of coherent control. Call me a business violinist. Hi, I’m Al. In the business world, there’s talent, there’s hard work, and there’s the synchronization of these two “strings”.

> I’m the merger of an investment consultant, a tech specialist, and a fintech enthusiast.

> …

> I specialize in investments related to Blockchain, Cryptocurrency, Fintech, Artificial Intelligence, among other tech ventures.

Thick BS language, and operating in a space that is chock full of fraud and criminal activity, I think you’re right to be suspicious. Clearly the client was a fraudster, using a stolen credit card, and re: the consultant being a fraudster, the chance of someone describing themselves as a “blockchain cryptocurrency investment consultant” being involved in fraud seems significant to me.

yashap

5 वर्ष पहलेdiscuss

As another commenter noted, there’s no Rust code currently in the Linux kernel. There may be some soon, but not much - it’ll be a dominantly C codebase for a very, very long time, maybe forever.

As for seL4, doesn’t that just support my point that highly secure software can be written in any language, even C? seL4 is primarily implemented in C. There “executable spec” is written in Haskell, but the actual kernel that people use is written primarily in C and a little Assembly.

yashap

5 वर्ष पहलेdiscuss

Would you refuse to use Postgres, the Linux kernel or SQLite because they’re all written in C?

Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.

yashap

5 वर्ष पहलेdiscuss

Yeah, I agree with your point that “if you publish content to the internet, expect it to be used in ways you don’t intend, or even permit.” Just pointing out that a lot of the concerns are not “GitHub is stealing my code for use in Copilot,” but “using GitHub Copilot in my proprietary software is a massive risk/liability.”

yashap

5 वर्ष पहलेdiscuss

A bigger concern for many is that if you USE copilot, you’ll unintentionally copy code with licences that your company really, REALLY does not want to copy. For example, here’s copilot copying some very famous GPL code: https://twitter.com/mitsuhiko/status/1410886329924194309?s=2...

And basically every software company avoids GPL like the plague, due to its strong copyleft conditions.

yashap

6 वर्ष पहलेdiscuss

As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well.

However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cross-platform mobile, or explicitly web, iOS and Android), and you want to power them all with the same backend. RESTful APIs serving up JSON works for all 3, as does GraphQL (not a fan, but many are). This however is totally web-specific - you’ll end up building REST APIs and mobile apps anyways, so the productivity gains end up way smaller, possibly even net negative. Mobile is a big part of why SPAs have dominated - you use the same backend and overall approach/architecture for web and mobile.

I’d strongly consider this for a web-only product, but that’s becoming more and more rare.

yashap

6 वर्ष पहलेdiscuss

Agreed, they’re definitely a “stand on the strength of our products” company. IntelliJ IDEA is not just the best IDE I’ve ever used, it’s one of the best software products I’ve used, period.

Also, they’ve got a great open source license program! https://www.jetbrains.com/community/opensource/#support

yashap

8 वर्ष पहलेdiscuss

Uh what? That’s maybe true with extremely junior devs, or in Windows shops, but most devs I know use the command line very heavily.

yashap

8 वर्ष पहलेdiscuss

IMO json+REST works just as well for contract first workflows. Just write up the contract in an IDL, have both sides agree on it up front, then use codegen tools to generate client SDK(s) for your client language(s) of choice. Same workflow as as with gRPC, though you’re probably less likely to get generated server stubs (which you don’t really need with json+REST anyways).

yashap

8 वर्ष पहलेdiscuss

Have used both, and don’t like either. I actually DO like very statically typed schemas, but you can easily do this with json over REST, and using IDLs to generate SDKs.

For gRPC vs. REST, I just don’t see the benefits. Performance wins of gRPC are extremely minimal for most backends, ”push based” workflows can easily be handled with webhooks (or message queues), so why am I throwing out extremely mature technology (and tooling/middleware!) that every dev is very familiar with?

For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. Why force people to learn another complex technology for that? “Returning smaller payloads” makes minimal impact in practice, and GraphQL requests are MASSIVE compared to REST requests, so you often end up with a performance loss, not gain. Also, GraphQL requests are way harder to glance at in the browser, you can’t just look for GET /dog/123, you have to peek into all the request bodies. And again, all the great REST middleware stops working, because you’re doing RPC.

Basically I see them both as extra complexity with little payoff.

comments