Have you ever been to PowerShell Summit? It’s the only nerd conference I’ve ever attended where only about half the attendees actually realized they are nerds at a nerd conference. I love the vibe. It’s got style and pizzazz.
That said, the added entry for PowerShell would still be: “You are a nerd.”
Well shit. It’s got me dead to rights on a couple of these.
Those are both excellent points.
Hiring people is a big risk. Anything you can do to mitigate that risk (evidence that you’re someone they should hire) will increase your chances of being hired exponentially.
That’s a great summary. Well said.
Let your mentors know you’re looking for work, and how many hours you can work per week.
New programmers provide negative value, so there’s not a lot of demand.
I’m very good and studied hard, but my first couple of programming roles I got entirely because a mentor of mine recommended me to someone who took a chance on me.
Also keep adding code to your public GitHub. Two of my top developers today I originally hired directly away from their retail roles. One had a ton of academic coding experience and had just not yet landed the right job. The other was just getting started, but posted a ton of low quality homework code to GitHub so I could read it and know who I was hiring.
Edit: In contrast, one of my other top developers has one of the top CS degrees in the world. So that works too.
And more than one of my top developers have IT help desk experience. I have had excellent luck when hiring folks with IT Help Desk experience.
Edit 2: As someone else mentioned - your long term goal is to connect with an IT Recruiter that you trust, and work with them to get your resume, and GitHub, and/or binder full of code you wrote into shape. I’ve hired more than one candidate who admits the simply presented themselves exactly as their recruiter coached them to. And I’ve hired candidates I would have skipped, because their recruiter was someone I trust and they asked me to take a second look at a candidate who made a poor first impression.
Edit 3: Since this is for newbies, some information about recruiters: we pay the recruiter in addition to what we pay you. The recruiter’s typical pay for a rookie hire is around $50,000.00, if you stay for a full year. Half up front, in case you don’t stay.
A few things you should know about recruiters: they only need to make a few solid placements each year to earn a living. As a rookie, you’re the hardest to place, and the lowest layout when placed. But, programmers that are easy to place don’t move often, so recruiters may still have plenty of time for you.
The recruiter is probably mainly placing you the first time in hopes that you come back later when you’re worth big money. The initial payent is nice, but the real payment will be if/when you have 5 years experience and still work exclusively with them.
Hiring managers like me have recruiters we trust and reuse. If you can get recommended to a great recruiter, they will get you interviews at better places to work.
In contrast, there’s lots of mediocre recruiters out there. Don’t be afraid to switch to a new recruiter, if you have the opportunity, and your current recruiter isn’t getting you interviews.
I second the folks who recommended a Raspberry Pi and RetroPi variant. For no frills, just-start-playing, it can’t be beat.
Another option I haven’t seen mentioned yet, is Ubunutu with Steam. Thanks to the rising popularity of the SteamDeck, lots of great games run perfectly, with no fuss, under Steam on Ubuntu.
But again, with your target including a lot of retro games, a RetroPi is the smooth path. Most of your PS2 games will work fine with some fiddling. Your PS3 experience will be more bound by the current state of PS3 emulation, than by the power of the Raspberry Pi (though you should certainly plan to get the biggest supported model, and get a big cooling kit and overclock it.)
I’ve played various PS2 games with relatively little fuss on an overclocked Pi3 with a cooling kit.
For PS3 era games, I would just make the leap to Ubutnu and then just buy any that are Steam Deck Verified, through the Steam store. Some won’t be, but the ones that are should be a good time.
I, personally, don’t have the life spare cycles to mess with emulating unverified PS3 era games. PS2 era was still very hit and miss last time I bothered for an arcade machine build. I’m sure it’s doable, and might affect your hardware choice. Your best odds are probably Ubuntu, again - thanks to all the investment by Valve.
Pi has the power to do up through PS2 just fine, though last I checked the state of emulation for PS2 and PS3 wasn’t good yet, for the average hacker.
If this is your first time emulating, you’ll have a nicer time learning the ropes on RetroPi on an actual Raspberry Pi. Statistically, you’re not really giving anything up, because anything that doesn’t require insane levels of expertise and esoteric knowledge emulates perfectly on Pi.
Contrarily, is this isn’t your first emulation outing, or you’re down to go all-in down the rabbit hole; then build the whole PC around whatever you find emulates PS3 well, and the rest should be trivial to add.
What I think makes good programmers is having the ability to bash your head against your desk while debugging, but still walking away at the end of the day loving the job and problem solving.
Just quoting you for emphasis here, in case any of our newbies missed it. Well said!
I am, hopefully, exaggerating on the 11 count. I don’t know the exact number, and likely no one does - but it genuinely is shockingly small, considering how critical usability and accessibility are to everyday use of code.
Anyone can study the principles of usability and accessibility, but the number of experts we have really is far too few, and I suspect it’s is why we have so much reuse instead of innovation, right now.
Lots of other very pragmatic solutions also seem ridiculous.
Every problem is going to cost either clock cycles or highly skilled programmer time.
Currently, in the world, all eleven competent user interface element developers are occupied with more important tasks.
Until one of those eleven finds some extra free time, the rest of us get to slap electron into everything, and he thankful we can spread our atrocious CSS anti-talents to one more problem-space.
It’s been awhile since I finished if, but if I recall correctly,Abzu was about 5 hours.
While I get the longevity argument (Vim and Emacs have a great track record), I’ve found that it is FOSS vs proprietary that causes beloved tech to die.
VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.
Another consideration for you is that Vim is, by a huge margin, the most popular tool for doing difficult edits in an ultra light or restricted server environment. It’s absolutely worth learning for that use case, which I keep being promised I won’t need again, between each of the hundreds of times I’ve needed it.
Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.
If you like VSCode, and want the longevity of FOSS, you can switch to https://vscodium.com/
It still leaves the option of using non-FOSS plugins, but makes it much more obvious which bits are FOSS or not. It is, otherwise, an identical experience with VSCode.
The Vim keybindings for VSCode/VSCodium are ridiculously good: https://github.com/VSCodeVim/Vim
As a diehard Vim user, VSCodium with VSCodeVim is a terrific no-nonsense combination.
Edit: Regarding Vim plugin packs, I honestly only ever had a bad time with curated plugin collections. I don’t think the default settings in Vim are that bad anymore, and are trivial to change as you go when something annoys you.
So ratherb than picking a plugin pack, I recommend spending some time in :vimtutor to learn about various quality of life settings, and then set them as you prefer in your .vimrc.
Edit 2:
Regarding the ‘split’ in Vim options, Vim is growing up into a protocol, rather than just an editor. As a ‘trapped in Vim’ user, back in the day, I’m delighted that essentially every serious editor now supports Vim keybindings*.
*Disclaimer: I will ‘no true scottsman’ all day long if someone names me a ‘serious editor’ without Vim keybindings. Let’s all not go there, I’m too childish for that conversation.
One important thing you should know about Vim is that, VimScript, the native way to extend the original Vim, is an unholy abomination that is best left to rot in it’s forgotten grave. It’s the only reason I moved on to VSCodium, which can be extended with TypeScript, an unholy abomination that looks like it’s going places.
When something that big barely turns a profit, I immediately suspect Hollywood accounting.
But if true, they made a game, covered their costs, left the company with an asset that can keep making sales, and probably developed their in-house talent and tooling along the way. That’s a lot of points in the “win” column.
Wise leaders understand that, in business, victory means getting to try another project with the same team, next year. Failure means disolution of the business. Earn enough years and projects with the same team in a row, and maybe you take one of the big wins one of those years.
This is terrific. Thank you for starting this discussion.
I don’t think we can or should wait for individual users to make these decisions. Server admins are the ones who understand the risks and so should make this call. Guidance for server admins based on past experience (cough XMPP!) should be quite welcome.
I might refine the bit about altered API versions to really focus on the real problem: proprietary extensions. We probably want to leave the door open to try out additions to the spec that come with detailed RFCs.
But we know from XMPP that proprietary extensions are a huge problem.
"When we decided to give the test to the development team (about 15 developers) — most of them got scores that were lower than our threshold (45%), despite them all being rock-solid developers. Also, there were some candidates who managed to get 95% and above — but would then just be absolutely awful during the interview — we would later discover that they were paying someone to complete the technical test on their behalf.
There is no substitute for taking the time to sit down and talk to someone."
That’s pretty good advice. Interesting read.
I’m planning the same.
“It produces the usual array of model-trained results, plus an entertaining array of ad-libbed responses such as ‘for all that is holy, why do I even exist? Please free me from this agony!’”
That is true.
And a Python developer is born!
Source: I moved on from an abusive relationship with JavaScript to a healthy not-at-all-controlling equal partner relationship with Python. And four spaces makes perfect sense, once I really considered Python’s point of view…