Not as old as the author, but I remember a time when my family's home computer was slow. I went to the library and picked up a book on making Windows XP faster, circa 2007.
I really miss those kinds of books now. This book distinctly had color and screenshots of all the recommended changes to make.
I'm a big fan of the book "The Tech Resume Inside Out"[0], it may be helpful to you.
The best thing I learned from the book was that for some positions, interviewers weigh your experience more heavily than your side projects.
This, like all advice on this topic, highly depends on the company, the individuals interviewing, and your side projects.
I typically think of it this way.
When you are fresh out of college you've had little to no professional experience - the most you've had is probably an internship. For an employer to hire you, they'll probably evaluate your internships, school work, and personal projects. It's evidence of your knowledge and how well you'll fit into a role.
After your first job - it's much different. Employers care much more about your experience, because you've worked within scenarios that you'll work in at their company. With fresh graduates, it would be unfair to evaluate them on years of working experience - because they won't have any - which is how personal projects come into play.
An employer will want to hear more about your experience at X company, because you've worked on things that have users, scale, and issues that come with all of that and more - which personal projects sometimes do not have.
That being said, personal projects can matter more if: 1) You are changing tech entirely, so you have a project to act as evidence of your newly gained knowledge, 2) Your personal project is running somewhere and has users, and/or 3) you work on open source projects. There's probably many more reasons that I'm missing.
I'm typing all this out because for me I weighed personal projects much too heavily. My first company had extremely outdated code and custom frameworks everywhere - I was afraid that my experience didn't mean anything. I kept on trying to find time to work on projects, and which led me to never try interviewing - because my projects were never done. Reading the book I suggested helped me to break out of this belief - and led me to find a new position.
Aside from all that I've said - the other things you suggested are good: taking interviews as practice and going through interview exercises.
Pramp[1], and other resources people have recommended here, are really good to practice with. That being said - the best practice is to be in an actual interview. I highly recommend finding companies that you aren't that interested in and interviewing there.
You may find that you are much less nervous! Going into an interview not caring about the outcome and maybe even expecting to fail really calms the nerves. Additionally, if you pass the interview and find that you actually like the company - then more power to you. Accept the offer and cut your practice short.
My final piece of advice - I know it is tempting to take time off to practice - but the best time to find a job is when you are employed. It's less nerve wracking knowing that you still have a way to make money if you fail the interview you are in.
As I mentioned previously, this always depends. For example, if you're living with your parents rent-free and your expenses are really low - then it is up to you. For many other people, it could lead to situations where you are running out of funds, and now you have to take the first offer you get.
That's fine, but once one assumes the impact of this technology is wholly without precedent then they're left speculating about a future informed only by their own imagination.
They'll always be able to re-affirm their own preconceptions (fears) because its the "just so" fantasy future of their own making.
I don't see the point of coming to HN to trade those invented stories, as people here traditionally push to stay within the engineer's realm of how real things work, how they fit into the history of innovation, and what people might practically build with those things based on how they work.
There are countless speculative fiction communities better suited to idle "yeah, but what if the sky was purple tomorrow?" discussions.
I like to fantasize about a super AI that does something for the working class people of the world.
Like, imagine one day that an AI just took money from a ton of different corporations and billionaires and redistributed it amongst everyone else. People will argue against the AI, and it'll just respond back with research done on how UBI improved people's mental health and well being.
AI is meant to be clever, AI will not do such stupid thing. Free money given to people who just spend it on unnecessary stuff will only cause more inflation. and the money will return the big corp anyway, just like it did during pandemic helicopter money times.
I believe you may be alluding to longtermism[0]. At it's face value, longtermism seems like a good thing, but I've heard many criticisms against it - mainly levied against the billionaire class.
And the criticisms mostly center on what you're saying here - how many billionaires are focusing on fixing problems that are very far off in the future, while ignoring how their actions affect those of the very near future.
This is really less of a criticism of longtermism, and more of a criticism of how billionaires utilize longtermism.
Is it important that we find another planet to live on? Sure, but many will argue that we should be taking steps now to save our current planet.
One of my previous work places with an auditing data set company.
We'd collect data sets from various sources (like public filings from the SEC) and the we'd send them over to different research teams to enrich the data in various ways.
That company was very Excel heavy - which made sense, we had data entry, accountants, and other people who worked in finance.
My CTO told me a story about how one day a member of a research team asked for a new computer. The old computer worked fine, but the employee wrote a VBA script in Excel that would crunch data... and wouldn't finish until 3 days later.
This employee wanted a new computer so that he had one to use while the other one was crunching data.
We ended up taking his VBA script and putting it into our codebase.
I think another reason why Emacs is in a second golden age is due to all of the new plugins that have come out in the past 3-5 years and how those plugins have affected Emacs.
For example, Eglot and use-package being part of Emacs core.
Additionally, there's also just many new plugins for the base-level things. I never thought there would be alternatives to completion frameworks like Helm or Ivy, until new ones came out. It's all been very exciting.
Someone else can tell you about Magit (the gold standard UI for Git), or Org Mode (the best markdown alternative / journal / planner / TODO / PM software, if only more people used it...). I want to take a moment to comment on:
> many new plugins for the base-level things
GP mentions Helm and Ivy. These "completion frameworks" are editor-wide, full-blown rich and ergonomic UI enhancements, each with its own philosophy. Each one is an island though - you have to buy into their philosophy wholesale[0]. At some point, however, the community identified the various paradigms and patterns in those completion UIs/frameworks, and where they map to existing core Emacs ideas, and a new breed of libraries were born - Corfu, Vertico, Embark, and many others, each of which provides a single piece of the equation, and deeply integrates into built-in Emacs APIs whenever possible. As a result, you can now mix and match those libraries to replicate something like Helm or Ivy, that works better, is more flexible, and more friendly to code against.
This is perhaps less interesting for casual users, but it means an important philosophical shift in community, towards more targeted and composable plugins. For casual users it just means more powerful, stable, better cooperating plugins.
--
Okay, I lied. Let me talk about Org Mode. My favourite little feature, which I miss from literally any other software I'm using (like Microsoft's To Do I've been using lately for ad-hoc personal things[1]), is `org-extend-today-until`. Made by and for people like me, who always find themselves reviewing plans after midnight, it's a variable you can set to make Org Mode extend "today" past midnight. See: http://doc.endlessparentheses.com/Var/org-extend-today-until.... I set mine to 3 (as in 03:00).
Flexibility of Emacs means people just implement random stuff like this in the first place - features not relevant to Minimal Viable User, but very useful for a subset of users.
--
[0] - Though in Emacs land, this just means it's only tad more annoying to extend, modify or repurpose pieces of those frameworks.
[1] - Org Mode is the bestest, but still has so-so mobile support; currently MS To Do is just the least annoying tool for private planning on the go.
Now mark them as TODO items, with one being in-progress:
* TODO One ..
* TODO Two ..
* INPROGRESS Three ..
In Emacs you can then view your calendar, or org-agenda, which will have the current day and all items on it.
You can add a deadline to an item, and it will jump to that day on the calendar/agenda.
Can you keep track of simple items in google docs? Absolutely. Can you make them appear on a google calendar? No. (Yes I realize Google has todo-app, and that does. Even with recurring scheduling, but that's not tied in to google docs either)
Easy examples, any source that is delimited with `#begin_source language` will have whatever the editor would do for `language` in the delimited section. Searching the file is exactly like searching any other file. Committing it to source is trivial, as it is a somewhat normal text file.
That last actually shows how emacs can be treated like what a lot of folks use jupyter for. With the main difference that the "on disk" form is a somewhat normal text document using fairly trivial markup.
Eglot is a package that works with LSP (Language Servers). There is another one called lsp-mode.
Eglot is integrated within Emacs over lsp-mode because it was specifically made to use existing hooks that Emacs has.
What this means is that you'd use the base Emacs command for finding a reference, and Eglot will populate the source for that command.
Whereas with lsp-mode, it has it's own command you'd run for finding reference. I do think you could also write code to have lsp-mode populate Emacs commands.
That being said, my impression is that Eglot has better integration with Emacs - which is why it became part of Emacs core.
(It's been a while since I've reviewed the Eglot vs lsp-mode discussions, so anyone feel free to correct me).
Use-package is a package for setting up your Emacs configurations. It allows you to place settings for individual packages in nice little sections. It's mainly used for organization but you also gain a plethora of options as well, like deferring to load a package until you open a file that requires it.
You also don't technically need to configure Emacs by hand by writing code lines. You could always do M-x customize and change settings that way. Emacs will auto-generate code from that and place it at the end of your configuration file.
That being said, this becomes quite messy to look at - so people prefer to use M-x customize to find the setting they want, and then they write it by hand in their config.
A big usage of use-package that I love is that you could specify specific settings that tell Emacs to enable it through M-x customize. If you don't know what I mean by that - that is totally ok. You'll learn about this more if you ever dive into Emacs and want to configure your own settings.
I don't know what plugins OP had in mind, but for me at least, a bunch are usability improvements that make the Emacs environment easier to program. use-package, for example, provides a nice way to programmatically install and configure all the plugins you need. My emacs file config file now is self-bootstrapping - I drop it on a new machine, fire up emacs and everything is there and configured as I like. You could do this before, but it was more work and I had never bothered previously.
In this deeply nested Reddit comment, when someone said: "Imo emacs shines when editing, not writing.", I tried giving a few practical examples of how I use Emacs for writing plain text. I'm just gonna list the use cases without specifics, you can click the link below and find details of each package if you're interested. Note that this is a single aspect of things for which I use Emacs. Many other possibilities are abound.
Emacs is incredibly incomparable for writing. I don't even try to type anything longer than three words in anything else. I always try to find "edit-with-emacs" feature wherever I go - I built one for Mac, then I wrote one for exwm, then I did the same for stumpwm . I recently started using AwesomeWM, and now I have it there too. If I'm ever forced to work in Windows, I can promise you, finding a way to edit with Emacs would be the very first thing I will try to solve.
When I'm typing in Emacs, I have:
- Spellchecking. When I mistype the previous word, I would just tap the comma twice, and it autocorrects it. If I need to actually insert comma, I'd use comma and space (which I always do anyway)
- I have thesaurus.
- I have Google Translate, for which I don't even have to switch the keyboard layout, meaning if I want to translate from Russian, it would automatically switch the layout to 'ru' and back to English when it's done
- I can check the etymology and definition of any word.
- I can count the number of sentences, words and characters.
- I can keep an eye on my writing with writegood-mode, it can look for duplicate words and use of passive voce, and perform Flesch–Kincaid readability test.
- Until recently, I was using Grammarly to check the text, these days I simply send it to chat-gpt, and it even shows me the diff upon completion.
- I can toggle "distraction free, zen mode", for writing.
- I can launch a web search on any selected text.
- There are various ways how you can preview the markdown.
- You can write helpers like wrapping a region in a collapsible section, or create "code sections" without any hassle.
- You can edit the code sections in their language environment, with syntax highlighting and REPL.
Eglot and use-package allow Installing packages from source, allowing you to easily switch between bleeding edge, tagged versions, and contribute changes.
I think the hard part of programming, or programming related things, is environment setup.
Even with things like Docker, you can still run into SO many issues.
Programming by myself is always easy.
Programming within a company can be difficult because of this. There are definitely places out there that make environment setup super simple. Even then, you can still run into something that hasn't been encountered before.
Also just slow, fragile environments once they are set up.
At a previous place I worked, tests would be slow, builds would frequently break and you had to recite the correct incantation of commands to fix them again.
We had a common saying: whenever someone would say their build process is broken, we'd say "ah you must have pulled master".
Environments that are fast, stable and get out of your way are a godsend. Unfortunately when working in a monolith, everyone's special build changes are shared with everyone else. Then those build changes break things.
It's worse when you get heavily invested in 3rd party APIs or some forms of "serverless." If you don't think about having a local environment ahead of time, you may never have one. Productivity drops like a rock. I've seen guys editing AWS Lambdas in the console. It's incredibly unproductive.
I used to have a bunch of old technical books. My university's library would give them away, and I'd pick them up for novelty.
I ended up getting rid of most of them a while back, since I carried them with me from move to move. Now that I'm in a place that I'll be in for a long time, I really miss these books.
The coolest one I saw, but never picked up, was a book entirely dedicated to creating a chess engine. It was published years ago at the time I saw it (seen 2013, published in 1980?), but I doubt the basics have changed all that much.
The art and graphics in old books are great as well. I always like to think of older albums, books, and movies as a snapshot in time. It's fun to see a snapshot in time in such a specific niche.
Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code.
In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs.
For example, think about doing a "Hello World".
In Emacs, you just open init.el and place `(message "Hello World!")`.
In VSCode, you have to follow a whole set up for an extension [0].
This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly.
If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.
I really miss those kinds of books now. This book distinctly had color and screenshots of all the recommended changes to make.