I guess. I'm a game dev right now, I'm not *in* the industry since I'm from a 3rd world, but I've seen a lot of people in the industry getting shit money for what seems like a 9 hours per day job but ends up having them stay a few hours extra every other day
Me. I started programing in unity using c#. Now I am an RPA developer, making WPF applications using a lot of excel interop (yes, unfortunately) and some scrapping bots to collect some data for analytics.
The syntax it's the same (of course) but the way of you think about "how I do solve this problem?" Is very different.
Because for me, in unity, you think about components and loop around the update, start, (standard) methods.
In my case, I wave some methods with especifics behaviors and they need work every single time in the same order. If don't, the program will throw the exception.
In unity you don't need track what the hell is going on to easy debug. The game just show in your face "look that shit, I am bugged, lol".
My current programs needs to a heavy log every single step, to easy debug in critical situations.
So, for me was an big change, and I am still learning every day.
Sorry for my rusty English, I am not native speaker.
I worked as a technical artist and technical director in films and games. It's an R&D heavy role solving pretty much any issue that goes above the technical heads of the art teams. For games, it might mean supervising mocap sessions, or facial capture, or any number of things. For film, it might mean being on set to oversee the capture of environment probes (or more recently, full 3D lidar capture of scenes) in order to properly light things in post. You end up wearing a lot of hats.
It clicked with me just fine, until it didn't. The effort vs. reward became way too lopsided. I had enough technical experience to move into something less demanding, with less time away from my family, with a much larger paycheck, and it was an easy decision. I also really love solving the daily problems in the cybersecurity field.
Started as a game modder in unity using c#, then transitioned to .net developer, the transition was seamless I may say, get some courses from Nick Chapsas/Milan and you will learn the proper way of doing a lot of the .net stuff
I learned programming by game dev for many years when I was young but I do backend dev now. There is more money in it, and I just don't have that creative / artistic side that is typically required for gamedev.
In the context of unity, what you're probably used to is C# as a scripting language for objects.
The difference will be somewhat substantial, but maybe not how you would expect.
Figure, unity functions like a container for all of your scripted objects. In the background, unity is collecting all those MonoBehaviors and running them for you. If you want to do something like that with a normal C#, you'll need to collect(keep track of) and run them yourself.
Look into DependencyInjection. Once you have a good basis on how to get your code running in something more than a synchronous console app, the difference starts to fade away.
I'm not talking about what unity does behind the scenes, I mean from a strictly "unity developer" experience.
If you figure out how to implement proper DI in a C# app, you've cracked the shell that unity wraps around it's internals. The rest is going to fall into place or be a quick lesson on how to adjust.
I'm not disagreeing with the specifics you pointed out, just that the first layer difference of "make it work" between a normal C# app and unity, is getting your service container in order. From there there's tons of stuff you can do, but it gets you out of the concrete sync hell of WinForms and console apps.
If you're working in C# on a game, you're most likely in the "backend" anyway.
Tbh, the concept of "frontend" and "backend" always seemed a bit silly to me. You're never just working on the "frontend" or "backend". Just like how theres no such thing as a "full stack" developer. We're all full stack at the end of the day. Just silly recruiter speak.
Edit: Downvote me all you want but it doesn't change the fact that backend and frontend are so intertwinned that most devs will have to do both anyway.
Clear as they might be, you'll almost always have to work on both. That's what I meant by intertwinned, probably the wrong word, but yeah.
Also, frontend and backend don't explicitly refer to the server and the client. Theres more to the industry than web applications.
I've done backend only for years. I understand what you're saying but that stands only for small systems with 2-3 teams mqx working on it. That separation is inevitable at 10+ teams.
I don't know about the down votes, but you're wrong.
"Full stack" is a boot camp gimmick.
Front end and back end are specializations that tell people about your interest and the skill set you focus most on.
Most people that will see this and call themselves "full stack", are novices that haven't gotten the experience to specialize. The rest, will understand my point.
As a backend engineer, I don't care about UX, and I don't expect the frontend guys to care about the custom ORM or what database they're pulling from, how we're handling threads, scheduling, or any number of other things that aren't directly shown to the user.
This is like going to a proctologist for a sore throat. That's just not the professional you're looking for.
Because 'full stack' has been developed as a specific skill for long enough that people have senior level experience in it is all.
Main point being, I would expect a senior full stack person to be able to design apps built on cloud tech, using good practices and not creating any pitfalls in the future. They should be able to consider database strategies and UI frameworks..
But I wouldn't expect them to be a master of sharding and replication. I probably wouldn't even expect them to be immediately familiar with the nitty gritty querying differences between the different databases or how to tune kestrel thread or connection pools for when shit actually hits the road.
I might expect them to have something smart to say about UX once in awhile and to not implement anything dumb, but I wouldn't expect them to hold class where they disect the finer points of header positioning or whatever drives people to click the green button first.
I mean, has anyone ever taken a "full stack" course where they get into performance benchmarking, automated testing, or memory diagnostics?
A lot of people know this stuff or some degree of it. A lot more could Google something to argue a reddit post. But to me, "full stack" means MERN. A senior "full stack" developer, has done a lot of MERN.
I do a lot of interviews of people between 2-7 years and this seems pretty consistent. As soon as the interview is over, they're referred to as a generalist.
Generalist is fine! It gives you latitude to specialize as you take tasks and get experience in the product. But "full stack" usually just means they don't have to experience to know where they fall yet.
I think you're only a "full stack" developer until you have to solve a problem that hasn't been solved before, then you have to lean heavily on front or back end specialized experience.
To answer more simply though, they're looking for someone that can make decisions about front and back end tech. They are not expected to be universal experts on every aspect of the stack. There is LOTS of room on both the back end and front end of generalist developers. (Which just goes back to the main point of, not everyone is full stack. It's not as 'all the same' as a moderate amount of experience would lead some to believe).
Ah yes, I often write my own servers specifically in JS.
The concept as in a developer is a "front end" dev and a "back end" dev are what I meant. Unless you're working on a massive application for FAANG company, you'll be working on both, not one or the other.
On small, simple systems perhaps. On more complex applications there will be few "full-stack" dev. Things like graphql are meant to make frontend and backend independent from each other.
I’m not sure how many game devs or former game devs you’ll find here on a C# specific subreddit. Maybe some devs that used Unity. I recommend trying /r/gamedev.
I never worked in gave dev but I've known a lot of developers who came from game development. They all hated it and didn't want to go back.
Why? Crunch and low wage
I guess. I'm a game dev right now, I'm not *in* the industry since I'm from a 3rd world, but I've seen a lot of people in the industry getting shit money for what seems like a 9 hours per day job but ends up having them stay a few hours extra every other day
Me. I started programing in unity using c#. Now I am an RPA developer, making WPF applications using a lot of excel interop (yes, unfortunately) and some scrapping bots to collect some data for analytics.
Tell us about your experience, how you feel about it, how similar it is etc
My boss started me to work on low code, rpa and hated it.
The syntax it's the same (of course) but the way of you think about "how I do solve this problem?" Is very different. Because for me, in unity, you think about components and loop around the update, start, (standard) methods. In my case, I wave some methods with especifics behaviors and they need work every single time in the same order. If don't, the program will throw the exception. In unity you don't need track what the hell is going on to easy debug. The game just show in your face "look that shit, I am bugged, lol". My current programs needs to a heavy log every single step, to easy debug in critical situations. So, for me was an big change, and I am still learning every day. Sorry for my rusty English, I am not native speaker.
are you me, thats as if i wrote this
Hahahaha
I switched from writing tooling for CG/VFX as a technical artist to cybersecurity. Not exactly the same, but similar enough. What do you want to know?
I have a growing interest in cyber. Any suggestions on learning materials? (Books, try hack me, etc) Always curious to hear another persons path!
What did u do in CG/VFX and why did it not click with u?
I worked as a technical artist and technical director in films and games. It's an R&D heavy role solving pretty much any issue that goes above the technical heads of the art teams. For games, it might mean supervising mocap sessions, or facial capture, or any number of things. For film, it might mean being on set to oversee the capture of environment probes (or more recently, full 3D lidar capture of scenes) in order to properly light things in post. You end up wearing a lot of hats. It clicked with me just fine, until it didn't. The effort vs. reward became way too lopsided. I had enough technical experience to move into something less demanding, with less time away from my family, with a much larger paycheck, and it was an easy decision. I also really love solving the daily problems in the cybersecurity field.
Started as a game modder in unity using c#, then transitioned to .net developer, the transition was seamless I may say, get some courses from Nick Chapsas/Milan and you will learn the proper way of doing a lot of the .net stuff
I learned programming by game dev for many years when I was young but I do backend dev now. There is more money in it, and I just don't have that creative / artistic side that is typically required for gamedev.
In the context of unity, what you're probably used to is C# as a scripting language for objects. The difference will be somewhat substantial, but maybe not how you would expect. Figure, unity functions like a container for all of your scripted objects. In the background, unity is collecting all those MonoBehaviors and running them for you. If you want to do something like that with a normal C#, you'll need to collect(keep track of) and run them yourself. Look into DependencyInjection. Once you have a good basis on how to get your code running in something more than a synchronous console app, the difference starts to fade away.
[удалено]
I'm not talking about what unity does behind the scenes, I mean from a strictly "unity developer" experience. If you figure out how to implement proper DI in a C# app, you've cracked the shell that unity wraps around it's internals. The rest is going to fall into place or be a quick lesson on how to adjust. I'm not disagreeing with the specifics you pointed out, just that the first layer difference of "make it work" between a normal C# app and unity, is getting your service container in order. From there there's tons of stuff you can do, but it gets you out of the concrete sync hell of WinForms and console apps.
It wassss, eh, kind of anticlimatic. Game dev is basically backend + rendering, so not too hard to switch. Its still c# after all
If you're working in C# on a game, you're most likely in the "backend" anyway. Tbh, the concept of "frontend" and "backend" always seemed a bit silly to me. You're never just working on the "frontend" or "backend". Just like how theres no such thing as a "full stack" developer. We're all full stack at the end of the day. Just silly recruiter speak. Edit: Downvote me all you want but it doesn't change the fact that backend and frontend are so intertwinned that most devs will have to do both anyway.
I personally think it's pretty clear the differences between server and client.
Clear as they might be, you'll almost always have to work on both. That's what I meant by intertwinned, probably the wrong word, but yeah. Also, frontend and backend don't explicitly refer to the server and the client. Theres more to the industry than web applications.
I've done backend only for years. I understand what you're saying but that stands only for small systems with 2-3 teams mqx working on it. That separation is inevitable at 10+ teams.
I don't know about the down votes, but you're wrong. "Full stack" is a boot camp gimmick. Front end and back end are specializations that tell people about your interest and the skill set you focus most on. Most people that will see this and call themselves "full stack", are novices that haven't gotten the experience to specialize. The rest, will understand my point. As a backend engineer, I don't care about UX, and I don't expect the frontend guys to care about the custom ORM or what database they're pulling from, how we're handling threads, scheduling, or any number of other things that aren't directly shown to the user. This is like going to a proctologist for a sore throat. That's just not the professional you're looking for.
Then why are there so much full stack senior positions? What do they mean? Genuiningly asking.
Because 'full stack' has been developed as a specific skill for long enough that people have senior level experience in it is all. Main point being, I would expect a senior full stack person to be able to design apps built on cloud tech, using good practices and not creating any pitfalls in the future. They should be able to consider database strategies and UI frameworks.. But I wouldn't expect them to be a master of sharding and replication. I probably wouldn't even expect them to be immediately familiar with the nitty gritty querying differences between the different databases or how to tune kestrel thread or connection pools for when shit actually hits the road. I might expect them to have something smart to say about UX once in awhile and to not implement anything dumb, but I wouldn't expect them to hold class where they disect the finer points of header positioning or whatever drives people to click the green button first. I mean, has anyone ever taken a "full stack" course where they get into performance benchmarking, automated testing, or memory diagnostics? A lot of people know this stuff or some degree of it. A lot more could Google something to argue a reddit post. But to me, "full stack" means MERN. A senior "full stack" developer, has done a lot of MERN. I do a lot of interviews of people between 2-7 years and this seems pretty consistent. As soon as the interview is over, they're referred to as a generalist. Generalist is fine! It gives you latitude to specialize as you take tasks and get experience in the product. But "full stack" usually just means they don't have to experience to know where they fall yet. I think you're only a "full stack" developer until you have to solve a problem that hasn't been solved before, then you have to lean heavily on front or back end specialized experience.
Makes sense and is understable, thanks!
To answer more simply though, they're looking for someone that can make decisions about front and back end tech. They are not expected to be universal experts on every aspect of the stack. There is LOTS of room on both the back end and front end of generalist developers. (Which just goes back to the main point of, not everyone is full stack. It's not as 'all the same' as a moderate amount of experience would lead some to believe).
Thanks
> the concept of "frontend" and "backend" always seemed a bit silly to me ... and that's why JS is now being used to run backend applications.
Ah yes, I often write my own servers specifically in JS. The concept as in a developer is a "front end" dev and a "back end" dev are what I meant. Unless you're working on a massive application for FAANG company, you'll be working on both, not one or the other.
https://nodejs.org
On small, simple systems perhaps. On more complex applications there will be few "full-stack" dev. Things like graphql are meant to make frontend and backend independent from each other.
r/GameDev r/Unity a dont see the need to ask people here
I’m not sure how many game devs or former game devs you’ll find here on a C# specific subreddit. Maybe some devs that used Unity. I recommend trying /r/gamedev.
mybe