turdprincess

I couldn’t imagine working on a large scale project without strong types.

What happens when you have to refactor a large elixir feature on a code base which many teams touch? In such cases you can’t test manually all code paths for runtime errors, so are you just relying (hoping for) perfect test coverage to catch any type related errors you may have caused?

My property taxes, maintenance costs and insurance all go up every year too, so ownership costs are also not fixed

It’s crazy to me that in todays remote first climate, many engineers still can’t effectively make diagrams without an actual whiteboard and marker. A great way to stand out as a senior contributor is to get the hang of using a virtual diagramming tool, both for design documents and live discussions.

Good move, but another thing this brand does is charge you a monthly subscription to unlock the full battery range on your bike. If you don’t pay, you lug around a dead weight extra battery you cannot access. Overall this brand is notoriously unfriendly to consumers.

Replacing the car completely is unrealistic. Replacing a second car - totally possible. The folks who are buying electric cars are often buying it as a second car anyways since they still need the ICE car for bigger trips. Those folks could probably get by with one ICE car and a couple of e-bikes, which would be cheaper, healthier and more fun.

Anecdotal, but my M1 MacBook Pro doesn’t have amazing battery life. The other day I went to a coffee shop with 60% charge and only made it about 2.5 hours doing iOS development.

I find it to be more nuanced. Your code has to work correctly in a bunch of scenarios. Some are very simple to see, others are nuanced corner scenarios.

A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios.

So, “this code works” is really a range, not a binary condition.

With your Meta experience I am curious - would the people you had to talk to been in the office near you anyways, even if everyone was in office? It seems like with a huge global company the people who would be hard to get context from (so not the people you might have a video standup with daily or weekly) might be in a different office or building requiring a video call anyways

I think in-person collaboration helps, but with folks on the outside of your team. If you are on a small team or in a small startup, I don’t see a big impact of in person communication. You will be interacting with these same people so much that you will grow a close bond with them regardless. When I think about the small company projects I’ve done, it’s honestly hard to tell which were remote and which weren’t - the bonds formed and amount of teamwork was the same.

For large company settings it’s a different story - if I have to have tons of meetings with a pool of various 100 people for many hours a week, some of them occasionally, yes it would be super helpful to have all those in person to establish connections quicker. However, even with RTO there is little chance those people would be in the same office, so you would be stuck on video calls anyways.

There is probably a sweet spot of medium sized companies where there is a lot of people but they are still in the same floor where in office would be effective. But for google scale - not so much.

I got a few good freelancing clients off the “seeking freelancer” thread back when I was contracting. The last one ended up being $100 / hour for a long term gig lasting over a year, which was great money for me at the time.

My wording could have been better - I meant that it’s uncommon for engineers to know both iOS and Android at a deep level. Sharing code can let you share a lot of your logic, but you still need to understand the native host environment well, in fact maybe even deeper than normal since you are using unconventional approaches.

So you need engineers that have this deep iOS experience, deep Android experience, and deep C++/rust experience. If you are a solo dev with this skillset then maybe it’s a good choice. But in a team / big company setting such an unconventional stack will always be a drag chute on your velocity in all stages of the project

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to mention the extra wrapping layers your native code needs to smooth out the interactions between the shared and native layers.

For sure there are settings where it makes sense to take this approach, especially if code is shared across more than two platforms. But just for iOS and Android I wouldn’t necessarily say it’s a more efficient solution.

Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?

I think in this career it’s possible to optimize for 3 levers - WLB, money, and fun work. If you truly want to code a lot, a startup is the place, but you will earn less money and work more hours. Big tech offers big money and good WLB but often at the sacrifice of interesting work.

I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.

I think an important piece of having that “higher satisfaction” is having the other folks you work with in the office with you. I think ultimately we will end up with remote companies and in-person companies. Both approaches work great. But the in-between not so much.

> For one thing, the initWithDependency: method ignores its argument!

Yes good, callout, I edited the code to fix this mistake

> Does the class even need to declare -init?

You are basically making my point. Its totally normal engineer's reaction to look to erase this boilerplate by removing the dependency injection, or using a singleton. Overtime, those decisions make the codebase worse. In Swift, you simply don't have to make this tradeoff.

> if your main complaint is just the number of lines of code, that's not particularly interesting

Verbosity alone is a major problem - why would it be a good idea to use a language which takes more time to read and write to accomplish your goal? It's a disadvantage.

Another issue is a lack of expressiveness and a dumber type system. Stuff like union types and optionals all allow you to express your system in a more airtight way. The lack of these features leads to, you guessed it, more boilerplate in ObjC.

Ultimately, noone is arguing that you should rewrite your existing ObjC in Swift - if your code exists and works, leave it alone. But the article is arguing that Objective C is a "better" language for writing iOS apps, which doesn't make any sense for all the reasons above.

Curious, which part of that Objective C code doesn't make sense to you? What its doing is:

* Creating a header and implementation for each object

* Using a private category to keep a variable private

* Implementing multiple constructors because you can't have default variables.

Can you suggest a more concise way to accomplish any of the above?

