522 karma · joined May 22, 2010
I was worried that Apple was going to discontinue support for my early-2015 13" MBP after their new Mac announcements in the late Oct 2023 event, so I took it to the Apple Store in Sept and had them replace the battery which had been needing service for a while.
It's stuck on macOS 12 Monterey, but got a macOS security update in Oct (possibly its last) and a Safari update just over a week ago.
But I continued to use Dark Sky because the UI was great at showing the hourly sun/temp conditions (accurate enough) at a glance, and it doesn't rain often in SF so the accuracy of rain predictions wasn't important to me. Also I'd paid for it: no adverts, no subscription.
It seemed weird to me that Apple acquired Dark Sky's poor rain prediction but didn't use the best part of Dark Sky's UI. Worst of both worlds.
Writing a project journal might seem onerous to some people, but if you get into a habit of writing, it gets easier. Eventually the cognitive load becomes trivial. And it's so valuable when you're returning to a project that you dropped for a year.
I started a daily journal writing habit a long time ago (~15 yrs), and it has evolved a lot since then. Specifically, now I write a work journal for every dayjob, and an individual one for each side project. My system has gotten more complex over time, so there are other notes files, but basically you just have to get into the habit and evolve your own system that makes sense to you as you go.
I probably shouldn't even mention this because it sounds crazy, but another thing that really helps me is that I arrange my source code based on each major feature, with scripts that can assemble/build/test the app at that stage. For example, it's nice to be able to get a version of the app that has no user accounts, and another version with account authentication. Yes, you could rely on `git checkout <hash>` to go back to an earlier stage of development in the code base, but that doesn't include subsequent iterations+refactoring that you might have done for that feature. Well, I'm not recommending that you do this, so I'm not going to say any more.
Nim isn't really known for anything other than being a good general-purpose language. In that sense, it's sorta like Haxe lang.
Other popular languages are T- or M-shaped generalists -- i.e. good enough as a general purpose language but also excelling at 1-3 specialties. You can use these languages for anything but in practice you use them in specific contexts.
* If you're working on a game in Unity3D, you're almost certainly using C#.
* If you're working on ML stuff using Jupyter notebooks, you likely use Python w Pandas etc.
* If you're doing big data processing with Hadoop then it's likely Scala w Spark.
* If you want a very high concurrency messaging backend, then Elixir or Erlang on OTP/BEAM is a good choice.
* If you're making a native iOS app, you don't have to use Swift but you probably will. Same with Kotlin for native Android. If you decide on Flutter instead of native mobile, then you'll use Dart.
However, my boss is never going to make me use Nim, because there aren't any particular use-cases where Nim is known as The Language To Use For That Situation. AFAIK Nim isn't known for any particular libs/frameworks/tools like Django, Rails, numpy/scipy/pandas, PyTorch, Hadoop, OTP, etc.
(full disclosure: I had a hard time finding a good language to replace my Bash scripts and settled on Nimscript, https://news.ycombinator.com/item?id=35756090)
Also *Timing*
Nim came out right after a number of other well-known languages caught on. There are too many other decent and popular languages to choose from. I like Nim, but not a single one of my programmer friends or acquaintances uses it. Whenever I mention it, the reaction is like: "Better to stick with a proven language I know (usually Go/Python/Ruby/Java)" / "Is that like Zig?" / "I'd rather learn Haskell, Rust, or a dependently typed language."
And finally...
I think Mojo is going to hurt Nim adoption.
I tried Ruby instead and it's nice but not enough of an improvement over bash for me. I tried Julia which has nice support for shell but the JIT compilation was annoying so I dropped it.
Currently I'm trying Nimscript, which is ok but example code is sparse, docs unfriendly, and the language is hostile to tabs and it has noisy output that you have to disable. Overall it's not pretty but workable so far.
Before you downvote me for insulting your fave language, he asked for opinions, and that's what I wrote.
I use it sometimes and it's pretty good. Haven't done a direct comparison with Copilot though.
* When I first moved to SF I got a 1br apartment, but later rented a very nice 2br2ba flat as the "master tenant" and got a "subtenant" roommate. Maybe you wouldn't consider having a roommate, but it's nice to have someone else around. If you set the rent price relatively low for a high-end apartment where each person has a private bathrm, you'll get more roommate applications than you can handle. Winnow the emails down to dozen or so. When you interview a dozen candidates, there's almost always one person who stands out as someone who would make for a great flatmate. (Warning: if you rent a 3br place and get 2 roommates, it's a lot more complicated. Difficult to know who did what, e.g. left food in the frig, etc)
* You might consider joining a lot of meetup.com groups. I joined literally over 100 SF-based groups and during the 2010's would go to at least 2-3 per month. I stopped going to meetups during the pandemic but it seems like in-person meetups are ramping up again.
* You run a mobile game studio? Join the Stanford Games/Entrepreneurs list. https://mailman.stanford.edu/mailman/listinfo/gsb-videogames It doesn't have as much chatter as it used to, but every once in a while there's some insider discussion. I used to be in the game industry, so I'd offer to connect you with people, but it's been some years so my contacts are kinda old.
* Your main goals are mostly professional, but consider the opportunity for other things. When I first moved here, it was supposed to be temporary for maybe 3 years max, so I tried to take advantage of things here that I couldn't do back in Atlanta. I did things like: every winter I joined a shared ski house in Tahoe, I volunteered as a National Park Service docent at the Point Bonita Lighthouse, and did more biking/hiking/outdoor stuff that I rarely did in Atlanta bc it was too hot there. This mindset turned out to be a nice forcing function to push me to do things that I wouldn't have done otherwise. Like, you're right by the ocean so you might consider taking up scuba, surfing, kayaking.
* Feel free to contact me. My email is in my profile.
// sum weight of items carried by elf
elf_weight := 0;
for weight : elf {
elf_weight += weight;
}
I apologize if this is already covered in the article, I've only read about half of it. Also I'm sorry if this comes off as criticism of the code or of Jai, I'm just wondering what kind of iteration and array/list ops exist (without watching dozens of videos).
Also when I was in college we used to use a friend's last name on restaurant waitlists. Her name was very unusual and it was funny amongst those of us who knew her.
(Edit: my own experience mirrors the article experiment.)
I never heat my house in San Francisco, and it frequently gets down to/below 10C/50F in the winter, and below 13C/55F at other times of the year. If I'm not moving around, just standing at my (standing) desk, then yeah I get cold, so I put on extra layers, a knit cap, and/or fingerless knit wool gloves. Often I'll already have wool socks on.
Btw a knit wool cap gets very hot especially if you have a full head of hair. Someone taught me that you can roll up the edges of the cap to dial down the heat. My partner smirks at me when I do this - she says I'm wearing a yamaka - but it works great, and you can fine-tune your temperature very well this way.
There are several that match your description on the first few pages of results.
If you change the query to "100 days" then you get more, but "90" fit your description better.
I've had to layoff direct reports during multiple layoff waves at a couple different companies. (Moreover, I myself have been laid off when a small company went out of business or when a business unit was eliminated.) I don't think it's difficult to avoid cruelty during a layoff, you just have to be very honest and make it clear that it is not personal. The announcement should be company-wide, but then talk to each person individually or in small teams if possible, and afterward go together offsite to a bar/restaurant and hang out with everyone who can join.
Honestly in many cases it's better for them to move on rather than go down with a sinking ship. In tech over the past couple decades there's always been jobs elsewhere for engineers, even after the dotcom bust. I have tried to help place people elsewhere using my network and told them I'd give them a good reference if they needed one. HR tends to discourage you from making an extra effort like this -- e.g. "you should only acknowledge that they worked at the company, don't give a recommendation" -- because a recommendation can become a liability, but I feel it's my recommendation as their direct manager and I am taking personal liability for it.
---
There's something else I'd add -- not about layoffs but related to firing people. Even if you're firing someone for performance reasons, IT DOESN'T HAVE TO BE CRUEL. I've seen so many people get fired in such a cruel manner, and it's totally unnecessary. There's absolutely no need for the manager to have any sense of anger or betrayal over a person's poor performance in a role.
Someone's performance in a particular role in a particular company has nothing to do with that person's worth as an employee. It was always just a bad fit, or a bad situation -- it doesn't mean that this is a bad person or even a bad worker, and should not reflect upon their self-worth. In my career, I've had to fire two people for performance reasons, and both times I made this difference clear, and thankfully we were able to actually maintain a friendship afterwards.
Another one is Oculus -- acq by FB in 2014, first consumer release in 2016. (Although you could argue that the 2012 kickstarter was a launch.)
Also, wasn't Vine prelaunch when it was acquired by Twitter?
A recent example this year is Qualcomm's acquisition of Nuvia.
My point was not that engineers are overpaid. That's not for me to judge. Only that many business models won't support those rates. That's the CEO's fault not the engineers. See for example: https://twitter.com/typesfast/status/1537151707141918720/photo/1
Suppose you have a website that caters to competitive Mahjong players, and earn revenue based on a combination of pro subscriptions, micropayments, adverts, and sponsorships. If your Trailing Twelve Month revenue is $120K, you couldn't afford an engineer who costs $100k/yr, much less $400k.
https://www.youtube.com/watch?v=tRHJkKTt0mY#t=8m30s
> After I graduated Berkeley as an undergrad in 2006 I worked at Industrial Light and Magic for about a year and a half. I met so many amazing, super talented, literally genius people there, but after a year at ILM, where they were doing movies like _Transformers_ and _Pirates of the Caribbean_, and doing all kinds of innovative motion capture research and simulation research, I found I was meeting too many people who were there since _Return of the Jedi_, who still wanted to make their feature film or wanted to make a sculpture, and that the creative burden of being at such a creative place took something out of them.
> I made a very seemingly irrational decision at the time -- it seems rational now -- that I really wanted to find a way to choose *my own problems*. And so I moved to New York - I went to Columbia for grad school - and for those of you who are in grad school here, I can tell you now that I didn't do *anything* in grad school. I was totally lost, I checked my email for two years. I didn't make anything and there were people who were making prolific amounts of work -- so much work that it filled the hallways, I couldn't get into my own studio. My studio at Columbia had black mold in it, so I was kinda getting drowsy all the time.
> It was only afterwards where I encountered a second set of mentors - I started working for two artists, one called Paul Chan, another called Pierre Huyghe, who both -- besides me -- really loving their work, I really learned what it felt like to live and be an artist, because I was around them so often and I really understood their "metabolism" -- that sounds weird -- but I understood, like, when they ate, when they exercised, how they needed the time in the morning to be away from people, that that was a really fertile time to make creative decisions. And I came to admire how they structured their time and their day. This became a real cornerstone and model for me for figuring out how it is I would want to make work myself.
You mention that a job provides a "framework that exists and you purely have to execute". And that is exactly what we're talking about here but for personal work not a job. It's a common message -- see Twyla Tharp's "The Creative Habit" or Stephen King's "On Writing" or even Steven Pressfield's "The War of Art" -- a personal work routine provides the framework.
However, even when I understood this consciously, for a long time I didn't have enough exemplars to internalize it.
Eventually what did the trick were other routines that I had been able to incorporate into my life: writing in a journal, cooking, and daily training for long-distance treks. Every time I had a question, I just had to look at those examples for analogous answers.
There were other steps involved too. Feel free to email me (contact info in profile) and/or read other comments I've made on similar AskHN posts.
Let's suppose that real results come out of current research into NAD-boosting and other methods for reducing defects when cells split and for reducing senescence of cells. That would extend your potential lifetime but you can still die from accidents/violence, cancer, and diseases incl heart disease, so you need to take preventative measures for those factors.
David Sinclair suggests that you should cut sugar/desserts from your diet (because it encourages cell splitting), and reduce damage to your body, e.g. use sunscreen (because cell defects arise when repairing cell damage).
If humans could grow biblically old, like 600-900 years, one thing to consider is it's possible they might start looking like Ferengi, since cartilage just keeps growing.
For example, say you use a svg button component several times on a page, and there's a filter in the SVG that you use to change the appearance of the button when it's disabled. If the filter tag doesn't have a unique ID, and one of the buttons is disabled while all the other buttons are enabled, then all the buttons will become disabled if you modify just one of them, because they're all referencing the same filter.
It's very easy to make the IDs unique by using a sequence number (as a member of the component class), incrementing the sequence number in the component constructor, and appending that sequence number to the ID every time you call the template function.
After I fixed this problem in my code, I found out that the css-tricks guy had also run into it and he did a whole write-up about it, but he was using React not Web Components: https://css-tricks.com/heres-how-i-solved-a-weird-bug-using-...
Requiring that javascript is enabled in the browser isn't a factor because my project relies on WebRTC, which requires javascript anyway. Its main value prop wouldn't exist with javascript disabled, so I'm just going to ignore that criticism.
To work across Chrome/Firefox/Safari, I avoided templates/slots by attaching the `ShadowRoot` and setting its `.innerHTML` to the result of a function that returns the html template literal string (where the function can fill variables in that string). I haven't tested this on Edge, but it works fine natively on the other browsers without any polyfills.
I love using Typescript without any client-side framework, but you might have different constraints than I do. Particularly when it comes to job search -- it seems that almost any front-end webdev position requires React/Angular/etc so you might find that it's a career-limiting move to go straight to plain Web Components as I did. I don't care because my main background is in mobile not web.
Your lack of a degree is not as much as an issue as the coding screen test. If you can ace those tests then you'll be able to get a job. I hate the idea of these coding tests -- I have decades of coding experience and even I must practice these coding test problems. It's the reality we must face, and we must deal with it. For those of us who enjoy coding for the joy of it, we can self-study data structures, algorithms, and system design for the joy of it too.
I know from previous job searches that I'll fail some coding tests at first, but as I get more practice then I'll start passing the interviews. Like everything else, it takes iteration.
Luckily there are lots of open job positions to apply for. You just need to believe that you can will get better with practice, and you can keep interviewing over and over until you beat the tests. You taught yourself to code; you can teach yourself to pass these interviews.
P.S.: These tech interview coding tests have been around for a long time. I remember going through some tough ones back in the 90's, even before Joel Spolsky promoted writing code during interviews in The Joel Test.
Once someone tried to convince me that "The Procrastination Equation" described the problem exactly, but to me it seemed to ignore key factors, although I admit that it was nice that it recognized that different people have different issues, so there's not a single trick that works for everyone.
I'd suggest that you try the first exercise from "The Now Habit" (Neil Fiore, 1989):
"The first step is easier than anything a book on procrastination has ever asked of you before: simply procrastinate at your normal level for another week. I will teach you to become aware of how and when you procrastinate. Just observe yourself objectively, like an anthropologist who records the behavior and rituals of a foreign culture without making judgments. Don’t judge yourself or analyze your behavior. For now, just concentrate on becoming aware of your current behavior patterns."
For me, this exercise was fairly easy because for years I had been logging my activities in a daily journal every couple hours, so I increased the frequency to every 15 min. What I discovered during this exercise was astonishing to me.
Knowing what the problem was, then I could address it. In my case, the issue was described fairly accurately in chapter 1 of Eckhart Tolle's "The Power of Now".
(I've been looking around at SWE manager jobs, and it seems fewer than half of them have a salary range that rise above $200K. I have decades of serious product development experience as a programmer, several years of experience as an engineering manager/director, AND I live in the city of San Francisco. Maybe I'm not looking hard enough.)
I find talking about languages with other programmers can be challenging, because there's a class of coders who seem to have a belief that all programming languages are similar to mainstream imperative languages and therefore their strong opinion about all of them is valid and it's as if there's no point in learning more. Paul Graham mentions this in his Blub Paradox essay (http://www.paulgraham.com/avg.html): "You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.". In discussions with other devs in 30+ years as a professional coder, I've seen that over and over and it's kinda shocking to someone like me who partitions knowledge into the ol' known-knowns, known-unknowns, and unknown-unknowns.
Your question mentions carrying over a coding style from Python to C. True, you can do that and not really learn the new language. But for some languages, the compiler can force you to use a certain kind of programming style.
For example, in a lot of languages (say, Python, Ruby, Typescript) you can use higher order functions (like map, filter, reduce, zip, etc) but you can also write large codebases without ever using them. They're like an optional language feature that you can adopt depending on your preferred coding style. In Swift I noticed that there's no real difference in conciseness when comparing the syntax for map() or forEach against an equivalent loop, so that's not even a compelling reason to switch styles. But in a language that prohibits loops and early returns (e.g. ML-based langs like Ocaml, Elixir) then you're forced use those higher order functions to avoid having to write loops as custom recursive functions. It wasn't until the compiler forced me to code this way that I truly learned it.
Likewise, if your language enforces Option/Optional/Maybe (e.g. Swift, Scala, Rust) then you're forced to write code to deal with nulls. (Typescript is also like this, but you can bypass it by setting the type to `any` or using the `as` operator.) I worked through some chapters in an old tech interview book (Leetcode-style problems) in Swift and compared the functions to their equivalent in C, and was a little surprised at how many lines of code were dedicated to optionals. However, it was just a line or two more than the equivalent in C if it checked for null pointers. (Swift has a lot of nice syntax sugar for dealing with it; I wasn't as pleased with how Rust does it.)
You've probably heard of people talking about "fighting the borrow checker" in Rust. But the borrow checker struck me just like the above language features. You had to give up a style of coding and adopt a new one.
There's no system that works for everyone. You have to develop your own, and it will evolve because you change. I started journaling over 10 years ago - it was a simple "daily log" that I only wrote in occasionally. Over time I got more prolific and proficient at it. The structure of that journal became more complex, with different journals for day-job vs personal, multiple levels of summary vs detail planning/notes/ideas, and links between them. I've had to refactor that structure and the taxonomy of tags many times. And much like he describes here, I ended up adding cheatsheets and Q&A and dev templates. *There's no way I'd recommend this system to a beginner.* You have to build your own system according to where you're at in your journey.
I had a career in the game industry, and it was just like that for me. When mobile games became a thing, I quit my job at EA and built a whole game by myself for the first time.
If you want to build games, give yourself permission to just do it. I suggest you start on something really super simple and small that you can do by yourself, and finish it. Then keep iterating, or start on something else slightly more ambitious, and do that over and over. Force yourself to finish each one, even if you have to cut scope.
Recently I've been building a multiplayer online turn-based game. It's nothing fancy, just a card game with video conferencing, but developing it myself is way more satisfying than a job at a game company.