Alternatively, throw some AI in there (https://krisp.ai/) :P
665 karma · joined May 28, 2020
(Feels so strange to "review" Spotify, haha)
Honestly, I'd recommend avoiding LinkedIn. It's completely devoid of any personal aspect to the work people do -- it's all business-this, company-that. There's no such thing as a post that's not spun in some positive manner.
As others have mentioned, in short, it's idealized. Plus, the skills that other people have are not necessarily the same skills YOU need to succeed. That includes Leetcode problems. Which, by the way: if the company cares about that kind of thing at an interview, they probably have that same sort of mindset during the job. Not guaranteed, but keep that in mind.
I struggled with impostor syndrome for a good three or four years, despite objective successes in my programming "career" as a student. I think that finding your own value, and distinguishing that from the skills you need to succeed, AND convincing yourself that you can get those skills, is the golden ("growth") mindset.
For example: math. (undergrad CS: calc, etc.) I tell myself I'm not good at math, I struggle adding basic numbers. but I've either 4.0'd or got 90%+ on midterms or just _passed_ enough math classes that I know this isn't true. How? I realized that math is literally just practice. That's it. Work in = work out, and if you get stuck, it's about correcting false assumptions.
That particular realization allowed me to embrace the (honestly terrifying) interview process a bit easier. Leetcode isn't about "grr get this problem perfect otherwise you're trash". Leetcode is about "okay, look, we have 20 minutes to see how good of a programmer you are, here's an intentionally hard problem. how clever are you. how fast are you. and do you fit our mold". THATS IT.
So, what could you do?
First, mindset. I've been doing iOS programming for a good 4 years now, but allll that work makes me worse at Leetcode, because I over-optimize for cases that don't matter. Realizing this made me slightly better at Leetcode. Only slightly.
Remember, Leetcode is just tiny, intentionally hard problems. It doesn't represent your skill as a programmer, just your ability to express a small subset of programming skills. And honestly,getting those skills is hard. I don't have an answer for that. Maybe try to analyze each problem, figure out what it's trying to test you on, then learn that topic from scratch.
Sorry for the ramble lol, hope it was helpful
In every hobby there is always a sense of discipline, it's just usually implicit. For myself: composing orchestral scores started off as a fun little "oh this melody would sound neat". Ever since then, there have been times when I need to sit down and do some "real work" to turn that idea into an enjoyable, fulfilling result. Could I have just wrote things when I want to? Of course. But now, after years of composing, I have the skill to make things that sound great when I really just threw it together.
In software engineering, a beginner or even intermediate programmer is going to lose a lot of their initial motivation to build their idea (game, app, website) -- because in finding the skill to execute on their initial side project idea, they realize they need to develop that skill from scratch, which takes work.
I think there's a good balance between investing skills between "basic knowledge" and "career capital". What that balance is varies from person to person, but I also believe that no matter what, even if it's implied, there is always a certain amount of work that needs to be put in.
[0] https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-cod...
All that info that's now in the sidebar is temporary. All of it. I never need to look at a project language more than once.
However, it takes up 100% of the height of the page, so when I'm halfway through a README, the README gets offset by some magical space. The ghost of the 1 paragraph of "language/tags/etc." takes up that space. The README is not centered.
From a design perspective, this layout implies an equal level of hierarchy between the right sidebar and the main content. It implies that they should be referenced side-by-side. But that is just not the case. I want to meet the person who thinks that the document literally entitled "README" (or oh, I don't know, all of the files) is somehow as-or-less important than the tags on a repository -- which are usually just the title copy pasted anyways.
I develop open-source things and I absolutely love to use GitHub. In particular, I've spent a LOT of time reading README's and also writing them. I really think their centered layout should come back.
As a suggestion: Maybe they could shift just the _files list_ over for that sidebar, and have any block content not centered?
Or maybe if there somehow existed a compact way to organize that information. Maybe a horizontal layout because there is only a little bit of text. Something like that.
I left feedback the moment it entered "feature preview", left feedback on all the accessibility it lacked (mainly reducing contrast everywhere), and well, looks like they just rolled it out anyways.
Really wish they would take things like people being able to see their product without difficulty seriously.
I like that this time they lined up design changes + hardware -- and that this time hardware was the reason to bump the version.
Like, we saw Intel transition in 10.3-ish, no more Rosetta in 10.7, entirely new design + Swift in 10.10, Catalyst and SwiftUI (brand new frameworks) in 10.15, but new design + ARM was the push for 11.
I like this trend of hardware being the "major" version bump but now I'm curious what kinda space-age paradigm macOS 12 will be breaking. "real" 3D touch? Brain-computer interfaces? I can dream, okay?!
I personally think that for software dev at least, making connections via Twitter or via friends is a better way to go for the first internship, but everyone has different paths to success :)
I think that might have to do with this complexity, but also: software has so many ways of doing something, even within the same language -- and that gets permuted across, say, five different languages (Python, Rust, PhP...). It's impossible to say the "right" way to do it because there are multiple ways to achieve a valid result that's readable, AND there is a margin for disagreement between what is "readable".
Like, for Instagram. First, just the scrolling list of images. Then, images with text under them. Then, a tab bar with images and a profile. After enough of this, a basic skeleton will form and you'll start hitting the fun edge cases: how do you edit a user's comment? How do you make sure user data is always in sync? How do you handle every possible API error that you might get, and communicate that simply to the user?
Open source projects are also a great reference. As an iOS dev, I'm biased, but I've heard Android code tends to err on the side of "meh, it works", even in large projects, so be on the lookout for that. Software architecture tends to be fairly consistent across platforms in my experience anyways.
And this kinda device-reference approach, I believe, is mathematical. And I also think that a lot of what makes music tick is that inherent usage of the musical language we study or grow up with. Truly original music imo doesn't really exist[0]; the intentional or unintentional borrowing of ideas is why music theory is a field of study: to describe the ways in which music works. I think even modern techniques (set theory, 12-tone rows, and atonal music overall) has to look at the existing rules and say "what can we do differently" -- even as Romantic-era composers got more adventerous in their use of texture, harmony, tonality, etc.
(The story of Charles Ives, who spent most of his younger life being "untrained" by his father to sing duets in overlapping keys and the like, is a good example of this.)
> ... actual composition, which is developed to a level that far exceeds the guidelines of species counterpoint itself
While true, I still think it's more of a spectrum than a binary "all or nothing" mathematical approach, which is why I believe that musicianship is more mathematical than not. I agree that it far exceeds the "use a forth and you're beheaded" approach but I'd be interested to hear music that is entirely free of some sort of process.
[0] note: the discussion of originality in music is probably an entire essay on its own, lol
Ding ding ding! However I do think that the combination of syntax with the brand new concepts just adds that extra layer of complexity. A similar thing is Optionals in Swift -- the syntax is so baked into the language that even if you really understand how optionals work, the syntactic sugar keeps piling up in different situations. (i.e., first the ? operator, then implicitly unwrapped optionals, then if lets, guards, guard lets...)
The borrowing model was actually my favorite part because it not only was interesting, but made sense! And the syntax was relatively clean :)
And especially Mozilla's intense passion for open-sourcing everything. I think it was a good catalyst to get it into the hands of as many people as possible.
Species counterpoint is entirely mathematical, as is (to a great extent) common-practice partwriting. Yet, I guarantee you that most people who listen to that music would think it is entirely musical, when in fact very little is more than rule-following. (And yes, this is for a lot of genres! Sonata form, pop structure, etc., etc.)
Also, involving the work of David Cope, his rule-based composition systems repeatedly passed the turing test.
(I'm hoping, once I get to grad school, for my master's thesis to be around this exact idea: the computational aspect of creativity, and how the idea of "musicianship" is really just a human attribute we hold on to.)
I agree that music theory is mainly descriptive rather than prescriptive, but the fact that many works of genius center around patterns, well... it's hard for me to believe that we aren't heavily dependent, on some level, on math.
Oh boy now that's a fun one
There's a great book called "The Oxford Handbook of Algorithmic Music"[0] that has many insights into that! Some philosophical, some really mathy.
[0] https://global.oup.com/academic/product/the-oxford-handbook-...
> goes into channel
Hey, this is the Freeman's Mind guy!