turdprincess

Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours.

The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.

Those people can give a reasonable estimate, in time not some strange point system.

Sometimes the estimate is wrong and that’s ok.

It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation

Virtual credit card numbers are a great way to combat this.

For example, the Wall Street journal pricing is pretty wild (8 dollars a month for the first 3 months then jumps to much higher) so I use a virtual card which expires right before the planned price hike.

For other services I like to either use a virtual card with a single transaction limit, or just buy the service and cancel right away which typically is equivalent to just paying for a month

Must be a shoe type thing - I’ve never had any smell with La Sportiva (solution, futura, Muira or katana)

In that setup, how do you write a test which acts against a mock version of your API client (a static function in your proposal?)

I got mine for health reasons (low back, must work lying down sometimes), and while for me it’s a really useful tool, I couldn’t see working in it full time. It’s just too bulky, leaves a dumb red mark on my face, has bugs where sometimes it doesn’t connect, and is pretty much always dead unless it’s actively plugged in (doesn’t idle well).

Some of those things can be improved but inherently strapping a computer to your face is just not a great experience.

I definetly get use out of mine - I’d say 5 hour a week is a sweet spot - and it’s cool working in novel places like a garden or by a river, but full time doesn’t seem feasible

Abstraction is a an abstract word, but as an example, I would consider the process of refactoring a big piece of code which mixed together api requests and view presentation into a 2 classes (a presenter, and an api client) as adding abstraction, especially if those new components are defined by interfaces.

And I’d rather work in a codebase where the owners are constantly doing such refactors than not.

As an opposite view point I work on a 10 year old legacy iOS app which has almost no abstractions and it’s a huge mess. Most classes are many thousands of lines long and mix every concern together.

We are fixing it up by refactoring - many through adding abstractions.

I’m sure code with bad abstractions can scale poorly, but I’m not clear how code without abstractions can scale at all.

Climbing works great in jeans if they are a bit stretchy. Especially good for knee bars - almost as good as a knee pad and 1100% more stylish

America is a land of inequality. There are many people (poor) which have bad healthcare, but for many others (the wealthy, stably employed), healthcare is excellent.

If you have a good job with a good PPO plan, this healthcare is just incredible. You are free to see any doctor you want, including specialists without any gatekeeping.

Want to see the best orthopedic surgeon in the world who just fixed Lebron James's knee? Make a call and get an appointment within a few weeks paying a 30 dollar fee. Want to see 10 more orthopedic surgeons to get 2nd, 3rd and 4th opinions? Same process.

Decide to have a surgery? Sure! Sign up to have that done in a few weeks, eventually paying $250 out of pocket for the whole experience, including overnight hospital stays and physical therapy.

Having spent some good time hanging out in facebook groups for my condition with international patients, its pretty much always evident that they dont have this kind of freedom in picking their doctor, getting a surgery quickly, and also often lack cutting edge and modern treatments that are offered in the states.

I totally understand that this system is very unfair, and there is whole subset of people that have no access to care, but it should be noted that if you are in the top 50% of society financially, and especially if you have a difficult health condition you manage there is no healthcare system better in the world to do that then the USA.

FAANG jobs absolutely hire engineers over zoom. It’s not just one interview, but the whole process is done remotely over video. It typically includes somewhere between 5 to 10 sessions covering coding, architecture and behavioral.

Source - work at a FANG which engineers exclusively via remote video call.

At least in the USA one major piece of the college application is a standardized test - a concept very similar to a Leetcode interview.

Thin boned and uncoordinated? Rock climbing is your sport! Go to a local gym and try it for a few months and you might find yourself getting really good really fast

Swift enums support union types as well, and are also very useful.

I recently left town for 1 month and got the post office to hold my mail. It was all delivered in bulk when I came back. Out of the huge bundle of 100 mail pieces, there was only 1 piece of mail that was not trash - a renewed car registration.

So for me, on average, 99% of mail goes right from USPS to the trash - in fact, I would probably pay a few dollars a month for a service which would automatically trash that 99% of mail for me.

That has me asking - what is the point of USPS these days? Is it just packages?

Actually coding is the domain of mid level and senior engineers. Staff engineers architect, design technical strategy, collaborate across teams. A proper staff engineer might only see code during review or a proof of concept.

That seems about as realistic as immediate dismissal from your job if you forget to unmute yourself on zoom.

Id be interested in a C++ for Swift developers version.

As a converse view point, in my experience, in terms of huge methods and huge files / classes, its rare to see developers who have the mindset of "in general, I prefer small files and classes, but in this case, it makes sense to have a huge function, so I make an exception."

What I do see every day is "oh yeah, this method / file is pretty big, lets add one more thing to it anyways, I dont have time to refactor", and things grow and grow out of control.

I think one basic, and yet rare ability of a professional software engineer, and the skill that should separate you from a hobby programmer, is writing your code in a way which can scale and grow. The strategy for this cannot just be "let me put everything in one file, class, method and lets just see what happens".

