I works differently from i3: you predefine screen zones (possibly overlapping), and then just move your windows between them with keyboard shortcuts or middle mouse button.
IMHO, covers the problems you mentioned. You can have:
- multiple windows in one zone with normal Z ordering
- an improvised taskbar for any zone or a group of zones
- zones that stack windows vertically or horizontally or tile them in a fixed grid
- zones that dynamically adjust size depending on contents
- windows of certain app opening directly into a certain zone
- floating windows
- widgets (the easiest one is simply showing text from a URL with XQuery or JSON parser)
- customize the hell out of it with WPF
It is now one of a few things holding me back on Windows: until I have it or something else very similar running on Linux, I have no replacement to manage my 3 screens the way I like it.
long time lurker, finally qualified to comment on a post.
I've been with amazon for 8 years (still an employee) as a software engineer. I've concluded that your experience at amazon - both work life balance and technical - is entirely dependent on your skip manager and your org.
I started with Amazon in the bay area. When I joined we were still in the very early days of our project. The work was awesome, and it felt like we were creating great things. Unfortunately, the ops burden (oncall) became way too much for our team to handle and the quality of life plummeted. My existence during those days was pure pain. From there I relocated (through Amazon) to Seattle to work on something else. I did the move with the promise that I'd immediately get to work on a cool project, but I ended up sitting around doing nothing for months. I didn't even have a desk. Once the project finally started though, things become great. Both of these teams had different VPs, and the cultures of each org were very different as well. My experience in the bay area started off very positively, and then become extremely shitty. My experience in Seattle started off extremely shitty, but then it turned into the most fun 2 years of coding I've done.
Additionally, different orgs do things differently. AWS does things different from how Alexa/Retail/Music/Movies/etc do things. A good example of this: Twitch isn't fully integrated with all of Amazon's internal systems (see recent news for reference). Some teams don't have oncall rotations, other teams have brutal ones. One of my previous directors used to do bi-weekly (once every two weeks) fireside chats. I haven't even met my current director, and I've been under him for a year and a half.
If you're entering the company from the outside, you might very well be walking into a dumpster fire of a team. If you're inside the company, it's really easy to spot which teams are garbage and which ones are not. Below is my guide:
Red Flags:
- No nearby principals (no tech guidance at the director level)
- Too many principals (bureaucratic arm chair engineering hell)
- Average tenure of engineers on the team is SDE1 (trash code)
- No PRFAQ/BRDs (projects have no north star, scope is all over the place, dumpster fire product team)
- Ops burden is too high (you can check a teams ticket queue on SIM, high ticket count = bad oncall)
.... and many more ....
Doing team switches are pretty straight forward as well (ymmv). Once you're in the door at amazon, do your research and determine whether you need to switch teams ASAP. You can search any engineer's username and look at what code they're contributing. It's pretty easy to investigate the code base you'll be working on in advance of joining the team to determine its health.
Regarding tooling, amazon does and doesn't have great tooling. There are things like Pipelines, CR/Crux, Sim/TT, Apollo, iGraph, etc that are actually world class tools and don't really have any rivals out there (yet!). Then there are other things like people wanting to fork bootstrap and react so that they can rebrand it as an amazon version.... In one of my early teams, I saw the SDETs (test engineers) metaphorically go to war with each other to write the best end-to-end integration test framework. There were four frameworks in the end.
Regarding the leadership principles. Those are predominately tools to be used during the decision making process. There is this concept called "one way door decisions" which would be any decision that is made such that the amount of effort needed to undo that decision is not feasible. Basically if you take that door, you can't come back out. When faced with a one way door decision, you use the leadership principles to decide.
Are you on a fixed timeline because your deliverable is tied to AWS Re:Invent? Then you need to optimize for Bias for Action and Deliver Results.
Are you about to create a core platform service that many many teams will build on? Obviously you need to optimize for Insist on the Highest Standards, if not you screw over your org for years.
The leadership principles contradict each other, but that generally gives you an idea of what's being gained and lost in the decision making process.
For software engineers, I would not exclude amazon as an employer just because you read some stuff online. If you can get in, do it and stick around for a year or two at least. The amount that you learn in such a short amount of time is significant, and you can take that experience with you anywhere. If you're having a bad experience at Amazon, remember that the company is massive. You can switch orgs and it'll feel like you just changed companies (only the tooling is the same).
Final thoughts: don't ignore your mental health! I have never had a manager actually ask about my mental well being before. I don't think that culture is actually fostered at all at Amazon. Use your vacation time if you have it, switch teams if you need too, or just straight up quit.
I don't understand why people insist on this shoehorning either.
It's like some obscene tribal topos that refuses to die.
KDE 1.0 came out in 1998 - 23 years ago (O god I'm old).
The discussion of "Linux to replace windows desktop" is over two decades old.
In computer age this is something geological. It's like... well, Macintosh came out in 1984. Xerox Alto came 1973. If we go back 5 years we reach Englebart's Mother of All Demos in 1968 which I think can be considered the intellectual precursor of those.
So there is 5 years from a tech demo on high-end research platform to a (more or less) commoditized consumer offering - even though Xerox had no idea what to do with it. Steve Jobs visits Xerox 1979 and five years later they deliver Macintosh.
So, with engineering talent PLUS business drive they copy the idea, implement their own hardware and software stack and are instant hit (well, let's say for the sake of this discussion they are a hit).
In FIVE years.
Linux is trying to copy the software stack, of an existing platform, and has been "attempting" this for two decades.
This is not an engineering problem. This is not a community problem. It's a "lack of business interest problem".
Honestly, the Linux desktop is quite usable. I'm quite sure two decades are enough for the open source software stack to find some local optimum for the desktop offering.
But really, copying and supporting a continuously moving target needs real capital and real business drive to sustain the boring, mind numbing support work that is needed to actually sustain an industrial quality platform.
Linux is fantastic in lots of things.
I'm not sure reverse engineering Windows stack on Linux is very effective way of spending our civilizations engineering resources.
I appreciate masochistic Rude Goldbergish feats of engineering as much as the next geek, but I just don't see the value of individuals detached from the corporations that are implementing the master stack trying to reverse engineer everything on top of a third party platform.
Native Linux support? That would be nice. Native drivers and all? That would be nice.
If it works for someone that's very cool and satisfying - but I still think reverse engineering based gaming stacks for modern platforms that are alive and well are not perhaps the best way to spend engineering effort.
As a FAANG engineer going on 9 years now, let me address the usual rebuttals:
- There is a selection bias. Nope, this is pretty much accurate.
- These aren't real. Yes, yes they are.
- Self-reporters are lying. Maybe some do but these numbers are pretty accurate. If anything, I question Lyft and Airbnb as such outliers. I wonder if this factored in Lyft's post-IPO stock performance and makes unrealistic valuations of Airbnb's RSUs/options. But for any listed company, these numbers are accurate.
- You have to work incredibly hard for this compensation. no, you don't. In fact you'll typically find significantly better work-life balance at a FAANG than a startup.
- These numbers are inflated by years of stock growth that is unlikely to continue in the future. This there is some truth to but not as much as people claim. Amazon, of all these companies, builds in expected stock growth into their initial grant valuation (which I think is total BS; if any Amazon recruiters are reading this, please stop). But I know what offers new hires can get pretty accurately so at current stock prices as a new hire these numbers pare pretty accurate.
- Newer offers are likely to be less. False. If anything, initial offers continue just climbing such that anyone who is interested in maximizing their compensation should probably move companies every 3-4 years, especially 4 if you don't get an additional grant after your initial grant has fully vested.
There are some things to be aware of though and these can make it nontrivial to compare competing offers. Some examples:
- Most FAANGs have a 25/25/25/25 vesting schedule. Amazon does not. It's vesting schedule is 5/15/40/40 with a vesting signing bonus in the first 2 years to (partially) compensate for this.
- Amazon, as noted earlier, assumes stock price growth in their offer.
- Amazon (noticing a trend?) has vesting on 401k matches that can take 2-3 years. Most FAANGs do not.
- Anything less than a 50% 401k match is below market.
- Some FAANGs have caps on 401k matches. Some don't.
- I think the most generous 401k match I've seen is Google's at 50% of your contribution with no cap or vesting period or 100% of the first $3,000 at year's end, whichever is higher. The really nice thing is because there's no cap you get it immediately. It's fairly common to get your bonus in January, put it all in your 401k, get your 50% match and you're done for the year.
- Some offer the ability to make contributions into after tax 401k (Google "mega backdoor Roth" if you're interested in this). This is potentially huge beneficial. You can use it to invest money you can withdraw at any time at no penalty but the investment returns are tax free. If you withdraw the returns (not the initial investment) prior to being aged 59.5 you pay taxes plus a 10% penalty, however.
- Vacation days vary but 4 weeks (20 days) should be considered the norm for the US (30 for Europe/Australia).
- Some companies (eg Google) start you on less vacation days but you get more with length of service.
- Unlimited time off is bullshit. Think of this as no time off.
- Health insurance can differ but I imagine pretty much all FAANGs at this point have good health insurance. The gold standard is probably Kaiser for CA residents.
- Some FAANGs have a 1 year cliff. Some do not (eg Google, FB).
- Vesting schedules can vary. Some are monthly, some every 3 months, some annually. Try to avoid anything less frequent than once every 3 months. It can create bad incentives for the company to get rid of you before a big vest date.
- FAANGs will give you performance-based RSU grants annually. The time of year can vary. The eligibility can vary. For example, Google gives you a refresh grant at, after Q2-Q3 calibration (based on your previous two halves). And I believe in recent years it changed that if you joined that calendar year you aren't eligible.
- Because of refresh grants and your initial grant running in tandem, years 2-4 can often be your most lucrative. If you don't get promoted or an additional grant you can get significantly less compensation in year 5. Why these companies let people leave because they won't give them additional equity rather than competing for a new hire is beyond me. But they do.
- Because of the inflation in initial offers, a new hire can often have a significantly better offer than someone who joined 3 years prior. The veteran may only have higher total compensation because of refresh grants and/or stock growth.
- FAANGs tightly control salary within bands for a given level. Going beyond this is unlikely to happen however there is FAR more movement on RSUs in an initial offer and/or signing bonus.
So this is all another reason of why from a financial POV working for a startup is--how should I put this?--suboptimal. Your equity is probably worth nothing (even if you get acquihired, liquidation preferences probably mean all non-founder stock is worth $0). The hours are worse. The benefits are worse. There may be reasons to do this that aren't financial (as a non-founder) but personally I'd suggest people use their most productive years to ensure their financial independence and then chase whatever moonshot tickles your fancy without the pressure of having to pay for food.
> As the author, I don’t think that it should be banned, but I agree that kids should not be forced to attend.
Here is the problem: high school is mostly not meant for those of us who wound up on HN.
My father taught English for almost 4 decades in a US rural school district. His comments were:
"I'm not really here for the good students. They'll do fine no matter what I do, so my job for them is to keep them engaged and moving forward. All I have to do is not kill their motivation."
"I'm not really here for the worst students. I can't fix simply not doing the work or reveling in being stupid. I can't do much to fix a student's terrible home life other than providing a sympathetic ear and space for a little while."
"I'm mostly here for the average students. They don't want to be here, would rather be doing anything else and will do as little as possible to skate through. If I can push a few of those to care just a little more and have just a bit of internal motivation, I've done a good job. For the rest, I set the average bar to the point that they have to learn what I want them to to get the grade they need to."
"And I'm really here for a few of the below-average students. This is probably the last chance before they slide into being useless. Most of them have a bit of smarts, or they'd have slipped into the worst category long ago. They probably hang out with the wrong people. They get harassed if they accomplish something. Their home life is deteriorating. If I can reverse any of these, I've done a really good thing."
If you get a job in customer support at Amazon there is literally no way to get a 'promotion' to a dev role. It's different parts of the org, and you're tarnished with being a CS person. Why? Because it's signaling - people who can do eng roles at Amazon don't take CS roles so they don't bother mining to check on the rare chance someone in CS can.
In your replies you say "I haven't lasted anywhere longer than 2 months. I contribute a lot and then quit after I feel like I'm not getting appropriate compensation."
If your resume reflects that you've bounced around after a few months as a hiring manager I'm not even going to bother offering you an interview.
You also said your were home schooled and many people here have commented you might have social skill issues. I am not a doctor but I wonder if you have delusions of grandeur around your abilities which is creating a miss-match of expectation leading you to quit jobs you need to tough it out in. Or you have dyslexia or another learning difficulty (I have dyslexia, I quit school, never went to university, did many shit jobs to work my way up, it took years and years)
I would suggest you find someone who is an actual hiring manager to give you a mock interview and analyze their feedback. If you can't find someone closer in your circle, I'll give you mock 30 minute interview (I've hired countless engineers, designers, PMs and other roles in the last 20+ years)
If you want a career in tech you do need to get out of the wrong swim-lane, which a CS role at Amazon is the wrong lane as it will never convert to where you want it to go.
Its amazing to me how people always want to analyze everything in terms of the Smartphone market.
This is nonsense. It simply doesn't make sense. They are completely different industries, completely different players and very different geopolitics.
One is a tiny consumer product for your pocket that gets replaced every 2-3 years that is easy to transport, the other is a huge consumer product people often keep for 5-10 years that is hard to transport.
Sure, both have Li-Ion battery but again its totally different. In a phone the battery is a small part of the overall price, while for a car its a huge factor in the overall price.
Tesla is not like Apple, in many ways and Volkswagen is not like Samsung in many ways. Tesla is like Apple in some ways but not in others. The same for VW.
The car market simply does not operate like the cellphone market, the role of software is different. The geopolitics are different, every 'Western' government that has a car industry is bent on defending it. Even outside of that, producing cars is such a massive capital intensive business that hits your cash-flow localization of production is basically a requirement for the biggest players.
Tesla is amazingly successful and have a strategy of strong vertical integration. They have a tech future centered image promising fun, good performance and environmentally friendly. They are building up localized production of a few models that they want to sell in very high numbers globally. They are hell bent on increasing battery production and on solving self driving.
Tesla will continue to grow at a quite rapid rate year over year and no matter if other EV come into the market that will likely not destroy Tesla growth anytime soon. Tesla is one of the largest costumers of all of the major battery companies and is turning itself into one of the largest battery producers as well. That alone is a huge advantage as with the continuing cost curves, it is likely almost all EV that can be produced, will be produced and will be sold.
They have also smartly invested in charging network and are an omnipresent symbol of EV along all major routes in the developed world and they are expanding that network every day.
VW is the first really big monster company that has fully realized not just that it needs to be done, but also that all the talk about how the car industry talk about how easy EV were and if they wanted Tesla would be crushed is not the case. Going into EV on large scale is breathtakingly difficult and VW has mobilized the whole company, made huge investment both in suppliers both now and future suppliers, they have transform their internal plans (of all their companies) and are trying to execute. They are doing quite a good job along most levels.
VW and Tesla will both be large parts of the EV future, whatever will happen in terms of mobility service, self-driving and so on.
There are open question for VW about how to transition such a large company but Tesla also have open question about continuing to execute a massive growth strategy. Both companies are set up for success if they continue to execute at a high level.
> Could you elaborate on this? I'd say repl based interactive programming is one of julia's greatest strengths, and avoiding the repl is probably setting yourself up for pain.
With REPL you have an invisible global state, can't reproduce what you have done, changes earlier in code path don't propagate to results, you don't have documentation of what you did.
It's for me really like trying to write a book by dictating. Except that you're dictating to somebody who's gonna give an independent summary of it to a third party and never gonna write down what you dictated. It boggles my mind how people can work like this, but they probably get hooked to REPL from the first tutorials and just don't know better.
I'll look into DaemonMode.jl. Not a fan of using a daemon (and I'm guessing there will be problems with e.g. interactive plots), but in the short term I'll take anything that could make Julia programming tolerable.
I 100% agree that disastrous codebases are every bit as likely in other languages. But it somehow hurts more in a lisp.
I think that the syntax really is the culprit. In a language like Java, the Byzantine syntax and semantics enforce some minimum level of structure on the code. It's not much, but it's something, just enough to give an experienced programmer a few extra heuristics they can use to make sense of what they're seeing. Even some things that normally drive me nuts about Java, like the way that there's no standard way to call an anonymous function (because the invocation is done through a method whose name is allowed to vary) end up being useful bread crumbs when I'm reading somebody else's code.
In a Lisp, though, everything looks more-or-less homogeneous. You can memorize the names of special forms, but, beyond that, you can't quickly tell whether some thing you're looking at is data, a function, or a macro, or what. It all blends together into a disorienting fog. You need to go trace its provenance to see how some new value is defined or constructed before you can even tell what kind of thing it is. (This, tangentially, might be a great argument in favor of lisp-2, though I haven't spent enough time in a lisp-2 to have an opinion that's worth beans.) It may, in the grand scheme of things, be only a small reduction in what you can assume without careful study. But, in an unfamiliar codebase where you don't know much to begin with, every little scrap of knowledge counts.
It all points to an insight I should have had 20 years ago when I was working in Perl: Features that make a programming language pleasant to write tend to make it unpleasant to read, and vice versa.
There's a lot of things that day to day businesses users will need that Slack (and the clones) provide but IRC basically can't. And they're kind of way more fundamental to the basic interactions than your idea of adding video calls.
- User authentication, preferably via some semi-standardized form of single-signon (e.g. SAML, or maybe OAuth).
- Users being able to receive messages even when all their devices are offline.
- Users being able to connect from multiple clients at the same time, with good UX. With IRC, people doing that will have to have a separate nick for each client they connect from. And people who want to @ them or /msg them will need to know which of the near-duplicate nicks to actually choose. Choose poorly, and your message might be sent to a device where it won't be read for hours even though the recipient really is actively online.
- State sync across the clients. If I've read some specific messages on one client, they should not show up as unread on my other clients.
- A consistent user experience. In IRC there's no reliable cross-client way of tagging a message for the attention of some set of users. Sure, clients will do various levels of nick highlighting. But the exact patterns will vary between clients, and the sender can't even know whether they got the format right since the decision on the highlighting happens purely on the receiver's end.
And that's not even getting into the things that IRC can reasonably do, but that are incredibly kludgy. Say history search in a channel. No organization wants to run channel logging bots, and no normal user wants to go to a totally separate service to do a search.
> "I would suggest that the users here are probably some of the best suited in the world to help smooth those rough edges"
How would you get around the problem that many vocal Linux users think easy-to-use software is for weak losers, and consider difficult software a sign of manliness and an identity, even a religion? This is like saying Buddhists would be the best suited people to disarm gun-lovers, without considering that said gun-lovers don't want to be disarmed, and see pacifists as weak and unmanly.
Threads about recycling have started to pile up just like the recycling has. A list of the major ones is below (but only with "recycl" in the title—if you find more, let me know!)
Given the current picture, perhaps most interesting in retrospect is this 1996 article (which apparently set a record for hate mail) and its sequel from 2015:
>Databases we have today aren't designed for the kind of consumer applications we use today.
Yes they are? Relational databases are very good for consumer applications with relational data. NoSQL databases are good for everything else.
>Data(bases) should be owned by users, and synced with friends and colleagues.
Why? You use words like should - why SHOULD it be that way? Users are able to create / buy / rent infrastructure to manage their own data - and yet they don't ... why?
>Shouldn't be centralized in this fashion. Data(bases) should be owned by users, and synced with friends and colleagues. So instead of a single centralized database, we need a million tiny little databases which are synced with peers.
Nice in theory (maybe). The problem is that centralization provides enormous quality and performance metrics. Distributed systems are resilient, but slow, and require a lot of care to maintain consistency and integrity of the network. Take email as an example. It took us 20 years to get email spam somewhat under control and a major part of that was creating a centralized infrastructure (from using centralized email providers to third party whitelists and blacklists). It's gotten to the point where hosting your own mail server is a huge hassle and pretty much impossible for regular people. I spent about a week trying to figure out why our Office365-originating mail wasn't being received by one of our customers. It turned out, their mail provider matched a particular phrase in our automatically-inserted disclaimer and completely rejected the mail.
Decentralized systems also make controlling your data all but impossible. If I want to remove my data from Facebook, that's the only entity that I need to deal with and it's relatively easy for regulators to set sound policies in place. In your distributed system, once your data leaves your node, you've lost all control all of it forever.
I'm Swiss. US pro-gun people (ab)use our liberal gun rights to proof their point.
But there are huge differences:
1. Concealed and unconcealed carrying is not allowed. You have to transport your weapon in a very specific way, without ammo etc. Also anyone with a gun in public would trigger a police intervention within minutes.
2. Active military personnel are allowed to stored their gun at home, but almost nobody does that. Those who do get 5 bullets, in a sealed box. They're not allowed to open it, except in war. The seal gets checked every time you go back for service.
3. Storage of legal weapons at home is very strictly regulated. Loaded guns are basically forbidden, ammunition has to be stored separately etc.
4. If you don't have a very clean history, it's almost impossible to get the right to buy guns.
5. Automatic weapons are illegal.
PS: Those "facts" are from my memory, as I don't live in Switzerland anymore. Fellow Swiss users, if there's anything wrong please correct me.
That's not the point. They are trying to not IBM themselves.
They and the clones won the war with IBM in the 80s and 90s because IBM was worried about things that didn't matter: they wasted time with things like an operating system CP/X86 that ran DOS and 3270 emulators to their mainframes on top of a GUI system called mermaid (3270 PC) while Microsoft was writing Windows 3. Oh yeah did I mention some configurations cost $20,000 each? some configurations cost $20,000 each.
Because IBM wanted to secure its AS/400 minicomputers, mainframe, and microcomputer line and make them interoperable, as if a PC user sitting in their den would be connecting with $500,000 or so of other IBM machines, everyone else ran circles around IBM. They kept up the "whole kitchen sink" system way way past its due date.
This also happened to DEC, which responded way too late in the game to be relevant, SUN, SGI, and Wang. And it may eventually take down Oracle.
So they're intentionally taking an uncommitted, decoupled approach. I'm paying Microsoft as a result. I pay GitHub and Azure bills every month and run exclusively Linux.
They can't sway around as a monopoly like they could in 2000, once Ballmer left things changed rapidly. It's not going back. They have effectively zero cloud software (database/operating system etc), effectively zero mobile presence, and most people don't really like Windows.
In a tightly coupled stack you're only as strong as your weakest link, and MS has a bunch. Their biggest risk now is to HP or GM themselves; basically gobble up a bunch of things, blend it into indifferentiable blandness and collapse while waving a giant sceptre labelled "greatest company of 30 years ago" (HP bought DEC, Cray, Tandem, Apollo, Convex, 3Com, Phoenix, Palm and SGI and did effectively nothing with them beyond slapping an HP logo on their final pre acquisition product line and then just rode it out without any followup. HP knowing only how to fumble the ball every time for 20 years is why big business switched to Linux. HP took all the alternatives behind the barn one by one, cut them a fat check and then shot them. Simply crazy)
I'd suggest that the vast bulk of software is written for inhouse use and B2B use, not consumer use. The impression you have would boil down to sample bias.
This is simply a reflection of the "structure of production": for any given consumer product, there is a vast graph of exchanges and transformations that lead to it. Most of the inventory and money is not passing between consumers and consumer companies. It is in the structure of production.
Consider: manufacturing is not instantaneous. Primary resource production is not instantaneous. Transportation is not instantaneous. Tertiary services are not instantaneous. Per Little's Law, average items in a system = average throughput * average item latency. The consumer market is the throughput. The structure of production represents a multiple of the consumer market.
The reason we overweight consumer brands is because they are consumer brands. Within each industry and niche, everyone knows who the leading firms are. But outside the niche, nobody knows that a) the firms exist or b) that the niche exists.
But all of us are in the consumer market, so we all know about consumer brands (they literally make it their business to ensure this is so).
Every journalist can write about a consumer brand. Every reader can read about the consumer brand. So on sheer volume, consumer brands are vastly overrepresented in the media relative to their total share of the economy.
So even a relatively small lead in consumer-facing firms will seem much larger than it actually is. B2B is a massive segment in the US software market. But it's the invisible dark matter of our industry: it constitutes almost all of the mass in the software universe, but few folks realise it's there unless it's pointed out.
That was exactly my experience. The defaults are so ergonomic, and the configuration scripting so utterly sane, that I have no desire to go back to bash.
For example, do you want to make an autoloaded function named "foo" that comes into existence the first time you call it? Write a file named ~/.config/fish/functions/foo.fish, and inside it define a function named "foo". There - done.
Follow this pattern to make a function named "fish_greeting", and it will run every time you launch a new fish shell. Want to make a custom prompt? Write a function named "fish_prompt". Decide you want one of those fancy prompts where the timestamp is displayed on the right side of your terminal window? Make a "fish_right_prompt.fish" file and put in it:
function fish_right_prompt --description 'Write out the right prompt'
set_color 666666
date +'%Y-%m-%d %H:%M:%S'
set_color normal
end
After years of customizing bash (and later zsh), this is a breath of fresh air.
I don't think luck is as "random" of a factor as much as most people think it is. Checkout "Luck Factor" by Dr. Richard Wiseman.
I do think there are a lot of things you can due to get probability more on your side:
- Keep your eyes open for opportunities and look for the upside ("be optimistic" is the woo-woo version), but it's been proven in experiments that you'll catch things others won't
- Only keep friends around you that actually support you. It's really hard to try to make life changes when people are constantly telling you you can't or shitting on your parade.
- Start making analytical choices. Certain fields pay more than others. Certain businesses treat their employees better than others. A lower position at a better company will increase your probability of "bumping" into those people who might be life changing.
- Learn about probability (Fooled by Randomness is a good start). If you constantly expose yourself to more chances of success, _odds are_, you'll start to find more of it.
- a CPU emulator
- a fully functional NTP client
- a skeleton grep implementation
- how decimal numbers are represented in Rust
- developing your own format for representing numbers
- a memory scanner so you can learn how game cheaters cheat
- handling UNIX signals
- inspecting binary files for hidden patterns
- an OS kernel + bootloader
- an L-Systems implementation
I don't believe there is a shortcut for "hacking" languages. I'm a diplomat, and currently learning my fourth language to the C1+ level.
When we learn languages, it's a full time job. It was 9 months to learn Mandarin to a B1, 6 months to a C1+ in Spanish, and I'm currently at a B1 in Estonian after 5 months.
There are several things I think are crucial after years of full time study (note: this assumes you're going for professional fluency, not just touring around the country where interactions are largely scripted and predictable):
* There is no substitute for production - you must speak the language with a native speaker (not an app) and talk about topics that are relevant to the kind of scenarios you anticipate. We spend the first several months discussing current events in target language - at first scripted, then later free form. This builds vocabulary and helps fluency. This is quickly expanded to discussing current events in depth and participating in mock debates.
* Give mini presentations - target 3-5 minutes of talking about a relevant topic with little prep time. The difference between intermediate and advanced is the ability to move from discussing only facts to making a coherent argument. Native speakers will often not be able to follow your train of thought without learning to connect cause and effect using structures appropriate for your language.
* Interview native speakers - prepare 2-3 questions about a particular topic and check your comprehension by translating their answers to English. This obviously helps build your comprehension, but also helps to learn to "automate" comprehension while you are thinking about something else. If you can take notes in English while a native speaker is talking at normal speed (and achieving 90%+ accuracy), it will make it easier for you to participate in normal speed conversations.
* Read target language news - this is critical for expanding vocabulary and learning colocations - knowing what verbs are used in particular contexts (e.g., do they say "I talked with X" or "I talked to X". Do they say country X shot, launched, or threw a rocket?)
Bottom line - language learning is not just about the number of hours you put in. The quality and type of practice you do matters a lot. You aren't going to be fluent via Duolingo alone. You need to put in the time using structured practice with native speakers to really learn anything.
i've been doing biological/biomedical research for about 20 years now (god, that's a scary thought...)
I don't think that biology is well modeled by "being a meat computer", in general, but as far as the analogy goes ... :
What we are debugging is 4.5 billion years of grad student code in at least a few dozen languages, with no documentation, method names that are outright lies, no separation of concerns at all, the worst spaghetti you've ever seen, god-objects everywhere, no separated state at all, spooky action at a distance, the whole spiel.
We don't have a reliable debugger, you can't trace the stack because the stack changes when you look at it, and the entire thing is running all the time and mutating in a really nasty feedback loop with you.
Oh and there is no software, there's only FPGA-like firmware that reprograms itself all the time and can decide to add or remove logic units basically whenever, or wrap itself in duct tape and baling wire.
I've never come across any indication that Dijkstra wrote actual code (in the sense of something executing on a computer) after 1970 or so. The algorithms in the EWD notes are all written in ALGOL style pseudocode.
Dijkstra was the CS equivalent of the Patent Law concept of a "Non-Practicing Entity", which gave him great liberty to troll all programming languages without exposing his own choices or designs to corresponding scrutiny.
The book he references (https://www.amazon.com/Making-Prince-Persia-Jordan-Mechner-e...) is a collection of journal entries he wrote while making the game. It's been about ten year since I read it, so the details are fuzzy, but it's a very raw retelling of the process of making a game basically entirely alone and before the internet. I'd strongly recommend it to anyone who writes software.
And like any other learning algorithm free-play has "real-world" information, free exploration, creativity. The vast majority of which is very slowly learning what not to do. Most times, that's all that happens.
Cultivation, when perfectly executed, provides about 50-50 what to do and not to do. Cultivation results in far faster progress. In deep learning, in reinforcement leearning, and in humans. (reinforcement algorithms are worse actually, they will simply barely make any progress at all until they see a positive example)
The problem is that this is really, really not what people want to hear. Free play, freedom to explore, ... results supposedly in happier children, more fulfilling lives, creativity, ... Except ... no it doesn't. It's an empty meaningless long string of failures slowly sapping strength until you fail, with very rare example of great success. It's spending seed corn on a lottery ticket.
This is made more difficult by the observation that, yes, eventually, if you do climb to the very top of society you'll be playing the exploration game, without any cultivation, regardless of whether you got there with exploration or cultivation.
The iShares S&P 500 ETF (quote: IVV) has an expense ratio of 0.04%, is offered commission-free on many brokerages, and based on some quick calculations, follows the official index to within about 0.5% returns. You're right that it's not completely "free", but the total "cost" is only about half a percentage point, meaning you can pretty closely follow the index in the long run with a single ETF purchase. I don't know what could be easier. :)
For Windows 10+ I made Stack WM: https://losttech.software/stack.html
I works differently from i3: you predefine screen zones (possibly overlapping), and then just move your windows between them with keyboard shortcuts or middle mouse button.
IMHO, covers the problems you mentioned. You can have:
- multiple windows in one zone with normal Z ordering
- an improvised taskbar for any zone or a group of zones
- zones that stack windows vertically or horizontally or tile them in a fixed grid
- zones that dynamically adjust size depending on contents
- windows of certain app opening directly into a certain zone
- floating windows
- widgets (the easiest one is simply showing text from a URL with XQuery or JSON parser)
- customize the hell out of it with WPF
It is now one of a few things holding me back on Windows: until I have it or something else very similar running on Linux, I have no replacement to manage my 3 screens the way I like it.