turdprincess

Reportedly Facebook asks two mediums in 45 minutes.

The key word here is “theoretically”. These cross platform solutions are great in theory - who wouldn’t want to share code across all platforms? It’s a great sell, especially to the folks holding the purse.

The reality though is it doesn’t work well. The tooling, performance, debugging, library stability and observability are all substantially worse. Your team might save a ton of time spinning up a React Native app, but lose it all right back once you keep hitting gnarly Android performance issues.

In the future, once we have a proper cross platform development kit officially supported by Android and Apple, code sharing will be great. But today it doesn’t exist. And that’s why none of (the good) apps you use are written in a cross platform way.

Ive been an iOS dev for 10 years now and every few years a new cross platform framework comes along. They all suck. Either the development experience is awful, or the user experience is awful. Actually, it's usually both.

The thing is that its easy to get 90% there with these things. But getting that last 10% is often a huge hurdle, erasing most of the efficiency gains you just made.

Then, when a new hot framework comes along, the old hottness you bet your project on quickly becomes deprecated, and you have to rewrite your whole project under duress.

I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian...

How long before people give up on that and move on to the next thing?

Hiring is really tough as well. With cross platform, at the end of the day, when you get that crazy memory issue or app crash, you need native expertise. So to be an effective cross platform engineer, you have to be an expert in iOS, Android, and whatever hot framework you bet on.

If you need to get to market very quickly and are OK with throwing it all away in a few years, cross platform is a great choice. But if you want your app to stand the test of time, the best thing you can do is to write it in the only framework which is officially supported by the platform - all native.

I think this attitude of making sure each junior engineer has someone senior answer every question as soon as it comes up is doing a disservice to our junior engineers. One of the most important qualities of a senior engineer is that they can independently solve an open ended problem, especially one they haven't solved before.

Being senior means you have learned how to learn. You don't get this skill by asking a bunch of questions, you get it by answering your own questions without having someone else to rely on. This is a skill we should foster in our junior engineers as early as possible, and being available as a shoulder to tap on every 15 minutes actively prevents that skill from developing.

I think it is perfectly resonable to mentor a junior developer using a single, daily video meeting of 30 minutes or 1 hour. This is a time they can use to ask questions about their previous day, bounce ideas, etc. If a question comes up later, they can spend the day trying to solve it and report on it in the next daily meeting.

The best thing you can do for your junior engineer is to find a stream of work which challenges them at the right level (not too much, but just enough), and let them go independently while keeping some guard rails. This should not require many hours of 1:1 face time.

I understand this approach might not work for some juniors who can only learn in a highly social context with a mentor in the room. But I think it can work for many juniors, and actually be beneficial in the long run.

You could pick up some contract work on Upwork. Set a really low rate and then work up. Pick a niche and specialize.

After you do some contracts and get some good experience under your belt, register as an LLC and give yourself a title - software engineer at your company.

It should be enough to get your foot in the door for an interview and from there as long as you are a good talker you will get the job.

It is none's business about why you left (or are leaving) your previous job, unless perhaps it is due to some legal issue that would show up on a (criminal) background check. Interviewing for a new job is all about the future, and it's totally up to you to reveal only the facts about your past that paint you in a favorable light.

Whether or not saying you got laid off would hurt your chances is a separate question. My guess is most of the time it wont. But as a flip, would saying you got laid off improve your chances of getting the job? If the answer is no, then its not worth saying - focus instead on the things that for sure portray you positively.

The same goes for jobs with short tenures - if you stayed at some place for a few months and left just leave it off your resume. It doesn't do anything to sell you, so why waste time on it?

Just remember, an interview is a short period of time to sell the best parts of yourself that are most applicable to the job. It is not a 100% confession of all the good and bad things that happened to you.

I'm not so sure. AAA estimates that it costs $10,728 to own and operate a new vehicle per year which is driven 15,0000 miles per year. This includes all the costs like depreciation, maintenance, gas, insurance, etc, and works out to be $0.71 per mile.

At least in my town, Ubers are more expensive than that. I can't seem to find a trip anywhere for under $15, even if its a few miles away, or like $3 per mile. Longer trips are more economical, but for example, my airport (40 miles away) is quoting me $80 at the moment, or $2 per mile. Also, these prices don't include tip.

I think if you lived in a big city with public transportation and occasionally took Uber, it would be more economical than a car. But as a 100% replacement, Ubers appear to be 3 to 5 times more expensive than having your own car.

And by the way, that AAA data is from a brand new car. You can easily go cheaper by getting a reliable used car.

