Forem: Jesse Angelo

Week 13

Jesse Angelo — Sun, 14 Sep 2025 16:19:37 +0000

I'm having a blast with week 13 this season, namely Dirt Ridiculousness.

I know a lot of people don't have much use for week 13 and that's understandable. Being that a lot of the series are unofficial, racing in week 13 invites some chaotic behavior. The "Ridiculousness" races are no exception, in fact they may be more chaotic than most others due the the fact that they contain a huge, multi-class field.

For me that's a good thing; I believe it's more useful than some people make it out to be (despite also being a ton of fun).

We don't have dirt AI (yet), and there aren't many ways to race dirt ovals without fear of a potential IR or SR hit.

In my opinion the most useful thing about these races are to be able to drive a new car in anger and get practice avoiding wrecks and potential incidents. Just finishing one of these races is an achievement. And managing to do so without any incident points is nearly impossible.

In Dirt Ridiculousness we have the winged and non-winged sprint cars, mini stock, UMP Modified, Late Model, and my personal favorite the 358 Big Block. There's a huge range of performance in that roster. And a huge range of skill in the drivers.

I know dirt oval participation is typically pretty low. The highest series last season was the Micro Winged Sprint Cars with 45,895. (For
comparison, the Rookie Mazdas have close to a million participants at 963,197). Stats from here

Hopefully if more people try dirt and see how much fun it is, they spend some time racing in the regular season. That's my plan!

Your spotter is going to have a heart attack, but you're gonna love it.

Check out this video - I thought it was fun. "It's always a shitshow"

Waving the Red Flag: Avoiding a 9-to-5 Nightmare, pt. 1

Jesse Angelo — Wed, 10 Sep 2025 18:04:23 +0000

Over my career, I've worked in a large variety of places.

I have been the lone developer at my own company, worked in tiny companies of just a few employees, and on a small team inside a 60 person design agency. I have also experienced companies of hundreds, thousands, and hundreds of thousands.

Each experience was pretty unique, but I'm a bit ashamed to say that I have never been terribly choosy when looking for a job. Unfortunately, this mentality hasn't always led me to the best situations

I've learned over the years, that it's a good idea to come up with a list of what you want in a company and, more importantly, a list of what you won't tolerate — your personal red flags. Avoiding these can save you from an incredibly painful and destructive experience.

Here are a few of my personal red flags. These are based on the jobs I've had over the years that have served as learning experiences.

Since you can't know everything beforehand, I'm going to break the list into pre-hire and post-hire.

