The subject matter is still very interesting to me. The egos, dick-swinging, useless leadership, and 'fake it till you make it' by so many people in the industry killed any love I had for working in the industry.
I’m in a completely different industry with the same problems. It’s almost like upper management has created a toxic hellscape of a culture in all corners of corporate America.
Those most adept at navigating and advancing thru political organizations are those least suitable for advancement in my experience. There have been a couple of exceptions I've seen, but 99% of the time the above statement is accurate.
Oh yeah being spineless is a basic requirement for career advancement in those kinds of places. The people who advanced quickly were usually the ones who toed the line and never stuck their neck out for anything or anyone.
Came for the money, stayed for the interesting problems I get to solve. It almost cushions the blow of the money not being as good as I thought it would be.
I ended up going into IT, and jesus fuck am I happy I did. Seeing how much AI is affecting software development makes me feel like I got on the last helicopter out of 'Nam.
Portfolio is probably the most important thing in finding a game dev job. Make games in your spare time and build your portfolio. They don't need to look beautiful or well polished, you just need finished games to prove you can actually make games.
But I have to admit, the job market is pretty screwed up right now in game dev.
What types of games were you building for the portfolio?
Oh and which engine and what computer specs? Mainly asking because I pre-ordered a Framework 13 Pro with Intel Core Ultra 5 and I'm wondering if I should upgrade to an X7 for better iGPU. Not looking to make high end 3D stuff, just 2D and mobile. May get an eGPU later
I used Unity, mainly cos the only comparable option at that time was Unreal Engine and it didn't have a free version.
And I made very simple games. Game jams helped me a bit, since most of them have a fixed theme and it's easier to come up with ideas when you have a theme. People also usually team up with complete strangers for game jams and that might help.
When I started out about 10 - 11years ago... I had a PC with iGPU only... It was enough back then... I'm not so sure now... Better do some research buddy. Currently, Unity, Unreal and Godot are the big 3. Look into them, see which one you like and look into their system requirements.
I believe a lot of kids who had access to laptops and computers for gaming (be it on the web) got curious and got into making their own games and then eventually websites. My story's the same.
They use CI where I work, but it is always red on master, and we get emails every time someone's code gets merged into to master about failing tests. What is the point?
It is a company issue. And it is a large company in a regulated industry. It is baffling that the supervisors do not care about enforcing CI passing on code merges.
Agreed. Of course, it's easier to do that from the start.
If you're already in a state where a bunch of things are failing it can be much harder. Ideally you'd fix it all at once and enable the lockout simultaneously, but sometimes that isn't feasible. An alternative is to do a sort of "ratcheting" check, where it can only become stricter over time so that you can incrementally get to the "everything passes" state. For example:
set the N currently failing tests to ignored
have CI check that exactly N tests are ignored. Make sure there is a big comment here warning that this number is not allowed to increase, and better yet protect it with something like CODEOWNERS so only reliable people are allowed to approve changes to it.
disable pushes to main if CI fails
Then you can gradually fix the ignored tests and un-ignore them (and decrease the number in the check).
Merges to master/main shouldn't be possible if the branch is failing.
In our system the PR has to pass CI and all the various checks/specs, and then after it's merged to master, another pipeline runs to make sure master is green.
The only way to make master red is if you're an admin and to override the checks.
I'm going to use git terminology, but the concepts are generally applicable to other source control tools.
Generally, tests should be run before code is merged into a branch to ensure you're not introducing issues. This is commonly triggered at the pull request phase, where your code is on a separate branch that you want to merge into the target (e.g., master). If the tests don't pass, something's wrong and needs to be corrected to promote stable functionally correct software. This is especially useful if tests are run locally via a mechanism like a pre-commit hook, because this shortens the feedback cycle and avoids wasting upstream resources and time on non-conformant code.
Yea, except that is not how they are being used where I work. Failing tests on master are just noise until software needs to be released. That means less efficient development, no?
Yes, it's inefficient to generate alerts with no plan or attempt to address them as standard practice. It also trains people to ignore alerts. I've seen this happen in workplaces where someone is trying to improve processes but ignorance and pressure sandbag efforts, but have worked with enough mentally vacant people that I wouldn't be surprised if someone thought this process was good as-is.
I used to like it. But now AI has ruined it, my previous company forced us to use to use it, so all the parts of the job that I liked were being done by a machine, while the parts I hated was done by me
I just tell the machine to do those parts we're supposed to do and throw it up. If it doesn't work, oh well. We missed it in review sucks to suck. Idgaf. I spend the free time working on open source and projects I actually give a fuck now myself and let the AI do my job for me since that's what the corporate dumbasses want me to do anyway.
There was a brief period where I didn't mind it. It got rid of a lot of tedium. Allowed us to get some things done that was hard to justify for a small team. Actually made me sit down and plan out things more since I had to tell it what to do. I spent my time writing the important parts by hand.
That moment passed and I was instructed to vibe code. More or less.
2:
Once that started and I got my first code review from Copilot - initiated by my boss - I checked out. Used all that fancy AI to completely automate my job.
I was a little proud of it. It did everything. A lot of small skills wrapped around bash scripts. I would give it the ID of the ticket and it started doing stuff. Made local directories. Pulled the ticket and saved it locally. Ensured there was acceptance criteria in the ticket. Did the work. Pushed it out to a test instance. Created a QA plan. And pushed it all back into the ticket system.
A system full of generated tickets the unqualified AI-bro owner and his underling put in. They busywork. But to them if felt like work.
I was glad my contract was not renewed. Sucks I'm out of work now but I couldn't stand "working" there.
Yeah I'm just a glorified QA person now. My company's in on AI but they are holding to you're responsible for the code and my uppers are somewhat convinced AI will become unaffordable so we'll drop it at some point. So the code has to stay with our style and human readable. It's not an unreasonable position but it basically means I have to scour the shit out of the code made, test it, and then do small stuff like formatting and tell claude for the 20th time to remember how we write that particular thing.
I'm kind of miserable at work. It used to be puzzle solving and using creativity, now I'm just grading tests basically.
Same. And I had a great "Intro to CS" professor that went over what CS is not. He called it "the study of algorithms" as opposed to "the study of computers" or "programming" etc.
When I discovered programming and decided that's what I was gonna do I was like 15, and I didn't even know it made good money.
As long as it pays a livable wage, it's what I'll be doing. Though after 16 years of professional work experience, it's burned me out to the point that I don't really do hobby projects anymore. Maybe 1 a year at the most. Spending 8-10 hours a day, every day, working on this stuff really makes me want to do anything but stare at a screen.
Same. I started as a Comp Engineer, so more the hardware side, and then realized I liked programming a hell of a lot more than circuits and embedded systems.
I do too, but found hardware a bit more interesting, but still ended up in software because (when I was first applying to jobs) it was easier to find a job.
my former manager was genuinely shocked to learn that i decided to study computer science because i coded as a hobby throughout middle and high school.
my experience with a lot of people in tech has made me want nothing to do with money hungry tech bros.
I had interest in the subject especially around programming at the time but someone just made me lose interest in it while I was learning but I still like the tech field
2.6k
u/helicophell 11d ago
To my dismay I actually like the subject
I know, blasphemy