That can be an OK first draft approach, but there needs to be a second step. And ultimately, if you set the architectural pattern of "big hairball", everyone else will happily follow it since its not their fault the architecture is like that - they are just adding one more thing. That can be OK for a first draft, but you will have to go back and introduce architecture and modularity at some point, or watch the project collapse under the weight of its own mess.

Once you see enough of those failures, you can start sensing basic patterns for introducing modularity, boundaries and structure to a project, to its modules, and to its classes and methods. As you keep flexing that muscle, in my experience, the "this code is best written as a huge single method" approach basically never seems like a good idea anymore.

Being able to talk to the model has been awesome for my conversational Spanish. I’m holding conversations and getting live corrections on my grammar.

Swift allows you to program using “headers” - just have a protocol and an implementation, even in separate files if you want.

This is a good pattern for some cases, like the public members of a package. However, I love that I don’t need to do this for every class I write.

And if you do use this approach, at least swift will emit a compile error if your protocol and implementation signatures don’t match.

ObjC will happily compile if your header is missing an implementation and crash at runtime.

SwiftUI exists to solve exactly this problem - the ui is declarative and state driven.

However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken.

Programming in UIKit is like programming in JQuery, or maybe Backbone at best.

SwiftUI brings us to the modern age of react (but with less capabilities and more bugs)

IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue.

Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities.

I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.

I’m not sure I buy this - who is looking to max out their HELOC? Of course one good reason to do that is to buy another property, but of course, this again is a chicken or egg problem where no actual gain being made.

Curious - which individuals benefit from housing values rising? It seems like if you own a home, and it gets more expensive, you have more money on paper, but how do you benefit from that? If you sell your house and buy another, you wont make more money - your profit theoretically wouldn't change. Same with selling and renting if rents are going up as well.

Is it primarily then people who invest in real estate outside of their primary home?

At least in the mobile world, I find that this “no abstraction” approach is the default one, and it usually leads to huge objects which do everything from drawing views to making network requests to interacting with the file system. These kinds of classes are quite hard to work in, hard to test, and also keep snowballing to get bigger and bigger. Things usually end with unmaintainable code and a full rewrite.

I am not saying you need to create complex abstract hiarchies right off the bat. But usually, it’s pretty easy to tease out a couple significant abstractions that are very obvious, and break down your classes by a factor of two or three. Just getting such low hanging fruit will prevent you from ever having a 2000 line long method.

And for the folks who are saying that they make sure to not add abstractions too early - are you disciplined enough to go back and add them later? I feel like if you’re the kind of engineer that busts out 2000 line methods, you’re also not going to refactor it as this method grows to 2500 or 3000 lines or beyond.

Probably most robust software you depend on is full of solid, quality abstractions. Learning to write code like this takes practice. The wrong abstraction might be wrong, but it’s one step closer on your journey to growing as an engineer. You won’t grow if you never try.

Agreed. I’ve written plenty of software of all kinds and have never had to write a 2000 line long methods (although I have had the joy of refactoring such messeses a time or two).

Just don’t do that. Your code doesn’t have to have abstractions out the wazzo, but if your class (or method) is getting bigger than 1000 lines that’s a great sign that it’s doing too much and abstractions can be teased out. Your future self will thank you, as well as your team.

It’s interesting how different the experience is between Whole Foods and the bigger brand Safeway style stores. At Whole Foods there is no scale in the bagging area and you are free to put whatever you want there. The process is smooth and works well.

At the same time, it’s notorious for people stealing stuff - many folks I know across all income spectrums cheat the system in some way.

The temptation to ring in organic produce as conventional and save a few dollars is pretty damn hard to resist myself.

On the other side, if you are privileged enough to be financially stable, in the USA it’s best to pay for every single thing with a credit card.

Aside from the points and rewards, credit cards are much more likely to reverse fraud transactions. I’ve had banks deny fraud reports and demand police reports while credit cards always reverse the transaction no questions asked.

Actually it’s best to not even have a debit card in your wallet if it’s linked to your main bank account - the only debit card I carry has access to an account with a hundred dollars or so just in case I need cash.

I feel like a common refactor in a large project might be a complete redefinition of a model layer exposed via a bunch of structs.

How does immutability or patter matching save me from runtime errors caused by changing the fields or types inside a struct? Wouldn’t the pattern matching just fail and go down the wrong code path since it was matching for the old pattern?

I feel like immutability is great, pattern matching is great, but static typing is also great and there is no reason why it can’t happily live along side the other two.

The “let it crash” philosophy is great, but at the same time a proper static type system protects you from a whole class of crashes before they ever reach deployment.

If you change the shape of a model object and break its type, it’s great that BEAM will gracefully handle that mistake, but no matter how many times that service restarts, it will still be broken at runtime.

I think type systems have gotten so good in modern languages (Kotlin for example) that it’s a disservice to your org to not use a statically typed language.

I haven’t looked at Dialyzer lately, but is it as robust and easy to use as a first class type system? Having experienced partial typing with annotations with python I must say it’s not nearly as smooth as a proper statically typed language.

I do wish something like Gleam was the front runner language on BEAM - I bet it would get taken a lot more readily.

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?