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.

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 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.

Yeah…We do it beacuse we’re cheapskate bastards, trying to get more than we’re willing to pay for.

Source: I worked for a cheapskate bastard, at one point.

there will be a drought of genuinely good talent in the industry.

You’re exactly right, and there’s actually already such a drought. We had this same conversation 15 years ago and it doesn’t feel like we’ve made much progress.

has to change imo, the path should become clearer than telling everyone to get 5 years of experience then come back when they’re ready.

Absolutely, it must change. We need to find ways to do better.

Lol. Nice.

In my decades doing this, I can honestly say I enjoyedboth times that happened for me. It was nice.

I assume you mean to check on his often they’re is the breaking changes? :)

Declarative style isn’t perfect, but it’s a massive improvement from straight bash scripting.

I think you’re looking for Ansible. Have fun!

The difference between an Anible playbook and a script, is Ansible has a ‘check’, ‘change’, ‘verify’ pattern, and is declarative (meaning that once the playbook is made, it tends to keep working on future versions of Ansible.)

I just can’t care anymore. Airplane flights are a lot of effort, and I invariably pick up some kind of conference flu.

For context, I was big into them when I was earlier in my career. But today, the tradeoffs aren’t worth it. I’m still a frequent presenter at my favorite conferences, but only for the online portion.

Also, I’m already available for hallway conversation spaces like this one, anyway.

Even early in my career, IRC chat (an ancient form of Discord) was at least as useful to me as in-person hallway conversations.

So now I enjoy an online conference with some time set aside for meet and greet activities.

It’s news to me that we’re not all just abusing Docker for this. I’ll have to look into some of these mentioned tools.

I honestly fail to see the difference between “don’t deploy on Friday if this can wait until Monday” and “don’t deploy on the evening if it can wait until the next morning”.

Both are top tier practices.

If your team is used to ship frequently and incrementally, it won’t matter when you ship and your risk will always be small."

Yep. That’s all great advice.

But I’m just a veteran saying that all the preparation in the world doesn’t compare with simply not inviting trouble right before the evening or the weekend.

Organizations that feel that they desperately need to take that risk, are doing it because they disrespect their team’s time.

It can be the smallest risk in the world, but it’s still a risk, and it’s a completely unnecessary one (outside of an active in progress disaster recovery).

Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

You’ve used the magic word “should”. “Should is famous last words.” The trick to keeping developer talent is not to risk the developer’s weekend plans on “should”.

And yes, maybe I’m only risking our cloud ops person’s weekend plans. Same principle applies.

Every change that isn’t already an active disaster recovery can wait for Monday.

Good question.

Since we’re doing a deep dive, I’ll share some additonal context. I’m the manager of the developers. On my team, that means the call comes to me first.

I have had Thursday deploys that resulted in bugs discovered on Saturday. Here’s how the conversation on Saturday went:

“Thanks for letting me know. So we didn’t notice this on Friday?”

“No, it’s subtle.” Or “We noticed, but didn’t get around to letting you know until now.”

“Okay. I’ll let the team know to plan to rollback at 0900 on Monday, then we will start fixing any damage that happened on Friday, and the weekend.”

It’s not about how hard the problem is to reverse, it’s about respecting the team enough not to call them on Saturday.

XML

Only inexperienced developers* are unafraid of deploying right before leaving the office.

There’s an entire untapped universe of possible new ways that things can go horribly wrong.

*Experienced developers who hate their boss and their colleagues, too, technically.

Now that’s a team that knows what they’re doing!

If something goes wrong, devs have to give up their weekend to fix the issues, leading to burnout and dissatisfaction.

Correct in spirit, but the words “burnout” and “dissatisfaction” are weasle words that spinless middle managers use.

The correct terms are “abruptly quiting without notice leaving the company fucked and our stock worthless”.

A minor point, but worth clarifying.