source: https://newsroom.aaa.com/2022/08/annual-cost-of-new-car-owne...

Curious if you have done this yourself

It really depends on who stays and who goes. Big organizations are collections of individual teams. Each key part of the site has a team behind it with 5 - 10 engineers.

If the departures are such that for each team, 1 competent senior engineer remains who can keep that domain running, then Twitter could be unaffected with 1/5 of its workforce. They might not be building new features, but the current site could function, which is reasonable since the current site is arguably feature complete.

But in reality it won't be as clean as that. If the whole localization team quits, suddenly the site won't be translated to other languages. If the whole mobile release team quits, suddenly the Twitter app might disappear from the app store. Or the security team is gutted and suddenly everyone's passwords are leaked.

To be fair, I am not saying college can't be that kind of experience too! But when a company is looking for a college degree, they aren't looking to make sure their employees experienced enlightenment in a poetry class. They are looking for evidence that their employee completed a 4 year structured program.

That was my point as well - its not what you learn in college, its that you can learn something. I am not a proponent of Leetcode (and suck at it personally), but I think the same concept applies - just shows you can learn an arbitrary puzzle framework tangentially related to the job you are interviewing for.

Its also my experience that as you get more senior and focused on a specific skill (I'm an iOS engineer), interviews tend to focus on that skill more than leetcode. I think there are a few stalwart holdouts (facebook + google), but I have interviewed with several trendy big tech companies and none of them asked me pure leetcode - it was always framed around my iOS skillset.

However, for a junior engineer there is no way to evaluate this kind of skillset since it doesn't exist - so Leetcode is a resonable substitute.

Searching slack is a superpower. You can solve problems you have zero domain knowledge in just by searching for past instances of that problem.

As someone not particularly social, it’s an amazing way to get unblocked without relying on another human.

It could also signal that you got motivated and took many hours out of your busy day to do a meaningless task like memorize a path finding algorithms. This might be a good signal that you will also be motivated to spend many hours doing meaningless things at your job.

Actually, if you think about it, the whole concept of getting a college degree isn't much different - its not about what you learn in the classes, it just shows that you have the capacity to go through an arbitrary social experience, follow a bunch of rules, learn some stuff, and stick with it for a few years - pretty similar to a job.

Even if my client thinks I am billing hourly, in my head, I am billing by the day, which happens to cost about 8 times the hourly rate I quoted them.

On my last team, I had an incompetent junior engineer. It was a time suck to do hold countless pairing sessions with them, answering the same questions again and again without having them learn anything.

On my new team, there is an incompetent senior engineer. Damn... how I miss my incompetent junior, who aside from wasting some time, never really affected the team. The incompetent senior produces impressive amounts of badly architected, untested code which breaks subtly and is impossible to maintain. They are also totally unreceptive to mentorship because they are so senior and know everything.

It is my opinion that the extra inconvenience that in-person folks have to do it dial into a meeting and use a virtual whiteboard is worth it to allow remote folks to fully participate. But ultimately it comes down to how strongly a company supports a remote culture. I’ve worked for 100% distributed companies, and I’ve also worked for places where remote was an afterthought. I imagine at some companies it’s harder to get promoted if someone doesn’t physically see you in all 3 dimensions every day.

As a remote employee I will always try to gravitate towards companies that accommodate me best, but I’m not opposed to the idea that some companies want to be in-person and don’t want to deal with remote. I just chose not to work for those companies.

Not sure I agree - the hybrid model where some are in office and some on video is unfair to the remote folks. Watching coworkers whiteboard from a zoom call makes it much harder to collaborate as the remote employee. It’s also harder to get a turn to speak when you are a face on the camera vs in the room. For these reasons I’ve insisted that in hybrid meetings, everyone dials in individually and whiteboards on a virtual whiteboard even if they are in the room. This is effectively demanding “all remote” from the in-office crowd and taking away their face to face interaction.

Not much of an Elixir developer but if I saw that snippet in code review I would flag it for readability.

Just because you can write something in 3 lines of code using lots of nesting and anonymous functions and variables doesn’t mean you should. This code would do better if it was longer, the variables had names, and the transforming functions broken out and named.

I’ve been employed by everyone from small consulting firms to big tech to FAANG and I’ve never seen anyone let go for performance. This includes serial low performers that produced nothing for years. Aside from a very few (like 1 or 2) select companies, the bar to staying employed is laughably low in tech.

In my opinion this is a big problem. I wish there was a stronger culture of letting low performers go quickly in tech. This would reduce the need for exhaustive interview loops and ultimately make the industry more inclusive because you could afford to take a chance on someone without being chained to them for years to come.