Pre-hire (signs that you shouldn't join a new place):

Nobody has gray hair
Bad vibe
Over-reliance on technical quizzing
No one is a parent
Too serious
When they warn you in the interview!
Pay too high or too low
Too many full-stack devs/asking too much of 1 person
Too many offshore devs

Let's dive into each one, and I'll explain why I consider these my red flags.

Pre-hire:

1. Nobody has gray hair

Generally, people in their mid and later career have had a few jobs already. They've likely had good and bad experiences and have learned what matter to them. One place I worked had exclusively new grads as developers. While there's nothing wrong with new grads, but when there is no mix on the team, the culture is out of balance. People with more experience tend to be wiser, more thoughtful and deliberate, and provide some grounding in tough situations.

My new-grad heavy experience was a nightmare. There were no best practices in writing code. No one had a long term vision for maintainability. Planning and testing were afterthoughts if they happened at all. My point is that you understand the value of these after experiencing how things go awry without them. And things going awry is what gives you the grey hair.

2. Bad vibes

I once had a round of interviews for a company and one of the five was a terrible experience. It was a pair-programming tech screen for the frontend developer position I was applying for. For some bewildering reason, the tech screen was in Java. I explained to them that I hadn't done any Java in a very long time. Needless to say, things didn't go well. I'm not sure what one gains from testing the skill of someone in something they don't know anything about. I felt like I was being hazed. The interviewer had zero sympathy for me and kept repeating the same sentences about how to approach the debugging.

I'm not sure what the purpose of this was supposed to be. Rarely are you given code and expected to understand it without help from anyone. It was a terrible experience and should have clued me in to the fact that this was part of how they operate.

3. Over-reliance on technical quizzing

I have interviewed and hired many developers in the past. I don't give technical assessments, projects, or quizzes. I understand how larger organizations might want to use a service to evaluate the technical proficiency of applicants, but it's not for me.

I believe that you can get a genuine understanding of someone's technical experience just by having a good conversation with them.

4. No one is a parent

Ideally, work isn't the number one thing is everyone's life who works there. It's perfectly fine to love your career, but I want to work with people who view their job as just a part of their life, not their "baby." An actual baby is their baby.

5. Too serious

I've always thought the point of life is to be happy. I don't want to have a miserable experience day-to-day, grinding away. And when the culture is too serious, no one is having any fun at any point in their day. Ideally we should be a little light-hearted and take everything with a grain of salt.

6. When they warn you in the interview!

This is a pretty obvious one - but also one I have learned the hard way. I think of an interview like a first date: everyone is giving their best first impression. If the interviewer mentions a tough client or difficult working environment, that's probably a major factor in the day-to-day work. I foolishly thought that I have more patience than others since I really wanted to work at this place, I thought I would be able to handle the "tough client." Well, as it turned out, they weren't kidding about this guy being tough. As a matter of fact, he was such a jerk to us that I ended up leaving after he yelled at me in front end the whole team during a meeting. Shortly after he kicked out the consulting company.

7. Pay too high or too low

As you can probably gather from this list so far, I prefer to work at a company that is straightforward and with people that are reasonable. When they offer to pay you too much, I can't help but wonder what the expectation is for your performance. It the deal is too good to be true, there must be a reason why. I know not everyone has a bad experience at FAANG companies, but it's common to get burned out or put on a PIP.

On the other side, pay that's why too low is another red flag. The company might not value what your role entails and they don't have a culture that values developers. They could treat them as a commodity. I'm not suggesting that we should always be paid a fortune, but software development is a demanding job that requires skill.

8. Too many full-stack devs/asking too much of 1 person

I've always been somewhat skeptical of rely solely on full-stack developers. I know that there's a lot of skills that transfer from different programming languages. Many concepts are rehashed or renamed.

However, just because it's possible doesn't mean it's optimal. Would you have a general contractor build your entire house?

I've always thought it's better to specialize; to be "an inch wide and a mile deep."

The allure of full-stack developers is that they can work "anywhere," but it frequently results in less familiarity with the code their working on. And as a results, less ownership over the code.

9. Too many offshore "resources"

I've expressed my feelings on this in a previous post. I definitely understand the need to manage cost as a large team of developers isn't cheap. And I am certainly not opposed to remote work at all. Modern offices are a place of distraction more than collaboration.

I vividly remember one day my tech lead came up to me and asked if I wanted to hide in a conference room upstairs and write code all day. I didn't truly get it until I became a tech lead. There was no time for anything - certainly no time for focus or deep work in that office environment.

My issue with "offshore resources" is the commoditization mentality and how people who aren't in the United States are sometimes viewed. You can't always just throw more developers at a problem or a project. Sometime you actually need project management and organization.

That's it for my pre-hire red flags. Next up are things to look out for when you got the job.

What's on your red flag list?

Hot Lapping with Cold Blood

Jesse Angelo — Tue, 09 Sep 2025 00:21:03 +0000

The above image is best of ~10 attempts with AIs to get them to put a dinosaur actually IN a car. Apparently not possible, sheesh.

I'm happy behind a wheel.

I've loved every car I have ever owned. From my Isuzu Trooper, to my crumbling Cressida, to my overheating 325i, and to my awesome Audi S3.

Freedom is driving.

I love to drive and I really love to race.

However, I am by no means an expert sim racer. If those guys with 10,000+ iRating are aliens, I'm definitely more of a dinosaur. And not a fast one like a gallimimus, more like a stegosaurus.

I am creating this space to be a place where I can post my struggles and successes. Where I can show my growth over time and learn from my mistakes.

I probably won't have many tips to help you. There's a good chance that you're faster than me and you have a higher iRating.

But this is will be my journey.

Right now, I have trouble finding the time to consistently race.

Also I'm someone who has trouble with the mental side of sim racing. I know it's only a simulator for chrissakes, but I do tend to psych myself out and want to endlessly prepare before jumping into a race.

Who else am I? I am a very good student and I love to read and study. I'm diligent and hard-working. I'm very intrigued by how relatively small amounts of consistent effort can, over time, give big results.

If any of this rings true to you, I hope to see you in a future post.

Until then, have fun out there.

This project should never be finished

Jesse Angelo — Mon, 14 Sep 2020 20:44:15 +0000

A co-worker once said to me, "I can't wait until this project is finished."

We had been working on a new web-based application for almost a year already, and we were nearing our first release. That made me think: it really shouldn't be finished, otherwise it's as good as dead.

To be clear, I'm not saying to never deploy the software. Also, this isn't about a 'Pied Piper' scenario where we had engineered something that, unleashed unto the world, would basically turn into Skynet in a few years time.

*Not exactly this dangerous, just really annoying tech debt.*

This application we were working on was a responsive Angular SPA replacement for the dated .NET version that had been in production for years. The software needed to be updated because it wasn't serving our business needs anymore. Since it was using such outdated technology from top to bottom, the best path forward was to scrap it and rewrite the entire thing.

So the software was effectively a zombie. Living in production, but simultaneously dead. This happens a lot - a team assembles and develops software. They become experts in the intricacies of the business and users' needs as well as the details of the implementation. Finally, the project is deployed to production and everything works great... for a time.

Inevitably the users' needs change or the business needs evolve. The team that had originally created the software has moved on to other projects or maybe they've left the company. In short, no one is really familiar with the specifics of the implementation; maybe it lives on a box that isn't maintained like the newer ones. Or likely it uses frameworks, libraries, languages that are rather old.

The best case scenario you can hope for is that members of the old team are there. However, I'm sure you know how fun it is to effectively dig up the past or relearn code that you wrote years ago. There are always surprises.

We have another piece of software that, after 3 years in production, the users would like some updates. A lot of the updates are minor fixes/presentational; making things more consistent and fixing typos. There are also some feature requests like adding new columns to the data grids in the application.

Seems innocent enough at first glance.

This software is another example of the living dead. It's using very outdated versions of packages (some betas and others alphas) and to update it would likely be just as much work as rewriting it. There are a host of security vulnerabilities, janky code, as well as an inconsistent user experience. It would also absolutely be a lot of confusion and frustration to 'git clone' and get to work.

*That team's AngularJS code from a few years ago*

We've determined a rewrite is the way forward, but the pain doesn't stop there. The current development team is trying to get access to the system in production so we can effectively create our new wireframes and user stories. It's always much easier to use an existing piece of software to understand it as opposed to reading a functional requirement document.

This is turning into a black hole - there's an email chain with 29 messages (and 30-something recipients) going back and forth just to give us access to the current system. We've had a number of meetings already too and keep dragging new people into the conversation. And we still don't have access yet. It seems no one knows exactly what combination of permissions one needs. So, there are more emails to come...

Just think about all the time spent on just these emails and meetings. Of course, not everyone is actively taking part in them, but they are yet more work/noise for everyone involved. And worse still, they are one more blow, however slight, to the confidence in our development team. No one knows why we can't get access - we're relying on people's memory when the project was first done to figure it out. And this is just the beginning.

*See you in hell*

Ideally though, the solution for this is to NEVER FINISH IT. Continuously update, patch, rewrite, and develop your software. Maintain it and modernize it and don't leave it for dead.

We're going to migrate this application onto our platform that's in constant development. It's the only way to avoid another complete rewrite down the road. Sure it'll be more effort to maintain, but that's the cost of software.

*Be like Gabe (not really)*

So next time you think about the relief you'll feel when a project finally 'finishes' just remember this post. Your entire team will be better off never finishing that application.

I said eff it and applied to NASA

Jesse Angelo — Mon, 07 Sep 2020 20:08:14 +0000

Many years ago I worked with a talented individual at an interactive agency. I'll call him Sal. He was the boss of our small group of developers and had far more experience than all of us.

To let you know roughly how long ago we're talking, I'll just say this: we were making Flash websites for cigarette companies. Of course, that's all illegal now. Cigarette companies can't advertise in that way anymore, and nobody's making websites in Flash.

*Pick your poison*

Though we were making Flash/ActionScript based websites, Sal started teaching us C. He had a lot of experience in C/C++ and thought it would be good for us to understand a fundamental language like C. He was trying to ingrain good practices in us since C was very unforgiving unlike ActionScript and Javascript. I thought it was great; it forced me to be more careful and aware of every line of code that I wrote.

He was a natural teacher. When you'd come to him with a problem, he'd typically take one look at your code and just say, 'ok'. Not only did he already know what the error was, but he also knew how he would go about explaining it to you in a way that would help you to write better code. He'd get some paper and a pencil and start drawing or writing. He always took the time to step back and explain concepts to get you to learn something through debugging.

Sadly the company was forced to scale back drastically when they type of work they primarily did was made illegal. The whole development team was laid off.

Sal and I mostly kept in touch over the following years, but fell out of contact for a time. When I did get back in touch with him, I was surprised to learn that he was struggling to find a job. It was a long story, but he had suffered some health issues so he couldn't work for a while and his skills weren't current anymore.

We started meeting for lunch every few weeks to talk about job hunting, the industry, resumes, etc. I really liked Sal and wanted to help however I could, but he was really struggling.

He was applying everywhere and interviewing where he could. He had fallen into a weird place where he had a lot of experience, but he wouldn't be able to hit the ground running. He needed to learn on the job.

His interviews were not going well. We tried tweaking his resume and he was studying some new skills. He even tried to scale back what was on his resume and get junior level positions, but that didn't work either.

One day we met for lunch and immediately I could tell something was different. He told me that he was so frustrated with the way he was being treated that one day he said, "Eff it, and I applied to NASA."

They had called him back and begun their interview process. I was elated!

The next time we had lunch I was thrilled to learn he had accepted a job offer! It wasn't with NASA exactly, but 'Uncle Sam' he said. He couldn't actually tell me where he was going to be working or what exactly he was going to be doing. In reference to his job, all he said was, "have you ever seen the movie War Games?" Amazing.

*Sal at work*

Fast forward a couple years, he's now a development manager and still working for Uncle Sam. He's managing the efforts of upwards of 50 engineers. I still don't really know any details other than the fact that he requires top secret clearance to do his job. And it's not Flash that he's using of course; it's C++.

My point in all of this is two-fold:

Many companies are hiring totally in a backwards manner.

There's too much stress placed on specific knowledge. The fact that my friend Sal was passed on by so many companies indicates that there's a problem with interviewing and recruiting. I know every company may not have the resources to take on someone that doesn't know the exact technology in use. But we need to get better at identifying skill and potential and value enthusiasm and personality just as highly. Anyone can learn a technology.

I never ask trivia style questions in interviews. Take home assessments don't respect the candidates time. And don't get me started on whiteboarding algorithms.

Practical coding tasks such as 'debug this application' are preferable. Also, I believe much insight into someone's skill and experience can be obtained just through a conversation.

*But he fizz-buzzed so well*

There's more to life than FAANG

Look for job opportunities outside of FAANG, big tech, fin tech, start-ups, etc. Blaze your own trail. Learn the tech you want and use it in the industry that you're passionate about. You may find when you get your FAANG job that it's not all it's cracked up to be with incredibly long hours required, high stress, and intense competition even when you're hired.

// Detect dark theme var iframe = document.getElementById('tweet-1302678542988251139-726'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1302678542988251139&theme=dark" }

Something that stuck with me was that there's more lines of code in the software for a modern car than in a modern computer OS.

https://www.visualcapitalist.com/millions-lines-of-code/

There's so much else out there than just websites. I literally just saw someone running Doom on a pregnancy test.

// Detect dark theme var iframe = document.getElementById('tweet-1302820468819288066-884'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1302820468819288066&theme=dark" }

The point it that there's software everywhere. And many types of people can offer unique skill and viewpoints. Keep an open mind when interviewing and deciding where to interview. Let yourself be surprised.

On 'Resources' vs 'People'

Jesse Angelo — Mon, 31 Aug 2020 20:27:32 +0000

All too often we consider developers a commodity. We don't use the term 'developers', much less 'people'; we use words like 'resources', 'bodies', or 'headcount.'

One of the things I dislike the most is hearing people say, 'offshore resources'... as if we don't know where they are or who they are.

For us at least, they're people and they live in India.

*The fabled off-shore land*

I'm not saying it's management's job to acknowledge and consider the details of everyone's lives. I know there is a bottom line and there is work to be done. However, some middle ground would certainly be nice. When you start abstracting that your coworkers are people who are living a life, and only look at them for what they are capable of producing, I think it's you that's lost your humanity.

This goes for contractors too of course. There's tendency to only think of contractors as someone there just for a specific purpose. And to an extent, that is the deal. You're hired purely for the skills you have and to do a specific job. The employer isn't expected to consider you as a person; one with aspirations and goals. You're basically just an interchangeable part that the organization can swap out as they see fit.

Of course this makes it easier to find talent and get the users stories moving across your Jira board. But where it breaks down is when you rely long-term on contractors. And I think it's not only doing a disservice to the individuals, but to the whole team and ultimately to the organization itself.

Most of my team are contractors, some of whom I have worked with for years. We rely on them heavily to get our day-to-day work done, and without them, our entire project would come to a screeching halt.

There's a natural tendency, after a while, to want to change roles or move forward in your career. And I think that should be encouraged. The best people are the ones who strive to improve and want to have a greater impact.

There have been a few occasions where contractors I've worked with for years have wanted to either convert to a full-time employee, or move to a different role. I know not every request can be fulfilled: sometimes there just isn't a full-time position available or an opportunity to switch teams. But I think we should make a greater attempt to encourage people to grow their career. We should enable them to take on new challenges and accept new responsibilities.

If we don't, they won't stick around. They will search for an opportunity elsewhere and they will take all the knowledge of the industry, team, code base, and how to work within your organization with them. As the void left by them is attempted to be filled, it will slow your team down. It doesn't matter how talented their replacement is, there's always a period of on-boarding before they can really expect to be productive. I've found this to be, on average, measurable in months.

How long do you think it'll take to learn your code base

In short, it's in your best interest to see your resources as people. You should expect and encourage their development. Hopefully you'll have a place for them, but if not, you'll be better off having a system in place to handle the inevitable turn-around and keep your team running smoothly.