It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class into the other's constructor, so I could do some unit testing.

Here is the Swift code:

    class Dependency1 {
    }

    class Object1 {
      private let dependency: Dependency1
      init(dependency: Dependency1 = Dependency1()) {
        self.dependency = dependency
      }
    }

And the Objective C equivalent:

    @interface Dependency1 : NSObject
    @end

    @implementation Dependency1
    @end

    @interface Object1 : NSObject
      - (instancetype)initWithDependency:(Dependency1 *)dependency;
      - (instancetype)init;
    @end

    @interface Object1()
      @property (nonatomic, strong, readonly) Dependency1 *dependency;
    @end

    @implementation Object1
      - (instancetype)initWithDependency:(Dependency1 *)dependency {
          self = [super init];

          if (self) {
            _dependency = dependecy;
         }

         return self;
        }

     - (instancetype)init
     {
       return [self initWithDependency:[[Dependency1 alloc] init]];
     }
    @end

Thats 9 lines of code in Swift and 31 lines of code in Objective C. If I have to type 3 times more code every time I want to break up big class into a few smaller ones, I am going to be much less likely to do it.

In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible.

And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn:

* What is an NSObject?

* How to create a private category on an class

* What does "alloc init" do, and why is it different than "new"?

* What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property?

* Why would `super init` return nil, and what does that mean?

For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set.

[edited] updated code for correctness

At least in the states, tipping is generally done as a percentage of the price.

I always tip $5 for a single meal and $10 for a meal for two. These delivery folks clearly don't pull in a lot of money, so if you are privileged enough to be able to afford takeout, you can also throw down a tip.

For sure part of it has to do with my fancy ultralight Rene Herse tires.

I have two bikes - one tubleess, one tubed.

On my tubed bike, other than 1 or 2 flats in the last 5 years, these tires have required 0 maintenance. Even after dusting the bike off from the winter, they pump right up and are ready to go.

My tubeless tires are a constant source of headache. They are constantly going flat, sometimes weekly, requiring more sealant, stuck valve cores, etc.

Overall, I'd say my tubeless tires require monthly maintenance, while my tubed tires have basically never required any thought at all. What am I missing here?

As long as they pay top dollar, many people would. For many, works is not a question of morals, principles, or company values. It's a question of collecting tokens into their bank account at the highest velocity possible. Meta is still one of the top payers in the market, so people will keep lining up to work there.

(Small time landlord here) homes are absolutely depreciating assets. On your taxes you can write off the whole value of your home over 30 years due to depreciation - the assumption is that your home will only last your that long and will essentially be “rebuilt” through all the maintenance expenses. Your home is just a pile of scrap wood and nails which rots and depreciated just like your car.

What does not depreciate however is that pesky patch of dirt under your home. That goes up and up in value because folks want to own a piece of this great blue ball and the value on that desire only goes up as population and standard of living increases.

My flow with ChatGPT lately is like this:

1. I get stumped and ask it “can I do thing X with technology Y?”

2. It always says “yes, here is how”

3. A majority of the time, it’s lying and you can’t actually do whatever I asked it.

It’s incredibly frustrating - it’s like it doesn’t know how to say “no”.

Granted, I am usually asking it pretty niche stuff about iOS development, but so far it’s proving to be a waste of time. I guess it does feel good to feel like you have a lead on some problem you’ve been beating your head against for hours, but then the harsh reality of actual reality comes quick.

Yes, I think FAANG grouping is too narrow. The true group is "big tech" - with the regular FAANGS, as well as Uber, Airbnb, Stripe, Pinterest, etc...

While each company has some unique qualities, my guess is that being an engineer in any of these places would be pretty similar and include:

* A lot of engineers and teams

* Lots of organizational / promo based manuevering and social engineering

* Problems at scale - some technology, but mainly "number of cooks in the kitchen"

* Work which might not be very interesting

* high compensation

My guess is that the OP's concerns would hold true at most of these big tech places that pay top dollar.

I think your options are:

* get a CS degree from a top tier program, preferably a PHD

* Pivot in from a normal software job. This is probably only possible if you have a bunch of C++ experience, and some top (FAANG) names on your resume.

You get excited for one reason and one reason only - the money. FAANG jobs pay between double and triple of normal software gigs. Some folks want to optimize for interesting work, or groundbreaking products or autonomy. Thats cool - you might not find that at a FAANG. Some folks optimize for the biggest paycheck. For that its basically two options - FAANG (and adjacent) or High Frequency Trading. To each their own!

I have bike commuted in the following places without near death: * New York City * San Francisco * Portland * Seattle * Raleigh Durham * Chattanooga TN * Salt Lake City

For sure there are some cities where biking is terrible, but I am not sure it’s a “majority”. It also takes some awareness to ride your bike safely in a city, but actually, doing anything in a city takes a bit more awareness and caution.

Is it possible that you could avoid death while cycling by improving your cycling skills a bit? You could join a group of (still alive) cyclists to learn the ropes.

Curious whats your plan if new cars become increasingly internet connected, kinda how smart TVs went? Will you keep driving early 2000s cars until they become "vintage"?