Of course, he left out the fact that the $40,000.00 USD worth of computer time was stolen from a US government owned computer on loan to one of his professors. He didn't actually PAY $40k USD or even raise funds to cover the equivalent value of the stolen computer time. Gates is a thief, and this was just his first big heist. I was always of the opinion that he US government should have gotten a cut of MS BASIC since it couldn't have been built without the modified emulator handling the ALTAIR 8080 assembly instructions.
Bill & Balmer didn't even have an agreement with Seattle Computer Products when they pitched it to IBM. They waltzed in, lied & said they HAD IT and they could SELL IT knowing it could go into millions of computers. Then, they bought it for chump change from SCP. SCP was a tiny nothing of a company.
It's like finding a homeless guy with a stamp collection & buying his Inverted Jenny for $1,000 USD knowing damn well it's worth over $1.5M USD (https://en.wikipedia.org/wiki/Inverted_Jenny). Is it illegal? No. Is it greedy and cruel for no good reason? Absolutely. Did it help SCP? Sure. Just like it helps the homeless guy to have a thousand dollars while you keep $1.5M simply because you could take advantage of him and there was nothing he could do about it.
Again. Gates is a liar and a thief. It's probably damn lucky for him Epstein "hung himself" in that jail cell. Otherwise, we'd probably have proof a few more choice names to call him as well.
1 - Correction: writing late, typo - BASIC should have been property of the US tax payers.
2 - It was still pretty novel back then, but "borrowing" computer time w/o paying for it is (and was) theft of services. Like sneaking into a movie theater without paying. It wasn't their hardware to use, it was a critical part of a commercial endeavor. They didn't have permission in advance to use it. They didn't murder someone, but they were a couple of spoilt brats who figured they could get rich by ripping people off. They ripped off SCP (next point) and they screwed over IBM & Digital Equipment Corp. with the OS/2 gaslighting & NT intellectual property theft (case settled out of court).
3 - Gates wired up the deal with IBM then "bought" 86-DOS from Seattle Computer Products knowing very well it was going to be worth millions since people were waiting for IBM to release a PC at the time. SCP made less than a million dollars and had it drawn out in court (from that same article - "Microsoft paid SCP US$925,000 and reclaimed its license for DOS"). He saw an opportunity to play middle man and then shanked SCP.
The general guideline isn't actually an amount: it's 3 - 6 months worth of living expenses. That is, what it takes to cover housing, transportation, food & utilities. If you're "living paycheck to paycheck" that's a problem, because it means 3-6 months worth of paychecks.
Personally, If you're living below your means, I would try to target 6 months to 1 year. Then again, the past 3 years have made me paranoid as hell. Your mileage may vary.
FWIW - I sleep a LOT better knowing I've got a year worth of expenses sitting in a high yield savings account. If I lost my job tomorrow? I'd say fuck it and take at least 4-6 weeks off before bothering to look for a job.
Seattle area is blessed with a wealth of all ages and 21+ barcades. There's a great one less than 5 miles from my house. I've been a pinball fan for years and still play weekly, playing in a local league pre-COVID. About 2 years ago, I saw a machine with my childhood hero that I couldn't pass up buying. A year ago it finally got delivered. I play at home a few times a week. No big issues with the machine other than one dead "flashy" servo that doesn't work and a stuck target that doesn't impact gameplay. I'll get around to fixing them at some point. FWIW - Here's some info on my big toy:
Scrum is training wheels. The time boxes are supposed to make you reflect and improve. Ditch Scrum. Go to Kanban, scope your stories smaller and prioritize bug fixes over all new work until you're not writing bugs. Can't ship code without writing bugs? Improve your skills as a team. Start pair or mob programming. Do TDD to improve your design, testability & maintainability of your code. Start moving towards trunk based development and use feature flags to do REAL CI/CD (hint: using a build server doesn't mean you're doing CI). Code deployment != feature deployment! Strive to "roll forward" your code as much as possible and disable/enable features if you run into problems - learn to not "rollback".
Now of course, since this is HN somebody's going to sneer divisively at everything I just said and tell me it's not possible (despite the fact that I've done this, repeatedly in different organizations in a developer and coaching capacity for almost two decades now). Here's my preemptive caveat/STFU for detractors: the above method only works if you, as developers, have full control & ownership over your application code data, and do your own deployments or are partnered strongly with an OPS team that gives you full monitoring & Read Only access. If your team is working in an environment where you don't actually get ownership over your code and data, this won't work. If management, architects, or egotistical prima donna staff/senior developers "won't let you" pair/mob, do TDD, do trunk based development, or do proper CI/CD, this won't work.
P.S. If you're in an environment where "this won't work" - QUIT! Life's too short to put up with being expected to build software with one hand tied behind your back. These things are often easier to do in medium to small sized companies. These things are often easier to do on greenfield (or at least recent) projects.
No, no. Go right ahead and sink time and money into this sort of crap. Just like every attempt before, it'll generate a pile of garbage that's unmaintainable yet will still manage to poop out ONE single nugget of value: determining what needs to be built after the idiot suits thrashed all around with the 'wonder toy' system. Then, we experienced developers can have a walk in the park while cashing out on contracting rates. Fat stacks of cash simply for replacing exact like-for-like functionality with REAL software and then bring in the extensions the vendor toy systems couldn't. I could do with a nice, easy, early retirement path to pop up in 7 years. Bring it on ;)
You can skip the tar pit of the Scrum Industrial complex (e.g. "here! you MUST take our certificate program!") and the drag setting pointless sprint boundaries and focus on just repeatedly, successfully, ship high quality software. The Accelerate book is a very good starting point - https://www.amazon.com/Accelerate-Software-Performing-Techno...
Yes! This is exactly my point. Having included something as fluff as "Essential Scrum" on TOP of skipping Beck's "TDD by Example" or Feathers' "Working Effectively with Legacy Code" is very regrettable.
Not only why is there a garbage book like "Essential Scrum", why is there no mention of any unit testing or TDD books? If the author is seriously going to plug Martin Fowler's Refactoring book but make no effort to call out any books to help guide in writing good quality tests, I'm starting to have serious doubts about the nature of those "10 years of experience". I don't care if you "buy into" TDD or not - refactoring without test coverage is flat-out "Cowboy coding": reckless & irresponsible.
I feel like the concern here is that we're quickly moving from open ended, content and _capability_ creation era(e.g. I can program anything I want for my PC _WITH_ my PC) to a mere _content_ creation at best and preferably _consumption_ only era of computing. Your iPad doesn't self-host any flavor of XCode that you can build and run iPad programs on.
It seems with a bit of cruel irony that for a moment in history, due to the intersection of affordability and the limitations of computing power, the home computer allowed anyone with the money to the full scope and capability of a computer with "higher level" programming languages. Such that they could not only use available software from others to create content (images, video, audio, text, web sites) but also create _capability_ programs that that made it easy to whatever the limitations of the machine would let them. But as the computer became more powerful, it became "easier" to hide the elements that allowed creating _capability_. We had it for a while, now it seems to be fading away from common view.
This is what scares me. We're no longer becoming true 'computer users'. We're becoming 'digital content consumers'. Companies are fine with that. I'm not.
People can go ahead mod me down for this, but I honestly don't care at this point. Here's the best ways to avoid this:
1.) Quit doing PRs for feedback. Start doing pair or mob programming. Bonus points if you ditch PRs completely and do https://trunkbaseddevelopment.com/ instead while you're at it. Asynchronous code review via PRs is waste (in the Lean sense).
2.) If you still want PRs despite pairing & mobbing (or you're about to tell me you've never done it, you're team won't and/or whatever insert lame excuse here as to slam/dismiss it without trying), spend a faster 5 min via screen share and audio AND CAMERA! Do the PR like an old skool code review session live/remote + camera, but have the author ANNOTATE for their own notes what you've reviewed when they go back to revise. 80% of human communication is non-verbal - interact w/ voice & camera. Help them learn & build confidence, then you won't worry about your writing tone.
3.)
Define "slightly older". The US Equal Opportunity Employment considers you part of the protected class against age discrimination if you're over 40 (see https://www.eeoc.gov/age-discrimination). Let's be honest, 40 is pretty much considered the entry point into "middle age".
Yes. This bullshit you describe was real. I remember having managers in 1998 using Microsoft Project and HUGE plotters that were used for nothing but printing out massive Gantt charts. And, of course, having DAILY meeting when we were behind so that our manager could show with great accuracy how behind we were - and complain he needed more people to manage so he could build his fiefdom.
If you want pacing & support for Nand2Tetris, Coursera has it split into two courses. I've done the first from NAND gates to a working CUP & assembler and can testify it's worthy. Coursera loves to have content sales, so if you're not in a rush you can pick it up for cheap and have their (petty yet ego boosting) certificate of completion to read over one morning with you Cheerios (and then put away in a drawer to be forgotten). Here's the two links:
Don't bother working for a large company. If you haven't seen it already, just watch the movie Office Space (https://www.imdb.com/title/tt0151804/) and you can see everything you need to know about doing software at a big company.
That being said, you have to understand that your new job isn't at a "Big company", your new job is at Amazon: a completely different beast. I live in the greater Seattle area and I can tell you there are two types of Amazon workers doing software development - those who quietly work their jobs and never talk to non-Amazon folks about it one way or the other (e.g. "my Amazon job is great! You should work here!" or "My Amazon job is hell"), or people who are Ex-Amazon who have NOTHING good to say about working there (except for the fact that they left the job). Be careful.
I've gotten hired due to LinkedIn exactly once, and it was helpful. However, that's not how I "use" it. LinkedIn's best use is what it was intended for: a professional networking social media space. Here's how I've used it successfully.
Put your resume on LinkedIn. Send connect requests to people you've worked with and who you'd be willing to work with again. Accept connect requests from people you've either worked with or know from professional networking (meet ups, conferences, user groups, open source project collaborators).
Why?
If someone asks for your Resume, you can first point to your LinkedIn profile (less of a pain).
If someone has a job opening, they'll have a way to contact YOU about the opportunity (yes - I've had this happen multiple times).
If someone with a job opening pings you (hiring manager or team member NOT A RECRUITER!) you can "introduce" people and help a former co-worker find a job or contract work (I've done this a couple of times).
From time to time you'll get pings from former co-workers who might not have another way to contact you - It's nice to talk shop over beers.
Summary: LinkedIn lets you keep your professional network separate from your personal network.